This is a work in progress - summarizing important principles for middle management, based on my current work attempting to create usefulness for the team and the departmental management. (It's called "team leader" because this characterizes a middle manager level where half of the maximum benefit can come from organizational improvement and enablement. The other half being people/leadership, which these maxims don't address.)
Insulate
Protect active specialists from distraction or confusion arising from politics, non-matching work requests, or inappropriate sucking into strategic level debates which they can't affect (and so would just be a source of stress)
A subset of this is "firewall the insanity", where other departments or management are a source of antipatterns, delusion, or faff
Translate
The other side of the firewall job: let stuff through. But add value by adding detail, context, clarity, planning, scope etc so people can act on it easier.
This also works upwards, by wrapping team member requests, whinging, etc into management speak, business cases etc
War on faff
Faff is a word popularized by my colleague @AFloodAppeared which nicely sums up all sorts of different inefficient / misdirected / over-reworked / under-specified / disproportionate work via the easily identified heuristic sense of "faffing around". Thus this is an excellent agile principle, i.e. maximizing the work not done.
The team leader should take advantage of (in theory) being less connected with the detail of the work and having a more supervisory standpoint... to keep watch for the signs of faff.
Identify and eliminate faff with extreme prejudice
Make quick plans including when hijacked
Accept unplanned work but not work done without a plan.
Control contention
It is completely fine and ordinary (in real life, not in productivity erewhon) to work on multiple things in parallel.
The team leader needs to set limits on the share of resources given to different streams of work. Measure and monitor. (A useful case of measuring and monitoring, unlike many other forms of measurebation.)
Set prioritization principles
Know your main types of work, know how your current streams of work are categorized into those types, and set general principles for prioritization. Prioritization means three possible things for each type of work:
- The work has a protected minimum amount of resources
- The work has a capped maximum amount of resources (to stop it encroaching on other work)
- The work, if pushed (because reasons), has a predefined rule about what it overwrites. In other words, it might expand to 50% of your resources, putting X and Y on hold, but Z is still protected.
If you treat incoming unplanned work as mostly a kind of service desk of your work production zone, then you pre-allocate it a standard share of resources, plus burst capacity. In this way, unplanned work is predictable in general even if you can't plan for what it consists of exactly... and you pre-protect planned work from constantly being moved around by incoming unplanned work.
Where your work includes testing and bug fixing this is pretty much predictable and so should be included within the main work type, rather than being taken as unplanned every single time.
Build comms into the working week
Communications are a predictable type of work that take up significant real time. So block off time properly rather than treating it like unplanned work.
This applies on an individual basis and a team basis. It's particularly important for the team leader because pure communication, sorting, monitoring, notifications, scheduling kind of work is explicitly a main function for your work.
Protect time for initiatives
Developers understand the importance of technical debt and working on underlying systems, even if this doesn't deliver directly visible change to their product immediately. Ordinary business teams should also think like this, and hatch initiatives to improve people, processes, policies, tools, communications, structures, working culture, interoperability, resilience, and so on.
Blocking off time for initiatives is a classic case of ensuring that you work on important things as well as urgent things.
Increase resumability
It is entirely realistic, predictable, and normal that planned work will be interrupted or even intentionally overridden or shelved. Therefore it's valuable to work in a way that helps you resume quickly and accurately where you left off, when you return to the work later.
This applies at the general project/initiative level and at the detailed/individual task level.
Treat everything as an iteration
Basic agile principle. Work on anything, single item or combined work product, with the intention to get to version three as quickly as possible. (Credit: Eben Pagan.) This allows you to think in version scopes from the beginning, and think about (i) your intended release process, (ii) how to collect feedback and react to it, and (iii) likely resource considerations you are committing everybody to by beginning work on the idea in the first place.
Another part of this is to de-scope good ideas back to v0.5 so that you can quickly release something (a) to get feedback, and (b) to increase the chances of getting anything done at all, by exploiting the initial inspiration/motivation/momentum/context of the original idea, and because the original idea is invariably several steps too far ahead.
Plan to revise the plan
Have a planning horizon, but more frequently than that (e.g. monthly) revise the entire plan of plans. This is predictable work you can block off.