December 1st, 2017
For the past couple of years I have been talking about the holistic development and operations environments at different camps. As this year’s highlight, I gave a session in DrupalCon Vienna around that same topic. The main focus of my talk has been on the improvement opportunities offered by a holistic approach, but there is another important aspect I’d like to introduce: The collaboration model.
Every organization has various experts for different subject matters. Together these experts can create great things. As the saying goes “the whole is more than the sum of its parts”, which means there is more value generated when those experts work together, than from what they would individually produce. This however, is easier said than done.
These experts have usually worked within their own specific domains and for others their work might seem obscure. It’s easy to perceive them as “they’re doing some weird voodoo” while not realizing that others might see your work in your own domain the same way. Even worse, we raise our craft above all others and we look down at those who do not excel in our domain.
How IT people see each other:
But each competence is equally important. You can’t ignore one part and focus on the other. The whole might be greater than the sum of its parts, but the averages do factor in. Let’s take for example a fictional project. Sales people do great job getting the project in, upselling a great design. The design team delivers and it gets even somehow implemented, but nobody remembered to consult the sysops. Imagine apple.com, the pinnacle of web design, but launched on this:
(Sorry for the potato quality).
Everything needs to be in balance. The real value added is not in the work everybody does individually, but in what falls in between. We need to fill those caps with cooperation to get the best value out of the work.
So how do you find the balance?
The key to find balance and to get the most out of the group of experts is communication and collaboration. There needs to be active involvement from every part of the organization right from the start to make sure nothing is left unconsidered. The communication needs to stay active throughout the whole project. It is important to speak the same language. I know it’s easy to start talking in domain jargon. And every single discipline has their own. The terms might be clear to you, but remember that the other party might not have ever heard of it. So pay attention to the terms you use.
“Let’s set the beresp ttl down to 60s when the request header has the cache-tag set for all the bereq uris matching /api/ endpoint before passing it to FastCGI” – Space Talk
Instead of looking down to each other we should see others like they see themselves. Respect both their knowledge and the importance of their domain.
How IT people should see each other:
(Sysadmins: not because we like to flip at everybody, but because Linus, the guy who can literally change the source code of the real world Matrix, the Web.)
Everybody needs to acknowledge the goal and work towards it together. Not just focus on their own area but also make sure their work is compatible with that of others. There needs to be a shared communications channel where everyone can reach each other. It should also be possible to communicate directly to those people who know best without having any hierarchy to go through. The flat organization structure doesn’t only mean you can contact higher ups directly, but also that you can contact any individual from different area of expertise directly.
By collaboration you can also eliminate redundancies. It can be so that there are different units doing overlapping work, both with their own ways. Or there could be a team that is doing the work falling in between two other teams. A good example of this is the devops team. Only in a very large organization there is probably enough work to actually have a dedicated team taking care of that work. As devops need to know something about both the development and the operations side they need to be experts on multiple areas. Still there are project specific stuff they need to adjust. This means communication between the development and devops team. Likewise this same information needs to be passed to sysops team. The chain could be even longer, but it’s already easy to play a chinese whispers, or telephone, over such a short distance. And there is probably nothing devs and ops couldn’t do together when communicating directly and working together to fill those gaps.
Working together, not only to get things done, but also to understand each other gives a lot of benefits with a small work. Building silos and only doing improvement inside them will only widen the cap and all the benefits gained from such improvements will disappear when you need to start filling the gaps between them. Now, go and find a way to do something better together!
Written by Janne Koponen.