Maintaining Consistency in Cross Functional Teams

After writing my last post on this subject a few people came to me with variations on this question (this one is from WellKemptNerfHerder on Reddit):

Does anyone have any resources/links/blogs that dig into the pros and cons of cross functional vs siloed IT/Dev teams? One obvious possible con that I can see traditional IT raising is lack of adherence to corporate practices and patterns

The real thing that working in Silos brings you is that you have knowledge transfer and easy consistency within a skill set. All the employees of a specialism work together so they can sit down and talk about how their team works, ask questions of each other, and generally really get into that one specialism. This is a bad thing.

This is bad for two reasons, the first being that consistency is not always a virtue. At GDS they have a catch phrase, which is "Harmonizing not standardizing", this means that so long as all the parts work well together the details don't need to be identical. Sometimes a bit of variation can allow you to solve a problem better than perfect consistency.

Infact there is a reasonable amount of research now that points to how a diverse workplace in both skills and personal backgrounds can create better products. One example might be that if you'd never worked with DevOps you might not know creating 1,000,000 tiny temporary files in your program is a bad thing. Cross functional teams move you away from this standardised environment, putting you in close contact with people with different skills, broadening your own.

Further than differing skills, differing roles attract people of different backgrounds. There is a well documented lack of diversity in the pool of software developers on the market, so if you are one you might never really understand the needs of people who don't fit into your niche without working with them. A better understanding of people of differing backgrounds can allow you to make sure you're developing better products, this can be little things like knowing gender shouldn't just be Male/Female, or bigger things like ensuring people who are colourblind can use your product.

Not standardising on a specific thing is beneficial for so many reasons.

Now I know what you're thinking now, there are some situations where you need this consistency. Perhaps your deployments work in a specific way, or you need to get some specific metrics out of some work you are doing. Thankfully there is a solution.

The solution is to maintain cohesion within the specialisms. This is done by nominating a leader for a specific specialization (see the bold shapes), and have them regularly meet, manage, and drive with their specialism and transfer skills and practices. These teams are secondary to the primary project teams, but offer a way to influence and develop a cohesive way of working across projects.

These teams tell you "How", not "What" to do, and you don't sit with them primarily, you sit with your project.

The second reason why total consistency is damaging for teams is to do with employee motivation. Modern research describes three key factors that motivate people. Autonomy, Mastery, and Purpose. Slight lack of consistency between projects aids two of these three.

You gain Autonomy by working in a smaller team, and making more of the critical decisions for that project. You're freer to try new things, experiment, and really own your part of the project. This gives you relatively a lot of power compared to a large Siloed team.

Secondly you gain Mastery. Slight deviations means you're able to go for that best implementation, you're able to stretch your skills, and specialise more in technologies that are best for that particular project. This creates lots of opportunities to gain mastery.

It's also easier to see the end goal, and as such see the purpose of your code in non-siloed teams. This aids purpose, but is not really driven by consistency or lack of it.

So there you have it. Siloed teams not only have lots of conflict like I explored in my last article, but also sap motivation and reduce your ability to make a well fitting solution.