An ounce of prevention is worth a pound of cure when it comes to conflict between founders and engineering leaders. Here's how to head off tension before it develops. By Steve Sinofsky (Executive in Residence, Harvard Business School)
When starting a new product there’s always so much more you want to do than can be done. In early days this is where a ton of energy comes from in a new company—the feeling of whitespace and opportunity. Pretty soon though the need for prioritized lists and realities of resource/time constraints become all too real. Naturally the founder(s) (or your manager in a larger organization) and others push for more. And just as naturally, the engineering leader starts to feel the pressure and pushes back. All at once there is a push to do more and a pull to prioritize. What happens when "an unstoppable force meets an immovable object", when the boss is pushing for more and the engineering leader is trying to prioritize?
I had a chance to talk to a couple of folks facing this challenge within early stage companies where a pattern emerges. The engineering leader is trying hard to build out the platform, improve quality, and focus more on details of design. The product-focused founder (or manager) is pushing to add features, change designs, and do that all sooner. There’s pushback between folks. The engineering leader was starting to worry if pushing back was good. The founder was starting to wonder if too much was being asked for. Some say this is a "natural" tension, but my feeling is tension is almost always counter-productive or at least unnecessary.
There’s no precise way to know the level of push or pushback as it isn’t something you can quantify. But it is critically important to avoid a situation that can result in a clash down the road, a loss of faith in leadership, or a let down by engineering.
As with any challenge that boils down to people, communication is the tool that is readily available to anyone. But not every communication style will work. Engineers and other analytical types fall into some common traps when trying to cope with the immense pressure of feeling accountable to get the right things done and meet shared goals:
- Setting expectations by always repeating “some of this won’t get done”. This doesn’t help because it doesn’t add anything to the dialog as it is essentially a truism of any plan.
- Debating each idea aggressively. This breaks down the collaborative nature of the relationship and can get in the way, even though analytical folks like to make sure important topics are debated.
- Acting in a passive aggressive manner and just tabling some inbound requests. This is almost always a reaction to "overflow" like too much sand poured in a funnel—the challenge is just managing all the inbound requests. This doesn’t usually work because most ideas keep coming back.
What you can do is get ahead of the situation and be honest. A suggested approach is all about defining the characteristics of the role you each have and the potential points of "failure" in the relationship.
As the engineering leader, sit down with the founder (or your manager) and kick off a discussion that goes something like this as said from the perspective of the accountable engineering leader:
- We both want the best product we can build, as fast as we can.
- I share your enthusiasm for the creativity and contributions from you and everyone else.
- My role is to provide an engineering cadence that delivers as much as we can, as soon as we can, with the level of quality and polish we can all be proud of.
- We’ll work from a transparent plan and a process that decides what to get done.
- As part of doing that, I’m going to sometimes feel like I end up saying "no" pretty often.
- And even with that, you’re going to push to change or add more. And almost always we’ll agree that absent constraints those are good pushes. But I’m not working without constraints.
- But what I worry about is that one day when things are not going perfectly (with the builds or sales), you’ll start to worry that I’m an obstacle to getting more done sooner.
- So right then and there, I’d like to come back to this conversation and make sure to walk through where we are and what we’re doing to recalibrate. I don’t want you to feel like I’m being too conservative or that our work to decide what to do in what order isn’t in sync with you.
That’s the basic idea. To get ahead of what is almost certainly to be a conversation down the road and to set up a framework to talk about the challenge that all engineering efforts have—getting enough done, soon enough.
Why is this so critical? Because if you’re not talking to each other, there’s a risk you’re talking about each other.
We all know that in a healthy organization bad news travels fast. Unfortunately, when the pressure is on or there’s a shared feeling of missing expectations often the first thing to go is the very communication that can help. When communication begins to break down there’s a risk trust will suffer.
When trust is reduced and unhealthy cycle potentially starts. The engineering leader starts to feel a bit like an obstacle and might start over-committing or just reduce the voice of pragmatic concerns. The manager or founder might start to feel like the engineering leader is slowing progress and might start to work around him/her to influence the work list.
Regardless of how the efficacy of the relationship begins to weaken, there’s always room for adjustment and learning between the two of you. It just needs to start from a common understanding and a baseline to talk and communicate.
This is such a common challenge, that it is worth an ounce of prevention and an occasional booster conversation.
This post originally appeared on Learning by Shipping. About the blogger: From 1989 through 2012 Steve Sinofsky (@stevesi) worked at Microsoft on a range of products including development tools, Office, and Windows as software developer, program manager, and general manager. He is currently Executive in Residence at Harvard Business School, an advisor at Box, and Board Partner at Andreessen Horowitz.