Engineering managers are in charge of tech teams. It means there are tens or maybe hundreds of people supporting them. Generally, they need to ensure the best practices around software development, hire and train engineering staff, align and motivate the team towards the company’s goal, manage the team’s performance, and be accountable for all technical decisions.
To comply with those objectives, managers need to perform a large number of daily activities, like 1-on-1, salary adjustments (bonuses, raises, promotions, etc.), career mentorship, job posting, resume screening, interviews with candidates, to list a few.
In summary, this position has a lot to be done. The problem is that, contrary to the engineering staff, which activities have a smaller feedback cycle, managing requires more patience. Changes in the software are faster than changes in the team’s culture. Institutionalization of a best practice across all teams usually takes way more time then taking an architectural decision on a specific project.
It is frequent to see managers struggling to foster a healthy environment where engineers can develop their personal and professional skills. Culture is not static; it must evolve and adapt constantly. Therefore, managers need to have an excellent view of the big picture.
Measuring is the best tool available for that. It is an excellent choice if your work includes understanding where you are, projecting where you want to be, and measuring progress.
Isn’t metrics bad for engineering culture?
Eliyahu M. Goldratt was a physicist that became a business guru. He once said, “tell me how you measure me, and I will tell you how I will behave.” This statement is definitively true. Once managers start to measure their teams, it’s natural to see changes in their behavior, so that the metric matches the expected goal.
To avoid this pitfall, managers need to measure not a single metric, but a set of metrics that make sense when looked together. There’s no easy answer for what to measure. It varies depending on the team’s size and maturity, the stage of the product, the complexity of the work, and many other aspects.
Finding the right metrics is an everlasting task. It’s the old PDCA applied: Plan what to measure, Do measure, Check what changed, and Adjust the metrics.
If you want to start measuring, listing crucial aspects of your culture helps to spot potential metrics. A list could include assertions like:
- We say a task is done when it’s coded, reviewed, tested, and deployed to production.
- We endorse teams to review other’s team’s pull requests
- We want to keep technical debt low
Listing the goals of your team can be used for both to find the metrics that best fit your needs and to align your staff. All those statements can be transformed into quantitative numbers, so managers can better understand which aspects of their culture or workflow need attention.
I am one person, and metrics are too many
There are lots of possible metrics. Each one tells a different version of the same story. They are essential to understand the complexity of dealing with people, the product, and the business.
It doesn’t mean you should always look to all of them. That’s the power of synthetic metrics. According to Wikipedia’s definition, a synthetic measure is a value that is the result of combining other metrics, which are measurements of various features.
It means that managers could summarize culture, productivity, and other aspects into a small set of synthetic metrics. It’s like creating buckets and then placing its result in the proper one depending on the criteria.
More about Synthetic Metrics in 2020
It’s 2019 already, and managers still create “zero bugs” policies or measure productivity in lines of code. We deserve metrics that cover all the complexity of daily challenges in software engineering.
As far as I got, synthetic metrics help managers to get closer to work performed by engineering teams. They can:
- Create abstractions that better describe reality. We all are humans. As such, we are prone to errors. There may be outliers and failures, and metrics should consider them.
- Easily spot and prioritize problems. By seeing a list of grades, buckets, or labels, managers can act precisely on teams that need their help.
- To align and promote changes with autonomy. As it is a human condition, the teams tend to adapt their process to achieve better scores.
- Track the team’s progress as a whole. Keeping track of the progress of a single grade, label, or bucket, whatever the synthetic metric is, better represent the efforts of your team as a whole. Looking for a single metric, like throughput, promotes “the champion” culture.
Although the advantages of Synthetic metrics are promising, some questions remain:
- How to start using synthetic metrics?
- Which metrics should it consider?
- What consists of a useful synthetic metric?
- How can managers create their synthetic metrics more easily?
One of my goals to 2020 is to study more deeply the impacts of synthetic metrics applied in the daily activities of engineering managers. I want to learn how synthetic metrics solved real-life problems and understand what problems they can’t solve.
What are your goals for 2020?