10 ms·

> For example, people often assume that any talented developer will end up becoming a manager. I believe this thinking is harmful for this Industry. While the

> For example, people often assume that any talented developer will end up becoming a manager. I believe this thinking is harmful for this Industry. While there is some overlap between a manager and software dev they are in the end two fundamental different jobs. Sure having some understanding of software is helpful as a manager but IMHO this only includes skills up to the "mid"/"just after junior" software dev level. Sure as software dev you also need to have some resource management skills (some time management, and some potential team lead skills) but as a manger you need much much more of this skills and apply them in many more ways. So if a senior software developer becomes a manager it's wasting their potential as software developer. Similar a excellent manager doesn't need _any_ programming skills, only some understanding of the programming job and it's hurdles (which might be simplest to learn by doing programming for a few years, but there could be much more efficient ways to learn this). So IMHO if you want to go into the management path its best to start early on, and end up there around the time you reach a mid-level skill set or earlier. Similar don't push senior engineers into management positions, being very good in one doesn't entail doesn't entail being good in the other. Also please don't go around spreading bs like "if a older software dev isn't a manager yet they are incompetent and shouldn't be hired". Our industry needs more old software dev, through only such ones which continue to learn and improve their skills. Not such ones which stagnated in the past.

SnaKeZ 5y ago
https://en.wikipedia.org/wiki/Peter_principle https://en.wikipedia.org/wiki/Peter_principle
Spooky23 5y ago
It may be harmful for the industry but good for the individual. Becoming a specialist is very dangerous, as your future is tied to a product, and the products don’t love you back. Make the wrong choice and you’re managing a Starbucks.
- JakeAl 5y ago
  Nope. Starbucks won't hire you without restaurant management experience. You'd be lucky if they hired you as a barista.
  - akomtu 5y ago
    Without coffee making experience you'd be lucky to get a toilet cleaning job at Starbucks.
dexen 5y ago
>While there is some overlap between a manager and software dev they are in the end two fundamental different jobs. I used to think that early on in my career as developer. At this point I believe those two are fundamentally the same jobs: gathering, processing and transforming requirements from one form & language to another.
nix23 5y ago
Exactly, it's like saying talented artist end up becoming Museum Managers.
- robofanatic 5y ago
  very very few developers do the kind of work that can be compared to a talented artist.
  - nix23 5y ago
    Talented developers.....it was a example, is it hurting your feelings?
Gtex555 5y ago
the program coming when someone who makes less money than you is managing you , doesnt really work. So managing is like a reward.
- marcinzm 5y ago
  Just have your staff+ engineers report into directors and VPs rather than line level managers.
  - kcplate 5y ago
    You need a line level manager to insulate the suits from developer lunacy.
    - betaby 5y ago
      More other way around
      - marcinzm 5y ago
        There's a reason good line level managers get called shit umbrellas for the team.
      - kcplate 5y ago
        Been on both sides of that line, in my experience there is FAR more lunacy among the development folks. But to your point, the lunatics always feel like they are the “normal ones”
        playing_colours 5y ago
        It is often expected to be defined in the expectations towards engineers at Staff+ level that people on that level are good at communications and can balance technical and business points of view. Also, developers are often not skilled enough to hide their “lunacy” and they are sincerely open about it. Managers are more skilful at hiding malice, incompetence, pure wish for power, that makes them more harmful for a company.
bjornsing 5y ago
This line of reasoning is popular, but it lacks one perspective: people are social animals and many instinctively want to climb hierarchies. If you promote junior software engineers into management based on interest then a lot of junior hires will start manoeuvring for that, instead of trying to get good at their trade and proving themselves that way. I’ve worked in big companies with the philosophy you’re advocating, and my impression is that they turn very political and lose focus on the day to day engineering work. In the extreme the engineering work even turns into something “dirty” that you should know as little as possible about, because that’s the way to be promoted into higher paying / higher status roles. When 10-20% go around “virtue signaling” their ignorance it quickly destroys the culture.
- dathinab 5y ago
  > instinctively want to climb hierarchies But that also means you still see managers "a top" of engineers (a "better" job). But just because you are managing a project shouldn't mean you stand above all the people in the project. Like e.g. a trainer in football/soccer might direct the Team but the highly experienced players in the Team are, while directed by the trainer, not in a social hierarchy below the trainer. Because most times they stay when the trainer gets fired and they might get the trainer fired too if they believe the trainer is incompetent. So in the end the problem just again boils down to seeing being a manager as a advancement of your carrier but becoming a senior engineer just as a continuation/negligible advancement.(1) (1): assuming proper standards for senior engines, I have seen many people in senior engineer positions which do not have the skills to call them senior engineer IMHO.
  - bjornsing 5y ago
    > But that also means you still see managers "a top" of engineers (a "better" job). No. All that’s required is that 10-20% of individual contributors see it this way. They will start manoeuvring, “virtue signalling” their ignorance, effectively destroying the culture. You don’t see it that way. I don’t see it that way. But they do. That’s enough unfortunately. What you need to break this dynamic is that the opportunity to be a trainer (or at least coach) is a kind of reward for learning to play the game really well. I think that’s how it works e.g. in (European) football as well.
