index.md 11KB
title: Medium Engineering
url: https://medium.com/medium-eng/way-we-work-ef431646ab17
hash_url: 11ce91e417
Holacracy is a toolset for an organization and its employees. The roles in the organization are all defined, and each role has certain accountabilities and authority. This means that the people at the “top” do not have all the authority — it’s distributed even though it’s hierarchical. People can also hold multiple roles, and everyone has access to view the roles of any employee. To learn more about the system’s general principles, check out the Holacracy publication on Medium.
Holacracy embraces and expects change, so Jean talked a bit about how our own structure has shifted to support Medium’s growing engineering organization.
The team started off with a pretty basic structure with engineers working in small cross-functional teams — engineers, designers, PMs, etc — called product initiatives (represented in Holacracy as circles).
Constant evolution
As the team grew, there was a need for a more permanent, defined space for tracking engineering projects, more explicit support structures and room for engineers to discuss engineering-related concerns. To meet this need, the Engineering circle was proposed and created.
Within that circle, there exists the Proto Engineer role, which all newly hired engineers fill, the Engineer role, and Tech Lead role. Each role has explicit accountabilities to detail what is expected of anyone filling that role. Most engineers have roles in both the core Engineering circle as well as a product circle. However, it’s possible that one engineer might hold many roles, more similar to the current state of Tech Ops— a circle within Engineering that has four engineers filling about a million roles. For a small circle that is responsible for a lot of important parts of the engineering team, they end up with a somewhat comical amount of roles — and impressively execute each role well.
Around the time the engineering team was ~20 people, it became clear that the lead engineer, Dan, wasn’t able to meet one-on-one with everyone regularly (more than once every few months). With people shifting in and out of roles and having various Leads in their product circles, it became clear the team needed a scaleable way for every engineer to have a longstanding relationship with someone to talk to about personal growth, career trajectory, and gnarly situations in day-to-day work.
The team adopted the role of “Group Lead,” which we consider the “people side” of engineering management. This person is explicitly not your Tech Lead (who provide the “technical side” of engineering management) or Initiative Lead (our version of a PM), and is someone that an engineer meets with regularly one-on-one.
People vs. roles
The biggest difference to a traditional structure is that you don’t just occupy one role that takes you down a specific one-way path. People and roles are separate, so you can have a sort of a “choose-your-own-adventure” career.
For example, Jean is on the engineering team at Medium, but she holds a variety of roles including Group Lead for 11 engineers, Lead of the Node Services Guild, and Engineer on the Publications Initiative. She also help set up the onboarding and interviewing training for the engineering circle, as well as some recruiting and outreach. Having these roles assigned to Jean explicitly is great for her because these responsibilities are important but are often overlooked or seen as detracting from an engineer’s work.
Jean appreciates the explicit structure and doesn’t feel like she’s had to choose whether or not she wants to go down a 100% management track, which she thinks would have happened at a lot of other companies. She can pick and choose what she wants to focus on, and that can change even month to month. Sometimes she might want to focus on organizational leadership and a few months later, she’ll want to work on or lead an infrastructure project to challenge herself technically.
Holding different roles
Koop, an engineer that contributes to the Writing and Reacting initiative and currently holds the Web Client Guild Lead role, spoke about the different roles he’s held during his time at Medium.
Each person at Medium occupies a unique slice of the organization, which is reflected through their roles.
Like most of our application engineers, when Koop joined Medium in March of 2013, he was given two roles: one as an Engineer, and another as a contributor to a product initiative. As the engineering team grew, the team sensed the need to have caretakers responsible for the core areas of our codebase. To fill this need, the engineering team introduced the role of Domain Expert at the end of 2013. Koop was one of the several engineers that stepped into the role, with a focus on maintaining Medium’s web framework. Over time, he’s held many other different roles in the engineering circle, while also holding his Engineering role throughout his tenure.
Not everyone has to hold multiple roles. Some people have one or two roles and focus their efforts, while others are spread across more roles and accountabilities. At times, it can be difficult (or even impossible) to satisfy all of your accountabilities in a given moment.
Additionally, everyone in the company has the authority to prioritize their work across roles. These priorities might change, so it’s always important to communicate what you’re focusing on to your coworkers.
Changing roles to adjust with the company’s needs
Every person has the power to propose changes to how we work. For example, at the end of 2014, engineering found that the Domain Expert role had become somewhat inaccurate. In reality, as the organization grew, a single person did not oversee an area of the codebase. Instead, a group of engineers — Domain Experts and otherwise — collaborated to maintain and improve areas within Medium’s codebase. In a meeting, Koop proposed to evolve the role of Domain Expert into several “Guilds” to reflect how the engineering team was functioning.
We now have four guilds: Web Client, iOS, Node Services, and Data. Each guild is focused on improving their discipline, establishing best practices, and educating the rest of the team. Guilds prioritize their work by assessing the needs of the team. Some choose to focus on developer productivity, while others have focused on education and best practices.
Our current engineering structure is the result of cumulative changes proposed by Medium’s engineers. Most organizational structures are rigid, and aren’t designed to change and grow. This can often lead to massive, disruptive reorganizations. Instead, Holacracy gives us the tools to continually refine. We’ve tweaked and honed our organization to fit our needs, and will continue to do so as the company grows.
We haven’t solved all the problems
We don’t have it all figured out. Holacracy gives us a set of tools to use to change our organization. We’re going to face more challenges as we grow. What does a comprehensive leveling system look like? How can we facilitate frequent, useful peer feedback? Most companies face these problems (regardless of whether they actually attempt to address them). We want to learn from their success and failures. We don’t want to reinvent the wheel.
Importance of good engineering management
Jumping off on Koop’s point that we haven’t solved everything, we invited one of our engineering advisors, Cathy Edwards, to provide some insight from her experience working on and growing engineering teams.
Cathy pointed out that it’s very trendy in the Valley at the moment to promote how little management your company has, or how you have a flat structure with no managers. She actually believes good management is critical to a company’s success. Good management helps minimize politics, ensures employee happiness and growth, and provides the right environment to maximize the productivity of the entire team. However, most people promoted to management positions are never told exactly what their jobs are, or trained, so they end up not delivering on this promise.
One of the things Cathy appreciates about Holacracy is how it makes many of these management functions explicit, and makes it clear who is responsible for figuring them out. While certainly not perfect, organizations using Holacracy don’t have the single point of failure that hierarchical management structures have (as embodied by the famous Peter Principle). Allowing the whole team to contribute to, and hold each other accountable for, making good decisions about company structure and process helps ensure that they work for everyone, and the earlier part of this post has been a great example of how this has worked at Medium.