Having impact in engineering by supporting other people's ideas

A staff engineer recently asked me about having more impact and whether they should be generating more ideas. I didn’t think so.

Their organization has plenty of mid-level engineers who are coming up with great ideas every day: ideas that go nowhere because they aren’t quite robust enough or just don’t seem to gain traction. I suggested that the staff engineer choose one of those ideas, help make it as good as it can be, be very vocal about their support of it, and then give 100% of the credit to their more junior colleague. That’s where the impact comes from.

That’s a mindset shift! When company tech incentives reward and promote people for ‘impact’, the impact is often framed as, ‘What did you, a single individual, do?’ When we write our self-assessments, we might emphasize action verbs like ‘designed’, ‘implemented’, ‘initiated’, ‘wrote’, ‘drove’, ‘led’. In fact, when I’ve reviewed more junior friends’ promotion packets, I’ve recommended words like these instead of downplaying the contribution as ‘being involved’ or ‘helping’. To get to senior levels you have to show self-direction and ownership!

But, at staff-plus and manager levels, the ability to generate new ideas is just part of the table stakes that got you here. The real superpower is your ability to support other people’s ideas and transform them from concepts into something that will actually work in reality.

Other people’s ideas

In any growing software organization, there are problems that span multiple teams or multiple orgs – problems that can’t be solved by a single person who’s off in their own corner. And usually, there are a lot of opinions about how any big problem could be solved: a new architecture, a change in technology, a reorg, a culture shift where everyone changes their behavior just a little. How do we react when someone proposes one of these ideas?

Well, for a lot of us, our first impulse is to show how we would solve the same problem, or perhaps how we have considered solving it in the past. We urge caution; we tell war stories; we deliver some brutal honesty about the difficulty of the path ahead. Maybe we even claim some ownership of the problem domain, insisting that we should be involved in any path forward. The person with the idea leaves with a little less energy, the wind taken out of their sails. Some will be lucky enough to meet a tailwind elsewhere, or will have the resilience and tenacity to keep pushing, despite the lack of support. But many baby ideas will just fizzle out here, even if they could have been nurtured into great plans.

In many cases, any reasonable path forward would improve the situation, and the worst decision is to make no decision at all and keep the status quo. But when there’s competition between ideas, the status quo is often exactly what happens. Everyone wants to be the visionary senior person who solved a problem; nobody wants to be the cheerleader or the quiet voice of support. We can end up in a deadlock, and the problem doesn’t get solved.

Don’t lick the projects

The more senior we get, the more experiences we have. That means there are more situations that we’ll have an opinion on. When we see a familiar-seeming problem, we may have a gut reaction about the best way to solve it. It’s natural to talk with others about that opinion, maybe even to write a short document about the system we should replace or the architecture we should move to. When someone else comes along with their own plan to solve the same problem, we might get a little territorial. After all, we already described the solution! We just haven’t had time to do something about it.

There’s a fantastically disgusting term for this, which is cookie licking. You don’t want to eat the cookie right now, but you don’t want anyone else to take it, so you stake a claim on it in a way that will make other people not want it. With projects, we might not be consciously setting out to make the project unappetizing to other people, but that’s the effect of claiming it. ‘Licking the project’ adds uncertainty. The next person has to navigate confusion about whether they’re working with you or competing. Other people who hear about your colleague’s idea may hesitate to support it because they think you’re solving the same thing, or because your lack of progress on it has made them assume it’s impossible. So, by claiming the problem, you might make it less likely to get solved, not more.

If you don’t have time to take on a project, vocally cede the domain and support someone else’s attempt instead.

But it’s not how I would have done it

What about when you think your colleague’s project is taking the wrong direction? It depends. Just how wrong is their direction? If there’s a reason their project really can’t work, give them all the information you have. It’s kinder to be honest here. But, once the person with the idea has all of the context you do, let them make their own decisions. Maybe they have solutions you haven’t thought about. Maybe they have more time available to push through obstacles. Maybe they’re solving a slightly different problem than you were. If they still think the idea can work, don’t just assume they’re wrong. Understand the reasons for their confidence, and see if you can help them succeed.

