Menu Search
Jump to the content X X
Smashing Conf San Francisco

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf San Francisco, dedicated to smart front-end techniques and design patterns.

Breaking Down Silos, Part 1: The Consequences Of Working In Isolation

No man is an island entire of itself; every man is a piece of the continent, a part of the main…

– John Donne

If you’ve ever worked at a company of any size, you’ve experienced it. Isolation. That feeling of being utterly alone in what you do.

Some people love it: the determination that comes from being a lone ranger, boldly going where no one has gone before. Others hate it: the despair that comes from slaving over a design only to see it disappear down a black hole of development, whereupon it emerges onto a website months later, unrecognizable from the pixels you put on the page with such painful precision.

Image credit: Ibrahim Iujaz2

These are the perils of working in siloed environments, and it’s where many of us find ourselves today. We’re either terribly alone or terribly frustrated, depending on the particular variety of silo we find ourselves in. In this two-part series, I’ll explore the consequences of working in isolated environments, and how we can solve this problem by encouraging more collaborative cultures.

What Exactly Are We Talking About Here? Link

Silos in work environments usually come in two flavors:

  1. Lonely silos
    Lonely silos are made up of workers with no real connection to the outside world. This often happens at start-ups where the focus is more on getting something out the door than on doing it right. I mean, who has time for proper UX design when “we’re building [technology x] because [company y] hasn’t built it and [people z] need it?” (as Kyle Neath recently put it3).
  2. Functional silos
    Functional silos feature workers who may be part of fantastic design teams. They have great whiteboard sessions, help each other out, enjoy their pizza Fridays… And yet, they have no real seat at the table when it comes to business strategy. Design happens painfully slow because it has to be signed off by 10 different people. And even then, there’s no guarantee that anything will be implemented the way the designers envisioned it.

Working in lonely silos and functional silos have two main consequences, both devastating to software development:

  1. No process
    This usually happens in lonely silos. It’s everyone for themselves. The company subscribes to the “release early, release often” approach, and so you won’t get bogged down with a formal development process, guidelines for functional specs or any of the stuff that big lame corporations busy themselves with.
  2. Too much process
    This usually occurs when functional silos get out of control. Organizations resort to putting hierarchies and processes in place to stop the “cowboy coding” madness. The science:art ratio in design shifts way too much to one side or the other. Functional specifications move into Microsoft Word templates that are 20 pages long before a single word of content is written. And sure enough, the cowboy madness stops. But it gets replaced with a different kind of madness: stagnation.

The Consequences Of Not Following A Design Or Development Process Link

When you work in an environment where silos result in no clear design or development process, the following often happens.

1. MVP Madness Link

We all know the concept of “Minimum Viable Product,” but revisiting Eric Reis’ definition4 would be useful:

The minimum viable product is that product which has just those features (and no more) that allow you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.

Problem is, that last section of the definition often gets ignored. You know, the part about people paying you money. So this MVP idea can be taken too far, and a product can be released before there is a minimum viable understanding of what the thing is supposed to do (or who it’s supposed to be useful for). You could argue that the Color app is an example of this MVP madness (“It’s a photo app!” “No, it’s a data-mining app!” “Actually, it’s a local group-messaging search/recommendations app5!”)

Perhaps the best example of this culture is the Lifepath6 sign-up page, which Dustin Curtis recently put up in what I’d like to believe is a deliberate and very effective attempt at MVP irony:

Lifepath sign-up page

A lot of this problem would go away if we evolve MVP thinking into what Andrew Chen calls “Minimum Desirable Product8”:

Minimum Desirable Product is the simplest experience necessary to prove out a high-value, satisfying product experience for users.

I think that definition would send a lot of MVPs back to the drawing board, and rightfully so.

2. No Significant Design Focus Link

The second consequence of a lack of process, particularly in start-ups, is that design can be the last thing on people’s minds. When you hear start-ups giving an overview of their staff, they often mention developers, marketers, and business development managers, but no designers.

There can obviously be legitimate business strategy reasons for those hiring decisions, but where it can become harmful is when ideas go from vision to code (and users) in one easy step, bypassing the principles of user-centered design completely. As Erika Hall puts it:

