How we Structure Multiple Teams: Navigating Team Success when Working with Customer, Internal, and Competitor Teams

Posted on : 24 Apr, 10:00 AM

If you’ve been around the SDLC, you know it can be challenging to build ready-to-go teams that communicate well, work cohesively and efficiently, and stay drama-free.

You also know that if you have multiple development teams, before even connecting and integrating with other departments, it can increase a project’s susceptibility to breakdowns in workflow, communication, and camaraderie. Now add on the extra layer of the development teams being from multiple vendors and that’s even more complexity to your already intricate processes and team dynamics.

So how do you set up multi-vendor teams for success?

At Integrant, it starts with our engineers. They’re ready for anything, work toward the greater goal, and take care to understand our customers, their processes, and the ins and outs of their project. But it takes more than grit and a service-oriented attitude to overcome project challenges.

When approaching how to structure multiple teams in a single project, our processes and structure (what we like to call the “Integrant ecosystem” when combined with our teams) play a big part in contributing to easing the obstacles that inevitably come up during a software development project and especially when working with a large overall team.

Programs like our 4Plus1 Shadow Engineering and our processes and analytics platform, CodeVoyance, go a long way in safeguarding the success of your project and minimizing the stresses of developing essential software to your business.

However, the structure of our teams and how we work together with customers and other vendors is the foundation of a winning project and one of our strengths. In this article, you’ll see a culmination of lessons learned and best practices we’ve picked up in the many projects that we’ve worked on.

We’ll answer the question of how to set up multi-vendor teams for success on your project by showing you what we prioritize and how it all comes together to create customer success and satisfaction through the lens of a recent project with a 30+ person software development team.

We'll be diving into the collaborative world of Agile, the importance of team balance, a one-team mindset and culture, how we navigate communication through different time zones, and how we work with competitor teams in hopes to clearly and effectively explain our team structuring process from my insider's point of view.

Project Flower

To provide some context, our recent project is related property taxes with a local county. To maintain confidentiality, we’ll call this Project Flower.

For Project Flower, we worked with our customer’s team and an additional software development vendor to build a system that would calculate property taxes. The system needed to account for varying parameters and updates or additions to local laws while also maintaining a tracking system for all property tax payments.

Before beginning to build the system, we had to navigate how we would structure our team to fit our customer’s existing environment and get the job done effectively while working with another vendor with their own set of processes and environment to ensure project success.

1. Define and Balance Your Teams

A balanced team is an effective one. Prior to identifying your dream team, work with your vendors and identify what roles each party should be playing. Does it make sense for Business Analysts to be on your side or on the vendor side? Is that an effective specialty you have in-house? Opening up this communication flow right at the beginning will do two things to benefit your team balance:

Set a foundation of trust between your customer and your team and
Allow for a clearer understanding of what kind of assets your team is going to benefit most from and which people will be able to carry out those roles the most effectively and efficiently.

When forming multiple teams, you then need to decide which groups are going to tackle which areas of the project. In this instance, it’s crucial to ask yourself, will it be more beneficial to have everyone in these teams carry the same set of skills? For example, three teams all consisting of developers, testers, business analysts, product owners, etc. Or will it better serve the project to have each developer have different skills, and then unite as one team that consists of all the right skills?

Each project will require varying skillsets, making it necessary to continue asking these questions at the start of each team building session and sometimes even readdress these questions as your project evolves.

Pro Tip: When working in Agile environment, the idea of solid communication and understanding is highly encouraged and easily integrated; when you have a strong foundation of collaboration and inclusivity, where team members have worked well and communicated effectively together before, it is always smart to utilize that same group of people in other projects when possible.

Defined and Balanced Teams with Project Flower

For Project Flower, working with 100 people and trying to navigate how to divide up workloads and skillsets was essentially like building a mini company.

While team structuring for a project this large ideally takes about three months, defining clear roles and responsibilities slightly extended our trial-and-error period for this project.

In the end, we determined the most successful structure for the project would be to establish Product Owners from the customer on each team. Product Owners would be responsible for communication guidelines and requirements between involved parties and then removing any possible roadblocks to ensure that a clear vision remained intact throughout the project.

Establishing these product owners, and self-organized, full stack teams, afforded us the ability to then sort out clear paths for each vendor team and internal Integrant teams, which includes scrum masters, business analysts, UX designers, architects, leads, developers, and testers.

