11 ms·

Defining a Distinguished Engineer

292 points by johns 8y ago

wellreally 8y ago
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 8y ago
  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 8y ago
    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.
DVassallo 8y ago
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.
- leothekim 8y ago
  > Job titles squash the peculiar strengths and differences into a label and make organizations treat people as fungible units of work. I'd think having clear job titles and differentiation would have the opposite effect of treating people as fungible units of work. I'm sorta with you on job titles, but my experience is that they enable organizational clarity, and people tend to like to show this reflected on their resumes/CVs. I'm curious to hear more about your thoughts on this.
  - DVassallo 8y ago
    The fact that organizations rely on job titles to measure/understand their capabilities is the problem. Sure, it’s simpler to think in labels/titles, but the strength is in the individuals. Look at team sports as a counter example where the thinking is in terms of the individuals, not labels.
    - ticmasta 8y ago
      What size company do you work at? how many distinct product lines? A sports team is 12-50 people, plus an immense supporting team, many with very specialized roles but all aligned towards a very well understood goal and pretty stratified options for success. A company could be hundreds or thousands of people with very diverse or even conflicting goals, spread over countless geographies and sub-teams. Should the technical lead know their team mates by individual traits? absolutely but the VP can't possibly maintain that cognitive load and needs titles & positions to guide there actions. Your counter example basically says every team owner knows everything the coach or sub-team coordinator knows, which is not true.
      - DVassallo 8y ago
        I worked at Amazon for 8 years; just left last month. Although the company has ~50K engineers, teams were made up of 8-10 people and orgs generally of around 200 people. The size of the company didn’t matter. Amazon could function just fine without job levels, and IMO it would function better. The VP doesn’t need to know the individuals. They can let the org leaders to deal with those details.
swiftcoder 8y ago
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.
howard941 8y ago
To the enumeration add "Insulates engineering team from unwarranted managerial meddling". The protective function is really critical.
- Fede_V 8y ago
  That is a very important job, but that typically falls more on the shoulders of an SDE manager, not a distinguished engineer.
  - rufius 8y ago
    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 8y ago
      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
Bahamut 8y ago
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 8y ago
  Ah so influence :)
  - jessfraz 8y ago
    Hard to define, do you have ideas :)
    - leothekim 8y ago
      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."
    - dougwbrunton 8y ago
      In my experience influence is earned using much of what you outline. Lovely blog post.
  - adamdennis 8y ago
    At Salesforce, one of the ways we measured influence was by the amount of internal social network activity an individual accumulated... posts, likes, replies, etc. In nearly all cases, the higher ups had the most influence.
    - gcb0 8y ago
      everything you make an input of the recognition process become an output of the office politics hack. obviously it corelates. at my company, were its not part of recognition, higher ups have zero posts on the information sharing systems.
uasm 8y ago
So - soft skills, experience, great attitude and drive. Do we really need a title for that?
- jessfraz 8y ago
  it's sad it needs to be defined, I agree, but apparently it does :)
- therealdrag0 8y ago
  To some people it comes naturally. Some people need more coaching. I think by having titles and skills like these associated with them it gives managers something to point to for engineers to understand what is expected of them and what areas they can improve on. shrug
PorterDuff 8y ago
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 8y ago
  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).
  - PorterDuff 8y ago
    I'd say that I know very well what they are doing, having to sit in the same meetings and all. Broke organization? Probably. They all seem to be in some way or the other.
  - munificent 8y ago
    I love this metaphor.
agentultra 8y ago
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.
- raehik 8y ago
  That's a really interesting final point that I've been trying for a long time to ingrain in myself. If someone is grouchy or irritable, it might not be that they're a bad person, it could be simply a bad time, day, week. The best bit for me about being in a software team for the first time has been learning to work with people. Consistently tough but rewarding.
- fbn79 8y ago
  About "Humility and Empathy"... why not to try Whiplash(2014) movie teaching method?
- msoad 8y ago
  This is a very good point! I'm trying become a better leader and reading this list was actually not motivating. I felt I had to be perfect all the time. I thought if I was this good I would start my own company instead of being a corporate cog.
