Silos

What is wrong with combining roles? Business Analyst / Tester? Tester / Developer? Designer / Front-end developer? Project manager / Product manager?

The rant

I dislike siloing. Siloing is when two or more combinable roles are split apart across several people so that each person has their own little niche. Instead of hiring one person with a broad skillset, two or more people with narrow skillsets are hired instead. And then all of these people are expected to function collaboratively. So for a task that could take one person a small amount of time, instead a communication overhead is created and many meetings ensue. Time is wasted, miscommunications happen. Mistakes are made, corrections are made.

In many cases, when people are siloed they tend to only take responsibility for tasks that fit within their own predefined roles. For example, developers won’t test the software because that is the test team’s job. Testers won’t update the requirements documentation because that is a business analyst’s job. Testers won’t set up a virtual machine because that is a system administrator’s job. So tickets get assigned, bucks get passed, time gets wasted. When something goes wrong, the first thing to do is assign blame.

The recovery

Where I work, we have the following roles: Designer, Developer, Tester, Product Manager. At first glance, it seems as if there are a few roles missing from traditional software development teams. That’s because, if we look at the skillset of each team member, it paints a different picture.

The designers are also front-end developers.
All of the testers also have developer skills.
One of the product managers is also a designer.
One of the product managers is also a developer.
All of the team members are essentially business analysts.
All of the team members also do testing.

There is no project manager as such. The whole team is responsible for keeping the projects on track. If someone sees something that needs doing, they will generally do it if they are able.

The great thing about having a small team with multi-skilled individuals is that communication becomes much easier. Instead of having to set up a meeting with four or more people to discuss the translation of requirements to design to implementation, this may only involve two people. In fact, we don’t have many meetings at all. We built our first meeting room two weeks ago and we have yet to use it.

Because most team members have developer skills, it makes it easier for everyone to understand each other even when the talk gets very technical.

The recognition

Of course what works for each organization is, as always, dependant on context. And it is difficult to find and hire good people with such varied skillsets. But I personally believe that siloing leads to badness and there is a much better way.

9 thoughts on “Silos

  1. Hi Trish,

    I did some work for a company where the support role was combined with the tester role. In some ways, it worked very well, as these people had some good domain knowledge.

    Testing often had to be interrupted and stalled because of support issues. However I guess as long as that is taken into account when estimating etc.

    I think sometimes it can be tough on the person if they have two different managers thinking that their specific task is of the utmost priority.

    So summary, yes it can work, but be prepared for conflict.

  2. Nice post Trish :)

    At ThoughtWorks, we have a mantra of being generalists, we can each help each other.
    As a tester though, I believe it goes even further of that- the very role of a tester is fairly flexible depending on what the challenge is.
    For example- you’re trying to test a banking interface interaction.
    You could go learn the banking rules, but you could also go find the business’s banker- and ask him to test it for you- and let you know if it is meeting the specifications and laws that he knows.
    As a tester, I find at times my role is part “Do’er” part “Coordinator”.

    On some projects, especially during iteration 0 where there is nothing ready to test, I’ve been known to pair with devs doing production and infrastructure code, my devs often pair with me when I write automation frameworks, I pair with my ba’s and help them with their stories. This is all business as usual in my job.
    Seperate the role from the person, and great things happen.

  3. What I sometimes find is that people switch their role several times a day/an hour/ a second/a sentence. Whatever they say also doesn’t have a stable interpretation through time.

    Whatever they say has a different weight and meaning depending on their role. It also happens that a TA said X and later on the same person interpreting having said X as if he/she had said it as a BA. That causes heaps of havoc and uncertainty. I’ve gone through days where I asked people “What role are you in, when you say that?” every 20 seconds.

    People don’t tend to say me-BA or me-TA or me-PM says bla-bla. But that is exactly the rigor you need when one person with multiple roles says something. That’s where it gets difficult. Human nature is in the way (and the simplification aspect of Agile). The easy way to solve that is to have one role per person. It’s just a “bit” more expensive.

    And what I don’t mean is what Dean is describing above.

    My example in “Dean speak” would be that the business user that is helping testing is doing so as a tester. So whatever he says in that role has the “weight” of what a tester would say. But say the same guy is also the main stakeholder/product owner. If he finds a bug and communicates the defect without saying he is a tester it might have a completely different effect on people listening.

    And also the role of the audience.

    I have things I discuss with a developer that should not be privvy in the same form to a PM because it would cause effects I wouldn’t want. If that person is one and the same I do have a problem. Oh and…. don’t say such a situation doesn’t happen in real life. ;-)

    I’m not against multiple roles or helping out but I am very clear on the rigor that needs to go with doing that. Without that and the awareness around the added risks to the project I wouldn’t advise doing it (on purpose).

  4. It is a nice post Trish and smaller teams may be able to work in this manner. Above all, if the business is getting ROI, this working can be enjoyed :)
    But in a longer run what I have seen is that there are conflicts that start coming up due to various reasons, like role not very clearly defined, individual egos etc., this kind of working does not work (and as you also mentioned it becomes context driven then)

  5. I have seen this happen especially in larger companies with enough funds and positions open. Siloing invariably seems to be lesser in smaller companies and start ups more due to budget constraints rather than anything else. I guess larger companies especially service companies need to have certain head count to show to their clients to get a project or even maintain their reputation. Its altogether a different matter that some of these resources work in more than one project and for more than one client.
    Still i think its important that people with wide range of skills are recruited and more importantly utilized properly for their skills. How often do we hear people saying “i’m tired of doing the same job”…

  6. So the opposite can also happen. On our team upper management has thrown several different groups under the same set of middle managers. Then they ask “Is there silioing?” Of course there is we’re not even realted teams. so then middle management spins lots of cycles trying to get rid of the silios which causes everyone to be just annoyed that they now have to pay attention to products that aren’t really related.

    It’s like one team designs, builds, and tests toliets, while the other team designs, builds, and tests waffles. NO THEY DON’T GO TOGETHER!!!

    But yes, silioing of disciplines is bad (our devs also point out testing issues, testers make dev suggestions, everyone has input on the design, etc).

  7. I think that all the good testers are generalists, they sort of have to be. Part BA to fix requirements, part Architect to ensure things are designed right, part UI developer to understand how CSS bugs are caused, coder to write automation and of course tester.

    The danger with being a good generalist is that you don’t specialise you may not focus on improving core skills, or you may not be able to focus time where it is needed.

    The worst scenario is that you have a department of silos with walls between them and just start throwing things over the wall.

    In the end, I think that balance is the key.

    Bruce

Comments are closed.