Why Good Developers Are Promoted into Unhappiness (2007)
robwalling.com
robwalling.com
I’ve been noodling on this for a while, and I think maybe a fourth track at a lot of organizations should be special projects. Small teams (3 people max) given autonomy and clear objectives (revenue goals, user growth goals, etc). For a pre existing company, this likely means “hacking” on an existing product, experimenting on something new, tackling huge debt... Pick your poison.
This is a fine middle ground for someone with a lot of experience who doesn’t want to manage, but still wants some growth opportunities. For many people who don’t want to manage or be an architect, autonomy is the number one thing I regularly hear. So, give them the autonomy and some ground rules, then let them loose.
You are literally a one man marketing and finance department.
Sure, if you don't mind failing. :)
I agree with blub. Coding and designing is part of a startup but if you spend a second more doing that than you have to, you are setting your company up to fail. Instead you should be talking to customers and churning out whatever the absolute minimum code is that will validate your market.
In one instance that I know, a Tiger Team of 6 delivered run away hit TV streaming product in 8 months. From conception to design to prototype to factory production to launch.
Another, albeit larger scale example would be Lockheed Martin's Skunk Works: https://en.wikipedia.org/wiki/Skunk_Works
I guess it's nice for the devs at first, but creates a lot of waste. They're basically spamming the world with programming languages, libraries and products only to wind them down and start again.
Replace libraries, languages and products with statistics, hypotheses and figures and you have described scientific research.
The point is that each iteration learns from the last, in principle, even if they aren’t backwards or forwards compatible.
Well, yes - and the inability to build on previous research code because people don't publish it results in a colossal waste of (usually) public money. Nonreproducibility in science, and Google's abandoning of products, are phenomena that resemble one another somewhat.
I think a principal engineer is the right mix of (still) developing, planning, mentoring and potentially leading small teams, while staying out of a full-on managerial role.
It's rare to see a big tech company with as many engineers as managers at the Director compensation level, for example.
I do free one on one mentoring for managers, and my business also has a manager training program we run twice a year that really helps people perform better in the role. A lot of studies say some people aren’t “meant to be managers”, but I really believe that’s the exception not the rule.
Would be happy to help!
People sweat about all the “Business Stuff” you have to do in addition, but I find it’s not really any more of your day than the normal boring admin stuff of being a rank and file developer. Certainly less than being a manager at a bigco.
It also does away with ageism concerns.
You’re not an employee so no performance reviews or line management and you are responsible for running your own company, but at the same time many contracts will be working with teams of permanent staff for 6 months or more so it’s not like you are off totally on your own having to invent new products or hunt for projects. I’d guess the remuneration can match that of a manager after you’ve been doing it for a while, but you’re essentially a technical expert who’s expected to be able to hit the ground running quickly and add a lot of value at each client.
My impression is that demand for good contractors outstrips supply right now (it can make sense for companies with fixed budgets or tight timelines to hire contractors despite a higher per-day cost) and the business side really isn’t that complicated, so it is a fairly well trodden path by good developers at a certain point in their career. Of course, if you are someone who feels like they benefit from having the company structure (eg in terms of management, training, etc) or doesn’t like changing company fairly often it’s probably not for you!
Edit: forgot about this guide posted to HN a while ago: https://github.com/tadast/switching-to-contracting-uk/blob/m...
One thing you might find is getting your first contract is hard if you are in a permanent job - companies generally are looking for contractors to start ASAP, so a one month notice period (with the risk that you get tempted to stay at your existing company) is often not acceptable to them. Some clients will wait for the right person but you might find you need to quit your job first before finding work which can be a bit nerve wracking - so it’s wise to survey the market, talk to recruiters etc. for a while before doing so!
If you’re UK based https://github.com/tadast/switching-to-contracting-uk/blob/m... may be interesting.
you become an "employee under guise" and then you will be taxed as such. then you get the worst of both worlds.
One way is to try and get some sort of security cleared job. Once you do, you immediately elevate yourself away "from the crowd" of developers in the market and you will find major global companies want you and they pay well. And when you get your first gig, you can be sure that another company will want a security cleared engineer, so it's good for job security.
Just be careful how you say no when they ask you if you want to join on a perm basis :)
So: email everyone you know (also non-programmers) a 4-sentence email that you're now a contractor. Explicitly list the domains and technologies you can "hit the ground running" at, and focus on those. People need to be able to see you as "a great Java programmer" or "a great iOS programmer". People have a hard time wrapping their minds around "a great generalist" so don't make that pitch.
Set a high rate from the start. Ask around what's common in your area and go a bit above average - some of your peers are likely charging to little. You'll find that customers don't typically negotiate rates - instead they'll just assume that this must be what a proper contractor costs. You might miss a customer that way, but that's the customer you don't want, the kind of customer that will make you regret contracting. Time-sensitive customers are ok (after all, that's what you sell right? hitting the ground running?). Avoid price-sensitive customers, they're hell.
Sell by the day or week. Not by the project, cause projects always blow up and you don't want to take that risk.
That's it, really.
Would you then use a recruiter or something like that? I don’t think I would get any gigs using my network.
We havent had anyone get promoted to this level, but several are close.
I go to bed every night not worrying about whether my company remains sustainable. If they don’t, as long as it is a microeconomic issue (company failed) and not a macroeconomic issue (economy is in the toilet), I reach out to my network and get another job relatively quickly.
The same amount of money appears in my account every other week whether I go on vacation, call in sick, etc.
And I’m 45. Ageism is way overblown if you keep your skills current with the market and your network strong.
Two. You're not going to multiply your salary by 2x-20x unless you start to take on more responsibility, like worrying about sustainability.
Well damn, I guess I am going to have to make do with 200k being a rank and file developer at a FAANG company.
Oh wait. I’ll already be able to do that as a bog standard enterprise developer/architect in a mid cost of living area as part of a dual income household. So why do I want the headache?
If you have a household income of $434K, you’re already in the top 1% if you have a household income of $600K you’re in the top .5%.
If it were that easy, don’t you think more people would be doing it?
I go to bed every night not worrying about whether my company remains sustainable.
As do I. The key is to build the business to the point where it replaces your income before you quit your dev job. Once it's ticking away, there's very little that can happen over the course of the night (or a month) that can much affect its profitability.
The same amount of money appears in my account every other week whether I go on vacation, call in sick, etc.
Same here, with the addition of it still coming in if I decide to drop down to 20 minute weeks for the next year or so while focusing on something else.
You're right about the Ageism thing though. I do still hop back into the working world from time to time (to keep the skills fresh and buzzword-compliant), and companies seem more than happy to hire an experienced guy to build things for them.
But yeah, back to the point at hand: try not to scare yourself off by the "business stuff" of running a business. You can do as much or as little of it as you like, and so long as the product is good and your marketing is in place, it's just not a big deal.
> The key is to build the business to the point where it replaces your income before you quit your dev job.
So your counter argument is for people to build a successful business on their own that will last for the remainder of their careers while working a full time job (and most likely while supporting a family and raising children)? Yes...it's just that simple.
You appear sceptical, but it really isn't hard to do. There are lots of examples here that come up every time anybody asks.
And even if it is "survivorship bias" and for every 1 example of someone that succeeds there are 1 million examples of people who have failed, the cost of failure is so low that you should try anyway. It costs you nothing and you have potentially everything to gain.
Ever hear about the story of the two wolves? You're feeding the wrong wolf.
And any money that you invested in your company.
If you are talking about starting a business on the side and working full time, that means you are sacrificing some combination of time with your family, exercise, and time that you could be putting in getting ahead at your current job or acquiring skills that would help you get a better paying job.
It doesn’t make sense statistically to take on “one million times the risk” unless the upside is much higher. These days, a CS Major can spend a year learning “leetCode” and study “Cracking the Code” and easily get a job at a FAANG making a quarter million - not that I would personally want to.
> If you are talking about starting a business on the side and working full time, that means you are sacrificing some combination of time with your family, exercise, and time that you could be putting in getting ahead at your current job or acquiring skills that would help you get a better paying job.
You think you somehow learn nothing attempting to build up a side project? I've yet to see an argument made successfully that you learn absolutely nothing marketable by working on a side project.
But let's say you manage to pull that off: all you've lost is a little bit of time. That's extremely low from a business perspective. Software is rather unique in that you don't need to spend tens of thousands of dollars setting up supply and manufacturing lines. And, the potential payoff is huge.
Now, maybe running a company isn't your thing. That's a fair argument. But fear of failure is a terrible way to go through life.
On a side note, why are you so relentlessly negative? Most of the comments you've made in this thread are needlessly hostile, sarcastic and bitter. Did a side project touch you inappropriately as a child?
What are the chances that a “side business” is going to make $150K to 200K a year?
On a side note, why are you so relentlessly negative? Most of the comments you've made in this thread are needlessly hostile, sarcastic and bitter. Did a side project touch you inappropriately as a child?
The whole point of the article is about people who don’t want to be in management. It’s makes no sense to start a business if you don’t have any desire to be in management.
Also, one thing that I’ve learned over the years, is the easiest way to make money during a goal rush is to sell shovels. There are plenty of opportunities out there to make good money working for a consulting company that matters to well funded startups and corporations who want to outsource development/infrastructure. Guess what my two areas are?
One side project doesn’t have to earn 200k/yr. you can have 5 of them, each making 50k. Running them as single software company is way less management work than managing your team in big company environment.
Let's say you need 1-2 hours a day for every of your product (all activities combined)
Being a manager means 5-8 hours a day managing people, not working on products.
So the time is similar, but your work on product, not manage people. Way different.
If I had to guess, I'd say that for every hacker news user that ships and markets an mvp, probably somewhere around 1-10% hit 150k/year from it. It's hard to find good data on this though.
One that made money was spreading malware and the author who seem to be making a decent return said.
It was really hard to write - took me 1.5 years, tons of research and re-writing. This isn't something I slapped together over a weekend. Far from passive income.
I built a business 5 years ago while I was working. The tech for it took me a weekend to complete and I had over a million in annual revenue within 2 years.
Coding became 20% of my job, but I loved the new skills I gained and challenges outside of coding.
And you’re still “managing” your business - the whole subject of the article was about people who didn’t want to manage.
But yeah, back to the point at hand: try not to scare yourself off by the "business stuff" of running a business. You can do as much or as little of it as you like, and so long as the product is good and your marketing is in place, it's just not a big deal.
It’s not that “I’m scared” of managing a business. I’m a proud MBA drop out, I have plenty of business acumen. I don’t want to manage a business. People were commenting about giving up management and dev lead roles because they didn’t want them - as did I. If I don’t want the headaches of being a dev lead, why in the world would I want the headache of owning a business and managing employees?
You can do as much or as little of it as you like, and so long as the product is good and your marketing is in place, it's just not a big deal.
You mean all I have to do is create a product people want, get funding, find the right people and then life becomes easy? Wow, I didn’t know it was that simple. Do you have a newsletter?
As far as I’m concerned they’re the people that run around flooding every meeting with words that have already been said by the developers, and by extension do not need to be said.
Big orgs with lots of outsourcing, architects are supposed to police the result to make sure it's semi decent. But since they've long since gave up doing any real work, they tend to be people who buy really expensive crap to cover their arse.
In smaller orgs, it can almost be just a lead dev with a fancy title.
Rarely does the title seem appopriate, but some of the folks with the title are good regardless.
Its taken a while to get to this point, with a fair bit of pushing back on more traditional project management stuff, but I’m ridiculously happy with what I get to do for a living now. That was definitely not true when I was in a pure technical management role, where 80% of my week was spent in meetings.
End of the day, if you're happy and delivering value your title doesn't really matter. But it might when you want to move role in the future, so you might want to keep one eye on what the market is branding you as.
Fow what it's worth, I'm glad you're happy with your role. :)
*or maybe just changed, who am I to decide what words mean
This particular group had a manager. One of my favorite bosses, who was very sharp as both engineer and manager, honest, humble, and supportive (and formative of some of my ideas of what I should aspire to).
It's not that different than any project with a novel component. Some projects ("Uber, for cats!") are mostly a matter of executing in some well-understood ways as soon as you hear the idea (set up your tools, use these frameworks, on this cloud configuration, and have frontend and backend start grinding through the tasks, while you're plugging them into the plan, and scheduling for demos or MVP launch or whatever). But other projects have more upfront domain knowledge to acquire, brainstorming, requirements analysis, market analysis, prototyping, figuring out possibilities, deciding what you will do, etc. In the latter, eventually it probably turns into a conventional fairly predictable project (although there might still be tricky problems to solve in the pieces, but you have a good idea where you want to go and what the pieces are).
And did you? — I'm really curious as to whether there ended up being a positive ROI from dedicating those top engineers to that task.
My personal ROI: moving to that group might've been the best decision I ever made. I learned a tremendous amount, got to work with great people, and afterwards it catapulted my career in the direction I wanted to go. Had I not been determined to go to grad school, I would've followed the original team lead anywhere.
In my mind they were called "swat teams".
That being said, it wasn’t codified in our career mapping. It was sort of a “one off” experiment.
> down to the woman who worked the front desk
Maybe she's on to something.
The only successful special projects I’ve ever seen are ones that are off the books initially, possibly even pissing off product managers or others because engineers essentially have to flippantly disregard the official prioritization of tasks according to non-engineers and just override it with what the engineer can easily see is actually more important from a genuine business/product perspective but can’t waste the time trying to jump through the hoops of political jockeying disingenuously asserted to be sincere evidence gathering to satisfy all the other competing interests and credit grabs.
It may be semantics, but I think "stagnating at a pretty high level" may be a pretty good endgame for a smart engineer who does not want to go to either people or technology management.
If this means significant autonomy, mentoring role and decent compensation what is wrong with stagnating at this level? This is not for everyone, bit may be OK for some. An honest question.
Counter to my own point, I have had conversations with HR individuals who encourage managers to fire employees that don’t get promoted every ~2 years. Basically their thought is that is an easy way to identify “bottom” performers. I don’t agree with this sentiment, but it’s not an unheard of position.
I watched my father get promoted into unhappiness. He didn't realize it until it was too late. For his most recent promotion they had to threaten to fire him to get him to take it.
Engineers are the most cautious lot I've ever worked with. Among the most intelligent, but I can't imagine them making ballsy market moves.
I have been thinking about that too. I am pretty experienced and the best use for me would be to get something off the ground quickly to working through a hard problem . I have seen a lot so usually my instincts are pretty good and I am much faster in responding to problems than the less experienced are. I also have the confidence to make decisions and take responsibility without needing approval from multiple parties.
A lot of companies like to talk about being "agile" and "like a startup" but they rarely let engineers stay focused on a problem, leave them alone and let them work through it.
When I work with managers who need to create change, I remind them that it took years for institutional baggage to grow. It’s reasonable to assume that it will take at minimum months to unravel.
You start hating it (I did) and look for a pure programming role. But you are not in your twenties any more and you have to align with and follow someone else's designs and decisions and you can't since you are experienced and know more and you have to push back and argue and end up going to lead/architect role again and writing less code again.
no, you don't.
I mean, to an extend, yes. But you need to be able to excert some positive effect.
Would like to see those counter examples people seemingly have.
Arpa / Darpa.
3M.
AT&T / Bell labs.
Amazon (AWS, FBA)
Apple (iPhone, iPad, iPod)
I would argue Apple is on this route now as we are only now seeing the impact of losing Jobs.
Well at least innovate and survive in the mass market.
That new smell for dove soap. The thicker papertowl bounce came out with are all examples of innovations.
Changing the world.. that's a dangerous idea companies want no part of.
[1] https://softwareengineeringdaily.com/wp-content/uploads/2018...
I think this is sort of ok at a high competence level, but fails when the people you work with are less experienced. One could say the same of an IDE I suppose..
This mindset bias is everywhere, first i noticed it in my european university, where the good teachers were promoted to high responsabilities position, meaning more and more administrative workload and far lesser time for teaching. Leading to the vicious situation where the teacher was not teaching anymore and not happy with his position, and studend loosing a good teacher and having to face less capable teachers. Using management position as a reward should be only used for wanabee managers.
Why might management be more valued by the organization? Perhaps because it produces more value for the organization?
A manager who enables 10 developers to achieve a goal (as mentioned in the post) is going to be more valuable to the organization than the same person who cranks out a bunch of code. That's the reason for the prestige and money.
Now, there are two answers to my argument. Either the organization is correct in valuing managers more highly, in which case if you want to stay an individual contributor, you should accept less pay and prestige.
Or the organization is incorrect. The costs to the organization of people being unhappy or leaving are such that the additional value from them leading a project evaporates (in the long run). In which case this should be revealed and hopefully good organizations will make adjustments. As other people have pointed out in other thread, Google does something like this.
Supposing you literally “just write code,” there’s a ceiling to how much impact you can have. One person can only hold so large of a program (or so many small programs) in their head, and if you are on a project that reaches a certain size you have to start working with other humans to maintain it, and thus the need for technical leadership and/or people management begins.
One of the basic ideas of good management is that a good manager is a multiplier. Suppose you have a team of ten, and individually they can each ship 8 “points” of work in a week. If you turn one of those people into a great manager you lose 8 points of direct work, but everyone else now ships 12 points per week, and you’ve gone from 80 to 108 points in a week. You could now say the manager is responsible for the 28 point gain.
Similarly with a technical leadership role, doing the architecture and teaching work can multiply the effectiveness of many other people, leading to greater impact than any one individual could have.
When you look at it like this, it’s obvious why these higher impact “multiplier” roles get more prestige and pay than the best individual coders.
And I think that’s the dilemma. The real question - for many of us, anyway - is do you gain more satisfaction from the higher impact role and the perks that come with it, or from the sheer joy of the hands-on work that got you into this field in the first place.
Its really difficult.
I saw some other posters talking about rotating the responsibilities around - ie. leading sometimes and working in the trenches sometimes, and I really understand the appeal of that. That said, I’m not sure if it’s practical beyond the first “rung of the leadership ladder” or so, because leadership is itself a very challenging craft that takes a lot of focus and effort to master.
What appeals to me more, but I haven’t seen yet in practice, is for orgs to let their technical leadership (both on the architect and people management sides) take periodic “coding sabbaticals,” or something along those lines. The main idea being that periodic returns to the hands-on work will help keep you sharp, up-to-date, and effective as a technical leader. The biggest problem with that is that it’s not always easy to just plug a “substitute leader” into the org chart while you’re on sabbatical.
I'm don't see why a single person can't have a ton of impact merely as a coder.
I mean, this whole website is dedicated to (mostly) discussing tech startups and how (mostly) software disrupts and help scale outdated business models. Isn't the software-making business model also ripe for that disruption, at least in a smaller scale?
Couldn't a single coder (or a small team) help an organization get some competitive advantage when it comes to tools. Or even programming languages? Why does ALL the innovation has to come from outside in our industry?
Fred Brooks talks about "The Toolsmith" it the "Surgical Team" chapter in Mythical Man-Month, and how "the tool-builder will often construct specialized utilities, catalogued procedures, macro libraries".
Facebook made React, Apple made Swift, Google has dozens of those. And the teams doing those tools aren't that huge. Why don't we try new things instead of letting good coders go away or making them stop coding?
Many programs can be small. But many of them cannot. For the larger programs, management is generally needed.
The multiplicand, which can be low or negative, does not matter to the vocal subset of talkers (often with vested interests) that has overrun HN.
Sort of, but:
1) Knowing what to build requires deep knowledge of that the other engineers in your company are struggling with. Figuring this out requires a lot of time spent meeting with people and doing other things that would be considered more management than coding.
2) If the thing you build is good, it's going to start getting a ton of feature requests. Your company will decide that it's worth investing in, and suddenly you're either managing a team or somebody else is managing you and running "your" project.
You could, but that would be a weird thing to say. 36 would make a lot more sense.
(Or, if you hire the manager and then fire the worker, 40 come from the manager and -12 come from the missing worker. Which one makes more sense depends on the analysis you're trying to do. In either case the manager is currently producing 36 points.)
What you can do, instead, is allowing your devs to stay at the maximum of their productivity even as the team grows - which is a challenge. And, even more importantly, you should ensure that those "points" that they develop actually contribute to the team's goals.
The interesting thing is that at that team size you really only need to have each team member “gain 1 point” for the “manager switch” to be “worth it” since 9x9 > 10x8.
The point being that as the number of humans, good leadership is increasingly valuable.
"Wow, only 1" isn't a good way of looking at it, since the points aren't measuring anything and therefore don't have any meaning in the example.
At this team size, you need to have each team member increase their productivity by about 11%, 1 / (10 - 1). If we're calling their output "8 points", then the increase you need is just one point. If their output stays exactly the same, but we call it "a million points" instead of "8 points", then it's more than one point. Is achieving the 100,000+ point gain in the second scenario more difficult than achieving the 1-point gain in the first scenario? No.
But they have limits - at each level up the hierarchy there are always decisions above your pay grade.
And that is the fundamental problem - organisations have built in limiters to how much change they can accept internally - because too much internal change breaks the cash generator.
So sometimes the most performant thing to do is not to chnage anything, or perhaps just to leave.
As I progress, I realise that coding is at the bottom of an inverted pyramid of "affect" - decisions in your code has less business impact than business decisions. For example I was just moaning that audible/kindle sync positions so you can read a bit, listen a bit. But a business decision was taken to kill off that fairly neat bit of coding - the business decision was not in sync with the coding decisions.
To my mind that means we should have smaller coder driven organisations- see programmer anarchy, not somehow work out how to hire more managers
It takes a certain kind of person, to be able to extract self value from seeing others directly create it, rather than directly creating it. Not everyone prefers that and some find more satisfaction when directly responsible for the added value.
It's the self consumption of a direct-value vs indirect-value effect that drives whether you will be good at one or the other.
The problem is that the mainstream mantra sways people into chasing indirect-value type roles, when they ought not to be (for the good of the individual).
> if Willie Mays played for your baseball team would you promote him to manager?
I don't know who Willie Mays is (not in the US), but I'm pretty sure elite athletes get top notch salaries, a lot of times bigger than managers or coaches.
People shouldn't need hierarchy just to remain professional and follow someone else's lead.
I had an identity crisis early on doing management. I liked to tell people what to do, because I had a big map in my head of where things should go. Because of this developers sort of organically gravitated to me for guidance even before I had the official job. However, I also liked to write a lot of code.
Once I was promoted to management I quickly realized just how much "not coding" that job requires. I struggled with not coding as much. I struggled with wanting to micro manage my staff. I struggled with wanting to write their code for them. I had juniors on my team and I wanted to snatch the keyboard from them and write their code for them.
The defining moment for me was one day, while watching one of my developers deploy something magnificent, that I realized I don't necessarily like to "build things", I like to "see things built". I like to see people succeed. I like to see a scribble on a napkin become a tangible piece of software. Code was a means to an end for me.
I won't lie and say I don't miss coding full time. I still get right in there when I can, but I step aside when I know my management duties are going to let the team down. One thing I don't feel is guilty about not coding as much anymore.
- There generally isn’t an ‘optimal’ solution, but there are a lot of solutions with tradeoffs.
- Everyone has their strengths and weaknesses, and gravitate towards different molds.
- People aren’t born perfect, but what they can do is grow. How can you help them do that?
Bad values is a slightly difference conversation. If the dev has a bad attitude, refuses to improve, lazy, etc then you can only coach that so far before it's time for termination. It sounds harsh but a good managers job isn't just filling seats. You need to make sure the people on your team force multiply each other, and that your best devs are happy enough to mentor the up and comers. Low values people spoil all of that and need to go, even if they're high performers.
Get to the point where you can convey the underlying reasons for them: why is it important to you? What’s going to be worse or slower with their solution? What future problems is your solution avoiding? How can they identify similar situations and apply the same concept next time?
It is good that you see these things instinctually as you say but if others don’t (including the coder in question) then you can make improvements by conveying this to them. And that is frequently more than half the battle in getting improvements operationalized: getting others to adopt and push and spread your good ideas as their own.
In a healthy org, these developers should be open and eager to listen, learn from new ideas, and adopt improved methods or outlooks, especially from a tech lead (or equivalent), who in turn should be able to update his/her own methods/outlooks when similarly presented with improvements.
I haven't dealt with people under me who write truly abysmal code so far, mostly because I am a picky hirer, but that subpar code that my people have written is my fault, because it's my responsibility to make them better programmers.
"We’re looking for a product leader to join a fast-paced and transformational start-up to manage various fraud and identity initiatives. While managing product development, The Director of Product, Fraud and Identity will analyze, investigate, and identify solutions to mitigate and prevent fraud and identity compromises. This individual is responsible for developing features, platforms, models, and capabilities to proactively identify sources and patterns of fraud and minimize the company’s total exposure to financial and reputational risk. The product leader will develop and execute a long-term vision that will establish Lyft, and its systems, as the industry leader in fraud management, mitigation, and identity-based capabilities and services."
Are engineers not interested in product management? Or are those roles not available to them?
The Peter Principle says people who are good at their jobs will keep getting promoted until they reach a role they're not good at.
In this variation, people get promoted until they reach a role they don't enjoy and eventually leave.
I've been desperately trying to get into a management position for years. I started programming at age 14 and am now approaching 30. I created projects using basically every major programming language, created and maintained a complex open source project which now has over 5K GitHub stars and several tens of thousands of weekly downloads.
I have experience managing the community around the source project and doing peer reviews. Feedback from the community is overwhelmingly positive. I can't even make a consulting business around the project because it works too well, the documentation is good and the community is very helpful.
I got passed up for promotion many times - In spite of consistently delivering beyond all expectations and despite my background as a long time open source developer. I've had people younger and less experienced than me get promoted above me twice! First time this happened, I quit the company about 1 month later (they were very upset/regretful when I handed my resignation).
Then it happened to me again at my current company - In spite of the fact that they are using my open source software as the core of their product (since before I joined). Even the biggest competitors of my current company started using my OSS project. Still no promotion. WTF do I have to do to get promoted? I've told the CTO multiple times that I want a promotion so it's not like they don't know.
PS: Please do go with the support plan route for your open source project. You wouldn't know how it will turnout unless you try.
But mind that there are more scenarios than "works out" and "doesn't work out". It might also for instance be that you get some customers, but too few to pay the bills, but too many to switch of the light. It might also be that suddenly paying customers demand the project to go a different route than you (and the contributing community) envision. Both of these can bring major tension to something, which had been fun before ...
Doesn't mean it's not worthwhile, but be prepared for it, to keep it on a track you're happy with.
Believe there are management coaches that might spot self defeating habits quickly. Books like andy grove’s and innovators dilemma, peopleware, dale carnegie etc, can help too.
I think this may be the case. I don't have many friends but those that I do have are very close.
The foundation of most friendships among the wealthy seems to be shared financial interests. This is not real friendship IMO and I cannot understand why supposedly intelligent people (who already have a high level of financial security) would participate in this kind of social theater where everyone is acting and everyone knows that everyone else is also acting and yet they all keep playing along. Friendships must be founded around core values not around mutual financial interests.
Really? In my experience, people are often promoted into management when they demonstrate political ability.
Often the people who I consider the true leaders - engineers who everyone considers competent, good advisors, mentors and role models, etc - continue quietly being engineers.
Several times, I’ve seen organizations reward people who were adept at deflecting and spinning projects, goosing metrics and hiring quickly (despite a lack of fit/competence in their hires). The teams that they led were demoralized and rudderless, but you’d hardly know that from how they were rewarded and promoted.
The idea one can put an end to politics with non-tiny groups of humans is unrealistic.
Definitely move Dale Carnegie to the top of the reading list and then actually follow the advice. Growing older and wiser and more humble just takes time though. Strangely enough, skydiving also helped me accelerate the process.
Sometimes, your own managers don't know what you want, until it's too late! But I don't want to assume anything, so please do start a conversation if you're up for it!
That said, even as an IC, at higher levels the scope of impact you're expected to deliver at some point exceeds what one person working alone can have, so there's still lots of people leadership skills needed to advance: working cross-functionally and setting direction, communication, and ultimately influencing others to jump onboard and help you out.
(Note that this is different from people management -- e.g. formal coaching, performance reviews, dealing with HR/org/budget issues, etc.)
That's why many engineers there, who have little to no leadership skills or inclinations, end up being managers: it's simply much easier to get ahead on the management track, comparatively speaking. There are simply a lot more senior managers than there are comparatively senior (by comp, the only metric that really matters) engineers, and you aren't competing against as strong a set of peers.
So maybe there is something worse: bring stuck as a developer after 40-50.
I very much enjoy being a dev and am a top performing one in my VP’s org, but the structure incentivizes me to switch over to the management track, which I’d be happy to do (I have prior experience as one), but it seems like a crappy way to depress salaries of ICs that they are forced to switch companies to move up to where they should be.
Yep, by L6 you're probably spending less than half your time coding even on the IC track.
I don't know where you are from, but in my experience the roles are very different.
As an architect you have to provide technical guidance over a domain that you know like the back of your hand.
As a PM, you have to manage a project that straddles multiple domains, some of which are completely alien to you, and you are explicitly limited by the scope, deadlines and your budget.
As a PM, you have to trust (and goad) multiple experts if you want to get anywhere.
The difference is that in academia is not an explicit promotion that moves you from research to management, but more of a boiling frog kind of situation where you gradually do less and less research and more and more management - or at least this has been my experience.
I wish Google (I work there, opinions my own) had three ladder flavours for engineers, not two. If we did that, in Google terms (ref. http://levels.fyi), I think: - the IC ladder should go from L3-L6, maybe L7 - the TL/architect ladder should go from L5-L11 (note overlap with IC) - the Management ladder should go from from L5-SVP/CEO (I don't know the numbers for SVP, but I'm guessing ~13 or so...).
Not long ago, I would be heads down in code all day everyday. My world was laser focused on getting out 1-2 code reviews a day, shipping small features. It paid substantially less, but I really wasn’t responsible for projects or deliveries. Business people want a feature? Great... here’s a t-shirt size estimate. Heh.
I love the analogy of a burger joint and ordering a burger with fries, because from a buyers perspective, that’s exactly how we want to buy software. We point out some items on the menu, and we expect them to be delivered together, on time and to our specified demands. The person taking our order, and making it happen is the project manager who makes the different cooks do their stuff in coordination and also the person who puts shit together on a tray.
That’s exactly how people buy software, or at least how they expect to buy it. Only software is more complicated, and developers keep failing to deliver the ordered project on time. Agile was supposed to help on this, but it hasn’t. I mean, it’s anecdotal, but I work in the public sector, we track and benchmark the hell out of these things for a bureaucracy that probably never reads the reports. Anyway, agile suppliers fail as often as non agile suppliers, and they have the added problem of wanting to sell us promises.
I mean, a true agile contract can’t specify requirements, cost and time at once, but how the hell can you ever enter a contract that doesn’t? So they typically end up mixing non-agile sales with agile development. I’d like to note, that we have actually entered into truly agile contracts. Being a digitisation unit in an organisation that largely doesn’t understand digitisation gives you a lot of freedom after all. Only agile wasn’t better, in fact it’s been a lot worse, every time.
In our decade long experience, the only thing that truly works, is when management or project management knows how to make the damn burgers. Which unfortunately means that you need to promote a few developers into unhappiness.
I would like to argue that the burger joint is actually very agile. The person taking the order isn't the project manager. He just has the role of placing the order on the kanban board. From hereon the rest of the people all take their self-managed roles to fulfill the order. You can point out such agile (lean) processes throughout the entire delivery chain.
> Agile was supposed to help on this, but it hasn’t.
My experience has been exactly the opposite. Those companies that managed to achieve a true agile process (or achieved an agile bubble inside a structured organization) were making the best progress. What I do see, however, is many companies misinterpreting agile. Especially Scrum. They see Scrum as a method for ticking off the to-do list provided by the product owner. I've seen project managers posing as scrum masters and project managers posing as product owners. It's still top-down management and the team is expected to follow orders. They don't seem to understand the principles of the sprint goal or how it's actually the development team that ought to own the sprint backlog. They never really did scrum.
> I mean, a true agile contract can’t specify requirements, cost and time at once
This is indeed a challenge. You can - at most - sell sprints. With agile you say: "You have the dev team for this amount of time". It's an uncertainty for the client. But in my experience this has always led to the most bang for the buck. I'm surprised you haven't experienced these results?
> Which unfortunately means that you need to promote a few developers into unhappiness
This perhaps is an argument in favor of agile. Those project managers indeed need to know how to make those damn burgers. Then why not just make them your lead dev (chef-cook)?
I believe IBM was the originator of this approach, but could be wrong.
If they wanted you to build things, they probably wouldn't have put you in management in the first place.
The scaling characteristics of those two patterns are different, because inter-team collaboration is pretty much always worse than intra-team, so the small teams are more effective if they are as independent as possible. If not you end up needing an extra manager to coordinate amongst the small teams... and now you have managers who don’t code.
Instead of? No, that would just make developers think that software skills aren’t valued at all.
There should be multiple equally-prestigious paths so that there is some way to publicly recognize star developers without turning them into managers.
I jumped at an opportunity to manage the software department and enjoyed the managerial side and representing the team within the rest of the company. I didn't like the politics and I didn't like knowing what I started to know about the company itself. A pretty big weight that took it's toll.
Most of all I missed coding, I wasn't doing it enough and I started to fall behind on the industry.
The idea of a Lead role is something I courted but then realised it may not be rewarding. I'd like to know how other lead's find their role...
* sit in a lot of meetings with management/other departments
* try to filter company politics from my team (thus absorbing it myself)
* would try to find what work would be most suitable and rewarding (considering interest & future growth) for each of my developers, thus in practice ending up with the most boring bug-fix & other maintenance tasks myself
* participating in a lot of project-management as well as people-management of my direct reports (weekly one on ones, conflict resolution, planning career growth, etc)
In practice I found the role of Principle Developer much more rewarding.
What I don't like is when I am mentoring a junior on best practices or techniques to increase their performance or the performance of their code and they get defensive to the point of becoming an insubordinate ass. I understand there is a lot of defensiveness in development, but in the corporate world I expect everyone to be an adult. I also expect junior developers can read, write, and follow simple instructions but I have been surprised by that as well.
You come across as a know-it-all and patronizing in the above two comments alone. May be you can start by recognizing that developers are not your extra sets of arms to code stuff. You should limit your self to clearly communicating objectives and measuring them rather than guiding devs (micro-managing ?) at every step.
This way the good senior devs didn't had to be promoted to management roles they didn't want, and the bad devs didn't get promoted to senior not to fuck up the juniors with bad advice.
It was a highly functional company until they changed the dev manager, then it went downhill immediately. Political middle managers soon took over everything, and all the seniors left.
Several of the orgs I have worked at have expectation that a senior developer will help juniors, whether that's formalized as a line management and 1 to 1s or informal mentoring.
Tbh expecting to be a senior developer and not give any time towards leveling up the next generation of software practitioners is both selfish and short sighted.
It's really gross that the higher you go up the tech IC ladder the less you code. Your opinions also somehow matter more even though you're furthest removed from knowing if they're valid.
I think they are not unhappy. They just don't want to admit it. Either they really enjoy this additional human interaction, or they actually really found coding stressful or meaningless. But of course it helps them bond with their engineers more if they can show that despite their +120% income and despite their more beautiful house and wife, and despite having more power they actually suffer because they are not a fellow developer anymore.
One can also argue that the developer who stays developer his whole career is actually not someone who was overlooked at promotions, but someone who really enjoys the coding grind, the low amount of visibility and the low amount of responsibility. But the bonding with their friends is much higher if they can hate on the management together instead of admiting that they actually like what they do and how they do it.
Altogether these realizations made me more relaxed about life. In the end it's not that the world is full of suffering, but we actually choose the suffering that makes us most happy.