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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
Largest corporation in the US, builds the best jet engines in the world, is very innovative. Constantly developing new technology and learning from failure. Amazing culture, laid back, supportive, management is well trained and very smart and they don't force engineers into full-on management.
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.
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.
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.
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.
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.
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 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.
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.
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!
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!
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.
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 :)
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.
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.
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
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.
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 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.
> 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?
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.
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.
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.
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?
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.
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.
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).
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).
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 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.
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.
> 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.
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.
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.
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.
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.
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.
" 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.
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.
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.
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 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.
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.
> 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.
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.
> 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.
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.)
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.
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
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).
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'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)?
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.
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?
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.
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.
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.
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...).
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.
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.
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.
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.
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.
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.
234 comments
[ 3.2 ms ] story [ 272 ms ] threadNot 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.
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.
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.
> 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.
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..
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 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.
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.
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.
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).
"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?
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 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.
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...).
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.
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.
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.
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.