As a manager, I want to tell a team what I need and they make it. Is that too much to ask?
It depends what you mean by “tell.”
Without the information we need, work is like “Bring me a stone.”
In this game, the Boss says to the Worker, “Bring me a stone.”
The worker goes out and gets a stone.
“No!” scoffs the Boss. “That’s a pebble. Bring me a stone.”
So the worker searches around and comes back with something bigger. It’s a fine example of a stone, in their opinion.
“Ugh!” says the Boss. “It’s way too round, that’ll never work. And it’s dirty, gross. Can’t you do anything right? Go out and get me a good stone.”
The poor Worker comes back one more time. Maybe the Boss wants a skipping stone.
“This is totally useless!” roars the Boss. “I have to do everything myself!”
When you don’t have the comparison function, when you can’t define “useful,” then you can’t do anything right.
If the Worker knew the Boss wanted to hold a door open, then they could evaluate each rock while they’re at the creek. Or they might say, “Hey, I have this nice kettlebell here, how about that?” And wow, that works way better than any stone.
To do stuff together, we have to trust people and teams to do their work usefully. For that, people need to understand the purpose of the work. They need a direction, not a static plan. Because if that plan were sufficiently stable, explicit and unambiguous… well, we call that code.
You can try to control a system (such as a team), or it can control itself.
If you’re the control, expect a lot of interaction — you have to monitor what’s going on, understand it, and take careful action. You are the error correction in the system. Expect to look at a lot of rocks.
This can work when the system you’re controlling is software. When the system is a team, good luck with that.
Provide the team what it needs to control from within.
Managers certainly are controllers, but they are not the only controllers. In any real development project, there are controllers at every level…. To the extent that [people] are controlling their work, the Managers’ jobs are easier. They can trust the work done, so they have less need to communicate.
Jerry Weinberg, Quality Software Management Vol. 1: Systems Thinking
Less need to communicate, yes! What do people and teams need to be their own control systems?
Weinberg’s control loop needs four things: action, observations, direction, and a comparison function.
For example: say there’s a software system that we’re changing. What it does depends on its internal state (code+production) and also what actions we take to change it.
Need 1: action, the ability to change the system. We can change the code, and we can deploy.
We can’t know every effect that our action (plus everything else in the world) will have, so we need to make observations of what’s really happening in the system.
Need 2: observations of what’s going on in the system. In production, events. In a development branch, this can be tests.
We can make decisions about what to do next by comparing what is happening with what we wanted to happen.
Need 3: desired direction, a knowledge of what we wanted to happen. Sometimes this is a Plan. In production, we might have SLAs and KPIs. In development, this could be our growing test suite.
Need 4: a comparison function. We can see the difference between what we want and what we have. This can be graphs, or test results, or judgement. This is what we don’t have in “Bring me a stone.”
If our direction is clear, our observations useful, our comparison insightful, and our actions effective enough — then we have a control loop.
TDD is an extreme of this: it makes us think about our desires and express them in a comparison function. Then we get clean observations right after every small action of code change.
In production, good infrastructure can help us get those observations, and a strong deployment pipeline can help us take action. The tricky bit is: what does the software really need to do? How well do we understand what people need from it?
If a manager can get the team everything they need for this… well, we call them a leader.