In High Output Management, Andy Grove asks us to think of a middle-manager as a mini-CEO. He states that a company messures the manager by the output of the team that the manager handles + the output of the surrounding teams that the manager influences. He states that “For every activity a manager performs, the output of the organization should increase by some degree.”
The goal of this post – focusing on the system (and the next about people) – is to highlight a few ways an engineering manager can influence this.
For a manager of engineers, the output of her team is to:
- bring a hypothesis to the hands of a customer (it could mean working software, but doesn’t need to be),
- when the customer expects it (a notion of on-time),
- with expected quality (perfect is the enemy of . . . and all that)
Often, a hypothesis is synonymous with a feature or a user story. The maturity of your product is one lens to determine the robustness of the hypothesis. Using this lens tells us that this is an experiment. If it succeeds we will need to come back to it and make it robust. If not we adjust the hypothesis and sometimes even give up on it.
You want to maximize your return on investment. Try to get feedback in the cheapest possible way that will tell you if it is valuable to a customer. In software a big chunk of your cost is time, speed of delivery is an important variable. Every second costs. Find the cheapest (fastest) way to test the hypotheses. It doesn’t always have to be production-ready code. One could even argue that in the early part of the life of a product it shouldn’t.
What does an engineering manager do to achieve this? Create a culture where the team focuses on an upward trajectory of value added to the business. The more hypotheses the team tests, the more it learns about what the customer considers to be of value. The more the team learns, the more value it provides the customer and the more ROI the team provides the company. This is the fundamental driver of growth, for the company, the team and the individuals on the team.
Page 315 of Out of the Crisis by Dr. W. Edwards Deming. “I should estimate that in my experience most troubles and most possibilities for improvement add up to the proportions something like this: 94% belongs to the system (responsibility of management), 6% special.” * Let us look at our system in this post and people in the next.
The system
Some questions we could ask ourselves about this system of ours:
- Does the team operate at a high level of trust?
- Do we know what the most valuable hypothesis is of the list we have?
- How long does it take for your hypothesis to reach our customer to get valuable feedback?
- How many hypotheses can the team take to completion in a time window?
- Does the system allow for a pair of engineers to do their best without waste?
You have a “pod”. It has 6 – 8 engineers, a tester, a Product Manager, a designer. I set aside the vagaries of the reporting structure. Unless you are an STO it is likely you have a separate product org. Reporting structure matters but not as much as we believe. You are still responsible, without the authority. But who needs authority when you can build relationships? 🙂
How does one improve the output of her team?
The following thoughts are pointers to consider. Every team is on a journey. Having a sense of the north star will help you to continuously improve.
- Build trust. Build relationships. This is harder than any process or technology. Gerald Weinberg in The Secrets of Consulting, No matter how it looks at first, it it’s always a people problem. Most hard problems are people problems. It takes time, energy and patience to build a team, brick by brick. It takes many conversations. You have won if you can bring out the diversity of your team, build on each one’s super power to the greater good. You have won if each person feels safe as a group. You have won if every team member habituates the asking of feedback. In Nine Lies About Work, the authors shows that the culture of the team is one of the most important factors in determining a team’s productivity. This is the responsibility of you, the manager, and is well within your control.
- Clear hypotheses. Loosen the definition of a product owner and bring the whole team early to define the the hypotheses. Avoid the tendency of throwing “stories” over the wall. Collaborate. Brainstorm. Build, measure, learn as a team. Tap into the wisdom of crowds. This does wonders for motivation and ownership and a sense of “team”. Measure all that matters. Be disciplined about this. Be clear, open and transparent on the measurement. Beware the highest paid person’s opinion. Remember that if you don’t put the customer first you are dilution value.
- Make your batch sizes small. Reducing the size of the hypotheses helps reduce the cognitive overload. Smaller stories mean less code, less testing, easier measurement and faster feedback. Limit WIP and queue lengths.
- Focus on engineering practices. There is a reason the great companies invest in solid engineering practices. Use a north start of pair-programming, test-driven development, trunk-based development, say. Stress clean code. Asynchronous code reviews, in my experience is deflating and expensive. It will let through code less robust than a pair of engineers merging into trunk. Scrum is perhaps a good first step but it is only a first step. Give XP practices the importance that it deserves.
- Avoid gates: Gates may protect us for a day or two – no more. Gates are a lazy way to put a bandaid on a problem. Use automation to “continuously deploy” code into Production. There is a direct correlation between the share price of a company and code deployment. Think of your Infrastructure as code. Think about it as work flowing to the customer.
- Automation – an engineer performing a manual task more than once should make your skin crawl. It is waste. Partly because this is a hidden cost we don’t insist for this. A pity. Invest early in tools that help engineers become more productive. Think linters, a pragmatic Test Pyramid, continuous deployment, automatic rollbacks, AI coding tools etc. Every keystroke counts in shaving time to receive customer feedback.
- Focus and flow: An engineer needs contiguous blocks of distraction-free time to write code. Avoid the tendency of randomly tapping an engineer on the shoulder with a product question or worse still an estimate. Create norms that define what works and doesn’t and revisit. A fragmented day leaves little time to add customer value. It is working code in the hands of our customers that adds value and ensures that the business is a going concern. Which brings us to meetings: Some meetings are critical for you to drive your business. Be disciplined. Snip a few minutes and let your engineers go back to writing code when you can. Group meetings together. Use asynchronous communication when you can. Record meetings where information flow is uni-directional.
- Processes and frameworks: Understand that these two are there to guide us. They may come across as definitive and authoritative but they are not. They are a starting point. It is up to you to inspect and adapt. And improve them every day. Building software is an engineering exercise. Make the process engineeering driven. Teams succeed with or without daily stand-ups, with or without story points, with or without tracking velocity, with or without formal planning meetings, with or without formal retrospectives, and on. It is much harder for a team to succeed without adequate unit test coverage or an automated build pipeline. Adopt processes based on what your team needs at that point of time. Ignore engineering practices at your peril. (side note: changing a programming language or a framework to something cooler might not not be as effective as you )
- Break constraints: A team is on a journey. Continuous improvement can never end. You find your biggest constraint. Break it. Find the next constraint. And keep going.
- Think systems: When an issue crops up, as they are bound to, our initial urge is to fix it. This can be hard at times. What is harder and more valuable is to fix it so that it doesn’t happen again. To do this we need to identify the root cause and fix the root cause. Needing to fix the same issue repeatedly is demoralizing and its effectiveness temporary. Ask yourself why, perhaps a few times. Ask yourself what in the system caused this to occur. Ask yourself what system you can put in place to prevent this from happening again. This is the only way to give you time to focus on delivering value to the customer.
I will cover the important 6% in this post.
* Taking Deming’s 14 points for management will help us build a viable business we are proud to be part of.