ankimal 8y ago
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.
W-Stool 8y ago
My definition of a "Distinguised Engineer" is Dave Cutler.
fizwhiz 8y ago
> 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>
redsavagefiero 8y ago
This is the self effacing, perfectly humble, PC thought enabled droid who knows that creating an impervious wall of humility and picking their battles gives the impression of infallibility and leadership to the non-technical and management. I like the 'customer first' item. Where did that come from except the brown noser and CYA workbook? Reference to Cantrill is superfluous. We all know Cantrill is first paragon in the SV culture of perfectable technical humanity and that Linus Torvalds is the exact opposite of what 'we' should strive to be.
- deleted 8y ago
  [deleted]
- dang 8y ago
  Please don't do this here.
C4stor 8y ago
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 ?
- protonimitate 8y ago
  I think that point has more to do with having well-rounded leadership skills than being a workaholic. In fact, I would argue that demonstrating hard boundaries when it comes to over-working is an exponentially better skill to have than working non-stop. The best managers I've had have known when to be done for the day and disconnect from work - and lead their teams to do the same.
- deleted 8y ago
  [deleted]
- panzagl 8y ago
  Part of the distinguished engineer's role in the company should allow them the time to do such things- attend conferences and meetups, participate in research, meet with vendors, etc. If a company needs someone focused internally on product for 8-10 hours a day, then that company cannot afford a distinguished engineer.
  - zachr 8y ago
    > If a company needs someone focused internally on product for 8-10 hours a day Then they need two people, not one.
- jcoder 8y ago
  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.
BestischMensch 8y ago
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.
edoo 8y ago
Or more concisely: Someone who has learned enough to positively engineer the engineering process.
msghacq 8y ago
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.
- BestischMensch 8y ago
  I tried to state this in another comment (which now seems to have been flagged/dead) that the author seems to have bounced around jobs a lot. Short tenures don't usually lend well in grokking the problem space and making a deep impact regardless of your skill level. Certainly not at a "distinguished" level.
3pt14159 8y ago
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.
- lemoncucumber 8y ago
  I think it's more about committing to a direction/approach but being willing change directions in the face of new data or changing circumstances. If there's no one making decisions that's obviously a problem, but if there is someone making decisions and they're unwilling to reevaluate those decisions that's also a problem. It's not that as a leader you should have a strong opinion about something you know nothing about. Rather, you should gather data and fully commit to a decision that is supported by that data, while being willing to revisit the decision in the face of new data.
- sailfast 8y ago
  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.
iheartpotatoes 8y ago
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.)
dcow 8y ago
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.
deleted 8y ago
[deleted]
ericsoderstrom 8y ago
"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.

292 points by johns 8y ago

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

DVassallo 8y ago

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.

leothekim 8y ago
> Job titles squash the peculiar strengths and differences into a label and make organizations treat people as fungible units of work. I'd think having clear job titles and differentiation would have the opposite effect of treating people as fungible units of work. I'm sorta with you on job titles, but my experience is that they enable organizational clarity, and people tend to like to show this reflected on their resumes/CVs. I'm curious to hear more about your thoughts on this.
- DVassallo 8y ago
  The fact that organizations rely on job titles to measure/understand their capabilities is the problem. Sure, it’s simpler to think in labels/titles, but the strength is in the individuals. Look at team sports as a counter example where the thinking is in terms of the individuals, not labels.
  - ticmasta 8y ago
    What size company do you work at? how many distinct product lines? A sports team is 12-50 people, plus an immense supporting team, many with very specialized roles but all aligned towards a very well understood goal and pretty stratified options for success. A company could be hundreds or thousands of people with very diverse or even conflicting goals, spread over countless geographies and sub-teams. Should the technical lead know their team mates by individual traits? absolutely but the VP can't possibly maintain that cognitive load and needs titles & positions to guide there actions. Your counter example basically says every team owner knows everything the coach or sub-team coordinator knows, which is not true.
    - DVassallo 8y ago
      I worked at Amazon for 8 years; just left last month. Although the company has ~50K engineers, teams were made up of 8-10 people and orgs generally of around 200 people. The size of the company didn’t matter. Amazon could function just fine without job levels, and IMO it would function better. The VP doesn’t need to know the individuals. They can let the org leaders to deal with those details.

swiftcoder 8y ago

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.

howard941 8y ago

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

Fede_V 8y ago
That is a very important job, but that typically falls more on the shoulders of an SDE manager, not a distinguished engineer.
- rufius 8y ago
  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 8y ago
    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

