Hi folks,

This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.

Posts from this week:

- What do Staff engineers actually do?
- Weak and strong team concepts.

What do Staff engineers actually do?

The role of a Staff-plus engineer depends a lot on what the team needs and also what the particular engineer strengths are. From my experience the responsibilities of a Staff-plus engineer can change over time, but usually their main focus is working on projects/efforts that have strategic value for the company, while driving technical design and up-leveling their team. - Diana Pojar

Anyone who has been cornered by relatives at a party and asked to explain what software engineers actually do knows that explaining the work can be a challenge. Over time you may have created a compelling answer for your relatives, but many folks’ minds go blank when their coworker leans over and asks, “What’s a Staff engineer do?”

The easiest answer is that Staff engineers keep doing much of what made them successful as Senior engineers: building relationships, writing software, coordinating projects. However, that’s a misleading answer. They are doing those same tasks, but whereas previously they were the core of the work, they’ve become auxiliary work, and they have new priorities. Their daily schedule varies a bit by archetype, but there’s a shared foundation across all archtypes: setting and editing technical direction, providing sponsorship and mentorship, injecting engineering context into organizational decisions, exploration, and what Tanya Reilly calls being glue.

Setting technical direction

I feel most impactful when I can facilitate setting a technical vision for an area and get people moving toward that vision. I think we would all agree that we want our code to be better architected than it is or improved in some way. However, I’ve found that often people have some vague sense of wanting better without having a clear idea of what that thing they want is. I like to help the group decide on a shared understanding of where exactly they’re trying to get (it’s actually okay if we never get there) and come up with a general game plan of how to get there. - Joy Ebertz

Much as the Lorax speaks for the trees in his popular children’s book, Staff engineers speak for their companies’ technology. Technology cannot speak for itself, and requires effective advocates on its behalf. Folks who successfully advance technology are pragmatic, deliberate, and focus more on the long-term trend of progress than viewing each individual decisions as a make-or-break crisis. It can be helpful to think of this as being a part-time Product Manager for technology.

Some Staff-plus engineers are explicitly hired to lead a specific area such as API design, and in other cases they find themselves editing and aligning approaches across a broad area. One constant across all roles is that the reality of setting technical direction is far more about understanding and solving the real needs of the organization around you, and far less about prioritizing technology and approaches that you personally are excited to learn about. In earlier roles you may have tried to influence decisions towards technology choices you’re motivated by, but in senior roles you’re accountable to the business and organization first, and yourself second.

Mentorship and sponsorship

In my current role, I feel energized when someone I’ve sponsored sends an announcement that they’ve shipped their work, or when I see that I’ve helped shape or shift an engineering team’s model of an important topic. It’s these teams, not me, who are doing the hard work day-to-day of building and supporting their technology. I measure my impact based on their progress and more importantly, the directionality of that progress and the alignment of their work to the company’s goals. - Michelle Bu

There’s a popular vision of heroic leadership than centers on extraordinarily productive individuals whose decisions change their company’s future. Most of those narratives are intentionally designed by public relations teams to create a good story. You’re far more likely to change your company’s long-term trajectory by growing the engineers around you than through personal heroics. The best ways to grow those around you is creating an active practice of mentorship and sponsorship.

Many career ladders have an obligatory checkbox around mentorship to qualify for a promotion into a Staff role, and mentorship is a key part of the role. Sharing your experience and advice, along with an ongoing relationship to understand the recipient’s context, is high impact work. In senior roles, mentorship is just the bar for admissions, and the most effective Staff engineers pair a moderate amount of mentorship with considerably more sponsorship: putting your thumb directly on the scale to help advance and support those around you. If you haven’t read it already, Lara Hogan has written the canonical piece on the distinction between sponsorship and mentorship, What does sponsorship look like?

Providing engineering perspective

I have a seat at the table at higher level engineering discussions that occur at a level above individual projects and teams. We have recurring staff engineering meetings where we discuss problems that span teams which are both technical and non-technical in nature. - Dan Na

Effective organizations streamline routine decision making. A good example of this is the process for reviewing contracts for potential enterprise customers. Early on, there will be some contracts signed that the product and engineering teams is uncomfortable supporting. After that happens a few times, the process will include more stakeholders in the review steps, and overtime the right people will be in the right places at the right time.

