Engineering Excellence (part 2)
by @eborden on October 03, 2022
In the previous post we discussed measures of excellence that have wider adoption in industry. They are accepted, have benchmark values, and frequently speak to delivery/user-value. These metrics keep us honest about how we deliver excellence to our users, but they do not speak about how we deliver excellence to ourselves.
An engineering org is larger than the sum of its delivery. It is also a culture of individuals with creativity, challenge, and expression. We want to ensure that culture is healthy and delivering excellence for each of its participants.
Number of RFC Authors
num rfc authors = count(distinct rfc authors)
When exploring new territory, reducing risk for large projects, and stretching our abilities we write RFCs. These are an opportunity for engineers to do research and defend their opinions.
A healthy team has opinions and many people that express them. A team with no strong voices likely lacks psychological safety. A team with only one strong voice will be blind to many opportunities and risks. A team with a diversity of voices can build a sensing resilience. They are more likely to see positive innovations, avoid traps, and generate creative lush ideas.
Number of Blog Posts
num blog post = count(blog posts)
Blogging is a social phenomenon of excellent teams. There are many reasons for this, but one reason stands out.
Teams are driven by the stories they tell themselves. Blogging challenges the team to develop a narrative voice. An effective narrative voice allows teams to advocate for themselves and also trains them to recognize stories developing in the org. Your team cannot make positive change if they cannot identify the stories that are forming and driving their current circumstances.
For this reason we want to ensure our teams are empowered to use their voices, share their ideas, tell stories, and craft the narrative of their experience.
note: With a more robust blogging culture, we may move to tracking unique blog authors instead of cumulative posts.
Number of Debt Tasks Completed
num debt tasks completed = count(debt tasks completed)
All orgs have technical debt, strike trade-offs that create debt, and must manage the life cycle of said debt. If our teams are not prioritizing and paying down debt then their day to day quality of life will begin to decay, our agility will reduce, and solving problems will become harder and harder.
We track completed debt tasks to ensure that continuous work is proceding. Finding the balance between user value and hygeine can be difficult, but we never want to be in a circumstance where debt is lost as a priority.
We utlimately want teams that can maximize their impact on our users, our problem space, the market, and on each other’s well being. We want engineers that are excellent and we want engineers that our excellent to each other.