
How do you delegate to a group of people? - Isofarro
https://www.annashipman.co.uk/jfdi/delegating-to-a-team.html
======
gregmac
Kanban does sound appropriate, but it seems like the biggest thing still
missing is prioritization.

One team = one ordered list of priorities. Someone has to make the call.

It doesn't mean there aren't multiple things happening at the same time, but
it does mean there's always one ranked above the other. This is the biggest
thing I've struggled with when introducing kanban concepts to non-tech people:
they will try to have several #1 priority items - sometimes by having several
priority lists or categories that are all "equally important".

Prioritization doesn't have to be perfect, so long as it's continually refined
and the priority of items in-progress (almost) never changes. It had to be
recognized that stopping work adds several hours to the time it will
ultimately take, and doing it more than extremely rarely is a great way to
completely destroy your team's morale. Even if it's a "only a five minute
task", you have to act like it's a 3 hour drive away (and back again).

~~~
TravHatesMe
I agree. In order to optimize efficiency, changing priorities (ie.
interrupting work) should be avoided unless absolutely necessary.

A five minute task equates to: context switching, creating a branch in JIRA,
checking out the branch, complete this small task with a few lines of code,
debug and run tests, create the PR.. It is awfully distracting and I often
lose focus on what I was previously working on. Great, I think I'll take a
little break or go for lunch a bit early.

~~~
levosmetalo
Then it’s your process that makes all this overhead. Why not just commit those
two lines of code to the main branch and continue?

~~~
TravHatesMe
Because the process pays off.

If you have a mature code base, all changes should be reviewed by at least one
member of the team. Being consistent with your branching process is important.
I favor squash-merging pull requests to keep a clean history of the target
branch, it makes it easy to track down bugs.

In my mind, this development process, as tedious as it may be, is worthwhile.
In my mind it is the proper way of managing a codebase, I consider it part of
the job.

------
tacon
This article reminded me of the book "A Factory of One", about applying Lean
principles to personal productivity.

[https://www.amazon.com/Factory-One-Daniel-Markovitz-
dp-14398...](https://www.amazon.com/Factory-One-Daniel-Markovitz-
dp-1439859930/dp/1439859930/)

Or applying Lean to office productivity:

[http://www.markovitzconsulting.com/blog/blog/tps-the-
thinkin...](http://www.markovitzconsulting.com/blog/blog/tps-the-thinking-
production-system)

------
huffmsa
> _how do you delegate to a group of people?_

Historically, you'd get a crusty, alcoholic, twice divorced guy and make it
his problem to figure out. These individuals are usually given the title of
sergeant.

------
hammock
>How do you delegate to a group of people?

How do you deal with multiple managers?

That's the converse. If you are asking either question, it may be a sign of an
organizational problem.

------
thaumaturgy
You don't, not if you want something to get done.

> _I felt that there must be a better way to do this so that the principals
> know the problems we have that I need help with (and also know about the
> problems I don’t know about), without me doling them out._

This is not management. Management involves delegation and monitoring and
control of resources. It's not, "hey gang, here's a workboard of the stuff
that needs to be done, you know what to do."

> _Quite often, someone will email or mention at stand-up a problem that they
> have picked up and solved before I’ve even heard that it exists._

This is problematic because that means nobody on the team (including the
manager) has a holistic view of what's going on in the project. That's
supposed to be one of the manager's responsibilities.

There's some stuff in this post that might be beneficial for managing a team
more efficiently, but it shouldn't be described in the context of "this is how
a manager abdicates their responsibility".

This is pretty well understood in ICS
([https://en.wikipedia.org/wiki/Incident_Command_System](https://en.wikipedia.org/wiki/Incident_Command_System)).
There is one incident commander; one section chief for each section (who may
have one or a couple of assistants); one branch manager, and so on, all the
way down. An incident commander may have a briefing with multiple branch
directors, but typically that'll just be for purposes of sharing common
information. Actual instructions go out to each branch director individually.
Each branch director in turn passes instructions and additional information
further down the chain. Eventually the information gets to a team, but even
then there's a designated team leader and if someone is in charge of multiple
teams, they gather the team leaders together and address them first as a group
and then give them instructions individually.

ICS is designed to scale up or down depending on the scope of an incident, so
these layers aren't present for all incidents. In small incidents you may have
an incident commander speaking directly to one or more team leaders.

It works really well in practice and this is the system that multiple
organizations use to find their ass when everything's going pear-shaped all at
once. Startups and businesses could learn a lot from it.

One of the essential parts of the system is that every person has a clearly
defined role. Another is that there's a one-on-one relationship between each
level, so that nobody's left trying to understand more of the situation than
is necessary or trying to figure out what their task is.

ICS is used all over the world to get stuff done in urgent situations that
would just blow the tops off the heads of most mid-level business managers.
It's a good system to learn.

------
thrower123
I really try not to, if it is at all important that it actually gets done, and
done correctly.

People who are reliable and competent exist, but they are seemingly very rare.

------
NicoJuicy
My manager now tries to micromanage.

Which basically means: I manage bad, everyone at the team thinks I hate them
and I promote someone with no Dev experience ( the tester) as teamlead to
shift the blame to them.

When I tried to tell him this is ridiculous situation ( the Teamlead is 100%
dependant on him for everything and brings no solutions to the table). He just
straight off told me that he didn't care ( 12th June, so it's 2 weeks now - it
was a 1 on 1 meeting, so I only have my word, urgh)

The author has a lot more empathy than other managers (y)

