Turn your best programmers into managers
levelup-edu.com
levelup-edu.com
It’s perfectly possible for someone who still performs surgery to play a
decisive role in how a hospital is run. Or for someone who still represents
clients in court to be a big cheese in a law practice.
Similarly, I'm not sure it's a good idea to have your best programmers also be managers. They're too valuable to pull away from day-to-day involvement with the code. Instead it might be better to select programmers who are good (but not necessarily great) at coding, but also display strong organizational and communications skills.
(*) The better you do your job the lower your chances of promotion. Hard work and dedication becomes a road to serfdom.
> Instead it might be better to select programmers who are good (but not necessarily great) at coding
Good but not great doesn’t mean they are the least valuable, it means they are competent or at worst average. This may be a good indicator that they would like to explore other forms of career advancement than mastering programming. You for sure shouldn’t just pick someone and make them a manager, you’d need to survey a few people or create an opening and take applications from interested parties. You also need to evaluate for competence and train them to become managers.
All of us who worked as developers for a few years have seen the seemingly trivial program be incredibly difficult to support/extend/fix/debug (especially after being in production for a few years). At the beginning of my career I thought this was circumstantial but having been doing this for a living for 20 years now this is common and I keep seeing this pattern over and over again - not so great programmers will easily manage to make your "trivial" program very much not trivial to continue developing.
Despite the fears of over-abundance of programmers driving down wages being around at least since I've started working, there is a shortage of good senior programmers. A lot of companies (many non-tech) need programmers these days, most programmers are not that great, most work is not that exciting but it still needs to get done. So it's also often not even about the cost of programmers but about their availability (for the price you can pay).
Let's say you're running the internal software department at ACME Insurance and Customer Care Services in your average big-but-not-major Western European or North American city. You need programmers to develop and maintain your creaky Java Enterprise Edition + Oracle DB internal system that has been appropriately handling your insurance and customer care services needs for the last 18 years.
At this point centuries of developer-years have been spent on this system and it's crucial for €/$ millions or revenue yearly that your company depends on. You can't offer the kind of compensation, prestige or interesting projects that the local FAANG development offices can offer to easily recruit great senior developers. What do you do?
I remind you in this case their main business is not even software, but insurance and customer care services (with the software there to support that).
They can’t/shouldn’t spend 40% of their profit margin ($400k/year) in matching facebook’s compensation for a top notch senior developer.
That said, yeah, it’s frustrating the percentage of code which simply doesn’t matter as long as it works at all.
Although the point about mediocre engineers making things way harder than they need to be gets exponentially worse as the decisions get earlier in the process. So many times you look at implementing something and ask yourself why we’re even doing this at all.
The only real option for most projects to improve quality is simply keeping the same team members for a several years as they improve. This does get increasingly expensive over time, so few companies try that hard to maintain people yet the world stumbles along.
Very high level frameworks like Rails are probably a better fit for this where you can write simple operations extremely easily, but it's still all just code that can be customized when you need to make small tweaks.
Now, what would be the cost of maintaining a domain-specific compiler and its tooling on top of the configuration files?
That's true for most abstractions, btw. When you abstract something, you now need to maintain both the abstraction and the code using the abstraction.
The issue is that much of it needs a craftsman not a scientist or engineer. Virtually all of the value I have added to software in my career has involved doing the equivalent of a "This old house" renovation and bringing things up to code.
I go in and untangle years of small hacks so that the data path is clear and special cases happen in the same place. I get things onto boring technology rather than bleeding edge or high availability stuff. Most mid-size companies, even serving the enterprise don't need "scalability" in the sense that Google does or a startup hopes for.
There is great value (both personal satisfaction, and even more business) in “renovating”. Of course it depends on the project at hand.
If I want interesting problems, I have a computer at home.
It is, but it has to be on their terms. I am currently doing more than one job, not on my own terms and I am ... not happy.
I cannot do either job with the level of quality I expect from myself. And I would be good at either of those jobs alone. The context switches cost energy. The timetables are in fight with each other. One job demands from me to be free for whatever comes the other demands to plan ahead for years. How can I be free for what coems through my door if I have crumbling infrastructure I should be maintaining at any given point in time? I have to essentially either do it on a day by day basis, or I have to sacrifice something.
Sure go ahead give your employees two jobs. Hell give them three. But please spend 10 minutes figuring out if these jobs are actually compatible with each other and if you can live with the friction losses between them. You expect to get the results of 1/n employees on each job, but you might end up getting less than that for real, unsolveable reasons.
And for some reason managers always pull shit like that, when what would actually be needed is n seperate people doing the job and then they go all [surprised_pikachu.jpg] when that one employee quits and everything goes to shit, because they had no time documenting what they did.
Just treat your good people well and let them do good work. If you have their good will and you treat them well, they will produce better work than if you threaten them into accepting terms that save you a bit in the short term but destroy you in the long term.
I'd like to add yet another aspect you didn't mention:
I've had a couple of experiences in very dynamic work situations where every developer is juggling multiple development jobs at once. If those aren't very well managed (which I've never seen done), the individual jobs/projects will immediately cannibalize each other: The thing that's the most critical right now gets way more attention than anything else, which causes those other things to go unattended for too long, which increases the risk of them becoming critical in turn (either through errors because of rush jobs or because of arbitrary deadlines coming up). The result is constant firefighting.
The thing is that juggling management and development jobs basically looks like asking for that to happen (at least to me). Most important "management issues" are more impactful than the development job (especially when done as a rush job) and in my opinion even less likely to be plannable/mechanical in nature. This means that it's even likelier that some tasks will cannibalize the amount of attention others get by themselves and it's never going to be a simple 1/n calculation. And if you maintain that you could reach that kind of multitasking nirvana anyway with enough iron discipline, I'd argue that this discipline should be considered a large multiplying factor of the context switching costs involved.
If you think a programmer can become a manager, you can guide them, but can't force them to become your vision of a manager. The reason they can be a good manager is because they know more than you.
This, of course, requires a certain level of humility from the upper management, which they usually don't have.
It's exactly this. Everyone wants the long term productivity and quality boost of combining roles, but not all necessarily understand or want to pay the cost. Improving efficiency is just another way to grow a business beyond mere sales.
Any organizational change would incur some initial failures, missed deadlines, etc. The friction you're describing doesn't last forever.
Certainly some roles are easier to combine than others. It shouldn't be a huge risk in the grand scheme of things, but more places really should try to give the devs the bigger picture and loosen the reins a bit instead of being afraid of scaring them off. I personally think having the "unsolvable" in your hands is exactly where you always want to be in a career.
All I know about this is what I read in Richard Rhodes' The Making of the Atomic Bomb but....the impression I got from the book was that Oppenheimer was probably as good as most of those but that he never achieved quite the same level of academic fame due to a combination of continually shifting interests (i.e. never staying on thing long enough to go deep enough to become "the guy" for that thing) and losing a huge chunk of his most productive years focusing on being a manager.
Luis Alvarez said of Oppenheimer "It was amazing to see how rapidly his mind worked, and he came to the right conclusions"
Alvarez also "believes Oppenheimer would have won a Nobel Prize for his astrophysical work if he had lived long enough to see his predictions concerning exotic stellar objects—neutron stars, black holes—confirmed, as they have been, by discovery."
Segre called him "the fastest thinker I’ve ever met,” with “an iron memory . . . brilliance and solid merits"
Bethe compared Teller and Oppenheimer "fundamentally . . . very similar. Teller had an extremely quick understanding of things, so did Oppenheimer. . . . They were also somewhat alike in that their actual production, their scientific publications, did not measure up in any way to their capacity. I think Teller’s mental capacity is very high, and so was Oppenheimer’s but, on the other hand, their papers, while they included some very good ones, never reached really the top standards. Neither of them ever came up to the Nobel Prize level. I think you just cannot get to that level unless you are somewhat introverted"
I also have a vague understanding of an anecdote from the book of someone saying that whenever anyone talked about their work on the Manhattan Project, Oppenheimer always showed an astonishing depth of understanding but I can't find a reference to it.
Hans Bethe (who won a Nobel Prize in 1967) said, among other things,
"There was just nobody else in that laboratory who came even close to him"
https://en.wikipedia.org/wiki/Peter_principle
> The Peter principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to "a level of respective incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another.[1]
The concept was explained in the 1969 book The Peter Principle (William Morrow and Company) by Laurence Peter and Raymond Hull.[2] (Hull wrote the text, based on Peter's research.) Peter and Hull intended the book to be satire,[3] but it became popular as it was seen to make a serious point about the shortcomings of how people are promoted within hierarchical organizations. The Peter Principle has since been the subject of much commentary and research. Co
In the documentary The Day After Trinity there’s an interview with physicist Hans Albrecht Bethe who worked on the Manhattan project and later won a Nobel prize. Oppenheimer’s cognitive abilities are briefly discussed, and Bethe says something like “It quickly became obvious that he was intellectually superior to us.”
It’s also noteworthy that Oppenheimer learnt Sanskrit, just so that he could read Bhagavad Gita in the original language.
So I think he could hold his own, even against those other geniuses.
https://news.ycombinator.com/reply?id=34115186&goto=item%3Fi...
With your quote helping, the reference from the book is:
Robert Oppenheimer oversaw all this activity with self-evident competence and an outward composure that almost everyone came to depend upon. “Oppenheimer was probably the best lab director I have ever seen,” Teller repeats, “because of the great mobility of his mind, because of his successful effort to know about practically everything important invented in the laboratory, and also because of his unusual psychological insight into other people which, in the company of physicists, was very much the exception.”
“He knew and understood everything that went on in the laboratory,” Bethe concurs, “whether it was chemistry or theoretical physics or machine shop. He could keep it all in his head and coordinate it. It was clear also at Los Alamos that he was intellectually superior to us.”
The Theoretical Division leader elaborates:
He understood immediately when he heard anything, and fitted it into the general scheme of things and drew the right conclusions. There was just nobody else in that laboratory who came even close to him. In his knowledge. There was human warmth as well. Everybody certainly had the impression that Oppenheimer cared what each particular person was doing. In talking to someone he made it clear that that person’s work was important for the success of the whole project. I don’t remember any occasion at Los Alamos in which he was nasty to any person, whereas before and after the war he was often that way. At Los Alamos he didn’t make anybody feel inferior, not anybody.
It's perfectly possible for technical people to work on decision making too. In fact, the idea of specializing decision making into a group that does none of the technical work is absolutely stupid.
- excellent biologists, physicists, computer scientists and so on, are rare. You should put them where they can yield the best results. Same for people with managerial qualities.
- managing may requires qualities that are in conflict with excellence in a field. Juggling projects, building relationships or the will to play some political/administrative game may be very useful for a manager, but not necessary something an excellent developer or a surgeon would have maxed out as a skill.
Your best engineers should produce value. It's often a good idea to have your best engineers (with the ability to manage) manage. They can train the next generation of best engineers and act essentially as coaches. That's a tremendous value-add that far exceeds the results one engineer can produce. As an additional benefit, if they're anything like me, not programming for 10 hours a day means programming becomes fun again in your personal time. I generally disagree with this concept of the "savant" programmer. In my decade+ of work I've seen quite a few of these. They're never as good as they seem and often more trouble than they're worth. If a programmer does not display strong organizational and communications skills they shouldn't be advancing beyond mid in any serious company. This type of person generally costs more than they're worth because you have to silo them for anything to get done. Not worth it. If such a "savant" can't develop the proper communication skills perhaps they'd be better in academia.
You needn't have identified yourself as management, your myopia speaks for itself. My sympathy to your organization.
In one of these you're paid to care.
i bet a lot managers know that devs don’t care about business goals
I also work to eject those who can’t work with customers. We’re not here to serve the beauty of JUnit tests. I simply don’t understand the “programmers aren’t paid enough” torpe; It’s only true for purists who don’t dedicate their work to building a business.
The business's goal is generally to extract as much value as possible from its ability to balance servicing customers and users, and managing operations. I've never worked anywhere where there isn't a fair bit of conflict of interests between those three groups
At work all we hear about is "put the customer (user) first" which is great. But in reality you get 'dinged' if you really do that. In the 80s and very early 90s, I would work directly with the user to give them what they want. The users would see real progress so was kept happy, no matter how long it took. You just had to prove to them why you are having issues. Not a big deal.
Then the methodologies came in, far more than I can remember. Now, god forbid I forget to keep Jira updated. Also, I have not talked to a real user in many years. The outcome, the real users are frustrated because they get their statuses from their managers who attend meetings that show meaningless 'high-level' presentations.
The web site should add a line for "high-level", meaning "I am too dumb to look at details, here is a pretty picture". When I hear "high-level", I know the meeting will contain no real information.
You can see this with Opensource too, in the Early Days of Linux, if a user had a problem, Linus or someone close to him, would respond directly and it would get fix rather quickly. Now companies run the show, so we get things we really do not want. But to be fair, I think Linus still tries to cut through the bureaucracy when he can, with little success.
That isn't the case for everyone, and not a reason for "black and white" thinking where you take the extreme position of rejecting the tools used badly against you ... rather than placing the individuals accountable.
It isn't the tool's fault, be that meetings, agile, estimation, jira or anything else.
Last I heard, the squad decides what points mean so how can that be rolled up :)
I think it depends what project you want to interact with. In the projects I am involved in (Python, Numpy, SciPy, Cython, PyPy) you will get a response from a core dev quite quickly.
Businesses are there to make money and pay the bills (including the salary of the programmers) but the needs of the users can get lost sometimes in the shuffle. Managers are so busy trying to meet some goal set in a 'high-level' meeting that they lose focus on what would make customers happy.
My current project is very enjoyable. I built a system that I personally wanted (data management) and worked on features that I thought were important. I work closely with customers and beta sites to figure out which feature should get my attention next. It's not finished until I am personally happy with how it works.
Hey look, he even sells "learn it the hard way" books for $29.99!
Code review, having a clear software development lifecycle (not rigid, just clear), testing, good and frequent communication between developers and from developers to the higher levels, and spending more time on design are not bad things. They can save a lot of time and frustration in the long run.
I mean, I agree that some tests are, indeed, pointless, but I wouldn't trust someone who "just wants to program" to decide which tests are useful and which are pointless.
It probably matters a little less for programmers in the ad-tech industry, in which case it's fine to be more risk-taking in your programming. Programming != Programming, different approaches make sense for different products and industries.
Don't use "we" when you mean "I".
If I interviewed a programmer who had this view point, they wouldn't get the job.
Good (not necessary) processes manage risk. Risk needs to be managed whenever money changes hands in exchange for goods and services. These processes ensure you get paid.
It's a profession. Just as a builder or architect shouldn't hate plans and drawings, programmers need to care as much about the surrounding engineering processes as the "hammer and nails" act of coding.
It's the difference between a professional engineer and an arrogant, hobby hacker.
I am really happy there exist more business people that look after processes and whatnot, because it does seem like we (society) need it, to some degree.
Assuming you’re not trolling: you might be surprised to know that your colleagues are actually not, in fact, idiots, and will sniff this out.
For how many years do you suppose you will find it rewarding to fake your way from one thing to another? 5, 10, 20, your whole career?
From an ethical standpoint, this is no more toxic or false than the facades presented by many employers to their employees.
What makes this strategy work is the quantity of technical incompetence that's present in nearly all workplaces. I am actually a liked employee (both by superiors and by colleagues), I just have a low tolerance for bullshit. Usually the problem is "the other way around", that is with people that follow processes, use proper corpspeak but don't actually produce much, and are trying to cover the low output with manners.
I've been writing code on and off since I was 8 years old. Of course not professionally :)
If we experience a white collar recession, the toxic players will have to reevaluate their behavior.
Like, what, are you building software in an ivory tower for yourself? It's such a self-centered attitude.
What do you care about other than 'tinkering'? Surely you have to care about at least delivering the bare minimum of results, or you wouldn't be valuable on a team.
In a large company, there are so many layers of abstraction between you and the users that it's difficult to see how something could benefit them.
Also on top of this, I don't think that showing users more ads is supposed to "benefit" them. There are so many orgs like this, where you hear this claptrap about "benefiting the user" when it's really just showing them more ads or something like that
At this point, what else is there to care about other than just writing good code and making sure it's correct?
Because that's the core driver for me. I often feel other programmers fall into this trap of technology usage for the sake of technology usage and less about solving real problems.
I think having a distaste for process is justified when working in environments where there's no buy in from the team...but don't assume that applies to "many of us"
A programmer can almost certainly be a leader, a mentor, and a coach for a team; a force multiplier for others’ work (through tooling, code review, etc); and many other things besides — all without being a “manager” in the project/product/people-management sense.
If you make your best programmers into PMs, though, you’re effectively asking them to do an entirely different job; one whose key competencies don’t have much to do with the key competencies of programming. A good programmer isn’t necessarily a good PM. A good lead programmer is more-often complemented by a good PM, with each playing to their strengths.
Also note, that this distinction has nothing to do with running the company as a whole — i.e. being an executive or officer. Some of the best CTOs I know aren’t PMs; they’re “just” programmers, but they happen to also be cofounders, and so they participate in all the executive meetings. (In a bigcorp you’re not going to see too many cofounder-programmers, but a “distinguished engineer” is close.)
For another set of good software devs, they are very organized, care about morale and are good communicators: they become great managers.
So my answer is: your great devs could, or not, fit into the role
In an organization where you have excellent coaching staff, excellent tech leads, and excellent project managers, what would a manager focus on?
I have the same question for “product managers”…
In an organization where you have excellent user experience designers, excellent user researchers, excellent tech leads, and excellent project managers, what would a product manager focus on?
I think both of these roles too often seem to become an overarching “I am the Representative of The Business Goals in All Matters” type role. And… do we really want that?
Or are there better job descriptions for managers and PMs that would create more clarity around what they are responsible for and where they defer to their colleagues?
Genuine question because I am starting a company and I will eventually be hiring for these roles and I would like to have a better job description than the traditional ones.
The one thing I don't like about PMs is that I think the title manager confers too much power or authority. The people with the business context should be making decisions, and that should be everyone.
Product managers are (should be?) more like product analysts or product researchers.
The question you pose is (no offense) somewhat nonsensical. If a computer could write its own code, what is the need for programmers? :)
The biggest value add for a product manager that I’ve seen is at the strategic level. Assessing the market conditions, being an expert in the broader space, and having a pulse on where the industry is headed. While I do get pulled into design discussions, I’d rather not, but that comes from our designers & researchers not having enough technical depth to fully create experiences and insights for the developer audience (I create cloud services for developers).
We had an interesting case recently where we rolled out a new service that isn’t seeing traction over the past year. Big investment, was initially led and kicked off by our engineering team. However, if you were to have examined the fundamental value props of the service and who this tool was valuable for earlier on in its lifecycle, some fundamental flaws in the assumptions would have popped up. Does this mean that those tech leads and engineers were “bad” at their job, or did they just not have the skill set necessary to assess the value of what they were building? Note: a research study was also done prior to building the product, which clearly missed key gaps and analyses.
How many tools should be in a single person’s toolkit? If they had involved a (good) product manager earlier on in that lifecycle, much of the current pain could have been avoided. As somebody who is currently running a side company, I wish I could hire only “jacks of all trades”, but those people are incredibly uncommon. Most people self-select into a strength and lean into that. Thus, divisions of roles are born.
Ideally they stay in touch with the programmers by continuing to program, occasionally but regularly. To not have their knowledge frozen in time the day they became managers. And to keep feeding their flame.
It's a necessary qualification, but not a sufficient one. The manager also needs to be a people person. Lots of programmers are not, and that's ok, they can be excellent programmers. Just not managers.
In summary, a better title would have been "Turn the people persons among your best programmers into part-time managers".
The difference between them is who treats me with trust and who doesn't, the technical/non-technical divide doesn't matter.
The worst thing about outside managers is that they generally don't understand teamwork and peer cooperation. They are too used to relationships based on hierarchy, negotiation and competition. And they don't have experience of actually cooperating with same level peers.
So in that case, the managers _were_ kind of technical but it would have been better if they weren't.
Even something as simple as believing when a developer says 3 weeks for something.
If you are arguing that managers with technical knowledge of the work being done are wholly unnecessary, then you are necessarily arguing that all teams are doing optimal work all the time, and have nothing to gain from external feedback.
I call bull on that. There are several times where, after discussing some estimates with my developers, it turns out that the overall approach was inefficient. By pointing them in the direction of a more efficient approach to the problem, and leaving them to work out the details, and making them feel free to discuss other alternatives, we have been able to get stuff done in reasonable time.
Your whole point of view seems to suggest some kind of conflict between technical managers and developer teams, where I see none necessarily. Managers are a resource for the team, not people who lord it over their teams.
I have been contracting and consulting for years. Without exception, the worst managers I've had in terms of demanding the impossible, and failing to appreciate the work I have put, were those without any clue what it takes to do what I did. The technical managers would work with me to write specs that made my work a breeze.
a manager who worked as a developer for 3 years some 10-15 years ago is not in a better position to estimate the work than an actual developer with the same 10-15 years of experience. But they think they are.
And it's not just managers that have this unfortunate attitude, I see it in a lot of PM's and PO's as well.
> There are several times where, after discussing some estimates with my developers, it turns out that the overall approach was inefficient. By pointing them in the direction of a more efficient approach to the problem, and leaving them to work out the details, and making them feel free to discuss other alternatives, we have been able to get stuff done in reasonable time.
I doubt it. What I've seen is corner cutting get called efficiency only for the system to devolve over time.
What's worse is this is exactly what I meant about trust (or lack thereof). If your team is recommending an approach, take it. Believe it or not, they're aware of time.
There are always going to be times when corner cutting is needed, but if you ignore the technical needs your system will eventually be mired in shit. And your developers don't want it to be mired in shit. That you think you know better than them is telling.
Why do you assume this is the case here?
> I doubt it. What I've seen is corner cutting get called efficiency only for the system to devolve over time.
Again, "doubt" is not evidence to contrary. If you believe I'm making things up, then there is no longer any basis for a discussion.
I think you're arguing in bad faith. I therefore will not respond to your threads any longer. Have a good day.
And in fact, the latter half of that sentence is what I meant.
I'm currently a software architect and each of the teams I work with has a very senior developer (all of them over 20 years experience). I generally communicate things that are up and coming and leave them alone. 1 of them is kind of terrible at communication so I'll sometimes have to bridge that gap, but otherwise they do just fine on their own.
The other poster claims he won't "allow them to work in a silo". A senior developer doesn't _WANT_ to work in a silo.
A good manager trusts their team and enables them by removing problems. A good manager plays the politics on behalf of their team so they can get work done. Their position has little to do with the software itself because software developers are the boots on the ground, the doers.
On a basic level, yes a manager needs to have reasonable trust in his team members and be able to interact with them well. On a deeper level, however, a manager who lacks any clue about the work being done will either frustrate the team or leave them to their own devices altogether. The former is bad under any circumstances; the latter is bad unless the management provided is supposed to be at a very general level.
Why do I get the feeling you're a technical manager trying to rationalize why you don't trust your developers?
The entirety of your second paragraph speaks to a belief that developers can't manage themselves. That without a manager, no work would get done and no software written.
But having been in this game for roughly 25 years now, I promise you I know how to get software written successfully. What I need is the manager to __believe and trust__ me when I tell them something. There's a vast difference between a negotiation to figure out what can be done in the next 2 weeks and arguing with a fuckwit who thinks they know better than you despite moving into management after 2-3 years of software development.
I feel like the micromanaging managers simply don't have enough work to do? I personally celebrate everytime I find a developer who can manage themselves, their work, and if they can also manage the team (at least partly) that's amazing!
I'd love to be a good person, but these pies aren't going to steal themselves.
Because you're not reading my comment carefully, and ignoring the caveats I've put in my comment (it's a problem I've noticed with communication in general; people respond as if I don't mean them).
This is what I said: > On a basic level, yes a manager needs to have reasonable trust in his team members and be able to interact with them well.
So I do agree that trust is important. Feedback and guidance is not about lack of trust, and I'm not sure why you're confusing the two.
For what it's worth, I prefer a manager who is engaged with what I'm doing, not micro-managing me, but helping me to align my efforts with the overall picture.
pegged you correctly.
I'm leading a small (4 person) team working on a large multi-year greenfield project, and I sometimes schedule the entire team to meet with the client, who is a domain expert, so that we can hash out some fine decisions that he has unique insight into. My insights, as someone who bridges the technical and domain sides are also key to the success of these meetings.
Would you say I don't "trust" the team by not allowing them to work in a silo?
Yes, this means you don't trust them.
As I've already said, I've been doing this for roughly 25 years now. I can tell the difference between a technical decision and a business decision.
Even the wording ... "by not allowing them" implies both that you don't trust them and you don't have enough respect for the authority you wield to avoid using it cavalierly. I mean "by not allowing them to kick kittens". Sure, if they're about to start kicking kittens, #savethekittens. Otherwise, let them work.
Because here's the thing. Shitty managers don't know they're shitty, if they did, they would stop being shitty because recognition is the first step to becoming a non-shitty manager.
Because it's one thing to tell me all of the developers are inexperienced and don't have these skills so you don't trust them. It's another to claim you DO trust them and treat them as if they're inexperienced developers.
Please read this sentence again in my comment above: > I sometimes schedule the entire team to meet with the client, who is a domain expert, so that we can hash out some fine decisions that he has unique insight into.
Without getting into specifics, the team simply does not have all the domain knowledge they need to successfully complete the project. I believe you understand what domain knowledge means. It does not mean I think the team is incompetent. No, but the client has some specific domain knowledge (not exactly related to software engineering) that should be incorporated into the project.
Now, according to the team structure, I bridge the gap between the client's domain knowledge and the team's core skills. And this is what shows that I trust the team: I schedule meetings where we all meet with the client, not just me, so that we can figure out some of the decisions together.
If my use of the word "allowing" is what is throwing you off, then let me phrase it this way: how do you expect the team to deliver a successful project by working without interacting with me and the client to acquire the domain knowledge that is needed? If you want the client and I to leave the team alone, how do you expect the team to even know what the client actually wants? The project is a large project; we are refining the specs as we go along. These are not rhetorical questions. I await your answers.
When something technical goes badly wrong, and there are two competing stories on who to blame, how do they decide?
If they're not working at that level, why isn't the output enough? Developer X's solutions are solid, developer Y's solutions tend to need bug fixes for the next 2 months, who is performing better? Why can't a non-technical manager do that too?
How would a non-technical manager know that? By examining the git commit history? Or having the team tell on each other?
And if developer Y's work tends to need bug fixes, it might be that he usually works on a more difficult class of issues. How is the non-technical manager going to understand that?
You're imagining a managers job is to ensure quality. That's a tech leads job. And QA, if you have them.
You're imagining yourself as Gandolf with the staff of perfection screaming "You shall not pass".
That is not your role, nor has it ever BEEN your role.
What's worse is that you're implying that you cannot manage teams working with tech you yourself have not worked with. This means you cannot manage projects that are in rust, lisp, perl, ruby, python, GCP, or any other technology that you yourself are not both familiar with and an expert in. When your company decides to move to the cloud and they choose GCP but AWS is the only thing you've seen, do you recuse yourself?
And when you hire a developer with 5+ years experience in GCP, HOW DO YOU MAINTAIN QUALITY?
The answer is you do it the same way the non-technical manager does it.
What you're not understanding is that your developers are BETTER THAN YOU at their job.
Just yesterday we had an interview with a senior manager who is being hired to take over the three teams I mentioned in another post that I regularly work with, 3 teams that have 20+ year developers on them. I gave him a thumbs down based solely on the fact that when he has someone who isn't performing up to expectations, he starts reviewing code. I do not want that for these teams, or the senior developers on them. Furthermore, I know if we hire someone like that, they will leave. I know they will because _I_ would leave. Furthermore, this department is in a bit of a political fight with another technical department. Them leaving means this department automatically loses that fight.
The problem with shitty managers is that it can often be very difficult to fully quantify their effects on the organization because any single instance of it can be very subtle.
The question is, how do you quantify a managers output?
And the answer is you do it the same way a non-technical manager does.
You don't need to be able to read code to know your Toyota should not force accelerate on its own.
Indeed if the only value added by a manger is to play politics, then I’m not sure whether the word manager should even apply to such a person.
How a good day, and best wishes with your “management” style.
The reason we're looking for a manager is that there isn't one, but the show must go on. One of those 3 teams was managed solely by me after it was created to build a new integration with a 3rd party vendor.
Once that integration went live someone on the business side sent out an email to everyone in the company and said they had never seen a project go so smoothly in the multiple years they had been there.
Yet here you are, unable to even _FATHOM_ such a thing working successfully.
What makes it worse is that Joel Spoelsky was talking about this in the late 90's, early 2000's, it's what made me originally start thinking about it. This aint new.
When I started my career I had a manager who couldn't even type, but just approached his role as I want to keep an eye on what's going on, and when I see friction or blockers I'll jump in and start working on removing those blockers.
I've seen a technical manager get promoted, from IC to VP of engineering within just a couple of years, and treat the VP role as his job is to tell everyone in his employ what to do, no feedback allowed (didn't treat those in his employ with trust as you put it). I don't know that I've ever seen a worse leader and had a litany of problems with them, and ended up deciding to leave within weeks of this person taking over. I don't even know if it's this persons fault, as the org didn't like hiring leaders externally, so basically the entire engineering org was just ICs with basically no leadership experience.
yep, exactly.
I think your anecdote about the engineer turned VP is fairly typical. imo it's generally more difficult for engineers to become _good_ leaders because it means moving from an environment where you have complete control to one where you don't and a lot of engineers can't bridge that divide successfully and become terrors like you described.
non-technical managers never had that control. They have their own challenges, but generally speaking, it's easier for them in terms of control.
in my opinion, of course.
Maybe I've just been lucky, but in my 15ish years of working I've found the correlation between "good programmer" and "good manager" to be zero or possibly even negative. Most of the best managers I've had either never could've done my job or hadn't programmed since Lisp went out of fashion. However what they all did have in common was that they knew their limitations and always deferred to the relevant experts when faced with technical decisions that they didn't have insight into. You need a lot of skills to be a good manager, being able to make good technical decisions is one you can easily delegate.
Can I ask you (sincere question, I'm investigating the topic) what kind of value did your manager provide if he had zero ideas about how your job was done?
I mean: if he trusts you, and does what you ask, that's great. But I'd find very difficult to manage a team without understand their jobs. How can I help them in their job, and help them improve? What's my role?
For the managers I’ve had that work that way, the work is basically human shield.
Meetings with stakeholders, random corporate demands, bugs that people attempt to escalate more than they should because someone in the chain is particularly vocal… their job is to deal with that so programmers don’t have to.
Additionally, acting as coaches (improving team relations, solving friction between colleagues, etc) and acting as an artist’s representative for their programmers, playing the necessary work politics so that they get their raises and promotions.
What made him a good manager was that he removed obstacles for me. He made sure I had the equipment I needed; he dealt with bureaucracy problems; and he hooked me in to experts when I needed advice. He was great. we got on well, and I was his right-hand man.
Then he got promoted, moved to Head Office, left me behind, and I never spoke to him again. He was replaced by a dullard checkbox manager, and I moved on within a couple of months.
1. Shields up, Scotty. Random drive by requests, intracompany resource raiders, time sucks for random asks, even just garden variety legwork to clarify (in the GTD sense) next actions on a company project all serve to keep the flow of programming moving
2. If I and a dev on my team disagree and can't resolve if ourselves, we need a judge to present our cases to and have an executive decision made
3. Our team culture and API are implicit contracts that everyone is stuck with no matter what, but if the manager encodes known processes and standards for how we work and principles the team assumes, everyone both on and off the team can benefit from the reduced friction and frustration they encounter when trying to work with the team (or in the team) because they are no longer trying to row against the current or "hold it wrong"
4. Even if all the available work is well defined and well specified, there won't be enough resources to do all the work at once. Even if you trust the devs enough to know and pick the higher priority work, communicating that out to external parties and ensuring that everyone involved has proper expectations is an important task that devs are just not invited to the right manager status meetings for etc.
5. If you see a dev spinning their wheels or getting stuck in the process, take a note of what you observed and stash it away until the next 1x1 with them or potentially see if 2 or 3 similar situations come up, then bring up the observations and work with the dev to see id they can improve their processes or if the business function has flexibility too
- understands the business requirements for the project(s) you're working on;
- helps coordinate the non-technical parts of projects, e.g. facilitator, finding overlaps, and (when they occasionally arise) dispute resolution;
- works on road blocks to getting your job done.
None of those require in-depth technical knowledge.
A good manager may have opinions about the minutiae of what you're doing, but keeps those opinions to herself. After all, the manager's purpose is to leverage their reporting ICs into getting more done, not doing the task herself.
A good manager doesn't need to know your job (that invites micromanagement) but they do need to known the "interface" for your role and be willing & able to learn aspects as they relate to growth and improvement. Managers work on a 2nd-order system that's an abstraction of the software you're building but with added complexity because it involves people. Depending on the balance it can look very similar or very different from the one developers navigate.
That's the key here. And it's really a coin toss whether previous programming experience makes a manager more aware of limitations or completely oblivious. Perhaps most likely both at once, acutely aware of being disconnected from the state of the art (or even from the state of the art within the org, even if that's also far behind) yet completely underestimating the actual amount.
The biggest thing I've learned is empathy and communication is key - tech doesn't matter in the end, but you have to be able to spot and stop bullshit.
I'm leading people across two major projects at a worldwide retailer - one being a new project driven by my tech decisions and architecture - and I'm also responsible for the welfare and upskilling of the teams.
The sacrifice is not doing day-to-day coding or even code reviews, but taking on more strategic decisions, and working more at the architectural level and handling all the stuff like stakeholder management, getting BIAs and Architecture reviews done, etc. That way the team can focus on what they need to do and not worry about management bullshit.
I like that phrase
https://en.m.wikipedia.org/wiki/Necessity_and_sufficiency#Si...
That is not a problem. In fact, the single thing that make a manager a good one is that a good one let the skilled do their job, and communicate back-and-forth with the rest of the people in a good way.
That is all.
And because this, the fact he can't understand most of I say not matter: It just insist to me to explain it like anybody can, and let the details to me.
I have this people before (some with actual skills). Nothing get closer to just the people that can do let them do it and not care about details but just outcomes.
And BTW: I work for "boring (but never actually!)" CRUD apps, and customers that are not only clueless about software: One of the biggest one was a guy with near zero formal education, coming from the street, that have invented his own things that is a bastardize attempt at accounting/financed with the most obtuse jargon you can imagine.
And the manager make it work well...
Even if the manager could do your job, it's a bad manager if they always tell you what to do.
A good manager should be helpful and assist you, not command you. And that's possible even if they're not a programmer.
IMO, PMs are too high on the decision making totem pole. Too often they are making demands of engineering when they should be asking.
There are companies where deep technical knowledge can guide strategic decisions. That applies to companies that are developing cutting edge technology, where the "ability" of the code base does in fact affect which products can be made. Currently, examples could be VR or AI.
However, any random SAAS where features can be developed in a reasonably predictable manner and can more or less be designed by non-technical people, I don't see a programmer adding more value to the board than any other employee that's not C-level.
The most confused one is probably the one on “10x engineers” BTW. Just ridiculous to try to discuss that without specifying the problem, or at least the general level of difficulty.
Nope, nothing but BS. Hundred meetings a day, forms to fill out, people texting you that their belly hurts and won't make it, people telling you you can't give good reviews, etc.
Being a manager is not the same as being a leader. It's being someone who can stand playing the game.
Don't try to learn from people who are also doing it wrong.
This whole "opposing forces" attitude is what makes hierarchies toxic instead of supportive and I'd run the other way if somebody described a workplace like that to me.
what % of companies do you think fit this qualifier.
I think its hard to tell from outside which company is shitty and which isn't. Even if you know someone on the inside you might end up in a different team with shitty culture.
Can you name couple of non-shitty companies in the US. I can't think of many.
Then you get to do 20 hours of interviews trying to hire their replacement instead.
So you get a choice - but not much of one.
Ppl do this just for money?
Anyone else feel that people who love programming aren't necessarily great at it?
A lot of devs who "love" programming can be highly opinionated, get distracted by minor issues, have difficulty or reluctance to summarize things to non technical people , have unwieldy PR's containing changes for things way outside of the scope of the task they were given, and don't believe that documentation is something they personally have to do.
So far, from the people I have met, I would agree that having a love for the craft distinguishes very good programmers from exceptionally good ones.
There's only so much you can do against someone who is talented and enjoys spending even more time learning something.
I think what you've said is a lot closer to the mark. A love of programming can distinguish the very good from the exceptional.
Although I'd be envious of whoever has the dilemma of having to select a manager from only very good or exceptional candidates.
That's the minority of us. Most of us are average or above average, and applying that rule tends to pick someone closer to my example.
As mentioned in another comment here[1], some programmers don't care about the users, or deadlines. That's fine if programming is your hobby. It's not fine if you're paid to deliver a product.
As an example, if our program doesn't do the right thing on the 1st of January 2023 when regulations change, it is completely useless for all of our users. A programmer who doesn't care about that deadline and the potential effects for the users if it's missed is worthless for us, regardless of skill.
"People Who Make Software Happen (you may know them as “programmers”) should have the option to progress their careers without leaving the code face."
I was promoted to CTO of a quickly growing company some years back. At some point I had so many offsites, strategy workshops and generally low value meetings (that the other C levels loved), that I got somewhat out of touch with what's actually going on in the code base and with the people. I was both frustrated and ineffective. Ever since I've made sure I spend roughly half my time in a CTO role reviewing/writing code or pairing.
It's not about all good programmers being managers, though they should be given the opportunity if they want it. It's about all (technical) managers being decent programmers.
No one above senior dev level has too many meetings. The issue is always that they say yes to all the meetings they're invited to. Realizing that you're allowed to say no is a critical part of leadership. Possibly the most important part...
Since I don't know when I will be swamped next, I'm hesitant to take on technical work lest I block someone else. How are you handling this? Have you found a way to smooth the admin/comm load?
(One advice is was given is "do only low value technical work" and I've tried this but it's just not satisfying enough to keep me engaged.)
For the juniors on the team, I make myself available for pairing so I can help train them. For the seniors, I help them by writing documentation, reviewing their work and making sure it's aligned with where we want to go (you can call it architecture but I don't like to throw that word around), or help out by resolving disagreements. Or whatever they need really. Not all of that stuff is technically "code", but to me it's not primarily about writing code myself, it's about being constantly in touch with the code base in some fashion or another.
I also delegate organisational work to those on the team interested in it - I very rarely run a meeting or drive some work, I just fill in the cracks where nobody else wants to do it.
The main trick is probably that we maintain a highly asynchronous communication culture - which is not for everybody and non trivial to establish and keep. But if it works, it really works.
Probably not the best way to do it, and it might not scale beyond 230 people (since I never tried), but it's what I ended up with and it works well for me.
Do you have any advice for a technical person newly turned manager? Anything you wish someone had told you when you started as a manager / leader?
I can't think of a lot of generic advise: Sure, people I've talked to over the last 13 months of doing this face more or less the same problems, but how to best deal with them depends entirely on their situation, the people they work with and their own personality and skills.
One of the most eye opening things I've learned about is Cynefin from Dave (!) Snowden - wish someone had told me about it when I just started.
On the more generic side, I think the most important thing I wish someone told me is to not be _too_ humble, to trust my intuition and experience and be proud of my brand of management, not apologetic for not doing things the way somebody else read they're supposed to be done. Depending on your personality, I might as well recommend to be _more_ humble though - the balance is key for me.
This is totally what I think about managers of technical staff (and not "in some respects"). It's the subordinates that are doing the production; managers are lubricant, whose task is to ensure the production staff are maximally effective. Without effective management, production staff operate at reduced efficiency. But without production staff, managers are completely useless, and might as well be re-tasked to work as coffee boys.
I'm referring to line-managers, not the executives who make business decisions. I know nothing of executive work, and I suspect there's not a lot of continuity between line management and executive work. And yet some line-managers carry on as if they're already three-star generals.
Not the person that you replied to, but I would suggest doing code reviews as a non-approver, taking non-critical path tasks (documentation can always be improved) and writing examples/tests if appropriate for your system.
I had a CTO once doing random code reviews without knowing complete context. It was hard to contradict him or much easier to just accept the suggestion and move on.
As a manager, I would see my main job to, in this order 1) keep as much of the non-coding tasks off my ppl's plates, 2) code review when needed, 3) type actual code, 4) remember birthdays.
Management is lateral. it's not for everyone, and it's not the definition of success
It's not a mistake, if the company doesn't provide any growth opportunity for ICs beyond a level equivalent to a Sr.Director or so. If you want to make VP/SVP/EVP level comp, what other option do you have? In most companies, none.
It’s just a numbers game. 50 engineers, 6 EMs, 2 directors and 1 VP.
The amount of meetings a VP attends is insane. That coupled with the diminishing marginal utility of money makes me question anyone who sets that as their explicit goal though.
Unlike business, programming has a steep learning curve. Managers cannot understand programming, but programmers can understand business needs.
At the same time, people who become programmers, typically lack skills required for managers. They also lack interest into those skills. So most programmers turned managers are a complete disaster.
Basically programmer-managers have greater variability: some of them are the best, but most are the worst. Promoting programmer to a manager is a high-risk high-reward gamble.
The distribution is inverted bell curve, so examples/counter-examples are pointless, they are just anecdotes.
I became a team lead recently and my job is to do all the things the others don't want to do. To keep shit off them so that they can focus. To organise things so that the people that we work with outside the team are ready for what we produce to do their testing, evaluation etc. There's meetings about how to fix our many problems, about what work we should do in future, about bugs - triaging them and working out which team should handle them. It's all necessary but it cuts into the day and destroys my focus.
There's just no time to get anything serious developed. I am lucky to almost tag-along technically but I cannot learn at the rate my team do (we are picking up a system that was done badly and quickly by contractors) because I cannot spend the concentrated time on it. I struggle to do bits here and there to keep myself understanding the situation just about. I work on the test system because we didn't have one till I started and it's so critical to fixing all the problems we have but that's about it.
I do find though that it's important to work daily with people who do know how to program even if their experience is years old. Having a programming Product Owner for example. Without that experience people just don't get it and they try to make teams do silly things or they try to apply pressure to get what they want as if that worked. So to me there's no alternative to turning programmers into managers (or other functions) because without it the company will try to do everything in incredibly stupid ways.
Also it's important that the best programmers get into decision making and by this I don't mean people who are good at writing piles of code. I am sorry but I don't find that important - to me it's people who write code that others can maintain and who help each other - people who help optimise the team's performance rather than just their own. That sort of developer is needed at higher levels to make sure the company acts intelligently but they will pay a price in lost expertise.
It's quite common, unfortunately, for companies to be agile at the bottom and waterfall at the top and you just cannot get the idea of agile into the heads of the accountants. It's hard enough for developers to get it.
Side note: The whole point of unpleasant non-recurring one-off issues is that it's difficult to find or come up with tools to address them. Tools start making sense when stuff is recurring.
Why have leadership of any kind? Why not just workers committees? :-)
With open source projects, most commonly, everyone wants to be there and has some level of the same objectives, possibly because they are consuming the final product as well as contributing to it. Here, the open source maintainer is a sort of shepherd for the flock.
As a software team in a company, not only is everyone not equally motivated, the incentives are also not the same. A company has a financial incentive that may not align with the technical one.
A company also has the pressure of deadlines where an open source project can be delayed or even in a state of maintenance mode. This drives a different culture as well. The purpose of the manager is to deliver value for the company while the role of the open source maintainer is to deliver value to the project.
I would simply posit that the two roles are not the same. There are maybe some overlaps from the standpoint of overseeing finished code and the delivery of releases, but the hierarchy, org structure, motivations, and incentives create very different situations.
I'm not sure if Bob Young (founder of Red Hat) meets the definition either since he is no longer involved these days. There's a bit of a theme developing in my mind clearly as these are all the enterprise and open source projects. I admittedly don't know much about the founder(s) of SUSE. (In my mind, I might be ascribing some notion of success to being a profitable enterprise. You may not feel the same.)
Nonetheless, those are examples to the hypothetical and I have not researched any others though I am sure they exist. I think one important thing to keep in mind is the type of person/personality these projects tend to attract in the first place. That is likely why there are a predominant amount that are technical. This detracts from the original point though.
[1] https://en.wikipedia.org/wiki/Mark_Shuttleworth#Early_life
With software, the genba is not the office. It is the codebase. Managers don't need to be making commits that get merged into production, but they should be constantly familiar with the codebase that their team is responsible for, and capable of playing with it and try out ideas. See the technical debt with their own eyes. Understand firsthand why their report says that making certain minor changes is such a difficult task.
Bingo!
In addition, it gets very difficult to critique a commit made by a manager (or worse a director who still wants to code) which is not consistent with rest of the team or the technical goals. They may have the best intentions but not reflect the current design/techniques that the rest of the team are using to improve the code base. The power structure just doesn’t allow the team to work. Seen many good people quit over this.
I'd agree to this, if you include the individual contributors in the set of "users".
If you are a direct manager of a technical team, that point should already be covered. You are always in contact with the working team. You are already in contact with the people knee deep in the work: that’s your the tech leads, the junior and senior engineers and the WPM working for you. Just ask them what’s happening and where process needs work. If you can’t trust your team, well, you have bigger issue than the quality of the code.
This has nothing to do with trust, and is entirely because different people with different experiences in life tend to see different things when they look at a situation.
> With software, the genba is not the office. It is the codebase.
Amusing aside: my dictionary includes "scene of the crime" in the translations for "genba".
Thus requires a deep hierarchy of managers to even out the administrative burden and give everyone time to do technical work.
What confuses me is that in my experience, a deep hierarchy of managers tends to lead to each layer inventing more administrative work for themselves and the layers below, not help take the burden off...
What you should ensure is that they can do that. That their schedule permits this. If they are the right people, they will gladly take the opportunity.
What knocked me out of coding ... you should always give your best work to your people ... don't steal it, never block the team, and do the work your team doesn't want to ... e.g. c*p deflection. For any reasonably sized team (8+) and company that isn't a startup, that's a full time job. That's without going above and beyond the low standards most people set of managers these days ... working career planning, understanding industry technical and business trends, helping people realize their better ideas and so on.
One other thing I've realized ... anyone that's hiring knows that it takes new hires time to come up to speed. Depending on how optimistic or senior you are, that can be anywhere from 1 to 2 months full time. If you're a manager, you should look in a mirror, that's you. That means to be anywhere near as effective you need a month to focus on bringing yourself up to speed while delivering on some content your team needs.
If you're a full time manager doing a good job, that's not a thing unless you are giving up nights and weekends to do it.
I miss my years coding and delivering though, when I finally get to a 'work on my own terms' state towards the end of my career, I'd really like to go back to it though.
>> If you're a full time manager doing a good job, that's not a thing unless you are giving up nights and weekends to do it.
I don't agree with this at all, for a manager or any job.
I think the better managers have 1:1's were they think about it before and after as opposed to just showing up. They have career plans and objectives on a quarterly basis, and they do it with the employees as partners, not just recipients. Operations, planning to make sure teams work reasonable hours, managing customers, documentation, hiring, budget, procurement, audits & process, salary planning, all of these things are in scope where I learned about management. Managers also lose control of the hours in their schedule, they need to work on other people's schedule in the team more often than not ... urgent issues for people can come up all hours of the days, nights or weekends. If you're a good manager you're there for people when they need it.
I don't meet a lot of managers that both do those things & really want to do them. I meet a lot of good team leads who are also coding that don't do the above, which frankly should be ok and rewarded. It's misleading to suggest though that they could also pick up everything else and still have the same time available to code.
I do not even really see it as going “back”, just moving forward in a different direction.
My managers seem to love this so far because they can focus more on the people aspect you describe, while also having someone on the team who can step into many aspects when they want to go for vacation.
In most business environments the good programmers are generally ones who stay on task, aren't careless, think ahead... they aren't exactly algorithmic masters or writing the cleanest most extendable code. They aren't writing complete shit shows either, they just get things done. Features implemented, bugs fixed.
Senior/tech lead should be enough of an upgrade to get valuable voices heard, without swamping programmers with managerial duties.
Otherwise, let’s turn the best managers into programmers as well, and see how that goes :)
If writing new software the the core business of an organisation then sure, put a programmer in charge of things. I'm struggling to think of situations where that is the case. Usually the success of an existing company doesn't depend on writing new software.
Video games and, to a lesser extent, consumer devices.
Sometimes there is need for efficiency and the programmer promoted to manager role will excel as they have devoted their past life to optimization and efficiency anyway.
Other times, there is a need for engineering excellence (-> best practices -> complexity -> over engineering -> bloat). If that's the case you better promote your worst engineer to the manager role.
It is really that simple, but most will fail to see it.
Tried applying to other jobs as engineering manager but obv people won’t hire me since my resume is mostly IC and team lead type roles.
I have had over a dozen managers in my career so far. Only two were good while the rest were terrible or indifferent at best.
Now I’m trying to build a KMS and hopefully it can become a company and my way out of this stupid career “progression”.
It's been almost 10 years when I last had such.
Tear it down.
Some were woefully mediocre players themselves, and didn't necessarily have a noteworthy career as players.
So my theory is that if we're going to borrow anything from the world of professional sports, you don't need to promote your best (whatever best means) employees to managerial positions. You probably need them to be above a certain threshold, but also be able to identify those employees with best leadership and managerial potential.
It’s not purely prejudice. Strategic and executive decision-making is a different skillset and demands significant time for preparation and integration of disparate information.
“Though they may be leading the company, it’s pure prejudice to think the C-suite couldn’t do some drive-by coding…”
"Maker's Schedule, Manager's Schedule - Paul Graham" http://www.paulgraham.com/makersschedule.html
Good programmers are good programmers and more often than not make shitty managers, they're separate skills. The best managers I had were at most ok programmers.
You can also make untrained, untalented people mangers into management.
At the same time. Double-barreled footgun!
But beyond first-line management, two things are true that argue against having people both be individual contributors, and managers: First, maintaining your skills at full fluency for actual coding and engineering is a major commitment. To be a contributor in any significant system, you need to keep a lot of details fully current, and that's harder, the further away from the day to day building your primary responsibilities demand you be; second, no project, program or product manager wants a part-time senior manager, who is likely to be dragged away from day-to-day concerns at any and every turn, and who can't possibly keep current with the details of the project at the lowest level, responsible for some component in the critical path of their project or product.
As an executive, responsible for multiple programs and products, I needed managers who were completely tuned into the bigger picture of their particular program or product family, and how it fit into the overall strategy of the company or division. Without question, you want people in these roles who understanding engineering, deeply and capably enough to be able lead, inspire, and read their teams (the one skill every manager and executive in charge of technical engineering needs is the ability to judge the plausibility of what their teams are telling them, because the roll-up of expectation and promise mismatched with ability is project and product disaster), so former developers are probably a good fit. And if they want to code as part of their development time, somewhere out of the management path, that's great. I did, all the way through the rank of CTO. But I never put my organization in the position of relying on me delivering anything in terms of actual code.
(BTW, I don't think the author's comparison to surgeons is at all apt. Every surgery is a stand-alone project, and if you're a capable surgeon for a given surgery, and can arrange your calendar so that you do enough to maintain that edge, then you can do them, and leave them, and not in any way dilute your attention to management. That said, where I worked before retirement, where every leader of a clinical department was an M.D. appropriate to that department, and still practiced medicine, they all also had full-time, dedicated administrative partners who actually did all the "pure management" while the M.D.s provided primarily strategic direction and leadership.)