Relative Sanity

thoughts on being and doing all articles

There’s a story I love to tell when I’m talking about enabling autonomy in teams. It was the first time I remember consciously letting the team plot their own course without either abdicating my role as the lead, or trying to “Jedi mind trick” them into thinking they had plotted their own course.

It was pretty early on in my management career, possibly the first major project I had been involved in from the start. It was time for the team to sit down, look at the problem, and start to formulate a solution. I was terrified, and had spent the previous week doing nothing other than running through the context, the current implementation, various bits of tech debt and bugs: effectively running a dress rehearsal on the whole planning session ahead of time, myself.

Why was I terrified? Despite having been at the company for five years before moving to management, this particular team worked in a domain that I had very little knowledge about. How was I supposed to lead them unless I knew as much as they did about everything? I didn’t want to let them down by being clueless.

I knew exactly how this project needed to go, exactly how it needed to be broken down. I even had a good idea who should work on what, based on skills, experience, upcoming holidays, even what kind of growth the team members had on their career maps.

All I needed to do was present it to the team. I was prepped, they would feel properly looked after, it would be great.

But as I walked into the meeting room to get the projector set up ahead of the start, something buzzed in the back of my brain: something my predecessor had said. Our job isn’t to stop them driving off the cliff, rather it’s to be there to roll up the sleeves, help them pick up the pieces, and figure out what went wrong. There was a nagging feeling that despite all my prep, this was going to be a disaster.

Still, I had my documents all ready to present. Work breakdowns, maps of the code, Gantt charts, the full thing. I couldn’t just abandon that, could I?

People started to file in. We had one remote engineer to dial in, made sure they were able to see everything (we had a dedicated in-room buddy for every remote team member, so they were on an iPad that their buddy could move around to better see what was going on), and so we began.

I pulled up the brief document which outlined the problem we were trying to solve, the constraints, how we were going to measure success, who the stakeholders were. All the starting points for the planning I had done.

I read through it, let them ask some questions, and was all ready to skip to the next tab: the one I had lovingly called “The Plan”.

And I paused. This was where the disaster would start. My gut told me to ask a question.

“So,” I turned to the room rather than talking to the projector. “Where should we start?”.

There was a brief pause before our remote engineer spoke up. “Well, we obviously need to chat with our contacts management team: this is going to bump into a bunch of code they manage.”

I breathed a sigh of relief. This was exactly on my plan, and so this might work. They were going to reinvent the plan I had for them. I wouldn’t need to be a dictator, the Jedi Mind Trick had worked.

“Hang on”, another voice jumped in. “No we don’t. The problem we’re actually solving for has nothing to do with contacts. That’s just in the success metrics. I can see why it’s there: it’s the easiest thing for us to measure. But it’s not actually needed to solve the actual business problem”.

I stopped. Wasn’t it? I skimmed the problem statement again. No, we could bypass the contacts altogether. I had completely missed that, as had our stakeholder. We had veered off course. I fought the panic for a moment.

“Okay,” I started, terrified that I’d fucked up but also genuinely curious. “Say we bypass touching contacts. How do we measure the impact?”.

More silence. Then “those are just a proxy for usage of this new feature. We could measure directly if we added in some telemetry here and here. Hang on, let me show you.”

The projector switched to another laptop screen and up came some code I had seen but not fully understood. “Look”.

The next ten minutes saw the team fully engage on this new idea. Code was pulled up, a quick diagram was sketched on our remote whiteboard, and suddenly we were starting to form a plan. I kept on asking insightful questions (only insightful because I was genuinely curious why things were different from my plan, but they didn’t know that), and the conversation flowed for a further hour.

Some of my plan (just over half of it) ended up being reinvented, but what we landed on in the end added up to about 60% the effort I had originally projected to myself, and informally budgeted for in terms of expectation management to stakeholders.

We had just manufactured four weeks of time. And all because I had the sense to keep my damn mouth shut.

See, what I realised later was that it wasn’t that I’d made a mistake doing the planning, but that it had been essential to help me be the best possible coach in the moment. Having an idea of how to solve the problem, but not sharing it, helped give me something concrete to compare to. I could ask helpful questions, not just dumb manager ones. But the shock of having a blind spot revealed to me so early helped me avoid poisoning the well by trying to steer them back to my plan.

I had context, useful knowledge, curiosity, and a genuine incentive to defer to their superior understanding of the existing implementations.

And by trusting that, the team now had a plan that they owned, that they felt genuinely invested in, that they understood and could adapt to changes, because it was their plan. Oh, and we had also managed to buy a month of refactoring at the end of the project.

It was at that point I resolved to avoid sharing my ideas till as late as possible in any conversation. I still fall into this trap too often, but it’s a powerful technique when managing a team that has been deep in the code for long enough, and is more in need of being guided in processes or business context.

In short, do your homework so you can ask good questions, rather than give good answers. Ask the questions. And then shut the fuck up.