It’s Not Really A Technology Problem
I recently had a conversation with a client who was looking for a third party to assess their software product’s quality. He is a very capable businessperson, but his concern was that since he is not technical, he had no way of knowing whether his lead engineer and his team had done a good job building the system.
The quality of a system is very important to the business. By quality, I mean that the software is architected and built in such a way that ongoing maintenance, modification, and extension are all relatively low cost activities compared to the initial cost of building the system. In modern software development, we have well-established practices for building such systems, such as pair programming, proper use of design patterns, modularity and encapsulation of components, and automated testing. One needs only to be knowledgable about these practices, and implement them carefully, in order to produce a good system.
But I knew something else was going on when he said that his lead developer would frequently reject requests for changes to the system either because the requirements were not detailed enough, or because such-and-such was “impossible” without months of pre-work doing this-or-that. You get the idea. This engineer, it seemed, had built himself a kingdom of code, one where he was able to ward off annoying requests from the business by throwing up walls of confusion and doubt.
My businessperson client had inadvertently found himself — and his business — held hostage by an engineer who was either unwilling or unable to honor requests for changes to the system, changes that could be critical to maintaining an advantage over a competitor or expanding into a new market.
It would be easy to project some nefarious aim into this engineer. But I doubt he’s being intentionally malicious. I think it’s just as likely that this relationship between the two of them emerged slowly and organically, as the each pursued their own perfectly rational behaviors, given the culture and processes of their organization, and their unique positions within it.
We’ve talked before on this space about Conway’s Law, a theorem proposed by Martin Conway in 1967 that system architectures tend to mirror the communication patterns of the organizations that build them. I think there is an important extension to this idea: the quality of a system is proportional to the quality of the relationships between the people that build it.
Let me say that again.
The quality of a system is a reflection of the quality of the relationships between the people that build that system.
And what do you call the aggregate of all of the relationships between people in an organization? Why, it’s the culture, of course! And thus, only good cultures can produce good systems as their products.
Of course, as a community we know that to true in our guts. But how do we use this understanding of the relationship between good culture and quality products to our advantage? We cannot directly modify the culture of our organizations, whether through innumerable inspirational memos or speeches by the leaders, or by putting pithy and thought-provoking phrases on the wall.
Culture emerges as a result of the behaviors of the people in a group, passed along by communication and imitation. Those behaviors are driven primarily by two very concrete things which you can directly modify: the process people use to do their work, and the incentives they have to do it well.
Culture may indeed eat process for breakfast, as Drucker says. But, to mix metaphors here, it’s also true that “you are what you eat”. Culture itself emerges from the aggregate of all your processes.
Every organization has a collection of processes, whether documented or implied, through which people accomplish their work. These processes exert an enormous influence on the relationships between people. A good process can bring people closer together. A bad process can produce negative and dysfunctional behaviors and attitudes.
Consider as an example, the old “throw it over the wall.” Many organizations are structured as silos, with different functions organized as wholly separate departments. However, in order to achieve some kind of project or initiative, those functions have to cooperate. Engineering needs to coordinate with Design, who needs to coordinate with Sales and Marketing, and so forth.
In organizations like this, you get a lot of “throw it over the wall,” as one function completes some portion of the process, and passes the unfinished work along to the next function. Functional groups then tend to see other functions, both up and downstream from them, in a negative light. There are frequently accusations of others dropping the ball, or shirking responsibility, and so on.
The problem is the process. It’s not that Marketing actually wants Engineering to fail. It’s that the process is set up in such a way that a handoff between them makes failure more likely. Each function is doing what it can to locally optimize their work for their own part of the process. They are not organized to work together effectively in a cross-functional team.
In culture terms, you end up with negative beliefs about other departments lasting a very long time. Folks in Engineering talk about “those people in Marketing” as if they are some tribe across the river competing for the same natural resources. It’s ludicrous, of course, but it’s all too common. This is just one example of how process produces culture.
Incentives also matter tremendously. Simply put, incentives are the combinations of carrots and sticks that your organization uses to drive performance from its employees. This includes concrete incentives such as compensation or disciplinary actions. But it also includes more subtle incentives like recognition and praise.
The incentives of an organization can also exert a powerful influence on culture. Telling people to work as a team, and then incentivizing them as individuals will ultimately backfire. Telling people to be creative and innovative, and then incentivizing them to stick to the original plan sends mixed messages and will result in stress and infighting.
It is critically important that your incentives be optimized to produce a culture of quality, so that your organization can produce systems of quality for its customers and stakeholders.
What incentives produce good product cultures? Well, let’s think about what a good product culture is, and work backwards from there. A good product culture includes collaboration and teamwork, people stepping out of their comfort zones, people admitting their mistakes and learning from them, people being honest and transparent with one another.
Incentives that encourage that kind of behavior are rare in organizations, but they do exist. For instance, try evaluating people as teams rather than individuals. Try, rewarding teams for failing fast and learning, rather than sticking to the original plan at all costs. Reward people for sharing information rather than hoarding it.
To conclude, if the key to producing a good product is to have a good culture producing it, then the key to producing a good culture is to design or transform your organization with the right processes and incentives that will produce that culture. Your processes should encourage cross-functional collaboration as much as possible. If that means you break-up silos permanently, then so be it. Your incentives should avoid rewarding local optimizations and individual behaviors, and instead reward teamwork and collaboration.
When you look at the culture of your organization, and identify things that you want to change, the first place you look should for trying something new be in the processes and incentives that have produced that culture in the first place.
