I’ve been reviewing a lot of career path documents recently for different engineering orgs, and every one is fairly uniform in that you either progress into management, team leadership, or architecture (or some blend of the three). If not, you’ll stagnate at a pretty high level, but stagnate none the less.
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.
A better fourth path is to transition to running your own business. You still get to write the code, and you remove the salary cap.
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.
So instead of going into management because you don’t like management and want to stay an individual contributor, you now become not only the manager of your own company, now you have to worry about marketing, finances, etc.
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.
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.
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.
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?
> You're doing that thing I warned you not to do...
> 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.
I'm really tired of seeing this posted whenever someone talks about their success. It breeds a loser mentality where people just assume they won't be successful, so they won't even try.
Bringing up "survivorship bias" every single time this topic comes up goes far, far beyond just talking about the possibility of failure. It's a self defeating mantra people use to justify their inaction.
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.
How is the cost of failure low? If you decide to go in business for yourself and it doesn’t make any money for 3 years, and you are just making non west coast salaries, you’re still potentially out of half a million dollars or more in total comp.
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.
Let me be crystal clear: I'm talking about building up a side business in your spare time.
> 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?
That even lessens the chances by starting it on the “side”. You will be competing with people who are better funded and are able to commit to it full time.
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?
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.
I skimmed the articles from the link. Most of them made less than a $1000 a month.
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.
Being in management is way different than running your own company.
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.
I couldn't agree more. It's a toxic mentality, it allows people to just say successful / rich people must have ripped someone off or just been really lucky. Dealing with fear of failure has turned into my biggest obstacle in life.
many people just don't want to do anything besides coding. it's the reason there will always be workers and business owners.
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.
One. 45 is the very beginning of when ageism starts to show (at most companies). There are certainly some companies that would be biased against a 45 but maybe you don't work there. Just wait.
Two. You're not going to multiply your salary by 2x-20x unless you start to take on more responsibility, like worrying about sustainability.
So you mean if I work really hard and double my income, I can have the big house in the burbs, cash flow my son’s way through college, and in a few years and just work part of the year as a consultant/contractor?
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?
I don’t know how it works in the US but in the U.K. becoming a contractor can provide a good half way house between being employed and running your own company.
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!
Having worked with contractors in the US, there are some added legal cautions where employers for especially software contractors to not setup too long/close of an engagement. But, in general many contractors will end up working for a larger contractor house which carries your vacation/healthcare etc. They of course take a cut to do that. None of them are exemplary, but some are less terrible. An arrangement of a cooperative of contractors and even whole mini teams could control more of their own destiny would be interesting there.
From your network, and everybody has a network. However, you need to make sure that your network knows that you're available.
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.
Yeah seems reasonable, nothing wrong with going through a recruiter, it can just be harder to find the interesting work as recruiters. But a good recruiter is definitely a useful thing to have and it can’t hurt to reach out, if just to get a sense of the market. It can also be worth emailing companies you’d like to work with (e.g. interesting or nearby) with a quick note offering your services. Even if they aren’t hiring permanent sometimes there’s budget for a contractor.
Personally I’ve been lucky enough to find it via word of mouth/recommendation and also directly approaching clients. Most contractors get their work through recruiters though, if you mention to a recruiter you are interested in contract work you’ll start getting a ton of phone calls and emails. It’s not uncommon for contracts to get extended several times, and you’ll probably build up a network of other contractors quite quickly.
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!
To get contracts as a contractor, you need to differentiate yourself from the market as best as possible.
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 :)
In the UK you need to be careful transitioning from permanent to contract for the same company without a gap as it could be an IR35 risk (assuming you want to operate as a Limited Company at least). Not saying it’s not possible but you’d need to be careful and explicit that the contract isn’t just a direct extension of your permanent work.
I don't think it is the "Business Stuff", though that can be troublesome. It is the hidden costs. You often have to be significantly more successful running your own business for the same "deal" to make sense, which is hard. Some people manage to find their own path, but that requires a lot of effort.
this is what we do, we help our employees start their own businesses as the top of the career path. We will help them with marketing, HR, recruiting, finance, etc. Also they can run losses while getting started.
We havent had anyone get promoted to this level, but several are close.
So that top tier is starting a new business line inside the company essentially? Or is the idea that that company might get spun off to a separate entity eventually? This sounds like a pretty nifty / unique idea so just curious how that works
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.
> If not, you’ll stagnate at a pretty high level, but stagnate none the less.
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.
There is nothing wrong with stagnating but in a lot of companies the stagnation level for engineers is pretty low compared to management. You also have to deal with the fact management has decision power so you often get overridden by less qualified people who happen to be in management.
True.. But engineers often have more knowledge than judgement. Engineers are often too cautious to run businesses successfully. This isn't a blanket statement, but engineering school does not make an entrepreneur or even create much business savvy.
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 am not talking about ballsy moves. I
am talking about middle managers blocking things because they don’t understand them or they want to keep their own pet project relevant.
This is the biggest counterpoint to the article. I think a bad developer promoted to a position of management wreaks much more havoc than an unhappy good one.
This is my plan. We'll see how it works out, but my endgame is a technical lead on a relatively small team.
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.
Not in my book. Don’t let yourself be peter principled if you know you’re exactly where you want to be. Not everyone is that self aware, but there’s no shame in choosing your own path.
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.
Isn't this more or less what Google does with all their profitless projects? Giving senior engineers something to play with so that they don't leave for the competition or create new competition.
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.
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 was in a group a bit like that. It was small product-focused R&D team of ~6 people, charged with figuring out an emerging disruptive industry change, and building a new product line for that. (The rest of the company was directed not to even allude to our existence, since that might interfere with sales of the current products, and we even had a stealthy group name.) Except for me, who was the token enthusiastic kid, it was hand-picked from among the top engineers in the company.
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).
Yes, we figured it out. The ROI question is complicated (and I'm a techie, not an MBA). At some point, old product line management appeared and took over everything about the new product line, bringing in much/most of the company's engineers and managers. I stayed on for this new phase. I later had a rapport with some people who'd had executive-level visibility, who confided a few bits of why some things happened, but I don't have enough information (nor MBA qualifications) to distill useful lessons from that here. I'll just say my sense is that the original team performed well for the organization, and then organization things changed outside the team.
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.
I loved it. I think the team lead managed it well. It helped that we already had insight into the old problem domain, and how it was changing. And experienced engineers can generally collaborate effectively, as well as work self-directed.
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).
I read this article a few months ago about being a Principal Engineer, https://blog.dbsmasher.com/2019/01/28/on-being-a-principal-e..., and ever since it’s been my designated career path / plan. I am in the lucky position of working in a small-but-growing team of developers, so I get to choose my career advancement and have support to follow this road.
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.
Which rewards? If it is salary, at least for us (I work with the author of the referenced article), we strive to keep those levels the same on the technical and managerial track.
I hopped between lead -> manager -> lead and I agree, though it’s informative to see the problem approached from both sides if you can stomach a manager stint (I had much trouble). Lead/Manager pairs have roughly the same success metrics IMO but split responsibilities and focus areas so you’re definitely right there, in my experience manager/lead is the same level on different career paths
If you ever decide to try the manager route again, look me up. My email is in my profile.
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.
Most of the companies I’ve worked for have utterly no possible capacity for formally managing special projects. It will either be an argument over what business goals the project must serve, whose autonomy gets to drive the project, politics about who gets to work on what.
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.
I've done special projects at a large, somewhat stodgy company, and the general pattern was that you had about nine months to do good work, just engineering and business folks together, after which point the "project management office" would get their hooks into it, and any further scheduled meetings would be prevented from achieving anything productive in deference to the new project manager's interest in gantt charts.
The other cool beyond-Senior role I’ve seen is “roaming fixer.” Take your pick form the engineering org’s hardest problems, conscript your pick of regular engineers into your service for a few months, go solve it. When you’re done, pick another one.
" 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). "
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.
I’d highly recommend you start laying the ground work for this to become your reality. It may take six to twelve months, but some simple repetition around proposing this as an option may turn out well for you!
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.
Thank you for saying that, this was exactly my conclusion when reviewing my own goals and notes on how other companies build products. If your company doesn't have this special-projects track in place, then your only option at some point is to quit and start your own thing I'm afraid.
Yeah, but parent mentioned "autonomy" as the driving force for people who'd want this track, and I'm very much in the same situation. Management or architecture won't give you the same level as autonomy as working in one of these small "Tiger teams" (thanks to sibling for pointing out that term)
> You really think that you can spend most of your time designing and coding as a contractor or start-up founder?
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.
I spend a huge amount of time coding as a startup founder, but also a huge amount of time doing 10 other things too. Owning your own business tends to mean doing a lot of everything, with coding just being one of those things.
I used to have the same idea about those small teams given autonomy to hack and get some clear objective done whatever it takes. I think a lot of corporate environments is really missing this option.
Since you seem to have some idea of what an Architect is, can you explain this to me?
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.
Yes the average ones are like that but the good ones I have seen provide a broader perspective, simplify solution, prevent the excited devs from trying out complicated solution with hyped but unsuitable technologies among other things. They save so much time and effort of an org that they are much more valuable than many managers.
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.
I’d like to think I’m one of the people who manage to do good despite the title. I see the job more as technical review (like code review, but at a higher level taking into account how systems interact, and existing solutions used in other places). Sometimes I’ll also try to drive the adoption of technology which has the potential to improve systems - in those cases I’ll typically be the one doing exploratory work to validate the solution is viable at all, and then working with other developers to introduce it.
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.
You probably fit the "principle engineer" or "technical lead" titles better. But it's hard, because no doubt in many companies these titles have been corrupted* to mean something else.
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
I know different teams assign or utilize architects in different ways. One option is just as team leader/senior developer who evaluates design choices and helps to make final decisions on the plan. But I think it's more helpful when an architect has visibility into multiple systems and can give high level insight into how everything will work together.
You stay in the company long enough and you write less code and spend more time managing people and processes as now you own your projects as the most knowledgable person for these projects.
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.
George Hotz once mentioned in an [1] interview; Managing people just another abstraction in making software. You can think of people kind of like an IDE that you can use to create things... I thought it was an interesting way to view management.
Yeah my boss certainly sees me and my colleague as a technical problem solving API: he says “now that I have told you what the problem, it is no longer my problem, and I don’t want an update unless it’s the solution.”
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..
I would argue that the how is up to the team and it is the boss/managers level to ensure the right competencies are present in the team. Having the boss join the team is not sustainable.
big companies do not innovate. (counter examples welcome!) unless you’re in a 1-20 person startup, your impact is -5% to +5% as a division. Essentially you’re stroking egos: yours or management’s. best to choose the latter and try your hand at changing the world in after-work projects.
As has been seen over the last two decades, small companies can’t “innovate at scale” when it comes to hardware. The logistics, supply chain management, etc. makes it almost impossible. Look no further than the smart phone market.
Well at least innovate and survive in the mass market.
I would argue these are the exceptions that prove the rule. They all have demonstrable leaders that made this happen. Xerox is done, as is AT&T, as those leaders are long gone. Sony is another one that lost their leader and their magic.
I would argue Apple is on this route now as we are only now seeing the impact of losing Jobs.
This is what happens when management is valuated more glorious than any other activity. Systems and hierarchies therefore tend to reward good performances with what they considers as good recompense: management position.
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.
> This is what happens when management is valuated more glorious than any other activity.
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.
I think it has a lot to do with wanting to have your cake and eat it too.
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.
A good manager is not a multiplier but a subtractor. They subtract the inanities and insanities of flawed organisations - they allow use of more appropriate tech, or they encourage developers to take on projects that might otherwise be frowned upon.
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
> Supposing you literally “just write code,” there’s a ceiling to how much impact you can have
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?
Yes and, if you're into it, you can model the effectiveness of those teams/projects in terms of productivity multipliers for other teams that use them.
> 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?
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.
I agree, but this website was dedicated to startups once upon a time. Now the dogma is that a single coder can do nothing and you need a "force multiplier".
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.
If as an individual contributor you produce 8 points per week, as a manager you're not going to get other team members to produce 12 - unless they are much better developers than you were in the first place.
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.
I agree with what you’re saying. When trying to coin an example I was imagining a team of ten with little in the way of focus and leadership, which means a lot of interrupts, conflicts, and changes in direction (ie lost points), compared to the same team with an effective leader clearing the way for them operate as you describe. It’s admittedly a contrived example.
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.
> 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.
"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.
Agree with all you say. the people who have a "higher multiplier" indirectly enact value rather than directly "at the coal face".
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).
The manager still created a 36 point gain. The policy of hiring one less worker and one more manager created a 28 point gain, of which 36 come from the manager and -8 come from the missing worker.
(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.)
A solution for that is promoting the best developers that don't want to manage into technical leadership roles. They can still create things and impact the team positively, and will not suffer with managerial tasks.
> 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 wrote code like a madman and then went into management. I like management, but I understand what the author of this article was getting at.
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.
So how DO you deal with people under you writing code under you that just boils your blood? Especially if you instinctually see that their contributions are always more counterproductive than not, but everyone else (including their people manager) thinks they're alright?
I am a manager as well, and I just recall that there are only so many hours in a day and I couldn't have written all of that code myself. But that's for suboptimal code, not atrocious code.
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.
Inspect your own feelings of why you feel your approach/solution is better. If you haven’t done it before, this can be a lot of work.
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.
Performance and quality is something you can mentor. I work my ass off to make sure my devs have a plan to get better at their craft and learn from others. If they're not doing well I tell them immediately before it grows into a shitshow.
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.
Every time this topic surfaces project management in the form of politics and pushing tickets through Trello is presented as the only option available to engineers. To me, a more natural progression is going into product management. It's a nice intersection of management, product design and engineering. From a job description:
"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?
Can’t say definitively, but know that these days if your resume has X and they are looking for Y it’s a no-go. Even when X overlaps Y significantly. Hard to even get a job as a programmer in one language with experience in another.
I cannot relate to this article at all. It's the polar opposite of my experience.
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.
In my experience, people are usually promoted into management when they demonstrate leadership. I see you talk about your technical ability a lot, but that is generally not the core competency of an engineering manager. I suggest working on those abilities. It is very much so one of those situations where doing the job will get you the title.
> In my experience, people are usually promoted into management when they demonstrate leadership.
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.
Agreed. The definition of leadership that most leaders have in mind is very superficial.
They just want people who look and talk like a leader but they're willing to compromise on everything else (all things that actually matter in terms of producing value).
Most software companies either are mini-monopolies or they are able to keep securing VC funding through social connections so they can afford to have mediocre leaders who can talk but don't deliver.
I run and maintain a successful open source project which is used by thousands of companies and has a small team of contributors who work for free.
So maybe your definition of leadership is outdated. It should be all about results. All the rest is BS IMO.
Maybe you have bad habits, maybe you aren’t in the right social circles. Maybe not interviewing at enough companies. Hard to say. But you should keep your mind open and not only point a finger outward.
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.
It sounds like you're not quite used to the political game that comes with getting ahead in the corporate world. If that is the case, do you honestly believe you would be happy in management?
Ok, the reason is coming into focus. There’s a natural arrogance that comes from being smart and in your twenties. I wasn’t the worst but suffered from it a bit myself, and remember a colleague who was almost intolerable. We’d all get a good chuckle from him once in a while.
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.
> 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.
Moving from being an individual contributor to a manager isn't a promotion: it's a career change. I moved into management in my 30s because I thought I could provide more value as an engineering manager than as an IC. I spoke to my management, and they agreed.
Have you talked to your manager about this? If your company has a non-terrible leadership, they should be able to tell you what specific qualities they look for in management and what you need to improve.
Do you have yearly reviews with your manager? Make it clear that you want to get into management. At the very least, they won't be surprised if they fail to move you to management and you leave (and they'll be forced to confront the choice in those terms before making it).
As someone who's about to enter management track, I'd be curious (and open to a conversation!) about what you've been doing to both demonstrate your management skills and putting up your hand about your desires.
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!
Thankfully, many if not most top tech companies in the valley realize this and have parallel management and IC tracks (at least for software engineers), with compensation the same.
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.)
Many in theory have parallel tracks but in practice it seems either the vast majority choose to go into management or that it takes a more exceptional individual to progress in the IC track (my money is on #2). IMO you don’t really need to be an above average person to reach the second layer of management, just put in your time and not fuck up, but everyone I know who hit the same level as IC was exceptionally bright and was like that long before they hit that level
In my company it's certainly the case that in order to progress on the technical track you need to be extremely good and more importantly on the right projects. I see a lot of mediocre people advance on the management track but only very few advance above a certain level on the technical track. Considering that salary is directly tied to a person's rank I think it's a very rational decision to go into management even if that's not your inclination.
It's _vastly_ harder to get ahead on the "engineering" track. At Google, for instance, it's to the point where as a manager you barely need to have a pulse to get promoted (as long as your reports are any good), whereas on the technical ladder promotions to Staff level and above are stupid hard and downright nondeterministic.
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.
This is also true of my own employer (a fellow FAANG) - the technical track is incredibly hard to advance in past senior, it seems to incentivize devs moving into management, along with the pay differential where even in the same tier, management makes a little more in general by a couple of $10k.
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.
Google aside there is nothing worse than getting stuck at middle management in a software corp after 40 - 50. You are expensive, replacable and disposable.
Oddly enough I've never seen managers complain about ageism or the difficulty of finding jobs later in life, but it seems to be rather common around here.
So maybe there is something worse: bring stuck as a developer after 40-50.
> 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.
Yep, by L6 you're probably spending less than half your time coding even on the IC track.
For many developers, they turn out to be good at project management, its not much different conceptually than being an architect, this issue is, once you 'level up' you're expected to stay there, rather than moving back to develop for some period of time, and letting the next guy get tapped for project management - It think more companies rotated those roles around, they'd see greater retention, greater employee happiness, and probably lower costs - as an engineer, I don't want to be a PM forever, but I might be happy spending 1/3rd of my time over a given long term period wearing that hat.
> its not much different conceptually than being an architect
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.
Funnily enough, it's the same thing in academia/research. You get into it because you like doing research and you (think you) are good at it. And if you are really good (and have a healthy dose of luck), eventually you progress to being a professor, you are principal investigator of some projects, and you find out that your job now consists mainly of managing a group of people -even if you aren't especially good at management and haven't been trained for it- and writing grant applications, and you have almost no time for actual research.
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 think it's pretty common to talk about "management career path" and "tech lead / architect career path", and I think it's a mistake. I think there should be three paths: manager, TL/architect, and individual contributor.
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...).
I’m in a senior level engineering role at one of the big tech companies. I was more than happy to receive the promotion, but the time I spent coding has certainly decreased a large chunk. I spend a lot of my time now facilitating projects across organizations, providing guidance to more junior engineers on architecture, sending emails and status updates, etc. at least that’s the norm on my current team.
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'm surprised how these traditional organizational structures still exist so strongly today. It sometimes feels like the whole agile/lean revolution (with self-managed teams) never happened.
The agile revolution never happened because it’s just not how people buy things. Hell, I don’t even think it’s how we build them.
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 love the analogy of a burger joint and ordering a burger with fries
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)?
Some companies specifically work to avoid this by having two "tracks": a management track and a technical track. The management track has many titrated ranks (manager..assistant director...) while the technical one still has salary increases and fewer ostensible title "promotions". So an IBM fellow is as prestigious as being a Sr VP or maybe GM, yet the holders didn't climb the "greasy pole" required of traditional management.
I believe IBM was the originator of this approach, but could be wrong.
Nowhere it says - we cannot program when we become a manager. What if managers continue to make 0s & 1s dance - half of the time if not full time? Wouldn't that be productive & fun? I would say world is changing towards this side. I have heard stories where VPs & SVPs in big enterprises write code & lead their teams by example.
I think this is a question of scale and hours in the day. In my experience when the team grows past 5 it gets difficult to do all the leadership things that “clear the road” for the team and also have enough focused time for effective programming. But at the same time, once you’re at that point, if you stop coding you can now handle another 5-10 direct reports. So you have to chose between keeping independent teams quite small with team leads who code, or with allowing bigger teams with a dedicated manager.
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.
The problem arises when you are evaluated based on your managerial responsibilities. The more time spent writing code, the less time you have to manage others.
If they wanted you to build things, they probably wouldn't have put you in management in the first place.
I remember starting as a developer wanting to be respected by my elders, and just looking to become senior as soon as possible. I got it and didn't feel very different.
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.
I actually enjoy management even when it means more administration at sacrifice to writing code.
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.
It sounds like you're not a very good manager, unfortunately. One of the most important things a manager does is understand how to communicate productively with each of their reports. If you have reports whom you believe cannot "follow simple instructions", your first response should be to re-evaluate the way that you provide guidance to that person, not to decide that they're "an insubordinate ass".
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.
In my previous company all the senior engineers took a few juniors under their umbrella and had very informal one-on-ones with them, just to bypass the troubles with non-technical managers. Hereby I as senior could give practical advices, eg how to deal with politics, without having to go into politics, excel and powerpoint and meeting-hell by myself.
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.
You kind of described a highly disfunctional company, where you as a senior sw engineer literally had the power and authority to choose who would get promoted and who wouldn't.
I think what he is saying is not particularly uncommon.
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.
No, I never talked with my manager about anything I talked with my juniors. I only advised my juniors how to deal best with managers, but mostly we talked about code.
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.
The machine is a companion and safeguard against swallowing too much of my own BS, or the BS of others that I get involved with. I'm unhappy without that level of feedback being frequent. Even declaring for Crocker's Rules doesn't get you really honest feedback from humans.
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 have rejected any calls for leadership positions which would mean I’d code less than 90% of my time. It might have cost me some money but it sure means I can do what I love and I have less than 1h of meetings every week. I still try to do technical leadership (architecture, coding standards, evaluating new products etc) but not people management.
In my experience, this works when you're younger, but as you age, you tend to accumulate responsibilities that take up a lot of your remaining energy. YMMV though.
My boss is engineering manager at our company of 60 people (he leads 16 engineers) and still finds time to get down in the weeds solving tech problems in addition to managing us. I’m his number 2, based in another country and am responsible for managing/supervising 7 engineers. I too am expected to do development work AND management of the team.
If you are a good developer, you are probably smart, right? So why would a smart person let something happen to him that he can't fix? Would it be possible for a dev manager to apply as senior dev in another company?
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.
When you understand how few lines of code create the business you work for, you realize the value is in taking risks on new product lines, which, are politically discouraged by most companies. for example, google.com could fire all employees tomorrow and still dominate search $ for 10 years based on an idea from 1999.
The author Rob Walling co-hosts the podcast Startups for the rest of us: https://www.startupsfortherestofus.com which is the best podcast I know of about bootstrapped startups.
Make a lot of money doing boring management work for a large company. Save as much of it as you can and retire early. Then code as much as you want - thats my plan at least :-)
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.