Corporate culture, learning and distributed version control
8 August 2016
I’ve written a bit about why Made by Many isn’t customer-centric any more over on the corporate blog, and wanted to share a bit of the background to how we’ve reached this point. It’s been a gradual process of discovery that’s taken place over many years, and reflects the growth both of our organisation and those of our clients.
And I think that the way that company culture and processes evolve as a company grows is a bit like distributed version control.
In the early days, everyone’s working out of the master repository. Ideas about new ways of working are quickly adopted by everyone – everyone’s ccontributing back into the master repository.
But it doesn’t take too long before this becomes impractical. The company grows, and making sure that the way your team works is precisely aligned with the way the other team works starts to obstruct progress and limit opportunities for experimentation. There might even be merge conflicts, where one team actively disagrees with the other about the best way to do something.
So, inevitably, people start branching. Creating parallel tracks of process and culture, based on the original – but without any obligation to achieve consensus.
And arguably this is healthy. As a leader, we have an obligation to create the best possible working environment for everyone here, and that includes giving people the freedom to experiment with new processes; to do things differently; to branch the Made by Many master.
But there’s a problem with this. As the company grows, people get comfortable in their branches.
At Made by Many, we have some very long established client relationships, each with its own branch. Some of this is for good, practical reasons – different clients often work very differently and that has an impact on the way we work with them. Some clients are well-versed in evidence-based decision making and full stack innovation processes. Some aren’t. Some have much more intensive internal communication requirements than others. Some are simply further away from our offices than others.
Sometimes the branches we create started to bend away from the master repository to such an extent that a newcomer might wonder whether they were really part of the same repository at all.
And that’s mostly because we got lazy about merging.
This can have one of two effects (not mutually exclusive):
- Annoyance at wasted effort – “I wish I’d known that!”. When you realise that a colleague on a different project has already solved the problem you’ve been grappling with, but when you haven’t made the effort to communicate with them. (Or vice versa.)
- Genuinely distructive conflict – “What on earth are you doing?”. When you realise that a colleague who’s new to your project tries to work in a very different way to you. (Or vice versa.)
The first is almost always annoying, and almost always easily rectifiable. Merge conflicts are rare, and in this scenario it’s often it’s just that the merge happened too late. We’re solving this one by finding better ways of sharing best practice between project teams, and between people who specialise in particular things (like the best way to make use of online usability testing platforms, or the best way to demo an interactive prototype). More frequent merging back into master takes a bit of time, but for small changes like this, it’s relatively painless and almost always beneficial to another team very quickly.
The second is tougher. When deep-set differences in perspective, approach and outlook start to develop, merging takes a lot longer. For example, some of those branches became customer-centric to the point of excluding other inputs that might have influenced outcomes for the better. We haven’t found a good catch-all solution to this one. Thankfully it hasn’t happened very often in the history of Made by Many. But through more frequent merging of everything we’ve learned about the work we do, we can massively reduce the likelihood that we’ll be tripped up by an inconvenient branch.
This might happen formally, but is more likely to happen informally – you need to talk with people to run a complex merge, after all. That’s why it’s important to create a workplace which encourages this sort of dialogue at every level. We do this in part at a micro level; making sure that everyone has an opportunity to contribute not only to the work that’s done, but how it’s done. There are no gatekeepers to what ‘official’ process is; everyone is encouraged to contribute back to the master repository. And at the macro level, we try to make sure that people get as broad a range of experience as possible, balancing the desire among our clients to have a consistent team with the need to cycle people across different projects to give them exposure to new ideas and practices.
It’s by no means perfect, but deliberate awareness of these needs is often enough to spur us into action when we detect a signal that something isn’t quite right. If we can detect problem branch behaviour early, then it’s going to be much easier to fix things.