Hi.

This blog contains whatever random tech stuff I'm thinking about recently. And a lot of conference reports.

Delegation means sometimes not answering questions you know the answer to

Image: www.publicdomainpictures.net. CC0 Public Domain.

Image: www.publicdomainpictures.net. CC0 Public Domain.

I had coffee with a friend recently who told me about a work annoyance: he's leading a project but his manager keeps intercepting questions about it. This situation is familiar. I've been there a couple of times and it's made my job more difficult. But I suspect I've also been the person on the other side, "helpfully" replying to mails without thinking about the consequences.

When you're the one intercepting the emails, you might not realise you're doing it.

Here's a scenario: imagine you're a senior engineer or manager in an organisation. You're responsible for a lot of projects in your group, and you've delegated each project to a lead. They're responsible for getting the things done.

Your director buddy, Ali, in another group mails you. "Hey, I see that the Ukulele team has implemented a Frobnicator library in Java. Could someone come to our team meeting and talk about how Ukulele Frobnication works? And are you planning a Go implementation?"

You just had a long conversation with Simone, the Ukulele lead, and you both reckon she should put a Go library on the roadmap for next quarter. She's already got a proposal for the API. And sure, you're free during your friend's team meeting and it'll be good to hear what they're up to.

It's tempting to just hit reply.

From: you
To: Ali

Yes, the Go library's planned for Q2. I'll be in the office on Wednesday so how about I call in to talk to you folks then? 

Seems innocent. But you just really undermined your colleague:

  1. You might be misrepresenting her team's plans. Maybe Simone has realised since yesterday that there's a higher priority and that the Go library needs to be pushed back a quarter.  When she publishes the roadmap, it's going to contradict what you said, and other teams might take your word over hers -- you're more senior, after all. By muddying expectations, you've made her job more difficult and you're making her team look less reliable too.

  2. You're hiding information from her. Since she doesn't find out that this other team wants a Go library, she can't ask them how much they care about it and why. Understanding their use case might change the API design.

  3. By positioning yourself as the face of the team, you're taking away a learning opportunity. Presenting your team's work gets easier the more you do it, and it's a necessary skill for advancing as an engineer. Even if Simone's completely comfortable talking to a group, she might have someone on her team who needs to learn the skill. In my last team, we loved to send our newest, most junior engineers on these expeditions (with a lot of support!)

  4. You're taking away the lead's visibility. Getting big projects done is much easier if you have a useful network. By overshadowing the lead, you've hidden her work from another senior person, and you've stopped her meeting someone she might need a relationship with later on.

  5. You're keeping yourself in the communication path for next time. If director-buddy or someone they talk to has another question about the Ukulele Project, they're going to come ask you again. That doesn't scale. The more you can hand off a project, the more projects you can keep track of.

So what do you do instead?

At a bare minimum: CC the lead on your response. At least she's got the opportunity to add any questions or correct any misunderstandings, and Ali now knows she exists and is important to the project.

From: you
To: Ali
Cc: Simone

Yes, the Go library's planned for Q2. I'll be in the office on Wednesday so how about I call in to talk to you folks then? 

Better: add Simone to the thread and ask her to answer the question. Yes, even if she'll just say what you would have said, or come talk to you to agree on the response. Even if she'll say it less well. It's really hard to watch someone do something less well than you would have done it, but it's the only way to give your people space to grow. (And sometimes they'll surprise you by doing it better than you would have, and that's the best feeling.) The reply needs to come from her.

From: you
To: Ali
Cc: Simone

Simone, is the Go library still planned for Q2? I can go talk to Ali's team on Wednesday,  but let me know if you'd prefer to do it.

Best of all: add Simone to the thread and take the opportunity to redirect future questions to her and give her your explicit support.

From: you
To: Ali
Cc: Simone


Simone is lead for the Ukulele project and owns the direction for it, so she's the best person to answer any questions you have about it. 

See how much delegated authority comes with that? It's going to be so much easier when Simone needs to get something done. The vocal endorsement of an authority figure makes most of us do better work. Your lead will get a little shimmy of "I feel capable, trusted and supported" and it cost you nothing to do it.

What do you intercept? There's no need to forward on basic user questions like "Do you have a pointer to the user documentation?" or "What was the name of that framework?". You probably don't want to answer those repeatedly either, so having a users list or drop-in slack or irc channel is a great way of making sure the team doesn't keep answering the same questions.

But when it comes to strategy or direction, how the team operates, or anything requiring a decision? Pass it through. Let your leads lead.

 

Hacking humans

Graphing chips with gnuplot