Becoming a manager is usually one of the biggest challenges of an engineer’s career. We are usually used to algorithms and state machines, which are predictable and have specific outputs depending on the input.
But managers (engineering managers, in particular) need to deal with people. And people are not predictable. It isn’t a matter of hard skill. Managers need to invest in soft skills to indeed be useful.
The manager’s skills pack has two different tasks: to manage and to lead. So it’s crucial to understand what each term means.
What’s the difference between Management and Leadership?
Every manager should be a great leader, but a leader doesn’t necessarily is a manager.
According to John Kotter, Harvard Business Review professor, management is about responding to complexity. The main job of a manager is to deliver outcomes in an orderly (predictable) way. Planning, budgeting, and staffing are examples of management. It means using spreadsheets, organizing documents, making hard decisions about processes and people.
Leadership, on the other hand, is about producing and responding to change. As professor Kotter states, leadership activities include setting direction, aligning people, and providing motivation. It involves pushing the team forward to meet the managing directions.
There are plenty of leadership materials out there. So, in this article, I want to share some thoughts on the challenges every engineer manager goes through to manage a team. I want to talk about hard skills for having visibility and predictability over the team’s work.
On having visibility over the process
Imagine how pilots control the aircraft. They need to fly up to a given distance from the ground, to follow a given route, to reach a given velocity, to keep the cabin pressurized, and so on. On the outside, whether, pressure, gravity, and other elements impact on the flight, and pilots need to respond accordingly to keep it in the air.
Metaphorically, engineering managers have the same job. External factors like culture, engineer’s personal life and aspirations, business, and company’s goals affect the development flow.
That’s why I think the most relevant job for managers (in the point of view of management) is to create a proper cockpit. It must communicate the metrics of process and provide data to point variations and state of every single step of the process.
Just like a pilot needs to correct the aircraft’s altitude because there’s a storm ahead, a manager needs to correct WIP when developers open too many pull requests and stop closing them. That’s the dynamic. You see something not going well, and you act; then, you keep watching the metric until the route is corrected.
If you don’t know what to measure, you can start by reading:
- Measuring Engineering Teams: actionable metrics for managers
- 5 metrics managers can extract from pull requests
- 50 shades of Lead Time. Measuring each part of the development process
It’s fundamental to control flow metrics. By keeping them stabilized, you can achieve predictability much easier.
On having predictability over the process
Predictability has been in the center of software development debates for years. There are lots of techniques and strategies.
For forecasting deliveries, product managers have been simply summing up Story Points or Point of Functions, for instance. It usually doesn’t work.
You can see it by yourself. Plot a histogram of many times a User Story graded with 8 User Points takes from Backlog to Deploy. Probably, the variation is among user stories is enormous, although the grade attributed is the same.
The work to move a card throughout the development flow is unpredictable. And it’s engineering managers’ responsibility to tame this unpredictability by controlling the system. Predictability comes from paced and cadenced work.
Some managers need to define some numbers in advance to define OKRs, or to commit with some improvements. In this case, I prefer using statistics rather than a simple average.
While I worked at Plataformatec, we did several experiments with the Monte Carlo method. It may sound not very easy, but actually, it is quite simple. As Lucas Colucci simplified: it’s like brute force, but for forecasting.
If you’re not interested in getting too serious about statistics, you may calculate the median or percentiles of delivered work. Do yourself a favor, don’t go for the average. It hides too much information.
If your median throughput is 15 work items delivered per week, then you can expect next week’s iteration to have a similar number. If 75% of last weeks’ work items delivered were 20 or less, then next week’s throughput should be near 20 with 75% of confidence.
If you need to set a date, do the same math, but use Lead Time instead of Throughput. If 95% of the last month’s work took 15 days or less to be done, then multiply the number of expected items to be delivered by 15 days.
Conclusion
Becoming a manager implies being good at management and leadership. In this article, I talked about two challenges of the management: control and predictability.
I shared some advice on how to control the development flow, and how you can achieve predictability from it. The article does not cover everything on the matter of management. But it can help just-promoted-engineers to understand what is expected from them from now one.
For more articles and tips, subscribe to our engineering management newsletter!
The post Becoming a manager of engineers: focusing on visibility and predictability appeared first on SourceLevel.
Top comments (0)