The floor of Silicon Valley is littered with the crumbling husks of great ideas — useful products and services that died in the shell before they hatched out of their impenetrable engineering-specified interfaces.

3. Endless Cycles Link

A third consequence of no-process development is that you never really know when you’re done. Not to make this about methodology, but this is one area where the “definition of done” concept in Scrum is extremely useful. If you don’t know when you’re ready to push something live, then the problems of MVP madness and lack of design are exacerbated.

Google Wave is a case in point. Listen to Douwe Osinga9 as he gives two good examples of MVPs done right before moving on to the problem with Google Wave:

Thinking big sounds great, but most big ideas start small and go from there. Google itself started from the notion that it would be interesting to look at back links for pages. Twitter started out as hardly more than a group SMS product that also works online. Facebook explicitly restricted themselves at first to one university.

Wave is a case in point. Wave started with some fairly easy to understand ideas about online collaboration and communication. But in order to make it more general and universal, more ideas were added until the entire thing could only be explained in a 90 minute mind blowing demo that left people speechless but a little later wondering what the hell this was for.

The Consequences Of Having Too Much Design/Development Process Link

So that’s what can happen in a no-process environment. But what happens at the other end of the continuum, where process is king of the world?

1. Org-Structure Design Link

When you can sketch out an organization’s structure by looking at its home page, chances are it’s hopelessly lost in functional silos. I experienced this first-hand while working at eBay. I would sometimes run into the product manager for the home page in the morning, and he’d have no idea why his page looked the way it did on that particular day. Each day was an adventure to see what had changed on the page that he “owned.”

Don’t believe me? Below is an example of the eBay home page from about a year ago, with the teams responsible for each section of the page overlaid (they’ve since gone through a redesign that fixed this issue):


This is unfortunately one of the side effects of functional silos. You run the risk of losing any sense of holistic design direction on the website.

2. Design Monkeys Link

Another consequence of an over-reliance on process is that designers could become nothing more than monkeys, cranking out efficient, perfectly grid-aligned but completely uninspired designs on an assembly line. Wondering whether this is you? Here are some instructions you might recognize as a design monkey:




Don’t get me wrong: I believe in style guides, and I believe in design constraints. But when an organization becomes overly reliant on design rules, creativity is often the first thing out the door. Yes, design is much more than art (we’ll come back to this later), but it’s certainly not pure science either. Without the right injection of art and creativity, science gets boring and forgotten pretty quickly.

3. Tired Developers Link

Once process takes over an organization, the acronyms start. And arguably, the most feared of them all is PRD: the product requirements document. This usually takes the form of a Word template, with a two-page table of contents. It includes a solution to every single eventuality the software might ever encounter. It sucks the soul out of product managers and the life out of developers.

To use an example from a previous company, we once had a 23-page PRD to make some changes to our SiteCatalyst JavaScript implementation. And then the project didn’t happen. I shudder to think about the hours and hours of lost productivity that went into creating this document that never got used. People could have created things during that time. Instead, they sat in Microsoft Word.

The result? Tired developers. Developers who don’t want to code anymore because coding becomes 70% deciphering Word documents, 20% going back and forth on things that aren’t clear, and 10% actually coding.

How do you know that your developers are tired? Charles Miller quotes an ex-Google employee15 as describing what it means when a developer tells you that something is “non-trivial” sums it up pretty well:

It means impossible. Since no engineer is going to admit something is impossible, they use this word instead. When an engineer says something is “non-trivial,” it’s the equivalent of an airline pilot calmly telling you that you might encounter “just a bit of turbulence” as he flies you into a cat 5 hurricane.

Tired developers use the word “non-trivial,” or some variation thereof, a lot more than energized developers.

4. Distrust Between Teams Link

When people don’t live and breathe each other’s workflows, understanding the decisions they make is hard. And if you don’t understand the reason for someone’s decisions, distrust can creep in.

