Published on May 17, 2025 2:50 AM GMT
Programmers have traditionallybeen contemptuous of management:if you're not writing code what are you even doing with your time? Ipicked this up through general culture, and I remember my instinctiveshudder and recoil the first time my boss asked if I was interested inmanagement. As I got a better understanding of what managers weredoing, though, I came to appreciate how good ones could let us be muchmore productive:
They gave us context on how the business worked, the role ourteam played, what we were trying to do, and how our work fit into alarger whole.
They helped us figure out what to work on, breaking largeprojects that were too big for any of us into approachable chunks.
They gave prompt feedback, helping us build mentalmodels of what good work was in this context, which let us workprogressively more independently.
While they had technical backgrounds, they also understood thattheir skills were somewhat out of date and they weren't as close tothe problem as any of us. They understood how to ask the rightquestions, have us review each other's work, and keep us going in agood direction without needing to fully understand what we were doing.
They knew what they wanted, gave clear descriptions of whatneeded 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 technicalwork.
Good managers do many other things, of course, but even just whenyou consider whether they're making the team more productive in themoment there's really a lot there.
Now that I've made the transition from individual contributor tomanagement twice, I see this from the other side. I work hard tosupport my reports by giving them what they need, maintaining a senseof what each one is capable of, determining an appropriate level ofreview, noticing when folks are struggling, among other things.
It's somewhat ironic that I've ended up in a role that I oncedisdained, but the bigger irony is that with LLMs we're all growinginto that role now. Everything I listed above is not just something agood manager does, it's also key to getting the best results out of anLLM. What we traditionally considered the real work, writing thecode, turns out to be much more easily automated than figuring outwhat problem we should be solving or whether a proposed solution is agood one.
I'd say management is the future, but I don't know how much longer anyof us will be able to continue usefully contributing. Instead I'lljust say that management is the near future. I think it's likely thatthe next few years will look like managing increasingly skilled andnumerous reports, where we'll need to maintain a solid sense of whatwe're looking for, continuously update our sense of how much trust toextend these virtual reports in what contexts, and generally work tokeep 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 managementand agency skills end up being yet another thing that LLMs can do verywell very soon. In which case perhaps the last areas where humans areeconomically useful are below theAPI, in roles similar to a driver following GPS instructions,applying our skills in interaction with the physical world at theclose direction of AIs.)
Comment via: facebook, mastodon, bluesky
Discuss
