Defining a Distinguished Engineer
blog.jessfraz.com
blog.jessfraz.com
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.
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.
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.
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.).
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.
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.
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.
Where is this mythical land? Are you hiring?
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.
By the way, your Twitter handle in your profile doesn't exist.
0. https://labs.spotify.com/2016/02/08/technical-career-path/
1. https://labs.spotify.com/2016/02/22/things-we-learned-creati...
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/
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.
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 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.
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.
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.
Can't find a better system for those who don't about titles.
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" =)
> 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.
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.
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.
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.
>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 ?
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.
Then they need two people, not one.
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.
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 !
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 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.
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.
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.
> 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.
I inferred that they do respect the programmers - more than anyone else even.
> 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!
The refining part I don't get.
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!
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).
Broke organization? Probably. They all seem to be in some way or the other.
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.
Pedantry has nothing to do with having opinions on everything, but has more to do with an obsession on minutia :)</pedantry>
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.
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.
(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.)
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.
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.
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