Skip to main content

How Silos Grow

In my previous post, I suggested several topics to blog about, based on my experiences of 2017. How Silos Grow was the topic most asked for:
This was my initial shock after joining the company. Only a few years after taking off as a startup, the hedges began growing, seemingly almost by themselves, and against the will of the founders.
I've worked in silos, and in companies without them, but I haven't been there to witness them coming into existence before. It is a fascinating phenomenon, yet oh, so common. And a killer of great companies.
This posts digs into why and how silos happen. It's a bit of a long one, so here's the TL;DR:
  • It is about human nature.
  • Departments are a good thing (for some things).
  • People in different departments are inherently different.
  • The project method is still problematic (and reinforces the silos).
  • Cross-departmental teams should be the first-class organizational unit instead.
Although the idea to write this came from my first year at eyeo, this piece is about the sum of experiences I made in my entire career. My employer (still eyeo) went through some of the experiences that I write about below, but not all of them - and they are actively improving the weak spot.

Human nature

If I had some more time, I'd love to dig into the human social and biological reasons for this, but I'll just jump ahead and say there is something primal going on since prehistoric days, and in modern times it is still observable as loyalty to closer/similar people, and distrust for those distant/different. We group ourselves and bind with those of similar means and motives. It makes sense on a very basic level, but like many of our cognitive biases, it is counter-productive in a many modern scenarios, where nomad tribes and saber-tooth tigers are not involved.

My colleague at eyeo, Aaron, describes the mentality of it as "Us vs Them". It seems at times that humans just need that common foe to unite a given group, driving the plot for Wag the Dog, war on drugs, terror, and so on. But let us try to dig a bit deeper on why this happens in companies, especially small-medium sized ones that are growing past the 20 person mark.

Strength in departments

At a certain point in any fast-growing startup, the average count of person-to-stranger relationships will grow much faster than the rate at which people get to know each other.

What people naturally do in such environments is to gravitate towards those they have the most in common with, or simply stick with the ones involved in their hiring and perhaps after hiring through some mentorship program. This tends to be with people of the same profession, or related ones, and the social bonds formed there will stay the strongest ones in the new-hire’s work life for some time.
I think this is a good thing! Having this circle of closer peers provides a safe haven for new-hires while they learn to navigate the larger company. Furthermore, it provides a platform for learning, fostering knowledge and craftsmanship between those who share professions.

Obviously, the kind of department I’m describing above is not a silo. It’s a catalyst for growth and development of people in a company.

Burgers, fries and coke

The typical line-up of departments are an odd bunch. Some of them are knowledge groups like I describe above, while others are defined by some function they provide to the rest of the company. Most of them are a mix of both.

Some of the departments are half-function and half-product: Sales, marketing and support functions (IT, legal, accounting, etc) are often not considered within what I call the "hamburger" of product/service delivery:

  • Product (research and design) 
  • Development 
  • QA 
  • Operations
If you want anything from a particular product or service, these are the entities you have to bite through in order to get anything.

