> 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.
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.
> "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.
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.)
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.
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.
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.
(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.
> 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 generation of developers and you can't readily bridge the gap between your and their technical expertise / perspective / knowledge.
That's not necessarily a bad thing, but you have to be mindful that becoming a manager implies that you're not a developer / craftsman anymore.
> 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.
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
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
> 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.
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'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
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.
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.
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.
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.
> 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.
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.
My father joined Kodak out of college, in 1951. A classmate who interviewed the same day ended up running the place.
My father helped a senior programmer automate dozens of jobs, chemically testing their film processing plant. For this he was moved to their research labs. In the 1970's he invented the filter used in nearly all digital cameras:
Bryce Bayer is your dad? That's quite the exceptional employee you're talking about then.
I recently used his other famous invention (Bayer order indices) to come up with a fast approximation algorithm for blue noise (still working out the kinks of an improved version).
This is like the exception that proves the rule. He was an exceptional specialist.
The reality is that there is a big demand for people willing to help direct/manage developers who are not great with their time, and to have some degree of vision and project management skills - with a dispationate outlook on corporate politics.
The best people to do that are former/current developers since they know how the sausage is made.
Because of this excess demand, and the higher efficiency of having a manager with more managerial experience, pay rates are higher for management than most development.
I don't think developers become much more efficient as they get older, since they're often required to learn the newest frameworks (unless they're in a highly specialized field that has tools that last decades), whereas managers become significantly better over decades, and thus can justify higher pay rates.
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.
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.
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 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.
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.
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 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
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.
Managers control the money. They hire, they fire, the approve or disapprove promotions. That's _fundamentally_ more power than writing code. It would be nice to be able to ignore this, but things like paying for housing, paying for kids' education, etc means you can't really just put that aside.
If you want to stay in a technical track, you need to offset your natural disadvantage here. You can't _just_ be writing code, you need to make sure you're actively -- and visibly! -- adding a lot of value as a tech lead. Even if you're not formally managing people, you're going to be coaching and mentoring engineers, because being able to tie your org's goals into a technical vision is the easy part -- the hard part is turning that vision into code that will be mostly written by not-you. And that's all people skills, involving people who do not report to you. IOW, there's still a lot of "management" work if you want to stay in the technical track.
I recently did a stint in the management track but have gone back to the technical one because I get a lot out of technical work and found I need that to sustain me and give me energy. I found I can do the management part, and didn't even mind most of it, but it wasn't sustaining me -- an important consideration since, while I've been working for a while, I have a long while to work yet. But it did help clarify where I need to grow if I'm committed to staying "technical".
Another pattern I've seen is the software developer who is promoted to high level manager, but they remain focused on the work being done by the software developers. On this front they are very good: mentoring, teaching, removing obstacles. But part of their job is also to now form a better understanding of the other parts of the business: how does the work of the software developers overlap with that of the marketing team, the sales team, the operations team, the financial team, the inventory team, etc. These newly promoted managers don't seem to realize that their new authority means they must now focus on more than tech. I've known developers who get promoted to CTO, and they are loved by the software developers at the company, but they are hated by the CMO, CFO, CCO and eventually, after enough complaints, they are hated by the CEO, at which point they are fired.
'This CTO is loved by the software developers but disliked by their peers. The CMO feels unheard, the CFO thinks the CTO doesn't show enough concern for the budget, the Chief Content Officer (CCO) feels that their team is crippled because the CTO doesn't understand their publishing needs. Such moments can undermine the career of a CTO. I'm aware of at least one case where, 10 years after the situation arose, the CMO and CFO and COO, who had all moved on to new jobs at new companies, were still whispering rumors about the CTO. When the CTO applied for a new job, and the company asked his former peers what they thought of him, they were told "He is uncooperative, he is not a team player." So clearly, in that case, it would have been better for the CTO if he'd spent less time with his tech team, and more time with his C-level peers. Or rather, there must have been some particular moment in the growing history of the company when it would have been best for the CTO to switch his focus away from tech and towards his peers, but the CTO missed that moment, much to the irritation of his peers."
> They start their career at age 24 and, because they have a Master's degree, they skip over the long years in the trenches working as a computer programmer. Instead, their first job is often as CTO of some medium sized company.
If this is actually in your book I would remove it. This totally destroys your credibility because:
A. You're talking about a 7 person startup, not a "medium sized company"
B. You're talking about the worst managed medium sized company I've ever heard of, where they would put a 24 y.o. masters student with no real world experience in charge of anyone.
C. It's not a true anecdote
Any of the above options lead me as a reader to think that either you don't have experience in the industry, have experience with poorly managed companies or are making up scenarios to fit your narrative
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.
FWIW I found this book to be a better survey of ways an experienced dev can take their career: https://staffeng.com/book
This article seems a little flippant. I’ve found very few “specialists”, personally, or legacy coders. Most of the time experienced devs tend to become leads or architects. Sometimes leads do management, sometimes not.
I’ve been an engineer for over 20 years now, and I’m definitely seeing more places defining very senior IC positions now than when I started. But I don’t know it will ever be super consistent.
Everything, such as where I work or my career trajectory, is quite fluid. I’ve realized and accepted as a more experienced dev, I am the one that has to lead the transition to, say, driving new product or technical directions instead of management. And I need to be at a place where I can make that happen. So far, that’s never been a static, predictable situation; but largely because of how the business itself is. In the last 10 years, a major company event, such as an acquisition, or a major leadership change like the CEO quitting, completely shifted the dynamics of the org. Usually negatively. So, I read the tea leaves, see if I have any ability to drive good directions. When the answer has been no, I move on to the next one.
Basically I’m seeing a lot of people expecting structure where there won’t be. Nobody will pave a clear career trajectory for you after about a decade. So I find it’s more important to ask “how can I negotiate what I want here” instead of “what title will I have”.
It’s not a promotion. It’s an entirely different job. You now manage people, influence and have control over their careers, performance management, as well as obviously working budgets, roadmap, etc.
In my opinion, it’s a downgrade. I’ve found few managers in my career to be effective leaders. Most of my managers relied on the senior engineers to essentially drive the roadmap, do the estimates, lead design, break down the work, delegate, and lead the implementation.
This is generally the trend I see at Amazon at least. The managers who are good are extremely driven and dive super deep into the tech, while showing humility and empathy. They grow their people, get them the right opportunities, and are people you want to be around.
But there are waaaayyy too many managers who simply can’t cut it as engineers and switch from the engineering path to manager path. These folks actually add very little value.
Actually the best managers I’ve worked with are all former engineers who didn’t want to become managers but took on the role because they knew they could fulfill the need.
>Most of my managers relied on the senior engineers to essentially drive the roadmap, do the estimates, lead design, break down the work, delegate, and lead the implementation.
You mean they were good managers who know how to bring out the best out of their engineers?
Some of the best managers out there today can't code out of a wet paper bag and yet generate billions of value for their companies.
>You mean they were good managers who know how to bring out the best out of their engineers?
No, I don’t mean that all. I meant that they provided no value on their own. They passed every bit of the responsibility to someone else, while still collecting a hefty salary and stock compensation. Did they actually earn anything? I don’t think so.
If the senior or staff engineers do everything, even down to recruiting, why do we need managers? The manager is a dead weight - letting go of them is actually the right thing for the stakeholders and shareholders of the company.
The general trend I see is that when their lack of management results in things actually derailing, their way of accepting responsibility is simply throwing one or more of their reports under the bus.
Sure, they’re shrewd and figured out a way to play the system. I’ll give ‘‘em credit for that.
Looks like GP is drawing a distinction between deliberate application of good management skill, and reliance on the initiative of others. Unless you’re implying that good management is minimal (potentially zero) management?
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
Recently I’ve found myself wondering about the average stress levels of managers versus senior engineers. I’m at a big tech company that has roughly parallel tracks up to a quite high level, so I’m not hurting for income, but I see a lot of VPs/directors taking vacations, generally seeming well balanced in work/life. Meanwhile, I haven’t taken a legit vacation in 2.5 years (ok, the pandemic and small kids are partially to blame) and am constantly a ball of anxiety over whether my technical ideas are up to snuff, whether we’re on the right track implementing them, etc. I wonder what stresses I’d find on the management track.
Haven't taken any vacations of more than 5 days since 2011.
Constantly worry about my technical skills becoming obsolete - hence I have to do coding on the side.
Constantly worry about whether my managers will practice what I preach (kindness, coaching, caring, etc.) with their team.
Constantly worry about multiple deadlines for multiple projects, all under my responsibility but not direct control (I'm not a direct manager).
Hire 10-15 people at a time, campaign for some of them, they disappoint, become a burden for others and risk destroying the team - have to worry about that as well.
Get an e-mail at 10pm on a Friday that your best developer has been hired by Google at 2x the pay and there's nothing I can do about it. Another e-mail at Monday 11am saying that your worst developer has ALSO been hired by Google at 2x the pay. Spend 24/7/365 on how to prevent your entire team from jumping ship because of pay I cannot match.
Worry about managing up, sideways, down, and in the fourth dimension as well.
Kill to just be a developer, step back into IC role. Do well, less stress, gets asked to become a manager again because the previous 3 have been a disaster and the team elected you.
Maybe, or grass is greener? Also don’t know if I would pass IC technical interviews after so many years as manager. The leetcode grind seems out of reach for me now.
In general, yes. I sleep a tiny bit better when someone takes something over from me. If they complete that well, I will go to bat for them to get them recognized.
Shit falls down. If these managers failed in their responsibilities, were they correctly trained? Why didn't you notice that? What have you done to remedy it? If you didn't, why are they keeping you in the organization in the first place?
Yep this. Trust, but verify. If a manager (or IC, for that matter) is failing in my org, then it is absolutely my problem. VPs won’t accept “these were by my buttons to push” as an excuse.
Fwiw I’ve spent the past few years pondering going back to being an IC to reduce stress. There’s probably a grass is greener effect here.
It’s interesting though. I do put in fewer hours as a manager. At the same time as I’ve progressed up the management ladder my anxiety levels have followed. Quality of life has suffered. I’ve learned to live with near constant stress headaches, frequent jaw pain, and a host of other issues.
> Fwiw I’ve spent the past few years pondering going back to being an IC to reduce stress. There’s probably a grass is greener effect here.
If you are a good manager now, you will let it transpire in your IC work and you will eventually be asked to step back into a manager role, because the team asked so.
Take a vacation! The company will be okay without you for a while.
Disclaimer: I’m about to say stuff that are just my impressions, without a lot of “I think” or “I believe.” Take those as implied.
Generally the stress of management is in coordinating various personalities and balancing competing priorities, while being on the hook for delivering results without having any direct impact on whether a project gets done to a high degree of quality. They rely on others’ expertise, some of whine may not be that reliable, and it’s stressful!
Directors and VPs have that stress plus they are more directly accountable to financial results. However, they have to be cheerful and optimistic and never show weakness or worry to an almost psychopathic degree. This may look like a good work/life balance externally but internally “work brain” and the weight of stress are relentless. The bad ones sublimate stress and occasionally explode and yell at their subordinates.
To engineers none of this looks like “work” because none of it produces concrete results. (I haven’t mentioned the endless word docs to read and write, and the spreadsheets, oh god the endless spreadsheets.) But it does accumulate a lot of stress and anxiety.
On the vacation side of things, seriously, take a vacation! It will be okay!
As a manager of managers, I can confirm this is a fairly accurate of my job, in some aspects at least. The lack of concrete results is maybe the most frustrating as a former engineer (it is like your compilation cycles takes months if not quarters).
This makes a huge amount of sense. I hadn’t considered how high level managers really can’t afford to project their stress publicly (bad for morale!) so I’m probably seeing an extremely airbrushed picture of their lives.
Yes, + they have to make impossible choices. There's a product right now at work we're debating killing and the decision literally comes down to evaluating whether losing an important organizational partnership or taking a reputation hit would be worse for the company. There's not a right answer; that's just fortune telling and having to own the results.
It’s different depending on the company. I’ve seen companies that can have very technical managers and this is good. I’ve also seen companies where managers like to play engineer, but badly. They don’t relegate until it’s a problem and may or may not focus on correcting design issues.
I have had to say in a meeting. Stop engineering the product and have the engineers handle the development life cycle.
Regardless, life won’t change just because the duties do. You have to make time off happen. The market is so starved for talent you can go somewhere else over night.
Director level is probably the worst - all of the grind but none of the glory.
VP at least you have some power and a lot more money, it 'feels' like something.
I think companies should pay technical people the same as managers up to at least director and there should be at least some parrallel technical tracks right up to the top i.e. Directors have Architects, VP's have Systems/Strategy Architects etc..
Some companies have a technical track culminating in "Technical Fellow." Supposedly equivalent to a VP level executive. I worked at Boeing many years ago, back before the engineering culture had been fully snuffed out, and technical fellows commanded a huge amount of respect.
Oh sure, I mean, there are tons of contributing factors to human happiness and one’s specific job function in a specific company isn’t a complete determinant. A lot of my anxiety is directly attributable to a tendency towards intense self-criticism, which is going to follow me anywhere.
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.
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.
I was a developer for 50 years. Almost every other software developer I can think of "retired into management". I was offered a management position 8 times in my career and turned all of them down. Management is a skill that I don't naturally have and can't be bothered to learn.
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.
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.
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.
The option they don't really list is "continue working in more or less the same way until you retire", which I think is, by volume, what most people outside our industry expect.
I was recently talking to some engineers about being in software in our 40s, and I eventually realized that a basic assumption they all shared was that they should continue getting raises and promotions indefinitely, and if that didn't happen it was a sign that something was wrong (with the company, or with them). They assumed that, as long as they continued advancing along a linear skill progression, getting better and better at their jobs, they would to continue getting at least commensurate career and salary progression.
The thing is, that's not how most jobs work. In most trades, you reach a certain level, then top out, and after that you (hopefully) get small, periodic raises to match inflation, then one day you retire. But, you don't expect to make 10-25% more money every couple years for the rest of your life, the way you often do in your first decade or so of software development.
I don't think it's a "check your privilege" thing, I think it's just that matching growth to compensation is a reasonable assumption engineers often make, because maybe that's how it should work in an optimal world, and it's sort of what a good developer experiences at first. But, the world isn't optimal, and the world of work is so sub-optimal it's not even funny, so don't count on it!
I definitely wouldn't classify myself as the author's "super developer" but I fall inline with what he described it as.
Isn't this just a case of someone being into what they're doing while continuously learning, applying and building things?
I've been at this for ~20 years and every day I wake up, all I really think about is what to learn, apply and improve upon. This comes in the form of everything (coding, project planning / architecture, assisting other devs whenever I can, making videos, writing blog posts, running a podcast, etc.).
Life would feel like torture if I couldn't do this and I know with absolute certainty I'll never go into management and I'll never stop what I'm doing until I'm dead. Money is really important but it doesn't drive me, otherwise I would have stopped doing most of the things on my list because none of them make any amount of money that's comparable to billable hours or a salary rate.
At the same time I imagine there's lots of folks out there who go from developer to manager because that's what drives them and it's not because of money. I think those are the best types of managers. They know tech and how developers operate. They would be a welcome addition to any team.
Let me put it this way: There is no love for old developers unless you are at the top like Anders Hejlsberg. Ageism is rampant in Silicon Valley. Older developers have some good qualities, like experience from fighting all the battles, and some bad qualities, like a resistance to moving out of technologies they are entrenched in. Younger developers offer companies more of a blank slate that can be molded, a willingness to spend long hours on technology that may not have much of a chance of succeeding (but there's a chance!) the stamina to put in long hours and less family obligations to worry about. I understand the preference for younger developers in the valley.
My recommendation to developers turning 40 if they don't want to be a manager is to start your own business and be your own boss. It doesn't matter what it is, but that way you wont have to face an increasingly hostile hiring environment.
Heck I've even thought about finding a young developer as a front and then writing all their code for them behind the scenes!
This hits the nail on the head. Most younger devs do not even have a clue of how senior devs are to be evaluated. This is why there is such a huge reliance on Leetcode-style interviews: it's much easier to evaluate someone on that basis, and it's also why most places will outright tell you that your leveling at the company will be contingent on your interview performance. This means that your skills that can't be displayed in an interview are of zero use insofar as getting paid what you are worth is concerned. As Leetcoding is the only thing that's going to get you that, you have the current cottage industry of interview prep companies.
The same developers who are blithely rejecting tons of experience in seniors will find themselves in the same spot a decade from now. Poetic justice at its finest, but alas there are no victors here.
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.
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 ?
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?
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 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?
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.
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.
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'd say the author forgot 'Survivor'. It's possible to remain a higher-level programmer, just switching projects from time to time as your work ages out.
Advice to the younger generation: About 25 years ago, a fellow programmer told me he was once in management, but switched back to programming. At the time, I though management was the logical career progression (an idea I no longer hold). I asked him why he left management. He replied "Because in management, they nip at you from the top and they nip at you from the bottom." Meaning that you still have a boss, but you also have underlings that want things from you. It was great advice.
I've known several who did the same. I was an Army officer before I went into software development, and have little interest in being in charge of other people again. The only painful aspect of this is being subjected to the poor "leadership" of others - when you know you could do a better job of it. Which is also why the #1 thing that can keep me at a company these days is when I see it has good leadership. I know it's rare.
Yeah I'm not sure about quoting Christopher McCandless so much... I was fascinated by him as well but end of the day he was a super young dude who decided to go into the wild with insufficient preparation, on purpose, and died of hunger. It is what it is. He never amounted to become Yoda or Ghandi or anything that we should be so comfortable in quoting him.
I am a 63 year old developer, three of my close friends are also developers in their 60's. One works for Lockheed on 3D engines, one works for Cisco, they are both treated very well by their companies. Myself and another friend work for a startup. We both enjoy the startup culture, and now that kids are away for their own lives, we have the time needed by startups. I have run into crazy hiring practices, but I have learned that when they ask me to balance a binary tree that the job is not for me.
>when they ask me to balance a binary tree that the job is not for me.
Could you please elaborate? I reject offers from the companies that never made me write any code during the hiring process for the fear of having incompetent coworkers.
LOL its an incompetent manager detector, not an incompetent coworker filter.
First of all it shows your future boss doesn't spec and doesn't care. From memory there are two solutions one has essentially zero memory cost but has a speed of O(nLogn) and the other has brutal O(n) memory cost and is about O(n) speed. Is memory so cheap for your application that you can double it for a mere log N speed improvement? Is N big enough of a number to matter? Its absolutely savage that in 2021 there's still companies hiring that can't pass Spolsky's hiring list from decades ago. A place that doesn't spec is a place that doesn't use source control, doesn't test before deployment, doesn't rationally schedule, its just a gang cowboys crashing it with no survivors. They don't spec, Run Away.
Secondly it shows a dangerous level of NIH syndrome. Its almost but not quite as dumb as trying to roll your own crypto. If the job is writing a database or maybe a filesystem or a sorting standard library type code, it gets a free pass. Any other workplace, if you see an application for a database, use a database, or import a known good licensed library for DB or filesystem work. If you're interviewing for, maybe, a 3-d engine game dev position, its legit to talk about something like how the 80s were an era of rapid theoretical development in hidden line removal algorithms, because they were and its cool. But if the interviewer is like LOL no we're going to talk about how you'd write a tree balancer for a filesystem, that's so deep in the NIH I'd run away. That project is doomed.
Third reason is its not terribly difficult to blast thru that algo the simple way where you traverse nodes and insert into a self balancing tree, or the memory expensive solution where you store into a temporary sorted array and then read out in a tricky fashion into a new tree (which is faster than one at a time because mumble something honestly who cares for 99% of jobs). Its probably about two to six screen fulls of Python. The real problem is its a cultural indicator of here's some flaming hoops to jump thru. The stereotype is we're a kinder gentler more civilized culture because we no longer abuse dolphins into jumping thru flaming hoops for our amusement, now that we're better people look at our halos as we abuse our fellow humans into jumping thru flaming hoops for our amusement. Just a workplace culture I'd run away from if I saw it.
Forth reason is I've been around the block and when the interviewer knows what they're doing and what you'd be doing they tend to talk about that specifically. When they have no idea WTF either they or you would be doing, that's when they whip out "I'm bored lets fill time by having you implement Bresenham's line algo in STM32 assembly language for lulz". The problem isn't the algo, and the problem isn't learning the algo, its that the hiring process consists of people who have no idea what they're doing and no idea what you'd be doing, so working there would be hell on earth. You're interviewing them as much as they're interviewing you, and they just told you they have no idea whats going on. Good luck there...
And then there are the vast majority of developers who are never offered a management position. I don't know what planet you guys are from but I've not seen a developer promoted in 15 years. I would kill for a promotion to get the hell out of programming
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?
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.
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.
- 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.
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.
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.
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.
I would say that I've been doing this my entire career in different specializations: T-shaped, Pi-shaped, TTT-shaped...
> Option #2 – The Super Developer
After accumulating knowledge in a number of specializations and contexts, environments, I'd say I'm about here now but want to change into something that's still not management.
> Option #3 – The Legacy Developer
I've been this at a number of companies where I've stayed 5+ years.
> Option #4 – The Career Switcher
Not at all interesting, unless it's perhaps a startup with a co-founder and I'm the tech-side.
The Option #5 that I'd like to get into is a tech mentor/advisor. You know how much better a movie is that has a 'is this accurate or dumb?' research person/team? Well, we need these roles filled in tech companies too. Working in one project has key moments where I can fill this role but then I'm then later a productive/super developer after the concepts and designs are sorted out. The later stage work can be filled by other sr devs. Reading a tech design proposal and asking good questions, exploring 2nd-order effects, or identifying scaling problems that could arise are the sorts of things I feel I provide the most value.
those types of roles are not usually salaried, or at most, very early-stage CTO type positions that quickly ask you to name your less-expensive replacements
you can more easily find that kind of work by offering consulting services and building/maintaining a network of entrepreneurs who stumble into those problems often enough to fill your schedule
being #2 Super Developer long enough to get your name out there is a good first step into that world ;)
Thanks, this explains why I don't encounter these opportunities--I'm not much for networking or consulting or much of any other social/non-technical activity. Perhaps the role I imagine requires that level of social/networking if I'm committed to finding them.
Technical leaders do exist and mentoring is a huge part of it, you need to figure out a way to be a multiplier, without being a manager.
If you want more money, you need to have more impact, but there are so many hours in a day, so you need to delegate, help others grow and look for large scale patterns that are easier to see with experience.
If you do code, you must choose wisely what's the best use of your time, sometimes you do what nobody else dares to (take calculated risks), small interventions to teach and speed up a project, or just plain do what needs to be done (even if it's boring as fuck) to let others grow and add value.
You also need to develop a good working relationship with other leaders (technical and otherwise). It's imperative that they trust you, so your integrity must be beyond reproach.
Understand their goals and objectives and help get the company to a better place.
In many cases, leading is a lot about emotions, people get scared/nervous when facing uncertain situations (think production incidents, external threats, etc.), it's in these situations that you need to be a reassuring presence, using your technical skills to break down a problem and give clear steps and criteria to attack whatever issue is at hand. Be calm and focus on the objective reality as much as possible. Give clear instructions and lean on more managerial roles to help track down tasks and deal with minutia.
In all, I think a technical career starts with focus on the technical stuff, the science and technology, but as the problems become larger and more challenging, you need to start to pay attention to the people side of it, software is a team sport after all.
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.
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.
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.
From my experience so far, you can keep plodding along as a regular developer as you get older. Your salary will plateau eventually. The plateau is high relative to most other jobs.
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.
These code schools are so ridiculous. Anyone can code in 12 weeks! Also, there are only 4 types of developers and good ones post blogs and do TED talks. Such bullshit.
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.
I'm a developer who worked for 35 years and never became a manager. I wouldn't say I fit into any of these classifications. I worked in the defense industry for 5 years, then switched to commercial software. I worked with several different languages in companies with very different products. I was constantly learning, but never thought of myself as a 'super developer'. I learned new languages and new product areas: C/Bash for a company building ethernet hardware in the '80s. (A full TCP/IP stack ran on the board). Switched to a company building software for the Mac. (C and Pascal). Did contract work for modem companies. Learned Perl (Bleah) when working for an Internet Advertising company. Learned Ruby on Rails working for a company that was doing analysis on Air-conditioning systems in skyscrapers in order to save the building operators money and energy. I stayed very interested and involved. Did my best work when my manager could carve out a project that I could work on by myself and be done in 3 months or so, without needing any supervision.
"Management skills" is a huge misnomer in my mind. I wasn't management material, and not especially good on a team, because I'd get angry when people disagreed with me. Peter Drucker said the most important part of being a manager was having character. Not something one can acquire in any easy way. I got a lot of therapy to deal with my own anger, so that helped.
If you have some people who do the work at hand, and some people who manage other people, you automatically put the managers in charge (because it doesn't make sense the other way around). And then you get the hierarchies we are used to, with managers and individual contributors. That's really a pity.
In German there is a phrase that translates to "content" or "substantive" work (inhaltlich). You use it in contrast to non-content or administrative tasks that enables the main work. It is like a neutral way of saying "actual work" without deriding the other kinds of tasks. I'm not really sure how to translate it properly.
As an experienced developer, I would really like to have a job with not much managerial responsibility, but a lot of "content" responsibility. Not a manager, so I wouldn't tell somebody how to organize their work, but I get to make larger technical and strategic decisions. Unfortunately such architectural positions (or maybe CTO) are very rare, even though I know a lot of companies could use benefit from somebody in this role, who would keep the greater picture in mind, make technological decisions, teach employees, and so on.
Inhaltlich sounds similar to Cal Newport's idea of Deep Work[0]. I know I've found that framework pretty helpful. It's about work that requires in-depth thinking + time with a lack of distractions vs work that you can do without those things (like making phone calls, etc.).
I've always wondered in these cases -- are we talking about a situation where "failure" means making less money than when you were 35, but by any objective measure still bringing in a very good paycheck? ie, Perhaps you used to make $170k, and now you "only" make $130k? Or are we talking about a situation where you get to a certain age and you literally can't find any work?
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.
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.
Depends on what you consider management. A people manager is a different set of skills than a product manager or tech lead, for example.
It also depends on the company. Some orgs let you level up past senior to principal/staff/partner without becoming a manager. Others reserve those titles for leadership roles.
In my org, there are seniors who are old and gray happily cranking out code and having fun with their job. They’re clearly happy not stepping into the realm of management, because they’re still well-compensated and their stress levels are low without the added responsibility.
Your career is what you make it. I’d suggest focusing on what you want to do, as long as you’re content with your position.
Developers can get jaded. If they are lucky and diligent, they might be able to retire early. After retirement they could continue programming in FOSS or private projects, if they love programming. This way they won't have to mollify annoying managers or customers and work around them. They won't need to participate in office politics, but of course if they work in FOSS projects they will continue to have to cope with politics, just different one. If they don't love programming, they could take up different hobbies or even start something completely different.
Haven't read this yet, but I'm having a hard time understanding the connection.
Pretty much everywhere I've been, these are independent paths. Sure, one can flip to the other side... But they're distinct ladders to climb
For the technical side you end up with some managerial tasks, like making sure your project is staying on time or deciding what to do when a feature tests stability. You probably do less work in the weeds, but still guide the technical direction
The other side is much more about people and the business in my experience. While the technical/development side maintains a lot of their focus
Many big companies have a “technical career path”. This is a lie. Reality is that this is a path of slow regular promotion up to your “level of education”. BS ends at technical staff. MS ends at principal. PhD ends at fellow, and those are all management roles anyway. Doesn’t matter how good you are. Nobody is really that good anyway; success or failure will largely be assigned to you.
My advice is to either go into sales for the best management ladder-climbing potential, or stop working and buy a cheap house somewhere nice after about 5 years.
I think the article is missing one key category. Many if these people are laid off in their 50s and are then never able to find work again or find on and off work as contractors.
I’ll offer a 5th — a twist on the legacy developer that is the opposite of the described. On an enterprise app for a smaller business, you’ll find that a legacy developer is one of few, if not the only, who fully understands the app, it’s architecture from A to Z and the data model from top to bottom. Thus, they are incredibly valuable. In the right role, they continue to tinker without being a manager and more junior devs handle the rote.
I’ll add, in most cases I’m probably describing an app with incredible technical debt, but that’s not at all unusual in the real world, especially in non tech industries.
Are you in it for the hacking, or for the results, or the money, or the power? Do you want to talk about and facilitate work, or do the work?
Somebody has to design, write and most importantly debug the work. You can do it with a number of good people, a herd of cats or some mixture of the two. If you assume the head shed exists to keep the company alive, every other manager exists to enable the “doing the work” people to operate without interruption.
This is something that really irks me about the tech industry. If you don’t move up, you risk getting cut. Management will eventually phase out older developers in layoffs, and replace them with younger, cheaper talent. Big corporations especially. I know way too many developers who Never wanted to be in management, and eventually management became people younger than them, who preferred younger colleagues.
The company I work for has too many managers with insufficient technical knowledge. that means witnessing the absurd battles of egos. I don't want to be one of them. Management and technical architecture are very different concepts, but people don't understand that. I find that making someone with insufficient technical knowledge a manager often makes that person a bad manager.
well the carpenters get better and better at carpentry and raise their prices each year because there isn't any significant changes in the technology of carpentry at least once a decade making carpentry skills obsolete in the eyes of the marketplace.
> because there isn't any significant changes in the technology of carpentry at least once a decade making carpentry skills obsolete in the eyes of the marketplace
That's a bit extreme I think. Tech changes yes. But let's say you were a a C#/C++/Java/Python/Ruby dev 10 years ago - how bad has it all changed in the last 10 years that your entire experience is somehow nullified? I'm not denying that some higher-ups like to adopt this line of thinking to justify hiring cheap juniors. Self respecting engineering companies don't really buy this bull.
It’s funny that your list spans languages from about 20 to all of 30 years old (and less than that if we start counting from the mainstream adoption). In a typical 40 year career, many people would think of these as hot new technology - kind of like working for 10 years today and suddenly Rust comes along or something.
I’m an old guy. I have 20+ years on me as an IC and am going through interviews. I have or have had a total of 20 interviews.
I can honestly say I don’t feel any ageism. I do feel like the interview process is getting harder and harder though from an expectations perspective. I’m not sure if that’s unconscious ageism but I think it’s more that people’s expectations for perfection have increased.
They get laid off before reaching retirement or vesting their pension and are replaced by younger and less expensive workers. They live in a van by the river and take such odd jobs as"motivational speaker":
The reality is that the org structure for engineering companies is broken.
Reasons:
1. The org chart shows a tree with managers on top of engineers - Big mistake because the manager will not be able to accomplish anything without reports
2. People "promoted" into management are usually the ones who WANT to be a manager. Wanting to be one is good but the reasons for wanting it should align with the company. Far too many people want to become managers for the TITLE. These people are parasites and will destroy the whole team by virtue of insecurity and sycophantism.
3. Many senior engineers are quite capable of managing teams. They should be encouraged by directors to try becoming a team lead - focus on tech aspects of a larger team, keep people happy.
A better org structure for fast moving engineering companies could be something akin to European soccer clubs of high caliber
1. Director aka Technical director - Reports to VP - Has the power of the purse but is also deeply technical to understand what bets their group is taking. Responsible for hiring, projects, org structure, pay and culture
2. Engineering manager aka club manager - Reports to Director - Only responsible for coaching, mentoring and allocating resources to produce outcomes. Their key responsibility is outcomes and it requires keeping people happy, engaged and growing. They need to be deeply technical, much more so than directors to be effective in their job.
3. Senior/Team lead engineers aka coaches/leaders - Works with EM but reports to director - Responsible for driving their own area of expertise/projects. Much like a goalkeeping coach drives goalkeepers only. Only difference is that Senior/Team lead should also be expected to contribute directly to projects. These people are not responsible for happiness or cultivation of other skills or producing other opportunities
4. ICs aka the players themselves - Real MVPs of the team - Should be paid higher than EM because the EM is replaceable but the players often aren't. Should be shielded from politics but should be incentivized by money and status to remain ICs. This is how you get players like Cristiano Ronaldo not retiring too early to get into coaching.
I would be very inclined to join a company where ICs are treated better because I have seen management-heavy companies lose sight of what is really important for the company.
- Director should be technical / Team Leads should be technical, but the person between them shouldn't? That sounds like a recipe for going behind the EM's back at every possible junction.
- TLs reporting to the director? The analogy of goalkeepers coach does not make a lot of sense, because in a club, they report to the manager, not to the General Manager (Director in your example).
1. My mistake. EM needs to be strongly technical. Much more so than directors. I will edit the post.
2. The GK coach works with the manager/head coach to figure out the entire strategy and keep the training aligned with goals. But they are hired by the director (general manager), fired by the director, paid by the director, have status meetings with the director.
From the director's perspective, all coaches are at the same level. Each coach has a specialty and a role to fill e.g. GK coach, fitness coach etc. There is a head coach/manager whose job is to ensure that all other coaches and all players are happy and aligned. Let's call this person the alignment and happiness coach.
In a similar vein in tech companies, you'd have team leads specializing in tech areas and leading projects (as opposed to merely coaching), and a EM whose role is to keep everyone aligned and happy.
Really depends on your employer. I work for an engineering driven public tech company in SV and it’s normal for there to be senior engineers who are 40+.
Also at a public company it’s very unlikely a junior or new manager will be making more than a senior engineer who has been there for years. They might have 10x the equity a new employee has.
When we talk about niches for specialists compiler development and Linux kernel are usually mentioned as examples. What are the other good options where specialisation, long term investments are valued, and someone after 30 can focus on going deep into?
What about 4. Become a Chief Architect, Product Architect, how ever you won't to call it, Usually guiding other architects, making strategic technical decisions.
Quite common: developer->designer->architect
Variations: solution architect, data architect, strategist
And of course: permanent->contract->entrepreneur
It makes sense to multiply the effectiveness of talented engineers by training them to be technical leads, but management is a completely different beast
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).
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.