Functional silos that rely on too much process serve as fertile ground for distrust in relationships. A reliance on process can instill a false sense of security and the mistaken assumption that conversation and understanding are less important than proper documentation. This is particularly true in the complicated relationship between designers and developers. As Don Norman recently put it16:

Designers evoke great delight in their work. Engineers provide utilitarian value. My original training was that of an engineer and I, too, produce practical, usable things. The problem is that the very practical, functional things I produce are also boring and ugly. Good designers would never allow boring and ugly to describe their work: they strive to produce delight. But sometimes that delightful result is not very practical, difficult to use and not completely functional. Practical versus delightful: Which do you prefer?

So, when designers and developers are not in the same room from the moment a project kicks off, or when design becomes prescriptive before thorough discussion has taken place and everyone has sweated the details together, the stage is set for the two worlds to collide. Breaking down these silos is the only way to design solutions that are practical and delightful.

5. Design by Committee Link

Not everyone can code, so they don’t go to developers telling them that their HTML needs to be more semantic. But everyone thinks they’re a designer, or at least has a gut feeling about design. They like certain colors or certain styles, and some people just really hate yellow. Because everyone has an emotional response to design and believes “it’s just like art,” they think they know enough about design to turn those personal preferences into feedback.

One of the first things we need to do to solve this problem is to teach people how to give better design feedback. Mike Monteiro gets to the crux of the issue in “Giving Better Design Feedback”:

First rule of design feedback: what you’re looking at is not art. It’s not even close. It’s a business tool in the making and should be looked at objectively like any other business tool you work with. The right question is not, “Do I like it?” but “Does this meet our goals?” If it’s blue, don’t ask yourself whether you like blue. Ask yourself if blue is going to help you sell sprockets. Better yet: ask your design team. You just wrote your first feedback question.

And how do we respond practically to the problems of design by committee? Smashing Magazine’s own article17 sums it up best:

The sensible answer is to listen, absorb, discuss, be able to defend any design decision with clarity and reason, know when to pick your battles and know when to let go.

Here are four principles I use in my day-to-day work to make that statement a reality:

  1. Respond to every piece of feedback.
    This is tiring, but essential. Regardless of how helpful it is, if someone took the time to give you feedback on a design, you need to respond to it.
  2. Note what feedback is being incorporated.
    Be open to good feedback. Don’t let pride get in the way of a design improvement. And let the person know what feedback is being incorporated.
  3. Explain why feedback is not being taken.
    If a particular piece of feedback is not being implemented, don’t just ignore it. Let the person know that you’ve thought about it, and explain the reason for not incorporating that feedback. They will be less likely to get upset at you if you explain clearly why you’re taking the direction you’re taking. And if you’re not sure how to defend the decision…
  4. Use the user experience validation stack.
    Read the post “Winning a User Experience Debate18” for more detail. But in short, first try to defend a decision based on user evidence — actual user testing on the product. If that’s not available, go to Google and find user research that backs up the decision. In the absence of that, go back to design theory to explain your direction.

Summary, And Where We Go From Here Link

Ending an article on such a doom-and-gloom note feels a bit wrong. But maybe pausing here would be good so that we can all reflect on the issues that siloed development creates in our own organizations. As UX people, we’re taught to understand the problem first before trying to solve it, right? So, let’s do that. Did I miss any consequences? Anything you’d like to add or challenge about the consequences I’ve highlighted in this article?

In part 2, I’ll explain my own journey with siloed development and go over some of the guidelines we’ve implemented to break down these silos and build collaborative teams that help eliminate the vast majority of the issues outlined in this post.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18

↑ Back to top Tweet itShare on Facebook


