Programmers have traditionally been contemptuous of management: if you're not writing code what are you even doing with your time? I picked this up through general culture, and I remember my instinctive shudder and recoil the first time my boss asked if I was interested in management. As I got a better understanding of what managers were doing, though, I came to appreciate how good ones could let us be much more productive:

• They gave us context on how the business worked, the role our team played, what we were trying to do, and how our work fit into a larger whole.

• They helped us figure out what to work on, breaking large projects that were too big for any of us into approachable chunks.

• They gave prompt feedback, helping us build mental models of what good work was in this context, which let us work progressively more independently.

• While they had technical backgrounds, they also understood that their skills were somewhat out of date and they weren't as close to the problem as any of us. They understood how to ask the right questions, have us review each other's work, and keep us going in a good direction without needing to fully understand what we were doing.

• They knew what they wanted, gave clear descriptions of what needed doing, provided us with useful training and relevant documents, and gave us examples to draw on.

• They handled stakeholder management and prioritization, defending our time and attention so we could focus on the technical work.

Good managers do many other things, of course, but even just when you consider whether they're making the team more productive in the moment there's really a lot there.

Now that I've made the transition from individual contributor to management twice, I see this from the other side. I work hard to support my reports by giving them what they need, maintaining a sense of what each one is capable of, determining an appropriate level of review, noticing when folks are struggling, among other things.

It's somewhat ironic that I've ended up in a role that I once disdained, but the bigger irony is that with LLMs we're all growing into that role now. Everything I listed above is not just something a good manager does, it's also key to getting the best results out of an LLM. What we traditionally considered the real work, writing the code, turns out to be much more easily automated than figuring out what problem we should be solving or whether a proposed solution is a good one.

I'd say management is the future, but I don't know how much longer any of us will be able to continue usefully contributing. Instead I'll just say that management is the near future. I think it's likely that the next few years will look like managing increasingly skilled and numerous reports, where we'll need to maintain a solid sense of what we're looking for, continuously update our sense of how much trust to extend these virtual reports in what contexts, and generally work to keep all this automated effort moving things in a good direction.

(Trying to think of reasons this post might end up being quite wrong, I think the one that feels most likely to me is that these management and agency skills end up being yet another thing that LLMs can do very well very soon. In which case perhaps the last areas where humans are economically useful are below the API, in roles similar to a driver following GPS instructions, applying our skills in interaction with the physical world at the close direction of AIs.)