3 simple steps to improving your team’s Cross-Functional Dysfunction

Tips to removing fundamental challenges that most Agile Product, Design, and Engineering teams face today.

Every cross-functional team has experienced disfunction at one point or another. One person might think someone is a bad communicator while someone else feels like the entire project has no focus. Maybe its the case of another person doing more than their fair share of the workload because their teammate is spending too much time looking at one bit of functionality. It could also be the difficult issue of a teammate being dreadfully inexperienced or just plain unqualified. However, these are just symptoms of a dysfunctional team––but not always the source of the problem.

However, let’s put the HR issues aside and focus on some insights that we believe will improve, from our experience, the overall discourse and functionality of a product team.

1. At the Kick-off meeting, introduce or remind team members of ‘who’ is serving ‘what’ role on the specific project at hand. Consider having a mid-term recap.

Just because most of the members on the team have worked together on former projects, don’t assume everyone is clear on each others roles or responsibilities for a new project. If a new team member is added, make sure they are in the loop by taking the extra time to introduce them to everyone and the team role each person serves. Don’t hold back on explaining how each individual serves as a sum of the greater whole. This also helps break down assumptions of what one person might think another member’s role is supposed to be, or like in my most recent experience, the new guy who joins the team and tries to take over the scrum meetings.

I know how basic this sounds! I’m sure everyone is reading this thinking ‘Duh, everyone does this at their kickoff meeting.’ But in reality, when organizations are on long term projects and bring new people into the mix, they forget that there is always someone who isn’t quite up to speed. This leads us directly to tip #2.

2. Make sure the team has a collective understanding of the Product Roadmap–where is the product now and where does it need to be?

I can’t tell you how many times a developer has told me they were frustrated with a project because features were added mid-stream and they felt like they were never reaching the end goal. What’s worse is how many times I have worked with developers building only one small portion of a product but not fully understanding how their feature fits into the larger scheme of things. This is especially problematic when new resources are added to the team.

I bet you have had a similar situation if you have been working on product development long enough. It’s way to easy to get all Agile and Scrummy with our favorite tools like Jira and Trello. Sure, we feel all organized and chummy because our backlog is groomed and each sprint we check off the list of stories or tasks. Yet each week the bug list and backlog grows with new tasks because features were not fully flushed out in the previous sprint planning session. This backwards momentum can result in the team feeling like progress is not being made and often times, lead to the blame game–especially of the other disciplines.

When only the leads of the triad (Product, Design, & Engineering) attend sprint planning sessions, specs may have not always been reviewed ahead of time. Feature details are skated over due to the short duration of the meeting. When the role of a lead intrinsically requires management of so many moving parts, significant details can fall through the cracks. That’s where you need to rely on your other triad team members to fill in the gaps.

When a team collectively understands the business goals on the Product Roadmap, the milestones of feature roll-out, and the details of feature functionality they should be able to anticipate and communicate the necessary tasks or sub-tasks required for each sprint. This also enables each team member to pull from their respective expertise and present the challenges and solutions for each feature requirement. This process only works if the entire team is informed and aligned.

Which leads me to tip #3 about communication.

3. Communication is not only important for alignment of your team but more importantly for the continuity within the entire organization (of course, on a need-to-know basis.)

It happens all too often where a product team of people are working on a major release, all toward the same goal yet none of them know what the others are doing. Let’s say it was a company’s first release of Android and there were nine customized apps on the OS. This means that several UI designers own each app and are working with several different dev teams. One designer in one app has a ubiquitous icon in one specific location. Another designer places it somewhere else. You get the idea––there’s a continuity problem between the two apps and a communication between two designers, not to mention the two dev teams who probably didn’t notice the issue because they are not designers.

Now moving up the food chain, let’s say the product team is aligned and has a vision for their product, but maybe the marketing team has other ideas. The product release is eminent with the consumer website and customer portal are underway. You’d think that there would be a cross-functional meeting between teams to address these sorts of issues, but there isn’t. So it’s up to someone who cares enough to work a little harder to make sure that the proper leads talk so continuity can reign.

A product launch of this scale already has the threat of scrutiny from the masses. Yet the risk of not having your ‘ducks in a row’ would be more embarrassing, and frankly for a tech company of this size, it’s outright negligent to not have cross-functional meetings to address and resolve these kinds of issues. More importantly, the communication between different groups within a large organization is just plain smart.

Understandably so, companies like Apple might struggle with being too transparent across their business groups and product teams for obvious reasons. We get that level of sensitivity when it comes to being on a need-to-know basis. However, what shocks us is how many companies don’t realize their company is suffering and in some cases hemorrhaging staff and morale because of the ‘them’ vs ‘us’ leadership/team mentality of not communicating together, even if only peripherally.

Cross-functional meetings within a large or small company are crucial to the success of your company. These are the ‘down in the trenches’ teams that surface up for air and maybe even a reality check if they are out of sync with other groups. Town Hall meetings from the CEO are not the same thing.

At the end of the day, each company has their corporate culture and processes for how they get work done. It is our experience that most companies seem to suffer from a bit of each of these cross-functional challenges. The reality of these tips is that they are not hard steps to implement. In fact, they should be as normal as weekly check-ins and scrum meetings.

One thing is for sure–these three steps can alleviate assumptions and create the potential for more inter and extra-team comradery. Yeah for the A-team!

–Keara Fallon-Mulcahy