There’s plenty of content out there on what we’re coming around to calling “engineering effectiveness,” the work of ensuring that an engineering organization is delivering on business outcomes by maximizing developer productivity and developer experience. There’s not so much about the hard work of implementing such a program in practice. Much is focused on what to measure and why, without much guidance on what to do with that new knowledge.
As we pointed out in the post about how size, age, and culture influence an engineering organization’s path, it’s hard to get incredibly prescriptive here. Every company is going to be different. Still, we’ve identified six pretty standard stages of taking engineering effectiveness seriously:
- In the baseline stage, you will lay the groundwork by setting up key metrics and implementing tools to understand the current delivery and team health situation.
- Next, you’ll immerse yourself in the environment of your engineering teams during the research stage. Through shadowing, interviews, and hands-on work, you’ll understand their challenges and victories first-hand.
- With this understanding, you will address quick wins—small but meaningful improvements that can immediately impact the team's work.
- After tackling quick wins, it will be time to invest in longer-term improvements. You will start standardizing processes and tools across teams to reduce complexity and improve consistency.
- After implementing these changes, you’ll work to normalize the new processes across the organization.
- Finally, you’ll commit to a long-term investment in improving the developer experience in the Sustain stage. The challenges you face will evolve as the company grows and evolves.
Baseline
The first step is understanding your current situation regarding delivery and team health. This includes implementing DORA metrics that accurately represent your software delivery performance. Getting these metrics in place demands a discipline that you’ll be grateful for in the future.
Now is also a good time to make it routine to attach Balance Framework labels to your work items to start to paint a picture of where your time is going; you might want to build or buy a tool that makes this easier. Again, this is a habit you’ll be grateful for later.
You might also take a moment to assess team health by considering satisfaction, attrition rates, and engagement levels. If you’re still small, this should be happening organically; once you’re larger than ten engineers, you may also want to create more intentional feedback mechanisms.
Remember, the goal of this stage is not to create benchmarks for comparison between teams or individuals but to understand the present state so that you can track improvement over time.
Research
Knowing how your engineering teams experience their work is essential to achieving real productivity wins.
Spend time shadowing engineers, conducting interviews, and doing hands-on work. Understand their daily challenges, frustrations, and moments of triumph. Pay particular attention to their work patterns, collaboration habits, and pain points. Watch for systemic issues that might be slowing them down or causing unnecessary stress. This first-hand understanding will be invaluable in identifying effective productivity and experience improvements.
Many or even most of the ideas you’ll hear will have technical solutions but don’t tune out people, process, and political challenges that you wouldn’t necessarily solve with code. Increasing engineering leverage without spending engineering time could be a huge win.
Now is also the time to review your early Balance Framework data: Where are teams spending their time? Are there any surprises in the data? Are there adjustments you need to make?
Address
Now that you understand your engineers’ current state and unique needs, it’s time to tackle the quick wins. Quick wins are small, relatively easy improvements that have a meaningful impact on the daily work of your teams. These could be anything from streamlining a standard process, eliminating a manual task, or addressing some other common source of frustration.
Who’s going to work on these quick wins? For now, ensure every one of your engineers knows they have permission to spend a little time making things better. Consider giving an engineer or two a two- or four-week rotation to tackle an issue they’re passionate about. Publicly celebrate large and small improvements.
Invest
With the low-hanging fruit addressed, it’s time to focus on longer-term improvements. This often involves standardizing processes and tools across teams to reduce complexity and inconsistency. Consider creating a dedicated platform team responsible for developing and maintaining shared tools and infrastructure. This investment in standardization can result in significant productivity boosts and make cross-team collaboration smoother and more effective.
Starting a team doesn’t have to be a big production: your team lead already works at the company and is looking for a new opportunity. They’re the self-directed, consistently high-impact person who’s been poking at flaky tests lately and exceeded expectations last half for automating the entire build and deployment. They’re a favorite collaborator among technical and non-technical folks alike, and they live for a good session of code archaeology.
The second engineer also works there, and they were exceeding expectations within their first months. They’re a smart execution machine in need of a good mentor. They’re interested in humans and computers, hungry for challenging problems, and don’t mind if people in the real world don’t see their work.
You will be most successful if this team thinks of internal developer platforms as products and if they understand that products have users: users who you need to talk to and listen to, especially when they’re frustrated. A platform team’s ultimate goal is to help those users produce more value for the same amount of effort.
Normalize
Standardization only delivers its full benefits if it actually becomes the default. Drive the adoption of these new processes, making it the “new normal” for how things are done. This step will likely require clear communication to explain the changes and their benefits, thorough training to ensure everyone knows how to work within the new systems, and incentives to encourage the adoption.
Be sure to support these teams throughout this transition and be open to feedback and suggestions for improvement. You can form an adoption squad to help teams make the transition and understand the benefits. Of course, whenever possible, automate these transitions. When that’s not possible, be sure to frame migration and usage instructions from the perspective of the platform user, not the platform creator.
Sustain
Maintaining and enhancing the developer experience is not a one-off task but a long-term commitment. As your company grows, so will the complexity of your DevX challenges. Continually invest in improving your understanding of these evolving challenges and devising innovative solutions. Set strategic goals that reflect this commitment and foster a culture of continuous learning and improvement.
Remember, you are focusing on improving the overall developer experience, not just specific tactics or short-term goals. This mindset will help you remain adaptable and responsive to the changing needs of your engineering teams.
What’s next?
Throughout your productivity journey, it’s important to focus on the ultimate goal: improving the experience and productivity of our engineers. This means we must avoid getting too caught up in specific metrics or tactics at the expense of actual improvement. It helps greatly if you have a single owner of what it’s like to do software engineering in your organization, someone who can oversee the effort with a coherent strategy.
This post provided a solid foundation for your journey, but every organization and team is unique. You’ll need to remain flexible, responsive, and adaptable to the changing needs of our engineering teams.
You can view a recorded version of this post here:
Embedded YouTube videos are disabled to reflect your cookie preferences. You can watch this video on YouTube.
