How To Engineer Software Culture
When people ask you, why your software engineering team will be successful, you will say 'our culture'. They will nod, you will nod. Nobody knows why they are nodding.
The problem with culture is that nobody knows what it is. We are all supposed to say we have agency and are individuals, or else you are a superstitious nonsense person. But if we are the grand deciders, why don't we say we will decide to be successful? If we cannot even control what we put in our mouthes, how can we control our success?
If culture decides who will win and who will lose, like some deity whose will we can't resist, perhaps we should address the elephant in the room. To understand culture, let's start from scratch and develop some assumptions:
- Our behaviors evolve on our shared neural network and to compete for resources similarly to viruses
- These social viruses can be selectively conserved or destroyed
- Strategies for selection and tactics for conservation or destruction affect a culture similarly to your immune system
Pictures and Sounds vs Neural Loads
Given that your neural resources are limited, and behaviors compete to recruit those resources, we should create an abstract structure to describe how we communicate better than 'pictures and sounds'.
When someone speaks up in a group, do you take their communications as simply words, or do those words live within the context of your relationship? The significance of the context is that the relationship takes up neural resources that it somehow won from other relationships, and that relationship then justifies the processing power we allocate to evaluating the words the person said.
Your relationship with that person lives within the relationship with the group, which takes up even more neural time. If Stacy suggested a solution for a problem, but Chau made a better suggestion, we can say that the Stacy was outcompeted by Chau for neural time. If the two suggestions can be described as behaviors, we can say that one behavior outcompeted another similarly animals competing for food.
Joining a software engineering team means having to make room for the neural resources required to be on the team, and so work can be described as a neural load. Within the context of that load, other smaller neural loads conspire to grow the resources they all take up, presumably with monetary incentive.
The team, as a load on the shared neural network across the members' total neural time, becomes a platform for the evolution of the team's behaviors. It's important to think in terms of neural loads that compete for limited resources because that forces a structure of incentives and disincentives.
Decisions VS Measurements
Do you remember how you learned to hold a pencil? The easiest way is to hold it like a stick, but someone corrected you, or you observe a fellow student and copied them. At some point, most of the kids in a classroom will hold a pencil similarly. Did they 'decide' to hold the pencil that way, or does that way of holding the pencil have a monopoly?
When you observe a behavior and copy it, are you deciding to copy it, or is that behavior copying itself into you? When someone shows you how to execute a behavior, are they showing you, or did that behavior summon one of its hosts to help copy itself?
If you are going through a loop of various ways to hold a pencil, the deciding factor is comfort. Did you decide or measure the comfort level? If you observed 3/4 of a classroom using a specific technique, and you also use it, were you just measuring the popularity level? Since you did not decide on the type of pencils, the task you must complete, or the shape of your hand, aren't you just measuring things that are out of your control?
Instead of considering yourself a decision maker with agency, it's better to consider yourself a platform for behaviors. Though you have little choice in being one, you do have the ability to measure incentives and therefore optimize for best fit.
The Genesis Of A Behavior
You are standing in line at the cash register, and the girl working it is not doing her best. She seems distracted and dismissive. After taking longer than she should, she finishes with you and asks:
"Would you like a bag?"
"Yes."
She does not ring up the bag, leaving you with the awkward choice of carrying the groceries in your hands, or asking her to go back and ring up the bag. What thoughts are going through your head?
"Just do your job."
"What is wrong with you?"
"A monkey can do this job."
-- or --
"She must be overwhelmed."
"I hope whatever is distracting her is resolved."
"Hi, I think you forgot a bag."
Which one will make the incident stick in your mind the most? The question is one of neural loads: which interaction takes up the most space? The former group of responses should stick in your mind because they create a conflict.
The nature of a conflict is that you must come up with some optimal way of damaging the other party, and then simulate their possible responses and your response to that. Mind you, this is before you said anything, so just modeling how the other person would react means housing an entirely different persona.
Conflict has an exponential neural cost. This means that, in terms of strength of signals, it stands out and is easier to commit to memory. Not only will such an incident stick in your craw, but you may actually say the stuff you're thinking, in which case that memory will become an agent that animates your vessel.
The key insight here is your reaction to the risk of potential conflict: if there is risk, you must mitigate it, so the longer the conflict persists, the longer you try to anticipate the other party's behavior, the longer the memory will be kept alive, or conserved.
Forgiveness, on the other hand, is a way of reducing the neural load of an incident. If one passes their interactions through a forgiveness layer, not only will they have less conflict, be in a better mood, but more of their neural power is available for productive accomplishments.
Signaling proof of risk creates and conserves itself, while the forgiving route is a destructive immune response. If proof of risk helps to conserve behaviors, then it be should be projected outside the team or the company in to the context of competition to signal proof of usefulness to your clients.
Everything is a Signal
Whether it's a pull request, a code review, or a slack message, everything is a signal that can be conserved and destroy other signals, and that is a problem. Thinking of a team from the perspective of a graph, destructive signals will be sent to some nodes more than others, and those people need to know how to handle them.
To define a destructive signal, let's take find a word that describes the difference between the two groups of possible responses in the cashier example. The first example implies that starting a conflict is equitable, meaning the two parties have an adversarial relationship. The second group shows work toward maintaining a relationship of interdependence, which incentivizes cooperative behavior.
We want to minimize, or destroy, adversarial signals and maximize, or conserve, cooperative signals, with the end goal to signal proof of usefulness. Let's go over some examples.
The bad manager
Scenario: A manager picks a least favorite junior engineer and puts him through an unnecessary hazing ritual, humiliating him, giving him tasks he's meant to fail at.
The signal: What is the manager signaling? If he is doing it to a junior, it means 'if you say something back you are fired', this can be described as proof of relative social status.
Problem: The junior is asked to bear a heavy load of adversarial signals, which will take away from his ability to perform his job. If he cannot manage to forgive the manager, not only will his work suffer, but the bigger problem is that the manager's behavior will get copied, either by that junior, or by others. This will replicate uncooperative behavior across the company culture, outcompeting and destroying useful work.
Solution: Ask if the manager is creating these behaviors, or if they are being transferred through the manager from the skip. If this is the case, address it with both: you are expected to be forgiving of the skip and not transfer this behavior to the junior. Do the same with the skip if necessary. If the manager is the source of the behavior, they should be fired and the reason should be communicated to the rest of the company. Firing the manager is in itself a very strong signal.
The very smart mid
Scenario: A mid level engineer commits javascript code that is supposed to be loops and conditionals, but searching for 'if' and 'for' finds nothing and instead he used reducers.
The signal: Things like chess, which signal proof of smart but not useful, are common in our culture and often express themselves by leading us in a direction away from usefulness.
Problem: The code is hard to read, and if allowed into the repo, people may start to copy the behavior, multiplying the amount of unreadable code and doing useless work.
Solution: In the code review, bring up signaling proof of usefulness vs proof of smart, and ask if this code expresses work that is smart, but not necessarily useful. This suggests that, it's not that the dev wasn't smart, it's that smart is the wrong direction. Avoiding useless conflict, yet rallying people around serving customers is a productive direction.
The careless senior
Scenario: A senior engineer committed code that touches all of prod, and when his manager told him to take it back out, he simply clicked 'revert' on the CI dashboard and pushed to prod without testing, breaking prod for half an hour.
The signal: The message this sends throughout the company is that, others need a validation step in their loop, but I can walk the tight rope without a net. This is a self perpetuating, useless, proof of risk signal.
Problem: This signal will destroy the importance of solution validation, decreasing code quality and increasing the potential for down time in the future.
Solution: Just like this senior will have learned his lesson about diligence, so will others observing him. In this case, likely forgiveness is in order. Let the signal reverberate through the company and express itself as increased testing requirements, automated validation techniques, and general awareness of production outages. However, firing someone for this sends he signal that our lack of reliability were one person's fault, and we solve this by getting rid of the scapegoat. The signal that increases testing standards creates should nullify the original signal.
The principled principal
Scenario: A principal engineer creates a developer tool that increases the workload of the developers instead of helping them.
Problem: Because of his status, the other engineers are forced to use his solution. When asked to defend it, he tells people how intelligent it is. This steers the direction of company culture toward solving for local political leverage instead of a meta goal of serving clients. This will result in people getting stuck in political local maxima and not processing client needs into engineering solutions.
The signal: Using authority to enforce a solution that doesn't work is a way to validate political leverage. Introducing this behavior into a culture will steer people in the direction of solving political problems instead of engineering problems. It also uses proof of smart to increase strength of signal, which means we now sound smart for a living instead of solving client problems.
Solution: A public poll of the other developers will reveal whether the solution is working, as well as flatten the hierarchy. If the principal refuses to abide by the poll, this is a good clue as to his intention. Reducing tension by bringing up proof of usefulness instead of smart will help to reduce the strength of signal. That authority leads to useless behavior is a good reason to solve for a flat hierarchy.
Proof of Usefulness
Since we are mentioning proof of usefulness so much, let's define what useful means:
- We all need leverage to get what we want, so whatever we do must result in leverage.
- There are two types of leverage: coercion and usefulness.
- Coercion means directly threatening someone with a worse consequence than giving you what you want.
- Usefulness means indirect coercion: some conflict with a third party is motivating a second party to look for a solution, of which you are a provider
- Any useful relationship can be defined as the first party (you), the second party (your client or customer), and the third party (forcing function)
The thing to avoid then is coercion. If find yourself in the position to say "If you don't do this, you are fired", the problem is not lack of ability. The other party lacks a proper forcing function. One major selection criteria in your hiring then should be people digging for usefulness so you can sell them shovels.
Why we signal
Nowadays, when we’re hungry we can reach into the fridge for a snack because agriculture figured out how to grow more food in the same amount of space. But at some point, we were chimpanzee-like things fighting over figs in the jungle.
If you can’t grow more food per square mile of jungle, and new chimps are constantly being born, somebody’s gotta die. Either members of nearby tribes, or members of your own. So… who do we kill?
Or let’s start with, who can we kill? We cannot kill chimps who look like the scariest chimps in our tribe, because similarity means they are related, and so will defend one another. We have to go for the uncool chimps. We can also go for uncool chimps of other tribes, however since they are more related to each other than they are to us, their scary chimps might defend them.
Problem: who is cool, who is uncool? In the chimpanzee world, the group labelled ‘related to the scary ones’ are called cool, however our world is more complicated. Rich people can defend themselves better, so the guy with the gold watch shouldn’t be messed with. What about desirable women? What about smart people?
Our society is not as bad as a chimpanzee tribe, but it's not that different either. We generally have what we need, but competition between engineers for promotions is largely zero sum. That means, If group membership in the club of the smarts can help you, it makes sense that those who signal proof of smart have leverage over those who don’t. Especially in the world of software engineers, a ‘smart’ profession, many coworkers have and will fall for this trap.
It may be a good idea to explain these concepts to expose them to the company immune system. The immune system should know it's an immune system, and whatever company culture you have should benefit from self awareness. For ideas to be held to account, they must be seen first.
The Heart of the Matter
At the end of the day, a company culture is an ecosystem of behaviors, and every node in the network can play a role in conserving or destroying the right ones. Everyone can play a part in the company immune system, whether junior, senior, or CEO.
A junior developer who is good enough at destroying signals like imposter syndrome, condescension, or feeling overwhelmed, will perform better than a junior who can't. Everything else being equal, his success is a function of a strong mental immune system based on forgiveness.
A middle manager who conserves useful signals and destroys coercive signals has an exponential positive effect on his team. Not only will he magnify what leverage he gets from the skip, but his reports will learn how to manage from him.
A CEO who creates useful signals and ensures their propagation throughout the network can be described as a queen bee of a usefulness colony. He hires people to recruit their neural resources to house the culture as his methods prove correct.
Your true place in the hierarchy is the power of your contribution to maximizing proof of usefulness, both directly with your technical output, and your function as a part of the immune system. The quality of work, hours dedicated, and helpfulness are just signals. Signals such as proof of smart, proof of authority, proof of wealth will increase the dimensional complexity of the work at hand: if your engineer has to consider a 'smarter' vs a 'useful' construct, he has already lost time in the consideration. Reducing the possible choices for every decision made is the biggest way to reduce the work it takes to get from A to B.
Go far enough in the wrong direction, and the relationships break down into adversarial competition. The less useful the average employee is, the more zero sum the competition for resources. Growing the pie means reducing useless work.
You would think that this article would be about engineering, and not psychological mumbo jumbo, but remarkably that is not the hard part. If it was, culture would not be talked about upfront. At the end of the day, usefulness is usefulness, whether constructing office buildings, harvesting food crop, or repairing cars. The type of useful work you do does not matter compared to how much neural time you have to devote to it, and this is largely the function of ignoring things that don't matter. May the usefulness be with you.