It depends on what kind of leadership we talk about.
Technical leadership: such leaders are often called architects. Of course they need deep technical knowledge.
Project leadership: such leaders are often called project managers or product owners. They only need shallow technical knowledge and can mostly lean on their experts in their team.
Human managers: they deal with personal growth and employment. They need enough technical knowledge to make employment decisions but need not be great programmers.
In large companies these are usually different persons. In a startup the CTO does it all, so of course he must be very technically competent.
I think that these are different persons leads may be one of the causes of a lot of the negative symptoms we're seeing in project management in our industry. If I compare the teams that I've been on, a lot of the frustration was due to the communication (or lack thereof) between the leadership roles that you've described. The best teams where were single people were responsible for all types of leadership - even if it was more than one person.
This. The dominant way software teams are managed seems incredibly bonkers and is not the norm in any other industry I know about. In the "real world", you have a boss, and probably he has a boss and so on. In the software world, everything is "negotiated" and "consensus-driven". Totally different people are responsible for hiring, firing, promotion vs. everyday decisionmaking. No programmer has a single boss, they have many, often implied and nowhere on an official org chart.
I think I understand how it got to be this way, and from a long-term professional point of view, it is probably good for programmers since it makes them less "cogs in a machine". It's also somewhat similar to "real" professions like lawyers, engineers (the kind with a title and professional responsibilities and, in Canada, an iron ring), and doctors, which I suspect programmers will ultimately become, thought it make take several hundred years.
Still, it can be maddeningly complex and seems like a lot of the time is too much overhead. On the other hand, a team is an engineered thing just like any other, in that there are tradeoffs. Management and capital largely seem to prefer predictably-scheduled software projects with accurate estimates to fast iteration and low overhead. One way to make this tradeoff is to have several clipboard-holders on a team looking at metrics daily, and spending 1 day out of every 10 in "sprint planning".
I should add that this "overhead" is, IMO, a good bit of the reason why other "professional" industries are so intractable to cost reductions, so long term the "professionalization" of programmers is probably bad for non-programmers (i.e. almost everyone) in the same way that the high cost of lawyer time is a disaster for ordinary people seeking justice (i.e. almost everyone), and the high cost of doctor time is a disaster for sick people (i.e. almost everyone).
For example, rarely does a firm just "hire" a lawyer and tell him what to do: they have to at least play along with the fiction that they are "junior partners" in a "partnership". They have professional obligations (to the Bar, for example) that are outside their employment obligations. It's not unreasonably for there to be more "overhead" positions for a practice than there are lawyers, because his time is to incredibly valuable that it makes economic sense for him to hire several paralegals and a secretary, not counting the "junior partners" that are employees in all but name. If lawyers were cheap (i.e. there was no cartel and fewer barriers to practice), the practice of law would look much different, and vice versa.
In most law firms, there are two classes of lawyers - employees (salaried, with bonuses) and partners (equity profit share). Generally, partnership takes close to a decade to obtain, and generally requires a buy-in into the partnership. The 'fiction', as you refer to it, is real - they are co-owners in the business, and should be treated with some level of respect.
Generally, partnership structures are closely associated with the professional services industry as it more closely aligns with the industry structure and how work is delivered - teams are often cobbled together out of the firm's employee resources, and work is overseen by one or more of the partners. As teams may be of varying sizes, it does not make sense to chain individuals to a specific 'boss' that they may or may not be working with.
Right, and this model is itself monstrously inefficient and a result of 19th century (and earlier) modes of production persisting due to the presence of a guild and the absence any reform in the legal system. This is how furniture making and shipping used to work too, but then we invented factories and wage labor.
Any sort of consulting work is effectively a bespoke product - I don't see how you can get to the point where you can 'mass manufacture' professional services.
But people don't want "professional services" at all: they want justice for the vendor who ripped them off and skipped town. They want a divorce. They want to make sure that, when they die, their daughter gets the house. They want a partnership agreement for their hot dog truck business. Later on, they might want to make sure that their partner doesn't skip town with the truck and stick him with the debts.
These things don't necessarily require professional services. They certainly don't require taking time off in the middle of the day to go to an oak-paneled office with potted plants and an anteroom. We could organize our society to give people justice without traditional law practices. We've chosen not to because the benefits accrue to a well-connected minority and the downsides accrue dripwise to the rest of us.
Note that LegalZoom and a few others are indeed trying to do this, but even they are forced to equivocate that they're not really lawyers. It's the legal equivalent of making tobacco companies put diseased lungs on their cigarette packaging, except it's not correcting for an externality, but imposing one. Why do I even need LegalZoom for a will? Shouldn't there be a government website where I can register my will for free? Should I need a lawyer and a judge to give me a no-fault divorce?
To be perfectly honest, a lot of your complaints sound like, "Why do I need someone who is an expert in plumbing to fix my pipes?" "Why do I need someone who is an expert in medicine to diagnose my illness?" "Why do I need someone who is an expert in development to develop my software?" And the answer almost always comes down to, because they've been doing this a lot longer than you have; they've been studying it more, and they know more about the pitfalls and potential issues than you do.
> Shouldn't there be a government website where I can register my will for free?
Registering a will is mostly a fallback to let people locate it.
> Should I need a lawyer and a judge to give me a no-fault divorce?
If there is nothing in dispute, you only need a judge (because a divorce is a court order.) You may need a lawyer to sure that your settlement achieves what you want, or to deal with disputes about the resolution as to property, etc.
Of course it makes it easier to have all three roles embodied in one person, but these are very, very different skill sets. In asking for one person who's good at all of them, you're talking about a seriously exceptional human being. There just aren't enough to go around.
I'm not saying reduce the body count, I'm saying don't specialize. If you have three managers, have them do everything, don't fire two of them and give the third one the work of the other two.
If you still disagree then I think we have different intuitions about the difficulty of wearing different hats in management positions. This is somehow analogous to the split on full-stack vs. specialized development. Interestingly, full-stack teams have been heads and shoulders above in quality in my experience.
> Interestingly, full-stack teams have been heads and shoulders above in quality in my experience.
The only caveat to this statement I'd make, based on my own experience, is that for the most successful full-stack teams I've known, having at least one of the team members dedicated as a front-end specialist is a major advantage. Someone who is honestly interested in the State of the Art and who is well-versed in the associated tooling and patterns.
They may decide, pragmatically, to work a step or two behind the bleeding edge with their production projects, but they understand what is out there and how that knowledge can be leveraged to help their team succeed. This role acts as a force multiplier and can empower the rest of the team's full-stack developers to build accessible, usable interfaces.
> Interestingly, full-stack teams have been heads and shoulders above in quality in my experience.
I agree with that. The way I think about it is that in web you benefit from thinking about a system holistically. The divide between front vs back end is merely a technical detail, and an organizational structure that mirrors that divide has a strong potential to artificially create friction between two parts of what should be a whole.
Beyond that, I personally feel more empowered to take on responsibility as a full-stack dev, compared to when I was previously focusing on just the backend. For me, I think it’s mostly a psychological shift: I have more confidence to focus on solutions instead of deferring responsibility and thought power to someone else because it’s not my domain.
So, while full-stack may be a generalist (which for some is a pejorative) in a technical sense, I see the general technical acumen as just one aspect of a higher level, more intangible specialization: solving problems and getting shit done.
That sounds a bit lofty but I think it has analog to the bigger conversation here about managing.
Manager with holistic responsibility for a project > manager with isolated responsibility for a single aspect of a project.
I don't think I disagree, but I'm confused by your clarification. You mean that all three managers should perform all roles; some sort of managerial council?
Technical leadership: such leaders are often called architects. Of course they need deep technical knowledge.
Project leadership: such leaders are often called project managers or product owners. They only need shallow technical knowledge and can mostly lean on their experts in their team.
Human managers: they deal with personal growth and employment. They need enough technical knowledge to make employment decisions but need not be great programmers.
In large companies these are usually different persons. In a startup the CTO does it all, so of course he must be very technically competent.