“Build, Measure, and Learn” when it comes to your engineering organization
When it comes to building a product, the “Build, Measure, Learn” feedback loop has become something of a mantra in software development.
The process, whether you call it Agile or adopt it as part of the Lean Methodology, is designed to drive performance by focusing on improving the product.
Incremental improvements. Based on data. One learning at a time.
But when it comes to building and leading teams of engineers, we’re way behind.
Somehow our post-mortems and retrospectives have focused exclusively on the work product (what has been built) while ignoring the work process (how we did building it).
Let’s say your team just added a new live chat feature to your product.
With Build-Measure-Learn, you quickly assess the success and failures of what was built. You might ask:
- How are customers using it?
- What happens if we change its color, position, or call to action?
- Are the changes helping?
You evaluate the quantitative and the qualitative data, communicate with the team, and rapidly iterate. You prescribe upgrades and bug fixes for slower performance and update requirements based on customer learnings. It’s a well-established path to a continuously improving product.
But Agile only contemplates what was built, not how it was built.
When the real blockers to improvement are rooted in poor communication, unnecessary process overhead, or team fundamentals, those types of dysfunction can go undiagnosed for years.
If the overarching goal of engineering is to deliver value to our customers and company consistently, it’s a wonder that Engineering leadership has been flying blind without the other half of the story.
How we got here
It might have something to do with our education system.
Take a look at the modern day computer science curriculum. You might notice that the entire concept of productivity is, well… nonexistent.
There aren’t classes called “Software development lifecycle 101,” “How to work well with other Engineers,” “Giving effective feedback,” or “How to implement, change, and optimize work processes.”
In the end, everyone graduates knowing how to code. And that’s really where our education system stops.
Fast forward to the first job. Most people will absorb everything they know about engineering culture and work processes in that first year of employment.
That’s where many engineers have their first experience with productivity. If they join a 10-person team that runs 2-week sprints, they’re naturally going to begin optimizing their work patterns around that cadence.
They learn what easy work, hard work, and productive work looks and feels like. Ultimately, they leave with a set of assumptions around engineering productivity and carry this with them as they progress in their career — never having a reason to revisit them.
And that’s what we have today. We have millions of developers operating from a set of assumptions that were never re-evaluated. Never returning to how they work (or how their team works) to ask whether that’s really the best way.
Why data matters in engineering
On a high-level, not measuring your teams’ efforts will undermine your ability to advocate for corporate resources. It makes it hard to know how projects are going, or whether engineers are effectively being onboarded.
Setting clear expectations is tough when no one knows exactly how well they’re doing, and it’s practically impossible to benchmark progress for specific teams, individuals, the organization as a whole, or any of the above as compared to the industry.
Data-driven engineering leadership allows teams to:
- Evaluate team performance relative to cost
- Eliminate manual reporting, subjectivity, and delayed information
- Drive performance with actionable metrics
- Recognize when a team or individual is off their normal pattern
- Understand strengths and weakness compared to industry benchmarks
With data, engineering leaders can evaluate the health and capacity of their teams. Data-driven leaders know when engineers are doing well, or need help, or when they have been pushing through the difficult and less-flashy work. They show outside stakeholders how hard their teams are working, protect their teams’ from distractions and unclear specs, and advocate for more resources.
GitPrime solves all for all of this. We believe that a more holistic picture of Engineering can be found in the data that drives a modern software organization.
We’re turning on the lights with data—on costs, results, efficiency, and performance—so engineering leaders can make smarter investments, build better products, and improve operational excellence.
I invite you to join us and see how much better it is with the lights turned on.
Get Engineering Impact: the weekly newsletter for managers of software teams
Keep current with trends in engineering leadership, productivity, culture, and scaling development teams.