Defining a Distinguished Engineer(blog.jessfraz.com)
blog.jessfraz.com
Defining a Distinguished Engineer
https://blog.jessfraz.com/post/defining-a-distinguished-enginner/
107 comments
Indeed, an ideal scenario for actually getting work done is when everyone knows each others abilities, and they collectively divide responsibilities (including leadership responsibilities) as peers.
Others have pointed out various reasons for titles, including:
- communicating one's level of responsibility to those outside the organization
- determining pay bands
- something to put on one's resume
Just for these reasons alone I would still insist on having an appropriate job title. It may not help me get work done, but it still impacts my career.
However, the reason why I like the idea of technical career ladders in general, is that (when done well) they should tell me how I can succeed in an organization beyond just hard work. I want to know that, if I demonstrate some ambition and initiative, that I am doing so in a way that the company will appreciate my work and I will benefit from it.
Others have pointed out various reasons for titles, including:
- communicating one's level of responsibility to those outside the organization
- determining pay bands
- something to put on one's resume
Just for these reasons alone I would still insist on having an appropriate job title. It may not help me get work done, but it still impacts my career.
However, the reason why I like the idea of technical career ladders in general, is that (when done well) they should tell me how I can succeed in an organization beyond just hard work. I want to know that, if I demonstrate some ambition and initiative, that I am doing so in a way that the company will appreciate my work and I will benefit from it.
Yes, employees do want job levels, so it's unlikely they'll go away. If I had employees, and they insisted on a job title, I'd give them one.
I personally don't see why the measure of success of an employee has to be dependent on career ladder ascension. Why do employees need a change in job title to learn if they're succeeding at a company? Can't they see the success themselves? Can't their boss just tell them?
I personally don't see why the measure of success of an employee has to be dependent on career ladder ascension. Why do employees need a change in job title to learn if they're succeeding at a company? Can't they see the success themselves? Can't their boss just tell them?
I think there are benefits to formalizing expectations (and what it means to exceed them) but yes, you can communicate that just by having a conversation. In fact the conversation is essential, a formal career ladder is just a tool.
I would say that the times in my career that I have had the most success were the times that titles didn't matter at all: what mattered was that I was doing hard, essential work as part of a highly-aligned team that was solving problems that impacted the business.
But eliminating job titles won't make those kind of situations happen, and having job titles doesn't prevent it. I've been in an organization that tried to just eliminate title differentiation, and it didn't work very well.
Let me change focus for a bit, and instead I'll address what I think would be necessary to successfully create a flat organization. The only way to make people comfortable with eliminating job title as a status marker is if they possess other status markers that are as strong (or stronger) than a title.
At a minimum, I think you would need to:
1) pay top-of-market salaries
2) fire anyone who isn't an exceptional performer
From what I've heard, Netflix is a pretty flat company, and they (claim to) do both of those things. Obviously there is more to it than just that, and I wouldn't recommend cargo-culting them, but I think they serve as a useful example.
I would say that the times in my career that I have had the most success were the times that titles didn't matter at all: what mattered was that I was doing hard, essential work as part of a highly-aligned team that was solving problems that impacted the business.
But eliminating job titles won't make those kind of situations happen, and having job titles doesn't prevent it. I've been in an organization that tried to just eliminate title differentiation, and it didn't work very well.
Let me change focus for a bit, and instead I'll address what I think would be necessary to successfully create a flat organization. The only way to make people comfortable with eliminating job title as a status marker is if they possess other status markers that are as strong (or stronger) than a title.
At a minimum, I think you would need to:
1) pay top-of-market salaries
2) fire anyone who isn't an exceptional performer
From what I've heard, Netflix is a pretty flat company, and they (claim to) do both of those things. Obviously there is more to it than just that, and I wouldn't recommend cargo-culting them, but I think they serve as a useful example.
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.
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.
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.
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.
Confirmation bias? Other companies may solve you use case better with context-specific titles, e.g. “directly responsible individual on X.”
Yeah, some projects have explicit technical leads, they are usually the best resource but are sometimes pretty busy.
What exactly do you mean by confirmation bias here? As in, the other people on the team are just as competent but I don't find out because I only ask the seniors? It's possible. I have had some relatively unhelpful interactions with junior engineers in the past.
What exactly do you mean by confirmation bias here? As in, the other people on the team are just as competent but I don't find out because I only ask the seniors? It's possible. I have had some relatively unhelpful interactions with junior engineers in the past.
Great point; this kind of codification is absolutely in service of HR-type requirements. It reminds me of the book Seeing Like a State; the entire premise is the way that various administrative forces elide or even erase complex on-the-ground details and nuance in order to make the subject more manageable in some way.
Not to say this is categorically bad or wrong, but it's useful to recognize its purpose. In my current role I have a position as a technical lead, with someone who formally outranks me on my team. In practice all it means is that I'm the one that management comes to for scheduling. :) We work together as equals on any given task. I don't think either of us would ever try to pull rank.
Not to say this is categorically bad or wrong, but it's useful to recognize its purpose. In my current role I have a position as a technical lead, with someone who formally outranks me on my team. In practice all it means is that I'm the one that management comes to for scheduling. :) We work together as equals on any given task. I don't think either of us would ever try to pull rank.
Really funny. I've been through this too. So much that I thought we'd worked together. I do not put much store on titles when I hire as a reason. You just have to reevaluate.
By the way, your Twitter handle in your profile doesn't exist.
By the way, your Twitter handle in your profile doesn't exist.
Netflix gives every engineer the same title: Senior Software Engineer. That worked out beautifully: everyone focuses on getting things done and doing the right things. One's total package depends on how important this person is to her team and to the company, and of course Netflix makes sure the person gets paid more than the market can offer. If the person disagrees with the market price, Netflix encourages the person to seek external opportunities.
Can't find a better system for those who don't about titles.
Can't find a better system for those who don't about titles.
Zappos tried getting rid of titles and hierarchy. I interviewed there, and it felt unworkable to me. Power structures exist whether you define them or not. To be fair, I only got to observe it for a day, quite some time ago. Would be curious if anyone knows how that's going for them.
Edit: Found a 2016 update. Sounds like it was controversial, with lots of people leaving, but also sounds like they are still doing it. http://money.com/money/4183246/holacracy-zappos/
Edit: Found a 2016 update. Sounds like it was controversial, with lots of people leaving, but also sounds like they are still doing it. http://money.com/money/4183246/holacracy-zappos/
> 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.
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.
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.
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.
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.
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.
How does one determine who is VP or org leader without either de facto job levels?
Those are different roles. I meant job levels when I said titles.
> Look at team sports as a counter example where the thinking is in terms of the individuals, not labels.
You still have your best players starting and a number on the bench. This is analogous to specific software teams (front-end, back-end, etc.).
You still have your best players starting and a number on the bench. This is analogous to specific software teams (front-end, back-end, etc.).
Job titles/level are really nice at my company because they have a help provide a language and social acceptable way to talk about the scope of tasks someone can accomplish AND a way to talk about the scope of a task or project.
Yes it’s simpler. But that’s exactly to problem. It squashes all the things that makes individuals individual.
Job titles don't in any way stop me from understanding the uniqueness of individuals on my team. There are many paths to leveling up, and understanding why people are in the positions they are directly requires that individual context.
That's good. But what value do job levels (not roles) give you and the company?
There's a gamut of reasons, and it benefits all of managers, ICs, and the company. I like to point to Spotify's prose on building their engineering career ladder as a good example of why ladders can be important.
0. https://labs.spotify.com/2016/02/08/technical-career-path/
1. https://labs.spotify.com/2016/02/22/things-we-learned-creati...
0. https://labs.spotify.com/2016/02/08/technical-career-path/
1. https://labs.spotify.com/2016/02/22/things-we-learned-creati...
I think it is some measure of the quality of an organization how easily they allow and even encourage employees of all titles to take on leadership. It becomes a business advantage when done well.
> They make people think in labels.
That's because people do think in labels. Mother, Father, brother, teacher, sister, uncle, boss, manager, CEO. More primitively, tribe member, tribe leader, enemy, scary cat thingy, dangerous crawling thingy. It's part of our evolution.
> then assign it to the individuals, rather than define the work based on the individuals.
I would imagine this is impractical trying to run or build a large org then because you need to be able to define the work you have to do first, then assign it, it doesn't work the other way around.
That's because people do think in labels. Mother, Father, brother, teacher, sister, uncle, boss, manager, CEO. More primitively, tribe member, tribe leader, enemy, scary cat thingy, dangerous crawling thingy. It's part of our evolution.
> then assign it to the individuals, rather than define the work based on the individuals.
I would imagine this is impractical trying to run or build a large org then because you need to be able to define the work you have to do first, then assign it, it doesn't work the other way around.
I worked 8 years at a large company. Saw many initiatives succeed and fail. The reason I attribute to most of the failures was the expectation that someone with an idea could just find 5 developers and do it exactly as they say.
That is bad leadership. You still need to craft roles and titles in a manner that allows ownership and autonomy.
At my large company that I have been with for 4 years, you are given a title. The title has a certain baseline level of expectations. If you want the next title, you start acting like it. Then you are given it. You are given freedom and autonomy on how to act like it. For example, an expectation of a senior is to mentor. You can mentor in hundreds of different ways: run a workshop, do one-on-ones, pair programming with a junior, have lunch with people, and so on. Seniors are expected to demonstrate technical prowess. The baseline is delivering results on your immediate team, but if you want the next level up, you can branch out and impact the wider organization: you can do this through refactoring a large portion of a legacy system, improving the performance of a current system, adding better test coverage to a project you are not on, contributing to open source, or having a talk accepted at a conference. Just one of many examples.
I think this way works the best from my experience with two other systems: the ones as you describe, and then the mythological flat org.
At my large company that I have been with for 4 years, you are given a title. The title has a certain baseline level of expectations. If you want the next title, you start acting like it. Then you are given it. You are given freedom and autonomy on how to act like it. For example, an expectation of a senior is to mentor. You can mentor in hundreds of different ways: run a workshop, do one-on-ones, pair programming with a junior, have lunch with people, and so on. Seniors are expected to demonstrate technical prowess. The baseline is delivering results on your immediate team, but if you want the next level up, you can branch out and impact the wider organization: you can do this through refactoring a large portion of a legacy system, improving the performance of a current system, adding better test coverage to a project you are not on, contributing to open source, or having a talk accepted at a conference. Just one of many examples.
I think this way works the best from my experience with two other systems: the ones as you describe, and then the mythological flat org.
Yes, it's bad leadership. IMO, good leadership is seeing what the individuals in your team are good and interested in, and adapt the work to that. Your 2nd paragraph describes the problem I'm highlighting. If for whatever reason someone is not interested in (or good at) mentoring, why expect them to mentor? Expectation from a leader cause people to feel forced to do them. People don't want to let their leaders down, but if they can't or don't like doing what they're expected to, they won't do a good job -- or the job at all. This obviously only applies to creative/knowledge work. I suppose it's less important in task-based/mechanical work.
Our company has two titles, one internal that's used in the HR systems for salary etc.
The other is the external title, that's mostly used to communicate what you are good at in a compact way. My title, for example is "General Specialist" =)
The other is the external title, that's mostly used to communicate what you are good at in a compact way. My title, for example is "General Specialist" =)
But if you always apportion work according to strengths, how can anybody ever fix their weaknesses? There have to be other criteria too, right?
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.
> 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.
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.
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.
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.
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.
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.
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.
It's a decision making framework that places the "Anything is fine. You choose" option at the bottom in terms of value.
By the way, weakly is not a synonym of loosely in this context. Weakly/strongly here is having no opinion vs having one. Loosely means "ability to be convinced is high".
Weak: I don't care where we eat tonight.
Strong, non loose: I'll only go if we'll eat at Tadich.
Strong, loose:
- I want to go eat at Tadich.
- That's mostly sea food and I have an allergy. How about Hakkasan?
- Sure, let's go eat at Hakkasan.
By the way, weakly is not a synonym of loosely in this context. Weakly/strongly here is having no opinion vs having one. Loosely means "ability to be convinced is high".
Weak: I don't care where we eat tonight.
Strong, non loose: I'll only go if we'll eat at Tadich.
Strong, loose:
- I want to go eat at Tadich.
- That's mostly sea food and I have an allergy. How about Hakkasan?
- Sure, let's go eat at Hakkasan.
[deleted]
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 ?
>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 ?
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.
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 !
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 !
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.
> If a company needs someone focused internally on product for 8-10 hours a day
Then they need two people, not one.
Then they need two people, not one.
You can be concerned if you like but you can't change it. Some people are 9-5 engineers but the best aren't. It's just a competitive advantage to care about something a lot.
Your framing sort of reveals it. It isn't "to show off" because no one is going to know that you went to your local LUG. They're only going to know that you told them about this thing called cgroups and how this other thing called Docker allows you to develop faster and it worked.
It's utterly exhausting to do these things if you aren't into them. I, for instance, couldn't go to my local Ruby group after the first couple because it was positively unexciting to me. But the other guys there were pursuing their avocation, not their vocation, and their knowledge and skills in that dimension are probably far beyond mine as a result of the Cross-pollination of ideas that inevitably happens when vokers converse.
Your framing sort of reveals it. It isn't "to show off" because no one is going to know that you went to your local LUG. They're only going to know that you told them about this thing called cgroups and how this other thing called Docker allows you to develop faster and it worked.
It's utterly exhausting to do these things if you aren't into them. I, for instance, couldn't go to my local Ruby group after the first couple because it was positively unexciting to me. But the other guys there were pursuing their avocation, not their vocation, and their knowledge and skills in that dimension are probably far beyond mine as a result of the Cross-pollination of ideas that inevitably happens when vokers converse.
I can only disagree.
I have coworkers going to meet-ups. And trust me, I know, since they can't stop speaking about it. And what do they talk about ? Internal meetup politics, how X said what to Y, etc...aka the usual human chatter. Also, they spend a fair share of their workday actually preparing and organizing those.
I seriously doubt they're the best engineers out there, they just have a hobby and like to talk to about it like everybody else.
Also, not going to meetups doesn't mean you have to do a 9-5, what I observe is that it's actually going to meetups which forces hours on you since you got to leave at a predefined hour to not be late there.
Maybe the meetup scene is very different where you are, but around there it's the same ~30 people going to every possible meetup subject to have a friendly chat, chug a few beers and listen to a talk rarely given by an expert but rather someone who spent a handful of hours hacking on something fun. I'm just not convinced it makes anyone better.
I have coworkers going to meet-ups. And trust me, I know, since they can't stop speaking about it. And what do they talk about ? Internal meetup politics, how X said what to Y, etc...aka the usual human chatter. Also, they spend a fair share of their workday actually preparing and organizing those.
I seriously doubt they're the best engineers out there, they just have a hobby and like to talk to about it like everybody else.
Also, not going to meetups doesn't mean you have to do a 9-5, what I observe is that it's actually going to meetups which forces hours on you since you got to leave at a predefined hour to not be late there.
Maybe the meetup scene is very different where you are, but around there it's the same ~30 people going to every possible meetup subject to have a friendly chat, chug a few beers and listen to a talk rarely given by an expert but rather someone who spent a handful of hours hacking on something fun. I'm just not convinced it makes anyone better.
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.
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.
If you don’t understand the external context in which you work, be it customers, competitors, new ideas, new priorities, and just focus on what happens in your organisation or team then you will fail.
You don't need to be a _leader_ in an external community to have external context.
[deleted]
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.
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.
There is an assumption here--one that Bryan Cantrill mentions in that toxin vs cancer talk--that management and leadership are the same.
In my experience, they have nothing to do with one another. This is especially true with technical leadership. Having people whose primary concern is organizational stability leading technical decisions is a recipe for resentment and dysfunction.
I would go even further and say if a person is concerned with making technical leadership decisions as opposed to people management decisions, they shouldn't be in "management". This includes being a CTO. Most CTOs are not as natural people managers as their VP Eng brethren, and CTOs are not best described as managers of other managers: they're entirely different roles.
In my experience, they have nothing to do with one another. This is especially true with technical leadership. Having people whose primary concern is organizational stability leading technical decisions is a recipe for resentment and dysfunction.
I would go even further and say if a person is concerned with making technical leadership decisions as opposed to people management decisions, they shouldn't be in "management". This includes being a CTO. Most CTOs are not as natural people managers as their VP Eng brethren, and CTOs are not best described as managers of other managers: they're entirely different roles.
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.
In your first paragraph you’re asking for more respect:
> Software Engineering Middle Management is a toxin or a cancer.
In your second it seems that you don’t respect those lower on the ladder:
> Programmers are like cats and their opinions are more important and refined than anyone else's.
As a leader it’s important to distill good ideas from bad and be able to bring those lower on the ladder along. Give them the respect they deserve and you’ll get it in return.
> Software Engineering Middle Management is a toxin or a cancer.
In your second it seems that you don’t respect those lower on the ladder:
> Programmers are like cats and their opinions are more important and refined than anyone else's.
As a leader it’s important to distill good ideas from bad and be able to bring those lower on the ladder along. Give them the respect they deserve and you’ll get it in return.
>> 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.
> In your second it seems that you don’t respect those lower on the ladder:
That's a good point. I didn't intend any disrespect. Speaking as a programmer I was making a self-deprecating generalization. Not everyone has had the same experience as I have and I can see how that has weakened my comment.
I think I could have made my writing stronger if I had avoided the generalization and went straight to the point instead.
Thanks for pointing that out.
> As a leader it’s important to distill good ideas from bad
In a way I believe you're right.
> be able to bring those lower on the ladder along
However I don't think it's our job to deem which ideas are good. If we believe the source of goodness stems from our own personal experience and opinions then we may favor a team that merely agrees with us.
A good leader, in my opinion, must embody some of the qualities in TFA to make those determinations: being focused on the customer, the business, and their team. They need to look to the current context of all of these things and find the good ideas. They often come from unexpected places.
> Give them the respect they deserve and you’ll get it in return.
I believe this is a universal truth: give people respect, ownership, and accountability. It's important!
> In your second it seems that you don’t respect those lower on the ladder:
That's a good point. I didn't intend any disrespect. Speaking as a programmer I was making a self-deprecating generalization. Not everyone has had the same experience as I have and I can see how that has weakened my comment.
I think I could have made my writing stronger if I had avoided the generalization and went straight to the point instead.
Thanks for pointing that out.
> As a leader it’s important to distill good ideas from bad
In a way I believe you're right.
> be able to bring those lower on the ladder along
However I don't think it's our job to deem which ideas are good. If we believe the source of goodness stems from our own personal experience and opinions then we may favor a team that merely agrees with us.
A good leader, in my opinion, must embody some of the qualities in TFA to make those determinations: being focused on the customer, the business, and their team. They need to look to the current context of all of these things and find the good ideas. They often come from unexpected places.
> Give them the respect they deserve and you’ll get it in return.
I believe this is a universal truth: give people respect, ownership, and accountability. It's important!
> their opinions are more important and refined than anyone else's
I inferred that they do respect the programmers - more than anyone else even.
I inferred that they do respect the programmers - more than anyone else even.
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.
Why exactly are programmers' opinions more important and refined than anyone elses?
Part of becoming a great engineer, in my limited experience, is developing a sense of taste for what problems are worth solving and which approaches to consider.
The software we build ends up baking in those opinions: into the frameworks and libraries, into our philosophies, into the algorithms themselves, and ultimately into our culture. We end up with Rails whose claim to fame is being based, unabashedly, on its strong opinions. We end up with the LKML being what it is. We end up with ML algorithms with our biases built in. That's why our opinions are rather important.
Our opinions signal our status to other groups. If you're an opinionated statically-typed functional programming aficionado it's quite likely you're not going to fit in with people who are serious adherents to object oriented programming. And you will find many people without any opinions or whose opinions lie somewhere in between.
We can't avoid having them and it's important to be able to work with other programmers and so being able to set those things aside to focus on the customers' needs, the business context, and the well-being of your team takes precedence!
The software we build ends up baking in those opinions: into the frameworks and libraries, into our philosophies, into the algorithms themselves, and ultimately into our culture. We end up with Rails whose claim to fame is being based, unabashedly, on its strong opinions. We end up with the LKML being what it is. We end up with ML algorithms with our biases built in. That's why our opinions are rather important.
Our opinions signal our status to other groups. If you're an opinionated statically-typed functional programming aficionado it's quite likely you're not going to fit in with people who are serious adherents to object oriented programming. And you will find many people without any opinions or whose opinions lie somewhere in between.
We can't avoid having them and it's important to be able to work with other programmers and so being able to set those things aside to focus on the customers' needs, the business context, and the well-being of your team takes precedence!
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.
A bit of that too.
Because they're building it, it's more important. If you want to build along vector X and they believe in Y, you'll only get the projection of Y on X in business value. So if you can convince the people making things to make something closer to X and you can articulate that value and excite people about it you'll get a bigger projection.
The refining part I don't get.
The refining part I don't get.
Not OP, but my stab: programmers are the ones actually building something. A technical leader can craft a vision for the technical future of a product, but the engineers need to buy into that vision and will, by necessity, quickly form refined opinions on the implementation details as they build things.
I've wondered this as well. Are there equivalents in other industries? Some human trait that shows up in some circumstance?
Thank you for this post - it's something I needed really badly to hear this week!
About "Humility and Empathy"... why not to try Whiplash(2014) movie teaching method?
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.
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.
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).
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).
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.
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.
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.
Broke organization? Probably. They all seem to be in some way or the other.
I love this metaphor.
> 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>
Pedantry has nothing to do with having opinions on everything, but has more to do with an obsession on minutia :)</pedantry>
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.
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.
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.
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.
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.
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.
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.
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.)
(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.)
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.
Ah so influence :)
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.
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.
Hard to define, do you have ideas :)
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."
In my experience influence is earned using much of what you outline. Lovely blog post.
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.
So - soft skills, experience, great attitude and drive. Do we really need a title for that?
it's sad it needs to be defined, I agree, but apparently it does :)
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
"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.
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.
To the enumeration add "Insulates engineering team from unwarranted managerial meddling". The protective function is really critical.
That is a very important job, but that typically falls more on the shoulders of an SDE manager, not a distinguished engineer.
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.
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.
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
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
[deleted]
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.
My definition of a "Distinguised Engineer" is Dave Cutler.
Or more concisely: Someone who has learned enough to positively engineer the engineering process.
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.