In my previous post I wrote about Culture for Collaboration. One thing I didn’t go into was that in order to create a culture of collaboration, you must first establish basic trust.
Trust is something that is extremely hard to just “establish”, it is something you earn. In short, establishing trust is not done over night. So were to start?

Empower individuals and teams
If you by your actions and words show that you trust a team or individual you will in time earn their trust. You will also learn yourself to trust them, which is equally important.
You break this trust when you do this like sending detailed instructions on tasks to be done.  What you should do is present challenges. Make the team or individual themselves come up with tasks, experiments or changes which would work as solution to the problem. This was what we all learned when we took CE courses at colleges. We solve problems. Too often in corporate life you get presented tasks rather than challenges. Sending tasks or assignments is a display of mistrust (or even worse it displays a belief that the sender has the answer and just needs help to execute).
How am I doing in this department? I lead a team so I guess they’d be the ones to ask. Personally I feel like an addict with relapses. Having used to think I could keep control if everything I do sometimes forget this. It’s hard. Once again it’s like with parenting.  Seeing your kid suffer the consequences of learning from own mistakes is torture and it goes against your instincts. It is similar with letting go and empowering teams and individuals, you just have to let go and trust them.

Growing Pains

If the general vibes are that there is a lack of trust and a continued presentation of a Us vs Them scenario you will have an organization without trust, and in return with little actual collaboration.
What happened? The explanation is usually “growing pains”. However that is false, as growing pains have a tendency to pass as you get older. The so called growing pains of an organization never does that. In fact it just gets worse, because the effort required to change something that’s grown too big is too large. The risk is too great and the daunting prospect of change has too many potential down sides.

What to do? You could just give up and go with the flow and when shit hits the fan (and it always does), you just move on. Another option is to tackle the problem of growth at the root cause of the problem. Growth.

Large problems should be divided into smaller ones

Make it small. It is what we as developers do when tasks are too high right? We split them up into smaller more tangible tasks. Why not refactor your organization? What are the benefits of doing this refactoring?  Reducing size will help reduce the alienation between teams and those managing teams. There is no room for “free riders” in small organizations (Well, there is room of course. But those organizations won’t last very long). You reduce the number of communication lines drastically. This means everyone is closer to the actual production. No need for reporting or endless meetings where people, who should know the product on the first place, gets to learn about what is happening with their product.

Another thing is that reducing size increase a sense of ownership and increase the feeling of being in it together. You know that feeling you once had? When there were just 30-40 people and everyone was going for it? If you speak to people who’s been with a growing company for a while and they talk about that time,  it sometime feels like they’re talking about a lost love.

Now, reducing size has it’s down sides. There will be much greater responsibility for everyone. You will probably have to do things which isn’t really “what you’re supposed to do”. Of course this is actually a good thing, as doing unfamiliar tasks gives you the chance to see things from a perspective and it could help you become better at your regular tasks.

Another side effect is that some of the parts being “cut loose” won’t handle the situation. This is a good thing. Reducing size increases the level of transparency. There is no hiding when all the layers of people are gone. You can not blame anyone else when you’re on your own. What this does is that it gives everyone a feeling of ownership and it also makes everyone more focused on the task at hand. When there is nobody to blame, behavior tends to change for the better.

In closing…

Yeah, so that’s it basically. Easy no? Just go ahead and refactor your organization. Use the “Extract Team from division” refactoring, or perhaps the “Push Down manager” refactoring? How about you just do the classic Remove Middle Man(ager) refactoring? 
Of course this could be just plain stupid. I mean I have no actual education or real experience doing any of this, so what do I really know about this? What I do know, is that it is people who’re supposed to know these things who create these bad organizations with inefficient work environments, so perhaps it’s time to let someone else have a go at it?