Maximizing Developer Effectiveness
What happens when engineering organizations neglect to provide effective working environments for developers, and how focusing on key feedback loops can help.
This week I read Maximizing Developer Effectiveness, a paper by Tim Cochran who is a Director at Thoughtworks. Tim opens his paper with an argument that resonated: “a primary reason for [low productivity and delays] is that the engineering organization has neglected to provide developers with an effective working environment.” Tim goes on to explain the importance of creating effective work environments, specific feedback loops that companies can optimize, and what’s required of leaders to support improvement efforts.
I interviewed Tim to learn more about his thoughts and research — you can listen to our full conversation here.
My summary of the paper
1. Developer effectiveness is heavily influenced by developers’ work environments
Drawing on observations from ThoughtWorks, Spotify, and Etsy, Tim summarized what it's like for developers to work in effective and ineffective working environments. An effective environment “makes it easy to put useful, high-quality software into production; and to operate it so that the developers do not have to deal with unnecessary complexities, frivolous churn or long delays — freeing them to concentrate on value-adding tasks.”
He also recognized that “being productive motivates developers. Without the friction, they have time to think creatively and apply themselves”. This perspective is in conflict with the ways leaders often approach measuring and improving developer productivity. “Organizations look for ways to measure developer productivity. The common anti-pattern is to look at lines of code, feature output or to put too much focus on trying to spot the underperforming developers. It is better to turn the conversation around to focus on how the organization is providing an effective engineering environment.”
2. To create more effective working environments, focus on key feedback loops
Focusing on the core feedback loops that developers’ encounter is one way for companies to create more effective environments. Tim presents eight key feedback loops that were identified based on analyzing the daily work of developers. He notes that “engineering organizations should conduct research within their specific context to figure out what cycles and metrics are important technology strategy.”
When these feedback loops are slow, “problems are quickly compounded. There is a great deal of wasted effort for the developers embodied in the time spent waiting, searching, or trying to understand results. It adds up, causing significant delays in product development…”
3. The importance of leadership
Tim writes that change “starts with a recognition by leadership that technology — and removing friction from development teams — is vital to the business.” Leaders must create a culture where developers are empowered to make incremental improvements to the developer experience. Otherwise change cannot occur.
Specific strategies suggested in the paper:
Create an open forum to listen to IC’s. “Developers will know the problems they face and will have many ideas on how to solve them.”
To motivate developers, make sure they have the ability to improve their day to day lives (eg. have policies to allow for targeting tech debt or other improvements).
Set up dedicated programs for big problems, but focus primarily on empowering teams to continuously improve.
As your organization scales, invest in teams and platforms focused on enhancing internal capabilities (eg. a “Developer Experience” team).
Final thoughts
Tim’s paper feels like a stellar manifesto for Developer Experience teams or anyone dedicated to improving the effectiveness of their engineers. His consolidated presentations of developer environments and feedback loops are a handy references for discussing how to improve effectiveness within our own teams. I’m looking forward to following Tim’s continued research in this area.
Other recommended reads
Tips for building effective engineering teams.
Miscommunication leads to missed deadlines
Bruce Weller, VP of Engineering at Divvy
“Missed deadlines are often the result of simple miscommunications.” Bruce says there are a few common communication problems that get teams into trouble:
They don’t separate the “estimate” from the “deadline”,
They don’t discuss the “cost of failure” (how confident do we need to be in our deadline?),
They don’t agree on what will be complete at the deadline (does complete mean the project is through testing, or is it being A/B tested with customers?), or
They don’t facilitate pushback from engineering.
Ask the team what their pain points are before instituting metrics
Mojtaba Hosseini, Director of Engineering at Zapier
“One of the things I’ve learned is to adapt the metric to the team. Start by asking the team, ‘What are your pain points and what are the outcomes you’re really after? And which metrics would help you?’ So instead of going to them and saying, ‘Okay, cycle time is the best. Or DORA metrics will surely get you out of this.’ First we’re asking, "Okay, what are your problems? Tell me about your work. Where do you think your bottlenecks are? Where are your pain points?’ That inevitably narrows down which metric they should use.”
Signs you work at a feature factory
Gergely Orosz, shared by Lenny Rachitsky
A few interesting “signs” from the list:
Decisions on what tech will build is done without tech’s involvement, coming directly from the business
Software engineers are referred to as “software developers” or “programmers”
Innovation is not expected from tech