Autonomy is the sense of free motion in a team.
I adjust the levels of this by expressing important needs as problems, letting go of unimportant needs, and managing risk by a combination of acceptance, next-stepping, and iteration.
The more we need creative technical work, the more we have to concern ourselves with providing the humans who do it the adequate autonomy to do it well.
Machines can’t give us what we need, and the extent we build machine-like things made up of people is exactly the extent to which we handicap our ability to get what we need.
At the same time, we take a risk. After all, if anything goes, some very Bad Things[tm] can go. We need to find ways to consciously manage our risk while still getting the best advantage we can from our use of those pesky non-machines whose human-ness is exactly what we value.
The advice here doesn’t really divide neatly across the three levels of individual maker, team of makers, and organizational host of maker-teams. Instead, maybe I can offer a specific case or two for each element of the pattern. As ever, you can do better than I can, if you try.
Pattern: Control the need definitions rather than the resolution techniques. That is, focus the majority of your attention on the understanding (and stepwise refinement, see below) of the problem.
A lot of orgs create a ton of procedure and rules around source code control, for instance. VBCA’s, especially, like to mandate expensive and slow source vaults from the early ’90s and wrap them with tons of forms, checkboxes, siginings, permissions, and so on.
The actual needs for source vaults are simpler than these rules & procedures suggest. 1) get the code safely repo’d in multiple well-known distant locations. 2) change the contents in annotated steps. 3) get every step signed by the person responsible for making it.
That’s pretty much it, as far as the org is concerned. Notice there’s no source vault anywhere today that can’t do all three of those things without batting an eye. There’s no intranet anywhere that can’t do mirroring.
We do better to define the need than the resolution.
One sees similar process-clusters around code standards, documentation standards, testing, technical review, and so on. In nearly every case the solution is over-specified.
The tech stack is an another example of this. If I have a team writing a service, I want that team using their best technique to fill the need for the service. I don’t care what language they use anymore than I care what keyboards they use to type it in.
Now, if the source vault one didn’t bother you, this one may still raise hairs on the back of your neck. The argument for standardization is ever-present in these kinds of situations. It goes like this:
You must all use the exact same tools in the exact same way for all projects because that gives us 1) economies of scale, and 2) interchangeable parts, and 3) easier training.
Except, there are no economies of scale in software creation, "interchangeable parts" is the language of mechanics not humans, and learning a new language is the easy part of being a geek, compared with learning a new domain and learning a new culture.
And I’ll go further: when you do this, you’re placing one of the silliest bets humans can place: the bet that today is the smartest, most skilled, most knowledgable, and most technically advanced that you will ever be.
Specifying resolutions is far more "anti-change" than specifying needs. Both are fluid over time, but one is far more so than the other.
Pattern: Use the smallest value-chunks — steps of work — you can, each one of which can be completed separately, assessed separately, and harvested separately. This is the key to accepting and managing the inherent risk of software development.
It might be that the most damaging concept in all of software development is "finish-line efficiency". This is the notion that all the value from a project derives from it reaching an endpoint, and that the best way to work is in a straight line of steps from start to finish.
The gist is to structure the work so that small amounts of work yield their value to us the moment they are done. We state the smallest possible need, seek the smallest possible resolution, ignore questions of efficiency or rework, cash it in. Rinse, lather, repeat.
At the org level, this means doing things like luring markets one improvement at a time. At the team level, it means working one story at a time. At the maker levle, it means working one test at a time.
At all three levels, it means assuming without hesitation that the resolution for today’s need will almost certainly require changes to resolve tomorrow’s need. We’re not seeking a finish line, we’re seeking a continuous influx of sustaining value.
Even if that makes sense to you as advice, you might still wonder what, exactly, it has to do with autonomy? It lowers the stakes. Lower stakes means less fear. Less fear means less need to control. Less need to control means more autonomy. More autonomy means more productivity.
Pattern: Support experimentation, even radical experimentation. Learn to design experiments, learn to propose them, box them, try them, assess them, ship them.
We’re talking here about moving ideas, not bricks. And we need idea-movers. But ideas in Platonic forms in abstract space are not nearly as valuable to us as ideas chugging around in the world.
One often sees ideas repressed because of the need for 1) permission and 2) consensus and 3) massive amounts of legwork to attain both. This is just another way "finish-line efficiency" slows us down.
We want the answer to every idea proposal to default to "Yes, how can we try that cheaply?"
So. There’s a lot to this autonomy advice. Specifying by need, harvesting value in chunks, trying lots of experiments. It fits in a sentence, but it doesn’t fit in a practice. Let’s talk about that for a second, then I’ll let you go. 🙂
A lot of what we’re talking about takes technique. I’m not talking about this at just the individual maker level. It needs technique at the team and the org level, too.
Conditioning customers to continuous improvement takes technique. Splitting needs into value-chunks takes technique. Splitting them further into stories takes technique. Enabling change in code takes technique.
The bad news is that the technique changes we have to make to boost our autonomy can be hard to learn. They are gradual, all the knobs a little, all the knobs a little. It’s not a boat we can turn around by instantly commanded change. (It’s about autonomy, after all.)
The good news is that there are people who have invested very heavily in knowing those techniques, knowing how and when to tweak the knobs, and knowing most especially how to harvest value during the steps rather than waiting for the finish line.
They’re called coaches.
When I go to raise the freedom of motion for teams — their sense of autonomy — I express needs as problems, not solutions. I emphasize value-harvestable steps to manage risk, embracing acceptance, next-stepping, and iteration, and I propose & accept lots of experiments.
Thanks for reading along! It’s a gray day in Virginia, but a warm one, and I’ve got a GeeKid zooming in for some help with his C++ homework here in a bit.
I hope you get a warm day with a chance to help one of your favorites, too!
Listener Support and How to Be On the GeePaw Podcast
If you love the GeePaw Podcast, show your support with a monthly donation to help keep the content flowing. Support GeePaw Here.
You can also show your support by sending in voice messages to be included in the podcasts. These can be questions, comments, etc. Submit Voice Message Here.