Staff Engineer and Other Things...

Staff Engineer and Other Things…

A few days ago, on my Twitter feed, I saw some people commenting on the book “Staff Engineer: Leadership beyond the management track” by Will Larson and discussing this type of position in Brazil.

I decided to write to talk a bit about my experience as a Staff Engineer in Data and Machine Learning to share some of the impressions I have regarding this title and some fundamental changes compared to other engineering positions I’ve had the opportunity to hold.

Right off the bat, I want to make it very clear that there is no canonical definition of what a Staff Engineer is and does; it depends heavily on the organizational maturity of the company and, especially, its size to comprehend this type of more technical career.

In other words, this type of position can have an extremely arbitrary definition, and copying what works in one culture without understanding the idiosyncrasies is something I’ve never seen work well—and in some cases, it’s problematic.

Another important point is that the phenomenon of companies creating a technical track parallel to the management track is relatively recent as far as I remember, and it meets a need to consolidate and establish paths for technical specialist careers. In my view, this comes at a great time, as it eliminates the pressure to push specialists into a management track (which is essentially problematic and naturally dysfunctional) and establishes new levels of expectation regarding impact and scope.

I think that with the high demand for technology specialists, the days of “walking the plank toward the sharks” promotions are over—not just because people today simply leave where they don’t feel comfortable, but also because I believe a management career in technology is overrated and has several serious, rarely discussed disadvantages, as well-exemplified in the always-necessary Charity Majors’ post “17 reasons not to be a manager”, where she brings some truths with her characteristic finesse.

Staff Engineer, So What?

First, I think that depending on the size of the company and its needs—such as a non-trivial technology stack, very complex product lines, or very large engineering teams—careers, especially in technology, evolve.

The two best definitions within what I’ve experienced, along with the literature, are in Will Larson’s book, where he talks about the staff engineer archetypes: Tech Lead, Architect, Solver, and Right Hand.

The description of each level is:

• The Tech Lead guides the approach and execution of a specific team. They partner closely with a single manager but sometimes partner with two or three managers within a specific area. Some companies also have a technical manager role, which is similar to the Tech Lead archetype but exists on the engineering manager ladder and includes people management responsibilities.

• The Architect is responsible for direction, quality, and approach within a critical area. They combine deep knowledge of technical constraints, user needs, and organization-level leadership.

• The Solver dives deep into arbitrarily complex problems and finds an appropriate path forward. Some focus on a specific area for long periods. Others jump from hotspot to hotspot as guided by organizational leadership.

• The Right Hand extends an executive’s attention, borrowing their scope and authority to operate particularly complex organizations. They provide additional leadership bandwidth for leaders of large organizations.

In my current day-to-day, I spend about 40% as a Tech Lead, 20% as an Architect, and 20% as a Solver.

Instead of getting into the distribution itself, I’ll talk about what changed in my workflow. Since my day-to-day is somewhat unorthodox in terms of workflow, I believe I can give a better sense of “what I do” rather than “why I do it.”

But What Changes as a Staff Engineer?

In general, several things have changed in my daily life, such as:

• Compensation: In my case, I was lucky enough to transition to a company that already understood this type of position, so the compensation ranges were well-established, and the negotiation was simpler (e.g., benefit packages, return expectations, stock options, vesting schedule, cliff, etc.).

• Participation in Creating Vision, Mission, and Strategy for a Team: This requires its own post, but in my case, I had to start this process from scratch. It was rewarding for me because, over time, the vision and mission proved to be perennial even after substantial changes in the market, people, stakeholders, etc. Regarding the strategy itself, it was more or less along the lines of what Will Larson described: something too boring that dealt with a large portion of foundational themes.

• My scope went from one team to multiplied by five, besides the number of stakeholders I had to start talking to directly.

