14 ms·

Thriving on the Technical Leadership Path

315 points by joshtynjala 7y ago

Ididntdothis 7y ago
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.
- chrisweekly 7y ago
  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.
  - homonculus1 7y ago
    Are you paying your ISP per vowel or sth?
    - chrisweekly 7y ago
      Heh, just typing on my phone in a hurry
dominotw 7y ago
This is bad advice. If you are hitting 40's, please do yourself a favor and go into management. Yes coding is fun but, 1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun. 2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun. 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. 4. Being paid less than the lowest grade manager, is not fun . 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. There is no such thing as "IC track" for almost every one of us, please shake yourself out of your delusion.
- jrochkind1 7y ago
  In my early 40s, I am starting to reluctantly wonder if this is true after all. I don't like it, but that doesn't necessarily mean it's not true. Another point is: In many/most actual organizations, it's the people managers making strategic technical decisions, not anyone on any other track.
  - chrisweekly 7y ago
    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.
  - arethuza 7y ago
    "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.
    - ryandrake 7y ago
      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?
nilkn 7y ago
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.
- Ididntdothis 7y ago
  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.
  - nilkn 7y ago
    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.
    - marcinzm 7y ago
      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.
taurath 7y ago
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.
- tannerc 7y ago
  Your first point rings so true it hurts. 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.
- LordHumungous 7y ago
  You need to pair up with a good manager in my experience.
marcinzm 7y ago
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.
- lordfoom 7y ago
  >Being a technical leader is a set of skills that is distinct from being a great IC Sorry if I'm being dim - what's an IC?
  - TuringNYC 7y ago
    Individual Contributor (ie working without others under you in the org chart)
    - lordfoom 7y ago
      Okay that makes sense, thank you.
  - arnarbi 7y ago
    Individual contributor, i.e. a non-leadership role
    - lordfoom 7y ago
      Ah, okay, thank you.
    - xxpor 7y ago
      A non-managerial role* If you're a senior IC and you're not exhibiting leadership in some way you're probably not going to be around for very long.
      - heavenlyhash 7y ago
bjt 7y ago
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.
- deleted 7y ago
  [deleted]
jdauriemma 7y ago
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.
- Jestar342 7y ago
  Yes, very much so.
- yitchelle 7y ago
  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.
  - jdauriemma 7y ago
    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.
mi100hael 7y ago
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.
- Jestar342 7y ago
  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.
- knightofmars 7y ago
  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." https://fortune.com/2015/11/17/rent-the-runway-exodus/ https://fortune.com/2015/11/17/rent-the-runway-exodus/
  - pkd 7y ago
    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.
  - mi100hael 7y ago
    It's good for what it is. 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.
waltertamboer 7y ago
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.
- 1MoreThing 7y ago
  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.
sargram01 7y ago
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.
- bluGill 7y ago
  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.
LordHumungous 7y ago
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.
this_na_hipster 7y ago
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?
- LordHumungous 7y ago
  Yep. Well said. People making snide comments about "CRUD apps" probably don't work at scale.
  - quickthrower2 7y ago
    "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.
maximente 7y ago
> senior principal engineer 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.
AndrewKemendo 7y ago
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.
lifeisstillgood 7y ago
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
kimchidude 7y ago
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.
mrp443 7y ago
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.
ttldr 7y ago
> 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.
shrubble 7y ago
I think that this is relevant... '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' http://thecodist.com/article/my-biggest-regret-as-a-programmer http://thecodist.com/article/my-biggest-regret-as-a-programm...
mathattack 7y ago
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.

315 points by joshtynjala 7y ago

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.

chrisweekly 7y ago
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.
- homonculus1 7y ago
  Are you paying your ISP per vowel or sth?
  - chrisweekly 7y ago
    Heh, just typing on my phone in a hurry

dominotw 7y ago

This is bad advice. If you are hitting 40's, please do yourself a favor and go into management. Yes coding is fun but, 1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun. 2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun. 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. 4. Being paid less than the lowest grade manager, is not fun . 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. There is no such thing as "IC track" for almost every one of us, please shake yourself out of your delusion.

jrochkind1 7y ago
In my early 40s, I am starting to reluctantly wonder if this is true after all. I don't like it, but that doesn't necessarily mean it's not true. Another point is: In many/most actual organizations, it's the people managers making strategic technical decisions, not anyone on any other track.
- chrisweekly 7y ago
  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.
- arethuza 7y ago
  "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.
  - ryandrake 7y ago
    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?

nilkn 7y ago

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.

Ididntdothis 7y ago
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.
- nilkn 7y ago
  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.
  - marcinzm 7y ago
    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.

taurath 7y ago

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.

tannerc 7y ago
Your first point rings so true it hurts. 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.
LordHumungous 7y ago
You need to pair up with a good manager in my experience.

marcinzm 7y ago

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.

lordfoom 7y ago
>Being a technical leader is a set of skills that is distinct from being a great IC Sorry if I'm being dim - what's an IC?
- TuringNYC 7y ago
  Individual Contributor (ie working without others under you in the org chart)
  - lordfoom 7y ago
    Okay that makes sense, thank you.
- arnarbi 7y ago
  Individual contributor, i.e. a non-leadership role
  - lordfoom 7y ago
    Ah, okay, thank you.
  - xxpor 7y ago
    A non-managerial role* If you're a senior IC and you're not exhibiting leadership in some way you're probably not going to be around for very long.
    - heavenlyhash 7y ago

bjt 7y ago

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.

deleted 7y ago
[deleted]

jdauriemma 7y ago

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.

Jestar342 7y ago
Yes, very much so.
yitchelle 7y ago
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.
- jdauriemma 7y ago
  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.

mi100hael 7y ago

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.

Jestar342 7y ago
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.
knightofmars 7y ago
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." https://fortune.com/2015/11/17/rent-the-runway-exodus/ https://fortune.com/2015/11/17/rent-the-runway-exodus/
- pkd 7y ago
  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.
- mi100hael 7y ago
  It's good for what it is. 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.

waltertamboer 7y ago

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.

1MoreThing 7y ago
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.

sargram01 7y ago

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.

bluGill 7y ago
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.

LordHumungous 7y ago

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.

this_na_hipster 7y ago

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?

LordHumungous 7y ago
Yep. Well said. People making snide comments about "CRUD apps" probably don't work at scale.
- quickthrower2 7y ago
  "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.

maximente 7y ago

> senior principal engineer 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.

AndrewKemendo 7y ago

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.

lifeisstillgood 7y ago

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

kimchidude 7y ago

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.

mrp443 7y ago

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.

ttldr 7y ago

> 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.

shrubble 7y ago

I think that this is relevant... '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' http://thecodist.com/article/my-biggest-regret-as-a-programmer http://thecodist.com/article/my-biggest-regret-as-a-programm...

mathattack 7y ago

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.