Once the needed roles and responsibilities were correctly pinpointed, assigned, and in effect, the multi-team structure became successful for Project Flower.

While each project is unique, Integrant’s Agile ecosystem allows for us to set up our ideal standards for each team-structuring timeline, then grants us the flexibility to adapt to the real-life situations and customer needs presented in each project. It is crucial to us to ensure all of our employees are ready and able to pivot around any needed changes at any time throughout a project, such as reorganizing a project's structure.

2. Maintain a One-Team Mindset and Culture

When it comes to a one-team mindset and culture, there are always multiple sides to the story. What I mean here is that you’ll have your own culture that your team already thrives in. Then there will be the culture of each vendor you partner with.

At Integrant, we know the importance of having a strong team culture to maximize effectiveness and build trust. We start internally, then work hard to integrate seamlessly with our customers’ cultures to align with their goals and standards.

While we have our own internal culture, part of building and maintaining a one-team mindset with our customers is providing the best-fit employees in terms of soft skills to contribute positively to an existing team dynamic. That’s why we ensure soft skills training is part of our engineering profiles and we ensure each engineer receives soft skills training as part of their career development plans.

In addition, we are in tune with our engineers and provide resumes that we feel will best improve and thrive in your culture. That’s another reason defining roles and responsibilities is such an important first step. It allows you to build trust and learn about your vendors’ culture and vice versa.

Our teams work hard to make sure every member feels encouraged to discuss and engage, not just within the team, but with our customers as well. They perform internal or mock interviews and presentations help present new ideas or questions that might be useful in collaborative environments later on when the team members are working one on one with customer or competitor teams.

This helps to break the barrier between engineer to customer or engineer to engineer and create a real bond between parties. Having the team be seen as people, not their work title, enforces the humanization of teams, making everything more familiar, comfortable, and authentic.

One-Team Mindset and Culture with Project Flower

In Project Flower, all management and team player dynamics from the customer, us, and competitor were very different to start. To help our internal teams understand the nuance and cultural makeups of the other teams, one thing we implemented early was travel.

At the start of the project, we had 4-8 team members onsite with our customer for 2-8-week periods to put faces to names and job titles and to become truly integrated into the team. This absorption of team dynamics and environment trickled down to our development teams in Egypt.

While we’re currently in a world where remote work reigns supreme, this face-to-face opportunity allowed us to identify missing information and misalignments in understanding quickly in order to resolve them and move forward together.

In other projects, we have implemented things like cultural exchanges to better show who we are and know where our customers and other partnered vendors are coming from.

By implementing travel early and often, this opened the door for increased trust and understanding of varying cultures—both personally and business-wise. At Integrant, we firmly believe in the use of travel to allow our teams to adapt quickly and develop a good sense of trust and familiarity with our customers.

3. Communicate Effectively and Maximize Time Zones

In order for communication to be effective, everyone needs to speak the same language. That’s why it’s important to have your team structure squared away and aligned on culture and mindset first.

This creates a starting point of understanding between the roles and responsibilities you’ve already defined and how each person and team will show up for each other.

One key factor here is to implement your Agile techniques in a way that benefits your team the most. Strategically plan sprint start and end days as well as the length of your sprints. Maybe your project cadence lends itself better to three-week sprints instead of two-week sprints. For distributed teams, is the best time to hold your stand-up in the afternoon due to time zone differences? Are you including your stand-up as part of your retro to continue to improve these daily meetings?

All of these seemingly small pieces of information can make a huge difference when working with multiple vendors, especially if they work in varying time zones.

We get it. Working across time zones can be intimidating or perceived as an inconvenience, especially if you have multiple vendors in multiple time zones! How can you be sure that your team will be there to support you when you need? Another piece of effective communication is not just knowing when your vendor teams will be available, but also predicting when you’ll need their support the most so they can be available to the best of their ability.

With distributed teams across time zones, as long as you have clearly defined processes and a solid communication process, it’s easy to pass information or tasks across distributed teams as needed. This is where you can maximize varying time zone coverages. At Integrant, our engineers’ work week starts on Sunday, so we’ve effectively gotten a jump on the week and can cover anything left over from Thursday or Friday from the week before.

Inside Scoop: At Integrant, we implement our 4Plus1 Shadow Engineering Program to every project to improve your project stability, keep your uptime at an all-time high, and make knowledge transfer ongoing and seamless.