• Projects shifted from a single team scope to cross-participation in other teams: I can say this is a small luxury of the position where almost no day is the same. One day I was understanding mobile event configuration in Segment; the next, dealing with warmup issues in EC2 instances and performing comparisons with Fargate in batch model training scenarios; the next, solving an issue in the Hue engine for job scheduling, etc.

• Leadership of critical projects (more than one) with company-wide scope.

• Absolutely a lot of foundational work: I think this depends on the company’s degree of maturity regarding the technology stack and the team that will make things happen. In my current journey, I encountered some shocking aspects of how the absence of foundational work, based on a coherent strategy, can throw a company 4 to 7 years back technically. Just maintaining parity with the same industry (not even talking about competitive advantage using data) is extremely difficult. Looking back, I think this was one of the aspects I most underestimated, and it was a revealing experience. Here I learned that engineering methods and principles will always be more important than technology. I can’t go into depth here, but at times, even when dealing with virtually unlimited cloud resources or technologies like MapReduce, Scala, containers, and so on, everything seemed done using 2009 practices (no exaggeration).

• Increase in individual decision-making power (agency) and expansion of knowledge instead of direct reports: I’ve felt all the good and bad feelings of management and having direct reports, so being in a position that didn’t demand that helped me greatly expand my technical knowledge in many things that weren’t my strength at the time, especially in infrastructure, containers, and backend. This gave me a strange power to decide things for myself, many of which people used to decide for me due to my lack of knowledge.

Main Challenges of the Role

• The number of meetings increased, which led me to be more brutal with my calendar: Meetings are a controversial topic on their own. In times of remote work and asynchronous communication, where many of us came from an analog-digital world to a post-pandemic fully digital one, meetings have become something that affects people’s mental health. To maintain my mental sanity, I put productivity blocks on my calendar with automatic rejection, and I set aside a specific day of the week for people to schedule anything (currently Thursdays).

• Soft lead with double the duties and using only pure and simple power of influence: Here’s a tip for anyone wanting to venture as a Staff in a Lead role or something similar—prepare to argue a lot and communicate with clarity to put forward your points of view. It might seem silly, but to learn this more effectively, I had to respectfully discard all technology management books and go back to the basics, which is a simplification of human psychology: the book “Influence: The Psychology of Persuasion” by Robert Cialdini.

  And I mean argumentation not in the sense of a conflict of ideas (those who know me know I love that, especially when one of my thoughts is wrong, as it refines my mental model and set of beliefs), but in the sense of explaining and exemplifying things that at first glance seem obvious but are not. If you add environmental, cultural, and work ethic differences, everything becomes absolutely much harder.

  Sometimes discussions are more surreal than Salvador Dalí’s paintings regarding how an example or point of view often has to be transposed in 3, 4, or 5 ways for internalisation by the other party. And I’m not saying this to pose as cognitively superior or anything like that, because I consider myself a mediocre generalist who will take a few years to be someone good; I’m saying that often the code, the experience, and reality are brutal, and often, with the complete exhaustion of arguments without a thought-out alternative from the other party, I’ve had to literally let some people fail. As simple as that.

  Obviously, this isn’t ideal, and there are mechanisms to avoid catastrophes that can be used, and obviously, there are learning costs involved. However, even for philosophical reasons, I don’t accept coercion or violence in disputes between ideas. Imposing ideas only serves to create power mechanisms over others, maintain the status quo, and leave a trail of resentment and dissatisfaction in people. It simply doesn’t work, and leadership via coercion is just a way of exercising unsolicited paternalism over others.

• Second-order thinking is probably something under-appreciated, but of fundamental importance for the work. If I had to select one trait of this type of role that marked me, it was starting to have the perception of what second-order thinking is and the chain of consequences for each decision. One of my biggest criticisms of the technology field is that companies/people mostly navigate between two extreme and opposite forms of mental sabotage: hyper-vigilance (catastrophism) or simplistic and superficial first-order thinking fueled by various levels of hype, with each extreme feeding the other. For me at least, the questions moved from the sphere of “Should we use technology X, Y, Z?” to something more like “OK, what are the tradeoffs we’re considering in switching to technology X, Y, Z; what are the costs, and when will we recover the time invested in terms of ergonomics or money?”.

