Blue sky silos

We all know silos are big horrible things, and i’m not talking about the physical ones I’m talking about the invisible ones between groups of people. These types of silos need sorted out as soon as possible; Otherwise one becomes two becomes four. I’m sure you get my point by now, they spread, and the longer they are left unattended the harder it is to break peoples habits.

The key thing to remember about silos, is that they are created because of the culture

The usual ones we see when creating digital services are between engineering teams. You can also get discipline or community silos which can cut across the various teams. But there is another sneakier one which you may come across every now and again. It can typically be found in large organisations or programmes and is between the blue sky thinkers (Archs, management and the likes) and the rest of us folks in the engineering teams.

Now i’m not saying blue sky thinkers are not required in the creation of digital services, in fact its the exact opposite, they have a vital role to play like every one else. But we need to ensure that blue sky silos, as I like to call them, don’t get built as they can suck the life and soul out of a programme quicker than I can drink my morning cup of coffee, which, trust me is pretty fast.

But how can you tell you have such a silo when delivering a complex set of services?

Here are three characteristics I have come across.

Chinese whispers

Ever walked from one end of an open plan office to another and heard at least three different stories about what the next delivery outcome is for the programme?

This is very common in large programmes and is often down to the blue sky thinkers saying to a select few what their vision is (What and the Why) or more importantly saying to a select few when this changes. The message gets re interpreted as it propagates down to the engineering teams to the extent that the original message is no longer recognisable, either that or it’s just not communicated down to engineering teams, the people who work on the “How”.

So what can be done about this?

We live in an age where it has never been easier to communicate with people. Tools like slack are light weight and ideal if you have something quick you want to communicate or find out. Combining this with getting the vision and programme roadmap up on a wall for everyone to see, will help get the right two way communication going.

But its not just that simple. The blue sky thinkers need to remember to use the appropriate communication tools, keep the wall up to date and give the proper context. Where the “How” people, the engineering teams, need to keep checking the wall and communication channels and actively seek the what and the why if not provided, or if they hear conflicting message. This is a mindset change and you will need to prompt a lot at the very beginning.

And while we are talking about building a wall which shows a programme view of things, it is important they are built in such a way that when someone outside the programme looks at it, like senior stakeholders, they can understand whats going on. Over the last year I’ve learnt the importance of straight lines, keeping the format extremely slick and removing any jargon when it comes to programme walls. Something I have also found useful is to test a paper based design with a few people before you start building one. It can save you many hours of frustration in rebuilding it. But I digress, back to the blue sky silos

Everything is a push

Ever been asked to carry out something and also been told by the same person exactly how you should carry it out?. It’s frustrating right, especially if you know the person issuing the instructions is missing some piece of lower level detail to determine how it should be done correctly.

Same thing can happen when building digital services. For example, the blue sky thinkers can spend days locked in rooms deciding the priority and also exactly how various features are going to work, they then tend to hand this off to the engineering teams to develop. Inevitably this leads to the teams going off and developing the feature in a way which does not deliver on the goals for the business.

So here’s the thing. The teams know what exactly has been built to date and also how it has been built. They also know the users and can empathise with them. So who is best placed to determine how the feature is going to work?. The team of course.

The teams however might not fully appreciate the benefits to be realised by the business unlike the blue sky thinkers, so the team can’t be fully responsible for making prioritisation calls or setting goals to be achieved. They are however vital stakeholders in the process.

To break down this barrier some boundaries should be established between the two groups in terms of responsibilities. The blue sky thinkers should come up with the strategy and articulate clear goals they are looking to achieve with the features. The teams should determine how to deliver on the features. Teams will also need to be given a voice to feed back into the goals and prioritisation of features as this will inevitably change based on whats happening on the ground.

Again easier said than done, articulating goals is an art form and people struggle with it in the early days. It also requires a certain amount of self restraint to not delve into the how when you are a blue sky thinker, especially if you have been used to it for so long.

For the teams they need to get used to not being spoon feed. Believe it or not people can get used to this if it’s been going on for a long time. They also need to get into the habit of feeding vital information back up which can be used for input into the strategy and planning process. The blue sky thinkers need to be willing to listen as well.

Doing what your told

So this is the spoon feeding thing I mentioned above. It’s where teams loose the willpower and motivation to think for themselves, and can be likened to having a bunch of lifelike robots working on the programme following exact instructions, rather than a group of highly motivated people all moving towards the same goal and collaborating on how to best achieve it.

A tell tale sign of this is when teams don’t question things that the blue sky thinkers say. They also will have a lot of blockers and dependencies which don’t seem to go anywhere as they don’t feel empowered to progress these themselves.

This is one of the trickiest ones to sort as you need to empower the teams. The best strategy is to use your scrum masters or coaches on the programme to get the teams motivated.

Teams are more motivated when they are getting high value things to the users

If you have a lot of teams you may also want to consider mixing the people up a bit so not all the individuals who challenge the norm are on one team.

So thats the three

You have probably guessed by now that there is no short term solution to breaking down this type of silo, it will take time, but the earlier you can identify it is being built, the easier it is to change the culture and get things back on track.