Rian is passionate about designing and building software that people love to use. After spending several years working in Silicon Valley and Cape Town, he is currently Product Manager at Postmark, working from Portland, OR. He also blogs and tweets regularly about user experience and product management.

  1. 1

    As a designer still in my first six months as a professional, I completely understand this phenomenon. I work in a small Java shop that is hopelessly out of date, which makes it very difficult to bring standard practices into the production environment. So far the front-end developer has handed all his projects to me half way through, and I’ve had to redesign everything from the ground up, then help the client understand why we are spending more time on a project than expected.

    Working alone can be rewarding, I mean, seeing yourself exceed past your peers. But it’s never good when you’re the only one, it puts a lot of pressure on you to convince clients and co-workers than what they’ve been doing for 10+ years is wrong.

    Thanks for this article, I hope to read the upcoming one about your own experience.

    • 2

      that’s true. You can’t convince them unless you are entering the company from a very senior position, otherwise, you’re in no position to talk about process unless asked (hard lesson to learn).

    • 3


      August 30, 2011 8:28 am

      But isn’t the conclusion that “everyone else” has been doing it “wrong for 10+ years” just symptomatic of precisely the danger of silos that this article is talking about?

      Obviously nobody’s processes are not perfect…heck, I’m sure I would look at what you’re wanting to do the “right way” and say it was “wrong”. But that’s not really an attitude or approach which is conducive to creating a sustainable and prosperous environment. Rather, it’s an institutionalization of the “cowboy” mentality, dressed up in the facade of “knowing better.” But the end result is still the same…more silos.

      • 4

        You’re absolutely right, I exaggerated and oversold the point. Also, yes, I am further perpetuating the problem. But that’s why we’re discussing it. In an industry such as our that changes so quickly, how can we create or modify existing environments that are conducive to constant change and development?

        The situation that exist at my office and many others is not ideal, and I’d love to find a better solution than the one I’m currently using, but right now that’s hard for any of us to concretely define.

    • 5

      What they did, was not wrong (in most cases) ten years ago – you should make them understand, that things changed and that there are more useful, better fitting, cheaper, more reliable solutions today!

  2. 6

    Good article (so far)

    Process is super important and can really make or break the success of a company. And I agree, too much process is just as bad as no process at all (might even be worse). Looking forward to hearing some solutions.

    So it goes…


    • 7

      Ah, so it sounds like you’re suggesting that we need to create a process to ensure that we don’t have too much process??

  3. 8

    great article! and soo much truth.

  4. 9

    Great article and very well written. It was a pleasure to read it.

  5. 10

    I like it a’lo!!!

  6. 11

    Really nice read. Looking forward to part deux.

  7. 12

    I see the no-process environment as just getting the job done, keeping your head above water and producing a product that “works”. Nobody wants that and I can’t see that a business like that would be able to fully grow.

    On the other side, I see the too-much-process environment as one that is un-trusting and stifles creativity and innovation. Those are never fun to work for and how much can they truly expect their employees to grow? Transparency is also big on this side for success.

    Also – I love that you pointed out the Org-structure design. No one can completely serve their client as best as they can without total immersion in my opinion. I want to do the best that I can for you and your business and reach your full potential. However, knowing how to talk about that brand/business, knowing what’s going on and where, can you bring you insight that can’t be served any other way.

    Great article, it applies to so many industries and job titles that anyone can take some pointers from it.

  8. 13

    Charles Miller

    August 30, 2011 4:25 pm

    I’m not the author of the quote about “non-trivial” problems. If you read the article, I’m actually quoting something else and then disagreeing with it.

    • 14

      Rian van der Merwe

      August 30, 2011 8:41 pm

      Thanks Charles, good point. The problem is that the original blog post you quoted from doesn’t exist any more, so we’ve now changed it to “Charles Miller quotes an ex-Google employee…”

      Sorry for the mix-up.

  9. 15

    Riaan, its great to see a fellow South African contributing to my favourite blog. Moved from a digital creative studio working on advertising to in house design for a startup this year its been very challenging as the developers are based in Holland and Im the only digital designer in the company, a lot of what you say in this article I have now experienced first hand , and there is lots of great advice here for me. Regardless of the challenges I face working in a silo I think this experience will make me a better designer, I also have more empathy for our dev’s now :)

    shot Riaan, cant wait for the next article.

  10. 16

    Niels Matthijs

    August 30, 2011 11:07 pm

    One consequence I’m missing is that silos lead to people living in sheltered environments. Designers who believe the Apple brand appeals to everyone, coders who believe the whole world uses Chrome or Firefox, UX designers who take a concept too far just because other UX designers are impressed by their creativity.

    You need outside influences to keep in touch with reality, and if you’re working in a silo, the hampered communication between you and team members from other fields will actively prevent you from picking up things from people with other mindsets, other priorities and/or different views.

    • 17

      Rian van der Merwe

      August 30, 2011 11:46 pm

      Good point, Niels. It’s the whole “you are not the user” phenomenon that’s so prevalent. Agile Bits recently summed this up well in one one their blog posts:

      “Security systems (well, the good ones anyway) are designed by people who fully understand the reasons behind the rules. The problem is that they try to design things for people like themselves—people who thoroughly understand the reasons. Thus we are left with products that only work well for people who have a deep understanding of the system and its components.”

  11. 18

    One of the most inspired articles I’ve read in a while – thanks! Makes me feel ever more thankful for my current job, having seen many of these siloed pitfalls in spades working contracts as a one-man-army for the past several years. Looking forward to the next installment!

  12. 19

    Silo mentality is born from the top down. It’s the death of company morale worldwide. The problem will become more and more apparent as less and less care is given to providing information to team as a whole as to what the over-arching vision and belief is of the company.

    Because it means that nobody in any department works in harmony and ultimately destroys the spirit and essence of it all.

    This is a great way of visually displaying what impact this has from the outside looking in.

  13. 20

    Bradley Hebdon

    August 31, 2011 10:28 am

    Incredibly relevant topic, and great article so far — really looking to Part 2.

    One angle I think you might want to include is one of cause. That is, why might silo’s exist? In certain cases, there might be no specific reason, but in other’s it might be by design. E.g. is someone looking to get a promotion, receive credit, get a bonus, take over a department, have someone or an entire group fail, etc, etc.

    If we are to truly understand the problem, we should be looking at the root cause.

    • 21

      Rian van der Merwe

      September 1, 2011 5:40 am

      Great observation, Bradley. In part 2 I spend quite a bit of time talking about understanding and motivating people, but talking about people’s personal/political motivations is probably a completely separate post.

      I think many functional silos happen organically as organizations grow without the necessary focus on building collaborative environments from day 1. More on that in part 2…

    • 23

      My experience of Silos has been through organisational structure or managers taking ownership as the belief in the organisation is the managers/ heads call the shots and the coders/ designers are the end of line monkeys.

      The issue is that the briefs are inaccurate and vital details omitted by less technically qualified ‘senior role members’. This only becomes apparent when development is undertaken, throwing out schedule and resource. Developers get frustrated, and the saga continues again, as those ‘senior members’ do not accept responsibility. This ongoing cycle then breeds mistrust and creates a them and us situation.

      I don’t think this is solely confined to software development. Many organisations have employees who see promotion and career progression as their priority.
      Organisations need the team concept and everyone to buy in. Unfortunately, these are few and far between.

  14. 24

    Developer Dude

    September 1, 2011 7:17 am

    Just a little side-note: I have used the phrase “non-trivial” quite a bit from time to time, and it did not mean I was tired. I did not use it to understate that something was very hard, impractical or near impossible – I meant it to mean some task/goal/objective was not a trivial undertaking, that while possible, it was not something that was easily done in a short amount of time.

    About half the time that would shoot something down because the PM wanted the task to be a trivial undertaking that took a trivial amount of time – otherwise it was not worth doing, at least not at that point. The other half of the time I was asked to elaborate further because the task was important enough to weigh the options against the cost, at which point I would try to lay out the time/effort/cost of the undertaking, or maybe just the effort it would take to figure out how much time/effort/cost it would entail.

    If something was impractical or near impossible, that is what I would say. Sometimes I was wrong – most of the time I wasn’t.

    Words mean things – we should use them correctly.

    Of course, there is always the boss that doesn’t listen; my first dev job the boss asked for several years about a particular task and I would always give the same answer; six months. It was six months last time you asked and it will be six months the next time you ask. It isn’t going to go away, and it isn’t going to get easier because you ignore it for a year, or two – indeed, if anything it will take longer.

  15. 25

    This is great article and I recommended to all my peers reading it. I have one question though. Authour featured example of eBay homepage and how business work. I wonder about Non Disclosure Agreement(s) and such… I’m sure that eBay won’t be happy reading about former employee not-so-nice experience.

    Actually, this is even bigger issue as I am sure we all sign NDA and then not able to talk about products, processes and tools of our client/employer.

    Does anybody want to write an article about this?

    • 26

      Bradley Hebdon

      September 1, 2011 4:57 pm

      Good point Alexei about NDA. How does this even impact one’s portfolio/interview process?

      • 27

        With almost 20 years of experience I learned to make general remarks about different approaches and industries. But it’s always hard (i.e. impossible) to make examples with real projects and limitations (read managers, team mates, budgets, goals, users, timelines, methodology, tools, tech solutions). Everything is under NDA.
        Although, UX is an activity of managing project limitations and client expectations withing time and budget. It boils down to a story of achievements withing a field of limits and goals which one not allowed to talk.
        I’m always surprised when I read in book or online about real projects with screenshots or even wireframes (which are strictly internal documents). Shady…
        I would love to know what industry leaders think about it.

        • 28

          Bradley Hebdon

          September 6, 2011 1:24 pm

          I think a lot of it has to do with timing. That is, are you sharing artifacts from a project that hasn’t launched, or has it been live for a couple of years. In other words, what your’e saying or showing — does it give a potential competitor insights that could help them compete more effectively? To me, if the answer is “no” — that you can probably justify sharing aspects of “internal documents” that won’t damage image/position in the marketplace.

  16. 29

    The second consequence of a lack of process, particularly in start-ups, is that design is often the last thing on people’s minds.

    I think it is not design, but copy :-) People have this taken for granted approach when it comes to content/copy.

  17. 30

    This article couldn’t be more appropriate. My employer is on the verge of going out of business because of the last 5 years we have tried to produce two software products that were done in isolation by the two individuals who proposed them but guarded them and controlled them tighter than fort knox. There was no team collobration, no group thinking or opinions. Now both products are a big joke and couldn’t sell even if we gave them away. Collaboration is the key.

  18. 31

    As someone who has just walked out on a job with (relatively) decent pay I can see a lot of where you’re coming from. I was hired as a PHP developer, except I got very little opportunity to actually develop anything. I instead spent most of my time trying to fix a system which had been written by a complete and utter novice and which was completely undocumented and unstructured (it didn’t even make use of functions, for crying out loud!) but which was apparently so vital to operation of the business that the only effective fix (scrapping it and starting over) was ruled out half way through development of said replacement. I was left hacking at code that, if I was a teacher, I’d fail the student for and tell them to take up flower arranging instead in an attempt to get it to do stuff that it just wasn’t sane to implement.

    Then if that wasn’t bad enough I got kicked out of IT and stuffed into basically a telesales department, left to spend the rest of my natural life trying to fix a MySql/PHP report that kept spitting out the wrong figures. Only I had no idea what the right figures were or how those figures were arrived at, and when I asked (repeatedly) for explanation I just got buried in a pile of accountant jargon that might as well have been in Mandarin Chinese for all the understanding I could glean with it. This was exasperated by being literally alone, locked off in an office on my own with one Java programmer who was also being piled high with work so we didn’t have time to talk to each other. After 3 or so months up there in that office I was ready to snap. Fortunately I found a new job and could free myself and quit, but I was so close to the point where I would have quit without a new job to go to.

    All this has taught me something that you ought to add to the list of stuff to consider in this article. Sometimes you’ll find yourself working for people who aren’t reasonable or honest or ready to listen to you. If that happens to you, get on Monster or Linkedin and look for something else. Some situations are just a lost cause.

    By the way, if you’re in the market for a hire car, don’t get one from [redacted] because their internal systems are a nightmare of Lovecraftian proportions and can’t be depended on.

  19. 32

    Great to read this!!! I feel less isolated now!! Thanks!!!

  20. 33

    Francesca Hilton

    January 14, 2012 9:49 pm

    I really liked your article.Much thanks again. Fantastic.


↑ Back to top