How do you delegate to a group of people?(annashipman.co.uk) |
How do you delegate to a group of people?(annashipman.co.uk) |
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).
I'm currently struggling with exactly that. We're the ops-team, so the infrastructure itself as well as the upstream applications are capable of producing its own backlog of maintenance work very well (hello SACK). And then you have all kinds of technical tasks to optimize and maintain the infrastructure. On the other hand, Sales, dev and other teams are also throwing project work at us we have to deliver, sometimes on a communicated deadline, sometimes without.
It's a rough balancing act. By now I've split that into two queues, our internal and our external queue. Multiple stake holders can fight about priorities in their external queue, the internal queue is team-internal and backed by our head of IT as a stake holder. From there, we're trying to consume both queues in a fair fashion. It kind of works, but perfect it ain't.
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.
https://www.amazon.com/Factory-One-Daniel-Markovitz-dp-14398...
Or applying Lean to office productivity:
http://www.markovitzconsulting.com/blog/blog/tps-the-thinkin...
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.
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.
> 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). 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.
People who are reliable and competent exist, but they are seemingly very rare.
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)
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.