In my experience, many companies legitimately don't really know what to do with very senior engineering staff. And how many distinguished engineers or principal engineers or technical fellows do you really need for your relatively straightforward technical challenges anyway? The IC track often fails to work in practice for the simple reason that technical work at an extremely high level is just not needed at many companies as much as engineers want to believe. Very senior ICs are also difficult to manage in the sense that the more you pin them down to specific work or projects the less you benefit from their skills. But sometimes all you need is to be able to assign someone to a specific project that isn't all that glorious or interesting or hard but is valuable and needs to be done by a certain time.
My experience has been that the value of very senior technical staff is not that they solve "extremely high level" technical problems but they are very easily able to see how what appears to be a complex problem is isomorphic to a much simpler, easy to solve problem.
The difference between expert and advanced/intermediate technical staff is that the advanced engineer has an understanding of complex solution and mistakenly tries to apply them everywhere, so the net effect is to increase complexity. The expert typically sees simple solutions and method of resolving complexity and has a net effect of reducing overall system complexity.
Believing that the value add of experienced technical staff is to only solve really hard problem is likely caused by having too many advanced/intermediate people playing the role of experienced technical leads. All of the great technical team member I worked with always make call solutions simpler and easier to implement by knowing exactly what doesn't need to be done and what is essential.
Much of the last 2 decades of my career has been as much principal work as I can get, and everything I know says you smacked this ball out of the park.
First, if the title is real, then the term Principal carries serious weight, and hews as closely as possible to the best definitions of Principal Investigator (yah, academia has been busy making a mess of that)
More often than not, a good PI knows that all problems don't need the most powerful solution, some just need to go away. If a claimed principal is always applying the most complex solution everywhere, then they're bad at their job.
A good 1/3rd of my benefit is not going 'zomg - a hard problem' to my co-workers, its the exact opposite. And even when it is a hard problem, at least half the time then it's 'Don't worry - here's what Djikstra/whomever did to solve it'
I love advanced algorithms, and relish the chance to actually go try and make ones - that said, my main value is not that, its that some horrible new problem erupts, my job is to say, 'no, calm down. That's an old problem in a new suit'
That said, switch isomorphic to homomorphic - I'll give the seniors credit, they usually tag the isomorphic cases . :-)
The fact that folks can't even agree on what constitutes a very senior IC is definitely part of the problem. I would consider what you describe here -- reducing complexity as opposed to increasing it -- a requirement of any senior engineer. I don't see this as the hallmark of a principal or distinguished engineer but rather one of the basic differences between a developer and a senior developer.
As my employer has tried to define the principal IC roles, I've actually seen the perceived qualifications of the original roles go down. IE, what would have been consider senior qualities are now principal qualities, and seniors need supervision. I believe it extends from the same root cause: not knowing how to get value out of a more senior role.
Something that explains this quite well (IMO) is the Dreyfus model of skill acquisition. You’re essentially talking about the difference between a proficient engineer and an expert, but I also think you’re suggesting there’s a 6th level: mastery.
The beauty of the model, to me, is in the separation of skills. Being an expert programmer doesn’t make you an expert in mentoring, or leadership, or architecture sometimes, and if the place you work has any flexibility with its career setup, there’s plenty of opportunity to branch out once you think you’ve maxed out your current tech tree.
... or you quit and get paid more elsewhere/go consulting/whatever ...
A hypothetical example would be one person spending a week or two setting up an extensive in-house Spark cluster to solve a problem that a second person in one day realizes can be solved on one machine using some clever shell scripting tricks. The former person knows a lot and may have been fully capable of the solution the second came up with, but they followed the wrong guiding principles in analyzing the problem and arrived at a solution of considerable complexity.
An alternate formulation of this would involve the second person above arriving at a new job, observing that they're using Spark on an expensive cluster to regularly perform a computation, and noticing that actually they could do the whole calculation on a single node using simpler tools.
Thanks for the example. Once I did some analytics consulting with a stealth startup with some very talented engineers. One of them was usingusing rsync to replicate their data from their eng server to the analytics server, and I (not a software engineer, but familiar with shell) was initially like "that's it? You're just using rsync instead of <complex, paid replication tool>?" But it was the simplest and most straightforward tool for the job.
You could answer that example problem just by being someone who reads Hackernews a bunch, since the "replace spark cluster with random unix tools" article appears here regularly. IMO, that doesn't really define being a principal engineer, it's basic.
I don't even agree that this is a defining quality of a principal engineer. This is part of our standards for a senior developer, and it's something we coach people on from the get-go.
Team engineers: we need a high-speed design with advanced adders and someone who can do the difficult static timing analysis.
Expert: No, you need someone who actually understands VLSI design who can interleave time and space in an algorithm. At that point, you can basically use a single step up from stupid-simple ripple carry adders. And if you use non-overlapped clock generators you don't even have to do static timing analysis. The biggest wins are in architecture, not implementation.
Yeah, 33MHz design in 125nm means VLSI like it's 1999.
The article I linked is about unnecessary increase in complexity with tiny gains. An expert engineer would be able to tell Juicero's machine could be simpler, and cheaper and faster to produce.
I'd say that 80% of the time, the IC track is bad for the ambitious, non-consulting engineer ultimately, unless your plan is to move around alot, which is a strategy that gets riskier as you get older and better compensated. Even for the consultant, the path to growth is... hiring people and leveraging their labors!
End of the day, the size of your tribe or budget is a physical manifestation of your power in an organization. Power is how you get stuff done -- all of the right answers don't matter if you cannot realize the outcome. IMO, it's critical to grow as an engineer to be able to get others aligned to whatever task is at hand.
My career is very much in the applied space -- my perspective is someone delivering solutions, not inventing tech. It may be different for different disciplines/scopes.
This is an excellent point. About 80% of the time, this is how it plays out in most larger orgs.
The interesting thing is what happens in mid size to smaller companies, where organization structures are not as well defined. You still need people here, however, if you know the stack very well or are a proficient IC, you can make contributions that can have a significant impact on the org, and gain the trust and allegiance of many engineers, albeit informally.
I've seen this happen a lot. A senior engineer will either create or integrate a new tool or process which makes life easier for other teams. They are grateful to the person and are much more willing to hear the engineer out for future designs and projects.
All that to say... just having a title doesn't get you anywhere. You have to build trust by delivering value, however incrementally. Maybe this is really trivial stuff, IDK.
You're not making a great case for senior ICs being impactful.
I mean, what you described is one way to deliver senior-level impact for a team.
However, this has a very important problem. Every time you join a team, you have to build up this rapport from scratch. If you switch jobs every few years, you'll find half your professional time consisting of busting your ass to build up rapport, only to have to start from zero at the next job.
When you're hired as a manager, you don't need to do (this kind of) rapport building. You just tell people what to do, and they will build it.
> If you switch jobs every few years, you'll find half your professional time consisting of busting your ass to build up rapport, only to have to start from zero at the next job.
Not half, all of your time will be busting your ass building up rapport.
Lets look at the alternative: you start a greenfield project with no understanding of what the rest of the company's stack looks like. Engineers know some person was hired to do something, and they may be interested in what you're doing, but they're probably not invested in it (the people who hired you are probably more invested, but they're unlikely to be the ones who have a deep understanding of the tech stack). You're facing an incredibly uphill battle here, as there are certainly going to be things that you will need assistance with (custom libraries, weird deployment frameworks, shitty deployment scripts that only one person somewhere knows how to get working etc.).
You may be a super genius, super hardworking person and be able to pull it off. For the average case, I am convinced this is a backwards way to approach the problem.
Not necessarily. Positional power is only one aspect of a managers capability.
It doesn’t prevent you from using personal power and influence, although most organizations are setup to purposefully make it difficult to function that way.
Usually your best managers do both. Think of the best people that you’ve worked for in any environment. Usually they are people from whom you’d seek advice and counsel.
It is a gross over-simplification - but I've had a lot of managers, and not once have I seen one bust their ass for a year, and then take six months to gather feedback and peer support on their work, in order to get the rapport necessary to do the job they were hired to do.
I mean, they do this sort of thing, in order to show that they are superstar, and should get 2x the headcount they currently have, but they don't actually need to spend a year and a half convincing people with results, in order to be allowed to direct their existing headcount as they see fit.
A senior IC, on the other hand, needs to personally prove themselves at every workplace, before they are allowed to act in the role of a senior. You're expected to deliver the results of a manager, without the corresponding power. You're expected to exercise soft power, and you're expected to acquire this soft power on your own.
It is an incredibly inefficient way of getting stuff done, if you ever switch jobs.
Totally! I believe the debate can be rephrased in certain situations as : whether you want to always be the player or do you want to be a coach at some point. As coach, you remain relevant as you grow older and have a bigger impact on the team. And in tech, nobody stops you from playing as a coach.
When I was an IC wanting to be promoted ASAP I kept hearing from management "We need to see if the org needs this [particular high level] role"
Took me a while to understand this is true. You can't have an org with the wrong ratio of "architects/leads" and coders. Or tech leads and engineers, whatever terms you prefer. An org with 2 teams doesn't need 5 people coordinating cross-team work. An org with 40 teams needs more than 40 engineers, and so on.
It would probably work if the people managers stayed out of the technical side but in reality most managers like to make technical decisions so there is not much space for senior engineers.
It's questionable to me whether an engineering manager can stay out of the technical side completely and actually be competent at their job. I think many non-managers underestimate how technical engineering management actually is. You often have to have a solid understanding of a very wide swathe of the organization's technology, including services whose code you haven't even had a chance to work on. In some ways it's not all that different from some of the expectations for very senior IC roles.
I always take it as a red flag when a manager wants to be responsible for technical decisions.
The best managers I've worked with have always made it their mission to serve technical teams by removing obstacles and making sure that the specialists have everything they need in order to create a high quality product. Managers who try to babysit developers and tell them how to do their jobs tend to just slow things down and lead to lower quality results.
I think that being involved in the technical side and "babysitting developers" are two very different ideas that have little to nothing to do with each other.
> The best managers I've worked with have always made it their mission to serve technical teams by removing obstacles and making sure that the specialists have everything they need in order to create a high quality product.
I think you're underestimating the degree to which doing this requires a solid technical understanding when there are dozens of teams involved and interacting with each other. In order for an engineering manager to bring their team(s) a clear plan of what needs to be done with few blockers or obstacles in the way, often a lot of technical planning with other groups has to precede that. As always, management done right is the sort of management you don't notice -- but that doesn't mean a ton of work isn't happening behind the scenes to make things very organized and clear for individual developers. You could have ICs do that, but they wouldn't be writing much if any code, and they probably wouldn't want to anyway.
Isn't what you're describing precisely what senior ICs should be doing more of?
I agree with OP, the purpose of a manager isn't to manage the technical side of things but rather the people side. It's why they have direct rapports: to manage the people.
A better use of the IC's time is to unblock them so they can meet with stakeholders and develop a rich understanding of the work in order to do it most effectively.
In trying to "shield" the IC from developing an understanding of the landscape they'll be working on, the manager may accidentally be preventing the IC from getting the information they actually need to do their job well.
> Isn't what you're describing precisely what senior ICs should be doing more of?
Yes, and I think the point I'm driving towards is that if this is the stuff you want to do, you're really not an IC at all -- you're an engineering manager with zero reports who doesn't have any authority, so you're making life 10x harder for yourself.
I think your view is seriously constrained by the assumption that you can't have both a manager and a senior IC on a team. You need both to be successful. Every team I've worked in that had success had both.
In these cases, the manager relies on the team, and the IC to get a clear understanding of the root of problems. You don't need to be super technically proficient to understand constraints, but understanding why those constraints exist requires a deep technical understanding, which is provided by the IC and the team. Using this knowledge, the manager has a perspective of the system and how to improve the system, and the manager tries to reason with the organization, trying to share that perspective with them.
The manager also relies on the IC to do spikes or POC's (or relies on the IC to select a crack team which have a good chance of success).
Most often, the IC has no interest in being in non-technial meetings all day, but the manager does. The manager loves working with other managers + product and helping them understand the issue, while the IC doesn't. The IC wants to spend most of their time on resolving technical issues, thinking deeply about the future and upcoming projects.
All of this to say: they're not exclusive, and both are required for successful teams. BUT, the idea that a technical manager needs to be super technical is not something I agree with.
I'm not sure if you're actually disagreeing with me. Of course a team needs a technical lead who is likely a senior engineer. I think that much is obvious. However, that person is predominantly concerned with their own team's technology.
As an engineering director, I have an entire organization of teams I'm personally accountable for, and I have to make sure the work that's being planned out meshes well with what all the other teams are also planning. I cannot constantly be pulling in a dozen senior developers into every meeting every day to help me figure things out. I also have my own technical objectives I want to achieve for the company that cut across multiple teams or the entire engineering organization. Most of these considerations are technical in nature, and while a senior IC on one team can help they frankly don't have time to be involved in the whole process -- that would prevent them from succeeding as a senior engineer in their current role.
Under discussion is not the role of a senior engineer, but rather the technical track beyond that point -- roles commonly termed staff, senior staff, distinguished, principal, fellow, or even senior fellow. My core claim is there's more in common between engineering management and these roles than many folks tend to believe and/or realize.
Often an engineering manager is just someone at this level of seniority who also has rock-solid people skills and has been empowered in the organization to actually get bigger things done that cut across teams, though they may not themselves write code anymore.
Certainly I agree with you that not every manager needs to be deeply technical, but I think that for someone who is deeply technical, engineering management can actually be a much more powerful and interesting choice vs. trying to expand your impact without taking on formal leadership responsibility on an IC track.
The primary disconnect on this larger thread is a disagreement about terms. Does an "IC" mean someone who doesn't have any direct reports? What does it mean to be an "engineering manager"? Are staff, senior staff, distinguished engineers, et. al, without any direct reports part of "engineering management"?
The other big disconnect is in the size of companies in question. At the larger companies, you can have a clear separation of roles, so that some people are almost exclusively managing resources, and trying to match resourcing to business objectives, while other people are much more exclusively focusing on technical issues and how they can achieve business objectives by making the right technical decisions.
In these larger companies, the issue of people on "The Technical Track" not having the "muscle" of people in management is really not true, or at least, heavily over-simplified. (And this is another definitions question; at IBM and Google, Staff, Senior Staff, Principal, DE, Fellow, etc., were all considered as on the Technical track and were considered very senior engineers. Yes, they generally aren't coding much by the time they hit that level; although you might be surprised how much Fellows are still coding.)
>>>> ...vs. trying to expand your impact without taking on formal leadership responsibility on an IC track.
This might come down to cultural differences between companies. At Amazon leadership responsibility is formally baked into the upper SDE roles (Sr and above), literally in the role descriptions. There's definitely still value in being a technical manager, but that's not the only way to get formal leadership responsibility.
Managers don't need to do that however someone needs to attend organizational meetings and deal will all the inter-team semi-technical stuff that keeps a company running. That person will tend to be involved in technical decisions to the extent that they have organizational knowledge and influence. You can have ICs do that however most would prefer a root canal and many lack of the soft skills for it.
There is little point to be a senior engineer in a company which us not growing, or at least seriously changing their technology.
Once the technology works well enough, and the ongoing changes can be supported by mid-level engineers, and there is no big challenges ahead, it's time to move on.
No, this is not how you grow in power and importance for 15 years within the same company. If you want that, management is your path.
I think the important point that's being missed is that super senior ICs are usually promoted for specific reasons. You're making it sound like they are a disposable commodity. But in my experience someone is super senior IC because they have proven to add key value when it was really needed and nobody else was up to the task.
> But sometimes all you need is to be able to assign someone to a specific project that isn't all that glorious or interesting or hard but is valuable and needs to be done by a certain time
There's a lot of business value in certainty. The value of the senior IC is the certainty that your business critical project will get completed correctly and on time. Sort of like how you want a good electrician to work on your house even if the job isn't technically that "hard".
That's just a solid senior engineer, though. You don't need a Senior Distinguished Technical Fellow to come to your house for some electrical work. That's the person you have designing the electrical grid for a city of 5 million people.
I guess if you have a lot of title inflation things might be different. I've definitely seen places where a senior developer is pretty much anyone 2-3 years out of school who does a decent job but still requires supervision and oversight.
That depends. For example my company we are trying to move all of our infrastructure to kubernetes, and we are trying to hire a very senior IC who can lead it.
She's coming from Github/Microsoft. That is a very different environment than most of us. A company of that size has more money to pay people who live outside the regular product org and more opportunities to do "strike teams".
The bullet point list of strategic work that she provides mostly overlaps with what engineering managers do. It's valid to point out that you don't need people reporting to you to do it. It's very cool that she's been at companies that made that possible. But I think it's a mistake to say, as I think many commenters here are saying, that that's the only valid approach.
Being a technical leader is a set of skills that is distinct from being a great IC and those skills overlap management in many ways (meetings, dealing with people, diffusing conflict, getting buy in, etc.). Except you don't have resources to leverage directly except your own, now very limited, time so everything is 10x harder. I was in that boat, eventually I got tired and just got into management.
perhaps (perhaps!) you weren’t a good technical leader after all. the JD you put out there isn’t quite right. you do have other people to leverage...that is your job. you just don’t have hard authority over them. it’s challenging and you can’t get by on pure tech ability anymore. so many very very strong tech folks fail here because they don’t have the soft leadership skills.
your company and your boss have to support you (eg by not micromanaging, so that you can actually effect soft leadership), but the way you put it, failure is a foregone conclusion.
My problem in the senior IC track at my company is that of how to influence people to get things done. Managers can very easily utilize resources, where the IC has to convince people and then also horse trade on priorities between managers who usually own a certain area and can’t really spare much help.
Strike teams seem to the most effective thing for ICs to lead, and having that be an explicit part of eng culture and the work processes is a prerequisite for that.
I've talked with many of my now manager peers and they seem to not understand that simply walking into a room with "manager" or "director" in your title gives you almost immediate clout (or something similar). Whereas if you enter a room as a "senior IC" there's just not as much authority inherent in your presence.
It's unfortunate, it's not right, but it seems to be true.
In my company there is a technical path but it’s really really hard to advance on it compared to the managerial path. We have one guy who is really high on the technical path but he was director before and was a bad manager so they moved him to the technical path. Otherwise I haven’t seen anybody technical promoted beyond the same pay grade of the lowest ranked managers. So it seems to me that the manager path is better just for the fact that it pays better.
In addition, a lot of of the main decisions are being made by management before engineers even get involved. Don’t know how to improve this but from what I have seen in other companies this seems fairly standard.
IME (21-yr career), there's a huge range wrt culture, power structure, and growth oppty across different kinds of companies. The biggest / most relevant diff rel to technical path is btwn orgs that are engineering-driven vs product-driven (except when said product is in a highly technical domain). Maybe obvious, sharing in case it's not.
I'm happy for the author, but did anyone else notice a lack of takeaways for the reader? It reads like a list of accomplishments rather than genuine advice for thriving in technical leadership.
In her closing sentences, she did say "In the coming weeks, I’ll post about how to build strategy and technical leadership skills with the goal of deliberately cultivating a long-term career as an engineer."
I guess you need to stay tune for her next blog post.
Yeah, I read the article. If the takeaway is "read the next article for the thing you clicked on this article for," that seems like the author is squandering the reader's time.
I can so much relate to the first paragraph. When you just start your career, you enter a junior role. It's than expected of you to grow to a medior role, a senior role and than somewhere along the line become a lead.
Well, that's the biggest BS there is. Not everybody is a good lead. It's a completely different job compared to engineering. It takes people skill, organizational skill and it requires you to approach engineering from a much higher abstract level.
Personally I was really unhappy being a lead and I decided to step down. I was doing more harm than good and no-one benefits from that. Not the company, not the team, and definitely not me.
FWIW, if you still have to work 50 more years before you can enjoy a retirement, you better learn what makes you happy and do what makes you happy.
Most places I've been at don't expect you to ever become a lead. Senior is often a terminal role if you don't want to keep climbing. But there is an expectation that you'll continue to grow to at least a senior level.
The Manager's Path by Camille Fournier does a good job covering the various steps from technical individual contributor all the way up through the ranks of management and looks at questions like when to stop getting involved in technical decision making. Would recommend for anyone interested in pursuing a leadership role.
The Fakespot stats on this book and the critical comments in the Amazon listing don't put this book in the same light as you have. Additionally, the conditions surrounding the exit of Camille Fournier and three other C-level individuals from the company which she was a CTO don't inspire confidence that this is good material with regards to the area it is supposed to cover.
"It is a significant exodus in a short time, and many former employees describe a corporate culture at the fashion company that is unwelcoming, stressful, and occasionally hostile."
Having personally read this book, I can add another anecdotal data point to the "it's great" category. It is an insightful book without being preachy and has something useful for people at all levels. Obviously it's mostly based on one person's experience, but there's so much trash in this category of tech books that this read like a breath of fresh air.
It's not a manual for how to be the world's best boss or build the best culture.
It's an approachable, informative view of what to expect at each rung of the management career ladder. I'd argue it's good because it doesn't take an opinionated stance on the particulars of how to accomplish the outlined roles.
The book is certainly better thsn her resume. It is very thoughtfully written, on an extremely important subject that otherwise only has folk wisdom and anecdata to look towards.
Yes, it's a great book and helped me to come to terms with my new responsibilities as a lead. The most important being when/how to relinquish control and trust your colleagues/delegates to do the right thing, with your support.
The list of "What does Strategic Engineering Work look like," looks a whole lot like basic management. Each of these things listed below are fundamentally organizational/resources/personnel issues and except for one have almost no relation to the work stream of an IC which would include actually writing new code, refactoring old code, debugging, etc...:
- Tackling technical challenges that span multiple technical and organizational systems.
- Researching and identifying the problems that could be worked on, a year or two from now
- Ramping up strike teams to help build a thing.
- Looking at the big picture including cultural, product and technical challenges, to help inform choices that would be best for the org, perhaps with a 2-5 year view.
- Forming strategies, writing proposals and pitching them across the company, for new architecture, systems or approaches.
- etc...
Except for developing prototypes, assuming the senior engineer is actually doing that, that entire list are just foundational management/leadership tasks.
This is definitely not true. There are IC tracks at many companies. I'm over 50, still doing technical work, and I'm having a lot of fun. I was a STSM (Senior Technical Staff Member) at IBM and I'm now a Senior Staff Engineer at Google. Yes, most senior technical folks don't actually spend much time coding; it's things like technical architecture, creating slide decks for the VP's, meeting customers, etc. That was definitely true when I was at IBM. At Google I get do more coding, but a lot of my time is spent helping more junior engineers, working subtle bugs that other people weren't able to do, reviewing code, etc. But people management? Heck, no! I enjoy doing the technical work too much to have to spend time doing people management. I'm grateful that there are people who are willing to do management, since it's a different set of skills, but it's not for me.
I do spend my weekends doing technical work (mostly reviewing and testing other people's ext4 patch submissions, and/or reviewing papers because I'm on various program committees), but that's because I love to do those things.
> 4. Being paid less than the lowest grade manager, is not fun .
At least at Google, and at IBM, it's not unknown for IC's to be paid more than their manager.
> 5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.
It may be different for people doing other kinds of programming, but at least for Systems Engineering, there's an awful lot of value in knowing how the various abstraction layers fit together, and more importantly, understand the business imperatives which drives even the lowest level technical work. (Things like maximizing ROI on storage infrastructure by making sure you can efficiently use nearly all the IOPS which the HDD's in your data center can deliver, for example, is subtle work.)
Also, at senior levels, you need to know how to lead technical teams, and that's quite different from people management. And when I say lead, very often you may not have formal hierarchical power over the people that you need to influence; but instead of you have to pursuade them to share your vision and go along with your plan.
> And when I say lead, very often you may not have formal hierarchical power over the people that you need to influence; but instead of you have to pursuade them to share your vision and go along with your plan.
This is the worst part of the whole gig frankly. It's an awful place to be, all the responsibility and expectations but none of the muscle.
The biggest projects span such a wide number of teams and/or departments and/or product areas (product areas at Google are headed by Senior VP's) that you're never going to have someone with the formal authority having either the time or the technical knowledge to run those projects. Even at the department level, the VP will have hundreds or thousands of people reporting to her, and so she's not going to have the time or attention either.
So the authority gets delegated down to the technical leaders, and while it can happen that there will be conflicts that have to be escalated to the VP or SVP level, it's usually because a team simply doesn't have bandwidth to satisfy a request, or are being given conflicting signals as to the prioritization of different projects, and so we need to escalate to senior management to either get more head count, or agreement that a given prioritization will mean that the project will slip, etc.
The technical leaders make the technical decisions, and are responsible for the technical decisions. Management makes the resourcing decisions, and product managers make the product decisions. Usually, it's pretty obvious whose domain a particular decision is in, and as a senior technical leader, I actually know enough about the constraints that I can tee up the question, with the tradeoffs, and then say, "but that's a product-level decision: do we ship with now, or do we slip and so we can add this particular critical feature? Note to management: if you don't like the velocity of the development, we badly need at least 3 more head count by next quarter or we will be presenting you with more Hobson's choices like this."
And that's fine with me; I don't find working with recruiters and negotiating with the CFO for headcount, or sitting in an all day meeting trying to divide up the headcount granted to the department to the various teams. Not having to do that is not "lacking muscle", it's being freed from work that I don't like to do.
Yes, I'm the /dev/random guy as well as the ext4 guy. I've also been the serial driver guy, and the tty guy (Posix job control was my first large contribution to Linux). I also was on the board of the FSG when we hired Jim Zemlin, and when the FSG merged with the OSDL to form the Linux Foundation. I was the Kerberos v5 TL at MIT, and I served as one of the IPSEC working group chairs and on the IETF Security Area Directorate. Oh, and for a while I was Treasurer for Usenix.
See? There are plenty of ways to be a technical leader without being on the management track. :-)
I'm trying but at 35 haven't formally held a title that meant I was leading others. Every posting even for a team lead wants 3 years or 5 years or whatever of leadership already, and that's not even really a management position most places. An MBA and re-entering at the bottom would be very expensive, in direct costs and lost wages.
What's the way in? Hope you find yourself in a job where there are leadership positions open and the stars align and you're promoted into one?
And you're dead right, not every place is Google or whatever. Hell I don't think Google's Google, mostly, in terms of what they actually do, but they do pay developers very well regardless, so there's that. But outside a handful of huge pure-tech companies and Wall Street, you better be moving out of development by 40 or so (earlier if you can swing it, really—god I wish I'd started making moves this way years ago), or your career's (pay's) in for a brief flat trajectory followed by a sharp drop way before you'd have liked.
You can find ways of being a technical leader without having a formal role. You can mentor more junior engineers; you can try to establish better coding and test/QA standards at your company. You can find some open source project that you're passionate about, and take on leadership roles there. Maybe you can find a way to contribute in standards organization.
If I'm interviewing you for a job at $COMPANY, I'm going to be looking for signs that you can exhibit leadership, and that's going to be way more important than whatever title that you might have. If you have the title, but you can't demonstrate ways in which you were able to demonstrate technical leadership, the title isn't going to mean much.
What's the way in? Hope you find yourself in a job where there are leadership positions open and the stars align and you're promoted into one?
In corporate jobs, this is rarely the way in. Most likely, you'll have to convince your current manager (and maybe theirs) that you're ready to be a manager and look for a manager opening elsewhere in the company. If you think you're ready and your current employer does not, you'll have to look outside.
Years of leadership seems like a purposefully vague credential. It's not about a title; if you don't think you've been a leader at work, you probably weren't (or maybe you were and your talent just wasn't managed properly ¯\_(ツ)_/¯ ).
> In corporate jobs, this is rarely the way in. Most likely, you'll have to convince your current manager (and maybe theirs) that you're ready to be a manager and look for a manager opening elsewhere in the company.
Also, get ready for a lot of gatekeeping. “Oh, you don’t really want to be a manager! It’s so much more responsibility and work. You should be happy to be a foot soldier for the rest of your career! Management is not all it’s cracked up to be. As you can see I’m stressed all the time! Now excuse me, I have to go close on my second vacation home in Hawaii.”
The requirement's usually tied to holding the title, like they want that to have been your full-time thing. It's been my experience that people see what you're doing in a very different light depending on your title (one title, one company one day, everyone second-guesses or ignores everything you say; different title, different company, a few days later, suddenly everyone's deferring to you in meetings and sincerely asking your opinion about everything to such a degree that it's unnerving) including in hindsight—if your title was "lead" you don't have to spend a ton of time explaining exactly how, as a non-"lead", you were leading to convince people you were, and you don't have to avoid giving the impression you were being "bossy" or overstepping by doing it.
[EDIT] my suspicion here is that yeah, it's basically "luck into it". I mean that's how everything else I've done career- and pay-progression-wise has worked (luck into someone tasking me with something they definitely wouldn't hire me to do, but after I've done it for a few months someone else would) so maybe this'll work out the same way.
I’ve faced the typical deadlock that first time job seekers encounter: you need management experience to get hired as a manager, but nobody will give you a chance to get management experience because you’ve never managed before.
You should take a look at startups, especially keep your eyes peeled for the growing ones. You’ll have to read the culture to see how they choose managers (promote from within or hire from outside) but opportunities are usually abound and companies just need to get things done. Try to hold out for people above you that you really like and are good, kind folks that want to see you grow. That’s also typically a good approximation of company culture in general, in addition to a good litmus test of whether your bosses can help you in your career progression.
In my own experience, the biggest "killer" is that it just gets boring and repetitive.
I've been programming for 20 years and it is a struggle for me to find something "new" that isn't a mild variation of something I've used before..
There's only so many variations of an application that can bring something really new to the table that gives you that excitement of learning something new like the first time you "get" TDD or DDD, or that first time you successfully implement an efficient CQRS model, with eventually consistent events, or run a GraphQL API that swaps the challenges of REST for a new set of problems and so on. Switching industries doesn't help much either, as they are either just more of the same but with different vernacular, or so niche that you'll need to have really been there since day dot of your career anyway.
There's only so many new libraries/frameworks that I can get excited about, and the rapid state of change in many ecosystems means that quota is pretty much full 100% of the time. Languages, too. That's before we even tackle the problem of getting _hired_ for languages I've not had any professional experience with, and with the added bonus of 0 personal time to implement side-projects, and a lot of companies never needing to stray from their current stack.. it's just not going to happen.
So now the only thing left that tickles my fancy are the "abstract" problems.
Instead of now focusing on implementing code to fix a problem, I'm asking and researching the questions like "How can the platform (and not just application) be more performant?" or "What is that the team can improve on?" and "how can I improve the learning culture?" etc. and using my experience to, at first, recognise these problems that are invisible to a lot of people, but also gauge which ones are actual problems or mild inconveniences.
On the technical track your job is to get the management track to make the right technical decisions. This is hard: they have more power and don't have to listen, but a proven track record of good advice - combined with hard knocks when things didn't go well that you claim to be preventing gives you the power to give them the strategic direction they roll out.
Don't forget that there are more possible correct answers to strategy than there are people to do it. Should your company continue to update the current project, work on the big re-write to fix all the problems, or abandon current products for something complete new? All of these are valid answers for different situations, and some of the reasons to choose each are not technical and so you shouldn't influence them.
I have a dozen projects I'm thinking about at any given time. Some will never get more than thinking about. Some are in progress. Some I'm working to get into progress. Some are likely to be needed soon and are just waiting for the time of need so I can save the day with a plan (if the likely need turns to reality). Some are bad ideas that I need to prove are bad ideas so that we don't go down a bad route.
IME skill-stacking (and including something rel to people / human interaction in your wheelhouse) is the best path to [power / authority / autonomy / clout / leverage]. It doesn't have to be binary "tech or mgmt". But you're absolutely right; companies are groups of people. If your role is such that your influence doesn't extend beyond what you can personally code, your sphere of influence (and career opportunities) will by definition be limited. This can be mitigated by eg explicitly developing skills of presentation and persuasion... but if you work somewhere that has other employees, and don't want to get stuck in a downstream role slinging code, there is no alternative to learning and mastering the [human] interface to the rest of the company.
"it's the people managers making strategic technical decisions"
I'm 54 and I'm pleased to say that I've never worked anywhere where that was the general rule - I've always been on the "technical leadership" side of things (CTO/Head of Architecture) since my 20s and I pretty much see my job as ensuring that "strategic technical decisions" get made in the right way.
As CTO, did you have direct reports? If so, you were a people manager and:
> "it's the people managers making strategic technical decisions"
...was true in your case.
In my experience (over 2 decades now, wow I can’t believe it) the people making the broad, strategic decisions and influencing outside of their orgs all happen to also have direct reports and usually those reports are people managers too. They have titles like “director” and “VP” and “CTO”. How many of those people have you seen who are individual contributors?
The obvious influence belongs to the managers at all levels. ICs have less obvious roles, but good managers look to their ICs for guidance on what decisions to make. Thus there is a lot of indirect authority in the roles that seem to have no power - for the IC that learns to use it.
This is demonstrably true in my experience. You're going to be downvoted to hell because this isn't the 2019 "I want to be an IC forever and I should make the same $ as my CEO" mood. For what its worth, I think the career path is more focus on operations mgmt or focus on tech mgmt.
> 4. Being paid less than the lowest grade manager, is not fun .
If this is the case, your company's technical leadership track has a broken pay structure. You shouldn't need to go into management to get paid better.
As usual, you have to scroll down to the negative voted comments to get the brutal truth. Ignore the happy-talk, this comment is right on the money.
If you’re in your 40s or 50s and not in a role where you’re “influencing decisions outside your own team” you’ll soon be in for a shock next (or next next) job interview.
I hear a lot about people having a younger boss but I think that’s more of a HN bubble. Maybe at some startups but the majority of places I’ve worked at or been to have older people as managers and they all have experience.
Once time I interviewed at a place with a few managers that were in their late 20s. Turns out they were the senior employees only having been there less than 2 years. Turnover was less than 6 months, I passed on the job and my schoolmate was there 5 months. The place had a bad reputation.
If you're in your 40s, and there are no managers younger than you, you're in a very unusual organization.
(But if you're bothered by having a manager younger than you, that's on you; I'm not sure what the inherent problem with it is. When I was a manager, I managed people older than me; now that I'm a senior IC, I have leadership younger than me. Both things are fine.)
OP said if you’re in your 40s and being managed by someone a decade younger than you. That would mean 30s. At my last job there was one manager in his early 30s (promoted at a small company and then switched). At my current org there aren’t any managers in their 30s but there’s more levels. I’m feel comfortable here because my current managers were ex SEs.
> Spending your weekends learning the latest JS framework because you don't want to be someone "who doesn't keep up", is not fun.
It's not about JS frameworks, but if you don't keep up with technology _because it's fun_; and you also what to be promoted very high on the ladder (aren't happy with "just" an average job with average pay that lets you have a decent life outside work) by all means do yourself a favor and move to management.
> because you can't invert a binary tree in 20 secs in leetcode
It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20).
> 2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun.
I've been managed by former students. Worked out quite fine for me. Why wouldn't it? Age does not equal competence.... I'd rather be managed by a competent young guy than an incompetent senior. (bad managers are no fun, that I agree; but bad managers are not necessarily young; and young managers are not necessarily bad)
> Being paid less than the lowest grade manager, is not fun.
Being paid less than what you're happy with is no fun. But it's not really required.
> do you really need 20 yrs of coding experience to write CRUD apps
So don't write CRUD apps if you're better than that.
> What exactly are you bringing to the table.
In general, knowing what NOT to do. Finding out & solving the right problem, not the one that was given to me.
> There is no such thing as "IC track" for almost every one of us,
If that were true, it all becomes a huge pyramidal scheme (you constantly need more young developers so that you can manage them as existing workforce ages).
I'll give you that: for most people, it's probably easier to advance on the management track than it is on the IC track. And the IC track in many companies is a joke (if you're not at the headquarters, advancing is an order of magnitude harder; also you advance easier by playing the advancement game than by being competent in what you do - but that may be true for management too). So yeah, it's not for everybody. But OTOH, middle management sucks... big time. For some people, it may be a good deal to sacrifice some cache upside than to turn into something they don't want to be. It all boils down to what you want to optimize. If you're happy with a good income, even if it's not the best that you could possibly achieve, IC track might be an option (still, change companies every now and then. It's much easier to promote this way).
> It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20).
ok. I was being facetious with that (particularly famous) example.
you are able to breeze through hard leetcodes in your 40's in a tech interview setting?
Why would you be faster at 60's vs 20's , not sure i follow the line of reasoning.
> So don't write CRUD apps if you're better than that.
Can you give me some examples of better things that actually require 20yrs of experience ?
For context I have 2 medals at IOI in highschool. I'm not the most competent in the world (best in my country took 4, all of them gold) but still I'm not too shabby.
Am I as good as I was in my 20s? No. But the truth is that most people can't do the simple recursion... very few places will deny you employment because you can't invent original algorithms on the spot. They'd just fail tou for simple examples like the one you presented. The amount of people who can't do a tree traversal unless it's DFS is staggering. (and in all honesty, not all of them are useless programmers... sometimes people would do amazing stuff despite failing basic algorithmic tasks. That's what makes hiring decisions so hard.)
[edit]
> Can you give me some examples of better things that actually require 20yrs of experience ?
I saw this just now. Lots of things can use said 20yrs of experience... maybe even some CRUD apps (e.g. to know what to not over-design). Some things you probably can't do right without extensive experience (say, design a new programming langugage; or a new datastore). E.g. Rich Hickey famously designed Clojure because he wanted a better way to do those "CRUD apps".
Also, it's quite easy to find a hard problem that you won't solve without extensive experience, no matter how smart you are (say: collaboration, data management & versioning in large AI teams). Pretty much any open-ended problem, really... remove all constraints and most programmers will get stuck. How many people can start with "void main()" (or equivalent) and actually release it to production, if the project takes a non-trivial amount of time to complete?
I don't know what "hard leetcodes" look like... even in my teens I failed to solve _some_ problems.
But what I can tell you is that I switched jobs less than a year ago, I was given as part of the interview process a link to solve 3 problems online in 1h30m and solved them all in 1h. Now, were they rated "hard"? I don't know, honestly.
Also, 2years ago (I think) I participated in Amazon TechO(n) challenge... I was 1st after the weekend, but couldn't work on it during the week (no time/ kids) so by Friday my solution ended up 5th or 6th I think.
[ninja edit] No, I'm not faster, I'm a lot slower. In fact I probably lost most of my speed in the first few years when I stopped competing... but it's not a linear function, at some point, you don't lose any more speed; and just a quick refresher every now and then can boost your abilities back to fairly high levels. And most interview problems are not really competition problems, they're fairly basic.
And no, I don't write algorithms from scratch currently, the company I work for might actually be characterized as "boring" by many people("robotic process automation" - look it up). But I've lived to learn that when there's lots of money involved, there's also lots of interesting problems to solve - one just needs to find them.
I can say you are def an exception, most ppl get slower at these in their 40's than in their 20's.
You seem to have gotten faster. For most people this knowledge tends to atrophy as they age. Maybe you are lucky enough to work at job that requires you to write algorithms from scratch ( embedded engg?).
What is your theory as to why that homebrew guy wasn't able to solve simple recursion problem ?
Either bad interviewer ( focused on syntax rather than problem-solving skills), bad day, or simply this:
> people would do amazing stuff despite failing basic algorithmic tasks. That's what makes hiring decisions so hard.)
It's important to note that this doesn't mean algorithm tests are inherently broken. People who can't solve _basic_ algorithmic problems tend to be weak employees. Rejecting them screws your recall (a few would be amazing if hired) but tends to improve the precision a lot, so the trade-off is often worth it.
> In general, knowing what NOT to do. Finding out & solving the right problem, not the one that was given to me.
So true.
I would add the ability to look farther ahead at potential problems.
I have seen so many young people blocked by some issues that should have been spotted way earlier.
>> because you can't invert a binary tree in 20 secs in leetcode
> It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20).
My main problem is that I look like an idiot while writing code. I pointy-clicky navigate too much for many's taste—doubly so when someone's watching because I start second-guessing every keystroke and so avoid keyboard navigation—and tend not to remember much about languages I haven't written a ton of within the last 48hrs, and even then if it's some feature or function I haven't used in a couple weeks I'll either look it up or poke and prod my way to the correct syntax ("it's either this way or that way... OK, red squigglies, must be that way" or "I think null can just be used as falsy but undefined is gonna throw in this language? Yep, there it is, cool, I'll guard it then" or I'll not be 100% sure about the order of arguments for a "map" function even if I used it ten times yesterday and I'll look at the IDE's hint to get it right, stuff like that). I'm much better at the "what" and "why" than the "how", without support from tools and the freedom to faff about a bit, unselfconsciously.
All that's even worse on a whiteboard, of course. If someone bet me $100 I couldn't write a solution to fizzbuzz on a whiteboard in any language of my choice, that'd compile if input verbatim, without looking up some stuff in the couple minutes before doing it, I would not take that bet. There's a decent chance I'd manage, but I quite literally would not bet on it.
I mean I've been (technically) designing & shipping software for pay for a long time and everyone's always told me I'm pretty friggin' good at it. I've often been the go-to guy for weird crap and "hard" problems. But I look like a total dipshit who doesn't know anything and probably wrote my first "hello world" last week, if you watch me do it in interview conditions. I pretty much only have a career in software at all because not every place does those.
I never would claim that your algorithmic skills define you as a professional - on the contrary with age I got worse at contest-style coding while getting generally better (I believe) at the trade. It's just that my experience is that the companies would generally require pretty basic stuff.
On your points,it sounds more like bad interviews if they're about syntax, not about the logic.
It sounds like you are making a lot of rationalizations for not investing the time to practice live-coding and whiteboarding. Those are skills that can be learned, like any other.
Sure, and I am training those. It's just tough to keep up with when you're happily employed, since you're spending 40+ hours a week working but not doing those things. The longer you're happily employed somewhere the harder it is to keep up with that stuff. People skills? Talking about your work? Plenty of that on the job unless you go out of your way to avoid it. You'll naturally accumulate knowledge, tricks, stories, successes to talk about. Bumps and bruises, too. Algo interview stuff and whiteboard coding? That's purely extra time training on evenings and weekends.
OTOH I'm already near the top of my earning potential as an IC in my area (and for most remote work that doesn't require some prior connection with FAANG & co or excellent skills at algo interviews) so I'm looking to move to roles that don't require that particular kind of prep and are higher-paid besides, tending to be more about concepts, people, and communication (architect, manager, that sort of thing). So I've done just fine working (and interviewing) the way I do, and hopefully the sorts of interviews I'm bad at won't be relevant to me a job or two from now, anyway.
I largely agree with you since I turned 40 not long ago. I still get a lot of offers for ICs, but the salary bump isn't there anymore (I make decent money). When I look for management positions, the salary bump is much higher. I'm starting to question my decision to be promoted to the highest level of IC my company offers instead of taking manager role when I had the chance.
I agree with a lot of this, but I have not worked ANYWHERE that a high level IC engineer doesn't get paid more than a first level manager. As a manager myself, until I got quite senior, I always had more than one person on my team who made substantially more than I did.
There are any some senior tech roles that are not strictly "management": Technical Lead, Application Architect, Solution Architect, Enterprise Architect.
OK, let me offer the competing viewpoint. I've been a technical manager, I've been an architect, I've been a programmer and everything in between. I've run my own company outside of the tech space too. I've been around.
>>1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun.
This is true. This doesn't bother me though. I don't need to find "this" job, I just need to find a job. You ask me to invert a binary tree, don't worry. I'll find a job someplace else, and you can find someone else that has less experience and knowledge than me.
>>2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun.
Don't honestly care. If you're a manager and making decisions on your lifestyle and feel that everyone else should live like you...see previous answer.
>>3. Spending your weekends learning the latest JS framework because you don't want to be someone "who doesn't keep up", is not fun.
Honestly, I don't have to. The foundations are the foundations are the foundations. Do I know how to use the equivalent of Redux in Vue.js? Admittedly, no I don't. I can google that. I may spend sometime looking up new stuff on my own, because I find it fun, but this doesn't stress me out. I can figure it out. You don't hire me as a framework jockey. That's not what I do. You want me to go up against some younger person who spends his time learning React and can tell you the syntax off the top of his head. OK, fine. Call me when your database has scalability issues, or your web server is overloaded.
>>4. Being paid less than the lowest grade manager, is not fun.
Yes, we'd all like to make more money. Here's the thing. I make enough money to live the way I want to. To think that all senior developers can become managers is a joke. Management is an entirely different skill set, and news flash, it's hard. Like really hard. The best manager understands things like accounting and finance. You have to keep track of head counts, who gets what raises, why do they get them. If I give this person a raise and not as much to this other person, will someone leave? How does that affect my staff. Do you understand how to counsel people, because whether you like it or not, you're going to do that too. You are a people person, you get to hear all the things that go wrong, and sometimes you need to understand how to fix them and other times you need to just listen, and you have to know when to do both. Are you ready to put your job on the line when you find out that another manager, or someone above you is sexually/discriminating or harassing people? You get to do that too (blah blah, laws against that. They can do that. Get back to me in the unemployment line on that.). Have we talked about firing people? How many people have you fired before? Not a fun requirement. How many people have you laid off that are perfectly good at their job, because the company wants to hit their bottom line?
Managers may make more money than me ... when they're working. Just think how many managers vs engineers there are in the workforce. Let that sync in. You're competing against a lot of people that are or want to be managers for maybe what a 10th of the spots. Competition is a lot stronger, and that's assuming the open positions aren't been filled by people from within.
>>5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.
What am I bringing to the table? That's easy, 20+ years of coding experience. I've seen enough to know you shouldn't do things a certain way, or a whole range of problems that people who just started out didn't even know existed. I know which log files to look in on a web server when there is a de-serialization issue. I know that a particular linker embeds a date stamp 60 bytes into the header of an assembly. I also know how to write and communicate technical problems to an audience in a simple way to allow them understand the const benefit analysis of a particular approach. You don't pay me to write code. You pay me to solve problems, especially ones you didn't even know you had. Some of them are coding problems, a lot of them are not.
This is a problem I have thought about over my career.
The TLDR; You definitely need senior level engineers (Principal's & Above) as a career track in a healthy organization.
Here is why - (for the sake of discussion, "principals" refers to principals and above)
- In an org, lets say as a director, I find I rely on my principal engineers to objectively tell me what the right thing to do is. They have less political motivation.
- Principal engineers almost unilaterally have a series of noteworthy accomplishments that create a catalyst for innovation for all engineers around. The depth they create inspires people to really understand tech.
- Discussions with them require managers to have more depth themselves. Rarely can managers win arguments without brushing up on tech.
- Regarding some comments about "CRUD apps" as universal easy things all engineers can solve I find perplexing. Problems in distributed systems are all trying to make CRUD possible and organizations are still figuring out how to do that at scale.
- Regarding arguments about ageism for principals, yes, I agree that ageism exists to a certain degree. However, I find most principal engineers are older as you go up the chain. Therefore, what you are really saying is ageism exists for engineers < principal level. Where you can have new hires know the same depth as them and pay less for. Can you imagine trying to hire folks that built S3, Python, Kafka, etc. be replaceable by younger folks?
"CRUD" apps not at scale definitely have their challenges too. Resolving UI/UX/Requirements and pleasing different types of customers with one interface isn't easy.
'When I was on TV (Computer Chronicles) in early 1987 showing our product Trapeze the other presenter was Mike Slade who was product manager of Excel. At the time young me thought him some random marketing weenie (young people can be pretty stupid). Yet he started all these companies later including ESPN, worked for Apple in various leadership roles, was a good friend of Steve Jobs and started his own VC firm'
> Sometimes being the voice for change, sometimes being the voice for not change. Always weighing up trade offs, always listening.
[emphasis mine]
i think she makes a really good point here: one that's often overlooked by the "improve"-everything-all-the-time culture that a lot of contemporary tech inveighs.
it's easy to advocate solipsistically for an alternate solution that you came up with. it's harder to objectively weigh the merits of extant design decision and admit that your predecessor made an optimal (or more-optimal-than-you-can-muster) choice and defend it. iconoclasts may occasionally create great things independently (perhaps if they're a Linus Torvalds or a Margaret Hamilton), but the meat and potatoes of building functional and robust software is building well on solid foundations, specifically by respecting those foundations when they're sound.
IMHO a good senior IC should be performing many of the same tasks as a manager: mentoring and helping junior engineers, setting the team's vision, meeting with stakeholders, and so on. On the other side of the coin, the best managers I've had were also ICs in terms of their code output.
I don’t see why there is a technical vs management path at many companies, you want management to be a support for the product that’s being delivered and your teams should be skilled in and embody the product they’re making first. Management for management sake makes the product a 2nd goal otherwise. You could argue we can’t find people who can do that, fair enough, but there are plenty of companies that do and their performance is high because of it.
There is more than technical situations in focus here. Someone needs to understand the financials and decide if the company can afford to develop a new product, and if so how much to spend. Someone needs to deal with the employee who is harassing a coworker. Someone needs to sell the product. Someone needs to figure out what feature is most important in the new product. Someone needs to figure out if you buy supplies at today's low prices or wait. Someone needs to decide how much quality to sacrifice for lower prices. Someone needs to decide if reusing some subsystem will pay off in the long run.
Some of the above decisions have a technical part, but none are entirely technical questions.
you're telling me there's a difference between a principal and a senior principal? this seems like title bloat (non-financial, meaningless compensation)
i think there are just way too many senior engineers and not enough work for them. this title thing feeds into my hypothesis: if you're getting to the principal level and then encouraged towards "senior principal" level, that's an illusion of career progress.
i think more senior engineers expect to carry the sort of intellectual freedom they had as high output juniors forever as they become "organizationally woke elite hackers". that's just not a good way to portray yourself, though: eager juniors like that person once was will do the job at 75% cost, and not try to occasionally wade into politics as this free roamer has empowered herself to (ref. bullet about cross-organizational lubricant type)
i would be extremely wary of portraying myself as an "elite hacker with enough confidence to meddle across teams" because that is about as vanilla as it could be in 2019. instead i would slot in with an enterprising managerial type and basically become his code peon, pumping out his prototypes, giving him the credit where due, and understanding that he's generating the ideas but not the code, so he can't ghost you very easily and (maybe) he'll keep you safe in the event of layoffs.
this keeps you learning new tech and always building, but makes you really valuable to someone with organizational power, so safer than some generic engineer on a larger team.
Great article. I’d also like to see some evolution to the classic definition of manager. I’m currently in managerial role that essentially replaces half my time (which could be contributed to specialised tasks) with HR-related errands, ie following up absences, helping people acclimatise themselves to the office, etc etc.
IC vs management is a false dichotomy. The goal should be running your own business and this needs (1) knowledge how things work and (2) connections with relevant people. To get knowledge you work on complex projects and making connections with big people is easy when they are small.
I am a great believer in "Software Literacy" - that software is a new form of literacy that we as society will need to ensure is as wide spread as normal literacy.
And I find more and more that using this as a lens solves lots of these sort of conundrums
What do we do with senior / principal engineers? can be translated to "what shall we do with these really good readers and writers we have hired"? The answer is not invent some parallel path in the company to have them walk around looking for solutions - they become leaders of the organisation ... or they go out.
And as for the C-suite. No CEO ever announced that "well I used to read and write but I don't have time for that anymore. I do enable my skip levels to do more reading and writing on their 20% projects however. Sometimes I dream of taking a week off in order to write something - maybe an email, like the good old days"
If the management of the organisation is spending less than half its time coding, the company does not have enough automation and will get its arse kicked by 2030
My takeaway from the article is these last senior resources have earned the right to work on longer term projects. This is vital for organizations to both innovate and clean up technical debt.
