On Custodianship, Culture, and Empathy.
Software organizations change a lot — they morph, they scale out, but they almost always never sit still. Structures change.
There’s a point in every restructure conversation where the word “culture” is bandied about: that if we retain our perceived working culture (“…as long as we collaborate…!”), things will be fine. There’s a key problem here: in that the approach seeks not to create culture, as much as it relies on it being an organizational bandaid.
Culture is not merely an input into a process. The working culture of an organization is largely informed by how it chooses to own things as much as it’s the other way around. We are the things that we choose to do.
Define: “Custodianship”
When I talk about custodianship, I refer to the responsibility of outcomes to a specific problem set. It could be the responsibility for decisions on the shape of a product, or the responsibility towards creating patterns that can be used by everyone. It can be towards a service (Who picks up the phone if product X is down?) or a set of components (Who builds our reusable UI components?)
Regardless of the permutation, there’s a couple of constants:
— Knowledge. People need to have domain-specific expertise — whether it’s the lexical knowledge of service internals, or years and years of doing design. If you’re going to own it, you’re going to need to know about it.
— Accountability spread. The more people “own” a certain thing, the less effective actual accountability is.
— Cognitive load. Ownership of things imposes a tremendous cognitive cost; Your bandwidth to do things reduces as your responsibility for it increases.
So how do we organize?
My mental model for an atomic unit of development is based on my time in startups. A lot of the time, it will look like this:
All the skills required for software development belong to that atomic unit, and they all work within the same domain. Communication is cheap here: everyone is in the same team. We work with each other, we learn from each other.
And while everyone has specializations, cross pollination can occur — sometimes, we just need to have more people on a problem, and everyone gets to wear different hats. Hell, I’ve done my time doing sales badly.
But then, a set of circumstances require that development scale out. What happens next?
Independent teams within problem sets
A lot of companies adopt a form of vertical slicing— wherein teams of people are tasked with solving problems within a specific domain. It looks like this:
This is great, when you have multiple distinct projects that don’t have a lot to do with each other. Communication happens within domain boundaries. So you build team B, whittling away at the problem set…
…and then you realize that you need a common capability. Team A has built one, and you don’t want to duplicate services. What happens next?
Arbitrary assignment
You can just keep Team A owning the service, while Team B consumes from it. Done. Dusted. We can all go home —
— wait, not really. You’re going to hear a couple of things.
“We’re responsible for things we didn’t build.” What ends up happening in this scenario is that Team A is imposed additional custodianship load (onboarding, service uptime) on top of their current work; whilst shouldering the cognitive load of the fact that Team B’s outcomes are dependent on said service.
“Who decides on priority?” There are also times when Team A is working on a project while Team B requires changes to the authentication service. There’s additional cognitive load here: which work is more important, and who makes that decision?
“They always just prioritize their own things.” Without a set prioritization model, Team A will organically put their requirements at the top of the list. There’s a resentment that can grow from having your needs play second fiddle; after all, isn’t Team B’s work just as important?
Service-based teams
…or, you can build a team that specifically looks after shared things. This can take many shapes: maybe you have an infrastructure team, or maybe it’s a design components group. They’re a group of people who produce consumable shared things. It looks like this:
And this is fine, for a while. But there’s a couple of things to watch out for:
“We’re more/less important than everyone!” Organizational accounting being how it is, a demarcation has to be set between profit centers and cost centers. There is a social cost to making this demarcation: we’re essentially saying: Team A/B makes us money, while Team C does not.
One of the common palliatives to this is producing a narrative strong enough to counter that statement — E.G., “We don’t make money, but we keep everything alive/Without us, there is no business.”
“We know better than everyone.” Communication drops across organizational lines, and priorities sometimes don’t get relayed correctly. Add the fact that people working within a specific knowledge tend to specialize over time, and we start hearing things like “The other teams don’t know what they want. We’re the experts here” — and we end up with teams building stuff that no one asked for.
“I know better than everyone.” Making sure that everyone remain grounded and mindful is important here: a person in the position of having to explain the value of that shared thing to people who don’t have to work on it will need an internal narrative to justify that repeated effort.
Function-based teams
Hmmm. So what if the teams still owned the capability, but we built a team that was responsible for the outcomes? For example: the teams still own their quality assurance, but there was a group of people — experts — that made sure things were good, or executed on the work?
“They’re just throwing stuff over the wall!” Each function generates an artifact, which is then handed over to the next group. But empathy does not cross boundaries well — and you frequently find that the artifacts are created by people who don’t have full understanding of what people downstream need.
“They don’t understand how hard my work is.” You’ll see this often with separated execution teams (E.G., Ops or QA); where the cost of effort of the function is obscured by organizational boundaries. Without the functions belonging to the same team, people will have a harder time understanding the gravity and important of that function — and assign less value to the task.
“We don’t have to listen.” In some permutations of this model, the group that owns the outcomes provides guidance (e.g., Coaching teams) — individual teams still own the execution, but a central team makes sure that things are executed well. And ( I’m repeating myself here I know ) empathy drops across organizational boundaries: and critically, you need to be empathized with in order to be listened to.
So what now?
The heavy cost of understanding. I’m not sure if there’s really an ideal model as much as there are compromises that we should be aware of, and should be ready to accept and mitigate.
At the end of the day, most if not all of the above problems can be chalked up to a failure to relay empathy: what everyone does, how important it is, and what each individual needs in order to be able to do their job well.
Mechanisms that support cross-sharing. This means that mechanisms to make sure that we understand and empathize each other exist as a deliberate choice, not just as an afterthought. Practically, what this means is that exercises and avenues need to exist for people across organizational boundary lines:
These need to be organizationally supported. But just as with capabilities or outcomes, these mechanisms need custodianship — and with custodianship, comes great effort. It requires work and time. You’re going to need people who care about these things, but you also need to recognize or make explicit that this is part of their job.
Closing
As stated before, culture is not merely an input into a process. It’s the result of how we choose to work: and thus, it requires effort and planning. It requires deliberate choices about the organization that we want to create.
Most importantly for me, it requires acknowledgement of the fact that we are creating environments that people will be exposed to for eight or more hours a day. These choices will change lives.
And so: what kind of people come out of the systems we’ve created?
