
Defining a Distinguished Engineer - johns
https://blog.jessfraz.com/post/defining-a-distinguished-enginner/
======
DVassallo
You can exhibit leadership and all those things at a much lower job tile.

On a semi-related note: I really dislike job titles. They make people think in
labels. The most powerful feature of a team of creators is their
idiosyncrasies. The best way I found to build something as a team is to adapt
the work to the strengths of the individuals. Job titles squash the peculiar
strengths and differences into a label and make organizations treat people as
fungible units of work. Too many organizations define the work first and then
assign it to the individuals, rather than define the work _based_ on the
individuals.

~~~
allyant
It seems to me these days that job titles are more an indicator of time-served
rather than technical abilities in many organisations in addition to a method
of retaining staff.

I recently observed a company move from 'everyone is the same title' to
specific jnr, snr, distinguished engineer titles. The primary reasons for this
was to create a framework for salaries and provide a defined track for
'progressing' as the organisation got bigger.

But if you think about it - it really comes down to a method of retaining
staff and salary banding, I have yet to see any organisations where the titles
of engineers defines their abilities, all engineers have the same say.

~~~
titanomachy
I work at a very large company with decades of complex systems. I find titles
useful because they let me quickly identify experts on other teams who are
good at communicating.

If I have a problem integrating with their service, I will get more useful
answers from that team's "senior" or "principal" engineers than from an
"engineer I" who just joined the company a year ago.

Higher titles are not given out lightly here, so they still have some
usefulness. I have yet to meet a senior who is anything less than highly
competent.

~~~
zachr
>I have yet to meet a senior who is anything less than highly competent.

Where is this mythical land? Are you hiring?

~~~
jdsully
Sounds like Microsoft’s naming scheme. I also found seniors there to be highly
competent - but it does vary by org.

------
3pt14159
Overall great, but I've always disliked this:

> Have strong opinions loosely held

It comes out of the very true reality of needing to pick a direction and lean
in hard. For example, Postgres vs MySQL. Almost anywhere either would do, but
you can't split the baby. Pick one or the other and carry on.

The part that breaks down for me is when people start talking about having
strong opinions. Why on earth would I have a strong opinion that I hold
weakly?

I'm just honest with people. We went with Postgres because we had to choose
one or the other, but both would have worked.

The things I have strong opinions on are the very things that are _not_ weakly
held. "One shouldn't use Ruby for feature extraction on video at scale." It
would take a _lot_ to convince me otherwise, hence the strong opinion.

I find some people have trouble thinking in non-discrete ways. For example, I
know this smart guy but he's just irrationally pissed off at five star rating
systems and he only ever gives 1 star or 5 stars. He considers it a usability
failure because he'd rather do a thumbs up or thumbs down. I discovered this
only after complaining that the five star system was _not continuous enough_
for me. I wanted to give something 4.8 stars because it was great, but had
some slight flaws.

~~~
sailfast
You make a good point, but I don't think loose = weak here. Loosely held, to
me, indicates that you are willing to consider other options when presented
rather than ignoring what's out there. So have a strong opinion, but be ready
to listen when other options are presented. This, in my mind, does not equate
to _weakness_ of opinion, just ensuring you are actually _hearing_ things.

~~~
ngngngng
It's just more nuanced than the phrase acknowledges.

I have a strong opinion that Go allows developers and teams to be much more
productive than Java. But i'm not going to to complain if someone above me in
an organization makes the call for Java. Does that make the opinion weakly
held? I don't think so. If I was calling the shots there's no way i'd pick
Java over Go.

~~~
sailfast
This interpretation also makes total sense and was different than I was
considering - nice! Continue to have the opinion but don't let it stop you
from being productive when presented with circumstances that don't match with
those opinions.

------
C4stor
I'm really curious about this item

>Community Good technical leaders are also leaders in the outside communities.

Well, why would they be ? I mean, they can be, but I fail to see it as a
requirement.

I'm a bit concerned that nowadays the dev culture is that you should be
working ten hours a day, and also go to meetups/brown bags lunchs/user
groups/whatever another 3 hours to show off how passionate you are.

Any opinions aroud that ?

~~~
jcoder
I feel like the author's prose right underneath that heading explains it
really well:

    
    
      If you silo yourself to only learning within your company, you are missing out on a world of experiences and expertise different than yours from the external community. Technical leaders realize this and place importance on learning from the larger world of computing than just their solo.
    

New ideas get introduced to orgs in many ways. In my experience, it's
primarily through hiring new people, but making it an expectation of
distinguished eng is clever, because you can also expect them to practice and
apply discernment.

~~~
C4stor
Yeah, but that has nothing to do with being specifically a leader in external
community.

It has to do with having an interest in external community, but I would argue
that you're probably learning more if you're in fact not a leader !

