Skip to main content

On engineering

I've been a product and engineering lead more often than any other role in my career, including when I co-founded my first startup over 15 years ago. Back then, I'm the first to admit that I had no idea what I was doing, and had to learn on the go. These days, a few things have become clear.

"Engineer" and "programmer" are not interchangable terms. The purpose of an engineer is not so much to write code as to engineer a solution with the time, team, and resources at your disposal. In most situations, that probably does mean writing code. But it might not. And it certainly also means architecting systems, considering the user's context, some degree of training and documentation, and having a user-centered product eye as well as a technical point of view.

For that reason, engineers don't just need to be technically skilled. They need to be empathetic and highly communicative. And they need to be able to tease their way to a solution even when none is readily apparent, using creativity and curiosity in combination with the breadth of their experience.

In fact, I would say that empathy, curiosity, and communication are the three most important engineering skills. An engineer who can't put themselves in someone else's shoes is never going to create a satisfactory solution for them. An incurious engineer will stop when the going gets tough. And an engineer who can't communicate won't be able to build a system that others can use or maintain.

The role of an engineering lead is to assemble a high-functioning team, and then create the conditions for them to do their best work in the context of the company's mission, vision, and strategy. It's not about delivering tasks from on high and monitoring their progress; nor is it about churning out code; nor is it about merely consulting with them at key strategic moments. It's about finding and nurturing people who can be first-class contributors, and collaborating them on the why, what and when of what needs to be done. And then being in service to your team, ensuring they have what they need (even - and especially - when they themselves can't quite put their finger on what, specifically, that is).

There are obvious best practices. Well-defined sprints with detailed user stories are important. So are automated tests and continuous deployment. But it's even more important to create the right frameworks for people to be autonomous. Style guides - for designs as well as for code - allow people to build features with fewer bottlenecks. Well-written specs (communication again!) and post-mortems allow an engineering team to review an idea before a single line of code is written. And I've become a big believer in checklists and playbooks. All of which should be living documents, evolving as the team and the company evolve together.

There are less-obvious best practices, too. When I joined Medium after a few years at a small startup, I was shocked at how slow everything was moving. The product was being built more deliberately, in a considered, unhurried way. It was the opposite of hustling. Radical collaboration was at the core of the company: everyone was collaborating with everyone, cross-functionally. Nobody was siloed away. And the result was a markedly better product.

Finally, of course, I believe in a prototype-driven, human-centered, radically collaborative company culture. Rather than hiding yourself away for six months and building something in the hope that people like it, I believe in an iterative process where you test your ideas with the real people you're trying to help. (Quantitative testing only gets you so far, and made-up personas don't allow you to derive surprising insights.) A high-performing engineering team must be human-centered and ready to collaborate across the whole company.

And that comes down to culture. It all does. Once again, that's the real role of leadership: to assemble a high-functioning team, and then create the conditions for them to do their best work in the context of the company's mission, vision, and strategy. It's a community-building job more than anything else.

I'm constantly learning. I can't pretend to be the leader I aspire to be. Nor will I ever be: it's an ongoing, life-long process. But concentrating on empathy, curiosity, and communication is a north star that I believe is worth following closely.


Photo by NESA by Makers on Unsplash