Why a multi-disciplinary team isn’t just different technical roles
Multi-disciplinary teams! They have now become standard practice for organisations that want to deliver good services. The importance of having a multi-disciplinary team has even been recognised in the Australian Government’s Digital Service Standard which is used to assess Australian government digital services:
What are they though and why are they essential to making sure your teams are successful?
Commonly given reasons are to ensure that there’s a broad mix of skills and experience within the team and they are empowered to make the necessary decisions to deliver the product or service. The aim is to make the team as autonomous as possible and minimize external dependencies.
In the digital service space, many of us have been part of agile teams where business and IT people are intentionally brought together to create a more business focussed solution.
Business people and developers must work together daily throughout the project. http://agilemanifesto.org/principles.html
Even before agile methodologies were popular, most of us are familiar with identifying the different technical resources we would need to deliver a service. How many times have you been involved in conversations that are along the lines “looking at what we think we’re delivering, we’ll need a front-end dev, business analyst, database administrator, .NET coders, and a product owner”?
But how often are we having conversations about making non-technical people part of the team — lawyers, procurement experts, policy makers? We are always reliant on them but often seem to establish a supplier/customer relationship rather than collaborating together towards a common vision. This leads to us waiting on external teams that don’t have the same accountability for the outcome.
I worked on one of the first wave of transformation projects at the Digital Transformation Agency (DTA), the Australian Government’s equivalent of the UK’s Government Digital Service. We had a cross agency team made up of a range of skills and experience. We ticked all the boxes of a multi-disciplinary team and looked great on paper.
- Service designer — CHECK
- User researcher — CHECK
- Technical lead — CHECK
- An empowered and enabled Product Manager — CHECK
- …
The project had a 20 week time frame with a 5 week discovery phase which identified some areas in the starting a business space that were causing users pain and relying on them to correctly understand tax law. We had a high performing team, people from different areas of the business, engaged stakeholders but we were were spinning our wheels each sprint going back and forth with a group of tax lawyers.We kept trying to convince them that what they were suggesting wouldn’t meet our user’s needs and they kept insisting that we couldn’t simplify things too much or we could give someone the wrong advice.
Each point of view was valid, everyone had our users in mind but we couldn’t get to an outcome that would satisfy the user needs we’d identified and be technically correct.
So we changed our team. One of the technical tax experts who we’d been consulting with was brought in to be part of the team. They began to participate in usability sessions, team discussions, our agile ceremonies and then this happened. We managed to transform a 171 word summary with a reading level of Year 22 to a 91 word question with a reading level of Year 5 — making information accessible to a wider set of our users so it’s easier for them to comply with government obligations.
If we hadn’t had a tax lawyer in our team, we would have stopped at the legal suggestion or scrapped the project as it wouldn’t have delivered value to our end users.
Guidelines for creating a productive multi-disciplinary team
The players can change
At the start of the project, we tried to keep an open mind about the needs of our users. As the project progressed and we learnt more about the starting a business space, what we expected to deliver changed. That meant we had to change the makeup of our team and that was okay.
Products and services evolve and you need to allow your teams to evolve with them.
Minimise consulting, maximise collaborating
Consulting type relationships need to be minimised. By nature, a consultant will give advice but they won’t feel the same type of investment as the team accountable for the outcome. They will give advice in between their own deadlines and workload. This type of engagement needs to be reshaped to have these people collaborate rather than consult.
Collaborating is also a great way to get a shared understanding. It wasn’t until we had our lawyer in the team that we started empathising about how hard this problem space was, how careful they had to be and what had previously been seen as blocking took on a new light. This knowledge changed the way the team worked and also made us realise that empathy with our team members is just as important as empathy with our end users.
By being embedded in the team, those saying “no we can’t” start exploring “how might we?”
There’s no limit
Don’t limit your team to people who are used to being a part of these types of projects. If there’s a skill set that you have a dependency on, do everything you can to ensure it’s part of your team. For example, if you’re creating a procurement platform, bring someone with finance and procurement experience into your team. You’ll find that they will get a lot out of the process too.
To borrow (and change) a line from a certain musical I’m currently obsessed with “Multi-disciplinary teams — they get the job done” but make sure they contain the skill sets that you need, not just the ones you are familiar with.
