It has been over two years since FreeAgent introduced staff engineers into the IC track. The intention was to align ourselves with the wider industry by renaming the previous Senior II level to Staff. At the time, no changes were made to the expectations for the role. Since then, we have overhauled the expectation framework (for our learnings on how to do this, see Dave’s post here), and the folks at LeadDev have created a conference called Staff+, defined on their website as “A technical leadership conference for senior individual contributors.”

The LeadDev conferences originally focused on engineering management, and have been popular at FreeAgent. On Monday (25th June 2023), Colin and I traveled down the East Coast Mainline to attend Staff+ London. We heard from 27 speakers across 2 days and many, many coffees (or in Colin’s case, tea’s). We were looking for what it means to be a Staff+ Engineer and asked ourselves if FreeAgent’s definition fits the industry mould?

Immediate Reaction

Firstly, a key take away was that the Staff+ role differs a lot across the industry, and sometimes even within the same company. However, a common expectation of the role was that the engineers at this level should have broad impact. A slightly surprising element of this was that most speakers acknowledged that their time writing code had decreased (since being promoted to a Staff+ role). So, if they didn’t write as much code, how did they achieve this impact? It tended to fall into following areas:

• Diversity & Inclusivity
• Mentoring & Coaching
• Documentation, documentation, documentation (a lot of talks were about documentation)
• Opportunities for others
• Architecture & Tech Debt
• Documentation (seriously, there were a lot)

Diversity & Inclusivity

Let’s start with the easy stuff… There were a number of talks directly aimed at improving diversity and inclusivity, in fact LeadDev as a whole, champions both. They put a lot of effort into being diverse and inclusive, and as a result, the conference is friendly, relaxed, and everyone just seemed really nice.

This actually underpinned the sentiment of the talks specifically about diversity and inclusivity. Firstly, diversity is the starting point, not the end goal. Inclusivity embraces differences, allowing people to be themselves and bring their different experiences, viewpoints, and opinions to the table. The speakers (Liem Pham and J. Bobby Dorlus) pointed out that if you have an environment that isn’t inclusive it can lead to heightened imposter syndrome and other mental health issues.

Mentoring & Coaching

There were no talks specifically about mentoring or coaching. Why am I mentioning it then? I would estimate that at least 60% of the talks included mentoring and coaching as something Staff+ engineers were expected to do. This was amplified by the conference having organised speed coaching sessions for attendees, which were exciting to watch. A group of attendees crowded around the coaches and presented them with problems they were facing in their roles. The coach would ask questions and try to get to the crux of the problem. I was left with a similar level of anxiety and panic that rises when a live performance requires crowd participation and I’ve ended up in the front row.

The benefits of mentoring/coaching included knowledge sharing and personal development. However, although it has a large impact on a limited number of people (at least initially). A common way to increase the scope of their impact was documentation.

Documentation

Tech specs, ADR (Architectural Decision Record), wikis, best practices, incident processes, etc. You name it, you should document it. The idea is that Staff+ engineers should look to scale your impact by creating something that is always available to others, at least if it is well-maintained, searchable, and curated. One of the most important aspects of this is to capture the why of the decisions.

Opportunities for others

Broadly speaking, if you’re a principal engineer, you’re running out of ladder to climb. Nice for some! The idea here is that we should be creating space for others to lead. Have you already written 10 RFDs? Let someone else write the next one and support them while they do it. Delegate “promotable” tasks to others and sponsor them. Pick up “unpromotable tasks” – the small things that are hard to be recognised for ( probably Gem updates) come expectation scoring time.

Architecture & Tech Debt

A recurring theme was for principal engineers to champion technical debt and re-architect solutions to provide long-term agility and maintainability. They needed to be able to effectively communicate to directors why this was important for the company and accept that it might not always be the best time to embark on these projects.

A fantastic example was provided by Alice Barlet of the Financial Times, who embarked on a project to reduce duplication across their system. The duplication and lack of single responsibility elements in the service resulted in numerous small, time-consuming bugs. Instead of continuing to fix the bugs in many places, refactoring the technical debt allowed them to make the system more maintainable for the long term.

A key takeaway (for me) was how Alice communicated the tech debt work with the directors. Initially, she asked for a team of four engineers for six months to complete the work. However, the directors said this was not possible**. Instead of embarking on the project understaffed, she decided it wasn’t worth doing at all. This was echoed in other talks, where the current economic climate demands that people do more with less. But this is often detrimental, and doing fewer, more focused, and higher quality projects has a larger impact than more half-finished, lower quality projects.

Another common approach to tackle large architecture problems was to create a group of Staff+ Engineers who would help make architectural decisions and review documents and plans created by others. The key here was to avoid an ivory tower scenario and allow others to make their own decisions. The community might be advisory, rotate members (which I really liked the idea of), and involve engineers from across the whole organisation.

**Due to Alices take it or leave it approach the directors ended up agreeing that the project was worth doing properly and changed their mind.

Closing Remarks

So what does it mean to be a Staff+ Engineer, and how does FreeAgent’s definition compare? Like everything, it depends. I think there’s a strong argument that FreeAgents engineering expectations are well-aligned with the industry, especially at the principal level. Inclusivity, broad (department/company) impact, documentation, communication, and architecture are all called out specifically.

The conference was really enjoyable, and I would certainly recommend it to anyone interested in technical leadership that isn’t focused on Engineering Management. It is running again in London next year (or perhaps we can convince finance the New York one would be more beneficial ).