Cross-functional teams: changing the manager’s mindset

A lot of software development companies have the structure based on discipline – you can come across development department (which can be divided by discipline too: mobile, front-end development, etc), design, QA, etc. Sometimes some mixed disciplines teams are formed for the project, but they depend a lot on the departments and members of these teams are not full time involved into the teams and report to their “manager” – head of department, for making their own tasks. So you can see something like “Ok, project failed, but the QA department work was wonderful!” Who cares, if the project failed?

What is wrong with “departments”

When it comes to planning – we can find out, that “feature” or “project” can’t be done by one of the departments.

One clear problem with such “department” organization is the following. Just imagine that we have to develop feature A and it involves all our disciplines: analysis, design, mobile, back-end development, qa, devops. It will take not less than 2-3 sprints to launch it: the first one analytics and designers work on it (we have already made the step towards the “cross-functional” team and united them), than development team works on it, than it is tested and finally deployed. And we absolutely need a coordinator for that – smth like “Iteration manager”(I once heard this title and still wonder what these people do in the office), as we have the massive amount of the external dependencies.

When we combine everything into the cross-functional team – we enclose all these dependencies in it and don’t need any coordination. Management layer becomes much smaller. Ok, we build smaller portions in each team, but we can have multiple teams which scale great. We take a step forward more quality product with shorter turn-around of feature iterations.

So, to sum up the benefits:

• with cross functional teams we can get features faster be shortening the cycle. Mo magic, of course (I already see the PM reading this text and thinking “Oh, yes, I knew there is some way to make them 2 times faster!”)
• each team produces not an “additional item to the puzzle” which coordinator has to fit into the process and push to the other department and which brings no value itself, but small “goal”, which is valuable for the product.
• scaling great – you can just add number of teams horizontally.
• much less dependencies, which drive us crazy usually. Cross-discipline dependencies are encapsulated in the team and resolved by the team members themselves.
• we would have more engaged team, as everyone in the team works towards the same goal. There won’t be “us” and “they” more, won’t be pushing the issue from one side to the other, as they are the one team now.

Why it is so difficult to build cross-functional teams?

As usual – managers are one of the biggest problems (I knew this, I knew this!). Specially – their “resource optimization” mindset. Resources should be loaded the most optimal way, everyone should have their own task. So we have these special people, who spent their time trying to optimize the “resources utilization”. They think of the employees and their time as the items of a big puzzle, in which whey need to fill all holes with tasks. But what if we give the teams the right to organize themselves? We just give them the goal and let to reach it with the most convenient for them way.

I think that it will help a lot if managers start thinking of a teams as the smallest item in the company – like atom. So there won’t be individual management more, we’ll think about teams.

How to implement

Start with 1 or 2 teams. Show how it works to the others. I think it is the most convenient way – have a kind of “experiments lab”, try ideas with 1-2 teams and only then spread to the whole organization.

For me it was very easy pass the “have developers, QAs in one team”, the most difficulties we had with adding designers and analytics to the team – they were shared between several projects, they also supposed their work to “artistic” to be added to the engineers flow).

We once had “0,5 designer” in one team and team suffered from lack of the designer’s time. And the second team which had “0,5” of the same designer had the same issue. So we just hired one more designer, finally got rid of “we create all design – we implement all design” flow, team had a chance to speak to the designer and ask him questions at any time of the day. Yes, sometimes he had nothing to do. But we had a miracle there – he found out what to do himself! He created the library of visual elements for the product, so developers were able to find designs of any control faster, he started slicing design by himself, so the development went faster and even more – once he brought all of us pizza!.

But remember – always avoid revolutions! Have patience! And the most important – one solution does not fit all – these is no silver bullet)