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.
I'm not sure that's the case. A good counterexample is the Manhattan Program. Sure, Oppenheimer was a great physicist. But was he as good as, e.g. Teller, Fermi, Feynman, Szilard, Von Neumann, etc? No, he was not. He knew enough physics to keep up with the geniuses, and, more importantly be respected by them. But he wasn't working day-to-day on the atomic bomb. His job was to oversee the program and distill its status into reports for the Army, so that external stakeholders would continue funding this enormously expensive project.
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.
> 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.
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.
While I can't speak from first hand experience of juggling programming and management jobs, I've observed the same problem in my part-time team leads to believe what you say is true.
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.
This is very true. I've been in the same position and eventually I just burned out.
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.
Yeah, the last thing you want as a patient is ending up under the knife of one of those “still performs surgery" managers. They often do so not because they are actually still good at it, but because they see it as a status thing and nobody can stop them.
> A good counterexample is the Manhattan Program. Sure, Oppenheimer was a great physicist. But was he as good as, e.g. Teller, Fermi, Feynman, Szilard, Von Neumann, etc? No, he was not.
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.
> Sure, Oppenheimer was a great physicist. But was he as good as, e.g. Teller, Fermi, Feynman, Szilard, Von Neumann, etc? No, he was not.
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.
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.
> 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
Yeah that's kinda my take too. A good manager should have enough knowledge to understand the field and be respected, but that's it. Putting your best technical person in this job would probably be a waste:
- 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.
Well, let’s add that most of the projects are boring CRUD apps. They have a few pain points and over a long time will need novel extensions, but their base is basically LEGOd together, hardly comparable to the Manhattan project of CS which would be something like a high-performance JIT compiler, database, etc.
Even though most commercial programming work is trivial (in the sense Math professors use the term) it doesn't mean you don't need excellent programmers (or that at least some of your programmers are excellent).
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.
Let’s not forget half the programmers working today are below average. So CRUD programs are fine when created and maintained for years to decades by people in the middle of the bell curve. But everyone’s going to touch code created by terrible programmers, if nothing else when they are getting started.
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.
“Everything not impossible is trivial.” - Mathematics.
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 thing I notice the most is with juniors out of school: some of them have masters degree, but they are really disoriented when put on the job.
Program might be trivial, but the ability to work is not taught in school, so there is all of that to learn
Sure, I agree (to the point where I sometimes question the need for cheap, not so great programmers at all). But even those great senior developers can on average only dream about being the next Von Neumann :D
It's really not that easy a problem to solve and sometimes the suboptimal solution seems better than the alternative (which would be to hire nobody until we find a good senior developer).
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?
How do you know it’s not significant? What if the company is making $5M in yearly revenue with 20% profit margin (so net income of $1M, remember most industries don’t have profit margins as high as software)?
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.
The challenges with most modern software are more long-term maintenance, extensibility and quality vs. actual hard engineering problems, but that doesn't mean that those problems are boring or trivial, as evidenced by the unmaintainable mess that many codebases are.
"most of the projects are boring CRUD apps". This is often repeated but to me it indicates that something is wrong. As soon as it is boring, it no longer is programming. If they are so boring why isn't it just done by a configuration file that anyone could type?
The trick is that usually what you require is boilerplate until you don't need boilerplate, where the "not boilerplate" parts are hard to predict ahead of time, and configuration files are pretty bad at this as it's usually difficult to "break out" of the configuration.
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.
Most of it is actually less boring than the saying seems to imply if you choose to actually look at the problem in a complete full stack manner.
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.
Well, to a degree it is done by a configuration file, it’s just written in the DSL of a big framework like spring. Like, most of the code is just declaratively specifying what should happen, not really the how. Add a few filter/mapping and you are ready.
That configuration file would be, in the best reasonable case, isomorphic to the boring parts of programming and, in the more likely case, worse than programming with a general purpose language and the associated tooling ecosystem.
One of my best buddies is a machinist, he sets up the exact same dozen or so CAM jobs every day. He and I both do 3d-printing for fun at home specifically to challenge ourselves!
I’d up the ante on the “Manhattan Project of CS”. It’d have to be something that was theoretically possible, but never done before. Like a quantum computer that actually works, say, not the toy implementations they’ve built to date.
I wouldn’t put quantum computers at the forefront of CS, at most it is an intersection between several fields. CS is much more theoretical than engineering.
Fair: CS is a poor analogy. But yeah, Manhattan involved more disciplines than just applied nuclear physics. There was applied chemistry, for example, to purify the isotopes. And von Neumann, Feynman, et. al. had to engineer purpose-built computers for brute-forcing all the differential calculus. And obviously, geology and metallurgy, to find and forge the U and Pu, had to be involved too.
Nowhere on that phrase he says the person will manage daily communication, or team coordination.
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.
The practice of having most 'final' decision making at some SVP level is stupid on its face. I can see a need for tie breaking between two teams, but the person who spends 4 hours a year thinking about a project needs to butt out generally.
You misread it, I think. The parent comment wrote "They're too valuable to pull away from day-to-day involvement." That's short-term thinking. Of course you should only hire people in roles that match their capabilities. Instead, the thought process behind the parent comment leads to "Who provides least value right now? Ok, bad luck he/she makes a bad manager."
I think your paraphrasing is inaccurate, they said
> 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.
I used to think like this but as I've gotten older I've seen the value of transitioning into management. I had aspirations of going beyond staff but I don't think it'll happen in my lifetime. I've peaked, and the cycle of getting close to the next title, getting laid off, and getting put back down at the bottom of the current title is exhausting.
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.
Stop hunting programmers. Many of us actually don't care about the deadlines, the users etc. We just love to program. We don't care about stand-ups, story points or whatever the business uses to convert complexity to billable hours.
As both a programmer and manager of teams of programmers, this take is wrong.
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.
You are absolutely right. But I will fake my way into your company on the whole business thing and still remain an arrogant, hobby hacker. But not too arrogant. You simply need my technical skills and I need the $$. Plus the job is often fun, at least a good portion of it. At least for a while.
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.
My whole career. It has worked for quite a few years already without a hiccup.
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 :)
From an anecdata standpoint, I would say this describes the mentality of ~20% of my past colleagues, and it didn't particularly correlate with their productivity. Inversely, the not-faking-it true believers bring their own problems, like failing to recognize (and hedge against) the possibility that their managers are incompetent and untrustworthy.
From an ethical standpoint, this is no more toxic or false than the facades presented by many employers to their employees.
My take, as a developer and a manager: everyone sniffs this out. It's a well known marginal dev archetype. For now, this behavior can be compatible with stable employment, but the tension around accountability sets a ceiling in career advancement.
If we experience a white collar recession, the toxic players will have to reevaluate their behavior.
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.
The most enjoyable programming jobs that I had were ones where I was also a 'user' of the software and was given power to build features that I personally wanted. I think this is common in open source projects that are started by people who couldn't find software that did what they wanted, so they wrote their own.
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.
I'm sorry you've had bad experience of being managed.
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.
Actually my direct managers are very good, the only reason I am staying, this is a very large company and rules are imposed upon us from senior VPs (direct reports to the CEO). One example, points from all Devl groups need to be combined and rolled up to the VP, and we need to increase 'points' by a small percentage every iteration.
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.
As a founder, I pay programmers who care about customers about 50% more. I’ve actually doubled the salary if a total junior within 10 months of hiring, because he cared 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.
Perhaps overly semantic, but... there's a conflation of "care about customers" and "cared about business goals" there. Ideally, they're the same thing, but not always. And if you care about customers, but are 'managed' in to doing things which are clearly at odds with what the customers are wanting... you're in a bind.
Also a conflation of customers and the users (mentioned upthread).
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
HN. Really, that was back at the time of PG essays and Kalzumeus’ 10,000-words blogposts. But I’m probably not an effective manager, I was just a good founder, a passionate creator, and luck/market fit struck me.
Sorry, but as a professional programmer, the entire point of your existence is to achieve business goals. Why would a business pay you to do anything else?
Well, I sort of disagree with part of this. There is a line between useless complexity and useful complexity.
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 can't fathom how a software dev could not "care about users".
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.
Have you met users? All they do is break stuff and complain, injecting complexity because of their varying platforms that need to be supported and features they thought would be neat. Writing code for yourself is the best.
> I can't fathom how a software dev could not "care about users".
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?
I think the fact you mention billable hours is telling. What about caring about problems and their solutions?
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"
Those comments against pair-programming, or testing, or PR reviews etc. just make me wonder about the industry the author is in. I used to think similarly, but after working in and on Fintechs for a while I just totally disagree. Small bugs can have crazy costs - there's literally a price-tag on those. So minimising bugs in production makes a lot of sense both for the company as well as the developer's mental well-being. I assume it's similar for programmers in the health-care, or aviation, etc. industry.
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.
Assuming it's not a joke site, I could kinda agree with some of the "values" but not with the "pointless tests".
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.
I feel that we conflate a lot of concepts into the term “manager.”
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.)
Absolutely. One of the questions I think about often:
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.
Disclaimer: I have been a software developer, a product marketing manager, a co-founder, and most recently a senior product manager and people manager at one of the big cloud companies.
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.
This one company posted their handbook on hackernews a while back. It described a system where there software was developed in small squads: an engineer, a designer, and a product person. The engineer's job was to lead the implementation, which meant they were the ultimate decision maker as the person actually implementing the feature.
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.
I suspect there are many definitions of "good software developer". For one of this, making them managers is a horrible idea: they are strong, fast and effective contributors, but terribly chaotic in their day-to-day.
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
For everybody working as a programmer, this should be blatently obvious. Who hasn't experienced a non-programmer manager without a clue telling them what to do? I'll never ever work again for a manager who couldn't do my job, at least in principle.
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".
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.
I don't disagree from my experience over 20 years, but I also guess than now I am a manager/leader - I'd hope this isn't the case for everyone?
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.
> 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
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?
>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.
One of my earliest line managers was a programmer. I don't think he was a particularly good one, but he was a good manager. He was a good-enough programmer to understand my job, anyway.
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.
Not GP. But for me, even a non technical manager has a full plate of duties.
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
IME (I'm not the person you replied to) a good manager does a few things:
- 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.
This is a good question, and I largely agree. I think the answer to your final question is in the preceeding two: a manager should be continually asking them (a) for the team and (b) for each individual on the team. Then next ask "what actions am I taking right now to test/implement these answers?".
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.
I think a big part of an engineering manager’s job is protecting their team’s focus, and advocating for their team to the rest of the organization. Programmers should be insulated by an engineering manager from the vicissitudes and stresses of corporate politics, and their work should be protected from management-level priority thrashing.
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.
> non-programmer manager without a clue telling them what to do?
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.
> Who hasn't experienced a non-programmer manager without a clue telling them what to do? I'll never ever work again for a manager who couldn't do my job, at least in principle.
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.
Absolutely worst managers I had have zero technical background. They both treated people badly and also were incompetent and did not understood our work. Which led to absurd processes, being simultaneously under pressure and having nothing to do, social issues in teams and so on.
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.
I worked at a company that almost only hired [nationality omitted] engineers. Seemed their goal was to become one of the managers so they could rule the others with an iron fist, much like they had been ruled for years. The very bad code proved that the engineering part of the job was mostly nominal. As a defensive measure, they knew to never hire good engineers. I was hired by one of the directors.
So in that case, the managers _were_ kind of technical but it would have been better if they weren't.
Were they a great manager simply because they let you do what you wanted, without any deeper guidance or feedback?
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.
One of my scrum teams is all very senior developers working in a new area with lots of unknowns and technical challenges. I purposely "leave them alone" not because I'm a clueless manager, but because this type of work is always messy and will have false starts. The phrase "reasonable trust" screams "FAKE!" to me. You trust until it's broken, or you don't trust. I think what you might mean is trust but verify?
You're conflating "guidance" with lack of trust; the two things are entirely separate, and I'm not sure why they are being confused.
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?
> 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.
I'm not sure if you are capable of understanding the point I'm making, but I'm going to try again (hopefully for the last time):
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.
> Were they a great manager simply because they let you do what you wanted, without any deeper guidance or feedback?
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.
Most managers I've known would love to have someone to "believe and trust" to delegate stuff to.
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!
> Why do I get the feeling you're a technical manager trying to rationalize why you don't trust your developers?
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.
My experience has been similar, I think it depends way more on the individual than whether they are technical or non-technical. I do suspect those with non-technical backgrounds are at a disadvantage though.
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.
> I think it depends way more on the individual than whether they are technical or non-technical.
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.
I often repeat how one of the best managers I had (he was the CEO of the company but it was a 5 person - including me - startup, so he was practically the closest thing to a manager) was a former restaurateur who never worked in software before!
My manager has no technical background either, and for our team he's great. However, I think they key is he understands enough technical stuff and listens to reason. If we present good technical arguments, he will listen and take that into account. He won't try to force something through just because.
A technical manager might in most cases defer to the judgement of the developer. However, provided he knows his stuff, he can also mentor the developer to grow.
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.
^ and this is why technical managers are so problematic.
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.
> 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.
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.
I don’t think they’re arguing in bad faith, only that their experience is different than yours. As with many things the answer is “it depends” and “a good manager is a good manager” and it’s hard to reduce to simple rules like “they’re good/bad if they worked as a developer before”. I had great managers who were very experienced developers (20+ years direct experience developing and still actively programming) and others that relied on a very experienced tech lead or senior developer that they could trust with technical decisions.
> I had great managers who were very experienced developers (20+ years direct experience developing and still actively programming) and others that relied on a very experienced tech lead or senior developer that they could trust with technical decisions.
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.
Managers can optimize for people or process but rarely do both really well; I'm not surprised a restaurateur is the exception. Their entire life is essentially keeping a highly dynamic, human-centric, likely broken system running while minimizing work in progress and focused on delivery.
If something technical goes badly wrong there should be a post-mortem concluding with enough clariry so that it is clear to everyone what the cause was.
How does a non technical manager know who is doing bad or good work? I wouldn’t want to work on a team where the person in charge of my compensation can’t understand if I’m doing decent vs. great work. Leads to the best folks getting frustrated and leaving over time. Mediocrity is all that will remain if manager’s can’t understand the work their team is doing and the obstacles they face.
Is it your supposition that managers should be doing things like code reviews to ensure quality?
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?
> 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?
After seeing this post my opinion has finally clicked over to "you're a shitty manager".
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.
I think you’re having a pretty narrow understanding of the word “manager”. All your argument ms boils down to an inability to perceive that I’m using the word manager in a general sense, as someone who manages technical developments. I’m not referring to a political manager.
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.
I got the opportunity to be a manager awhile ago. I had to take people I used to work closely together with on a very agile research environment and fit them into the "totally agile but really waterfall" scrumfall development process used elsewhere in the company. I was forced to assign highly specialised people to totally unrelated tasks to their expertise because PMs wanted features that we neither had enough people nor the right people to do, all the while people were either quitting or wanting to quit left and right. I had all the responsibility and none of the power. Fuck that.
I quit as a manager and went back to working as a developer (after burning-out for awhile). I can deal with shitty processes as long as I'm not asked to impose them on other people. The sad part is that nobody in my immediate surroundings (including higher managers) are happy with those processes, they're all great people trying to do the best of a bad situation. But "it's just how things are". Big companies suck.
This reflects my own experience too and I did come back to being IC. That was about a decade ago. All my friends and peers are now at director level positions and I still have to do leetcode puzzles to 'stay sharp' incase i have to change jobs. I also make about 50% less pay than them. i tell myself 'atleast i enjoy going to work everyday' when i feel like a failure.
I'd rather be slightly poorer than miserable and needing therapy. It's what it is, we're not all cut out for corporate ladder climbing. My hope is that I'll find a startup I truly believe in someday, join them early and skip a bunch of steps. It's not management that I can't stand, it's middle management.
The article seems to argue the opposite of what the title says? And then concludes that programmers should be on the board?
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.
True. What is good organization always depends on the problem that is to be solved. Almost every discussion on this kind of topic misses this.
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.
Nah. I thought that was the pinnacle, and took it. I thought I'd get to mentor folks and tie break tech decisions and whatnot.
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.
Of course there are. And in a good company, those above you will listen to your suggestions for improvement and work with you to make them happen, or something addressing the same issues. Just like you should be listening to your reports and work with them, not against them.
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.
Apparently not many. What's beyond me is why people don't leave the shitty ones. HN comments are full of examples where I'd scream that question. But maybe it's not as bad and people like to exaggerate? Or they prefer to complain instead of taking consequences. I suppose seeing oneself as the victim is just the easy way out.
> Apparently not many. What's beyond me is why people don't leave the shitty ones.
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.
>If they love to do it (and that’s usually what distinguishes the average from the best programmers)
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.
The key is that writing the best code might not be what a project requires. Frankly it might be quite down the list. Delivering a great product is so much more than writing great code.
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.
I want to point out that none of your points are an actual indicator of how good someone is at programming.
They are important in the context of a job, especially in a team, but not for actual coding.
So its really two different things we are talking about here.
Good point. The points I made apply more to Software Engineering. I should have clarified "good programmer to work with". But as you say, this is in the context of a job. There are no managers in amateur/hobby programming.
Don't agree with everything, but the opening for sure:
"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.
That was on you though, and by the sounds of it you realized that and fixed it. When you're a C-level you're expected to use your autonomy and agency to say no to things, and if people need you to be there (eg strategy meetings that need tech input) then they should have to work to your priorities.
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...
Absolutely true, it was nothing but my own failure to not follow whatever "best practices" (how I dislike that phrase) others talked me into. It's lonely to be the only technical guy in the C suite of a tech company, but that's the job. And it's important - I've seen what happens when there's nobody there.
What surprised me when I became a manager was how high the variance of the workload was. Some days (or even weeks) I have very little administrative/communication work to do. Others I'm doing 10 hour days to catch up.
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.)
I either do low value work or, most of the time, I support others.
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.
I really like this approach - in some respects I think managers should be serving their subordinates. I've just recently become a manager of a data team, having previously been a data person myself. I find myself with very little time to do anything technical, and envy my team members when I see them doing technical work.
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?
Well, I'm thinking about trying consulting so I started to offer free consultations to get better at it - see my profile.
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.
> I think managers should be serving their subordinates
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.
Oh, and for when I was running a larger ship with multiple teams, I would just focus on one team at a time, do all of the above there (with the other half of my time dedicated to more high level company wide work), then switch teams after a few months.
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.
> I'm hesitant to take on technical work lest I block someone else.
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.
As a "senior" engineer, I believe it is my responsibility to code review as much as possible. It's the best use of my advanced knowledge outside of doing the occasional complex tasks.
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.
i don't like ppl with power over my employment and salary doing code reviews.
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.
It's a short and sweet comment with a lot of understated power. A lot of people mistakenly conflate management with upward growth, and mistakenly believe you're not growing if you don't make this "career leap".
Management is lateral. it's not for everyone, and it's not the definition of success
> A lot of people mistakenly conflate management with upward growth
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.
Sure if you want to make it to VP it’s very hard to do it as an IC. But then again it’s hard to make VP as a manager as well (outside of title inflation or working at a very small startup).
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.
It's interesting to get a glimpse of these things inside of major corporations. At a former (BigTech Co) employer, Staff Software Engineer was equivalent to Director. I was not well received when I pointed out that we had a few dozen Directors in the engineering organization, but we only had less-than a dozen Staff Software Engineers, and half as many Principal Software Engineers. It didn't take me long to leave after having these conversations.
While I agree with this, I’ve been at multiple companies that claim to have a management and a technical track, but neglect the technical track as it’s much more straightforward to define success and show progression as a manager.
I recently 'demoted' myself so I could focus on software development instead of talking about software development and managing software developers. I'm much happier.
A military contractor I worked for had three different ladders employees could climb: One was the usual engineer/developer-to-manager route. Another was becoming a consultant and later a primary engineer who remained an engineer, but instead of working on one project, consulted across the company (not outside it) and was rewarded with a salary similar to top managers. The third was to do a startup within the company, form or become part of a team, write grant proposals, get money, do the R&D, then start a product line if it worked out. Going into management was not what some engineers/developers wanted and the other two routes were extremely beneficial to the company. Unfortunately the company got bought out by Lockheed Martin and the management route became the only allowed path. I left not long after feeling betrayed and they lost someone they had been educating for many years in a highly specialized knowledge domain.
Whatever for? Programmers work with machines because the results are predictable and controllable. Unlike people, who don't do as you ask, don't tell the truth, and have their own agenda.
Well working with machines wouldn't need sprint planning and code review. I think peer programmers are also uncontrollable, the business requirements and technology evolvements can be unpredictable, and the customers/users have their own agenda, and they're kinda what/whom senior programmers tend to care about. They don't represent the responsibilities of a manager role though.
I agree with the title but more of a case that the alternative is having people who desperately just want to manage who usually make the worst managers.
There's an inherent gap between managers and programmers, which does indeed makes programmers the best managers. As a manager, you don't know what does "better architecture" mean. You don't know which practices of your favorite methodology are bullshit. You're always left guessing.
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.
You cannot do everything - even in development itself you cannot be master of all languages or all subject matter areas and the ones you don't work on daily atropy. I used to know Java but now...
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.
I think this "I'm leading a team so I need to become a single point of failure for a lot of important tasks" idea is dangerous. Have you tried rotating the unpleasant tasks around the team? Started training your replacement?
I don't do anything others couldn't, technically - just whatever is peripheral but necessary. There are multiple single points of failure in our team and part of the job has been to reduce that by getting everyone to do stuff that's not in their comfort zone. We still have an undesirable bus-factor and it's not me that's the main source of it.
That's a really good point and applies to unpleasant recurring tasks, but I think there are some unpleasant tasks which are one-offs. Basically, small pieces of technical debt that may get ignored or swept under the rug, that are cumulatively important but individually too small to detract others from their work for.
So what is the team missing to be able to handle those things on their own? Wouldn't it be more useful to give them those tools instead of quietly patching over the deficiency?
I didn't mention quietly patching over a deficiency. I suspect that (without bad intention) you're reading something that's not there into what I wrote.
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.
I was unclear. I tools not in the sense of software automation, but rather the mental toolbox required for a person to deal with the situation as it come up.
With open source projects there aren't any managers, and yet good quality software gets produced. I'm interested to know people's thoughts on that? Perhaps in open source projects the 'maintainer' roles are analogous to being a manager? On the other hand I've been a manager of a software team in a company, and I'm also a maintainer of a couple of open source projects, and I'd say that the two roles are very different. Does it mean that we don't actually need managers? Really I don't don't know the answer and I'm raising the question to see what other people think.
I would start by suggesting that the incentives and motivations aren't aligned but there's more to it than that.
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.
Is there any example of a long-lived successful open source project from a non-technical manager that leads a team of people on board with his or her vision?
Bachelor of Business Science degree in Finance and Information Systems[1]. Depending on the curriculum and institution, Information Systems is not a technical degree in the same sense as Computer Science. That is why I quantified with "it depends on your definitions."
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.
Engineering managers exist to ensure the company is getting sufficient value out of the hundreds of thousands they’re paying for each software engineer. If goals were always crystal clear and every SWE always had a good sense of how their work translated into business outcomes and prioritized accordingly then no, managers would not be necessary. Those conditions are often true at very early stage startups, and never true at any company over 100 employees.
The article's claim is not actually as simplistic as the title suggests, it says that active individual contributors should have a say in how the business is run.
The Toyota Way emphasizes that managers cannot merely read and listen to reports. They need to walk the genba, the factory floor, and see firsthand what the state of things is.
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.
That's not quite how I remember it. Maybe it was a different source, but the idea is that the manager should spend a significant chunk of their time doing actual technical work, so they retain enough proficiency to step in and substitute for any of their subordinates e.g. in the case of sickness.
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...
> 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.
While the codebase is critically important, the most important aspect is how that codebase translates into user experience. How the design/software changes impact what the customer expects and how the company manages the expectations of both existing and new clients are both vital factors.
Managing that journey for both internal software teams and the wider client base to achieve the overall objectives is the real landscape for managers.
Especially for small companies, the impact of poor commits can have huge impacts for important clients which then takes time to educate and assist them to handle.
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.
That’s really stretching the m idea behind this tentent of lean manufacturing. The idea is that the whole management team should somewhat regularly visit the workshop - the place where work is actually done - so as to stay in contact with what’s happening there and are aware of what’s happening with the process and the team.
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.
No, the point of genchi genbutsu is specifically not to rely on the reports of third parties (including your team) but to actually go and observe for yourself.
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.
For some managers I worked with in the past, this was an impossible task. One person took over a year to set up their development environment. He never even ran the application. Though you don't have to actually code, there is a ton of value in knowing what the people you manage are actually working on.
No. If you need to make it mandatory then they are the wrong people anyway.
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.
Coded for 10 years, been a manager or higher roughly the same period of time.
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.
Managers can still program, it's just not the hard/rewarding/critical-path stuff. Knock yourself out with the shitwork like documentation updates and quality of life improvements like build & release streamlining.
>> 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.
In my experience, definitions of managers and what they should be doing varies widely. A lot of developers I meet these days put a pretty narrow scope on what constitutes 'management'. The bar is pretty low, and seems to get hotly debated as marginally useful to redundant on reddit and other places. Frankly it's hostile enough I'll be glad when I retire.
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.
Why can’t you now? I did the whole management thing for a few years and have gone “back” to being a really strong IC. This frees my time to work on architecture, solving difficult problems on the projects, and coding.
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.
Most of the "good" programmers aren't good at being a "people person" which is what a manager should be, right?
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.
I agree with the author that "People Who Make Software Happen" can and should fit into more dynamic roles. Although I don't think the content of this post leads one to conclude that they should become managers. Unless by manager they don't mean manager of people. It makes a better case for them being board members, or technical practitioners with more decision making power.
I agree with this. If someone has put in the work to become good at programming, and perhaps has some innate intelligence required to become good at programming, then I think it's reasonable to assume that they might be able to put in the work to become a great manager, and perhaps have some innate intelligence required to be a great manager. Certainly many programmers here are saying that they only program because they love it, and they wouldn't give it up to go into management. Great, but that in no way proves that there aren't some or perhaps many programmers who would like to make a transition to management.
While programmers probably make quite good managers; it is worth noting that software companies write software and then transform into some other form of company. Google, for example, started as a software company then became an advertising company. Since writing software isn't what they really do, it is unclear what use it is trying to promote programmers into general management.
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.
Software is always used to build something. A digital advertising company does in fact have software as the core business. You need software engineering managers to manage the software that continues to be built and get more complex.
That's a really good take but the reverse can also happen - my last company was an insurance company in the UK who's job was selling insurance... now they fully accept (with the way insurance is sold almost entirely online and with bringing rapid product and website changes to the market as fast as possible) that they are now a software development and data company who's end goal just happens to be selling insurance.
I'm an SW Dev manager who still strongly identifies as a developer and the thing I see people miss all the time is that while you don't have to become a manager you don't have a choice about becoming a leader if you want to move up. I'd also argue technical leadership is much harder as you don't have the hierarchy as your ultimate hammer; you need to earn and learn authority the hard way. You want to focus on the code and still guide the organization? Figure out the leverage to increase your sphere of influence; you'll never get there focusing on the individual.
I believe there is a lot of confusion in the debate between programmers and "the business" on what is actually needed from software manager role.
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.
On the flip side there are many of us "programmers" who are interested in technical problem solving and building things in a more abstract sense - writing code is one tool but not the only one. Promote us instead of the ones who just wanna code :D
I always found it interesting that when it comes to sports, mangers are/were rarely - if ever - the best players of their time.
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 also rudimentary to think in binary that you can either be a programmer or a manager. Progressing in my career i am finding this duality to be incredibly constricting, I excel best at programming, machine learning & working with business, product teams in finding areas of highest impact and then executing with smallish teams but i am increasingly finding that this doesn't fit into most corporate structures and i find resistance in landing the right role.
Why to do that if someone loves being developer?
I think that it's better to convert struggling developers to managers because they would understand better the abilities of best developers. After switching to managerial role, you have a lot more to take care of and it would be better to focus on organization of work than to take most complex programming on yourself. Let managers be managers and developers be developers.
> though they may still be at the code face, it’s purely prejudice that suggests that they therefore can’t be involved in strategic or executive decision-making.
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…”
This is bizarro world for me because to this day we're still fighting to have technical career progression outside of management. Excluding big companies there is no path forward after a certain level.
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.
This is precisely why large tech companies generally offer parallel career progression paths for individual contributors who don't wish to go into management. A Senior or Principal engineer at Amazon carries nearly as much weight, sometimes more, in software related decision making as their SDM counterparts.
I was pushed, less than willingly, into a management role for a pretty junior dev team. Ended up doing the work of about three developers as it was faster for me just to do certain things than manage other folks into doing it. Bad experience for everyone, shouldn't have done it but learned my lesson.
Or don't turn your best programmers into managers; turn them into project managers and stop letting your non-technical managers make technical decisions; they should defer to the tech leads.
Exactly. I'd argue that your best engineers should probably stick to engineering. And your best managers should manage. Don't take someone's skillset and dilute it by playing to something other than their greatest strengths.
Such people usually don't become famous enough unless you also count founders. How about Bill Gates, for example? He was a pretty good coder by all accounts.
There are lots of disciplines where highly skilled persons advance to first line management and continue to perform the skill that launched them. But there are diminishing returns as you move up management. Part-time management of a relatively small team coupled with part-time hands-on engineering for the same team works fine. Management of an engineering team requires being in the team's work, and coordinating between contributors anyway, and taking direct responsibility for some elements can contribute to that.
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.)
The best programmers are usually the ones, who enjoy programming and have been doing it for years. If you move them on to the management, perhaps even convincing them, that this is what they want, you might make them very unhappy and ultimately leave your business. Great way to lose your best programmers. Just let people do, what they excel at and listen to what they say about things they could have an idea about. Instead of moving your best programmers to management, hire management, that listens to the best programmers in matters, which the programmers touch due to working on problems.
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.