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 than 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.
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:
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.
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.
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:
Although the advantages of Synthetic metrics are promising, some questions remain:
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?
(Disclaimer: The Author is the CEO at SourceLevel)
Originally Published here