------
agentultra
I'm not huge of Bryan Cantrill's often provocative tone and advice. The author
links to a talk by him where Bryan deliberately misdirects the audience so he
can introduce a false dichotomy about whether Software Engineering Middle
Management is a _toxin_ or a _cancer_. While fun if you're the kind of
engineer that sneers at management I would hardly consider it a guiding post
for becoming a leader.

Being a leader is hard. Being a good technical leader is harder. Programmers
are like cats and their opinions are more important and refined than anyone
else's. And I don't think it's sustainable to work in an environment where
your every mistake or bad day will make you seem like a dipshit to your team.
It can be demotivating to work under someone who has a toxic attitude problem,
for sure, but it's also hard to be perfect all the time.

One thing I would add to the _Humility and Empathy_ section is that you don't
have to be all these things all the time. It's okay to have a low-energy week
where you don't feel up to mentoring junior developers. It's normal to get
frustrated when you review code that consistently exhibits the same patterns
and bad habits you've been coaching your team out of for months. Part of
building humility and empathy is creating a team where it's fine to be
vulnerable: the team knows you're having an off week, that your energy is low,
and they trust you that you're going to recover and bounce back from it.

~~~
palimpsests
Why exactly are programmers' opinions more important and refined than anyone
elses?

~~~
brianyu8
Not OP either, but I think what OP means here is that programmers feel that
their own opinions are more important and refined than anyone else's, even
other programmers. This means that they are likely to judge someone who
operates in a way that differs from their opinion more harshly.

~~~
agentultra
A bit of that too.

------
BestischMensch
While the blog post is well-intentioned in its message, I can't imagine why it
resonates much with the author because their professional history seems to
indicate that they've never been at a job for more than a year. This isn't an
ad-hominem and I'm not trying to say you need to be a faithful old fart at a
company for decades to reach the rank of a technical fellow; but there's
something to be said for barely being around to learning the problem space let
alone having a deep impact. Seems to me a high ranking technical leader should
have the experience of influencing, aligning and leading large teams on
complex cross-vertical projects. Some of these things take months to design
with key stakeholders, launch and finally "land". And that doesn't include the
phase where you learn from said projects.

------
PorterDuff
I'm not sure what a 'Distinguished Engineer' is, but in the places I've worked
with 'Principal Engineers' (above the other 5 ranks or so) I've noticed that
their main job is to go to meetings, be on standards committees, go to
conferences, and give the folks who've been at the company a long time but
don't want to work on a product team something to do.

~~~
jedberg
I think that's because you don't understand what a PE is doing (or you work in
a very broken org). As an example:

Imagine you're the driver of a car. You're an expert at driving that kind of
car. Someone gets in the back and says, "Please go to 123 Main St.". Another
person gets in next to you to tell you how to get there, they are your
navigator.

You are the software engineer. You understand the mechanics of actually making
the car go. The person next to you is your manager, and the person in the back
is the PE.

So what has the PE and your manager done here? Well, what you didn't see is
that your manager went to a bunch of meetings before getting in the car to
find out that 1st avenue is blocked up and will help you avoid it by
navigating you around it. And the PE? The PE had 12 meetings before getting in
the car with both internal and external leaders to figure out where the car
will go.

Without the PE, you would just be driving wherever you want, and maybe you'd
get to a useful place and maybe you wouldn't, but with the PE there, you'll go
directly to a useful place. And if you ask them why 123 Main St is the most
useful place, they would probably be happy to tell you.

To you it may look like the PE is just sitting in the back, but that's because
you don't see all the work they did before they sat in the car, and you
haven't asked (or they're bad communicators and haven't told you).

~~~
Jach
I'm not sure I like this metaphor, but here's a version of how it can fail
(perhaps only in a dysfunctional org).

PE: _Sits down_ "We're driving to 123 Main St."

Manager: _Sits down_ "We want to be there within 9 months. We'll first try and
get to a similar street, 456 Blue St., within 3 months."

SE: "Uh, this is a Wendy's, not a car."

When people spend all their time in meetings and not enough time in the
product (or the product's technical architecture) they're going to lose track
of what has actually been built and what its capabilities are. Similarly even
with seemingly infinite meetings to address all sorts of interesting issues
from stakeholders, roadmap destinations can only be so accurate for each
distance in the future. I'm not even digging on the manager for having an
intermediary destination; experience tells there's a reason to go to 456 Blue
St. first (agile philosophies might help with even tighter midway reevaluation
points) because maybe once we're there, we'll learn something and decide we
wanted 125 Main St. instead of 123. No meeting can tell us that ahead of time.

------
fizwhiz
> A technical leader should be able to have strong opinions loosely held on
> designs and architecture. They do not need to have opinions on everything,
> that would be pedantic.

Pedantry has nothing to do with having opinions on everything, but has more to
do with an obsession on minutia :)</pedantry>

