A good friend of mine who’s been in engineering leadership at a handful of early-stage companies recently had something interesting to say about core values:
I’m never putting ‘Accountability’ as a core value again. I’ve tried it three different ways at three very different companies and it always ends up the same. ‘Accountability’ just ends up being something everybody wishes everybody else would take more of. It’s a stick to beat people with, instead of a core value to practice.
That echoes something I noticed as Indeed grew rapidly through the 2010s. As the company grew larger and more complex, it became harder and harder to improve shared capabilities that fall outside any given team’s scope. Over the last couple of years, I’ve occasionally heard some variation of one of the following:
- Whose responsibility is (thing X)?
- We should make (aspect Y) somebody’s responsibility.
- Why doesn’t leadership make (task Z) somebody’s job?
The thing is: responsibility can’t be given, it can only be taken.
I’ve had the pleasure of working with hundreds of colleagues over the last decade. Every one of them is a highly qualified professional who would thrive with many different teams inside Indeed and many different organizations outside. If one of their managers insisted on assigning them tasks that were neither interesting nor transparently impactful, it wouldn’t be very long until that individual quite rightly started asking after what other positions might be available.
Indeed’s engineering leadership has emphasized the coaching model of leadership over command-and-control management ever since you could count the engineering managers on one hand. In this model, a coach’s job isn’t to assign tasks or obligations. Coaches work with people to identify opportunities, help them choose between opportunities, and then help them realize those opportunities.
One of my favorite examples of seeing opportunity versus obligation play out in practice is ownership of the retrospective after a production outage. Indeed has long championed the habit of blameless retrospectives: focusing attention on understanding contributing factors and preventing recurrence, rather than fault-finding.
Nevertheless, I’ve heard a hundred times in the heat of the moment: “that team broke things, they should own it.” From my point of view, this is a little wide of the point. Driving a retrospective is an opportunity, not an obligation. You grab the baton on a retrospective when you happen to be well-positioned to prevent its recurrence independently of whether or not you were anywhere near the triggering condition.
As for individuals, so for teams
We do ask teams to take on specific responsibilities… but we explicitly list out probably fewer than you imagine. When a team has a service running in production, they take on responsibility for making sure that service stays healthy, responsive, and compliant with company policies. We don’t mandate that teams respond to feature requests within a certain timeframe, that they support specific features, or that they use specific technologies.
Instead, we ask them to look for opportunities. Where will supporting new users help other teams onboard to the solution they’re building? Which features will help them accomplish their mission? Where can they find discontinuous advantage by adopting a different underlying technology?
As the engineering lead for a group of platform teams, I get a lot of chances to think about obligation versus opportunity. For example, we provide a modular browser-based UI platform. The bulk of code written against that platform is not written by the team itself. It is written by product teams creating product-specific modules. The platform team members clearly aren’t obligated to monitor the browser-side errors emitted by those modules, and it would be wholly unscalable to try and make them responsible. But at least for now, they can and they do. The opportunity to help product teams that are less familiar with deploying and maintaining modules is just too good to pass up. It won’t scale forever but, while it does, it significantly eases adoption by new teams and helps the platform team see where their users run into trouble.
Our communications platform team helps product teams message job seekers and employers over various channels. Through the years, the team has worked through just about every flavor of this when partnering with core infrastructure teams:
- Years ago, when postfix performance was a dramatic bottleneck, the core infrastructure team took the feedback, fixed the performance problem, and has maintained it ever since. Responsibility taken.
- When various issues affected the durability guarantees our message queues could offer, the core infrastructure team didn’t have a clear path to be able to provide the hard guarantees we needed. We worked around the problem by detecting and re-sending messages after any end-to-end delivery failure. Responsibility declined.
- When we needed to move away from a proprietary key-value store that had been deprecated, an infrastructure team working with OpenStack was very interested in building out a Ceph-based solution. We worked closely with them to prototype the solution, but it became clear that timeline pressure would not allow the solution to provide sufficient performance guarantees soon enough. We fell back on using S3, with the option to cost-optimize in Ceph later. Responsibility desired, but not feasible.
These examples spotlight some really important themes. Responsibility cannot be assigned based on the logic of team names alone. It can only be taken based on a team’s desire and ability to fulfill it. A team named “Storage Systems” is not obligated to support OracleDB simply because they’re the Storage Systems team. If their roadmap takes them in a different direction that meets the needs of their clients and stakeholders, it’s their decision.
Similarly, desire alone is not sufficient. When a much smaller Indeed first experimented with Cassandra, the experiment didn’t fail because of an inherent flaw in the technology. It withered because we didn’t have the in-house expertise and capacity to successfully operate a large-scale cluster through all the vagaries that occur in production. We wanted it to work and teams were happy to try and figure it out… it just ended up not being feasible.
Getting your opportunities noticed
So what does that mean for Thing X, Aspect Y, Task Z, and all of the other wish-list items that people come across in the course of a normal workday? If managers can’t just make those somebody’s job, then how on earth do we make progress on the opportunities that no one’s yet taken?
Two basic prerequisites make the opportunity-driven model effective: one mechanical, one cultural. Unsurprisingly, the mechanical aspect is easier.
The coach’s responsibilities that I listed earlier are identifying opportunities, selecting opportunities, and realizing opportunities.
Product-driven delivery organizations like Indeed already spend a lot of effort continuously improving their ability to deliver software to production. I won’t spend a lot of time on realizing opportunities here.
Identifying opportunities is also a core skill for product delivery teams. Where we needed to invest significant effort was in identifying them effectively. Primarily, that means making sure that good ideas end up on the radar of the people who are able to act on them.
An audience-friendly intake process is a crucial component for teams serving internal customers. Audience friendliness involves several critical aspects.
- It must be lightweight: incomplete ideas can be fleshed out later; lost ideas are gone for good.
- It must be responsive, since nothing demotivates a colleague so much as finding their suggestions lost in a black hole.
- Finally, it must operate at a high enough level in the organization. Individual delivery teams typically have narrow, carefully defined scopes that let them focus. That’s smart for delivery efficiency, but people outside the team can’t reasonably be expected to understand fine-grained subdivisions.
An effective intake process requires something of requesters as well. Making sure the rationale and assumptions behind a request are crystal clear—even when they seem obvious to you—makes it far easier for future engineers to notice and get psyched about the opportunity you’re presenting. Understanding and communicating a value proposition is good practice for any up-and-coming engineer and greatly increases the odds of somebody selecting your opportunity.
A culture of ownership
Of course, relying on others to pick up and run with opportunities requires a lot of trust in your colleagues. You trust that your priorities are generally aligned, so that your rationale will be compelling. You also trust that most everyone is generally hungry for good opportunities and will look for ways to make them happen.
Another way of framing that is that an opportunity-driven model can only work in a high ownership culture. At Indeed, we don’t tend to frame things in terms of obligations and accountability, because we’ve worked hard to develop a culture in which individuals and teams hold themselves accountable. Once a team or an individual has chosen to adopt a responsibility, they will see it through.
My long-time colleague, Patrick Schneider, illustrates the idea of high-ownership nicely. He looked at the daily question of “How should I spend my time?” through the lens of a RACI breakdown for an individual displaying various degrees of ownership. RACI stands for responsible, accountable, consulted, and informed.
How should I spend my time?
Patrick Schneider | May 16, 2019
| Level of Ownership | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| High |
Me I decide how to spend my time. |
Me I am able to describe what actions I have taken, which tasks I have completed, and provide justification for each. |
OKRs, my product manager, my team, other teams, … I consult whoever is necessary until I’m confident that I’m spending my time well. |
My team, my product manager, Jira, Slack, etc. I regularly and proactively let people know what I am spending my time on. |
| Medium-High | Me
I choose from curated options how to spend my time. |
Me
I am able to describe what actions I have taken and which tasks I have completed. |
Me
I have choices or recommendations from my manager, product manager, or others after they have consulted whoever they believe is appropriate. |
My team, my product manager, Jira, Slack, etc.
People usually know what I am working on. |
| Medium-Low |
My manager My product manager |
My manager, my product manager, or automation My manager, product manager, and/or automated systems describe the things I have completed and actions I have taken. |
Me
I am provided choices or recommendations by my manager or product manager, after they have consulted whoever they believe is appropriate. |
My manager or product manager
I inform my manager and product manager about what I am working on; they may inform whoever else they believe is appropriate. Jira is usually up-to-date. |
| Low |
My manager My product manager Non-humans, e.g., the next email in my Inbox |
Unknown or opaque Many things are in-progress or being worked on; work is described in the continuous tense, often with “-ing” verbs. The state of completion is rarely reached or described. |
Unknown or opaque My manager or product manager consults whoever they believe is appropriate. Randomness or algorithms. |
Unknown or opaque My manager or product manager informs whoever they believe is appropriate. Others may or may not find out about my work. |
Putting it all together
Accountability is a critical attribute of high-performance teams, but it isn’t well-served by simply being named a core value. Instead, you need to instill a culture of high individual ownership, establish processes that spotlight opportunities, and empower your teams to chase the opportunities most meaningful to their mission.