(If you know your Agile history, you'll remember that most of the industry managed to interweave the first three, and with the coming of DevOps, the fourth joined in as well.)
The other less interdependent functions, like HR, sales or marketing (let's call them "fries" and "coke") are still left out of product/service in some of the most agile shops around to this very day. And because they are operationally separate, they get defined by separate purposes. Now, that's probably not a good way to split up your business/work, but hey, that’s just how it’s done in a lot of places. My point being: until all departments are part of the burger, you’re going to have some degree of silos.

Departments’ natural differences

As each employee can only be member of a single department, it draws in some odd borders throughout the company, like the programming designer - is she in Development or Product department? Infrastructure engineer is another one. Dev or Ops?

Two colleagues independent of each other suggested us being divided by those who think fast and those who think slow. This made me think of something I wrote in one of our internal methodology guides (the context was balance in the nature of work we do, but I'll come back to that another post, I hope):
QA, operations and developers tend to focus on stability, while marketing and business people, designers and product managers focus on new features.
Of course, those things are results or symptoms of how we have (or have not) defined purpose within the company. Of course the latter groups will focus on novel things that drive interest from media and customers. The former groups know they'll get swamped with technical debt if they go chasing new features for too long.

Another difference I think is gender-culture. The constellation of technical departments (the same one I mentioned tends to focus on stability) tends to consist of men, and they attract (or select) male new-hires, while the remaining ones have a more healthy mix. I don’t know enough about the psychology in play here, but in my experience, “male departments” tend to have rougher communication, somehow colder and very “evidence” oriented. The mixed departments have more empathy, more respectful tone and tolerance for intuition.

Some departments may be elitist due to generally longer education paths or having more experienced members. Some departments may be made up of dominantly extrovert people while others consist of introverts. Some may be distributed while others are co-located.

There are probably more reasons for departments being different from each other than I've listed above. Point is, these differences pose the departments in tension with each other, and may lead to avoidance, lack of trust or aggression, furthering silofication.

When do departments turn to silos

The very name-sake of the DevOps movement is the constellation of the Developers versus the Operations department. Already during the Agile revolution, we realized that velocity will hit a certain ceiling less we include the customer (often represented by product owners), QA and Operations in the development teams. Yet, we continue to see growing companies split the work by departments once they reach a certain size.

(Side-note: I believe the wiser companies break out sub- or separate companies before this happens, like Fog-Creek splitting out Trello, or 37signals splitting out everything but Basecamp, or going further back: Semco’s satellite companies.)

When I joined eyeo a year ago, around the 80 person mark, I saw the manifestations of these departments, but the divisions had already begun years before. I'm re-telling a simplified version here, but some time during those early years:
  • Business developers were hired to drive sales and partnerships. 
  • IT administrators were hired to make sure everyone had the equipment they needed. 
  • Infrastructure engineers were hired to take care of the infrastructure. 
  • There was a steady hiring of software developers to develop and maintain the products. 
  • A QA manager and testers were hired to take care of processes and well, QA obviously. 
  • A product manager was hired to build an awesome "product team". 
Maybe you already suspect the culprit here: Already at the hiring stage, new people are brought into the company with role-specific purposes, rather than product-specific ones. This does not alone explain why these new-hires organize themselves by their departments instead of the products/services they work on. Obviously, they’re still supposed to join up with people from different departments on demand, kick-off projects together, drive them to completion, then rinse and repeat.

Now, what happens during the early years of a successful startup, is that it goes past that magic number of employees, somewhere between 20 and 40 perhaps, and things just get difficult:
  • Number of products goes up (and platforms per product goes up) 
  • Number of projects goes up (new product launches, new features in existing products, re-designs of existing services) 
  • Number of services and users on these go up 
  • More money, more media-attention, more responsibility to customers 
As the stakes grow ever larger, people want to perform their best, and it seems intuitive for them to focus in on their own specialty and let others practice theirs. The work gravitates towards being department-oriented, because people have defined their purpose that way.

Along with this, the lines of communication between individuals grow factorially. The essence being that any QA-person can do QA for any project, and the same for every other department for every project. Of course, everyone realizes person-project relationships are more sticky than this, but in a department-oriented company, the person-project relationship is a second-class citizen.

Projects and Departments

The cross-department project methodology works most of the time. Up to a certain size. Then you start getting the occasional misunderstanding: "I thought you were on that project. Who is? Oh, I don't know that person. Can I trust them with getting that right?"

Then comes the differences in priorities: project A is more important than project B now, because project A is in the [department x] phase.

Along with it come the hand-offs: [department x] cannot complete their work in project A before [department y] has finished their part. Lead-time goes down. Quality goes down. Rework goes up. Now you automatically get the blame-games.
And at this point, we’ve pretty much re-invented waterfall. The silos are all around, and you’ll notice that project completion takes forever. The rare successes are overly celebrated by the managers that were in charge of them. Things just don’t get done any more. Toxic relationships develop across departments as tension grows.

How not to fix it

Companies that see projects slowing down into waterfall processes between blame-gaming departments may attempt to combat this in various ways.

They may try putting systems in place to drive improvement. The danger here is that they will look for organizational units where they can latch on goal-processes, incentives, processes or responsibilities (think contractual obligations between departments) and hierarchies. But these measures will only strengthen the silofication and possibly lead to a culture of faking success (known from pretty much any large corporation out there), more blaming, less trust and even slower delivery.

They may introduce an entity responsible for making the problem go away: Cross-departmental project managers, agile or DevOps coaches. This is probably a step in the right direction, but it will only do so much - at least the people in this unit should be calling for a new structure, where purpose can be placed where it should be.

How to start fixing it

This is probably where I should make a cut for a future blog post, but here’s the short version:
  • Re-purpose the departments to be what they are best at: knowledge centrals/catalysts, and home-ground for new-hires. 
  • Replace temporary projects with sustainable, product/service-oriented, fixed teams. Make these teams the first-class citizens of the organization. 
  • Redefine people’s purpose in the organization: Ask them to commit to the success of their team, not the success of their department. 
  • Long term (maybe): Spin off autonomous team-clusters into separate companies. 
Department-oriented is a very old-fashioned way to work these days: We should have teams, each of them with a clear purpose focusing on the end-needs of the business or its customers.

This means business-oriented, but also cross-functional and autonomous teams (because anything else will slow stuff down). The natural departmental differences will still occur, but already within the team on a daily basis, where they can be much better handled than between separate departments at irregular, painful intervals. In the sum of a cross-department team's actions we get a healthy balance of maintenance and innovation with shared purpose.


Popular posts from this blog

Managing dot-files with vcsh and myrepos

Say I want to get my dot-files out on a new computer. Here's what I do:

# install vcsh & myrepos via apt/brew/etc
vcsh clone mr
mr update

Done! All dot-files are ready to use and in place. No deploy command, no linking up symlinks to the files. No checking/out in my entire home directory as a Git repository. Yet, all my dot-files are neatly kept in fine-grained repositories, and any changes I make are immediately ready to be committed:

    -> ~/.atom/*

    -> ~/.mrconfig
    -> ~/.config/mr/*

    -> ~/.tmuxinator/*

    -> ~/.vimrc
    -> ~/.vim/*

    -> ~/bin/*

    -> ~/.gitconfig

    -> ~/.tmux.conf    

    -> ~/.zshrc

How can this be? The key here is to use vcsh to keep track of your dot-files, and its partner myrepos/mr for operating on many repositories at the same time.

I discovere…

The End of GitMinutes (my podcast)

I'm just about ship GitMinutes episode 46, which is going to be the final episode. I'll just paste the outro script here, as it sums up the sentimental thoughts pretty well:

I’m happy to have finally finished [publishing the last episodes from Git-Merge 2017], just in time before Git-Merge 2018 takes place in March. I won’t be going there myself, so I’m counting on someone else to pick up the mic there.

It’s sad to be shipping this one as it is probably the last GitMinutes episode ever. To go a bit down memory lane, 6 years ago, my daughter was born, and as I used a little of that paternity leave to set up my podcasting infrastructure and produce the first few episodes. Initially it was just going to be 10 episodes and call the experiment finished. Instead, I got to 46 episodes, the last dozen or so lazily tailing the last few Git-Merge conferences.

To every one of my guests, thank you so much again for coming on to share your passion in this little niche of computer science a…

Using Voice-Chat for Gamers in Distributed Teams

This is a post going into the usefulness of live voice-chat tools in distributed teams.

If you've ever seen the Leeeeeroooooyy Jeeeenkiiins video of World of Warcraft fame, you've heard this kind of tool in action. It's how the participants in the video are speaking with each other - this is not a feature built into the World of Warcraft game - it's a separate team-oriented VoIP software, and it's all about letting gamers communicate orally while gaming. 

Since these tools are for gamers, they have to be
fast (low latency)light (as not to steal CPU-cycles from heavy games graphics) moderate in bandwidth usage (as not to affect the game server connection) There are several options around: TeamSpeak, Ventrilo, more recently the massively grown Discord, and finally Mumble, which is the open-source alternative of the gang.
A few years ago, when I joined eyeo (a distributed company), several of the operations team were avid gamers, and had a TeamSpeak server set up…

Joining eyeo: A Year in Review

It's been well over a year since I joined eyeo. And 'tis the season for yearly reviews, so...

It's been pretty wild. So many times I thought "this stuff really deserves a bloggin", but then it was too inviting to grab onto the next thing and get that rolling.

Instead of taking a deep dive into some topic already, I want to scan through that year in review and think for myself, what were the big things, the important things, the things I achieved, and the things I learned. And then later on, if I ever get around to it, grab one of these topics and elaborate in a dedicated blog-post. Like a bucket-list of the blog posts that I should have written. Here goes:
How given no other structures, silos will grow by themselves This was my initial shock after joining the company. Only a few years after taking off as a startup, the hedges began growing, seemingly almost by themselves, and against the will of the founders. I've worked in silos, and in companies without the…

Working in Teams over Working as Individuals

I recentlypostedthis sketch on Twitter:

Thanks to a few mighty retweets, it gathered a lot of views (9000 impressions, whatever that means). While that's fun and all, I still felt a bit sad that such an awfully simple insight can garner much more popularity than a thorough blog post that I put some hours into.

So, rather than let Twitter get away with this, I'll steal my own content back into the blog :)

The thread went like this:

Pondering how to battle individualism in companies. For some, it is counter-intuitive that teams can be more responsive, faster and even more accountable than single individuals.

Having "teams" in place is no guarantee that team work is happening. Be wary of too large teams, "I/me/mine", personal contact details instead of team point of contact. Good team is sailing crew, not galley slaves.

Beware heroes, go-to persons, calling in favors and other shadow handling of work. Real teams make the work explicit, both requests/needs and re…