If you want to go into management, then why do you waste 10+ years going from junior to senior to principal and so on until you finally get to manage your first small team? The people who went for management from the start would be way ahead of you then, no?
Some of the better managers I’ve seen had no background whatsoever in the field they were managing. But they were great at listening, working with people, managing conflicting interests, and taking decisions after consideration of relevant input
if manager knows how to code he will try code using your hands. aka micromanaging. you will get comments like "well just add an 'IF' here and case closed". you don't want manager like this.
Indeed. Also, you have plenty of time do to both. Start as an engineer at 22, write code for 15 years. Switch to management at 37. That still leaves you with 15+ years to climb the career ladder.
So am I guaranteed to fail at developing a platform for selling used cars if I have never worked as a used car salesman and have no idea how they work? Of course not, I am supposed to acquire the necessary understanding by talking to users and subject matter experts. I think the same holds for managers, you can understand and manage a software development process without having been a developer. Does experience help, could former used car salesman develop the platform better, could former developers manage the team better? Sure, but only if they are also good in their current role, if they are good developers or a good manager. And being good in your current role comes first, having experience in the field you are writing software for or that you are managing is an added bonus.
That's only the case if the manager meddles in technology and doesn't know how to delegate properly (or hire properly). I would say a manager who does those things is inherently a manager who can't scale and is unlikely to ever work well with senior technical people.
As a manager my goal is to use as little of my technical knowledge as possible but rather to let my senior technical leaders do that part instead. I've got so many other things to handle and deal with that being technical except at a high level seems silly.
- Helping figure out the right goals and metrics for the team and ensuring everyone is on the same page.
- Holding 1-on-1s with team members, non-technical feedback and yearly reviews. Seriously, yearly reviews are a massive time sink if you actually care and spend time on them.
- Passing around information to the team and making sure they are involved in the right meeting/conversations.
- Attending various management meetings that usually could be replaced with a wiki page.
- Resolving non-technical issues my team members are having. This includes listening to venting sessions, complaints and general bitching. Need to handle these situations in a diplomatic non-judgemental way.
- Keep track of team non-technical blockers (people, process, etc.) and try to resolve them (short or long term). This includes resolving product management issues and other teams blocking my team.
- Keeping stakeholders close and happy
- Selling the team, it's vision and achievements broadly
- Hiring
- Planning team promotions and executing on those plans. This includes telling your team members what they need to do to get promoted and then ensuring those promotions happen.
- Non-toxic (or toxic depending on the company) politics
- Talking to random people in the company for networking. It's amazing how much people from HR will tell you if you are friendly and get coffee with them.
I am and like I said I'm actively trying to not leverage that skillset. I'm not in the weeds anymore and I cannot be due to the other things I'm responsible for. Someone making technical decisions who used to be an expert, isn't an expert anymore but can override decisions is a horrible mix.
I still don't buy this. You talk about scaling the team: how can a manager says to HR "I need N new hires in 2022 because we have projects X Y and Z" if you don't have the technical knowledge and experience to know how complicated those projects can be? How are you going to protect your team from extra work or starting a stupid project if you cannot recognize it? Those are tech skills and a good manager must have them.
I'm very confused, is your team made of nothing but juniors? Or are senior engineers not trusted at all? I simply ask my tech leads and senior engineers to give me an estimate. Then I trust them.
In my experience engineers hate it when an out of touch manager makes an estimate on their behalf and then they are forced to do crunch time to meet it.
edit: Also most projects come via the PM who would coordinate with the tech leads directly for planning and scoping.
Obviously you ask the team but many times you might be in some meeting and it's just you because you don't want to drag an engineer in yet another meeting... isn't what they all hate? I don't really see technical knowledge in an engineering manager as a bad thing, really.
There should be a process for project planning other than "a manager was in a meeting and agreed to it." That process should not require people to show up in meetings.
This brings up my overall view that being technical can often make a manager take short term shortcuts. That works right until it no longer does and then you have a broken team and culture and processes. Not thinking technically means you are forced to implement good long term processes and not keep monkey patching things. For example, if the managers keeps making these decisions in meetings then senior engineers will wonder how they can have their voice heard except by going into management.
There’s exceptions to any rule. So far working for nontechnical managers has been invariably exhausting. I don’t doubt that managers exist where this isn’t true.
Even if they trust me to provide them with estimates (and they understand that 9 women cannot have a baby in a month). I have to spend a lot of time just constantly communicating the information they need, and why certain things need to happen so they can tell (and satisfy) their stakeholders.
In most places I've seen it's the non-technical PMs that deal with stakeholders so having a technical manager doesn't help that much except as an escalation point. And more broadly I feel if you're having to explain technical information to stakeholders then you've failed in much deeper ways. The person handling them should have built a good reputation of trust and provided good communication on what stakeholders really value. Very rarely have I seen them to really value technical details but rather ask for them when they simply don't trust the team anymore.
If your technical knowledge is 20 years out of date, as an individual contributor you can't be hired although worst case you can't do much damage. On the other hand if your technical knowledge is 20 years out of date, then its much safer for the company to put you in charge of direction and goal setting and hiring decisions and so forth.
A Visual Basic 6 programmer "can't" be hired to program in Javascript, although its the same people and skills 25 years apart. However put that VB6 programmer in a management role and somehow that completely obsolete technical skillset is "invaluable", LOL.
Yes, because from a business standpoint, you should care where your product is going to be after 20 years, and the VB6 programmer knows that eventually JS might not be a thing and will think of architecture decisions like 'we'll have to transition this to another language, how should we make that process easier?'
Likewise, some lessons transfer. "Huh, that time we were working on Thing X and relying solely on Bob's technological expertise we were completely screwed and the company went under after after Bob had an aneurysm, I should make sure there are no single points of failure on the team knowledge wise."
Or "Man, we built such a beautiful Visual Basic 6 program, but the interface was so bad nobody used it and we failed. Let's make sure our front end and back end people are communicating properly." Or, "This was the most elegant technical solution, but then it turned out nobody had the resources to run it. So let's make sure to do our user testing and make sure we're designing appropriately."
I work in Google and have seen distinguished engineers switch to management. They typically get a small number of direct reports, all of them directors.
Don't know about pilots, but I'd think doctors and actors are near the extreme ends of the age discrimination spectrum. Ie. being an old doctor makes you credible, being an old actor (or especially actress) severely impinges on your options and expectations. Being an old developer is probably somewhere in between.
Unfortunately in many places of the US this is starting to change. Companies like Advent Health (used to be Florida Hospital) have been seizing control of medical practices from the doctors.
The common scheme is to offer logistical support (dealing with paperwork, IT, etc) in exchange for joining under their umbrella (with the implicit or sometimes not so implicit promise that otherwise they exert no influence over the operation of the practice). Then after a few months to a year they start making sweeping changes restricting what patients the doctor is allowed to see, what treatments they are allowed to provide or suggest, how much they can charge, and where they are allowed to see or treat their patients. Essentially resting any autonomy the doctors had over their practice.
This is what happened to our PCP and many other doctors in Florida. They were given an ultimatum and any patients who didn't fit the profile Advent had selected for them were forced to leave them for some other doctor.
Nowadays the only doctors with any "real" autonomy are surgeons and even then the actual autonomy they have is being increasingly encroached upon.
I'm not sure how common this is in other regions but at least in Florida it is becoming increasingly difficult to find Doctors who haven't been effectively tricked into forfeiting control of their practices and reduced to employees for large corporations.
Pilots retire at the mandatory retirement age of 65, which a friend of mine will do next year. He'd rather keep flying and I imagine his employer would prefer that too, given the pilot shortage. But he will also admit that the job his harder on him now than it was when he was 25, so the rule arguably makes sense.
In my experience (from Europe), contractors are more of a lackeys, because they are worried about their contracts extensions. So, in practice, they try much harder. The only good part about being a contractor (except the usually much larger pay) is the fact that you're invisible to HR and their games. No yearly reviews, no development plans, no promotions - you just negotiate your rate with your hiring manager without all the charades.
I do not recognize your parents experience in the EU, but yes, here employees are very protected while contractors are not. Still, outside the certainly of employment, even in the EU, I know only positives when contracting. Things like tax and insurance optimizing you cannot really do as employee and now with WFH, it is possible to optimize even more. And if you have a trackrecord, it is easy to get other projects. Note: I am getting close to 50y/old.
Edit; another thing which you can do as contractor and typically not as employee, is take retainers. When a project is done and the company does not need me anymore, they can retain me for n hours per months that I will spend on that project no matter what else I am doing; and they pay no matter if they use the hours or not. Similar is, and I have done that too, an SLA on the project you helped deliver. But that is far more dangerous as others might have continued working on it, so I don't do that anymore.
I dont (try much harder) :) and as you said, i keep bumping the rates after some time and work is done and customers are happy. No agile meetings (those extras that are not really in agile apirit, but managers think they are :D). I get to work on what i wqnt and when i want. Its fun, but as dev you should be full stack for it or have someone ready to come in when you hit the wall while configuring servers or needing to use some tech that you'd need to learn and its no time/place for learning.
Perhaps you don't notice how little the full-time people are trying :) It's not hard to try harder than them.
BTW now I'm curious. It sounds to me like you're talking about very different contracting that I am? I have never seen a larger company allow contractors to skip the agile ceremonies. They're always treated exactly as an employee in this regard - they're basically "temporary" augmentation of the staff, because company is not able to hire enough permanent people. (BTW this "permanent" state usually extends into years of staying at that company). Is this the kind of contracting you do, or do you do something else?
This sounds like basically just having an employee but with different legal standing as a loophole or something.
Contracting is completely different, you generally define a set project to complete, do it, and get out.
In the UK there's something valled IR35 which means that in order for you to be considered an independent entity for tax purposes you should have full control over working hours, practices, etc.
Is the IR35 really having the intended effect? I've contracted in the UK pre-IR35, and I was essentially just an employee who paid much lower taxes (and was easier to fire, didn't have paid vacation etc.). I've met lots of people who contracted exactly the same way. Is it really different now?
In the UK, and I think the rest of Europe, things like tax have recently been changing to strongly discourage this. Contractors now have to be hired for specific projects with identified goals and deliverables or the whole thing starts to get unattractive expensive.
Of course, it's all paperwork that can be bullshitted, but it's had at least some effect in my experience.
Who hires such contractors? All the major companies have their own tech departments and write software in-house (or outsource it whole-sale to giants like TCS). That mostly leaves smaller non-tech companies. Do they have the money to pay a competitive rate?
Locksmiths make a couple hundred dollars per job at most. Software engineers make tens of thousands for basic jobs, and hundreds of thousands for more ambitious things. It's not really comparable. Even $50k is not an insignificant amount for a small-to-medium company.
Ive done quite a bit of years in agile and full time office jobds so i've seen some terrible things from full time people (i even got some of them fired because they were straight off *ucking their employers) :) so its a matter of choices and what you want to do, if youre a fordism believer then go ahead and sweat it out. Im on permanent contracts with companies/customers in both Europe and US. Is it so hard to believe that someone is "the captain" of their own ship? Or that you dont need tye sillt standup in the morning if people actually know what theyre doing and delivering great results? I do love to fire customers that are cheap or stresfull or require more than what they want to pay for. Im hiring ppl as well and i dont require from them that, and they deliver 100%. Some times giving ppl more freedom to arrange their work time and life as they want gives you their trust and grattitude and you dont need to worry about keeping them on x to x hour leash.
Btw. Your contract will be as you make it and as your customer sign it. Thats it. Theres no point in labelling contract is this or that. Its unique per situation.
Not OP and anecdata but our CTO is in his 60s and contributes a lot of code to a fairly modern stack, he doesn’t appear to have any trouble keeping up.
And irrelevant to the conversation unless managers are better protected for cognitive loss (I doubt it) or managers requires less cognitive load (I doubt that too, but you can make a joke about that :)
It's none obvious that various cognitive skills (and the amount of energy/motivations) decline at the same rates and that managing and programming requires the same skills.
People taking offense at this and kneejerk downvoting (or making ridiculous "NO U" comments): chill the fuck out. It's just a question. This is a legitimate thing to discuss.
I feel that my cognitive peak is already way behind me and I'm 35. 25 felt like my golden age of creativity and cognitive performance: no longer the erratic bullshit of the coming of age teenage years, no responsibilities, a job with loads of freedom. Such a contrast from my life now at 35 with kids, where I still love my job but must actively pace my expenditure of mental capacity to avoid crash and burn.
I want to hear from people how they feel cognitively in their 60s. How is it when kids leave home? How is it when you trade agility for experience? I want to know what it's like, as it is inevitable and real, in my own experience, to lose brain power as I age.
In today’s software industry, I’ve found that older technical specialists aren’t particularly welcomed; regardless of their ability or skills. Just being older is enough. If they have a significant reputation, or long-term employment at a single place, prospects are better.
I was a manager, in addition to being a technical specialist, for a long time. It was a fairly small, highly-skilled team. As time went on, my management duties replaced my technical ones, and I was forced to do technical work on the side (open source work), in order to maintain my technical edge. This resulted in my having a fairly significant technical portfolio, by the time I left my job.
I have encountered very few good managers, in my career. I have seen some great technicians destroyed by becoming managers.
I think the industry’s refusal to cultivate lifetime technical careers has resulted in a lot of problems, but it is not anything that has been studied, in any meaningful way (of which I’m aware). I only have personal anecdata, which, by itself, isn’t particularly relevant, in the big picture.
At a certain point, more experience does not make them more effective developers.
If they want to justify higher salaries, but can not be more effective on their own, they need to multiply their experience by making other developers more effective.
The organizational problem is that most companies see management as the only way to do that, but not everyone can and likes to be a manager.
We as developers have to make sure we promote mentoring, tool and framework building, system architecture and such topics as viable paths upward. Otherwise, managers will only have managing as an idea of how someone can create more value.
I took an alternative approach, I was living in london, so I moved to Portugal.
a remote London Dev contracting, and the wage is more than enough over here
Last night, I had dinner with a friend of mine, who is a former Marine. He told me that the "best of the best" become DIs (Drill Instructors). He had tremendous respect for his DIs, and described them as "almost superhuman."
DIs are always noncoms, but tend to be highly experienced. They are also good trainers. Being a good trainer is a fairly specialized skillset, and many techs aren't able to adapt to that, either.
In my case, money has never been the point. I'm a high school dropout, with a GED, and never really got paid as much as even many entry-level kids are, these days. Nonetheless, I lived frugally and sensibly, and have been able to survive being tossed out into the trash. Many of my peers do not have that capability.
I agree with one caveat: the degree to which more experience means more productive depends to a large extent on two factors:
1) The experience.
2) The job.
Having 10 years hacking on one system probably won't make you anymore productive than 3. At that point you're a factory worker, and you can't only put so much expertise into flipping a few switches and following traces.
However, having 20 years of diverse technical experience will make you more productive than 15 if the job requires the breadth you've developed.
I'm 12 years in and have moved into Startups for just that reason. You get to learn more numerous things, and you get to use all of them. I've been at my current job 6 months and I've worked with 4 languages, more libraries than I can count, 2 third parties, blah blah blah. If I went back in time even 3 years of experience, I would definitely be less effective. If I went back 5, I'd be struggling.
This ignore the immense amount of overlap various systems have, and the benefits of cross-pollination you get from the parts that don't. Even if you work on a completely different system every year, by that tenth year, you'll be up and running faster, and probably have something to teach the people who've been working on that system longer than you.
I work for a small company, and one of the things I enjoy is we're always spinning up new ideas to see if they work. We tend to spend half time on new stuff and half time on maintenance.
This has given me a lot of exposure to different things over the years. It's mostly web stuff, but one of the more interesting ones was interfacing with hardware for a warehouse app that we built to make the shipping process less error prone and more efficient.
In the early years of my career I was the hot-shot developer that outproduced everyone. It was fun, but ultimately unrewarding. Some people don't mind but most people dislike others who are conspicuously better/faster than them. In a "team sport" like development, this was a bad strategy.
Now the analogy I like to use is a rising tide raises all ships. Instead of being the individual hot-shot I do everything I can to make everyone else a hot-shot. If they are talking in a meeting and I think a nudge needs to be made, I just 1:1 message them with a tip and then let them say it instead of speaking up. I do more training of juniors and even seniors, teaching devs how to think through complex problems. Now my teams are more productive, most of the people like me and want to be working with me, and my income has skyrocketed as a result. Of course, I did have to escape from traditional office hierarchies and go into consulting to really increase the $.
I wonder if the lack of cultivation is partially due to mismatched incentives: It's often impossible to be a successful manager without embedding yourself in a particular social network and organizational culture; making management the 'reward' for a good developer means that the good developers can be, for lack of a better term, brainwashed into corporate culture.
Older and more experienced technical specialists are more of a threat. Cultivating those people would mean giving them mentorship and resources, and older tech specialists are the population that's most likely to be a.) able to leave/have transferrable skills/not be as reliant on the companies as the managers, b.) old enough to stand up for their juniors - can't have someone on the team telling them NOT to work 14 hour days/killing themselves grinding to work at FAANG, and c.) they're most likely to have the organizational and long-term thinking/architectural skills to compete.
Cultivating older technical specialists could be seen, by tech execs, as training in and investing in their own competition.
The team that I ran was composed of experienced C++ developers, working on image processing pipeline stuff (propellor-beanie territory). They also weren't being paid particularly well, compared to what they could have gotten at other places.
As a manager, it was my job to retain them; which I did -quite well. I did this via a combination of maintaining my own technical prowess (on my own time, as my company was no support at all on this), empowering my employees, staying out of their hair, learning the individual drivers of each of my team members, not nickle-and-dimeing them, supporting their training and personal/career development, and not playing political games. I never lied to them, and used carrots far more often than sticks. I also -very importantly- shielded them from a rather rapacious HR department, and terrible upper-level management.
I didn't give a damn about whether or not they wanted to replace me (I don't think it ever crossed their minds).
Basically, I became the manager that I always wished I had.
The "talent" we need is definitely not technical. Software projects are a magnitude more about "people" and "negotiation" than it is "how do do this technical widget efficiently" and "how can we make this arch scale" (these are all relatively solved problems, despite us trying to reinvent the wheel). Even projects that fail due to, on the surface, technical problems are actually a result of people and leadership, and the effect they have on the project.
This is the part that I think a lot of technical people really misunderstand, hence all the negative sentiment about turning developers into managers. A stellar incredible "10x" team of super talented developers can not negate the bad people dynamics within a project caused by bad leadership or lack thereof.
> Software projects are a magnitude more about "people" and "negotiation" than it is "how do do this technical widget efficiently" and "how can we make this arch scale" (these are all relatively solved problems, despite us trying to reinvent the wheel). Even projects that fail due to, on the surface, technical problems are actually a result of people and leadership, and the effect they have on the project.
If you think the current crop of managers are doing all this, I am afraid you are mistaken.
And how long does that domain knowlege survive as technology moves on, and the manager isn't getting hands on. You could have great domain knowlege when you move into management age 35, back in say 2010, and just 10 years later you'd have very little hands on knowlege of say AWS. Go back 10 years further and while you might be a whiz at building win32 programs in 2000 when you were 35, how do those skills apply in 2010 let alone 2020 when you're 55.
Being on the move is part of the skill. I expect a good developer to be effective in a ew tech faster than a younger one barely knowing one tech. I think THAT is part of the appeal of a senior+ dev, having proven they will be able to adapt to the new framework or the next pivot.
I believe one of the major skills a senior+ dev has to have is to see through the marketing and impl. detail fluff and instead understand the underlying concepts and which aspects a specific implementation has wrt. the underlying concepts.
While frameworks and libraries change all the time, the concepts do not.
At some point, languages and frameworks become as interchangeable as different brands of tools. Sure, you can have a favorite brand with strengths and weaknesses, but someone who's used one powered screwdriver or handheld sander can pick up any other one quickly, and it's actually possible to reach that point with code.
Yup. If you know how to think like a coder, you can keep picking things up. I've been coding for 28 years and I've dipped in and out over the years. I keep abreast of things enough to know where to find the most up to date information and how I would learn it if I need or want to.
I'd compare it to using Wikipedia/web search for basic facts. Even if you don't know the capital of Morocco off the top of your head, you know how to answer that question.
Human languages are similar: I've studied six + have a Linguistics degree, and even languages in families I've never studied before are a lot easier for me to pick up than somebody who's only studied 1 non-native language.
This person is qualified for the job, and does it. Stays prepped for interviews and moves companies/roles as needed to maximize income/happiness. This person does a job, somewhat acceptably, acceptable to the company that demands acceptable work and acceptable to a life that demands acceptable upkeep (bills and shit).
So if you find yourself unable to become a manager, luckily for you, you can still do your job (boo hoo).
> 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.
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.
Yes let’s fire all management. Remove all that harm from the organization and put a bunch of lunatics in charge who all believe without a shred of doubt that they are the smartest person to ever walk the earth.
I did not suggest to replace managers with engineers, just give an opportunity to work and be represented on more strategic level to some engineers. It can be seen as a good career progression for ICs.
There is always an assumption by engineers (especially folks early in their careers) that management is somehow “easier” and therefore it’s an easy and a reasonable career path for folks in engineering to have available to them should they choose it. It’s not easier, it’s simply different, and in many ways much more difficult. I have seen a lot of folks try and make the transition and ultimately either fail or spend a lot of time as terrible managers until they develop the skills to do it.
Management of technical teams is not a one sided operation, it’s not us vs them. You are beholden to those you manage, as well as your leaders above you (actually, more so). Sometimes the motivations of those two groups can be seen to be in conflict. You have to be an effective advocate for both. The problem I have seen with many engineers who try to make that transition, is that they think they job is to be an advocate for their engineers they manage. They forget the other 50% of their job…which is the 50% that is actually the most important to their livelihood.
> makes less money than you is managing you , doesn't really work
It can, managing is (should be) a collaborative effort. It only is a problem if the manager manages in a non collaborative forceful top down manner.
It's all a question about communication skills.
Like in some sports you will find top players earning multiple times of what their trainer earns, and potentially having enough influence to get their trainer fired. They work together with the trainer for optimal results.
Similar enough wealthy people hire fitness trainer, or people which manage their cullender, schedule, appointments and might even majorly decide career directions. And it still works even through the person in power is the person being managed.
Why? I make less money than every single one of my staff. I’m an EM, I manage 9 engineers, and never once has the fact that they make more money seemed relevant.
_Maybe_ I could change careers and be an engineer and make as much of them, but I wouldn’t want to. I’m a manager because I like being a manager. It’d be a QoL decrease for me to be an engineer just for the money.
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.
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.
> 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.
> But that also means you still see managers "a top" of engineers (a "better" job).
Managers are typically comped better. Usually on a level by level basis, but also in the number of times you can be promoted before you run out of new job titles.
In my (giant) company, it appears there is a bit more room at the top for managers, but in general leveling up is more difficult as there is an expectation that the amount of headcount you manage is commiserate with the level, so the optimal leveling progression appears to stay an engineer for as long as you continue to level up and then switch into management.
You meant "commensurate", of course, but maybe "commiserate" was a Freudian slip? I often look at people managing large groups if people and think, "that looks like (it's often) a miserable job". :)
My company also has a level for level match, except there are far more managers than equivalent high level ICs, and even the generous IC tree ends far sooner than the management one does. If a manager is so inclined one could pursue an executive position, and I’ve never seen an equivalent for IC engineers.
I think there is probably one IC equivalent for every 2-3 low level managers, and $CORP is better about these things than any other company I’ve ever worked for.
I think a lot of success in hierarchies is based around the willingness and ability to turn a screw.
What domain expertise buys you is a higher intuition on whether or not you should.
Sure, you can have a lot of technical managers who suck. You can also have a good experience with a non-technical manager.
But day by day, pound for pound, my money is on domain expertise leading to better results. This happily explains why a manager is typically a senior role.
There's a different perspective, which is that there are different kinds of management. At the very least there's line management, project management, product strategy, business design/strategy, and operational/delivery strategy.
Sales engineers can also have customer/client consulting management roles.
Some companies promote good engineers to R&D and product strategy roles. They're still engineering-led, and not particularly about day to day development issues or longer term - but still very clearly defined - project goals.
Most of what's being described as management really seems to be line management. What you want from management is at least as much of the other types.
Generalists who can invent the future with some accuracy are particularly valuable. Giving them space to pursue that within some very broad strategic goals is far more valuable than "promoting" them to team management.
> There's a different perspective, which is that there are different kinds of management.
I don’t understand why this is a different perspective. The dynamic I’m describing applies if you start promoting junior engineers to these roles as well (based on interest in management and ineptitude in hands-on engineering).
> Generalists who can invent the future with some accuracy are particularly valuable. Giving them space to pursue that within some very broad strategic goals is far more valuable than "promoting" them to team management.
In my experience it’s very hard to invent the future and realise the vision without some sort of formal leadership / management (in the broadest sense) role. (Unless it’s small enough for one or two people to build of course.)
> "This line of reasoning is popular, but it lacks one perspective: people are social animals and many instinctively want to climb hierarchies."
Managing people is a shit job. You spend your time in endless meetings and playing politics. You're tasked with day-to-day HR-related tasks. You need to keep everybody satisfied. Your salary won't necessarily be any higher. You get the blame for stuff. You have to delegate away the fun work. You lose touch and rust faster. If you're lucky, some of the people you work with will actually like you - but if your team doesn't deliver then it doesn't really matter...
What makes any of this sound like you're somehow "climbing"?
The wording is slightly negative, but it does describe that side of the role well.
There are also positive aspects that hang in the balance. Personally (as a people manager) I appreciated the positive impact (coaching, career development) I could make to people around me in ways that are not easily replicated in other roles. And there are many others.
I actually believe that a small percentage of people want to climb the hierarchy. Based on books I've read, finding meaning in their work, either locally (how it helps the company) or globally (how does my work serve human welfare), is far more important for most people.
It's sad that our society is organized so that people who find meaningful work are stiffed by our society (teacher salaries, for example).
Seeking power is probably a miswant anyways. I think what many people desire is the social stability that it presents, something that is probably more easily achieved via volunteer work.
I don’t. I think it has very deep evolutionary roots: more status / power has historically translated into better access to resources, especially in times of scarcity.
But I agree it’s a miswant. In modern society nobody has much power over anybody (compared to how it was in ancient/evolutionary time). I think of it as a primitive drive that can lead some of us astray, like the sex drive can make some preoccupied with pornography.
I also think good managers should have a healthy distance to their desire for power. If they don’t they can waste a lot of company money on scratching that itch endlessly.
I think some, myself and Apple included when I worked there for years, consider hierarchies as a restricted sort of graph (essentially trees) that, to be a tree, necessarily collapse multiple dimensions of talent per individual into the single hierarchy, and thereby loses information. Hierarchies were avoided even whenever possible.
This has worked out fantastically for me for decades. But would-be managers have vested interest in promoting the supposed intrinsic instinct thing. Individuals don't have to play along.
(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?
> 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
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.
I'm 40 but I've been on both sides of the aisle. It's not just moving from a "development" into a "non-development" role. You're basically moving into an environment with very different incentives, interpersonal relationships and so on.
As a tech lead / senior developer, you're very much part of the operational level, and your decisions are mostly tactical and working from an existing strategical framework which you don't control.
That changes when you move into a (mid) management role. You now have to come up with overarching strategems, long term vision, be able to form strong alliances, navigate political landscapes, know who will fight you and why they will fight you, be able to broker deals and understand how your stance on a current issue creates much needed leverage down the road.
Technical knowledge matters far less. Being prepared when going into a meeting room means knowing who sits in front of you, what drives their motivations, what they want / oppose, and having a deep understanding of what you can say, and - more importantly - how you are going to say it. People will try to get under your skin, not because they have a personal dislike of you, but simply because the position you were promoted / hired into may be perceived as threatening to them. You're skin needs to grow thick.
At this level, the people you're going to work with don't care how the pie is being made. They want to leverage software to act on their larger strategic goals. You will have to promote technology not just because of its merits for developers, but above all because of the value it provides to stakeholders. You have to find selling points that resonate with the stakeholders you're supposed to cater to. And you have to ensure you can deliver on your word.
So, how does this apply to software developers? When you're working at an operational level, dealing with day-to-day emergencies and issue queues, working with a small team of people, building / maintaining systems and applications,... you're not really exposed to all of the above. Your supervisor is supposed to shield you from all of this and defend the work you and your team is doing. When you move up into that (mid) managerial level, you're moving into a very different world which requires skills and experience you can't easily acquire on an operational level as an IC.
Now, that doesn't mean it's impossible to grow into that level. You're transitioning into it, right? Your being recognized for your skills, the experience and the perspective you've grown over the past two decades. The big challenge ahead of you is learning how to actively "let go" of that operational level and delegate anything and everything operational so you can spend your time advocating for the stakeholders you're supposed to represent.
However, making this career change isn't for everyone. Nor is it something that ought to be seen as a marker for "career success". There's a lot of merit in being a senior developer who is keenly aware of the decision making process upstream and how things move, so they can organize work on the operational level accordingly. And this includes taking the lead in making pragmatic technical decisions regarding architecture, incorporating technologies, programming practices, documentation, setting priorities and so on. This is what sets them apart from someone who's at the beginning of their career and still has a lot to figure out about themselves as well as the workplace and everything involved in the process of building software and delivering value.
> At this level, the people you're going to work with don't care how the pie is being made.
Hear, hear... oh. Here be dragons. A manager at each rung of the ladder who doesn't have insight into the technical constraints will over-promise and embellish things, and the least technically capable will do it with the greatest zeal. And the grunts will be left with an impossible task of storming a well-protected fort with inadequate support.
> As a tech lead / senior developer, you're very much part of the operational level, and your decisions are mostly tactical and working from an existing strategical framework which you don't control.
A (really) good dev will recognise where strategic framework falls short or is non-existent and will be able to find a way to fix it. He will know that he needs to build trust and budget it to get the really important stuff done. For a good tech lead this is significant part of engagement as there is typically no other very technical person that would be better positioned to do it.
As a tech lead, for example, I am in a constant battle against complexity. Managers want to only add functionality, developers want to only add technology, and I try make people aware of how this ends if it is not supplemented with hefty effort to manage complexity. And this ideally ends in significant contribution to strategy if I can succeed or, if I can't, with inevitable problems later.
> At this level, the people you're going to work with don't care how the pie is being made.
They might not, but that does not mean that how the pie is made isn't influencing the outcome.
A manager that has significant experience with development knows how the pie is made and can be very valuable if he is able to use that knowledge for better outcomes. There is of course risk that the knowledge is misused (like people using certain solutions just because they are familiar with them and not because they are right for the particular situation).
> A (really) good dev will recognise where strategic framework falls short or is non-existent and will be able to find a way to fix it. He will know that he needs to build trust and budget it to get the really important stuff done. For a good tech lead this is significant part of engagement as there is typically no other very technical person that would be better positioned to do it.
This comes with some serious caveats. On an operational level, it is never your responsibility to "fix the strategic framework where it falls short". You're not expected to, nor are you incentivized to do that and you certainly don't have the authority to do it.
For instance, if you get inundated with deadlines and unreasonable requests, there's a handful of ways you could respond. You could go into crunch time / overtime until you burn out. You could draft a list of priorities and suggestions of a manageable workload and send it upstairs. You could even suggest reorganizing or expanding the team.
However, you can't hire someone new yourself, you can't ignore planning or requests, you can't decide from one side what kind of value the team is going to deliver. Why? Because you are subordinate to the authority of management on an operational level.
If you feel that shortcomings in the strategy of your employer impacts your work to the extent that what you do on a day to day basis doesn't align anymore with your views on how you want to contribute, well, that's a red flag.
> As a tech lead, for example, I am in a constant battle against complexity.
That's par for the course. On a fundamental level, you don't stand on equal footing with management. You can hope that your suggestions will be incorporated in the overarching strategy, but don't have the authority to actually make it so. At best, you may play your cards right and gain enough clout to exert influence from the sidelines.
That changes when you move into management.
As a manager, you will sign off on the solutions that needs to be build. You're accountable for the definition of the high-level requirements of a product / service, how it fits with available budget, how it matches with the envisioned value its going to provide to stakeholders. You might collaborate with experts in interaction design and design thinking to help guide this big-picture process. Depending on how much responsibility you're allotted, you may even have the authority to hire staff, organize teams, come up with your own projects and strategies and so on.
Being able to draw from your experience with the overall process of software development may help you in your estimations and the outcomes ahead. However, the usefulness of deep technical knowledge on a managerial level is very limited. As manager, the one thing you can't do is apply that knowledge directly on a day to day basis. That's where you are expected to delegate towards the team you're managing.
Indeed, having experience as a developer can even be disadvantageous. Your inherently biased towards particular tools and solutions and stepping back from them can be surprisingly hard. You also can't be overly sympathetic to the particular challenges faced by the development team. As an erstwhile developer, you might acutely relate to the pain of dealing with legacy and technical debt. But as a manager, you'll quickly find that you just can't afford addressing those as priority without potentially negatively impacting overarching goals, interests, budgets and so on.
One of the biggest challenges you will face is to unlearn to purely think from the perspective of a developer in the trenches.
Whether you like it or not, over the course of time, your technical knowledge will grow stale as technological progress replaces today's programming languages, IDE's, database systems, etc. If you keep on the managerial track, inevitably, there will come a day when you find yourself in a meeting with the next genera...
I think that the "politics and strategy" level is over-played. It exists, but it is not essential to the creation of a product - it is a consequence of the creation of an organisation to create the product.
At a senior senior level, the focus should be on un-creating the organisation so people can focus on building the product. Stack-ranking in companies is brutal but might be kept alive because it forces re-creation of the organisation as 10% of it vanishes each year...
I think that separating "management" as something to do with navigating social politics as a separate skill is taking something humans do every day at the school gate or the football field and claiming it has special status - it gets more vicious and more consequential because of the money involved yes, so perhaps having specialists is a good idea, but from an organisational design standpoint it seems sub optimal
> 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.
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.
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.
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 ...
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
> My view is leadership is the least important part of a successful business
Leadership is the part of the company that decides what the company will pursue. Tesla started making electric cars because Tesla leadership decided to. When they started making the Model 3 or PowerWalls or rolled out the SuperCharger network, it’s because leadership decided to.
> and "management" is the least important part of leadership.
>>> When they started making the Model 3 or PowerWalls or rolled out the SuperCharger network, it’s because leadership decided to
yes, and ...
Look anything I say sounds like sour grapes but, honestly there were a thousand bloggers saying "someone should make electric cars", there were hundreds of engineers who had built prototypes in and out of major car companies. It was time. The technology was there.
Leadership is not posting a vision up on a site or sending round a memo (ie deciding to).
Leadership is having the capital in place (financial and reputation and network and that x factor), and risking it.
I am not trying to belittle the leadership - but I am trying to right size it. Without the climate, without the skilled engineers and the cash and the government support and so on, leadership is just prattling on HN comments.
You could pluck any fucker from HN and put them as CEO of any random tech company and their decisions would be within 10% of the original CEO.
The hard part is not leading. We already know where we are going. The hard part is not staff work. The hard part is inspiring people so they don't fuck off and join the other guy with the same ideas but more charisma.
Just like High frequency traders the CEO competition is other CEOs. And just like HFT the secret is not the special algorithm, it's just the doing of it that gives society benefit. And just like HFT there is a lot of sound and fury and we could probably get the same social benefit with a new market structure
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.
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.
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.
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?
I think the responsibilities of project coordinator / project manager can be a part of the work of senior IC (Principal Engineer) or someone like Agile Coach, Delivery Lead.
Recently, I was a Chief Architect - an IC role - and organised and drove cross-team initiatives was a part of my work. It is not an easy skill, it needs practicing and the work is time consuming, may not be a fun quite often, but I think you do not absolutely have to assign it to a manager.
Great reply, I sit in meetings and see management who have no technical clue making pivotal decisions, resetting timelines without consulting their Architects, and will decimate them with no mercy. Yeah, I’m a paper pusher now but keep my skills up at night by doing consulting gigs on the DL and swore when I got into management I’d stop these ignorant schmucks from making decisions affecting project and product success all while rubbing their noses in their idiocy. Publicly. Those decisions get reversed and they learn to consult with technical staff before opening their uniformed pie holes.
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.
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)
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.
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
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.
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.
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.
>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.
I took a management position and delegate my management tasks out to people who want to do them on my team. I am still hands on and it allows people who want to get management experience to get it and allows me to land a management salary. Problem solved.
Im 35, programming since 15. great dev, never gonna be manager, simply dont want the responsibility and headache. Im good with code, not with managing people who code. The assumption that devs should go into managment seems alien to me :D but nice art
- "How did you get over here?"
- "Do you know what they do with engineers when they turn forty? They take them out and shoot them."
I've read in other threads that the ageism fear is overblown, and also that it's not overblown at all.
My plan is to develop enough of a professional network (whatever that means) that I won't be doing leetcode problems for a twenty-five-year-old interviewer when I'm fifty.
Well it depends. I do program in couple of languages, i do re and i still know a bit of assembler. If youve got right skills (sorry guys with just php and js) then i believe its not an issue. That might change, i will let you know when i hit 45 though im planning to be on retirement at that point :) but i do learn constantly, im not sure if thats true for every developer
I work with a developer who's in his 50s. He chose not only to stay in development but also to stay on the front end where he turns out beautiful and beautifully effective UIs using Angular.
He enjoys his job, earns great pay and plenty of stock and has the respect of his managers and junior colleagues. He has helped the engineers around him perform to a higher level and teaches, but he loves creating through code and is very good at it. He also has earned enough trust and is productive enough that when he says "The snow is great today, so I'll be skiing," that's just understood as his privilege.
Those people are in precarious positions. All it takes is one bad manager to join the team and misunderstand his value before he loses all his power. I've found those people usually don't create as much value as they think anyway. It takes an extraordinary IC to match the business value of a decent manager.
If his status came from the trust of one person that might be true. But it comes from ability and from character and from the consequent respect of many people. One bad manager could certainly tank his group (as in https://steveblank.com/2009/12/21/the-elves-leave-middle-ear...) but that theoretical manager wouldn't tank him -- he can just move on to a better place.
I hired him once and if he were in a bad spot I'd hire him again in a heartbeat.
In the meantime, of course, he has lived within his means for years and could weather any financial storms likely to blow his way.
The article implicitly conditions the strategy space on remaining an employee (or an employee-equivalent contractor) of a tech company.
Somewhat surprisigly it omits the relatively common option of becoming a long term planner (a.k.a. "paper pusher"), whether in product or engineering.
The options space outside of the Borg includes the following areas:
- Becoming an engineering associate at a non technical organization, for example by automating or adapting standard tech tools to legacy industries.
- Becoming a researcher (whether in an engineering field or one that requires engineering ability, e.g. computational biology - warmly recommended, BTW)
- Starting your own business that creates platforms/business cases that would otherwise not exist.
Bad. Very bad. You may 50% more at the very best case at the cost of being tied to your current organization. The problem with manager job is there is no way to prove your individual value. This is very problematic during job switch.
This article misses the most common path: technical leadership. That covers staff, principle, architect, tech lead and so on. You may be a specialist but hands on coding isn't your main contribution. You provide technical direction and guidance to a team, project or whole company. Pays very nicely at a large tech company.
My 10-year path at a 4->400-person startup has been Lead Software Engineer -> Director of Infrastructure -> Principal Software Engineer. I’m making more total compensation today than ever, with no reports.
I lead complicated initiatives and advise a lot of feature work. This means a lot of meetings, document-based collaboration, and process-oriented thinking. But I still program, and I don’t feel accountable for others’ work output or behavior or morale the way I did when I was a manager.
Technical leadership is almost nonexistent, and frankly, not required, in most of the CRUD shops that are out to "disrupt" the industry du jour. If all you are doing is slapping together a website with a backend that serves up the dreck while operating a two-sided market that's grinding actual humans down and fleecing naive consumers on the other, or perhaps the next DeFi con where rich marks are being convinced to hand over their money, "technical leadership" simply amounts to being on top of the latest faddish javascript framework / crypto snake oil vaporware / insanely expensive and asinine cloud-native gobbledygook.
As you have said, actual technical leadership can pay at a large tech company but those are relatively few and far between.
there is only one distinction that matters - do you own a budget? In other words has the company give you at least 10x your own salary to spend on your signature alone? If not you are not a manager, no matter your job title (including Project Managers!)
Everyone else is a work for hire.
Is it the best way of arranging things? Hell no. My bet is voting on projects to be funded by the the employees will be transformative
And if we clarify things like that, other things become easier - why should a manager be the arbiter of technical decisions? They should not - it's like hiring a dog and barking yourself.
Hire people, be clear in the outcomes do not confuse operations and development and release often.
I've never seen this to be true in any of the mature, publicly traded companies that I have worked at. It also seems like poor corporate governance to let someone spend millions without proper review. Consider the opportunities for fraud, waste, embezzlement, scams, etc.
At mature public companies there are people with sign off on millions and
often billions of spend. Choice between this supplier or that? Between a factory in Vietnam or Ohio? 100 Million on the nose and his / her signature is the final decision.
There is obviously auditors to catch the worst corruption and a process as to how a decision gets made (usually with an eye on the auditors) but yes. It's that person who makes the call.
Do they do it on a whim ? Unlikely but do they also give a monkeys what the devlead on the third floor thinks?
On the corruption front ... hell yes! Ok there is rarely the envelope of tenners dropped on the desk, but tell me, if the SVP with millions to spend on a supplier happens to serve on the board of the Gotham Orphanage alongside the CEO of a major supplier, is that corruption ? What about the understanding they have of "working together in the future"? And the nice directorship waiting on the suppliers board ?
We live in a world where Air Force Generals join boards of air plane manufacturers, so a quiet understanding between suppliers and buyers will easily pass muster. Is it corruption ?
Quite common: developer->designer->architect
Variations: solution architect, data architect, strategist
And of course: permanent->contract->entrepreneur
296 comments
[ 3.0 ms ] story [ 258 ms ] threadManaging a team of developers without any idea how to do the work is a disaster.
Of course, having some experience doesn’t guarantee you’ll be an effective manager, but without it you’re almost guaranteed to fail.
As a manager my goal is to use as little of my technical knowledge as possible but rather to let my senior technical leaders do that part instead. I've got so many other things to handle and deal with that being technical except at a high level seems silly.
Like what?
- Helping figure out the right goals and metrics for the team and ensuring everyone is on the same page.
- Holding 1-on-1s with team members, non-technical feedback and yearly reviews. Seriously, yearly reviews are a massive time sink if you actually care and spend time on them.
- Passing around information to the team and making sure they are involved in the right meeting/conversations.
- Attending various management meetings that usually could be replaced with a wiki page.
- Resolving non-technical issues my team members are having. This includes listening to venting sessions, complaints and general bitching. Need to handle these situations in a diplomatic non-judgemental way.
- Keep track of team non-technical blockers (people, process, etc.) and try to resolve them (short or long term). This includes resolving product management issues and other teams blocking my team.
- Keeping stakeholders close and happy
- Selling the team, it's vision and achievements broadly
- Hiring
- Planning team promotions and executing on those plans. This includes telling your team members what they need to do to get promoted and then ensuring those promotions happen.
- Non-toxic (or toxic depending on the company) politics
- Talking to random people in the company for networking. It's amazing how much people from HR will tell you if you are friendly and get coffee with them.
In my experience engineers hate it when an out of touch manager makes an estimate on their behalf and then they are forced to do crunch time to meet it.
edit: Also most projects come via the PM who would coordinate with the tech leads directly for planning and scoping.
This brings up my overall view that being technical can often make a manager take short term shortcuts. That works right until it no longer does and then you have a broken team and culture and processes. Not thinking technically means you are forced to implement good long term processes and not keep monkey patching things. For example, if the managers keeps making these decisions in meetings then senior engineers will wonder how they can have their voice heard except by going into management.
Even if they trust me to provide them with estimates (and they understand that 9 women cannot have a baby in a month). I have to spend a lot of time just constantly communicating the information they need, and why certain things need to happen so they can tell (and satisfy) their stakeholders.
A Visual Basic 6 programmer "can't" be hired to program in Javascript, although its the same people and skills 25 years apart. However put that VB6 programmer in a management role and somehow that completely obsolete technical skillset is "invaluable", LOL.
Likewise, some lessons transfer. "Huh, that time we were working on Thing X and relying solely on Bob's technological expertise we were completely screwed and the company went under after after Bob had an aneurysm, I should make sure there are no single points of failure on the team knowledge wise."
Or "Man, we built such a beautiful Visual Basic 6 program, but the interface was so bad nobody used it and we failed. Let's make sure our front end and back end people are communicating properly." Or, "This was the most elegant technical solution, but then it turned out nobody had the resources to run it. So let's make sure to do our user testing and make sure we're designing appropriately."
The common scheme is to offer logistical support (dealing with paperwork, IT, etc) in exchange for joining under their umbrella (with the implicit or sometimes not so implicit promise that otherwise they exert no influence over the operation of the practice). Then after a few months to a year they start making sweeping changes restricting what patients the doctor is allowed to see, what treatments they are allowed to provide or suggest, how much they can charge, and where they are allowed to see or treat their patients. Essentially resting any autonomy the doctors had over their practice.
This is what happened to our PCP and many other doctors in Florida. They were given an ultimatum and any patients who didn't fit the profile Advent had selected for them were forced to leave them for some other doctor.
Nowadays the only doctors with any "real" autonomy are surgeons and even then the actual autonomy they have is being increasingly encroached upon.
I'm not sure how common this is in other regions but at least in Florida it is becoming increasingly difficult to find Doctors who haven't been effectively tricked into forfeiting control of their practices and reduced to employees for large corporations.
That's pretty much the #1 route for people I know, get out of the full time lackey game and chill.
Edit; another thing which you can do as contractor and typically not as employee, is take retainers. When a project is done and the company does not need me anymore, they can retain me for n hours per months that I will spend on that project no matter what else I am doing; and they pay no matter if they use the hours or not. Similar is, and I have done that too, an SLA on the project you helped deliver. But that is far more dangerous as others might have continued working on it, so I don't do that anymore.
Perhaps you don't notice how little the full-time people are trying :) It's not hard to try harder than them.
BTW now I'm curious. It sounds to me like you're talking about very different contracting that I am? I have never seen a larger company allow contractors to skip the agile ceremonies. They're always treated exactly as an employee in this regard - they're basically "temporary" augmentation of the staff, because company is not able to hire enough permanent people. (BTW this "permanent" state usually extends into years of staying at that company). Is this the kind of contracting you do, or do you do something else?
Contracting is completely different, you generally define a set project to complete, do it, and get out.
In the UK there's something valled IR35 which means that in order for you to be considered an independent entity for tax purposes you should have full control over working hours, practices, etc.
Of course, it's all paperwork that can be bullshitted, but it's had at least some effect in my experience.
GP is describing people contracted to deliver a product/service.
Do you have the money to pay a locksmith a competitive rate? Same.
Btw. Your contract will be as you make it and as your customer sign it. Thats it. Theres no point in labelling contract is this or that. Its unique per situation.
What does "verifying products" mean?
He works from home, more or less at his own convenience.
Zero interest in retiring.
I feel that my cognitive peak is already way behind me and I'm 35. 25 felt like my golden age of creativity and cognitive performance: no longer the erratic bullshit of the coming of age teenage years, no responsibilities, a job with loads of freedom. Such a contrast from my life now at 35 with kids, where I still love my job but must actively pace my expenditure of mental capacity to avoid crash and burn.
I want to hear from people how they feel cognitively in their 60s. How is it when kids leave home? How is it when you trade agility for experience? I want to know what it's like, as it is inevitable and real, in my own experience, to lose brain power as I age.
I was a manager, in addition to being a technical specialist, for a long time. It was a fairly small, highly-skilled team. As time went on, my management duties replaced my technical ones, and I was forced to do technical work on the side (open source work), in order to maintain my technical edge. This resulted in my having a fairly significant technical portfolio, by the time I left my job.
I have encountered very few good managers, in my career. I have seen some great technicians destroyed by becoming managers.
I think the industry’s refusal to cultivate lifetime technical careers has resulted in a lot of problems, but it is not anything that has been studied, in any meaningful way (of which I’m aware). I only have personal anecdata, which, by itself, isn’t particularly relevant, in the big picture.
Developers want more money for more experience.
At a certain point, more experience does not make them more effective developers.
If they want to justify higher salaries, but can not be more effective on their own, they need to multiply their experience by making other developers more effective.
The organizational problem is that most companies see management as the only way to do that, but not everyone can and likes to be a manager.
We as developers have to make sure we promote mentoring, tool and framework building, system architecture and such topics as viable paths upward. Otherwise, managers will only have managing as an idea of how someone can create more value.
Training and mentoring are extremely important.
Last night, I had dinner with a friend of mine, who is a former Marine. He told me that the "best of the best" become DIs (Drill Instructors). He had tremendous respect for his DIs, and described them as "almost superhuman."
DIs are always noncoms, but tend to be highly experienced. They are also good trainers. Being a good trainer is a fairly specialized skillset, and many techs aren't able to adapt to that, either.
In my case, money has never been the point. I'm a high school dropout, with a GED, and never really got paid as much as even many entry-level kids are, these days. Nonetheless, I lived frugally and sensibly, and have been able to survive being tossed out into the trash. Many of my peers do not have that capability.
1) The experience. 2) The job.
Having 10 years hacking on one system probably won't make you anymore productive than 3. At that point you're a factory worker, and you can't only put so much expertise into flipping a few switches and following traces.
However, having 20 years of diverse technical experience will make you more productive than 15 if the job requires the breadth you've developed.
I'm 12 years in and have moved into Startups for just that reason. You get to learn more numerous things, and you get to use all of them. I've been at my current job 6 months and I've worked with 4 languages, more libraries than I can count, 2 third parties, blah blah blah. If I went back in time even 3 years of experience, I would definitely be less effective. If I went back 5, I'd be struggling.
This has given me a lot of exposure to different things over the years. It's mostly web stuff, but one of the more interesting ones was interfacing with hardware for a warehouse app that we built to make the shipping process less error prone and more efficient.
Now the analogy I like to use is a rising tide raises all ships. Instead of being the individual hot-shot I do everything I can to make everyone else a hot-shot. If they are talking in a meeting and I think a nudge needs to be made, I just 1:1 message them with a tip and then let them say it instead of speaking up. I do more training of juniors and even seniors, teaching devs how to think through complex problems. Now my teams are more productive, most of the people like me and want to be working with me, and my income has skyrocketed as a result. Of course, I did have to escape from traditional office hierarchies and go into consulting to really increase the $.
Older and more experienced technical specialists are more of a threat. Cultivating those people would mean giving them mentorship and resources, and older tech specialists are the population that's most likely to be a.) able to leave/have transferrable skills/not be as reliant on the companies as the managers, b.) old enough to stand up for their juniors - can't have someone on the team telling them NOT to work 14 hour days/killing themselves grinding to work at FAANG, and c.) they're most likely to have the organizational and long-term thinking/architectural skills to compete.
Cultivating older technical specialists could be seen, by tech execs, as training in and investing in their own competition.
As a manager, it was my job to retain them; which I did -quite well. I did this via a combination of maintaining my own technical prowess (on my own time, as my company was no support at all on this), empowering my employees, staying out of their hair, learning the individual drivers of each of my team members, not nickle-and-dimeing them, supporting their training and personal/career development, and not playing political games. I never lied to them, and used carrots far more often than sticks. I also -very importantly- shielded them from a rather rapacious HR department, and terrible upper-level management.
I didn't give a damn about whether or not they wanted to replace me (I don't think it ever crossed their minds).
Basically, I became the manager that I always wished I had.
PLEASE LET US NOT GENERALIZE ALL DEVELOPERS INTO JUST 4 TYPES.
It's great with managers that have domain knowledge, but having domain knowledge does not make you a good manager.
This is the part that I think a lot of technical people really misunderstand, hence all the negative sentiment about turning developers into managers. A stellar incredible "10x" team of super talented developers can not negate the bad people dynamics within a project caused by bad leadership or lack thereof.
If you think the current crop of managers are doing all this, I am afraid you are mistaken.
While frameworks and libraries change all the time, the concepts do not.
I'd compare it to using Wikipedia/web search for basic facts. Even if you don't know the capital of Morocco off the top of your head, you know how to answer that question.
Human languages are similar: I've studied six + have a Linguistics degree, and even languages in families I've never studied before are a lot easier for me to pick up than somebody who's only studied 1 non-native language.
“Building client-server architectures to run on the internet” is domain knowledge that hasn’t significantly changed in the last 20 years.
Also I get to decline my boss asking if I want to take on manager responsibilities on top of normal duties without extra pay. Bit of a no-brainer.
The Job Do’er:
This person is qualified for the job, and does it. Stays prepped for interviews and moves companies/roles as needed to maximize income/happiness. This person does a job, somewhat acceptably, acceptable to the company that demands acceptable work and acceptable to a life that demands acceptable upkeep (bills and shit).
So if you find yourself unable to become a manager, luckily for you, you can still do your job (boo hoo).
They could be merely 'normal developers', not very different from any other developer.
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.
But to your point, the lunatics always feel like they are the “normal ones”
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.
What could go wrong?
Management of technical teams is not a one sided operation, it’s not us vs them. You are beholden to those you manage, as well as your leaders above you (actually, more so). Sometimes the motivations of those two groups can be seen to be in conflict. You have to be an effective advocate for both. The problem I have seen with many engineers who try to make that transition, is that they think they job is to be an advocate for their engineers they manage. They forget the other 50% of their job…which is the 50% that is actually the most important to their livelihood.
It can, managing is (should be) a collaborative effort. It only is a problem if the manager manages in a non collaborative forceful top down manner.
It's all a question about communication skills.
Like in some sports you will find top players earning multiple times of what their trainer earns, and potentially having enough influence to get their trainer fired. They work together with the trainer for optimal results.
Similar enough wealthy people hire fitness trainer, or people which manage their cullender, schedule, appointments and might even majorly decide career directions. And it still works even through the person in power is the person being managed.
Google translate says "cool calendar" which seems ... wrong?
_Maybe_ I could change careers and be an engineer and make as much of them, but I wouldn’t want to. I’m a manager because I like being a manager. It’d be a QoL decrease for me to be an engineer just for the money.
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.
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.
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.
Managers are typically comped better. Usually on a level by level basis, but also in the number of times you can be promoted before you run out of new job titles.
I think there is probably one IC equivalent for every 2-3 low level managers, and $CORP is better about these things than any other company I’ve ever worked for.
I think a lot of success in hierarchies is based around the willingness and ability to turn a screw.
What domain expertise buys you is a higher intuition on whether or not you should.
Sure, you can have a lot of technical managers who suck. You can also have a good experience with a non-technical manager.
But day by day, pound for pound, my money is on domain expertise leading to better results. This happily explains why a manager is typically a senior role.
Course, there's a lot of ways to screw that up.
Sales engineers can also have customer/client consulting management roles.
Some companies promote good engineers to R&D and product strategy roles. They're still engineering-led, and not particularly about day to day development issues or longer term - but still very clearly defined - project goals.
Most of what's being described as management really seems to be line management. What you want from management is at least as much of the other types.
Generalists who can invent the future with some accuracy are particularly valuable. Giving them space to pursue that within some very broad strategic goals is far more valuable than "promoting" them to team management.
Office space joked about having eight different bosses, the secret to worker happiness is less management in their lives, not more.
I don’t understand why this is a different perspective. The dynamic I’m describing applies if you start promoting junior engineers to these roles as well (based on interest in management and ineptitude in hands-on engineering).
> Generalists who can invent the future with some accuracy are particularly valuable. Giving them space to pursue that within some very broad strategic goals is far more valuable than "promoting" them to team management.
In my experience it’s very hard to invent the future and realise the vision without some sort of formal leadership / management (in the broadest sense) role. (Unless it’s small enough for one or two people to build of course.)
Managing people is a shit job. You spend your time in endless meetings and playing politics. You're tasked with day-to-day HR-related tasks. You need to keep everybody satisfied. Your salary won't necessarily be any higher. You get the blame for stuff. You have to delegate away the fun work. You lose touch and rust faster. If you're lucky, some of the people you work with will actually like you - but if your team doesn't deliver then it doesn't really matter...
What makes any of this sound like you're somehow "climbing"?
Of course the majority of people don’t even come close to this, but people will try nonetheless.
There are also positive aspects that hang in the balance. Personally (as a people manager) I appreciated the positive impact (coaching, career development) I could make to people around me in ways that are not easily replicated in other roles. And there are many others.
It’s just not private planes and Champaign.
It's sad that our society is organized so that people who find meaningful work are stiffed by our society (teacher salaries, for example).
Seeking power is probably a miswant anyways. I think what many people desire is the social stability that it presents, something that is probably more easily achieved via volunteer work.
I think the desire for power is manufactured.
I don’t. I think it has very deep evolutionary roots: more status / power has historically translated into better access to resources, especially in times of scarcity.
But I agree it’s a miswant. In modern society nobody has much power over anybody (compared to how it was in ancient/evolutionary time). I think of it as a primitive drive that can lead some of us astray, like the sex drive can make some preoccupied with pornography.
I also think good managers should have a healthy distance to their desire for power. If they don’t they can waste a lot of company money on scratching that itch endlessly.
I think some, myself and Apple included when I worked there for years, consider hierarchies as a restricted sort of graph (essentially trees) that, to be a tree, necessarily collapse multiple dimensions of talent per individual into the single hierarchy, and thereby loses information. Hierarchies were avoided even whenever possible.
This has worked out fantastically for me for decades. But would-be managers have vested interest in promoting the supposed intrinsic instinct thing. Individuals don't have to play along.
> 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?
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
Definitely seems a lot less clear cut than just practicing a language
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.
As a tech lead / senior developer, you're very much part of the operational level, and your decisions are mostly tactical and working from an existing strategical framework which you don't control.
That changes when you move into a (mid) management role. You now have to come up with overarching strategems, long term vision, be able to form strong alliances, navigate political landscapes, know who will fight you and why they will fight you, be able to broker deals and understand how your stance on a current issue creates much needed leverage down the road.
Technical knowledge matters far less. Being prepared when going into a meeting room means knowing who sits in front of you, what drives their motivations, what they want / oppose, and having a deep understanding of what you can say, and - more importantly - how you are going to say it. People will try to get under your skin, not because they have a personal dislike of you, but simply because the position you were promoted / hired into may be perceived as threatening to them. You're skin needs to grow thick.
At this level, the people you're going to work with don't care how the pie is being made. They want to leverage software to act on their larger strategic goals. You will have to promote technology not just because of its merits for developers, but above all because of the value it provides to stakeholders. You have to find selling points that resonate with the stakeholders you're supposed to cater to. And you have to ensure you can deliver on your word.
So, how does this apply to software developers? When you're working at an operational level, dealing with day-to-day emergencies and issue queues, working with a small team of people, building / maintaining systems and applications,... you're not really exposed to all of the above. Your supervisor is supposed to shield you from all of this and defend the work you and your team is doing. When you move up into that (mid) managerial level, you're moving into a very different world which requires skills and experience you can't easily acquire on an operational level as an IC.
Now, that doesn't mean it's impossible to grow into that level. You're transitioning into it, right? Your being recognized for your skills, the experience and the perspective you've grown over the past two decades. The big challenge ahead of you is learning how to actively "let go" of that operational level and delegate anything and everything operational so you can spend your time advocating for the stakeholders you're supposed to represent.
However, making this career change isn't for everyone. Nor is it something that ought to be seen as a marker for "career success". There's a lot of merit in being a senior developer who is keenly aware of the decision making process upstream and how things move, so they can organize work on the operational level accordingly. And this includes taking the lead in making pragmatic technical decisions regarding architecture, incorporating technologies, programming practices, documentation, setting priorities and so on. This is what sets them apart from someone who's at the beginning of their career and still has a lot to figure out about themselves as well as the workplace and everything involved in the process of building software and delivering value.
Hear, hear... oh. Here be dragons. A manager at each rung of the ladder who doesn't have insight into the technical constraints will over-promise and embellish things, and the least technically capable will do it with the greatest zeal. And the grunts will be left with an impossible task of storming a well-protected fort with inadequate support.
A (really) good dev will recognise where strategic framework falls short or is non-existent and will be able to find a way to fix it. He will know that he needs to build trust and budget it to get the really important stuff done. For a good tech lead this is significant part of engagement as there is typically no other very technical person that would be better positioned to do it.
As a tech lead, for example, I am in a constant battle against complexity. Managers want to only add functionality, developers want to only add technology, and I try make people aware of how this ends if it is not supplemented with hefty effort to manage complexity. And this ideally ends in significant contribution to strategy if I can succeed or, if I can't, with inevitable problems later.
> At this level, the people you're going to work with don't care how the pie is being made.
They might not, but that does not mean that how the pie is made isn't influencing the outcome.
A manager that has significant experience with development knows how the pie is made and can be very valuable if he is able to use that knowledge for better outcomes. There is of course risk that the knowledge is misused (like people using certain solutions just because they are familiar with them and not because they are right for the particular situation).
This comes with some serious caveats. On an operational level, it is never your responsibility to "fix the strategic framework where it falls short". You're not expected to, nor are you incentivized to do that and you certainly don't have the authority to do it.
For instance, if you get inundated with deadlines and unreasonable requests, there's a handful of ways you could respond. You could go into crunch time / overtime until you burn out. You could draft a list of priorities and suggestions of a manageable workload and send it upstairs. You could even suggest reorganizing or expanding the team.
However, you can't hire someone new yourself, you can't ignore planning or requests, you can't decide from one side what kind of value the team is going to deliver. Why? Because you are subordinate to the authority of management on an operational level.
If you feel that shortcomings in the strategy of your employer impacts your work to the extent that what you do on a day to day basis doesn't align anymore with your views on how you want to contribute, well, that's a red flag.
> As a tech lead, for example, I am in a constant battle against complexity.
That's par for the course. On a fundamental level, you don't stand on equal footing with management. You can hope that your suggestions will be incorporated in the overarching strategy, but don't have the authority to actually make it so. At best, you may play your cards right and gain enough clout to exert influence from the sidelines.
That changes when you move into management.
As a manager, you will sign off on the solutions that needs to be build. You're accountable for the definition of the high-level requirements of a product / service, how it fits with available budget, how it matches with the envisioned value its going to provide to stakeholders. You might collaborate with experts in interaction design and design thinking to help guide this big-picture process. Depending on how much responsibility you're allotted, you may even have the authority to hire staff, organize teams, come up with your own projects and strategies and so on.
Being able to draw from your experience with the overall process of software development may help you in your estimations and the outcomes ahead. However, the usefulness of deep technical knowledge on a managerial level is very limited. As manager, the one thing you can't do is apply that knowledge directly on a day to day basis. That's where you are expected to delegate towards the team you're managing.
Indeed, having experience as a developer can even be disadvantageous. Your inherently biased towards particular tools and solutions and stepping back from them can be surprisingly hard. You also can't be overly sympathetic to the particular challenges faced by the development team. As an erstwhile developer, you might acutely relate to the pain of dealing with legacy and technical debt. But as a manager, you'll quickly find that you just can't afford addressing those as priority without potentially negatively impacting overarching goals, interests, budgets and so on.
One of the biggest challenges you will face is to unlearn to purely think from the perspective of a developer in the trenches.
Whether you like it or not, over the course of time, your technical knowledge will grow stale as technological progress replaces today's programming languages, IDE's, database systems, etc. If you keep on the managerial track, inevitably, there will come a day when you find yourself in a meeting with the next genera...
At a senior senior level, the focus should be on un-creating the organisation so people can focus on building the product. Stack-ranking in companies is brutal but might be kept alive because it forces re-creation of the organisation as 10% of it vanishes each year...
I think that separating "management" as something to do with navigating social politics as a separate skill is taking something humans do every day at the school gate or the football field and claiming it has special status - it gets more vicious and more consequential because of the money involved yes, so perhaps having specialists is a good idea, but from an organisational design standpoint it seems sub optimal
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.
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.
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 ...
You only herd them when you want them to do something they do not understand or are not incentivised to do
Source: Currently trying to train a literal cat. And am a figurative cat myself.
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
Leadership is the part of the company that decides what the company will pursue. Tesla started making electric cars because Tesla leadership decided to. When they started making the Model 3 or PowerWalls or rolled out the SuperCharger network, it’s because leadership decided to.
> and "management" is the least important part of leadership.
This part could very well be true.
yes, and ...
Look anything I say sounds like sour grapes but, honestly there were a thousand bloggers saying "someone should make electric cars", there were hundreds of engineers who had built prototypes in and out of major car companies. It was time. The technology was there.
Leadership is not posting a vision up on a site or sending round a memo (ie deciding to).
Leadership is having the capital in place (financial and reputation and network and that x factor), and risking it.
I am not trying to belittle the leadership - but I am trying to right size it. Without the climate, without the skilled engineers and the cash and the government support and so on, leadership is just prattling on HN comments.
You could pluck any fucker from HN and put them as CEO of any random tech company and their decisions would be within 10% of the original CEO.
The hard part is not leading. We already know where we are going. The hard part is not staff work. The hard part is inspiring people so they don't fuck off and join the other guy with the same ideas but more charisma.
Just like High frequency traders the CEO competition is other CEOs. And just like HFT the secret is not the special algorithm, it's just the doing of it that gives society benefit. And just like HFT there is a lot of sound and fury and we could probably get the same social benefit with a new market structure
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.
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.
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?
Recently, I was a Chief Architect - an IC role - and organised and drove cross-team initiatives was a part of my work. It is not an easy skill, it needs practicing and the work is time consuming, may not be a fun quite often, but I think you do not absolutely have to assign it to a manager.
Having a mediocre developer in that position will lead to all sorts of problems.
So managing technology means managing people.
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.
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
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.
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.
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.
My plan is to develop enough of a professional network (whatever that means) that I won't be doing leetcode problems for a twenty-five-year-old interviewer when I'm fifty.
He enjoys his job, earns great pay and plenty of stock and has the respect of his managers and junior colleagues. He has helped the engineers around him perform to a higher level and teaches, but he loves creating through code and is very good at it. He also has earned enough trust and is productive enough that when he says "The snow is great today, so I'll be skiing," that's just understood as his privilege.
So that's what happened to one person.
I hired him once and if he were in a bad spot I'd hire him again in a heartbeat. In the meantime, of course, he has lived within his means for years and could weather any financial storms likely to blow his way.
Somewhat surprisigly it omits the relatively common option of becoming a long term planner (a.k.a. "paper pusher"), whether in product or engineering.
The options space outside of the Borg includes the following areas: - Becoming an engineering associate at a non technical organization, for example by automating or adapting standard tech tools to legacy industries. - Becoming a researcher (whether in an engineering field or one that requires engineering ability, e.g. computational biology - warmly recommended, BTW) - Starting your own business that creates platforms/business cases that would otherwise not exist.
Flawed premise. Why does everyone assume it's a promotion?
> For example, people often assume that any talented developer will end up becoming a manager.
I assume the opposite (and it's been true the vast majority of times over a 30+ year career).
Most people understand raise in human hierarchy as a promotion. Few deal with increasingly difficult technical tasks on the daily basis.
I lead complicated initiatives and advise a lot of feature work. This means a lot of meetings, document-based collaboration, and process-oriented thinking. But I still program, and I don’t feel accountable for others’ work output or behavior or morale the way I did when I was a manager.
As you have said, actual technical leadership can pay at a large tech company but those are relatively few and far between.
there is only one distinction that matters - do you own a budget? In other words has the company give you at least 10x your own salary to spend on your signature alone? If not you are not a manager, no matter your job title (including Project Managers!)
Everyone else is a work for hire.
Is it the best way of arranging things? Hell no. My bet is voting on projects to be funded by the the employees will be transformative
And if we clarify things like that, other things become easier - why should a manager be the arbiter of technical decisions? They should not - it's like hiring a dog and barking yourself.
Hire people, be clear in the outcomes do not confuse operations and development and release often.
At mature public companies there are people with sign off on millions and often billions of spend. Choice between this supplier or that? Between a factory in Vietnam or Ohio? 100 Million on the nose and his / her signature is the final decision.
There is obviously auditors to catch the worst corruption and a process as to how a decision gets made (usually with an eye on the auditors) but yes. It's that person who makes the call.
Do they do it on a whim ? Unlikely but do they also give a monkeys what the devlead on the third floor thinks?
We live in a world where Air Force Generals join boards of air plane manufacturers, so a quiet understanding between suppliers and buyers will easily pass muster. Is it corruption ?