
Thriving on the Technical Leadership Path - joshtynjala
https://keavy.com/work/thriving-on-the-technical-leadership-path/
======
nilkn
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.

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

~~~
oarabbus_
Would love to hear some examples of experts decreasing complexity and advanced
engineers increasing complexity.

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

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

~~~
foobarian
Principal engineer: arrives at company, notices expensive Spark cluster,
replaces with one server running shell scripts

Double digit-strong data science team: speechless

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

------
marcinzm
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
>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?

~~~
arnarbi
Individual contributor, i.e. a non-leadership role

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

~~~
arnarbi
You're right, that's what it usually means. But gp was asking about it in the
context of this comment:
[https://news.ycombinator.com/item?id=21377401](https://news.ycombinator.com/item?id=21377401)

Here it's being used to contrast with both TL-ship and management.

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

------
Ididntdothis
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
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
Are you paying your ISP per vowel or sth?

~~~
chrisweekly
Heh, just typing on my phone in a hurry

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

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

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

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

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

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

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

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

~~~
dfxm12
_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
¯\\_(ツ)_/¯ ).

~~~
dominotw
> If you think you're ready and your current employer does not, you'll have to
> look outside.

Is it even possible to find a management position outside without management
experience?

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

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

~~~
quickthrower2
"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.

------
shrubble
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-
programm...](http://thecodist.com/article/my-biggest-regret-as-a-programmer)

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

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

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

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

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

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

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

