Leading Ideas: Buffer’s new Engineering Career Paths Framework
VP of Engineering @ Buffer
During early startup days, everyone pitches into everything and just does what needs doing. The focus is on building a product: getting it out the door and delivering something great for our users. A small, flat team, a cluster of passionate engineers doing whatever it takes each day, works just fine.
More than fine – it’s brilliant. It’s what got Buffer to where we are today, passing $12M in ARR with a team of 81 Bufferoos spread across the world, serving over 4 million users who send more than 200k social media updates each week. We’re pretty happy with our engineering team!
This year, we’ve been realizing that we’ve outgrown that structure. Buffer’s now focussed on building a company, not a product. The engineering team has grown to 27, of which 24 are fully focused engineers (not managers). Like with most startups who start to grow up, the time has come where we need the transparency of a career framework. We need a structure to develop our engineers and start growing careers, not just codebases.
For Buffer to continue to be a place of growth and fulfillment at this bigger scale, we need a way for engineers to advance to bigger responsibilities and harder challenges as engineers. To deliver great software, we need to encourage engineers to grow horizontally: to grow their knowledge and thought leadership as engineers and do the job they are good at even better. Management should not be the only option for growth and advancement!
An engineer-centric framework
Our career path framework is engineer-centric and crafted for individual contributors. Engineering managers don’t fit into this framework. We don’t yet have a management career track. What we do know is we don’t want the only way to grow to be by becoming a manager. Our career path starts at “Software Engineer”, and carries on right up to an “Engineer of Distinction” (someone who has industry-wide impact, and who is very rare indeed). Where an engineer is currently at on this path is determined by two factors: the scope of influence they have, and the “ownership” level engineers commit and are held accountable to.
Scope of influence
The scope of influence concept that drives our structure is borrowed from Camille Fournier’s engineering ladder and we’ve found it a useful and accurate proxy for how far along their career journey an engineer is. A very skilled engineer will likely have influence over a whole project, or area, and having wider influence requires deeper skill. Someone earlier in their journey may influence only the tasks they work on directly.
We decided not to use a matrix of hard skills because you can never make a complete enough skill checklist to avoid unfair negotiations on this skill vs that skill. Comparing a front-end engineer and a systems engineer and an iOS engineer using a checklist of specific skills didn’t lead to transparent and fair outcomes (or outcomes we could make much sense of at all). It also might encourage engineers to grow in artificial directions following a random checklist rather than their true interests. Instead, scope of influence, together with a description of “how work is conducted”, proxies for technical skill.
Ownership
The second major component of our career path framework is the concept of ownership. Making ownership explicit like this wasn’t something we’ve seen done before, so this is one way where the framework is a little different and experimental. We feel it is important, because ownership is a core part of our engineering culture, and of Buffer culture.
Bringing it into the framework as a major component forces us to articulate what ownership is and the ownership expectations at each point in an engineer’s journey. The technical skills someone has should enable them to fulfill the ownership requirements for where they’re at, but technical skill tells only part of the story. The rest of that story is about owning increasingly heavy responsibilities – something not every skilled engineer is ready to do, or indeed wants to take on.
It’s not a ‘ladder’ – here’s why
Lastly, a note of the wording of our framework. We chose not to call it a “ladder” with “levels” or “rungs”. There’s nothing inherently wrong with a ladder-like system of advancement up various levels – it is really clear, for one thing. It’s just that talking about ladders with “higher” and “lower” rungs felt out of tune for our engineers.
Being a flat team was very in line with our “Be a no-ego doer” and “Focus on self-improvement” values, and having a career framework described in strong hierarchical terms seemed harder to reconcile with those values when some people are described as being“levels above” or “levels below” others.
Instead we choose to focus on the journey, the growth and evolution that is a career. We talk about paths and where you’re at now, and where you hope to grow towards. At any one time, you’re simply at one particular point on your path. And no one stop ever describes the whole journey.
Scope of Influence | How work is conducted | Ownership |
|
|---|---|---|---|
Software Engineer |
Themselves and their tasks.
· Makes a contribution through completing well-specced tasks.
· Receives closer guidance and technical mentoring to avoid becoming blocked/stuck
· Not yet learning at Buffer in a self-directed way
No ownership responsibility yet: this person is learning and being actively developed by others.
Average Expected Timeframe to Software Engineer II: 6–12 months
Software Engineer II
Their project and their peers.
· Works on project as a whole
· Makes steady progress on tasks within the project
· Works directly in parallel with peers.
· Self-directed learning process.
· Knows when to ask for help when they are becoming stuck; does not go down rabbit holes.
Co-owns an area with guidance & takes initiative (e.g fixes bugs unprompted)
Average Expected Timeframe to Senior: 1 - 3 years
Software Engineer III
Their project and their peers.
· Same as above (Software Engineer II)
Fully owns a service or component
Average Expected Timeframe to Senior: 1 - 3 years
Senior Engineer
Whole team/product area
· Translates ideas into projects with discrete tasks.
· Gives guidance & unblocks others on their team/area.
· Sought out by others as a technical resource.
· Seeks design/architecture or specialized input when needed (and knows when it’s needed).
· Makes good, informed decisions around technical debt and tradeoffs.
· Communicates with non-technical team members to give technical advice.
Has a consistent record of very strong ownership for their area, e.g. figuring out on-call schedules, establishing monitoring
Timeframe to next Step of Senior II or Staff Engineer: 2+ years, if you choose to increase influence further.
Every engineer should aim towards becoming a Senior Engineer in their own ways.
From Senior Engineer, Becoming an Expert Technical Leader Within One Team or Area:
Scope of Influence | How work is conducted | Ownership |
|
|---|---|---|---|
Senior Engineer II |
Whole team/product area
· Exhibits excellent judgment regarding decisions across many aspects of the project
· Acts as a resource to unblock and enable the whole team.
· Reduces the complexity of projects/services/processes in order to get more done with less work.
· Researches and leads adoption of new systems/technologies to stay current and strive for excellence on your team.
· Routinely and consistently pushes the team forward.
Senior Engineer II conducts work in the same way as a staff engineer, except across 1 team/project rather than multiple teams/projects, going deeper into their team/project rather than increasing breadth influence to staff engineer.
Timeframe to next Step of Staff Engineer: 2+ years, if you choose to increase influence further.
From Senior Engineer or Senior Engineer II, Becoming a Technical Leader Across Multiple teams/projects:
Scope of Influence | How work is conducted | Ownership |
|
|---|---|---|---|
Staff Engineer |
Multiple teams/projects
· Exhibits excellent judgment regarding decisions across many teams.
· Acts as a resource to unblock and enable teams across various projects.
· Reduces the complexity of projects/services/processes in order to get more done with less work.
· Leads architecting new systems/technologies/processes to stay current and move the bottom line.
· Routinely and consistently pushes pushes multiple teams forward.
Exhibits ownership across the org - this person is a guardian of BufferTimeframe to next Step of Principal Engineer: 3+ years, if you choose to increase influence further.
From Staff Engineer, Choosing to Become a Thought Leader:
Scope of Influence | How work is conducted | Ownership |
|
|---|---|---|---|
Principal Engineer |
Whole organization
· Sets the technical path and direction for the company.
· Understands business need and impact of choices.
· Makes multi-year decisions and informs the vision for technical culture.
· Anticipates challenges across the organization well before they occur and takes preventative action.
Ownership: Is a last point of failure; the buck stops here (in the case of some massive failure, the 5 Why’s process would likely come down to something went wrong at this level)
This person is rare. This takes an exceptional amount of dedication to the craft and is again a big jump from staff engineer.
Engineer of Distinction
Industry
· Is a thought leader in industry.
· Makes major breakthroughs.
· Driving projects on which multiple organizations depend.
· Unblocking multiple organizations of the future.
Same as above. Would guide principal engineer.
Very few organizations would have an Engineer of Distinction.
Over to you
We’d love to hear what your take on this, and of course feel free to copy and adapt this framework for your own organization.
Try Buffer for free
140,000+ small businesses like yours use Buffer to build their brand on social media every month
Get started nowRelated Articles
Nine years ago, we decided to launch a new free product alongside Buffer. We called it Pablo, and it was a huge hit in our community. Within just seven months of its launch, half a million photos were created using Pablo. Similarly, we had the initial ideas for Stories Creator and Remix many years ago now. All three of these tools have been an important part of Buffer’s story. They’ve taught us lessons and helped us connect with a wider audience. In Pablo’s case, the idea for this tool happene
If you use Buffer, you might have experienced us having more downtime than usual recently. We want to start with an apology for not sharing more transparently along the way what’s been happening. We’ve been caught up in the work and haven’t invested enough in communicating with our community, and we’re so sorry about this misstep. We know some of our customers have had a frustrating time using Buffer recently and we need to do better by you. This past August and September were the months we’ve
As part of our commitment to transparency and building in public, Buffer engineer Joe Birch shares how we’re doing this for our own GraphQL API via the use of GitHub Actions.
