Cross-functional team, or how to not kill each other

software

Cross-functional team concept is not a new “The Proper Agile”. It’s been around for a long time, but I have realized just recently that I have had an opportunity to work in such setup. I worked in a team of software engineers, marketing experts and statisticians. We collaborated on daily basis, we had common goals, and managed to finish the work without killing each other. By no means, it wasn’t that difficult, but it wasn’t very easy either. Imagine, you’ve just finished CI scripts and you are ready to go to production on daily basis. Smile and happiness all over the place. But your colleagues don’t get it. “Why do you need it?” - they ask. Don’t you have more important tasks to do? (straight in production)

Let’s keep the sarcasm behind us. Behnam Tabrizi in his blog post 75% of Cross-Functional Teams Are Dysfunctional investigates drawbacks and issues of cross-functional teams that he captured during his research.

Nearly 75% of cross-functional teams are dysfunctional. They fail on at least three of five criteria: 1.) meeting a planned budget; 2.) staying on schedule; 3.) adhering to specifications; 4.) meeting customer expectations; and/or 5.) maintaining alignment with the company’s corporate goals.

Cross-functional teams concept is especially true and important in Data Science teams. Data Science by definition is an interdisciplinary field about scientific methods, domain and technology. The past two years I have had the pleasure of building and successfully working in such setup. Just a while ago I was planning to boast about our achievements in setting up the team of highly skilled and various individuals. My main selling point was “We did complete the job with a smile on our faces and we didn’t kill each other”. Seriously, do you call it a success? We missed schedule so badly than no one remembered the date of the first deadline. Sure, we met customer expectations, some of them. Difficult to measure it if you haven’t seen any specification.

What went wrong, is there a way to improve performance of cross-functional team? According to Benham, Portfolio Governance Team (PGT), where high-level leaders make complex decisions on the various aspects, didn’t do the right job. Benham identifies following aspects that have to be ensured in every cross-functional team:

1. End-to-end accountable leader(s)

In our case one leader was overseeing all functions and each “domain group” in the team had its representative. In case of difficult decisions PGT was deciding on next steps. I think we accomplished this subtask.

2. Every project should have clearly established goals, resources, and deadlines

Our goal was clear, people available and deadlines specified. What didn’t work? Technology. Cutting edge libraries, tools and Microsoft Azure immaturity made me nearly bald. The goals and deadlines were affected heavily by too optimistic technology evaluation.

3. Teams should have the project’s success as their main objective

Even though the team members had many responsibilities outside the project, the objective was known and agreed upon everyone. The team had full end-to-end responsibility and even small deliverables were visible to the team and outside in the organisation.

4. Every project should be constantly re-evaluated

We faced many technological issues and learned a lot about it on the way. Right now it seems that we have done a considerable progress, but the progress could have been much bigger. How? We did solution re-evaluations in the beginning, but then we pushed the accelerator to the end and took things for granted. Because so much work was put into it, how could you stop it? The show must go on.

Remarks

Cross-functional teams are great, cross-functional teams are powerful. But one of the key roles of Portfolio Governance Team (PGT) responsible for similar teams is to follow William Faulker’s advice to kill your darlings

A PGT that is not routinely canceling some projects isn’t doing it’s job.


I'm Valdas Maksimavicius. I write about data, cloud technologies and personal development. You can find more about me here.