• The strategy won’t always make everyone happy: All I can say is that there’s a difference between what needs to be done and what our ego wants to do. Aligning the latter with the former is one of the best avenues for increasing job satisfaction.

• You depend heavily on the coachability (trainability) of others [NA1] in cases where the role demands guiding professionals in development.

• Resist the trap of being a luxury consigliere: I have an article ready called “What is the biggest trap for a Staff Engineer?”, but the spirit of the post is that there is no technical role that isn’t building things while also having no direct reports. Period. Many people are dazzled by the salary, the false sense of importance from receiving invitations to meetings with key stakeholders, doing “coaching” with less experienced colleagues, architectural definitions, etc. All this, combined with a few other things, puts many people into a sense of comfort that initially gives a false sense of productivity, but in the end, it’s a great silent villain that causes skill erosion and degradation of technical knowledge. Do this over the years, and technical obsolescence in the market is certain. Simple as that.

Final Considerations

If I were to summarize my experience as a Staff Engineer so far, I think it would be somewhat similar to a senior technical career in foundational work (i.e., maintenance, support, and evolution of platforms), with a bit more coordination, influence across various projects, and occasionally helping some colleagues reach their potential [NA1]. Some colleagues have an experience much more focused on mentoring less experienced colleagues mixed with something more like an architect. The sphere of duties and scope of skills can vary from company to company and is something much more esoteric than scientific, given the recency of this type of position and the high degree of arbitrariness in requirements.

References

• Staff Archetypes

• The Seniority Rollercoaster

Notes

[NA1] - The word “coaching,” besides its many negative connotations today, has two problems in my semantic plan. The first is that it creates a false sense of precedence of the one training over the one being trained, and I think that’s wrong in knowledge professions, given that it’s absolutely impossible for anyone to know everything. The second problem is that, being a mediocre military athlete, I can say that at least in my years in technology and knowledge work, I can begin to affirm that the vast majority of people have a great capacity for learning but a very low level of trainability.

Elaborating further: often, the more trained an individual is, the less trainable they become. In my case as an amateur 100m/200m sprinter, I think it took me about two years just to change the way I did my block start, which was one of my biggest deficiencies. The coach insisted and talked and everything else, but the fact is that I had to unlearn many things before I was ready to learn.

I had to modify everything from how I trained my legs to how I tied my shoes and the body’s inclination toward the starting block, etc. I only internalized this for knowledge professions much later after reading this book, which talks about the first change to his swing that Tiger Woods made after winning two Masters and how difficult that was for him.

Putting into perspective how difficult a swing change is for a high-level golf athlete, it’s the same thing as if Roger Federer switched his one-handed backhand to two hands or if Messi swapped his left-foot curve shot for only flat strikes.

At that point, my evolution wasn’t because I thought the coach was bad or because I was rebellious or anything of the sort; simply the way I had been conditioned by a few years of training left me with some limitations that, if I didn’t respectfully unlearn some of those teachings, my evolution would never come.

“But OK, and what does this have to do with trainability in knowledge professions?” In knowledge professions, we have particular ways of working: languages, tools, work management modes, technology and thinking frameworks, methodologies, among others. All of this begins to become part of our operating system or mental models, and this is extremely difficult in practice-based professions in general. Just look at the numerous flamewars that exist for absolutely everything: IDEs, Scrum vs. Kanban, Java vs. something with more hype, people saying PHP is bad, folks crossing the barrier of evangelism regarding Clean Code and flirting with open preaching, etc.

I don’t have a degree in cognitive science to affirm this, but at least in my view, how much I am willing to unlearn to make room for new ways of doing something is what determines my level of trainability. Once I understand the why of things and start to have a certain minimum level of fluency to keep things moving, then I use all my background. At least that’s how I see this trainability.