There’s a second category of decisions, thoes which are both time-sensitive and important, and it’s more challenging to get the right folks into the room before those decisions get finalized. It’s frequent for an organizational restructure to occur without valuable input that would have changed the outcome. Similarly, it’s common for interview loops for infrequent roles–those where you might hire one person into them each year like executives or Staff-plus engineers in an early stage company–to not evaluate the candidate on an important dimension. For some companies even things like roadmap planning fall into this category.

Staff-plus engineers are the folks who will often get unexpectedly pulled into the room where this sort of decision is happening. This gives them the opportunity to inject engineering context and perspective into a decision while it’s still possible to change the outcome. These brief moments of input on critical decisions are unduly impactful, and will allow you to keep engineer’s perspective heard. They’re also a moment when it’s easy to forget that your role in these moments is often to represent the interests of all of engineering, not just your own.

Exploration

In my current role within the incubator I’m spending all day prototyping, but in my previous tech lead role I did a lot of different things. - Ritu Vincent

Hill-climbing can’t solve every problem, but it’s so effective that many companies struggle to take other approaches. This can be a consumer-oriented company struggling to support enterprise deals, or a mature company struggling to compete with a smaller competitor’s release cadence. It can even be the case that your current business is so valuable that it’s hard to prioritize new businesses, even though the valuable business’ growth rate is trailing downwards.

In the long-term, companies either learn to explore or they fade away; this isn’t an ignorable challenge. Simply assigning a team that’s mastered hill-climbing to do exploratory work is far from a sure thing, so many companies take a different approach. They find a couple trusted individuals with broad skills, allocate some resources, and check back in a few months later to see what they’ve discovered. One of those engineers is often a Staff engineer.

This isn’t always a business problem either, it can be any sort of ambiguous, important problem that the company’s systems are ill-shaped to address. It might be reducing your infrastructure costs by an order of magnitude. It might be identifying a multi-region strategy that takes six months instead of three years. It might be addressing the sudden realization that your primary database only has three months of remaining diskspace and you can’t upgrade to a larger size (in my experience, a surprisingly frequent problem at fast-growing startups).

This is some of the most rewarding, and the riskiest, work companies do, and it takes a great deal of organizational trust to be trusted with this work, including having the respect from the business that if you fail it’s a reflection on the problem and not you.

Being Glue

Tanya Reilly wrote a wonderful post, Being Glue, which captures another core element of successful Staff engineers: doing the needful to identify the right work and get it shipped. It’s not glamorous, but high impact organizations often have one or more Staff engineer working behind the scenes expediting the most important work and ensuring it gets finished.

But will you still write software?

It’s impolite to end any discussion of the Staff engineer role without opining on the first question that Staff engineers ask when they congregate in a room together: “Do you still find time to write software?” The answer is, of course, it depends!

Ras Kasa Williams said, “I still contributed code regularly—certainly less than the rest of the engineers on my team; but it was important that I sustained "hand to keyboard" work to ensure that my technical strategy (and other macro–level decision–making) was informed by the on–the–ground experiences of the rest of my team.”

Katie Sylor-Miller said, “I’m a frontend architect, but by far the main thing I've been writing lately is SQL, because I'm doing a lot of data analysis. I’ve been looking at our performance metrics to figure out where the areas for improvement are, and what would be the most impactful issues to fix to improve performance and business metrics. I will write little bits of JS or PHP here and there, but it's mostly to help unblock teams or to run small performance-related experiments.”

Silvia Botros said, “I don’t do coding for the business anymore. I think the last time I had to pull up my terminal it was to refactor my dot files. This is an intentional decision by my boss, the Chief Architect. He’ll check in with us every quarter to make sure we didn’t contribute any code that goes into production.”

Joy Ebertz said, “The more senior you get, the less your job is about code. Sure, unlike a people manager, you still have a very technical slant and even through principal, you’ll likely be doing at least some coding. However, the higher you get, the more your job becomes about mentoring and growing the people around you (and more broadly), building your team through building your company’s public tech brand, noticing larger technical trends that can be improved upon or corrected, helping to set the tech vision for your team or the company and advocating for resourcing for tech debt projects.”

Most write some, some write none, but none write as much as they used to earlier in their career. There will be the occasional week that is purely coding, but those won’t be the norm, and if they happen too often it’s usually a sign of working on something comfortable rather than important.

Slow but rewarding

One unifying theme across Staff-plus work is that the timeframes are simply longer. Early in your career it’s easy to get attached to software development’s quick feedback cycle–write, test, ship, repeat–and most of the work you’ll be doing at this level replaces that feedbdack loop with one that takes weeks, months and years.

