At my last workplace, it was uncommon for engineers to communicate with our clients. We collectively referred to this concept as the “developer veil”. As an engineer, I could hide behind an imaginary wall: all I had to do was write code and perform the tasks expected of me, and I didn’t need to worry about having to talk to anyone outside of our organization: an introvert’s dream! On the surface, this actually makes a lot of sense. Developer hours are expensive, and if you bog engineers down with user meetings, long email chains, or taking phone calls, they’ll never actually have time to write code for you. This is Scrum 101: get a PM who handles all customer communication and let your person who writes code write code.

For a long time, I didn’t believe software development had much of a chance at success with any other mindset. When I came to Proton, however, I learned that we do things a bit differently. And now that I’ve been here a while, my perspective has changed: I’ve come to appreciate it. At Proton, we make it the mission of everyone — including our engineers — to understand our product and users, and I think it makes our teams more effective in the long run.

How Is Proton Different?

Compared to a more “traditional” scrum workflow, Proton’s team organization shares many similarities. We have a product manager on each team that does most of the direct communication with our users, takes bugs and feature requests, and determines overall direction of a specific piece of our product. Tech leads on each team serve as the “scrum masters,” delegating specific tasks to engineers, managing blockers, and taking on any administrative or busywork that might otherwise interfere with their engineers’ ability to complete their tasks. Engineers are then the bread and butter of the team, writing code to fix bugs and build features to make our overall product stronger and our users successful.

What makes Proton different, then? Simply put, engaging with our users is encouraged for all of our employees, not only people on the product team. For engineers, this of course means giving up the developer veil. User calls are shared on a public company-wide calendar where anyone is free to get facetime with real-life users of our product. All our user calls are also recorded and saved in an internal database so we can listen to the conversation if we weren’t able to join the call or want to reference it again. Have a few spare minutes while something is building? It’s a cinch to watch a few minutes of a user conversation. And if you are really interested, and the opportunity aligns, you may just find yourself getting some in-person experience with one of our customers at their office.

The In-Person Visit

During my second month at the company, a small group of Proton employees came to visit a prospective client at their office in my residing city of Dallas. While not custom, I invited myself to be part of this visit for a crash course on distribution.

At the time I was coming in with no knowledge how our customers’ businesses worked, and very little understanding of our users’ day-to-day experiences. There’s nothing quite like being able to sit with someone using my code to see how they really use it. We spent the day shadowing several sales reps, discussing how they work, talking about their biggest challenges, and thinking about what Proton could do for them.

We also spent time with their managers to get a read on more organization-scale challenges, the managerial perspective. Talking to these more senior people, we learned Proton was a game-changer in providing clarity and transparency to managers. They could check in on the work their reps were doing without having to individually ask for updates. Understanding this use case was huge for me in grasping the why behind all the code I write. As a bonus, I was able to meet fellow Proton employees in-person for the first time: a rare treat at a fully-remote company such as ours!

Why Remove The Veil?

Hopefully you’re starting to get an idea of why communicating with users directly is important for engineers. Let’s bring it all together.

  • Better understanding of the user. When you speak with a client and see them use your product, you gain valuable insights into what works and what doesn’t. As you start to get a feel for a user’s daily habits, you understand how your application fits into their everyday life. This makes it easier to move more nimbly. I understand what functionality can get cut and which features are non-negotiable when I run into a potential roadblock.

  • Better understanding of the industry. Just as Proton is my first foray into the world of distribution, other developers — whether you’re in fintech, healthcare, or at a social network — may also be writing code for an industry they’re unfamiliar with. Getting involved in user conversations will bring more context into your work and let you see the bigger picture of the difference you are making with your code.

  • Build more robust features. With a better understanding of your users and the industry, you have a new lens through which you can examine your work. You’re more likely to dream up realistic edge cases for inputs, catching potential issues across your application that you may never have considered otherwise.

  • Ideas for meaningful new features. When you see your app from the perspective of the people you’re solving problems for, there’s a chance you’ll run into brand new ways you could make your software better. Perhaps you’ll stumble on challenges your users face that no one else has spotted, and can advocate building solutions to meet those needs. Opportunity for engineers to influence the product - The new feature ideas and perspectives you gain from conversations with users may give you an opportunity to bring suggestions to the team on what you should build next. This could be very refreshing if you’re used to just having feature requests handed down to you from a PM without you having much input in your work.

Are Product Managers Even Needed?

Of course, the answer to this hypothetical question is a resounding yes: we of course need product managers. Product managers fill an entirely different role than engineers in communicating with the user. At Proton, our PMs and tech leads are the definition of servant leadership, taking on meetings, email threads, and calls on a daily basis so that we as engineers don’t have to and can spend our time doing what we enjoy, building software. If we engineers get a sense of how our users work, our product team knows them inside out. Without PMs, you’ll likely end up with engineers who become glorified data loggers, wasting their potential, and prone to bounce towards an opportunity elsewhere where their skills will be better used.

Veil or No Veil?

By now the advantages of developers spending time with product users should be clear. Understanding why we’re building something helps us build better. At Proton, we’ve found success when we encourage our engineering team to spend two or three hours every month with our users learning what makes them tick, while leaving the customer relationship itself to be handled by our talented product management team. At the end of the day, removing the developer veil will likely only be successful if you are willing to cloak yourself back after a little bit of user interaction and go back to your introverted self and write some code. If that sounds like your cup of tea, we’d love for you to consider getting to know Proton more to see if there may be an opportunity for you here as an engineer.