How to Build an Engineering Culture that Focuses on Impact
This was first published to my weekly Q&A mailing list. Every week, I pick a different reader’s question to answer as honestly as I can.
How do you create a culture of effective engineering in a large company outside of Silicon Valley? I’m the CTO of a company with almost 2,500 people, most of them engineers. One of my missions is to create a culture of engineering where my team not only focuses on technology (learning new “cool things”) but also on delivering value and impact for the business.
How do I create this balance between technological innovation and business effectiveness? How do I make our engineers eager to not only play with technology but also to generate business value?
Many years ago, during my time at Quora, the entire product and engineering team experimented with reviewing together how each project affected the business’s top-line growth metric. Which projects contributed the highest returns on investment toward growth? Which projects had we expected to drive growth, but had fallen short?
That monthly practice conveyed a crystal-clear message: what mattered most for any project was its impact on business growth. Individual teams spent more time discussing how to estimate and measure the impact of their work, and they prioritized their work based on the projected impact.
How engineers make tradeoffs depends strongly on the values behind the company’s culture. And that culture is heavily shaped by the conversations we choose to have and how engineers fit into those conversations.
Shape your culture through conversations and stories
When I was interviewing Bobby Johnson — the CTO of a data startup called Interana — for my book The Effective Engineer, he shared with me the importance of storytelling in building company culture. He had built up the early infrastructure team at Facebook and shaped the team’s early culture around focusing on impact.
“A lot of culture comes from stories,” Johnson said. “You write down your values, but they don’t actually mean anything until you have some story that gives it context.”
Johnson believed strongly in rewarding people who fixed stuff. Many engineers tend to gravitate toward new and shiny things, but the true heroes were the people who kept critical systems up and running – and so he explicitly celebrated them.
At team meetings, he’d congratulate people who contributed important fixes. In team emails, he’d point out and share graphs of the performance impact or the reliability impact of different fixes. In casual conversations, he’d tell stories of how people debugged particularly nasty bugs. The net result was that people who worked on grungy but critical tasks knew that they were being valued at the company.
If you want to build a culture where business impact is a key context behind engineering decisions, that culture comes from the stories you tell, the conversations you have, and where people see you spending your time.
It comes from sharing customer stories around the value that people see in your company’s products and services, as well as the pain points they continue to face.
It comes from explicitly discussing and measuring the value of projects based on the company’s key performance indicators and the business impact that they have.
It comes from celebrating the unsung heroes who spend time addressing or fixing critical business needs — especially if the work isn’t glamorous — and directly acknowledging the value they’re providing to the team.
Where you choose to spend your time and energy directly influences how those you lead spend their energy. If you spend most of your energy reviewing tricky or fun technical decisions, you send the message that technical focus is the top priority. If you spend most of your time asking the hard business questions, you send a message that business impact is important.
Motivate with autonomy, mastery, and purpose
Emphasizing business impact is only one part of the story. What else can help motivate engineers to rally around it?
In his book Drive, Daniel Pink argues that motivation comes from three key elements: autonomy, mastery, and purpose. When a focus on impact reduces autonomy in technological choices or opportunities to tinker with and master new tools, we need to compensate for that autonomy and mastery in other dimensions.
For example, how might engineers play a bigger role in shaping product and business decisions? If engineers are viewed as partners rather than as just implementers who are handed work to do, they have the opportunity to see the bigger business context behind their work. Oftentimes, a desire to shelter engineers from these details to help them focus can actually backfire — the greater sense of ownership and purpose supports the autonomy that’s needed to keep people motivated.
What opportunities might exist in certain business areas for technological innovation to directly translate into business value? Many tech companies will organize 20% time or hackathons — what ideas might come out of an organized time block of effort targeted at a particular business or product area?
How might you provide opportunities to challenge engineers to develop mastery and grow in other ways? Many senior engineers will be seeking technical leadership opportunities, for instance — what resources could the organization provide to both support and encourage that growth?
These are all hard questions, but they’re high-leverage ones to explore.
When Raffi Krakorian — who had just finished a role as an engineering VP at Twitter — was reviewing a draft of my book, we discussed the topic of motivating engineers. “Why am I wasting my most valuable minds on an already solved problem!” he’d tell people who wanted to explore new and shiny tools to replace the tried and true. “Just think of what we could do if we were all focused in the right place.”
Paint the vision of what’s possible, and then give engineers the space to channel their collective energy toward that vision.
“A comprehensive tour of our industry's collective wisdom written with clarity.”
— Jack Heart, Engineering Manager at Asana
“Edmond managed to distill his decade of engineering experience into crystal-clear best practices.”
— Daniel Peng, Senior Staff Engineer at Google
“A comprehensive tour of our industry's collective wisdom written with clarity.”
— Jack Heart, Engineering Manager at Asana
“Edmond managed to distill his decade of engineering experience into crystal-clear best practices.”
— Daniel Peng, Senior Staff Engineer at Google
Leave a Comment