That’s a very clickbaity title. I was reading the article and sharpening my pitchfork up until the middle when I had to stop and put it down (the metaphorical pitchfork)
Yes, it isn't very clear about whether the demotion was chosen or not. "I followed my dreams to be demoted to software developer" or "I followed my dream of being demoted to..." would be much clearer.
I don't know if I'd call it clickbait. Whimsically worded, sure, but the author did literally go from being a Director of design to an associate software developer so it doesn't seem inaccurate to call it a demotion.
This might be excessively nitpicky, but the use of the phrase "_got_ demoted" (emphasis mine) implies to me a lack of control over the situation. It's technically correct, but it sounds like it was a punishment rather than what it actually was (namely, a career choice).
Same. English isn't my first language so I'm not sure, but the title doesn't' seem sincere when the subtitle reads "Kristina Lustig, formerly our Director of Design, explains why she took a new role as an associate software developer"
English is my first language. I'm American on top of it. This is a clickbait title. It conveys an incorrect meaning. People can talk about formal definitions all they want - it doesn't matter. Language isn't always about formal definitions - it's more often about how people use it. In this case - the headline is being used to grab eyes, is clickbait, and is wrong about the contents of the article.
Your new headline would be better but it wouldn't have attracted any views.
Yes, subject to minor variations. The version I heard had him going from the back of the section in a community (amateur) orchestra to playing in the Toronto Symphony to leading the viola section in the Berlin Philharmonic -- and making the same wish ("make me a better musician") each time.
It seems clear to me from the title that the demotion was deliberate. The content of the article was more or less exactly what I expected from the title, which seems to contradict the notion that it's clickbait.
I've always fought to stay a developer as well. It seems that as soon as I know a codebase well enough to be really productive, there is a "team lead" or "scrum master" role waiting. Once or twice I've even fallen for it but the result have always been more meetings, less customer interaction, more responsibility and somehow less power over the product. Pay has stayed the same of course.
I guess I could amend it to "Never move up when someone else wants you to unless you get a pay bump."
If you want to move up and someone else is iffy on it, sure, skip the raise to help convince them.
It's a matter of who is prompting the move, and what extra responsibility is required and such. If your boss asks you to take on more responsibility, ask for more money. That's really all I'm saying.
I've always found it difficult to come up with OKRs (goals - insert company BS euphemism here) that were acceptable but didn't force me towards a management position. It is just assumed that the goal in any company that a person should want to herd cats as a living.
If pay stayed the same, then something went wrong. And I get it. I've had some friends go through this, where they'd get offered a lead position but technically it's 'Lead in training' so he gets the old pay while they evaluate him etc.
Complete BS. If they offer it to him, they think he would be a good fit and they're just trying to pay less. Contrast it with my experience, where I just stepped up to fill the gaps whenever I saw them, my boss noticed, offered a lead position including pay bump.
I've always believed and practiced this too. You get the promotion & bump because you're already essentially doing the job. I'm OK with a trial without the promotion, but many (most?) seem to think you should get the opportunity to succeed or fail, with the rewards up front. I do't get this viewpoint.
This is mild exploitation widespread in employment, and I think you're identifying with the exploiter.
It's not the rewards up front, it's the rewards as-you-go. Or it's the rewards at the end of the previous rank.
Always having your pay 1yr behind your responsibilities is wrong. You're doing the job, you get the pay.
On day 1 of being a lead, you've never been a lead before, but you are now. Year 1 leads get lead pay.
"You've done great, you're at the top of your rank! No, I can't reward you for it yet, just start at the next rank and we'll wait and see pleasethankyou." No. We saw. Pay me.
For this to be true, then it must be true that trial-run promotions very frequently fail, so they keep the person in the role they perform best in. I think that's not the case. I think trial-run promotions lead to promotions about equally as often as no-trial-run promotions.
The same people end up at the same end rank, they just take lower pay for a year to get there. And that one year drag compounds because raises are %.
Anyway we're likely disagreeing in an entirely vague way. Of course my leadership skills should be evident if I'm going to ask to be Lead, so yes day1 leads aren't starting from 0. But a company's surest bet for who to hire as Lead is me, so why should I put up with them telling me they just aren't sure yet? All hires into new roles are very uncertain, and I'm the most certain, so I get the role. Someone more certain than me is a person with 2yrs of Lead on their resume, but they get Lead 3 pay, and I'm not asking for Lead 3 pay. You're hiring a Lead 1 and I'm sure surest bet (inside the org or out) and we all know it.
Or go ahead whisper promises of a promotion in the ears of two on my team and watch them butt heads as they try to act out the phantom authority you've given them. A politicking horserace like that has a vastly worse impact on the company than just pulling the trigger and naming one of us Lead 1 even if we're obvious greenboots for a year.
I'm so glad I've found this comment. It's REALLY strange to me that this is the first time I've read someone talking about this phenomena and on how exploitative it actually is and, like other comment noted, this is a very convenient co-opting of the Peter principle in order to get more senior people for cheap in the guise of "trials" and similar.
When exactly did this extortionary tactic started? There are so many things that go unquestioned...
I think it's quite a difference whether your boss already knows (or thinks) you can do the other job and still tries to not pay you the bump and you doing the extra work to get noticed.
In my case it wasn't even to get noticed. I just care about stuff. My current boss is actually trying to make me 'care less'. Like I can't leave it alone if I see the PMs do a crap job and I try to fix it. I can't not say something when I see the DevOps guys not taking care of the dev envs and dev experience.
Also when did this start? Like hundreds of not thousands of years ago. Why?
I don't think I've ever interviewed from the same angle but I have been clear with my managers that I want to avoid moving into any sort of people management. It hasn't been an issue and when you've marked yourself out as a long term developer you can get more momentum behind technical pushes that might have a long project lifetime since the company will be less concerned about putting a big weight in your hands - they can trust you to carry it through[1].
1. I mean - assuming no life changes which you should never feel guilty about making to suit your own interests.
Then on the other hand, you have unusual guys like me who are trying over and over to get into management, but 20+ years in I'm still at the bottom of the totem pole. It's always the same need-experience-to-get-experience catch-22: "Well, [JOE] already has management experience and you don't so [JOE] is now your manager." It's always a struggle: If you want X and don't want Y, somehow you're always going to be offered Y and have to fight for X.
I’m right there with you - despite feeling like I’d be more passionate about being the more managerial and less “hands-on coder” on every team I’ve ever been on, including having a biz/IT degree vs pure CS, and having worked in a variety of industries in a variety of roles ... it’s always “well we want you to be the dev because reasons” and I can’t quite figure out what I’m missing. I have a feeling it’s just that my resume doesn’t say I’ve already been a manager and that when I interview, I don’t lie and tell people how I’ve managed teams of direct reports. That doesn’t mean I’m incapable, or that I wouldn’t be great at it, but I guess orgs see management as high risk so they never want to take a chance. Either that or I’m always doomed for some sort of “BUZZWORD-Ops” role
Have you had the discussion with your manager that you want to get into management as a long term goal? Your manager should help you plan out a track to a management promotion. If your manager is not helping you develop along your intended career path find a new manager. If they do when one becomes available you should be prepared to interview for that role.
My strategy: pursue a lot of things as hobbies. If you view amateur in the true sense as "not paid" vs. "not good" you can do so many things for a much purer motivation - it's sooo much more rewarding. Nothing wrecks something you love like having to do it.
I interpreted it as tongue-in-cheek. On my reading, the point of the article is that titles and prestige are far less important than being excited about what you're working on. If having a more fulfilling job means a less fancy title (and you can afford the pay cut) you should go for it.
Sometimes people working in tech lose sight of why they went into this field. The author's enthusiasm is a great reminder why. Fantastic article.
I think it’s just to make an attention grabbing title.
After reading this, I’m just genuinely happy for the author. I think that not everyone is in a position to do that kind of thing, but for those who can, I wish we all had that kind of courage and the willingness to put in the extra work to make it happen.
For context, my last job change was also a diagonal step down and an overall step up in happiness. Not as dramatic though. I also did it because I felt like I was innately more suited to a different role.
But it is a demotion! I think perhaps we view that as a negative thing when it's done as a punishment, or due to factors outside one's control. But in this case, she chose it (indeed, worked for it!), so she must think it was worth it.
Her rank is literally demoted. She went from being high on the job ladder ("Director") to low on the job ladder ("Associate"), reflecting the fact that she's still developing the capabilities needed to do her new discipline. I guess maybe if one viewed this as a commentary on management vs IC work, it could be seen negatively -- but I didn't personally interpret the framing that way.
Ditto for status - she likely went from having lots of soft power due to her time and relationships in the design org, to essentially starting over in the development org.
Are these bad things? I don't think so. Presumably she was pretty clear on the short-term negative impacts of the change, and still wanted it.
As I said in another comment, I completely agree with this.
I guess you and I are taking a more literal definition of demotion, whereas others may interpret it through the lens of the feelings of shame that would normally come with it, or perhaps even through a more "anarchist" view that no man is ever above any other.
I still disagree - I think there is too much of a conflation between managing people and rank/status. Once upon on a time master craftsmen were the pinnacles of their industries but mechanization has shifted the framing to place "doers" below "directors" - I don't think this is strictly accurate and prefer to think of people managers as peers that manage the interpersonal side of the business (which I think is quite important to take care of - I just suck at it) - similarly I think that directors, if they're good, are managing long term strategy and that senior craftsmen need to be in on this conversation to supply expert advice on what's possible similar to salespeople being in on the conversation to try and inform what may sell.
Org-charts are about management structure and directors weirdly get very highly placed on them while their role isn't person-management driven. I've always found them exceeding strange except in their highlighting of SMEs and to aide in inter-departmental communication.
But this all may just be the socialist in me shining through as someone working with a team to make widgets that do their thing well.
I think I agree with almost all of what you said! I don't view ICs as below or above management, but as complementary to each other.
I don't actually know what her role was, but I'm not sure it matters too much. Typically, I've seen directors in two kinds of capacity: people management or strategic/technical vision. For both of them, there's a ladder. For example your career progression might look like:
- Manager, Senior Manager, Director
- Product Designer, Product Design Lead, Director
In both cases, "Director" isn't an entry-level role. You don't get hired into it fresh out of school, for example, and your scope of influence is expected to be much larger (regardless of whether you're influencing people or vision) than someone at the "bottom".
By contrast, her new role (Associate Developer) _is_ an entry-level role.
That's where I think the "demotion" terminology makes sense. I also agree with other commenters who note that it's most likely meant in a tongue-in-cheek way to drive clicks. But for me, there's a bit more to it than just the cheeky clickbait headline. Have you ever wanted to change things up at your company, but felt constrained, knowing that others would perceive you based on your previous performance in a previous role? I definitely have. The allure of a demotion seems pretty real to me.
I think 'peers' is a good viewpoint. I used to think of it differently though.
Imagine if you didn't have managers, so you had to spend all day answering the phone and emails, sitting in boring meetings, getting interrupted to deal with people problems, making out TPS reports. You'd want to hire an assistant or secretary to do all that stuff for you so you could get some work done, right? Developers have that, we just call them manager or boss and they get the slot above us in the org chart.
That's not an insult, just a view of how things are different in development vs. traditional industry. A good manager is very valuable, and a lot of 'doers' wouldn't want that job even with the higher rank/status.
If you're a manager at a McDonald's, and you switch to being a programmer, were you demoted then too? I think every time I've heard the word 'demoted' it was in the context of staying on the same ladder. It just doesn't seem like the right word choice, even if it is arguably correct.
The title wouldn't be as interested if it was
"I followed my dreams to change my career a software developer"
I do not view career changes as a promotion or demotion. You're starting at neutral.
When I clicked the article I thought it would be about maybe a Senior Developer, Technical Manager or Architect going to developer...which...is kinda what happened to me (less meetings & responsibilities, more coding).
But alas the story had little relationship to what I expected.
As someone who reached quite a high rung on the ladder (from outward appearances anyway) in a different career path prior to development, I think it's really healthy to see it as a demotion or step down.
If you stay in denial and hang on to your old title or status, you will struggle coming to terms. Having relatively little influence over strategic decisions is super difficult as one example. Also no one really respects you for expertise you bring from a prior career either since they don't really know how to judge your "stature" in that field. Not to mention that if you mention it much at all, it can raise questions in colleagues minds about your dedication to the new field.
All that being said, I couldn't be happier with my change and am so much happier as a person.
It's tongue-in-cheek as a sibling commenter is saying, but I'd argue it's also quite literal.
She was running the Product Design team at SO, assumably managing people, and went on to work as a staff software developer.
I'm not making a judgement on the worth of the different jobs - I've been a manager, I'm now both a designer and a developer, and I personally prefer the latter above all else - and I don't think she is either. Maybe she even makes close to the same amount of money, who knows.
It's just that by most organizational standards it is a demotion. At any rate, I don't see any of it derogatory for neither developers nor product design managers.
An inspirational story that anyone, at any level, can always reinvent themselves given time, patience, and a plan. That said, "demotion" doesn't seem like the right word. Yes, going from Director to general population is technically a step down, but more realistically this is a lateral move. In a lateral move sometimes you get to keep your pay but almost never your rank.
Ah, so not a lateral move. Demotion does make sense in that case, though, I wish that outcome would be different. It seems like whatever skills and experience you bring with you would still be relevant, even in an entirely different domain.
I was prepared for that and expecting it. I also didn't start at the very lowest rung of pay for this role: they took into account my years of building up knowledge about our product and other non-programming skills like communication and design in determining my new salary.
Thanks for your insight. I'm at a similar crossroads currently and leaning toward staying in my current role. Basically about 14 years ago, I left a Fortune 500 company where I was a Network Administrator for a decade to go to a University and took a large pay cut to become an IT Analyst. Primary reason was wanting to get another degree, cheaply. After 7 years as an Analyst, I was promoted to manager of the team. After 3 years of that, I realized I wasn't good at managing people and I was a "do-er," and left from managing (with a HUGE paycut, again) to go back to Analyst in county government.
Fast forward 3 years and here I am, being asked to be an Interim-Director as the director here is now retiring and I'm the only one with management experience. They are then in turn 'encouraging' me to apply for the full time director position, saying how I'm the most qualified and despite the "promote from within" policy, they want me to go up against external candidates to "earn" the job they asked me to interim.
I've wracked my brain for a week now--I'm an engineer level do-er, I'm not a manager, but 22K a year is a NICE increase and I want to buy a home. Part of me says "thanks but no thanks, I'm not going to apply for a promotion to a job you obviously think I'm qualified for but won't offer out-right if its going to be a massive paradigm shift AGAIN for me," and another part says, "Dude, you're so dumb if you don't apply for a job that pays 30% more than you're currently making!"
I've got a couple weeks to decide--money isn't my driving factor, the ability to "turn off" at the end of the day is.
If you know you don't like managing, then no amount of money (okay, unless it's comically large) will make you like it. You even said it yourself - money isn't your driving factor.
I just get a feeling that no matter how privileged you are, how intelligent you are, how high or low a position you are in, or how much money you make there is going to be some random article on HN to make you feel insecure.
Probably due to the very poor and misleading article title, which frames the situation as a "demotion", something that happens to us, not something that we decide to do.
The article has a good message, but the title is absolute click-bait. Many people might come across the title, and although not interested in reading it, walk away with the idea that following dreams leads to negative consequences. I hope the author changes it.
Yeah, the title of the article is pretty poor. It kind of sounds like someone who was promoted from a developer to something else, rose to the level of their incompetence, then reversed the promotion to go back to doing what they enjoyed.
This person was not a developer previously, so I don't understand how they were "demoted." Other than management > individual contributor.
What really happened was they changed jobs to do something they found more fulfilling. Which is great, but if I decided to change careers to building furniture, I wouldn't say I "got demoted to making furniture."
They were director of design! I am not part of that company so it’s possible that director is a joke there but in most companies that’s the highest level prior to the c suite/owners (public company/professional services firms). That would mean she likely had immense autonomy and a large group of direct reports whom themselves had teams of direct reports. Going from that to “just a coder” ie one team member of one team responsible for only their contributions to their current projects.
In nearly every organization that would be a huge demotion WITH a huge pay cut. In this instance because coders are paid so much more than most other professions it’s possible it was a lateral move or even a pay raise! But no question as far as responsibility for the direction of the organization it’s a huge demotion.
> That would mean she likely had immense autonomy and a large group of direct reports whom themselves had teams of direct reports.
As someone who has worked at a variety of companies - this isn't true. It's just a title. I've seen plenty of "director of X" with no direct reports. I don't know how big Stack Overflow's design department is but with only 300 people in the company - I can't imagine it being massive enough to warrant a typical director title you'd see at some truly big corps where a director has 50+ people under them.
> Probably due to the very poor and misleading article title, which frames the situation as a "demotion", something that happens to us, not something that we decide to do.
Not seeing the connection with that and feeling inferior. I agree with your point, just still can't figure out the top level comment.
Not feeling inferior, but feeling insecure. The message in the title can easily reinforce people's insecurities and discourage them from pursuing their dreams, because they'll just get "demoted".
We have a fairly diversified economy. If you feel promotion is more important to you, pursue that. If you feel performing a different kind of task is important to you, pursue that. Neither is "better" in some absolute sense, much less moral sense.
Life is full of tradeoffs though sometimes they are easy and that's wonderful ("doing X isn't worth the money to me" or "I don't really like doing Y but I don't mind because the extra money will allow me to Z"). Some people couldn't care less about titles (e.g. me) while some people think they are even more important than pay (e.g. my mum who grew up in such a culture). I can't claim either is bad or wrong; people just have different itches to scratch.
The "choices" we should worry about are those forced upon people who don't actually have a choice ("I have to drag myself to my second minimum wage job because otherwise I'll be homeless").
If you want to be strict, sure. But there's no arguing that when people hear the term "demotion", it's almost universally regarded as a non-voluntary change of negative consequence. Perhaps if the title was "To follow my dreams I asked my manager for a demotion" it would be decent usage, but the current phrasing in the title is entirely misleading. It's probably the use of the word "got", implying that it was an external decision, not their own.
Not really if it’s by choice. She decided more to “retire” from being a director. A “demotion” is involuntary.
It’s not a demotion in the same way that voluntarily deciding on a career change from IC to management is not a promotion. A promotion is given to someone, not chosen by them.
The title undermines any message that the author may have cared about conveying. This is why I rarely read articles where the title has a whiff of clickbait.
I'm not the best messenger, but nothing is certain, and in some cases fighting against it makes you more susceptible to crushing disappointment.
If you want to go all the way to Eastern Philosophy, you can, but even without going into that, there comes a point where contingency planning is more fruitful than doubling down on trying to force a thing to happen no matter what.
Memento mori (remember you will die) as the Stoics say.
Certainty is an illusion, one that romantic partners and anxious bosses in particular don't want to hear about. Great insight for a smoke jumper, not so good for valentine's day or SLA violations.
I get a feeling you commented after reading the headline and didn't read the article. This is a positive story and I'm glad the person was given the opportunity to chase her dreams.
I second this wholeheartedly, it is a very positive story, albeit with a cheeky title. The article explains how a person in a "higher" position (director of design) made the active choice to change career path and start again as an associate developer.
It didn't come out of thin air, as this person had been coding as a hobby for a few years (Ludum Dare rocks!). So she actually did have some skills, though maybe not as formal or structured as say, a tech recruiter, might want to.
Furthermore, it's great that she is working in an organisation that would support such a change. It makes this career change much easier than having to quit your job and trying to get gigs or get hired without having formal credentials or experience.
Sometimes we by nature map self-worth to title... don't do it! At this point in my career, I'm a senior director, accountable for nine figures of turnover annually and driving things that truly matter and are meaningful to me. I'm reasonably good at what I do, and am blessed to have an incredible team. But, if I could make the money work and not have to relocate, I'd happily be a staff engineer again. I miss the technical problem solving (ie. learning alot about a thing vs. learning a little about 100 things), the small team and mentoring new people.
I'm not grousing, it's just a different set of things, but I think that I would miss the "perks" of what I do now less. It also makes an impression on me that for a brief window, technical "stuff" made me a rockstar to my nieces and nephews 10-15 years ago. Now, my 9 year old eyerolls at my "conference call commando" skills.
What you're ignorant of is intangible value. Sure there are managers and C levels that don't, but I'd bet that most are successful at creating value that you're just quite not able to see.
>but I'd bet that most are successful at creating value that you're just quite not able to see.
I did not say they create nothing, i just said that they should not be held to a higher "rank" than people who actually create something real, with that said there should not be a feeling of "demotion" from director to developer...quite the opposite in fact.
BTW: Look at your reaction, instantly calling me ignorant because i think managers are just gears in the system and NOT drivers.
Most of the value that Gates created was as a pure manager.
He was a programmer before, possibly amazing at it too, but I'd hardly say his role at Microsoft was that of an engineer-manager.
He regularly attended engineering meetings throughout his tenure as CEO (he says so in that Netflix mini-series about him) but by far his largest drivers for creating value were how he envisioned software eating the world (esp. the enterprise), and how he executed a commercial strategy to perfection to build a monopoly around that vision.
Not to downplay the difficulty of building operating systems at scale, or that Microsoft might have made some impressive innovations in the 80s and 90s, but they always had a reputation for their products being "OK" at best, so I'd argue their dominant position was acquired through wheelin' and dealin' more than anything else.
It might be harder, but could still be possible. Just because the US has lower taxes, doesn't mean expenses are the same (tons of variables) - just look at our healthcare costs.
Sure. No one can tell you exactly what job to apply, only you know what you'd really love. If you feel "trapped", start searching for something that you love doing (and also can get paid for that) that doesn't feel trapped. When you find it, you'll feel that it's the right thing.
If you want to get on the managerial side, you have to learn how to get people to listen to you and do what you ask of them. You have to become an annoyingly squeaky wheel and develop your soft-skill Jedi mind-tricks.
Or you can drop it all and start your business, which means all of the above plus sales plus lots of patience and little or no pay.
Otherwise, you can always change career completely.
I wonder how many other of us have had "non conventional" careers, stepping down from (whatever) higher paying positions in order to work as developers. Similar to the author of the article, I stepped down from management, took a pay cut, in order to become a developer. Eventually, after many years, my pay caught up and the temporary sacrifice was totally worth it.
I’ve been thinking about going the other way (developer->something else) and all I have to say is holy shit being in software is in many ways a godsend. When I look at other fields and the credentials required/pay it’s somewhat a marvel that some uneducated kid with barely no experience such as myself was able to get into what’s considered a high paying technical field.
Similar here. I took a 50% cut from a Director at an NGO to junior frontend developer (with a 8-month no earnings interval while I studied software development). Now, 4 years later, I am earning 6 times that pre-dev earnings.
I was in startups for 25 years, (except for a few years in an acquiring company), and I had this ongoing debate with myself and my bosses for many years: Should I stay on the technical side (developer, architect), or go into management?
On one hand, I thought that I "should" go into management because ... that's what people do, right? On the other hand, I loathed management. Even as a team lead, meetings made me literally sick to my stomach, (well, once).
I kept torturing myself with this decision over the years, until my boss cleared it up for me. He said that if I hated being a manager, that I would suck at it, and be constantly miserable. So don't do it. It was so obvious once he said it. So I didn't become a manager, and I never worried about it again.
> On the other hand, I loathed management. Even as a team lead, meetings made me literally sick to my stomach,
I don't know that you should use this criteria as the sole deal breaker. Managers should be shielding teams from unproductive meetings and pushing for productivity (action items) from the meetings that happen - holding their peers to a degree of standards.
Now, if you hate 1:1, org planning, and successful meetings, that's another thing.
Everything about it. Every moment spent organizing, planning, reviewing, coordinating, is just torture. If, at work, I am doing anything but working on code, or preparing to (researching, reading, etc.), I feel like I am wasting my time, and it is just draining. At the end of a work day, my mood is completely determined by how much time I spent on code.
I'm always thrilled to hear stories from people who have or reach this level of self-awareness, about what determines their mood/satisfaction. It's so wonderfully freeing to know yourself to that level, and understand part of what makes you tick internally.
I myself am a former-engineer and current-manager, and I also remember absolutely loathing meetings as a waste of time, explaining things to people who don't really care that much about what I have to say, and plus why should I contort myself to speak "their" language and why can't they be bothered to learn to speak "my" language as an engineer?
But over time, I think I've come to develop a taste for, the style of communication that happens in most typical business meetings. If you think about coding and entering a "flow" state, to me the core of that flow is being able to clearly and concisely conceptualize the software abstractions you have in your head, mapping them effectively from business concepts or technical requirements and into code, and being able to just churn out a beautiful representation of all those things into something tangible (an application, a service, etc.).
Believe it or not, in roundabout ways, meetings can achieve that kind of "flow" state as well, creating a shared understanding of a beautiful abstraction, and resulting in high-bandwidth exchange of ideas. Certainly it is much harder to achieve "flow" for meeting communication than for coding/engineering (IMHO at least) since it involves lots of other people with lots of different backgrounds and different levels of understanding, but I find that nonetheless it is something I can find enjoyment from the pursuit of that state. Not every meeting succeeds in reaching that "flow" state, but more and more I can perceive and introspect why/why-not it didn't, and come out with tangible lessons for myself for improving. So long as I have a flywheel for getting better, it doesn't feel so draining or so pointless anymore even when I "fail". And sometimes, I really do come out of the most productive meetings feeling very energized, and hearing from my peers how much clarity they gained or how much more confident they are about a decision that was previously questionable/uncertain, is truly a great feeling (at least as good for me, as producing a solid piece of beautiful code).
I feel this too. I've been working in industry since the early 2000s and for me I've known for a while now that I do not want to be a manager. There have been times where I've considered it, but like you, I find organizing, planning, reviewing, coordinating tortuous. I would rather design and implement a system, or work with others to do so, than spend time doing the meta-work to get work done.
That said, to get a title promotion, I've found that you have to do more of the organizing, planning, coordinating stuff to be noticed. Performance reviews are biased towards "the next step" in your career and companies are forever trying to get you to do more "meta-work" which I really dislike.
Exactly this! A couple of times in my career I've stepped over into management, and regretted it each time, in large part because I can never get to the point where the manager-y stuff "counts" as work; instead it's stuff that gets in the way of doing "real" work, so the job is constant misery.
I'm glad that people are becoming increasingly aware of this.
I found that I don't mind managing, but it's such a different type of work. As an IC I went home (before COVID anyway) mentally exhausted. As a manager I went home emotionally exhausted. Different people are better at recovering from either state of exhaustion.
The work of shielding my hypothetical team from useless meetings sounds just as miserable as the useless meetings themselves. Now that I think about it, my own boss shields us from these meetings primarily by taking the meeting himself.
I have this dilemma at the moment. My company has a management and non-management track. I feel like the company is pushing me up the levels and that all focus across engineering is on getting promoted to the next level. My problem is now that I've got to Staff level I feel like I'm a manager even though my manager insists I'm not. I hardly ever get to code, and my calendar is full of meetings. I spend a lot of time writing planning documents and having meetings about spreadsheets and OKRs and to be honest I absolutely hate it.
I've been trying to work out if it's like this everywhere, or if this is specific to my company. I spoke to a few people and they pretty much said "Yeah, the more senior you get the less you get to code". The articles I read about Staff Engineer level seem to imply it's more about architecture and planning.
I'm really tempted to demote myself back to Senior and just stick there, but I'd probably take a salary cut and I also feel like I'd taint my career and be viewed as a failure.
I thought we'd move forwards by creating twin tracks that means engineers don't automatically have to go into management to get ahead, but it feels like it hasn't changed that much. I know some people are great at that level of engineer role, and I can see why companies need it.
I keep coming back to the question: why do we take people who are good at coding and say "OK, you're great at that so I'm going to promote you into a role where you hardly ever get to do it"?
For what it's worth, I enjoy mentoring and explaining things, writing docs, and being involved in design of systems and influencing technical strategy. It's nice to be making technical choices. But when you're more familiar with a spreadsheet than an IDE, something has gone wrong.
Seniority to some degree is about enabling others and having the overview. The big problems are rarely the precise code being written (it /can/ be the case when working on a specific algorithm or something) but large parts are about architecture, code review, ... and understanding the business needs aside from core technical skills. If a senior shares their experience with 5 juniors it is (especially long-term) better spent than them hacking something alone.
At the companies that I've seen that have a good IC track, including some of the FAANGs, the staff+ level engineers are measured by impact. There are many ways to have that impact, and that could be by architecture, design and influencing technical strategy, or it could be by churning out tons of code, or it could be by highly specialized domain knowledge. It's fairly normal for staff-level engineers to spend a lot of time in meetings, but there are also staff engineers who spend most of their time coding.
>the staff+ level engineers are measured by impact.
That's a good description. And the reality is that while, as you say, there are master engineers who can crank out great inventions largely autonomously, the vast bulk do so in large part by mentoring and guiding others. I know many distinguished engineers and SDEs who are ICs. But at least the ones I know spend most of their time communicating and working with others. Open source project maintainers often describe themselves as primarily editors.
Some are actually managers (which carry more formal administrative responsibilities) and some aren't. But almost none of them are largely working on their own because it's really hard (especially outside of a research context and even then) to have maximum impact that way.
I really wouldn’t worry about “being viewed as a failure”. I think it’s admirable if you choose your passion over normality. You’ll be better at your work and at life, you’ll be happier and live longer.
Job titles are, in my humble opinion, a trap.
So my advice is to set boundaries. If you don’t want to be sitting in meetings, then stand your ground or come to a compromise. If they don’t understand then quit! Find the path for you, life is too short to be unhappy and someone else’s pencil pusher.
> I enjoy mentoring and explaining things, writing docs, and being involved in design of systems and influencing technical strategy
One of the great dilemmas is that these things are always interwoven with the non-technical aspects of being a manager. There is some aspect in which it is essential - "how long will this work take" depends intimately on the technical complexity, exactly how skilled the available resources are in the necessary areas etc. Other aspects are completely non-essential - "responsibility for staff completing health and safety training lies with line management". I would really like to see a model where these are disentangled.
This is exactly how I feel, except I also have technical responsibilities, meetings dominate my day. Some technical meetings sure, but a lot of status and syncs, and a lot of email. I'm lucky to get an hour a day between 9 and 5 to engineer. I've often fondly remembered when I had 3 meetings a week and the rest was just productive time and I could churn out code or work on workflow improvements, automation, etc.
> like I'd taint my career and be viewed as a failure
My old boss said: "on the way to work in the morning, you should be whistling". I'm from The Netherlands, and I'm not sure if it translates well. But that's the point where I thought that I love engineering, stopped caring about what others may think, and put my management ambitions in the freezer.
Five years further, and I'm slowly coming back to that decision, but in a much more natural way. I started freelancing, took on an apprentice, and slowly I'm getting more responsibilities. But in a natural way, not an all-or-nothing choice.
As a FAANG Staff engineer, yes my days are full of meetings (with coding breaks in the middle). I view the meetings as a way to solve technical problems beyond one person to solve alone, a way to scale my own impact - not LOC I wrote, but LOC I enabled. Fully agreed though that even as an IC, I feel like a manager, especially in COVID times, when a lot of junior engineers I work with need more TLC from their "leadership".
I'm looking at a career change (possibly to tech), and I can't help but wonder: is there a way to be one of these managers, but without being a coder first?
Weird question, I know. But I'm an advanced beginner of a programmer who knows that I'd make a better manager than a SWE. Almost would prefer to just leap-frog to management since, as it is, I'm already looking at a career change and know my strengths.
You have to have credibility with engineers to manage them or they will not respect you. At least at leading companies with a Silicon Valley type culture.
It's about more than knowing how to program, but rather the ins and outs of development, architecture, technology.
Plenty of more typical Fortune 500 type companies and small, non VC funded companies let managers from non engineering backgrounds manage engineers.
is there a way to be one of these managers, but without being a coder first?
There is, but probably not in a Software company, since they tend to prefer promoting experienced programmers to managers based on their tech skills (for better or worse)
Companies that work in logistics, banking, engineering etc. and have in-house software teams, but don't ship software as their primary business are far more open to hiring non-programmers as software team managers (for better or worse). If you have any domain knowledge about the area they're operating in that often weighs much higher.
My previous manager was non technical, my current manager is an ex-developer, it makes things a bit simpler to have an ex-developer as manager but it isn't 'that' different, it just meant that before I had to simplify the description of the issues, which is a good thing anyway (most of the time).
And the best thing my manager can do for our team is political: each team/site competes for the more interesting features to develop..
Do yourself, and your potential direct reports, and don't do this.
Maybe you would be a great manager, maybe you would be a bad one. But you would not be nearly as good as a person who is just like you but has also worked as a developer. You literally will not know what you are talking about, and the people you manage will see this, and that creates an unfixable problem between you and your developers.
I mean, the classic "couldn't you just ..." is bad enough from a manager who at least was on the receiving end of that suggestion, at some point in his or her career. But from someone who hasn't had that experience, it is so much worse. Maybe you would never use that phrase, but the dynamic is unavoidable. Much of what you do and say will be second-guessed and devalued.
I am quite happy being a developer. In this the tail of my career I'm happy to work as a consultant with peers, getting contracts and billable hours for all of us.
I never wanted management in a corporation. Used to be only half of America for instance worked in a big company. The rest of us worked in small business, or as individuals. That's changing I guess.
I hope there continues to be room for those of us who prefer a life to a career.
"Demoted" from a common perspective, promoted from a true perspective: life isn't that long to do something that you don't love, or at least that you love less. No matter how much less (if it does) they get paid, congratulations on following your dreams.
Her staying at her current company is a warning flag.
It doesn't sound like she went through any other interview process at other companies, so she doesn't yet have full understanding of what's required to be in software engineering field.
The most likely path is that she will be guided into some sort of Software Development Management role after couple of lackluster years as "software developer" role. Many, if not most, software engineers burn out after couple of years or get into comfort zone and stagnate or get moved into management roles.
There's huge propaganda push to get certain groups into software engineering, women, minorities, etc. The central planners decided software engineering field had to change. The motivation is mostly financial, they need to increase number of available candidates to drive down salary increases in software engineering.
The quality of candidates has suffered because of this push, men, women, etc. Most people are simply not interested in software engineering field. Some people find out too late, after spending too much money and time trying to pursue a career in software engineering.
I related to a lot of this and really appreciate the authenticity and how humble the author is. Good luck on this next chapter and congratulations on pursuing your dreams! Also: keep doing the side projects :-)
You are never "just a whatever" and you should not think of yourself like that. You are a human and you have just as much value as any other. Your life experience and views create the diversity that makes us all strong.
I studied a bachelor CS / master CS, having worked for 2 years (odd jobs as a dev), and I have to struggle interview after interview by myself. I dream about getting this kind of mentorship from a such an amazing company. Yet, when I apply to Stackoverflow, I don't even get a chance to be interviewed. The mentorship that she received is so super lucky, I hope she realizes that.
I'll bet you this: if I (or most CS master graduates from The Netherlands [1]) would receive a similar kind of treatment, then they'd nail that software developer position in terms of skill [2].
[1] I can't comment on other CS master programs, but I've followed lectures at: Utrecht, Amsterdam (both of them) and have seen what they're capable of at Delft.
[2] I'm not making claims about culture or communication.
Don't get yourself too down about it compared to her. She moved internally, has a lengthy employment history and was backed by her manager, there was no loss to the company here as knowledge of previous projects would stay with them. There is hardly any way to compete against that from the outside.
That and the related bits - hashing out nebulous requirements, agreeing on an approach, pinning down an estimate, coming to a consensus on what color to paint the bikeshed.
.. writing the code .. testing the code .. writing docs that show others how to test the code .. distributing the code .. getting the users through a few upgrade/update release cycles .. refactoring to a new product .. maintaining all of this .. writing docs to help others maintain all of this ..
> Most importantly, I was right: I thought I’d love writing code professionally, and it turns out, I do!
She must clearly not be writing JavaScript.
I love writing JavaScript applications, but not professionally. It’s a matter of actually building a product versus spinning your wheels with hundreds of megabytes of dependencies and stupidity and circular processes.
I love this story. I can intensely relate as I too have made the pivot from being a UX professional to software engineering a few years back. Sure I hadn't achieved anything close to being the director of design for a known tech firm; My design career was just starting to flourish when I'd made the move. But so much of the sentiment regarding confidence and self-doubt were the exact emotions that I had experienced . It felt as if there was this huge gap in knowledge that I'd never be able to fill. It took a lot of effort from me to overcome that fear of inadequacy and make the jump, so I know it must've not been easy for the author either. It's also funny how the activities she chose to express her desire to code - tinkering with Arduino, participating in Ludum Dare - were the exact stuff I was doing too!
Huge congrats to Kristina, and I hope her engineering career brings her as much joy and fulfillment as it has brought me.
I went from a Sr. Manager to Jr. Developer. The pay cut sucked. The first year working as a developer was rough. Everyone assumed that I knew a lot because of my age, but I was mostly a newbie.
Fast forward 8 years later, I am a Lead Developer and making double what I made as a Sr. Manager. I am still learning, I am still behind compared to my peers. Technology feels like it's moving too fast.
But in the end, the best part is to open my IDE and write code. It makes me the happiest.
I think any developer who feels like they have a 100% handle on all the new tech in their field... isn't paying enough attention :D feeling like there's more to learn is a way of life!
She may have felt superior to software developers, so in her eyes it may look like a demotion.
I run a small company which does software development and graphic design. i could describe myself as a CEO, entrepreneur, software engineer or graphic designer. But whenever someone asks me what my job is, I say "programmer". That's how I identify and IMHO it is a very challenging and honorable job.
As a non-technical professional (yes we also peruse HN), I can't stress enough the value of having career conversations early and often with your manager. It's not just HR mumbo-jumbo. OP's story is just one example of a potential benefit.
Most organizations actively try to support internal mobility (admittedly with varied success). Companies invest resources in hiring, training, and keeping you. Your manager, as a representative of the company, is wise to amicably transfer an unsatisfied employee to another part of the organization. And as a human being, they probably want to see you engaged and happy at work, even if it means losing you to another team. Plus in this example, OP was a high performer and had already shown initiative, putting in legwork to upskill themselves for the new role. Demonstrated value/performance and initiative are always helpful when asking for something of your employer.
Don't be dissuaded by cynical examples to the contrary - those who told their manager about other interests and suddenly and inexplicably got fired. Remember there are two sides to every story - for example, maybe they were underperforming and disengaged for a long time, and then randomly raised the question after their manager reached a breaking point? They won't share that in their post. Also remember availability bias - just because we see these people complaining on forums or "know a guy" doesn't mean it happens frequently enough in real life to be seriously concerned.
In the end you'd be surprised what you accomplish by simply talking to your manager early and often, having general conversations about potential aspirations and leaving the door open for them to say "How can I help?"
I don't know. For a sufficiently large change, it isn't necessarily in your company's best interest to try to keep you happy. You have banked knowledge and skill in X. You have limited skill in Y but wish to learn. The loss of some fraction of X is always going to hurt the company more than your gain in Y will benefit them, so they are going to try to keep you doing as much of X as possible for as long as possible. If they were to let you switch to Y, they'd have to have already needed a junior person there, and they will now have to replace the person doing X. Maybe this is a small vs large company thing, but I think it is entirely possible to "typecast" yourself into a corner such that the best thing you can do if you want to pivot is jump ship.
> it isn't necessarily in your company's best interest to try to keep you happy
This is true -- but your manager won't always act in your company's exact best interest either! I do think "management are human beings, too" is pretty important to remember.
> The loss of some fraction of X is always going to hurt the company more than your gain in Y will benefit them
I don't think you can assume this is always true. What if X is jQuery and Y is Typescript? Or X is oldLegacyCodebase and Y is newProjectInBurgeoningField?
In some cases, probably. But in others, bringing your knowledge of X into the team that does Y can be quite valuable. Consider the case of a former product manager who knows very well what the customers need from the product, and how they use it, and now also understands the code and dev process - any dev team can really use someone like that. A subject matter expert, someone who knows the industry, designer, or whatever, can bring a lot of value to a different role.
In addition to what other responders have said, another factor is that if you're a top (or better than average) performer in X, then the default assumption will be that you'll be a top (or better than average) performer in Y, given some time to ramp on Y.
That may or may not be true, of course, but it's an element in your favor either way!
(though fwiw, in my time as a past manager, I found that significant effort counted for a lot - it's cliche but folks who consistently put in extra effort and worked their butts off improved faster than those who relaxed, so they would soon exceed folks who relaxed, even if they had much less of a head start.)
And understanding what you're interested in. In spite of having an MBA, which has been at least somewhat useful (if only for being nearly a requirement for a somewhat different than today PM at the time), I've never had a great passion for managing people. And a semi-tech IC track has been fine for me through various iterations. And I've also done OK--at least enough--largely sticking with companies for many years. There are probably other paths that would have led to bigger paydays (or not) but I've been fine.
I find too many workplaces see the only way for a developer to move ahead in their career is to become a manager. I'm glad I don't work at such a place.
At my workplace those who really thrive on technical stuff can follow a path to technical glory and those who love the intricacies of managing people get to do just that. We end up with more competent managers and developers in the end.
Shaking off your former titles and successfully career changing is really hard to do, as I’m learning the hard way. Grats to her on her new opportunity!
Can someone explain to me why titles like Engineer, Architect, and Developer are perceived as having less value than titles like Manager or Director? Managing products requires a completely different skill set from managing people. Both skills are vital to the success of a business and neither are trivially developed or easily replaced.
If you ask me, the "demotion" in this article is not going from Director of Design to Software Developer. The demotion is going from a senior level position to an entry level one. But that's not how it's presented.
In a lot of companies Managers and Directors make more money than being a Developer. On top of that the perception of status is higher from the outside if you are a Director vs a Developer.
Smart tech companies have two paths, the management and the engineer path. Where they both have certain expectations but there is no pay ceiling. Bad tech companies tend to disregard this and there is a point that you can no longer get a raise unless you "move up" and become a manager.
> Smart tech companies have two paths, the management and the engineer path.
In my 25 working years, I've learned this is mostly lip service. Yes, there are ICs who make as much as a VP. But look at Amazon. There are maybe ten people in that company that are IC level making what VPs make. And thousands of VPs.
To be a VP, you have to be a really great manager. To get VP pay as an IC (ie. Distinguished Engineer), you have to be the best in the world in your field.
So yeah, it's possible to have equivalent tracks, but the reality is that you will never make as much as an IC than if you switch to the management track.
Absolutely true. Even non FAANG companies have that problem. For example in IBM you have to start producing new patents etc. In short the qualifications a VP vs an IC (as you called them) are in different stratospheres.
Making a big mistake as a manager can cost the company a lot more than a big mistake as an individual Engineer, Architect or Developer, especially if you consider that the latter roles will catch many of each others' mistakes.
The manager level can result in entire teams quitting, failing to support each other or an atmosphere where catching each others' mistakes is discouraged.
Some jobs are paid based (roughly) on the value they bring and others are paid based on the threat/cost of large mistakes.
The relationship between contribution and compensation is obvious. If you bring more value to the company, the company compensates you directly with a portion of that value.
But why does a position with greater risk necessitate greater compensation?
EDIT: Everything below here was in the original post. However, I re-read it and realized it had little to do with the relationship between risk and compensation.
I don't buy the idea that managers are liable for the mistakes of their reports. That would cause a snowball effect in large organizations, resulting in extremely high turnover for leadership positions.
Managers share some liability for their reports' mistakes, but they also share some reward for their reports' successes. Those liabilities and rewards are split across all of their reports, resulting in what are usually relatively stable positions within a company. A lazy manager can get along by just regularly pruning reports who produce more liability than reward.
> But why does a position with greater risk necessitate greater compensation?
There are various methods to address risk:
1. Avoid the risk
2. Reduce the risk
3. Transfer the risk
4. Accept the risk
When you buy insurance, you're doing #3. If you self-insure, you're doing #4. Either strategy requires putting some money towards premiums, the expected possible cost of the risk.
It's much cheaper to pursue #1 or #2. You're then saving an amount exactly equal to the premiums don't have to pay under #3 or #4.
Thus, you can pay a person to do #1/#2 a fraction of the equivalent cost of #3/#4 and still come out ahead.
> A lazy manager can get along by just regularly pruning reports who produce more liability than reward.
It’s a generally accepted principle in economics/finance that the more risk you take on, the more up-front compensation you can expect. This is less about the risk the reports pose to the manager and more about the risk of the manager position itself and the high opportunity for spectacular failure.
> Making a big mistake as a manager can cost the company a lot more than a big mistake as an individual Engineer, Architect or Developer, especially if you consider that the latter roles will catch many of each others' mistakes.
Of course anything is possible, but there is often a chain of managerial command (managers of managers) to catch mistakes. It's pretty hard for a single, middling manager to inflict costly mistakes anymore than an individual engineer. Also, I've seen management levels that are 0 - 1 subordinates deep (managers of none).
This is factually not true. Developers can make big mistakes to bring entire companies down with them. Of course it depends on the definition of "mistake". However I can claim that a single defect caused by a developer can cost the company money and downtime, if nothing else a bad user experience.
Managers don't generate defects. Developers do. Not to mention that a lot of the times it's much harder to reverse an engineering decision vs a managerial one.
Most outages are caused by developers and IT, not managers. This perception that there is higher risk as a manager is false. As a developer I make multiple decisions daily, interpret vague requirements, make judgement calls, request new technologies etc. My manager understands about 20% of the decisions I make. Here is the kicker since I work in DevOps, with a super heavy emphasis on the Dev side. 70% of my decisions have wide ranging effect, much wider than my manager's eight person team.
Finally note that no one really talks about 10x Managers, but people talk about 10x Developers. Why is that? Managers are glorified cheerleaders. Most managers are average, their value is vague but they are controlled by managers so its an endless loop till you hit the worker layer that get things done.
You sound like someone who has never been a manager or has no idea what a manager does.
Yes, you're right that defects are made by developers. But you'd be hard pressed to find an example of a software defect that destroyed a company. Even if you as a DevOps engineer cause your company to be down for a day, it probably would have little effect on your company's bottom line.
I was in charge of Reliability for Netflix. Our whole site was down for Christmas Day one year. No one was fired, and it barely affected anything. That was a pretty major defect.
However, the way that management handled that outage had a huge effect on the company surviving that incident. Making sure we focused on the right problems to solve to prevent it from happening again. Creating entire new groups of engineers and then hiring them to solve specific problems of moving traffic between regions.
So yeah, management is really important, and a good manager is definitely more effective than a single engineer. And management decisions can destroy a company, but I doubt you can find even one example of a single engineer's decision that took down a company.
I was a Sr Manager for about 4 years, two different "teams", one IT based, one QA based. Regardless, perhaps we need to define the word "Manager", mainly because your example said:
> Creating entire new groups of engineers and then hiring them to solve specific problems of moving traffic between regions.
Albeit admirable, like heck yeah that was a great outcome, it's not a manager decision. Most likely it was a VP or Sr Director decision. Perhaps a manager brought it up as an idea. So if we are talking about Sr Director's+ then yes, their decisions can absolutely bring down a business. Granted I am not familiar with Netflix's org chart so perhaps it works differently, from some basic reading it looks like Netflix follows a decentralized command of sorts.
My beef with the original poster was the implication of risk. Both managers and devs have risk with their decisions. It's not just a manager thing. In the end, when Netflix went down where did the mistake come from? A manager or an architecture decision? Probably it was both.
> In the end, when Netflix went down where did the mistake come from? A manager or an architecture decision? Probably it was both.
In that particular case it was an engineer making a mistake, but my point was that it wasn't anywhere close to a fatal mistake.
But more importantly, when a team had repeated technical failures, it was usually the manager who suffered the consequences. Especially if their failures were causing problems with other teams.
The manager had the higher risk job because they were blamed for their team's failures. Therefore they had to be compensated to account for that risk to their job.
It's the same reason CEOs get huge golden parachutes. Because their job is constantly at risk for not only their decisions but the decisions of everyone below them. So they get compensated for that risk.
Yeah, managers higher up have a strong incentive to create compensation structures where managers are paid more the more people they manage. But like, being a manager doesn't say much at all about what you do. A non technical manager who managers engineers doesn't add much value and instead the engineers will be mostly self organizing, as such they are mostly there to provide administrative support. Your average office worker can do that, there is no reason such managers should be well compensated unless they also do other work like product management or similar.
When you make a decision as a manager or a director, the impact of that decision has a multiplicative force.
As an individual contributor, the impact of your decisions may be broad, but however broad your individual impact is, your manager's impact on you is [broad * number of directs], so it's always "greater" (note: not better, just greater).
So in that sense, the "value" of a manager/director is "higher".
IMO it's all just a series of roles, and you need someone to do both. Someone has to be designing and building code while someone else attends meetings and understands the larger context of that code, making sure the code makes sense a week/month/year later.
In fact, I prefer it when managers take on a much less "HR" role, and instead act as "go-fers" for their team, a la "how can I unblock you today?". Bonus points if they can mentor, but not necessary.
Being an individual contributor isn't a "demotion", but it is a change in where your impact hits (people vs. things). You need both, and it's fundamentally a partnership, I wish more people realized that.
> So in that sense, the "value" of a manager/director is "higher".
That depends on how high the multiplier is and how many direct reports a manager has. A manager with 5 direct reports and a multiplier of 110% is only producing as much net value as 0.5 of his/her reports. A manager with 20 direct reports and a multiplier of 106% produces a net value of 1.2 of his/her reports.
It's not safe to say that managers in general produce more value. Some do, some don't. It depends on their ability and the abilities of those they share a management relationship with. But the same could be said about engineers/architects/devs.
Much more importantly, it depends on the multiplicative effect that an engineer is positioned to have.
It's 2002. Does a Kohls Director Of Whatever with tens of direct reports and thousands of people below those reports have more leverage than a single engineer at Amazon?
It's 2021. Does a manager of hundreds of warehouse workers have more leverage/impact potential than a single engineer in a robotics R&D division?
Totally fair. The potential impact a manager can have is much higher (good manager multiplying their positive impact across good engineers), but an ineffective manager can be less impactful (or even actively harmful) to their direct reports (bad engineer multiplying their negative impact across bad engineers).
> When you make a decision as a manager or a director, the impact of that decision has a multiplicative force.
Every time I hear this explanation, I can't help but think "so we're still smoking Luck Strikes, huh?"
When you make a decision as a software engineer, the impact of that decision can often have a multiplicative or even exponential force.
The goal of 21st century organizations -- especially software organizations -- should be to make things scale in way that's at most sublinear with the number of people you throw at it.
Automation prints money and businesses that can harness automation have huge profit margins.
People are expensive and body shops are shitty companies waiting to be replaced when technology catches up with whatever work they're throwing bodies at.
It's not 1960 anymore. Invest in your automators and treat your people managers as a low-value-add cost center.
And, more importantly, what might be the massive unintended consequences of routing your org's permission structure in the same way you route its head-count?
Strategic decision-making is not the same as people managing, and people managing can even create blind-spots that get in the way of good decision-making.
A manager (who said anything about people manager? I even explicitly said otherwise) knows what to build because she's coordinated with the groups who spend their entire day focusing on the customer, as well as the other developer groups to make sure everyone isn't working on the same thing, as well as leadership so they know what's being built and how it aligns with their goals and vision into the market (because that's what their expertise is in), as well as within her own team to make sure people are building things that can work together smoothly/cleanly, as well as covering for people who have illness/unavailability, and so on...
Would you rather have developers wearing every hat in an org? When would they find time to code? I know many developers who don't want to have to do all of that work simultaneously, and are extremely grateful for a manager who can take many of these tasks off their plate.
When was the last time you tried to add a recurring meeting to a development team's calendar? They... don't like it, in my experience, and I respect the hell out of that.
Where did I say we don't need managers? I explicitly said otherwise: Invest in your automators and treat your people managers as a low-value-add cost center.
Just because you treat something as low-value-add or admit it's a cost center doesn't mean you don't need that work to happen!
> When was the last time you tried to add a recurring meeting to a development team's calendar?
Yes, I agree, managers' secretarial and political work is incredibly important to the success of an org. But the 1960s idea that it's a "force multiplier" worth high comp is a mistake.
I'm not contesting whether managerial work is important or necessary or to be respected. I'm contesting the idea that managerial work is a force multiplier for individual contributors, in any sense other than in the same sense that janitorial work or admin assistant work is a force multiplier. The only orgs where I've seen managers to be actual force multipliers were body shops.
A good manager is worth 10x a good developer, and a good developer managed by a good manager is 100x base developer value.
This is why managers often get paid more, and it applies even more the further up the chain you go. A good CEO is worth every single penny of the millions they get paid, because of the multiplicative force they have on everyone below them on the org chart.
Even those tiny orgs follow what I'm talking about, you're mistaking bloat for specialization.
The skills involved in figuring out what to build are entirely separate from the skills involved in building, and you are making the classic mistake of worshiping the skill of building to the exclusion of all other skills.
It is much rarer to know what to build than it is to know how to build.
> Even those tiny orgs follow what I'm talking about, you're mistaking bloat for specialization.
Right. The whole thing is a silly tautology.
Good managers are force multipliers. Better hire good managers! and then if they don't force multiply they must not have been good managers :(
It's literally an unfalsifiable tautology.
> The skills involved in figuring out what to build are entirely separate from the skills involved in building, and you are making the classic mistake of worshiping the skill of building to the exclusion of all other skills.
"Knowing what to build" is not what 90+% of managers do.
No, it is not a tautology. You are misusing that word.
A good manager will improve the performance of her direct reports. If you can't understand this fact, then I don't think you and I have anything more to discuss.
> A good manager will improve the performance of her direct reports.
Right. A good manager indisputably force multiplies because a good manager is defined as someone who improves the performance of her direct reports...
Importantly, any empirical evidence that less management structure improves outcomes is easy to dismiss because it's really just proof that the particular manager/company that failed wasn't a "good" manager/management structure. After all, if they were "good", then the output of engineers would have been multiplied, right?!
Tautology (n): a statement that is true by necessity or by virtue of its logical form.
Saying that we know good managers force multiply by improving performance of reports -- and then defining "good" to mean "improve the performance of her direct reports" -- is absolutely a tautology.
More importantly, ignoring empirical evidence by making a rational appeal to the truth of this tautology creates a rather pointless conversation.
Given the choice between blind faith in a tautology that "good managers = good" and empirical evidence that sometimes "less emphasis on/power for managers = better", I prefer the latter.
> When you make a decision as a manager or a director, the impact of that decision has a multiplicative force.
The above resonates as an exercise in tautology to me. If the job of a manager is defined as a position in which a person's decisions will have a multiplicative force... well... then of course their decisions will have a multiplicative force! Though I'm not sure the above is even remotely true for the vast majority of management-type positions, save those at the highest-level. And even if it is... then it of course a fact that the value derived from an individual in such a position is therefore not related to the "multiplicative force", rather, the decisions themselves.
I'd wager most managers come from two camps (the first two below):
1. Those that are ex individual contributors who have accumulated enough seniority and experience to best-understand not "what to build", but rather, "how to build it best". And are therefore given the authority, responsibility, and pay-check to do so.
2. And those who are not really managers at all, and whose job would be more accurately named "coordinators". This seems to be the role you are hitting on at end. You know, the guy who asks the engineers "how can I unblock you today?" and whose explicit role is to have the authority to act on the answer. Notably, not synthesizing the answer in the first place.
3. The third camp is of course the ones to which you seem to be alluding in your comment. The high-level, c-suite, "director of strategy"-type roles. And you are exactly right about them. Clearly the person deciding which widget needs to be built is in a position of tremendous responsibility when the value they can add (and remove) is extremely consequential (assuming the resources required to do so are equally consequential). There aren't many roles like this in a company.
It's the second group of "managers", I think, that the OP is confused about. They don't actually make that many decisions, and the ones that they do make are rarely different from the one their most competent reports wouldn't also make. Sure these "managers" sit in meetings and talk about the larger context of the code, the product vision, etc., but only insofar as that its useful to have someone who can distill and relay this information back to the engineers building the product. Because as an engineer it is, of course, nearly impossible to build a truly great product if you don't understand its larger context. It is this group of managers where the tautology is glaring. It is their job to carry-out the work necessary to multiply force. The work isn't all that creative, doesn't require much judgment, and rarely requires much expertise. The value isn't in multiplying force, it's in just showing up...
To clarify, I'm not suggesting managers don't have value, and certainly don't believe there doesn't exist a spectrum between those in the position. Some people multiply force more than others. They know to ask "how can I unblock you today?". They know that Jim doesn't like to be bothered before 11AM. That Susan is more productive if she has a tight feedback loop. Or that Ron isn't as good as Pam at test coverage. They know how to find and exploit people strengths while also minimizing their weaknesses. This is valuable.
Even so I'd wager most of the time a manager's pay is calibrated such that they make more than those whom they manage regardless of the value these people (the people being managed) contribute and without any sort of rigorous appraisal of how much value they bring or how much force they multiply. How could you? The skills illustrated above can't easily be captured in a pay band...
> As an individual contributor, the impact of your decisions may be broad, but however broad your individual impact is, your manager's impact on you is [broad * number of directs], so it's always "greater" (note: not better, just greater).
But this is obviously false, right? If the IC is truly a spectacular IC, then it's likely that no matter which manager they're under, they will have large impact.
The impact of the manager isn't the entire impact of their directs, but rather the relative difference between the impact of their directs and the impact their directs would have under a different manager. Which is substantially less, and could easily be less than the impact of a particularly strong IC.
As companies get larger and larger, the need to manage people becomes even greater challenge. The C level people start to disassociate from "tech" people and start associating more with "management". Even guys that start out as engineers, Mark Zuckerberg, Bill Gates, etc. get swallowed up by management layer deep state.
You'll start noticing when the "Star" employees of the late stage start up are more from HR, director groups, instead of product, tech, etc.
A single developer developing an app vs large team building an enterprise SAAS application have exponential differences.
Switching from (Senior) Developer Advocate to Software Engineer (2) at Microsoft. Both jobs are on the same ladder / pay scale and in the same engineering org. I was promoted just last September and am effectively undoing my promotion.
I had never worked as a SWE/SDE 100% of my time. I have a Math & CS degree and have built lots of random integrations, apps, and created technical architecture designs / product requirements.
I realized I enjoy projects where I get to code or dive deep into technology best. I also want a role that is easier understood by industry across companies.
The hope is that I can perform well to quickly get promoted back to my current job level (and compensation).
308 comments
[ 3.1 ms ] story [ 247 ms ] threadYour new headline would be better but it wouldn't have attracted any views.
[1] (https://www.reddit.com/r/Jokes/comments/ab5oht/a_violists_3_...)
If you want to move up and someone else is iffy on it, sure, skip the raise to help convince them.
It's a matter of who is prompting the move, and what extra responsibility is required and such. If your boss asks you to take on more responsibility, ask for more money. That's really all I'm saying.
Complete BS. If they offer it to him, they think he would be a good fit and they're just trying to pay less. Contrast it with my experience, where I just stepped up to fill the gaps whenever I saw them, my boss noticed, offered a lead position including pay bump.
It's not the rewards up front, it's the rewards as-you-go. Or it's the rewards at the end of the previous rank.
Always having your pay 1yr behind your responsibilities is wrong. You're doing the job, you get the pay.
On day 1 of being a lead, you've never been a lead before, but you are now. Year 1 leads get lead pay.
"You've done great, you're at the top of your rank! No, I can't reward you for it yet, just start at the next rank and we'll wait and see pleasethankyou." No. We saw. Pay me.
The same people end up at the same end rank, they just take lower pay for a year to get there. And that one year drag compounds because raises are %.
Anyway we're likely disagreeing in an entirely vague way. Of course my leadership skills should be evident if I'm going to ask to be Lead, so yes day1 leads aren't starting from 0. But a company's surest bet for who to hire as Lead is me, so why should I put up with them telling me they just aren't sure yet? All hires into new roles are very uncertain, and I'm the most certain, so I get the role. Someone more certain than me is a person with 2yrs of Lead on their resume, but they get Lead 3 pay, and I'm not asking for Lead 3 pay. You're hiring a Lead 1 and I'm sure surest bet (inside the org or out) and we all know it.
Or go ahead whisper promises of a promotion in the ears of two on my team and watch them butt heads as they try to act out the phantom authority you've given them. A politicking horserace like that has a vastly worse impact on the company than just pulling the trigger and naming one of us Lead 1 even if we're obvious greenboots for a year.
When exactly did this extortionary tactic started? There are so many things that go unquestioned...
In my case it wasn't even to get noticed. I just care about stuff. My current boss is actually trying to make me 'care less'. Like I can't leave it alone if I see the PMs do a crap job and I try to fix it. I can't not say something when I see the DevOps guys not taking care of the dev envs and dev experience.
Also when did this start? Like hundreds of not thousands of years ago. Why?
1. I mean - assuming no life changes which you should never feel guilty about making to suit your own interests.
Sometimes people working in tech lose sight of why they went into this field. The author's enthusiasm is a great reminder why. Fantastic article.
These two are quite different:
I followed my dreams and got demoted to software developer
I follow my dreams and got promoted from Development Team Team to Software Developer
After reading this, I’m just genuinely happy for the author. I think that not everyone is in a position to do that kind of thing, but for those who can, I wish we all had that kind of courage and the willingness to put in the extra work to make it happen.
For context, my last job change was also a diagonal step down and an overall step up in happiness. Not as dramatic though. I also did it because I felt like I was innately more suited to a different role.
But it is a demotion! I think perhaps we view that as a negative thing when it's done as a punishment, or due to factors outside one's control. But in this case, she chose it (indeed, worked for it!), so she must think it was worth it.
Her rank is literally demoted. She went from being high on the job ladder ("Director") to low on the job ladder ("Associate"), reflecting the fact that she's still developing the capabilities needed to do her new discipline. I guess maybe if one viewed this as a commentary on management vs IC work, it could be seen negatively -- but I didn't personally interpret the framing that way.
Ditto for status - she likely went from having lots of soft power due to her time and relationships in the design org, to essentially starting over in the development org.
Are these bad things? I don't think so. Presumably she was pretty clear on the short-term negative impacts of the change, and still wanted it.
I guess you and I are taking a more literal definition of demotion, whereas others may interpret it through the lens of the feelings of shame that would normally come with it, or perhaps even through a more "anarchist" view that no man is ever above any other.
Org-charts are about management structure and directors weirdly get very highly placed on them while their role isn't person-management driven. I've always found them exceeding strange except in their highlighting of SMEs and to aide in inter-departmental communication.
But this all may just be the socialist in me shining through as someone working with a team to make widgets that do their thing well.
I don't actually know what her role was, but I'm not sure it matters too much. Typically, I've seen directors in two kinds of capacity: people management or strategic/technical vision. For both of them, there's a ladder. For example your career progression might look like:
- Manager, Senior Manager, Director - Product Designer, Product Design Lead, Director
In both cases, "Director" isn't an entry-level role. You don't get hired into it fresh out of school, for example, and your scope of influence is expected to be much larger (regardless of whether you're influencing people or vision) than someone at the "bottom".
By contrast, her new role (Associate Developer) _is_ an entry-level role.
That's where I think the "demotion" terminology makes sense. I also agree with other commenters who note that it's most likely meant in a tongue-in-cheek way to drive clicks. But for me, there's a bit more to it than just the cheeky clickbait headline. Have you ever wanted to change things up at your company, but felt constrained, knowing that others would perceive you based on your previous performance in a previous role? I definitely have. The allure of a demotion seems pretty real to me.
Imagine if you didn't have managers, so you had to spend all day answering the phone and emails, sitting in boring meetings, getting interrupted to deal with people problems, making out TPS reports. You'd want to hire an assistant or secretary to do all that stuff for you so you could get some work done, right? Developers have that, we just call them manager or boss and they get the slot above us in the org chart.
That's not an insult, just a view of how things are different in development vs. traditional industry. A good manager is very valuable, and a lot of 'doers' wouldn't want that job even with the higher rank/status.
I do not view career changes as a promotion or demotion. You're starting at neutral.
When I clicked the article I thought it would be about maybe a Senior Developer, Technical Manager or Architect going to developer...which...is kinda what happened to me (less meetings & responsibilities, more coding).
But alas the story had little relationship to what I expected.
Ok, it was a reduction in rank, but an increase in status (if you ask most software engineers) ;)
If you stay in denial and hang on to your old title or status, you will struggle coming to terms. Having relatively little influence over strategic decisions is super difficult as one example. Also no one really respects you for expertise you bring from a prior career either since they don't really know how to judge your "stature" in that field. Not to mention that if you mention it much at all, it can raise questions in colleagues minds about your dedication to the new field.
All that being said, I couldn't be happier with my change and am so much happier as a person.
She was running the Product Design team at SO, assumably managing people, and went on to work as a staff software developer.
I'm not making a judgement on the worth of the different jobs - I've been a manager, I'm now both a designer and a developer, and I personally prefer the latter above all else - and I don't think she is either. Maybe she even makes close to the same amount of money, who knows.
It's just that by most organizational standards it is a demotion. At any rate, I don't see any of it derogatory for neither developers nor product design managers.
Fast forward 3 years and here I am, being asked to be an Interim-Director as the director here is now retiring and I'm the only one with management experience. They are then in turn 'encouraging' me to apply for the full time director position, saying how I'm the most qualified and despite the "promote from within" policy, they want me to go up against external candidates to "earn" the job they asked me to interim.
I've wracked my brain for a week now--I'm an engineer level do-er, I'm not a manager, but 22K a year is a NICE increase and I want to buy a home. Part of me says "thanks but no thanks, I'm not going to apply for a promotion to a job you obviously think I'm qualified for but won't offer out-right if its going to be a massive paradigm shift AGAIN for me," and another part says, "Dude, you're so dumb if you don't apply for a job that pays 30% more than you're currently making!"
I've got a couple weeks to decide--money isn't my driving factor, the ability to "turn off" at the end of the day is.
What makes you say this? An entry level SWE is lateral to a director who is presumably multiple rungs up on the org chart?
It isn't one of those "in six weeks I turned my side gig into a Nobel-prize winning web site and now I'm a billionaire" clickbait articles.
The article has a good message, but the title is absolute click-bait. Many people might come across the title, and although not interested in reading it, walk away with the idea that following dreams leads to negative consequences. I hope the author changes it.
This person was not a developer previously, so I don't understand how they were "demoted." Other than management > individual contributor.
What really happened was they changed jobs to do something they found more fulfilling. Which is great, but if I decided to change careers to building furniture, I wouldn't say I "got demoted to making furniture."
In nearly every organization that would be a huge demotion WITH a huge pay cut. In this instance because coders are paid so much more than most other professions it’s possible it was a lateral move or even a pay raise! But no question as far as responsibility for the direction of the organization it’s a huge demotion.
As someone who has worked at a variety of companies - this isn't true. It's just a title. I've seen plenty of "director of X" with no direct reports. I don't know how big Stack Overflow's design department is but with only 300 people in the company - I can't imagine it being massive enough to warrant a typical director title you'd see at some truly big corps where a director has 50+ people under them.
I don’t know what one calls the director of directors, though.
Not seeing the connection with that and feeling inferior. I agree with your point, just still can't figure out the top level comment.
Life is full of tradeoffs though sometimes they are easy and that's wonderful ("doing X isn't worth the money to me" or "I don't really like doing Y but I don't mind because the extra money will allow me to Z"). Some people couldn't care less about titles (e.g. me) while some people think they are even more important than pay (e.g. my mum who grew up in such a culture). I can't claim either is bad or wrong; people just have different itches to scratch.
The "choices" we should worry about are those forced upon people who don't actually have a choice ("I have to drag myself to my second minimum wage job because otherwise I'll be homeless").
It’s not a demotion in the same way that voluntarily deciding on a career change from IC to management is not a promotion. A promotion is given to someone, not chosen by them.
"I followed my dreams, left management, and love being a coder again" might be more on target.
Demotion has a very negative connotation.
Well, it is a demotion, though: "reduction in rank or status".
And it's interesting here exactly because it was by choice.
There are other ways to look at the world. In some ways they can be both more and less stressful than contemporary western ideology.
If you want to go all the way to Eastern Philosophy, you can, but even without going into that, there comes a point where contingency planning is more fruitful than doubling down on trying to force a thing to happen no matter what.
Memento mori (remember you will die) as the Stoics say.
Certainty is an illusion, one that romantic partners and anxious bosses in particular don't want to hear about. Great insight for a smoke jumper, not so good for valentine's day or SLA violations.
It didn't come out of thin air, as this person had been coding as a hobby for a few years (Ludum Dare rocks!). So she actually did have some skills, though maybe not as formal or structured as say, a tech recruiter, might want to.
Furthermore, it's great that she is working in an organisation that would support such a change. It makes this career change much easier than having to quit your job and trying to get gigs or get hired without having formal credentials or experience.
Sometimes we by nature map self-worth to title... don't do it! At this point in my career, I'm a senior director, accountable for nine figures of turnover annually and driving things that truly matter and are meaningful to me. I'm reasonably good at what I do, and am blessed to have an incredible team. But, if I could make the money work and not have to relocate, I'd happily be a staff engineer again. I miss the technical problem solving (ie. learning alot about a thing vs. learning a little about 100 things), the small team and mentoring new people.
I'm not grousing, it's just a different set of things, but I think that I would miss the "perks" of what I do now less. It also makes an impression on me that for a brief window, technical "stuff" made me a rockstar to my nieces and nephews 10-15 years ago. Now, my 9 year old eyerolls at my "conference call commando" skills.
Maybe have a look at Gates and Musk who are actually engineers rather then Managers....or more correct Managing-Engineers.
But congratulation for your "demotion".
I did not say they create nothing, i just said that they should not be held to a higher "rank" than people who actually create something real, with that said there should not be a feeling of "demotion" from director to developer...quite the opposite in fact.
BTW: Look at your reaction, instantly calling me ignorant because i think managers are just gears in the system and NOT drivers.
https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...
Any big organization will optimize for people who can extract as much value from their peers/subordinates and present it as their own.
By the way, this does not mean they are not smart or hard working, but you could say the same about any other worker.
He was a programmer before, possibly amazing at it too, but I'd hardly say his role at Microsoft was that of an engineer-manager.
He regularly attended engineering meetings throughout his tenure as CEO (he says so in that Netflix mini-series about him) but by far his largest drivers for creating value were how he envisioned software eating the world (esp. the enterprise), and how he executed a commercial strategy to perfection to build a monopoly around that vision.
Not to downplay the difficulty of building operating systems at scale, or that Microsoft might have made some impressive innovations in the 80s and 90s, but they always had a reputation for their products being "OK" at best, so I'd argue their dominant position was acquired through wheelin' and dealin' more than anything else.
Or don't.
It's your life.
Or you can drop it all and start your business, which means all of the above plus sales plus lots of patience and little or no pay.
Otherwise, you can always change career completely.
I was in startups for 25 years, (except for a few years in an acquiring company), and I had this ongoing debate with myself and my bosses for many years: Should I stay on the technical side (developer, architect), or go into management?
On one hand, I thought that I "should" go into management because ... that's what people do, right? On the other hand, I loathed management. Even as a team lead, meetings made me literally sick to my stomach, (well, once).
I kept torturing myself with this decision over the years, until my boss cleared it up for me. He said that if I hated being a manager, that I would suck at it, and be constantly miserable. So don't do it. It was so obvious once he said it. So I didn't become a manager, and I never worried about it again.
I don't know that you should use this criteria as the sole deal breaker. Managers should be shielding teams from unproductive meetings and pushing for productivity (action items) from the meetings that happen - holding their peers to a degree of standards.
Now, if you hate 1:1, org planning, and successful meetings, that's another thing.
I myself am a former-engineer and current-manager, and I also remember absolutely loathing meetings as a waste of time, explaining things to people who don't really care that much about what I have to say, and plus why should I contort myself to speak "their" language and why can't they be bothered to learn to speak "my" language as an engineer?
But over time, I think I've come to develop a taste for, the style of communication that happens in most typical business meetings. If you think about coding and entering a "flow" state, to me the core of that flow is being able to clearly and concisely conceptualize the software abstractions you have in your head, mapping them effectively from business concepts or technical requirements and into code, and being able to just churn out a beautiful representation of all those things into something tangible (an application, a service, etc.).
Believe it or not, in roundabout ways, meetings can achieve that kind of "flow" state as well, creating a shared understanding of a beautiful abstraction, and resulting in high-bandwidth exchange of ideas. Certainly it is much harder to achieve "flow" for meeting communication than for coding/engineering (IMHO at least) since it involves lots of other people with lots of different backgrounds and different levels of understanding, but I find that nonetheless it is something I can find enjoyment from the pursuit of that state. Not every meeting succeeds in reaching that "flow" state, but more and more I can perceive and introspect why/why-not it didn't, and come out with tangible lessons for myself for improving. So long as I have a flywheel for getting better, it doesn't feel so draining or so pointless anymore even when I "fail". And sometimes, I really do come out of the most productive meetings feeling very energized, and hearing from my peers how much clarity they gained or how much more confident they are about a decision that was previously questionable/uncertain, is truly a great feeling (at least as good for me, as producing a solid piece of beautiful code).
That said, to get a title promotion, I've found that you have to do more of the organizing, planning, coordinating stuff to be noticed. Performance reviews are biased towards "the next step" in your career and companies are forever trying to get you to do more "meta-work" which I really dislike.
I found that I don't mind managing, but it's such a different type of work. As an IC I went home (before COVID anyway) mentally exhausted. As a manager I went home emotionally exhausted. Different people are better at recovering from either state of exhaustion.
For what it's worth, I enjoy mentoring and explaining things, writing docs, and being involved in design of systems and influencing technical strategy. It's nice to be making technical choices. But when you're more familiar with a spreadsheet than an IDE, something has gone wrong.
But as always: ymmv
That's a good description. And the reality is that while, as you say, there are master engineers who can crank out great inventions largely autonomously, the vast bulk do so in large part by mentoring and guiding others. I know many distinguished engineers and SDEs who are ICs. But at least the ones I know spend most of their time communicating and working with others. Open source project maintainers often describe themselves as primarily editors.
Some are actually managers (which carry more formal administrative responsibilities) and some aren't. But almost none of them are largely working on their own because it's really hard (especially outside of a research context and even then) to have maximum impact that way.
So my advice is to set boundaries. If you don’t want to be sitting in meetings, then stand your ground or come to a compromise. If they don’t understand then quit! Find the path for you, life is too short to be unhappy and someone else’s pencil pusher.
One of the great dilemmas is that these things are always interwoven with the non-technical aspects of being a manager. There is some aspect in which it is essential - "how long will this work take" depends intimately on the technical complexity, exactly how skilled the available resources are in the necessary areas etc. Other aspects are completely non-essential - "responsibility for staff completing health and safety training lies with line management". I would really like to see a model where these are disentangled.
My old boss said: "on the way to work in the morning, you should be whistling". I'm from The Netherlands, and I'm not sure if it translates well. But that's the point where I thought that I love engineering, stopped caring about what others may think, and put my management ambitions in the freezer.
Five years further, and I'm slowly coming back to that decision, but in a much more natural way. I started freelancing, took on an apprentice, and slowly I'm getting more responsibilities. But in a natural way, not an all-or-nothing choice.
Weird question, I know. But I'm an advanced beginner of a programmer who knows that I'd make a better manager than a SWE. Almost would prefer to just leap-frog to management since, as it is, I'm already looking at a career change and know my strengths.
It's about more than knowing how to program, but rather the ins and outs of development, architecture, technology.
Plenty of more typical Fortune 500 type companies and small, non VC funded companies let managers from non engineering backgrounds manage engineers.
There is, but probably not in a Software company, since they tend to prefer promoting experienced programmers to managers based on their tech skills (for better or worse)
Companies that work in logistics, banking, engineering etc. and have in-house software teams, but don't ship software as their primary business are far more open to hiring non-programmers as software team managers (for better or worse). If you have any domain knowledge about the area they're operating in that often weighs much higher.
And the best thing my manager can do for our team is political: each team/site competes for the more interesting features to develop..
Maybe you would be a great manager, maybe you would be a bad one. But you would not be nearly as good as a person who is just like you but has also worked as a developer. You literally will not know what you are talking about, and the people you manage will see this, and that creates an unfixable problem between you and your developers.
I mean, the classic "couldn't you just ..." is bad enough from a manager who at least was on the receiving end of that suggestion, at some point in his or her career. But from someone who hasn't had that experience, it is so much worse. Maybe you would never use that phrase, but the dynamic is unavoidable. Much of what you do and say will be second-guessed and devalued.
I never wanted management in a corporation. Used to be only half of America for instance worked in a big company. The rest of us worked in small business, or as individuals. That's changing I guess.
I hope there continues to be room for those of us who prefer a life to a career.
Her staying at her current company is a warning flag. It doesn't sound like she went through any other interview process at other companies, so she doesn't yet have full understanding of what's required to be in software engineering field.
The most likely path is that she will be guided into some sort of Software Development Management role after couple of lackluster years as "software developer" role. Many, if not most, software engineers burn out after couple of years or get into comfort zone and stagnate or get moved into management roles.
There's huge propaganda push to get certain groups into software engineering, women, minorities, etc. The central planners decided software engineering field had to change. The motivation is mostly financial, they need to increase number of available candidates to drive down salary increases in software engineering.
The quality of candidates has suffered because of this push, men, women, etc. Most people are simply not interested in software engineering field. Some people find out too late, after spending too much money and time trying to pursue a career in software engineering.
I'll bet you this: if I (or most CS master graduates from The Netherlands [1]) would receive a similar kind of treatment, then they'd nail that software developer position in terms of skill [2].
[1] I can't comment on other CS master programs, but I've followed lectures at: Utrecht, Amsterdam (both of them) and have seen what they're capable of at Delft.
[2] I'm not making claims about culture or communication.
This is probably the single most significant differentiator between skills academic CS or programming courses and real world development.
She must clearly not be writing JavaScript.
I love writing JavaScript applications, but not professionally. It’s a matter of actually building a product versus spinning your wheels with hundreds of megabytes of dependencies and stupidity and circular processes.
Huge congrats to Kristina, and I hope her engineering career brings her as much joy and fulfillment as it has brought me.
Fast forward 8 years later, I am a Lead Developer and making double what I made as a Sr. Manager. I am still learning, I am still behind compared to my peers. Technology feels like it's moving too fast.
But in the end, the best part is to open my IDE and write code. It makes me the happiest.
Congrats on the successful career shift.
1. Did the new role come with a pay cut? If no, it was not a demotion.
2. Is someone else pulling enough money where 1. did not matter? If so, then it is a hobby move.
I run a small company which does software development and graphic design. i could describe myself as a CEO, entrepreneur, software engineer or graphic designer. But whenever someone asks me what my job is, I say "programmer". That's how I identify and IMHO it is a very challenging and honorable job.
Most organizations actively try to support internal mobility (admittedly with varied success). Companies invest resources in hiring, training, and keeping you. Your manager, as a representative of the company, is wise to amicably transfer an unsatisfied employee to another part of the organization. And as a human being, they probably want to see you engaged and happy at work, even if it means losing you to another team. Plus in this example, OP was a high performer and had already shown initiative, putting in legwork to upskill themselves for the new role. Demonstrated value/performance and initiative are always helpful when asking for something of your employer.
Don't be dissuaded by cynical examples to the contrary - those who told their manager about other interests and suddenly and inexplicably got fired. Remember there are two sides to every story - for example, maybe they were underperforming and disengaged for a long time, and then randomly raised the question after their manager reached a breaking point? They won't share that in their post. Also remember availability bias - just because we see these people complaining on forums or "know a guy" doesn't mean it happens frequently enough in real life to be seriously concerned.
In the end you'd be surprised what you accomplish by simply talking to your manager early and often, having general conversations about potential aspirations and leaving the door open for them to say "How can I help?"
This is true -- but your manager won't always act in your company's exact best interest either! I do think "management are human beings, too" is pretty important to remember.
> The loss of some fraction of X is always going to hurt the company more than your gain in Y will benefit them
I don't think you can assume this is always true. What if X is jQuery and Y is Typescript? Or X is oldLegacyCodebase and Y is newProjectInBurgeoningField?
That may or may not be true, of course, but it's an element in your favor either way!
(though fwiw, in my time as a past manager, I found that significant effort counted for a lot - it's cliche but folks who consistently put in extra effort and worked their butts off improved faster than those who relaxed, so they would soon exceed folks who relaxed, even if they had much less of a head start.)
At my workplace those who really thrive on technical stuff can follow a path to technical glory and those who love the intricacies of managing people get to do just that. We end up with more competent managers and developers in the end.
If you ask me, the "demotion" in this article is not going from Director of Design to Software Developer. The demotion is going from a senior level position to an entry level one. But that's not how it's presented.
Smart tech companies have two paths, the management and the engineer path. Where they both have certain expectations but there is no pay ceiling. Bad tech companies tend to disregard this and there is a point that you can no longer get a raise unless you "move up" and become a manager.
In my 25 working years, I've learned this is mostly lip service. Yes, there are ICs who make as much as a VP. But look at Amazon. There are maybe ten people in that company that are IC level making what VPs make. And thousands of VPs.
To be a VP, you have to be a really great manager. To get VP pay as an IC (ie. Distinguished Engineer), you have to be the best in the world in your field.
So yeah, it's possible to have equivalent tracks, but the reality is that you will never make as much as an IC than if you switch to the management track.
E.g., the 2nd/3rd-to-last rung of a FAANG IC ladder makes much more than managers and directors at most other companies in the USA.
This is significant because it's much easier to become a senior IC at a FAANG than to become a Regional Director at the typical company in the USA.
The manager level can result in entire teams quitting, failing to support each other or an atmosphere where catching each others' mistakes is discouraged.
Some jobs are paid based (roughly) on the value they bring and others are paid based on the threat/cost of large mistakes.
The relationship between contribution and compensation is obvious. If you bring more value to the company, the company compensates you directly with a portion of that value.
But why does a position with greater risk necessitate greater compensation?
EDIT: Everything below here was in the original post. However, I re-read it and realized it had little to do with the relationship between risk and compensation.
I don't buy the idea that managers are liable for the mistakes of their reports. That would cause a snowball effect in large organizations, resulting in extremely high turnover for leadership positions.
Managers share some liability for their reports' mistakes, but they also share some reward for their reports' successes. Those liabilities and rewards are split across all of their reports, resulting in what are usually relatively stable positions within a company. A lazy manager can get along by just regularly pruning reports who produce more liability than reward.
There are various methods to address risk:
1. Avoid the risk
2. Reduce the risk
3. Transfer the risk
4. Accept the risk
When you buy insurance, you're doing #3. If you self-insure, you're doing #4. Either strategy requires putting some money towards premiums, the expected possible cost of the risk.
It's much cheaper to pursue #1 or #2. You're then saving an amount exactly equal to the premiums don't have to pay under #3 or #4.
Thus, you can pay a person to do #1/#2 a fraction of the equivalent cost of #3/#4 and still come out ahead.
> A lazy manager can get along by just regularly pruning reports who produce more liability than reward.
Yup, and the books will balance.
Of course anything is possible, but there is often a chain of managerial command (managers of managers) to catch mistakes. It's pretty hard for a single, middling manager to inflict costly mistakes anymore than an individual engineer. Also, I've seen management levels that are 0 - 1 subordinates deep (managers of none).
Managers don't generate defects. Developers do. Not to mention that a lot of the times it's much harder to reverse an engineering decision vs a managerial one.
Most outages are caused by developers and IT, not managers. This perception that there is higher risk as a manager is false. As a developer I make multiple decisions daily, interpret vague requirements, make judgement calls, request new technologies etc. My manager understands about 20% of the decisions I make. Here is the kicker since I work in DevOps, with a super heavy emphasis on the Dev side. 70% of my decisions have wide ranging effect, much wider than my manager's eight person team.
Finally note that no one really talks about 10x Managers, but people talk about 10x Developers. Why is that? Managers are glorified cheerleaders. Most managers are average, their value is vague but they are controlled by managers so its an endless loop till you hit the worker layer that get things done.
Yes, you're right that defects are made by developers. But you'd be hard pressed to find an example of a software defect that destroyed a company. Even if you as a DevOps engineer cause your company to be down for a day, it probably would have little effect on your company's bottom line.
I was in charge of Reliability for Netflix. Our whole site was down for Christmas Day one year. No one was fired, and it barely affected anything. That was a pretty major defect.
However, the way that management handled that outage had a huge effect on the company surviving that incident. Making sure we focused on the right problems to solve to prevent it from happening again. Creating entire new groups of engineers and then hiring them to solve specific problems of moving traffic between regions.
So yeah, management is really important, and a good manager is definitely more effective than a single engineer. And management decisions can destroy a company, but I doubt you can find even one example of a single engineer's decision that took down a company.
> Creating entire new groups of engineers and then hiring them to solve specific problems of moving traffic between regions.
Albeit admirable, like heck yeah that was a great outcome, it's not a manager decision. Most likely it was a VP or Sr Director decision. Perhaps a manager brought it up as an idea. So if we are talking about Sr Director's+ then yes, their decisions can absolutely bring down a business. Granted I am not familiar with Netflix's org chart so perhaps it works differently, from some basic reading it looks like Netflix follows a decentralized command of sorts.
My beef with the original poster was the implication of risk. Both managers and devs have risk with their decisions. It's not just a manager thing. In the end, when Netflix went down where did the mistake come from? A manager or an architecture decision? Probably it was both.
In that particular case it was an engineer making a mistake, but my point was that it wasn't anywhere close to a fatal mistake.
But more importantly, when a team had repeated technical failures, it was usually the manager who suffered the consequences. Especially if their failures were causing problems with other teams.
The manager had the higher risk job because they were blamed for their team's failures. Therefore they had to be compensated to account for that risk to their job.
It's the same reason CEOs get huge golden parachutes. Because their job is constantly at risk for not only their decisions but the decisions of everyone below them. So they get compensated for that risk.
Employees are the first to get fired when a company struggles.
Managers are less likely to be fired, and when it happens they can have more savings as they salaries are higher.
CEOs quit failing companies with multi-million exit bonuses.
So no, salaries are based on power, and so is the ability to dodge risks and responsibilities.
As an individual contributor, the impact of your decisions may be broad, but however broad your individual impact is, your manager's impact on you is [broad * number of directs], so it's always "greater" (note: not better, just greater).
So in that sense, the "value" of a manager/director is "higher".
IMO it's all just a series of roles, and you need someone to do both. Someone has to be designing and building code while someone else attends meetings and understands the larger context of that code, making sure the code makes sense a week/month/year later.
In fact, I prefer it when managers take on a much less "HR" role, and instead act as "go-fers" for their team, a la "how can I unblock you today?". Bonus points if they can mentor, but not necessary.
Being an individual contributor isn't a "demotion", but it is a change in where your impact hits (people vs. things). You need both, and it's fundamentally a partnership, I wish more people realized that.
That depends on how high the multiplier is and how many direct reports a manager has. A manager with 5 direct reports and a multiplier of 110% is only producing as much net value as 0.5 of his/her reports. A manager with 20 direct reports and a multiplier of 106% produces a net value of 1.2 of his/her reports.
It's not safe to say that managers in general produce more value. Some do, some don't. It depends on their ability and the abilities of those they share a management relationship with. But the same could be said about engineers/architects/devs.
It's 2002. Does a Kohls Director Of Whatever with tens of direct reports and thousands of people below those reports have more leverage than a single engineer at Amazon?
It's 2021. Does a manager of hundreds of warehouse workers have more leverage/impact potential than a single engineer in a robotics R&D division?
Every time I hear this explanation, I can't help but think "so we're still smoking Luck Strikes, huh?"
When you make a decision as a software engineer, the impact of that decision can often have a multiplicative or even exponential force.
The goal of 21st century organizations -- especially software organizations -- should be to make things scale in way that's at most sublinear with the number of people you throw at it.
Automation prints money and businesses that can harness automation have huge profit margins.
People are expensive and body shops are shitty companies waiting to be replaced when technology catches up with whatever work they're throwing bodies at.
It's not 1960 anymore. Invest in your automators and treat your people managers as a low-value-add cost center.
And, more importantly, what might be the massive unintended consequences of routing your org's permission structure in the same way you route its head-count?
Strategic decision-making is not the same as people managing, and people managing can even create blind-spots that get in the way of good decision-making.
Would you rather have developers wearing every hat in an org? When would they find time to code? I know many developers who don't want to have to do all of that work simultaneously, and are extremely grateful for a manager who can take many of these tasks off their plate.
When was the last time you tried to add a recurring meeting to a development team's calendar? They... don't like it, in my experience, and I respect the hell out of that.
Just because you treat something as low-value-add or admit it's a cost center doesn't mean you don't need that work to happen!
> When was the last time you tried to add a recurring meeting to a development team's calendar?
Yes, I agree, managers' secretarial and political work is incredibly important to the success of an org. But the 1960s idea that it's a "force multiplier" worth high comp is a mistake.
I'm not contesting whether managerial work is important or necessary or to be respected. I'm contesting the idea that managerial work is a force multiplier for individual contributors, in any sense other than in the same sense that janitorial work or admin assistant work is a force multiplier. The only orgs where I've seen managers to be actual force multipliers were body shops.
This is why managers often get paid more, and it applies even more the further up the chain you go. A good CEO is worth every single penny of the millions they get paid, because of the multiplicative force they have on everyone below them on the org chart.
I think we are disagreeing because we're talking past one another. Hopefully the following observation helps make my point:
The average base pay for a manger in the USA is much lower than the average base pay for an engineer in the USA.
I'm talking about management as a discipline in general and engineering as a discipline in general.
> A good manager is worth 10x a good developer, and a good developer managed by a good manager is 100x base developer value.
Can you define "good" in a way that would allow us to empirically test this statement that doesn't make this statement a literal tautology?
The skills involved in figuring out what to build are entirely separate from the skills involved in building, and you are making the classic mistake of worshiping the skill of building to the exclusion of all other skills.
It is much rarer to know what to build than it is to know how to build.
Right. The whole thing is a silly tautology.
Good managers are force multipliers. Better hire good managers! and then if they don't force multiply they must not have been good managers :(
It's literally an unfalsifiable tautology.
> The skills involved in figuring out what to build are entirely separate from the skills involved in building, and you are making the classic mistake of worshiping the skill of building to the exclusion of all other skills.
"Knowing what to build" is not what 90+% of managers do.
A good manager will improve the performance of her direct reports. If you can't understand this fact, then I don't think you and I have anything more to discuss.
Have a good day!
Right. A good manager indisputably force multiplies because a good manager is defined as someone who improves the performance of her direct reports...
Importantly, any empirical evidence that less management structure improves outcomes is easy to dismiss because it's really just proof that the particular manager/company that failed wasn't a "good" manager/management structure. After all, if they were "good", then the output of engineers would have been multiplied, right?!
Tautology (n): a statement that is true by necessity or by virtue of its logical form.
Saying that we know good managers force multiply by improving performance of reports -- and then defining "good" to mean "improve the performance of her direct reports" -- is absolutely a tautology.
More importantly, ignoring empirical evidence by making a rational appeal to the truth of this tautology creates a rather pointless conversation.
Given the choice between blind faith in a tautology that "good managers = good" and empirical evidence that sometimes "less emphasis on/power for managers = better", I prefer the latter.
You have a good day as well :)
The above resonates as an exercise in tautology to me. If the job of a manager is defined as a position in which a person's decisions will have a multiplicative force... well... then of course their decisions will have a multiplicative force! Though I'm not sure the above is even remotely true for the vast majority of management-type positions, save those at the highest-level. And even if it is... then it of course a fact that the value derived from an individual in such a position is therefore not related to the "multiplicative force", rather, the decisions themselves.
I'd wager most managers come from two camps (the first two below):
1. Those that are ex individual contributors who have accumulated enough seniority and experience to best-understand not "what to build", but rather, "how to build it best". And are therefore given the authority, responsibility, and pay-check to do so.
2. And those who are not really managers at all, and whose job would be more accurately named "coordinators". This seems to be the role you are hitting on at end. You know, the guy who asks the engineers "how can I unblock you today?" and whose explicit role is to have the authority to act on the answer. Notably, not synthesizing the answer in the first place.
3. The third camp is of course the ones to which you seem to be alluding in your comment. The high-level, c-suite, "director of strategy"-type roles. And you are exactly right about them. Clearly the person deciding which widget needs to be built is in a position of tremendous responsibility when the value they can add (and remove) is extremely consequential (assuming the resources required to do so are equally consequential). There aren't many roles like this in a company.
It's the second group of "managers", I think, that the OP is confused about. They don't actually make that many decisions, and the ones that they do make are rarely different from the one their most competent reports wouldn't also make. Sure these "managers" sit in meetings and talk about the larger context of the code, the product vision, etc., but only insofar as that its useful to have someone who can distill and relay this information back to the engineers building the product. Because as an engineer it is, of course, nearly impossible to build a truly great product if you don't understand its larger context. It is this group of managers where the tautology is glaring. It is their job to carry-out the work necessary to multiply force. The work isn't all that creative, doesn't require much judgment, and rarely requires much expertise. The value isn't in multiplying force, it's in just showing up...
To clarify, I'm not suggesting managers don't have value, and certainly don't believe there doesn't exist a spectrum between those in the position. Some people multiply force more than others. They know to ask "how can I unblock you today?". They know that Jim doesn't like to be bothered before 11AM. That Susan is more productive if she has a tight feedback loop. Or that Ron isn't as good as Pam at test coverage. They know how to find and exploit people strengths while also minimizing their weaknesses. This is valuable.
Even so I'd wager most of the time a manager's pay is calibrated such that they make more than those whom they manage regardless of the value these people (the people being managed) contribute and without any sort of rigorous appraisal of how much value they bring or how much force they multiply. How could you? The skills illustrated above can't easily be captured in a pay band...
But this is obviously false, right? If the IC is truly a spectacular IC, then it's likely that no matter which manager they're under, they will have large impact.
The impact of the manager isn't the entire impact of their directs, but rather the relative difference between the impact of their directs and the impact their directs would have under a different manager. Which is substantially less, and could easily be less than the impact of a particularly strong IC.
You'll start noticing when the "Star" employees of the late stage start up are more from HR, director groups, instead of product, tech, etc.
A single developer developing an app vs large team building an enterprise SAAS application have exponential differences.
Switching from (Senior) Developer Advocate to Software Engineer (2) at Microsoft. Both jobs are on the same ladder / pay scale and in the same engineering org. I was promoted just last September and am effectively undoing my promotion.
I had never worked as a SWE/SDE 100% of my time. I have a Math & CS degree and have built lots of random integrations, apps, and created technical architecture designs / product requirements.
I realized I enjoy projects where I get to code or dive deep into technology best. I also want a role that is easier understood by industry across companies.
The hope is that I can perform well to quickly get promoted back to my current job level (and compensation).
The sacrifice is worth it to me.