If the direction feels possible but risky, think about whether you can suggest changes to make it safer. Are there incremental milestones that could prove the concept? Could you encourage a prototype or limited rollout? Even if you’re not certain the idea can land, could you support your colleague by telling them you’re excited to see the result of an experiment? Can you be excited to see the results of that experiment?

Try to be open to directions that aren’t where you’d planned to go. If the solution you don’t prefer is still going to solve the problem, make sure your colleague knows about any hazards in their path, then either become their cheerleader or get out of their way. (To be clear: ‘disagree and commit’ doesn’t extend to endorsing ideas you think are dangerous or actively harmful; save your arguments for these ones.)

Be a supporter, not a bystander

When you don’t have particular objections, or only have small ones, you can help a project by saying that explicitly. A lack of comments is ambiguous, and good ideas can run out of steam for lack of clear support.

Think about how you can endorse an idea and give it momentum. Some ideas:

• If you’re reviewing a document, don’t just comment on the parts that need to change. Leave a comment somewhere near the top of the document – where every reader will see it – to say that overall you’re in support and that you think this is a good direction.
• If you’ve written your own documents about solving the problem, update them to redirect to the new plan.
• Take opportunities to name-drop the project. Link to it from other things you’re doing. Describe its success when you describe a vision for the future. If you hear of a related project, make sure to connect the people together.
• When someone asks you questions about the problem domain, redirect the questions to your colleague. You might need to do this repeatedly before everyone accepts that the new owner is the go-to person for the project and that you’re not.
• Be what Mekka Okereke calls a ‘Difficulty Anchor’ for your colleague, i.e., someone who can speak about the importance and complexity of the work, and prevent it from being devalued later.

If someone is going to solve a real problem that you care about, it’s worth spending a little social capital to clear roadblocks, give them a reputation boost, or otherwise help them succeed. But make sure credit for the solution stays with the person who’s doing the legwork. Trust me: a leader who makes everyone around them more successful is building goodwill and reputation and is not going to be hurting for credit.

Building an org that likes to say yes

It’s a great working experience when it doesn’t matter whose idea something was. But, of course, sometimes it does. In organizations with a lot of senior people, there can be a fight for the opportunity to show impact. If you’re in a place with limited ‘good’ projects, sometimes there’s a struggle to be the one to own a problem domain. I’ve seen this happen in companies with more senior people than they really need: there’s a constant battle to get your name on the promotable work.

If you’re a leader in an org like that, be aware that the best ideas aren’t winning. If two engineers are working on adjacent problems and only one can ‘win’ and be promoted, they’re incentivized not to work together. That setup means there’s almost guaranteed to be a power struggle about who gets to ‘win’ the technical direction. It can lead to what I’ve heard called ‘ape games’: dominance plays and politicking where each person tries to establish themselves as the leader in the space. It distracts from actually solving the problem and it’s toxic to collaboration.

Instead, find ways to incentivize letting work happen. Don’t promote based on having ideas, but on removing roadblocks, making everyone else successful, and doing the work to get to the solution. Build a culture of calling out each other’s success, and of explicitly saying an idea is a good one, instead of staying quiet to mean ‘no objections’.

In conclusion

My friend Robert Konigsberg, a staff engineer and tech lead at Google, says that one of the most important aspects of being a good teammate boils down to this: just because an idea came from your brain, doesn’t mean it’s the best idea.

Needing to be the person with the plan is wrong and limiting. Really question your motives if you find yourself fighting for a marginally better path, especially if the better path is an idea that came from yourself. Your highest impact might be in throwing your weight behind someone else’s good-enough idea, especially when it’s a more junior person. Give them credit, back them up, help them go up a level in skills, and get the problem solved. It’s a way that everyone wins.

Thanks to Steph Hippo and Anne (juniper) Cross