lmilcin 5y ago
(BTW I am 40, have been working as dev for the past 21 years and I am now transitioning to my first non-development role ever after working as tech lead / senior dev for over a decade) > Sure having some understanding of software is helpful as a manager but IMHO this only includes skills up to the "mid"/"just after junior" software dev level. I disagree. There is a lot of useful skills that a developer can pick up usually only after you are very comfortable with the coding and technical problem solving. Ability to improve processes, being able to influence morale of your team, ability to think though a coherent strategy for what you are working on, handling emergencies, preventing emergencies, creating space for your teammembers so that they can thrive, teaching others useful skills, managing up, and so on and so forth. > So if a senior software developer becomes a manager it's wasting their potential as software developer. Sure. But maybe they can now "leverage" (building towards that bullshit bingo card...) their experience in a position that has more impact?
- kcplate 5y ago
  > For me ability to code (like knowledge of programming language) is a necessary but relatively minor ability of a good software developer. Absolutely. I have been in tech since the eighties and it’s remarkable to me how all the other skills that used to be necessary to create quality systems have seemingly taken a backseat to this skill. There are far to many developers with a severe lack of good engineering and troubleshooting capabilities nowadays…but boy are they fluent in the language de jour
  - bboylen 5y ago
    What is the best way to develop engineering & troubleshooting capabilities? Definitely seems a lot less clear cut than just practicing a language
    - kcplate 5y ago
      I think to a certain degree it’s just an innate capacity for creativity coupled with logic that gets refined in practice. If you don’t have those core components in you you are pretty much at a disadvantage to develop them. To be honest in the last 10-15 years with the shift to Agile it really feels like the type of folks who become software devs prior to that shift represent about 15-20% of the new devs now. The rest are kind of just commodity devs. Give them good detailed requirements and they can churn out code. That 15-20% are the ones who can churn out something without a hyper level of detail or refined requirements.
