

Ask HN: How do I get better at delegating? - tostitos1979

I&#x27;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&#x27;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&#x2F;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&#x27;ve got now or can I make the change to management?
======
gregcohn
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.

------
logn
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.

------
gus_massa
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](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.)

------
blooberr
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.

------
sarojt
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?

------
kissmd
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.