Bahamut 8y ago

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 8y ago
Ah so influence :)
- jessfraz 8y ago
  Hard to define, do you have ideas :)
  - leothekim 8y ago
    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."
  - dougwbrunton 8y ago
    In my experience influence is earned using much of what you outline. Lovely blog post.
- adamdennis 8y ago
  At Salesforce, one of the ways we measured influence was by the amount of internal social network activity an individual accumulated... posts, likes, replies, etc. In nearly all cases, the higher ups had the most influence.
  - gcb0 8y ago
    everything you make an input of the recognition process become an output of the office politics hack. obviously it corelates. at my company, were its not part of recognition, higher ups have zero posts on the information sharing systems.

uasm 8y ago

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

jessfraz 8y ago
it's sad it needs to be defined, I agree, but apparently it does :)
therealdrag0 8y ago
To some people it comes naturally. Some people need more coaching. I think by having titles and skills like these associated with them it gives managers something to point to for engineers to understand what is expected of them and what areas they can improve on. shrug

PorterDuff 8y ago

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 8y ago
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).
- PorterDuff 8y ago
  I'd say that I know very well what they are doing, having to sit in the same meetings and all. Broke organization? Probably. They all seem to be in some way or the other.
- munificent 8y ago
  I love this metaphor.

agentultra 8y ago

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.

raehik 8y ago
That's a really interesting final point that I've been trying for a long time to ingrain in myself. If someone is grouchy or irritable, it might not be that they're a bad person, it could be simply a bad time, day, week. The best bit for me about being in a software team for the first time has been learning to work with people. Consistently tough but rewarding.
fbn79 8y ago
About "Humility and Empathy"... why not to try Whiplash(2014) movie teaching method?
msoad 8y ago
This is a very good point! I'm trying become a better leader and reading this list was actually not motivating. I felt I had to be perfect all the time. I thought if I was this good I would start my own company instead of being a corporate cog.

ankimal 8y ago

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.

W-Stool 8y ago

My definition of a "Distinguised Engineer" is Dave Cutler.

fizwhiz 8y ago

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

redsavagefiero 8y ago

This is the self effacing, perfectly humble, PC thought enabled droid who knows that creating an impervious wall of humility and picking their battles gives the impression of infallibility and leadership to the non-technical and management. I like the 'customer first' item. Where did that come from except the brown noser and CYA workbook? Reference to Cantrill is superfluous. We all know Cantrill is first paragon in the SV culture of perfectable technical humanity and that Linus Torvalds is the exact opposite of what 'we' should strive to be.

deleted 8y ago
[deleted]
dang 8y ago
Please don't do this here.

C4stor 8y ago

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 ?

protonimitate 8y ago
I think that point has more to do with having well-rounded leadership skills than being a workaholic. In fact, I would argue that demonstrating hard boundaries when it comes to over-working is an exponentially better skill to have than working non-stop. The best managers I've had have known when to be done for the day and disconnect from work - and lead their teams to do the same.
deleted 8y ago
[deleted]
panzagl 8y ago
Part of the distinguished engineer's role in the company should allow them the time to do such things- attend conferences and meetups, participate in research, meet with vendors, etc. If a company needs someone focused internally on product for 8-10 hours a day, then that company cannot afford a distinguished engineer.
- zachr 8y ago
  > If a company needs someone focused internally on product for 8-10 hours a day Then they need two people, not one.
jcoder 8y ago
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.

BestischMensch 8y ago

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.

edoo 8y ago

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

msghacq 8y ago

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.

BestischMensch 8y ago
I tried to state this in another comment (which now seems to have been flagged/dead) that the author seems to have bounced around jobs a lot. Short tenures don't usually lend well in grokking the problem space and making a deep impact regardless of your skill level. Certainly not at a "distinguished" level.

3pt14159 8y ago

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.

lemoncucumber 8y ago
I think it's more about committing to a direction/approach but being willing change directions in the face of new data or changing circumstances. If there's no one making decisions that's obviously a problem, but if there is someone making decisions and they're unwilling to reevaluate those decisions that's also a problem. It's not that as a leader you should have a strong opinion about something you know nothing about. Rather, you should gather data and fully commit to a decision that is supported by that data, while being willing to revisit the decision in the face of new data.
sailfast 8y ago
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.

iheartpotatoes 8y ago

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

dcow 8y ago

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.

deleted 8y ago

[deleted]

ericsoderstrom 8y ago

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