einarwh

Don’t settle for a playground

March 29, 2023

This is a transcript of a talk I did at Booster 2023 in Bergen.

Here’s a scene. Imagine we’re having a stand-up meeting. A stand-up meeting, as you will be aware, is a ritual where a team of software developers stands in a circle in the hope of summoning the spirit known as agility. If a sufficient number of teams performs this ritual, it brings about a digital transformation in the organization, and everyone becomes happy and productive.

Anyway, we’re having this stand-up meeting, and something comes up. Suddenly everyone goes quiet, and gazes down at their feet. There is a moment’s awkward silence, until someone looks up from under their eyebrows and says “we’re gonna need a grown-up for that”. And then we snicker a bit, cast sideways glances, shuffle our feet, and move on to something else.

Is this scene familiar to you? Have you been in this scene? I don’t know how culturally specific it is, but I’ve been in this scene multiple times. And I must say that to me, this scene is the least dignified scene in all of software development. It makes my skin crawl, it fills me with shame, and it makes me angry.

Here’s the thing: I’m not a child, and I’m not going to cosplay as one. I’m a grown man! I’ve been married for 20 years! We did a house renovation project last year. It was hell and cost a small fortune. I have two teenagers at home. Even my kids aren’t kids anymore! If I’m not grown-up, then who the hell is?

And it’s not just me. Take a look in the mirror! Do you see a carefree child, or a person juggling a tangled mess of incompatible responsibilities and making trade-offs all day long, every day? Of course you do. Everyone does.

And still we perform that stupid little scene. At least in my part of the world we do. I’m sure I know developers who played out that scene just last week. Isn’t that strange? I think it’s strange. Why do we do it?

When we behave in strange ways, it’s often because we’re getting in touch with something uncomfortable. And so we look for a way out, a way to diffuse the nervous energy and get back to normal. We use jokes for that. But we shouldn’t. We shouldn’t fall for that temptation. Discomfort is actually useful and interesting. It can be a clue, a symptom of something. If we look a little closer at that discomfort, maybe we can learn something, and maybe we can fix the problem at the source.

Obviously, it has something to do with brushing up against some kind of boundary. We find ourselves at the threshold of something, and the most obvious candidate is the good old business/IT divide. That awkward point where what we do as software developers meets the reason why the business exists. And when it feels too business-y, we retreat, and call for the real business people to take over.

When we say “we’re gonna need a grown-up for that”, what does it really mean? It’s code for something, right? What could it be? What are we really saying? Here are a few candidates:

If I’m right, and these are the kinds of things we’re trying to say, why don’t we say them outright? It seems like a shame, because they all sound like really interesting topics to me. We could have meaningful conversations about our environment, our boundaries, the constraints we operate under, our dependencies on others, our degree of ownership over the problem we’re solving, etc etc. And not just as generic, abstract topics from the realm of philosophy either, but concretely: we could build our understanding of what these big words actually mean to us, in our context. But if we just laugh it off as something awkward, we won’t be having those conversations. And so those things are going to remain unexamined and unclear.

You might say, ok, but why does it matter? What’s the harm? It’s just a joke, right? I think it matters, and that it does real harm. First of all, the child/adult trope sediments a very real divide between “the business people” that make decisions on one side, and “the developers” that carry out instructions, essentially still just building to order, on the other. This is the divide that we’ve been fighting for at least 20 years of agile software development. I would argue that it’s a really bad idea to reinforce that divide, even in the form of a joke.

And second, it’s much easier to challenge the things we say outright. We don’t have the autonomy to make that decision? Ok, let’s talk about that. First of all, is it true? Or are we just scared, or reluctant, to exercise the autonomy that we do have? And if it is true, what would need to change for us to have that autonomy? Is it possible to make those changes? Who would need to be involved? What would the consequences be? This conversation offers a path towards potentially increased autonomy, or at least clarified autonomy.

And we do want autonomy, right? I’m sure that many of you are familiar with Daniel Pink’s book Drive, about what motivates us as knowledge workers. He says there are three things: Autonomy, mastery and purpose. And autonomy is the first word in that list.

Well, what kind of autonomy is that going to be? What are we aiming for here?

Consider the difference between the autonomy of children and the autonomy of adults. If you take a bunch of children and put them in a playground, they have considerable autonomy within that playground. They can run around freely, without a care in the world. They can do what they want and play with whatever toys are available. But they can’t venture outside. They need a grown-up for that.

Adults have a very different kind of autonomy. They can do many more things than children can, but that type of autonomy comes with a bunch of strings attached, like responsibility and accountability. Right? When we make a choice, we’re willing to own the consequences in a way, or at least be able to explain to ourselves and others why we made that choice. In a sense, that’s what it means to be an adult.

Similarly, I think we can distinguish between autonomy inside and outside the developer bubble. That’s our playground. I once tried to tell a joke, that the ultimate autonomy for a developer is “THEY LET US USE HASKELL”. I thought that was pretty funny.

The thing is, no-one really cares what programming language you use. Not really. They might have some concerns about being able to replace you if and when you leave, but ultimately it doesn’t matter. It’s not important. They’ll manage. They’ll find someone. Similarly, no-one really cares if you have one or two or three monitors on your desk, or what kind of mechanical keyboard you prefer, if it’s an expensive model. They can afford them all. It’s peanuts. It’s insignificant. It’s just toys to them. Choose whichever you like.

Now consider this: if no-one really cares what you decide, does it even make sense to think of it as autonomy?

If we want real, significant autonomy, it’s going to have to be about entirely different things! Almost by definition, it’s going to be things that are painful to yield control over, because they actually matter to the so-called business people. It’s going to require real trust, and a conviction that your team is in fact best equipped to make that decision. It must be because they realize that you actually understand the business problem the best, and that you are best situated to own the consequences of that decision. That’s what it means to own a business problem, or to focus on business outcome over output. You can’t do that if your idea of autonomy is to use Vim.

Ironically, real autonomy tends to involve exactly the things that make us snicker nervously and say “we’re going to need an adult for that”. The thing to realize is that, yes, obviously we’re going to need an adult for that. Probably several. But the good news is: here we are! The adults we need are right here! We’re standing in a circle, trying to summon agility!

Of course I realize that it’s not just up to the team itself. We’ll have to fight for that kind of autonomy, and there will always be limits. Not even adults have unbounded autonomy. But we can explore those boundaries, and see where they yield to pressure. There’s no reason to fail on the safe side.

I would like to see development teams with much higher ambitions with respect to autonomy. The aim should be to become tiny organizations in their own right: self-organizing, self-governing and self-modifying. They have a mission and a budget, and they are free to carry out that mission in the way they see fit, within that budget. They can even challenge the mission itself, because they understand why the mission is important, and how it fits into the larger scheme of things. They can pivot if they find a more useful mission to pursue within that scheme. Or they can choose to disband. Dissolve the team itself, if it turns out that mission is ill-advised or infeasible or outdated. Just pass whatever money you have left back and say “it would be better for the business to invest this in something else”. That would be the grown-up thing to do.

But of course, we must really want that kind of autonomy. The kind that comes with responsibility, accountability and real business impact. We must prefer to be adults. We can’t settle for a playground.