------
wellreally
Does this article mean an engineer at the same comp level as a director or
something else?

When pondering the expectations of an engineer at your organization, consider
the expectations of a manager at the same level and how many engineers vs
managers there are at that level in your company.

At large tech companies like Amazon (and possibly Microsoft), you'll find that
managers reach higher levels significantly faster and in higher numbers, maybe
because of unbalanced expectations of engineers at the same levels compared
with other roles.

~~~
Consultant32452
In my wing of a household name financial company, there are 7 directors and 1
engineer at that tier. And the 1 engineer is a lifer, so anyone would have to
leave if they want that position within the next 10-15 years.

~~~
wellreally
Thank you for sharing. We need more information like this to be made public
before engineers make more informed decisions about where to work and
companies feel some pressure to value engineers as much as they do managers.

------
ankimal
The call out about being "Customer focused" is key! Many engineers use the
Individual Contributor path as a means to just solve engineering problems and
an exit route from product teams. No matter if your customers are internal
(other engineers) or external (actual clients), understanding the business is
equally important.

An Engineer's goal is to solve problems. Technology is their tool to do so and
the more you understand the business' problems, the more effective you become
at using the right tools in the right ways.

A Distinguished/Principal Engineer's role is a multiplicative technical leader
whose use of these tools in an effective manner will impact solving customer
problems in a more effective and streamlined manner. Thus, building customer
empathy is very important.

------
msghacq
I wonder how this posts overlays with Jess' experience at GitHub. She only
worked there for a couple of months and I've heard from insiders that there
was a lot of tension. It would be great to hear her side of the story and see
if this post was partially a comment on GH's culture or her own growth after
the experience.

------
iheartpotatoes
I realize there is a need to stratify engineers based on performance in order
compensate accordingly each year during raise time, but having been in the
tech ranking system for ~30 years, it turns my stomach. About 40% of the time
the people promoted are really not that good, they just waited long enough or
knew the right people (or were in the right division that needed to boost its
clout so it promoted everyone arbitrarily). This whole "special name" business
is so very misleading. You want the title of famous engineer? open source your
work, let us see what you made. The masses will decide.

(And before you say "sour grapes", at my last job i rejected promotion to
principal because I like my work/life balance, but eventually dropped in
ranking because I refused to work 60+ hours a week in my 50's.)

------
Bahamut
All these things are important, but this misses the important distinction -
the higher up the leadership chain is about the scale you operate at, whether
you affect one team of developers, a couple of teams, a director level
organization, executive level organization, or the whole company.

~~~
jessfraz
Ah so influence :)

~~~
jessfraz
Hard to define, do you have ideas :)

~~~
leothekim
The most succinct thing I've come up with is: "You're an influential engineer
if an engineer magically becomes better just by sitting next to you."

------
swiftcoder
This is a solid template for personal growth as an engineer. Should be handed
to every engineer as they start to climb the senior engineering ranks.

------
uasm
So - soft skills, experience, great attitude and drive. Do we really need a
title for that?

~~~
jessfraz
it's sad it needs to be defined, I agree, but apparently it does :)

------
ericsoderstrom
"A technical leader should also make time for growing and mentoring others."

I like this. From reading The Idea Factory, I learned that at Bell Labs it was
compulsory for even the most established scientists (e.g. Shockley and
Shannon) to mentor newer recruits from time to time. Mentorship is one of the
highest leverage activities one can possibly do. Even if you're a high
muckety-muck, you're mission is still well-served by teaching others part of
the time.

------
howard941
To the enumeration add "Insulates engineering team from unwarranted managerial
meddling". The protective function is really critical.

~~~
Fede_V
That is a very important job, but that typically falls more on the shoulders
of an SDE manager, not a distinguished engineer.

~~~
rufius
In my experience, sometime's SDE Manager == Distinguished Engineer.

That said - the few DE's I've gotten to work that I most appreciated were
particularly invasive when dealing with management. That is, they would weigh
in and use their influence to ensure the team wasn't pulled in too many
directions. Sometimes this occurred even when they weren't explicitly asked.

Your most experienced engineers can be a good reminder for management that
they're asking too much whether it's breadth or depth.

~~~
mikeryan
SDE Manager == Distinguished Engineer

I always felt whole point of a Distinguished Engineer is to not have to deal
with the overhead of managing a team and instead focus on technical direction.
Recognizing however that requires a certain organizational scale to be able to
pull apart those roles

------
dcow
Most all of these are expected of principle if not senior engineers across the
board. I think the point of a distinguished engineer is more about
accomplishments and value generated for a company or industry and less about
exhibiting all these qualities. But I understand the frustration.

------
W-Stool
My definition of a "Distinguised Engineer" is Dave Cutler.

------
edoo
Or more concisely: Someone who has learned enough to positively engineer the
engineering process.