davnicwil 5y ago
> this only includes skills up to the "mid"/"just after junior" software dev level Not so sure about this. Usually part of the responsiblity of managers in software is making or at least guiding those making the bigger techincal calls that have long term and broad scope impact. These decisons typically benefit from a pretty decent assessment of technical risk, which derives from both a good first principles understanding of a proposal, and probably moreso, lots of first-hand experience of similar things going wrong and right. It's not a coincidence that top level tech management at most big successful software companies have deep technical skills and backgrounds.
- tkiolp4 5y ago
  Is that true? In the companies I have worked for, the technical risk assessment and everything related to “is this a viable tech solution” is done by senior engineers. Managers barely limit themselves to agree with what senior engineers say.
  - Mezzie 5y ago
    Yes, it is. A lot of companies run like you've seen, but that's not how it should be. For instance, if I have to talk to tech people about that aspect of a project I'm working on, if we're talking about technical risk, I should have some different perspectives from a senior engineer that will influence our back and forth. For example, it's common for engineers to switch jobs every year or two and knowing that means I would know to ask questions specifically about what our tech risk would look like if we don't update the stack/tools for the next five years (say if I know the exec team won't fund upgrades or the non-technical parts of the organization are resistant to change). Or if we'd be able to hire engineers to maintain whatever product in 3 years: Is it being taught? Are there enough engineers on the market with this expertise that we could replace someone if necessary? Can we AFFORD to? (Will the execs/HR pay for the expertise if it's a rare skillset?) Etc. And I wouldn't consider myself qualified to manage a team of engineers; I'd expect more skills and insight from people who are genuinely qualified.
    - isbvhodnvemrwvn 5y ago
lifeisstillgood 5y ago
I am very very negative on "management" as a skill in the software world. There are a few key outcomes needed 1. staff work 2. Policy decisions 3. resource allocation 1. is working out how the various pieces will collide (ie how long it will take to march x thousand people through various roads as a good example of army staff work). This is absolutely a job to be replaced with software. Then all that's left is the trade off in options otherwise known as 2. policy decisions. And this includes making policy on the hoof. That's fine but I think companies are going to become more democratic and much more obvious what policy decisions are being made and when - and that will take oversight 3. resource allocation. Where to spend the budget? And again this is mostly about staff work and policy So i think the staff work (the helicopter view) will get commoditised, the policy decisions constantly reviewed and eventually replaced with democracy and frankly that's it. What we will need is lots of administrators .. oh not that will be replaced with software ...
- senko 5y ago
  You forgot herding cats. Good luck automating that.
  - lifeisstillgood 5y ago
    Cats respond to incentives. You only herd them when you want them to do something they do not understand or are not incentivised to do
    - sdenton4 5y ago
      Cats often value their autonomy and sense of mystery over any particular incentive one can offer. Source: Currently trying to train a literal cat. And am a figurative cat myself.
      - lifeisstillgood 5y ago
        You are probably easier to train than your cat! My basic takeaway is that most jobs and businesses are terrible for society and badly organised and run. If a manager (investor / producer) wants to hire for that they need to pay well to herd cats If they instead organise things well, and even have a glorious vision then cats herd themselves. Why is Tesla doing so well? Why was Facebook or Google great places to work? But honestly, most businesses can be achieved without management taking over. A business is either within the phase space of engineering possibility or or is not - the electric vehicle was there and was so well recognised that Tesla actually got given grants by govenment to build it - a government department recognised what car manufacturers refused to see. One could imagine hundreds of engineers coming together without management to build that on some kickstarter like site. My view is leadership is the least important part of a successful business and "management" is the least important part of leadership. edit: i may be overly cynical and i really need to write up my thoughts more coherently
ano88888 5y ago
It is true but just like others said, if you don't have ambitions, the junior developer you train will quickly become you boss, have more pay and manage what you do or can't do (and possibly have the power to fire you too).
register 5y ago
I do not agree. In most of the cases a manager sits in the right meeting at the right place and right moment where a critical decision has to be taken. Those moments are often the ones that will determine how a project will go. Having management skills and being able to understand the big picture from a technical perspective makes all the difference in such situations. While it's true that the set of skills are orthogonal I strongly believe that a "technical manager" , other skills being equals, will in average be able to produce better results over non technical managers. I am working in enterprise IT and I have seen many instances of "non technical managers" taking wrong decisions at the right moment just because of a lack of understanding of the possible consequences. Good technical managers are however quite rare because they need to combine two skill sets that are already rare alone. I believe that this is the reason why companies look just for "pure managers": for me it's more a matter of convenience rather than one of performance.
- temac 5y ago
  I kind of agree with you, but the problem is that "management" is often (very) poorly defined. Is it people or project management? It is often implicitly the two without much rational. Even considering project management the style can vary greatly between somebody concentrating on filling various spreasheets vs somebody pressuring others all the time about deadline vs somebody wanting to ensure engineering is performed and not just mere coding vs somebody having broad picture ideas for future dev. It makes sense to have "managers" in fast foods. It's way harder to even just define the role in an environment where everybody is a knowledge worker. Maybe we should even stop using that term and stick with more precise role descriptions.
  - epicureanideal 5y ago
    I agree that some titles could be changed not to have manager in the title and be a role instead. For example: Product manager -> product designer But what about the people who decide salaries, promotions, hiring, and reviews? Part of the role is “project coordinator” and another part is “staffing and compensation”. Is there an alternative title for that?
mgaunard 5y ago
I don't quite agree. Managers will be the ones assessing the devs and making all sorts of decisions as to the overarching architecture or the software development process. Having a mediocre developer in that position will lead to all sorts of problems.
- isbvhodnvemrwvn 5y ago
  You assume this is the case everywhere, in many organization managing people and managing technology are separate jobs. Managers have no say in how the architecture looks like, and very little to do with how SDLC looks like (outside maybe getting rid of organizational impediments or suggesting some other approaches to planning)
  - mgaunard 5y ago
    Technology is actually made by people (who would have thought!) So managing technology means managing people.
    - isbvhodnvemrwvn 5y ago
      There's a fair bit of difference between being a line manager and a tech lead. You do have a noticeably different dynamic.
      - mgaunard 5y ago
        In many organizations the line manager is the tech lead (at least at the lower levels of the hierarchy). Having a separate leader and manager is only useful if you aim to create a barrier between technology and the business, which is typically not a very healthy thing if you're a technology-driven company. Nevertheless it's a common practice in places where technology is just a supplier servicing the business. And a tech lead is very much about directing people. You need to have a vision, inspire them, make sure everybody is making progress towards the goal etc. It's hands on and operational, but that's where collaboration between people is most important.
ren_engineer 5y ago
I'd compare it to sports, there's a bit of skill overlap between playing ability and coaching but not much. The majority of great coaches were fairly average players, the majority of great players fail as coaches. Same for being an engineer manager and individual contributor, tons of great programmers are horrible managers and vice versa The key to a successful business is aligning incentives, make it so each skillset is rewarded properly for their contribution. Obviously a tough task. Most fail and great engineers have to become managers to make more money and it hurts both parties
62951413 5y ago
The most talented developers I have seen were highly-introverted intense guys. You know the type, it's like most of us only on steroids. They could probably be great architects but that role doesn't seem to exist anymore and wouldn't be on the managerial track anyway. As a side-note, I have no idea why we have "managers" in large companies. I see more and more that a "team lead" is just another developer who has to deal with spring planning and work assignment without much/any difference in compensation. A team "manager" doesn't touch/see any code at all and never impresses me with his technical insights. So other than hiring/firing and 1-on-1s I cannot see them doing anything which would justify the prestige and benefits.
- isbvhodnvemrwvn 5y ago
  Project management is quite often a major task of the team managers, especially if they span across multiple teams. You need to budget for the teams, arrange for the work to be roughly scoped further in the future than one or two sprints. You also need to balance things if e.g. new people are hired, or teams are split etc. You are not an individual contributor anymore. Of course you can have the team lead do that, but they will quit in a month because they no longer have any time to write code or spend with the team.
flashgordon 5y ago
So I have seen another slightly different angle to this (and this applied to me). As companies get bigger org boundaries are a real thing. Engineers who prefer breadth (I contributing across the stack and boundaries) are stymied. And making this kind of impact is really hard unless you have a high enough title but getting there needs a lot of political maneuvering. For these engineers who are more driven by building vs impact management starts to look appealing as side projects may start offering more excitement and challenges than yet another crud service.

SnaKeZ 5y ago

https://en.wikipedia.org/wiki/Peter_principle https://en.wikipedia.org/wiki/Peter_principle

Spooky23 5y ago

It may be harmful for the industry but good for the individual. Becoming a specialist is very dangerous, as your future is tied to a product, and the products don’t love you back. Make the wrong choice and you’re managing a Starbucks.

JakeAl 5y ago
Nope. Starbucks won't hire you without restaurant management experience. You'd be lucky if they hired you as a barista.
- akomtu 5y ago
  Without coffee making experience you'd be lucky to get a toilet cleaning job at Starbucks.

dexen 5y ago

>While there is some overlap between a manager and software dev they are in the end two fundamental different jobs. I used to think that early on in my career as developer. At this point I believe those two are fundamentally the same jobs: gathering, processing and transforming requirements from one form & language to another.

nix23 5y ago

Exactly, it's like saying talented artist end up becoming Museum Managers.

robofanatic 5y ago
very very few developers do the kind of work that can be compared to a talented artist.
- nix23 5y ago
  Talented developers.....it was a example, is it hurting your feelings?

Gtex555 5y ago

the program coming when someone who makes less money than you is managing you , doesnt really work. So managing is like a reward.

marcinzm 5y ago
Just have your staff+ engineers report into directors and VPs rather than line level managers.
- kcplate 5y ago
  You need a line level manager to insulate the suits from developer lunacy.
  - betaby 5y ago
    More other way around
    - marcinzm 5y ago
      There's a reason good line level managers get called shit umbrellas for the team.
    - kcplate 5y ago
      Been on both sides of that line, in my experience there is FAR more lunacy among the development folks. But to your point, the lunatics always feel like they are the “normal ones”
      - playing_colours 5y ago
        It is often expected to be defined in the expectations towards engineers at Staff+ level that people on that level are good at communications and can balance technical and business points of view. Also, developers are often not skilled enough to hide their “lunacy” and they are sincerely open about it. Managers are more skilful at hiding malice, incompetence, pure wish for power, that makes them more harmful for a company.

bjornsing 5y ago

This line of reasoning is popular, but it lacks one perspective: people are social animals and many instinctively want to climb hierarchies. If you promote junior software engineers into management based on interest then a lot of junior hires will start manoeuvring for that, instead of trying to get good at their trade and proving themselves that way. I’ve worked in big companies with the philosophy you’re advocating, and my impression is that they turn very political and lose focus on the day to day engineering work. In the extreme the engineering work even turns into something “dirty” that you should know as little as possible about, because that’s the way to be promoted into higher paying / higher status roles. When 10-20% go around “virtue signaling” their ignorance it quickly destroys the culture.

dathinab 5y ago
> instinctively want to climb hierarchies But that also means you still see managers "a top" of engineers (a "better" job). But just because you are managing a project shouldn't mean you stand above all the people in the project. Like e.g. a trainer in football/soccer might direct the Team but the highly experienced players in the Team are, while directed by the trainer, not in a social hierarchy below the trainer. Because most times they stay when the trainer gets fired and they might get the trainer fired too if they believe the trainer is incompetent. So in the end the problem just again boils down to seeing being a manager as a advancement of your carrier but becoming a senior engineer just as a continuation/negligible advancement.(1) (1): assuming proper standards for senior engines, I have seen many people in senior engineer positions which do not have the skills to call them senior engineer IMHO.
- bjornsing 5y ago
  > But that also means you still see managers "a top" of engineers (a "better" job). No. All that’s required is that 10-20% of individual contributors see it this way. They will start manoeuvring, “virtue signalling” their ignorance, effectively destroying the culture. You don’t see it that way. I don’t see it that way. But they do. That’s enough unfortunately. What you need to break this dynamic is that the opportunity to be a trainer (or at least coach) is a kind of reward for learning to play the game really well. I think that’s how it works e.g. in (European) football as well.

lmilcin 5y ago

(BTW I am 40, have been working as dev for the past 21 years and I am now transitioning to my first non-development role ever after working as tech lead / senior dev for over a decade) > Sure having some understanding of software is helpful as a manager but IMHO this only includes skills up to the "mid"/"just after junior" software dev level. I disagree. There is a lot of useful skills that a developer can pick up usually only after you are very comfortable with the coding and technical problem solving. Ability to improve processes, being able to influence morale of your team, ability to think though a coherent strategy for what you are working on, handling emergencies, preventing emergencies, creating space for your teammembers so that they can thrive, teaching others useful skills, managing up, and so on and so forth. > So if a senior software developer becomes a manager it's wasting their potential as software developer. Sure. But maybe they can now "leverage" (building towards that bullshit bingo card...) their experience in a position that has more impact?

kcplate 5y ago
> For me ability to code (like knowledge of programming language) is a necessary but relatively minor ability of a good software developer. Absolutely. I have been in tech since the eighties and it’s remarkable to me how all the other skills that used to be necessary to create quality systems have seemingly taken a backseat to this skill. There are far to many developers with a severe lack of good engineering and troubleshooting capabilities nowadays…but boy are they fluent in the language de jour
- bboylen 5y ago
  What is the best way to develop engineering & troubleshooting capabilities? Definitely seems a lot less clear cut than just practicing a language
  - kcplate 5y ago
    I think to a certain degree it’s just an innate capacity for creativity coupled with logic that gets refined in practice. If you don’t have those core components in you you are pretty much at a disadvantage to develop them. To be honest in the last 10-15 years with the shift to Agile it really feels like the type of folks who become software devs prior to that shift represent about 15-20% of the new devs now. The rest are kind of just commodity devs. Give them good detailed requirements and they can churn out code. That 15-20% are the ones who can churn out something without a hyper level of detail or refined requirements.

davnicwil 5y ago

> this only includes skills up to the "mid"/"just after junior" software dev level Not so sure about this. Usually part of the responsiblity of managers in software is making or at least guiding those making the bigger techincal calls that have long term and broad scope impact. These decisons typically benefit from a pretty decent assessment of technical risk, which derives from both a good first principles understanding of a proposal, and probably moreso, lots of first-hand experience of similar things going wrong and right. It's not a coincidence that top level tech management at most big successful software companies have deep technical skills and backgrounds.

tkiolp4 5y ago
Is that true? In the companies I have worked for, the technical risk assessment and everything related to “is this a viable tech solution” is done by senior engineers. Managers barely limit themselves to agree with what senior engineers say.
- Mezzie 5y ago
  Yes, it is. A lot of companies run like you've seen, but that's not how it should be. For instance, if I have to talk to tech people about that aspect of a project I'm working on, if we're talking about technical risk, I should have some different perspectives from a senior engineer that will influence our back and forth. For example, it's common for engineers to switch jobs every year or two and knowing that means I would know to ask questions specifically about what our tech risk would look like if we don't update the stack/tools for the next five years (say if I know the exec team won't fund upgrades or the non-technical parts of the organization are resistant to change). Or if we'd be able to hire engineers to maintain whatever product in 3 years: Is it being taught? Are there enough engineers on the market with this expertise that we could replace someone if necessary? Can we AFFORD to? (Will the execs/HR pay for the expertise if it's a rare skillset?) Etc. And I wouldn't consider myself qualified to manage a team of engineers; I'd expect more skills and insight from people who are genuinely qualified.
  - isbvhodnvemrwvn 5y ago

lifeisstillgood 5y ago

I am very very negative on "management" as a skill in the software world. There are a few key outcomes needed 1. staff work 2. Policy decisions 3. resource allocation 1. is working out how the various pieces will collide (ie how long it will take to march x thousand people through various roads as a good example of army staff work). This is absolutely a job to be replaced with software. Then all that's left is the trade off in options otherwise known as 2. policy decisions. And this includes making policy on the hoof. That's fine but I think companies are going to become more democratic and much more obvious what policy decisions are being made and when - and that will take oversight 3. resource allocation. Where to spend the budget? And again this is mostly about staff work and policy So i think the staff work (the helicopter view) will get commoditised, the policy decisions constantly reviewed and eventually replaced with democracy and frankly that's it. What we will need is lots of administrators .. oh not that will be replaced with software ...

senko 5y ago
You forgot herding cats. Good luck automating that.
- lifeisstillgood 5y ago
  Cats respond to incentives. You only herd them when you want them to do something they do not understand or are not incentivised to do
  - sdenton4 5y ago
    Cats often value their autonomy and sense of mystery over any particular incentive one can offer. Source: Currently trying to train a literal cat. And am a figurative cat myself.
    - lifeisstillgood 5y ago
      You are probably easier to train than your cat! My basic takeaway is that most jobs and businesses are terrible for society and badly organised and run. If a manager (investor / producer) wants to hire for that they need to pay well to herd cats If they instead organise things well, and even have a glorious vision then cats herd themselves. Why is Tesla doing so well? Why was Facebook or Google great places to work? But honestly, most businesses can be achieved without management taking over. A business is either within the phase space of engineering possibility or or is not - the electric vehicle was there and was so well recognised that Tesla actually got given grants by govenment to build it - a government department recognised what car manufacturers refused to see. One could imagine hundreds of engineers coming together without management to build that on some kickstarter like site. My view is leadership is the least important part of a successful business and "management" is the least important part of leadership. edit: i may be overly cynical and i really need to write up my thoughts more coherently

ano88888 5y ago

It is true but just like others said, if you don't have ambitions, the junior developer you train will quickly become you boss, have more pay and manage what you do or can't do (and possibly have the power to fire you too).

I do not agree. In most of the cases a manager sits in the right meeting at the right place and right moment where a critical decision has to be taken. Those moments are often the ones that will determine how a project will go. Having management skills and being able to understand the big picture from a technical perspective makes all the difference in such situations. While it's true that the set of skills are orthogonal I strongly believe that a "technical manager" , other skills being equals, will in average be able to produce better results over non technical managers. I am working in enterprise IT and I have seen many instances of "non technical managers" taking wrong decisions at the right moment just because of a lack of understanding of the possible consequences. Good technical managers are however quite rare because they need to combine two skill sets that are already rare alone. I believe that this is the reason why companies look just for "pure managers": for me it's more a matter of convenience rather than one of performance.

temac 5y ago
I kind of agree with you, but the problem is that "management" is often (very) poorly defined. Is it people or project management? It is often implicitly the two without much rational. Even considering project management the style can vary greatly between somebody concentrating on filling various spreasheets vs somebody pressuring others all the time about deadline vs somebody wanting to ensure engineering is performed and not just mere coding vs somebody having broad picture ideas for future dev. It makes sense to have "managers" in fast foods. It's way harder to even just define the role in an environment where everybody is a knowledge worker. Maybe we should even stop using that term and stick with more precise role descriptions.
- epicureanideal 5y ago
  I agree that some titles could be changed not to have manager in the title and be a role instead. For example: Product manager -> product designer But what about the people who decide salaries, promotions, hiring, and reviews? Part of the role is “project coordinator” and another part is “staffing and compensation”. Is there an alternative title for that?

mgaunard 5y ago

I don't quite agree. Managers will be the ones assessing the devs and making all sorts of decisions as to the overarching architecture or the software development process. Having a mediocre developer in that position will lead to all sorts of problems.

isbvhodnvemrwvn 5y ago
You assume this is the case everywhere, in many organization managing people and managing technology are separate jobs. Managers have no say in how the architecture looks like, and very little to do with how SDLC looks like (outside maybe getting rid of organizational impediments or suggesting some other approaches to planning)
- mgaunard 5y ago
  Technology is actually made by people (who would have thought!) So managing technology means managing people.
  - isbvhodnvemrwvn 5y ago
    There's a fair bit of difference between being a line manager and a tech lead. You do have a noticeably different dynamic.
    - mgaunard 5y ago
      In many organizations the line manager is the tech lead (at least at the lower levels of the hierarchy). Having a separate leader and manager is only useful if you aim to create a barrier between technology and the business, which is typically not a very healthy thing if you're a technology-driven company. Nevertheless it's a common practice in places where technology is just a supplier servicing the business. And a tech lead is very much about directing people. You need to have a vision, inspire them, make sure everybody is making progress towards the goal etc. It's hands on and operational, but that's where collaboration between people is most important.

ren_engineer 5y ago

I'd compare it to sports, there's a bit of skill overlap between playing ability and coaching but not much. The majority of great coaches were fairly average players, the majority of great players fail as coaches. Same for being an engineer manager and individual contributor, tons of great programmers are horrible managers and vice versa The key to a successful business is aligning incentives, make it so each skillset is rewarded properly for their contribution. Obviously a tough task. Most fail and great engineers have to become managers to make more money and it hurts both parties

62951413 5y ago

The most talented developers I have seen were highly-introverted intense guys. You know the type, it's like most of us only on steroids. They could probably be great architects but that role doesn't seem to exist anymore and wouldn't be on the managerial track anyway. As a side-note, I have no idea why we have "managers" in large companies. I see more and more that a "team lead" is just another developer who has to deal with spring planning and work assignment without much/any difference in compensation. A team "manager" doesn't touch/see any code at all and never impresses me with his technical insights. So other than hiring/firing and 1-on-1s I cannot see them doing anything which would justify the prestige and benefits.

isbvhodnvemrwvn 5y ago
Project management is quite often a major task of the team managers, especially if they span across multiple teams. You need to budget for the teams, arrange for the work to be roughly scoped further in the future than one or two sprints. You also need to balance things if e.g. new people are hired, or teams are split etc. You are not an individual contributor anymore. Of course you can have the team lead do that, but they will quit in a month because they no longer have any time to write code or spend with the team.

flashgordon 5y ago

So I have seen another slightly different angle to this (and this applied to me). As companies get bigger org boundaries are a real thing. Engineers who prefer breadth (I contributing across the stack and boundaries) are stymied. And making this kind of impact is really hard unless you have a high enough title but getting there needs a lot of political maneuvering. For these engineers who are more driven by building vs impact management starts to look appealing as side projects may start offering more excitement and challenges than yet another crud service.