Ask HN: How do I get better at delegating? | Hacker News Reader

Ask HN: How do I get better at delegating?

7 pointstostitos19796 comments

I'm pretty good at writing software (in my mid-30s). Since I was a kid, I wanted to go into a leadership role. Even though I'm in my mid 30s, I am considered an exceptional individual contributor. No management experience except interns. On my most recent project, I explicitly tried to delegate tasks to other devs (not as proficient as myself). I kept helping to the point where I did most of the design/code myself. I recognize that this is holding me back. Any other mid-career techies having the same issues? Should I just give up my dream of being a leader and settle for what I've got now or can I make the change to management?

View on HN

This answer is generic to managing delegates, not specific to tech, but the number 1 thing is to re-orient your own thinking around the goal of building a sustainable system, not on perfect outcome of the next project. You have to be able to take a few hits if you can learn from it as a team, iterate, improve, and adopt the mindset that moving a little more slowly now will help you build muscles to move more efficiently later. It's easy to not "get" this, or to set it aside in times of stress, but it's important to keep that focus as much of the time as you can, because it helps you apply your own energy to the parts of the process that need fixing, rather than patching code as it were.

The number two thing to realize is that lots of people delegate without measuring the follow-up. If you figure out the measurement strategy first, then work backwards to how you communicate the assignments and goals, that might help. ("We're going to meet every monday and review what you coded last week" is totally different from "Our goal this quarter is to X and your piece of it is to move the needle on Y."

Third is you have to be consistent and vigilant about the follow-through on the preceeding point. If you say you're going to meet every week, put a standing meeting on the calendar and make it happen, every week, without fail, so that it becomes routine and expected and a part of the rhythm of the office. (Don't announce a new goals plan, or new tasks, or whatever, then forget all about it, then announce a new way of doing things, etc. )

Even if it's not perfect, the process and repetition are very effective tacit communications that a) you're paying attention in good ways and bad (delegates will get visibility both for their progress and their lack thereof), and b) everyone has a miss now and again, and you get to be patient and tolerant of that (if you want) at the beginning, but it's hard to skate week after week if people don't eventually get sh*t done.

Implicit in the above is some means to track all of this that you can rely on.

I went through what you're experiencing. Stick with it! It's a normal experience for new managers transitioning from sole-contributor.

Never do the work of your team. You have to let them succeed and/or fail on their own. You should set them up to succeed, but don't do their work. Draw clear boundaries, such as you might set requirements or dictate certain architectural details, but be sure that you don't get involved in any implementation-time decisions. This helps guarantee that you won't ultimately be involved in future fixes and re-work. If your team fails, it's not your fault! It's only your fault if you take no corrective managerial action (such as hiring, firing, or changing the way you plan/manage things).

Also stay on top of work as it progresses. Ask people how they're doing. Ask for demos and explanations.

Set good deadlines. Communicate your realistic (conservative) expectations to your managers, but set ambitious deadlines for your workers. Create actionable plans everyone on the team is accountable to.

Identify leaders. If you're the manager, find someone under you to be a lead developer. If your team ends up asking you technical implementation questions, redirect them to your lead dev.

Hold regular hours. Don't be available 24/7 for every problem that arises. Make your team self-sufficient and productive without you constantly around.

Be very careful hiring. Unproductive devs bring the whole team down by constantly failing and creating extra work for others. Fire people who make the team worse.

This idea may help, but I didn’t try it so I don’t know if this works.

Painless Functional Specifications - Part 1: Why Bother?: http://www.joelonsoftware.com/articles/fog0000000036.html

You still do most of the high level design, but delegate most of the coding.

(One of the problems is if you are much better writing code than writing English.)

Why do you need to keep helping? What's holding them back from learning without you being around all the time?

Have you tried handing your direct reports a few tasks and checking back after a week?

With a new inexperienced hire, I start off by black boxing everything and just telling them input / output. Write the innards. Once they have a few wins under their belt, I ramp up the scope of the projects and that works pretty well. I only step in if it's some strange problem none of us have ever seen before and we're up against a tight deadline.

Don't give up on your dreams they are precious.Why don't you join a kickass start up and focus on creating stuff & managing very small teams - may be 1 or 2 developers?

this is really easy: define goal, context and measurement. assign to dev. discuss with dev if needed. check and collect on ready.

if he is a good developer this is enough for him.

And for you? you are delegating, you have nothing to do about that fking task. except answering questions and collecting results.

Forget it. And if it comes back to your mind forget it again. Until the dev comes to you with a question or with a result.

Reply on news.ycombinator.com