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. [...]
I'll take the opposite failure mode: in an absolute sense (as opposed to relative-to-other-humans), all humans have always been thoroughly incompetent at management; it's impressive that any organization with dedicated managers manages to remain functional at all given how bad they are (again, in an absolute sense). LLMs are even more bottlenecked on management than human organizations are, and therefore LLMs will be less useful than human organizations in practice for most use cases. People will instead mostly continue to rely on human employees, because human employees need less management.
2- LLMs are even more bottlenecked on management than human organizations are, and therefore LLMs will be less useful than human organizations in practice for most use cases.
- People will instead mostly continue to rely on human employees, because human employees need less management.
These seem like great predictions worth checking. Can you make them more specific (time, likelihood)?
Likelihood: maybe 5-30% off the top of my head, obviously depends a lot on operationalization.
Time: however long transformer-based LLMs (trained on prediction + a little RLHF, and minor variations thereon) remain the primary paradigm.
I don't think this captures quite why programmers are disdainful of managers, nor what it would be like to manage AIs.
First, I think most programmers are disdainful of managers because their main experience with managers is that managers are bad. As in, there is such a thing as a good manager, but there is also a very small percentage of them versus a deluge of managers that range from blandly ineffectual to aggressively incompetent to outright maliciously exploitative. Part of this, I suspect, is because it's a lot harder to get hard feedback that reliably points to a manager being bad and ought to get fired, and managers have plenty of chances to shift the blame around. The one substantial piece of evidence is when the manager's subordinates say they're bad, but even if they do, it is often assumed that's just the usual grumbling of drones.
Second, managers exist at the interface of corporate interests and the needs of the workers. Whenever someone up top needs the workers to eat some shit, it's the manager who plays "here comes the airplane!" with the spoon. This makes them understandably unpopular, because if there's something worse than being treated badly, it's being treated badly and told that it's actually quite good.
Third, managers are often outright superfluous. Managers supply a need for coordination, but they're not the only possible coordination mechanism. It's entirely possible for small enough projects to simply self coordinate, and it's entirely possible for bigger ones to make do with a higher worker to manager ratio in which the latter only absolves the needed functions and no cruft is added.
Which leads us to the biggest difference between managing humans and managing AIs: politics. All the superfluous stuff, the waste, the inefficiency, the reasons not to fire managers entirely deserving of being fired, are office and corporate politics, the result of schmoozing, of personal biases and preferences, of prejudices, who's whose friend or in extreme cases who fucks who. A lot of that goes out of the window with AIs. The manager of AIs is a lot more like a programmer in the corporate ladder: the buck stops with them. The AIs have no opinions that matter. They're just tools assumed of a certain quality; if they're found wanting, we simply subscribe to a competing service and move on.
Yeah, my experience suggests the same. I also had a few good managers... which only made the incompetence of the rest of them more obvious.
Another difference between programmers and managers is that programmers are usually in a flat structure (for example a team with three to seven developers), while managers are in a hierarchy (managers of managers of managers). That means, if one programmer clearly sucks, there are colleagues who can say that openly, and if you assign tasks to them, you will see which ones complete their tasks quickly, and which ones virtually never. That is a feedback mechanism. On the other hand, even if you have a good manager, but his boss is a bad one, well, the job of the good one is to obey the bad one, so there is a limit to what he can do right. You only get a good outcome when the entire chain is good, or when the lower managers are very good at shielding you from what happens above them (which is not always possible).
Who decides what ratio of managers to developers is ideal for a software development company? That's right, the managers! So you get companies that seem to have more managers than developers, the developers are overworked, but there is not enough money in the budget left to hire more developers. Meanwhile, the managers organize more and more meetings, to create work for themselves. (There are dozens of people in a meeting, even if most of them only say a sentence or two. No one writes meeting minutes. Many meetings repeat periodically and a large part of them consists of repeating what was told the last time.)
the result of schmoozing, of personal biases and preferences, of prejudices, who's whose friend or in extreme cases who fucks who.
Yes to all of these points. It is so weird when your boss gets a new boss who talks about his hobby... and suddenly you boss has the same hobby, too. What a coincidence! Or when your IT company is 100% male, and no one seems gay, so you think "okay, this company is an exception, I see no way how sex could play a role here", and then you find out that this guys fucks that guy's sister, etc., and the entire management is practically one big happy family.
One more thing to add:
Developers are often blamed for optimizing for their career over what's best for the company. For example, the developers sometimes insist that the new project try this new shiny technology, regardless of whether that is necessary or not, just because "worked with new technology X" will look great on their CV. Yes, that happens. And guess what... managers play the same game! Sometimes good projects get decommissioned and replaced by new ones not because there was anything wrong with the old project, but because "created a new project" sounds better on the manager's CV than "maintained a project created by my predecessor".
Since we're speculating about programmer culture I'll bring up the jargon file which describes some hacklish jargon from the early days of computer hobbyists. I think it's safe to say these kinds of people do not in general like beauty and elegance of computer systems sacrificed for "business interests", whether or not that includes a political counter cultural attitude.
It could be a lot of programmer disdain for "suits" is traced back to those days, but I'm honestly not sure how niche that culture has become in eternal september. For more context see "Hackers: Heroes of the Computer Revolution" or anything else written by Steven Levy.
but I'm honestly not sure how niche that culture has become in eternal september.
Long gone, I am afraid.
It seems to me that greatest difference is that a few decades ago, the only people who studied computers were math nerds. Then at some moment, computers became a reliable way to make a great salary, and everyone started paying attention... but of course it takes a few years to learn programming (and more years until the school systems wake up and start teaching it), so the first generation of well paid programmers were the nerds who originally learned it for Platonic reasons.
The next generation of programmers, however, consists mostly of people who are there only for the money. Many of them do not even like programming, it's just that they need to do something to pay their bills. And yeah, the nerds are there too, but now they are a minority, and their preferences are considered irrelevant.
1I mean, obviously there's some of that, but even if you have a high tolerance for necessary ugliness, bad management in tech has so much more to it. Honestly just the whole Agile/Scrum thing and the absolute nonsense it has devolved into would be enough to make most sane human beings hate the guts of anyone who keeps imposing it on them (all the more if that other person then contributes no measurable good to the rest of their day).
1
1
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.)
Comment via: facebook, mastodon, bluesky