Empower your engineers
I recently read a great article by Gergely Orosz called "What Silicon Valley "Gets" about Software Engineers that Traditional Companies Do Not", and in it he makes a few points that really resonated with me as an engineering leader:
- Treat engineers as "Curious problem solvers, not mindless resources"
- Engineers need "Exposure to the business and to business metrics"
- "SV-like companies think of engineers as value generators, and creative problem solvers. Traditional companies think of them as factory workers."
When I think back on the very best teams I've managed over the years - the ones where we got the most done, delighted our users the most, and had the most fun - these were the teams where the engineers were truly empowered. They weren't treated like cogs in some machine, they we actively engaged in understanding what problems our users and our business faced, and they took part in deciding what we were going to do to address those problems.
"So what's the upside here?", you might ask. To put it succinctly - empowered engineers solve more of the right problems quicker and are more satisfied doing so. Marty Cagan says that empowering your engineers is the single most important factor towards moving your team from a feature factory to an integrated product team. To get a bit more specific on the benefits:
- Your engineers will have more context for every problem they solve. They will understand which things are really big issues for the users and the business, not just the technical challenges they face.
- Your engineers will have more buy-in. Can you think of a team you've worked on where the product manager decides what's going to be done and the engineers walk away grumbling that the PM doesn't have a clue what they're doing? I bet you can.
- Talking to users and understanding user research will help the engineers do their job. Rather than only getting user insights secondhand, your engineers will directly understand your users' needs.
- You'll better leverage the collective problem solving skills of your team.
- Your engineers will be inspired by talking to users and understanding the context and vision for your business. They'll be more engaged and motivated. They'll take your users' problems personally.
Alright, so let's say you have a team today where the engineers are decidedly not empowered. How do you make steady progress towards a more empowered team? There's no magic formula, but here are some things that have worked well for me over the years:
- As John Cutler says, start together. I can't emphasize this one enough. Don't have your PM come to the engineers with a finished spec for what they're going to build. Even if they have free rein for how to implement it, that's not empowerment. Get the entire team together at the very beginning of any initiative.
- Have your engineers take part in user research and give them other opportunities to talk to users. Nothing helps an engineer understand a user's pain quite as much as watching it. And as an engineer myself, I know this can be horribly painful but you've simply got to do it. By having everyone on the team talking to users, it democratizes access to the insights needed to have good discussions within the team.
- Break down the wall between design and engineering. One of the collaborations that can leave engineers feeling distinctly un-empowered is relationship between designers and coders. If this "collaboration" involves designers tossing finished designs over the fence to their engineering counterpart, then that's not a collaboration. This one is particularly addressable - beyond starting together, have your designer and engineer work side-by-side and iterate together. Instead of handing over design work, have the designer and engineering sit together and design by changing the UI code directly.
- Build trust in your team in order to actually get engineers to speak up. I wrote a separate blog post with some tips for this one.
- Expose your entire team to business and product metrics.
- Hire for the behaviors you want to see. If candidates show no interest in your actual business, just the technical aspects of the role, question whether they're the right fit. Make sure engineers understand that active participation in discussions around the product is really part of their job description.
- Resist the voices in your head that might tell you "if we do this, our engineers will spend less time coding." Trust your team and trust in the benefits of being an integrated product team which truly collaborates closely.
I hope this is a useful starting point for you to start discussing these ideas in your teams. It's not an easy path, but the benefits can be huge.
PS - plenty of people disagree with this viewpoint. Here's a fun video/discussion you should check out to see some different perspectives.
Are you a member of a team that's trying to make the journey from feature factory to a highly-collaborative product team? Are you tired of clunky issue trackers and project management tools that don't support the way your team tries to work? If so, we built Kitemaker for you! Head to https://kitemaker.co to sign up, or reach out to us at hi@kitemaker.co if you'd like to have a chat about how your team works today and how Kitemaker might be able to help.
Thanks for reading! Did you find this article useful? If you want to see more material like this follow @ksimons and @KitemakerHQ on Twitter.