In my experience, programmers that are isolated from the rest of the organisation are almost always not very good programmers. There’s nothing wrong with the code they write – they’re just stuck solving the wrong problems, making incorrect tradeoffs, and generally unaware about what drives the business. You can write brilliant code, but if you don’t know what the big problems to solve are, it doesn’t matter how good your code is.

I want to hire clever people and trust them to do the right thing. For that, they need to learn on their own how to make that judgment in whatever line of business they are in.

At this point, some people think that it’s the manager’s job to make sure programmers understand what’s important. Yes, at a high level. No, not when it comes to details. During the course of implementing a design, a programmer makes all sorts of tiny decisions on the fly – these require understanding and context. For the manager to produce on-demand context for all of these tiny decisions, they must be micromanaging. That does not scale.

So here’s my suggestion to new programmers: care about the entire organisation, not just the little corner you’re sitting in. That’s a very easy way to add more value and become a better programmer.

Sometimes non-coding work is simply rote work required by the bureaucracy: filing expense reports, sending variable compensation information e.g. for on-call, registering customer consulting hours in some time tracking tool, requesting additional hardware, whatever. It’s tempting to stick this work with the manager, to shield programmers for it and let them focus on higher value-added work.

The drawback of having the manager do all this is that it sucks up a lot of time. If the manager can distribute this work through the team, the manager gets more time over to do technical work.

I think it’s very important that managers stay technically active and don’t fall into the trap of trying to absorb all bureaucracy and forget how to perform the craft they used to do. A manager should ideally be able to step in and substitute for any of the people under them, and that takes active involvement in the day-to-day work.

I want managers to be primarily technical, not primarily administrators or bureaucrats. If the bureaucracy is too much even when distributed over the entire team, then that’s a separate problem of too much bureaucracy.

Here’s my suggestion to managers: eliminate as much bureaucracy as possible. Then distribute what remains over the team (yourself included), e.g. by rotating responsibilities monthly. Use the time you’ve freed up to stay technically active.

There’s another argument in a similar vein as the one before: if the team is shielded from the non-coding work, then nobody in the team is able to step in and substitute for the manager!

I would strongly prefer to have someone from the team being managed stepping in and substituting for the manager than an even higher-level manager. The reason is simple: the team knows more about their day-to-day work than an even further removed manager would.

Besides, it’s not like the manager will stick around for ever either – at some point they will move on and need to be replaced, and at that point it’s very useful to have already trained potential replacements within the team. Shielding the team from non-coding work ensures that they are incapable of serving as a replacement for the manager.

The suggestion from the previous point applies just as well here, except in reverse: if you remove as much bureaucracy as you can and then distribute the remains over the team, you will have a team capable of covering for you when needed.

This is not just reducing bus factors, it’s also about building a more competent, well-rounded team that can make meaningful local decisions autonomously. If the manager can do what the team does and the team can do what the manager does, there’s more freedom in how to structure work, and how to proceed with less communication overhead.

Religiously adhering to chains of command is inefficient and hampers innovation. Yet avoiding it takes some sacrifice from programmers: we have to suffer a little non-coding work.