The impact and the personal growth lives in those longer timeframes, and while everyone I spoke with wished they’d occasionally get more time to code, none of them regretted their transition into their current roles.

Weak and strong team concepts.

Engineers are often frustrated that their management “treats us like fungible resources when we’re unique humans.” On the other hand, engineers usually view individual ownership as a managerial failure, “critical systems need to be owned by teams not by individuals.” At a certain remove, these seem like contradicting beliefs—they’re not—and thinking about how both can be true brings us to an idea I’ve been reflecting on a lot recently: weak team concepts and strong team concepts.

“Weak” here isn’t meant to be disparaging, and neither is “strong” necessarily a synonym for good, rather it’s intended in the spirit of weak and strong forces in particle physics. I first mentioned this idea in Staff engineer archetypes, summarizing the concept as:

A strong team concept is one where ownership, work, and accountability are generally assigned to teams. Signs of a strong concept are sprints, story points, tracking tickets, SLAs, and goals. A weak team concept is one where most work is assigned to individuals, and work is driven primarily through interpersonal connections rather than process.

Very small companies have a weak team concept with each individual is fulfilling many roles. There simply aren’t enough people to rely on teams. The work still gets done though, with the folks involved organically fitting into the necessary roles. Most of the time there isn’t a written operating document describing who does what, but everyone knows how to get the work done. The weak team concept is fundamentally an organic process because individuals need to understand and negotiate with many other individuals. The organic approach is quick to respond to change, but struggles to effect broad changes that impact many individuals.

Large companies have a strong team concept with responsibilities spread across teams and organziations. Teams serve as an abstraction over their composing individuals’ various schedules, obligations, and priorities. Even if folks join, leave or transfer across teams, the teams’ responsibilities remain constant. Folks on a given team don’t have to understand what every other individual in the company does, only what the various teams do. The strong team concept is fundamentally hierarchical with certain individuals, typically managers, who negotiate on behalf of large groups. The hierarchical approach is often slow to make an initial response to a new challenge, but is able to effect massive, wide reaching change.

It’s interesting to ask what pushes larger companies towards strong team concepts, and ultimately I think it’s the relationship between rate-of-change and rate-of-hiring. When a company is hiring rapidly, managing change becomes the fundamental management challenge, and structures that adapt slowly to change are an impediment to success. Scaling organizations tend to value the ability to respond wholly more than they value responding rapidly, and consequently push themselves towards the strong team concept.

Once there, they tend to stay there indefinitely. While companies that adopt the strong team approach tend to get stuck there, it’s not necessarily because it’s the best solution to every problem. Every system is perfectly designed to perpetuate itself, and the strong team concept is particularly adept at self-preservation with its cadre of managerial roles created to support the approach.

There’s this popular conceit that startups are the underdogs fighting against bureaucracy, and you might imagine that they preserve the weak team concept longer than other styles of companies, but startups’ scaling constraints conspire to force them towards the hierarchical, top-down style of company that many startup aficionados villainize.

There are a few factors at play here:

1. The venture capital funding model requires rapid growth, which requires responding quickly to structural changes., which pushes towards hierarchy and the strong team concept.
2. Young companies are composed of young relationships. Teams that have gelled and worked together well for years are different not just in degree but in nature to teams that have worked together for several months. Non-gelled teams find it easier to rely on hierarchy than interpersonal relatinoships for rapid, effective response.
3. Almost everything managers are taught is focused on managing young, mostly non-gelled teams. Do you really need a weekly 1:1 with someone you’ve worked with for six years? No, probably you don’t. (You do, of course, still need to make them feel appreciated.) Do you need agile and weekly sprints working with a team that mastered working together? It depends on the team, but it’s certainly not the only way.

These forces promoting strong team concepts are powerful, and software development organizations rarely overcome them. The few organizations I’ve seen that continue to rely on weak team concepts past product-market fit are either:

• struggling badly with scaling,
• hobby businesses that aren’t really working but somehow have enough capital to avoid confronting that for the time being, or
• bootstrapped businesses who deliberately temper growth.

I don’t think adoption of the weak team concept has to be quite so limited though. Roughly, the downside of the weak team concept is they are less efficient processing structural change. Conversely, they are vibrant and self-healing as long as the change size remains small or interpersonal relationships remain strong. Ultimately, for more companies to rely on weak team concepts, we’ll need to move beyond an industry where it’s the norm for your forty year career happens at three or four companies rather than a dozen.

That's all for now! Hope to hear your thoughts on Twitter at @lethain!