Why Truly Multidisciplinary Teams Can Lead to Building Better Products
Every discipline needs a seat at the table
By Adam Talcott, Software Engineering Manager, YML
Imagine yourself as a software architect or tech lead, and a project manager brings you in to a new software project.
She describes the client and the problem they want to solve, and it definitely seems to be an interesting project. It’s for an exciting brand in a very interesting space, and it would likely leverage some exciting technology.
You’re looking forward to being part of the team which will bring it to life.
“Cool!” you tell the PM. “Let’s get started. When’s the kick-off meeting? It will be great to meet with strategy, design and the client to start talking about what we want to do here.”
“Well,” she replies. “That’s already happened. We kicked things off six weeks ago. We’ve already identified what the product needs to do. We have some designs we’ve been testing with users, and we’re just about ready to hand the finished designs over to your engineering team so we can deliver an MVP in two months.”
You’re incredulous, but you’ve unfortunately seen this before. You sigh. “Okay. Tell me more about what this does and then show me the designs.”
The PM fills you in on more details, and the solution sounds good to you. But they’re talking about leveraging some immature technologies that you haven’t found to be quite yet ready for primetime.
The designs look good, but there are some interactions which aren’t the easiest to pull off on the targeted platform, and you’ll have to collaborate with the designers.
Also, there is that one screen which seems to need a lot of data. These issues will have to be addressed, and that’s going to mean more design time, more back and forth with the client and therefore an unhappy client (“Why didn’t you plan for these things earlier?”). You see missed deadlines and unfulfilled promises ahead.
Couldn’t we have avoided this?
Fortunately, the answer is yes, but more often than not we don’t do what’s necessary and technology projects end up in this situation.
Creating a product is a team effort, and every discipline has a role to play, some of which are overlapping to some extent, but you need to have every discipline represented in the room throughout the process to develop a robust solution on time and on budget.
Every discipline needs a seat at the table.
The example above is written from the perspective of a software architect or a tech lead, but a similar story could have been written from the perspective of a creative director or a lead designer. Imagine a project in which designers don’t have an opportunity to review the finished product and provide feedback to make sure it works as well as it should:
What do I hear the designers out there saying? That also happens more often than you would like? How did I know you would say that?
So every discipline needs a seat at the table, even before or after that discipline’s primary phase is underway.
Consider the following diagram which shows how a team’s involvement varies over time depending upon the process’ current phase (note that project managers are not included here as they are, by definition, already included throughout these phases of the project lifecycle):
In a sense, one can compare the approach outlined here with the practices associated with DevOps.
Just as DevOps is focusing on better collaboration between disciplines (software development and operations), the inclusion of multidisciplinary teams across the entire product-development timeline is intended to improve collaboration across the disciplines of strategy, design and engineering and improve project outcomes.
Most teams have at least one team member on the project throughout each phase, with the number of team members varying over time, and obviously peaking when their phase is the primary one.
The number of strategists is highest during the strategy phase, the number of designers is highest during the design phase and the number of engineers is highest during the development phase, of course, but there are representatives from each discipline present and involved throughout.
Designers are still involved after the “design” phase is done, just as engineers are involved before “development” officially kicks off.
What is such a truly multidisciplinary team able to achieve?
Engineers
When engineering has a seat at the table from even the earliest, business-development-focused stages, the entire process can be grounded and inspired by what technology can do.
Other team members may have an understanding of the technologies in question, but members of the engineering team will bring a different level of understanding, particularly if they have previously built something with the same or related technology.
Designers
When designers are actively engaged during the development phase of a project, they can help to ensure that the designs delivered by the engineering team are what were intended and that any necessary tradeoffs are approached in the best possible way.
It’s obviously also engineering’s responsibility to deliver the required design and user experience, just as it’s the responsibility of the design and strategy teams to understand technology sufficiently well to have a broad sense of capabilities, but it is the design team’s responsibility to ensure that the final product delivers the experience they intended.
Everyone is invested in making this product the best it can be.
In this way, all disciplines are committed to collaborating with each other to maximize their contributions and help the product have the greatest impact. Everyone is invested in making this product the best it can be.
Furthermore, each discipline becomes more skilled with the other disciplines, upleveling the capabilities of the entire team. They’re by no means experts, but other disciplines are less of a mystery.
For example, hearing an engineer ask about error states may prompt a designer to think about error conditions earlier on in the design process and develop a more modular approach to design which makes it easier to incorporate loading, error and empty responses. In addition, hearing a designer question the spacing between elements or the fluidity of an animation will prompt a developer to spend more time on making sure these nuances are as accurate and as solidly built as they should be.
It also helps us communicate better with each other as we have more practice speaking with individuals who approach problems from a different perspective or have a different skill set.
As the old adage goes, before you judge someone else, be sure to walk a mile in their shoes.
What better way to have empathy for what others are facing than to be confronted with the problems they have to solve and the language they use to talk about and solve those problems?
But what do other voices have to say on this topic?
In an effort to practice what I preach, I asked representatives from several other disciplines at YML to contribute to this article and share their thoughts on the benefits of multidisciplinary teams.
Marcela Lay, Head of YML’s Atlanta Office and VP, Client Strategy:
“When we include all disciplines to collaborate from day one, we ensure coverage on different vantage points on the challenges we are trying to solve for our clients.
It also provides visibility into various positive and negative ways in which decisions impact each discipline, enabling the right collaboration when defining the best solution.”
Ryan Spencer, Creative Director in YML’s Redwood City:
“Often times developers are seen as the ‘magicians’ who are responsible for turning design tasks or solutions into code. In my experience I’ve found that this perception to be misleading and not an accurate representation of their actual skills.
Developers can be the most creative people in the room, because solving problems in creative ways is what they’re driven to do — it is their passion. And problems always have constraints, whether it’s time, budget, or resources.
Developers are first and foremost problem solvers who are the best at breaking down and solving problems under a set of constraints.
They also provide a different perspective on solving the problem better or faster.
An example might be ‘What if this API takes a few seconds to display information? Can we instead load the info in a different way?’ For this reason, it’s incredibly important to create a robust design and developer QA process where the two disciplines work together to push and perfect the final product.
The goal is to make sure the product doesn’t just look perfect, but also feels fluid given real-world data and constraints.”
Stephanie Wiseman, VP of Business Development at YML :
“We constantly remind ourselves that good ideas can come from anywhere. Interns, junior designers or our culture team.
Having every discipline — especially technology and engineering — involved from day one ensures that we’re pulling from our collective experience and creating truly innovative and customer-centric solutions.”
Patricia Alonzo, Senior Resourcing Manager at YML:
“Having a representative from each discipline as projects kickoff is integral to catching potential issues early in the process. Especially as it pertains to resourcing.
While something might have sounded feasible during the project estimation phase, it’s during kickoff exercises when the team may realize that the staffing plan isn’t quite right.
Getting ahead of this allows for enough runway to add the right resources to the project.”
—
The benefits of a multidisciplinary team are clear, but this doesn’t mean we can take a shortcut and keep our teams maximally staffed throughout their lifecycle. That’s a waste of resources and typically just not possible given the amount of work we ask our team members to complete.
Furthermore, given that communication is one of the more complicated things we do in our daily work, we want the team to be small and nimble in order to reduce the complexity of communication.
As a result, the representation from each discipline will inherently vary over time.
In conclusion
So now you know how we like to approach the projects on which we partner with clients here at YML.
It’s not always easy to get this approach right, and there will be some growing pains as you start to adopt this approach, but when it works, the results are worth the effort.
I like to think of such a truly multidisciplinary team as a choir accompanied by an orchestra: there’s nothing as amazing as having all those instruments and voices playing and singing together, supporting each other and making the whole sound better than the sum of its individual parts.
—
About the Author
Adam Talcott has more than 20 years of experience developing digital technologies ranging from microprocessors to mobile apps.
He is focused on bringing great customer experiences to life and partners with clients to see projects from inception to deployment through strategy, design, and development.
He has worked closely with such clients as Universal Music Group, PayPal, State Farm, and Dell EMC.
—
Originally published at YML — Why Truly Multidisciplinary Teams Can Lead to Building Better Products
