Defining a Distinguished Engineer

You can exhibit leadership and all those things at a much lower job tile.<p>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 <i>based</i> on the individuals.

Overall great, but I&#x27;ve always disliked this:<p>&gt; Have strong opinions loosely held<p>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&#x27;t split the baby. Pick one or the other and carry on.<p>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?<p>I&#x27;m just honest with people. We went with Postgres because we had to choose one or the other, but both would have worked.<p>The things I have strong opinions on are the very things that are <i>not</i> weakly held. &quot;One shouldn&#x27;t use Ruby for feature extraction on video at scale.&quot; It would take a <i>lot</i> to convince me otherwise, hence the strong opinion.<p>I find some people have trouble thinking in non-discrete ways. For example, I know this smart guy but he&#x27;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&#x27;d rather do a thumbs up or thumbs down. I discovered this only after complaining that the five star system was <i>not continuous enough</i> for me. I wanted to give something 4.8 stars because it was great, but had some slight flaws.

I&#x27;m really curious about this item<p>&gt;Community Good technical leaders are also leaders in the outside communities.<p>Well, why would they be ? I mean, they can be, but I fail to see it as a requirement.<p>I&#x27;m a bit concerned that nowadays the dev culture is that you should be working ten hours a day, and also go to meetups&#x2F;brown bags lunchs&#x2F;user groups&#x2F;whatever another 3 hours to show off how passionate you are.<p>Any opinions aroud that ?

I&#x27;m not huge of Bryan Cantrill&#x27;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 <i>toxin</i> or a <i>cancer</i>. While fun if you&#x27;re the kind of engineer that sneers at management I would hardly consider it a guiding post for becoming a leader.<p>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&#x27;s. And I don&#x27;t think it&#x27;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&#x27;s also hard to be perfect all the time.<p>One thing I would add to the <i>Humility and Empathy</i> section is that you don&#x27;t have to be all these things all the time. It&#x27;s okay to have a low-energy week where you don&#x27;t feel up to mentoring junior developers. It&#x27;s normal to get frustrated when you review code that consistently exhibits the same patterns and bad habits you&#x27;ve been coaching your team out of for months. Part of building humility and empathy is creating a team where it&#x27;s fine to be vulnerable: the team knows you&#x27;re having an off week, that your energy is low, and they trust you that you&#x27;re going to recover and bounce back from it.

While the blog post is well-intentioned in its message, I can&#x27;t imagine why it resonates much with the author because their professional history seems to indicate that they&#x27;ve never been at a job for more than a year. This isn&#x27;t an ad-hominem and I&#x27;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&#x27;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 &quot;land&quot;. And that doesn&#x27;t include the phase where you learn from said projects.

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

&gt; 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.<p>Pedantry has nothing to do with having opinions on everything, but has more to do with an obsession on minutia :)&lt;&#x2F;pedantry&gt;

Does this article mean an engineer at the same comp level as a director or something else?<p>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.<p>At large tech companies like Amazon (and possibly Microsoft), you&#x27;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.

The call out about being &quot;Customer focused&quot; 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.<p>An Engineer&#x27;s goal is to solve problems. Technology is their tool to do so and the more you understand the business&#x27; problems, the more effective you become at using the right tools in the right ways.<p>A Distinguished&#x2F;Principal Engineer&#x27;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&#x27; experience at GitHub. She only worked there for a couple of months and I&#x27;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&#x27;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 &quot;special name&quot; 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.<p>(And before you say &quot;sour grapes&quot;, at my last job i rejected promotion to principal because I like my work&#x2F;life balance, but eventually dropped in ranking because I refused to work 60+ hours a week in my 50&#x27;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.

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?

&quot;A technical leader should also make time for growing and mentoring others.&quot;<p>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&#x27;re a high muckety-muck, you&#x27;re mission is still well-served by teaching others part of the time.

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

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 &quot;Distinguised Engineer&quot; is Dave Cutler.

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