How Medium is Engineering Holacracy [Q&A with Daniel Pupius]

The only thing as important as building product, in the engineering world, is building product culture. Structuring a team, figuring out the right development process, and scaling that processes is a science. A hard science. I’m always curious to learn how other engineering organizations operate for this reason. Especially when that organization is building the world’s favorite publishing platform: Medium. 

The company is pioneering a relatively new type of management system called Holacracy. Medium’s Head of Engineering, Daniel Pupius, wrote an interesting post about how they’ve designed a holacratic organization and how it's providing them with a new kind of manager. He wrote that a “common misconception about Holacracy is that it’s a flat organization structure” when in practice, their organization is built around a hierarchy of circles and roles. 

I had the opportunity to ask Dan the questions below about what this structure means for their engineers and how it shapes their product culture, team, and development process. 

How does Medium's engineering team prioritize what to build next, and how do they decide when it's good enough to ship? (Does the circle lead decide? Is it A/B tested?)

At various stages in the product’s evolution we’ve operated differently, but in all cases the teams are mission-driven. Sometimes the missions are tightly scoped (“improve the on-boarding experience”) while at other times they are more open ended (“connect people with the content that matters to them”). The teams are cross-functional circles, and as a circle they are responsible for deciding how to fulfill their mission most effectively. We don’t have specific criteria on when something is “good enough to ship." It’s a conversation between product, design, and eng on the given team, but we strongly favor iterative, visible progress over large launches.

We do A|B test a lot of changes, but we’re not beholden to the results. As an example, we ran a test for a change to the Recommend button that drastically increased the click-rate. It was a controversial change, but after lively debate we ultimately decided it didn’t feel right and concluded that the increased click-rate corresponded to a devaluing of the Recommend signal.

As products mature, there’s a shift from the exciting projects to a need to drive more of the “less interesting stuff." How do you ensure you have equally motivated and passionate developers working in those areas?

In terms of product there will be new and exciting things to work on for a long time to come; ideally forever. We should always be pushing the product forward, innovating in service of our mission.

Even so, as you grow you inevitably start dealing with scaling concerns, spam, technical debt, and things like improving the build system to handle more developers. While I think these are still interesting challenges, you need to make sure projects are tied back to company priorities. If you understand the importance and impact of your work, it’s much easier to stay motivated, even if it might be unglamorous.

We do want to avoid the same people tackling these types of issues over and over again. So we make sure that the team structure is dynamic and flexible, making it very easy for people to move around.

How does recruiting and hiring work with Holacracy? Is it the responsibility of the circles to grow their own teams or is that a function of some centralized group?

Ultimately it is the responsibility of the circle to fill roles and take care of the people within the circle. In Engineering we developed a system for professional development and mentorship, and we’ll continue to iterate and evolve as we grow.

We do have central functions though, the best way to think of it is a series of circles that act as service organizations: for example, Talent Acquisition does sourcing and recruiting, and People Ops develop tools and processes that circles can adopt.

One of Medium’s key tenants is “Make everything explicit — from vacation policies to decision makers in each area.” In contrast, HubSpot has one key policy: Use Good Judgement (which then translates into an Unlimited Vacation Policy.) How do you think about having explicit policies vs. giving individuals autonomy to figure out how to apply very broad rules?

The problem with implicit systems is that organizational lore builds-up, which is hard for new people to learn and becomes open to interpretation. This unwritten lore includes implicit authority that may then reside in the person who’s been there longest, the person who is loudest, or the person who is most opinionated. And over time you are susceptible to unintentional shifts in culture.

So I favor explicitness.

The explicit nature of Holacracy’s policies and roles aren’t in contrast to autonomy; in fact the whole system is designed to create distributed authority and autonomy.

Explicit roles have a number of benefits. Let’s take a recent role created for Email Delivery as an example. That role now makes it clear who on-call should talk to about a DKIM issue, who Legal should talk to about email policy, and who has the final call on selecting a mail provider (MessageBus is shutting down). The role makes it clear what is expected of you, so you can easily know whether you’re doing a good job. And the role empowers you to make decisions without approval or consensus.

This allows us to give degrees of authority to people early-on in their careers because organizational guard-rails exist. Having explicit roles also makes it easier to identify where your time is going and what to prioritize.

In terms of policies, they shouldn’t constrain, they should liberate. Explicit policies reduce anxiety because people don’t have to stress over what “good judgement” means; they let you know the rules of the road, so you can operate autonomously within a safe framework. A policy might say you can deploy code whenever you want during the week, but if it’s the weekend you should get approval from on-call first.

For what it’s worth, we also have an Unlimited Vacation Policy, the policy says to take what you need but to check-in with your Lead Links first, and encourages 2–4 weeks spread over the year — we often have to encourage people to take time off.

How do your engineering teams create safe space to innovate and try new things without having to explain themselves to the whole organization?

Experimentation and failure should be baked into the culture. If you never fail you’re not trying hard enough; you’re not being bold enough. We should celebrate failures as much as successes. No one will criticize you for a reasonable hypothesis failing, but you might get criticized for not trying.

Holacracy also helps. One of the core philosophies is that you are the arbiter of your own time. So as long as you are fulfilling the accountabilities of your various roles, there is nothing to constrain what else you do; no permission you need to seek (domains notwithstanding, which are like property rights, but that’s probably another interview.)

I want to thank Dan for talking to us about Medium's engineering culture and sharing an inside look at Holacracy. Be sure to follow Dan on Medium here.