Effective Communication and Time Zone Differences with Project Flower

At our development centers in Egypt and Jordan, our engineers’ standard work week is Sunday-Thursday. Our customers, who are all U.S.-based, work Monday-Friday. To address this, we shifted our sprints to start on Wednesdays and run for two-weeks.

Our engineers and project leaders remain on-call on Fridays and our customer and partner vendor know that we always have their back. Our stand-ups and demos are scheduled when the whole team is able to attend, even if that means the occasional “late” night for our team.

When working across multiple teams, this helps continue to progress your project further and you’ll always have great news at your Monday stand-up because progress has been made while you and your team were recharging over your weekend.

These expectations and decisions related to scheduled meeting times and availability are implemented with our customer and communicated to every engineer who joins the project to avoid confusion and reinforce that one-team mindset.

Communication layered on top of a sound structure and supportive, cohesive ecosystem allows you to not only effectively work across time zones between you and your vendors, but elevates your project’s ability to maximize them.

4. Leverage Competitor Teams

Having competing vendors on a project can be strategic and beneficial. It gives you insurance on large and small projects alike by not putting all your eggs in one vendor’s basket and provide risk management.

It also gives you additional information and inputs related to solutions, effective processes, and productivity. But these inputs can also be a double-edged sword, particularly when you don’t already have an established one-team mindset or the right structure to execute your project successfully.

Having a project with multiple vendors could mean more time spent in establishing your communal processes or assimilating with your team culture. So how do you leverage competitor teams?

Prioritize your goals as the customer and utilize the strengths of each vendor. As a custom software development company, our engineers pride themselves in the excellent solutions they realize and the hard work they put into them. We want to showcase our strengths and we know the motivation to be successful on a project. That’s why we want other vendors on our project to do the same. To use their strengths to help us be successful in turn. So that we win as one team.

Leveraging Competitor Teams with Project Flower

For Project Flower, Integrant was one of three vendors. We work with competitor teams about 90 to 95% of the time, either directly or indirectly, so how we decide to approach them is critical not just to our success, but to the success of the whole project.

We showed our value by demonstrating our strength in teamwork, transparency, and providing solutions. This determination and grit to make the project successful cohesively led our customer to trust us with onboarding another vendor team that started on the project after us.

Giving this competing vendor the same service-oriented approach that we give our customers, we were able to onboard them seamlessly and get them up and running at full capacity on the project in no-time. Our desire and commitment to provide a great onboarding experience to our fellow vendor allowed us to “click” a little faster and establish a supportive rapport we’ve been able to carry on throughout the project.

Like all of our approaches, this one can also be met with new bumps or setbacks. What we do to prepare and react to these bumps is to hold all members of all teams accountable for actions at all times, and continue to strive for open communication and collaboration down the road.

Mini-FAQ:

Q: Are there roles that should stay within one vendor and roles that can be spread across vendors? If so, which and why?

A: While it was important that the product owners for Project Flower all came directly from the customers side, one position that can be either on the customer or vendor side is the business analyst position. Our business analysts have contributed greatly to the success of our projects and the caliber of their recommendations and decision making is phenomenal.

This all circles us back to our transparency commitment and Agile ecosystem. We work to achieve mutual trust and respect between all of our teams, customers, and competitor teams and believe in a united workforce across all aspects of our company.

As a company, we pride ourselves in our ability and work toward a constant state of stability and risk management, while remaining flexible when necessary, all of which we believe we have succeeded in thanks to our Agile environment. With the combination of standards set by CodeVoyance, our 4Plus1 Shadow Engineering Program, and our self-organized software development teams, we put forward a cohesive, transparent, and trustworthy force for our customers to rely on.

When it comes to structuring multiple teams of any size, we make sure to include the collaborative measures keeping Agile methodologies at the forefront and strive to develop a foundation of trust with our customers that has allowed our average customer retention to be five years and growing.

We then infuse the areas of balance, a one-team mindset, and culture with the stability of our software development ecosystem and connect them all together to aid in the line of open communication through time zones, between us, the customer, and any competitive team.

Moving Forward with Project Flower

Project Flower is an ongoing project that is projected to span three years. Our lessons learned from previous software projects and expertise from working with large teams has allowed us to provide a strong foundation for the completion of this project that has been attempted twice before without success.