You – dear reader – have an awesome job: you are responsible for managing teams and delivering results. It sometimes looks so perfect from the outside, that an accurate assessment on the inside hits you like a cannon ball: things aren’t going ok with the teams and the expected results are not there. If you’ve seen this before, then this article is for you.

We all love to be part of a team. We love the feeling of belonging to a group with similar interests, and we also love the feeling of accomplishment when our work, together with the other team members’ work, generates something above our capability as an individual – and we’re happy we are part of something bigger than us.  We – that is me with my colleagues – put together the parts of the puzzle, piece by piece. And we simply love doing it.

So far, it’s all good, and if we start zooming out and extending the view to the entire business unit or organization, we should see how all these larger pieces that are created by each team come into place, connecting and achieving the greater goal: the organization’s goal that’s the sum of the individual goals. Except it’s not.

We all have sometimes felt in our professional life that maybe our mission is disconnected from the organization, maybe our work is not appreciated as it should be, and maybe the team that our team should be tightly working with, in fact works against us.

When facing such situations, the teams’ morale is affected, productivity decreases, and the job satisfaction is at risk. But don’t lose faith, there are ways to get back on track, and this is where strategy comes into place.

Let me start with a personal example first.

The architect and the builder

A couple of years ago I decided to do a bold move: leave the nice sunny house on top of a green hill for an apartment back in the city. As the kids grow, it’s important to offer them the ability to become independent, while being close to family’s daily life points of interest. So, the apartment was there, the architect had a beautiful vision, and the builder was prepared to deliver it.

I thought things would go smooth as planned, until the first milestone came, and it was missed as the two parts involved – architect and builder – escalated to me that they’re not getting from each other what they needed, and it’s going to take more time than expected. I started asking questions, and realized that each one had the right expectation from the other, however neither of them did any effort to make sure the other fully understood the details of the work to be done.

And that’s where I decided I’ll be applying in my personal life the knowledge I got from my professional experience: for two or more teams to work together in an effective manner, they need to have common goals.

The implementation tactic was simple and effective: both parties would only receive their payments connected to the milestones they delivered. And it worked like a charm. Once people realize that delivering their part depends on how the other person is delivering too, a paradigm shift appears: we’re no long on separate tracks, but we’re in this together. And this is when they start being interested in the other person, when they start helping proactively the other person and clarify things so the other person understands what’s to be done. They truly start working together.

In my case it became clear that for the personal interest, each one should be investing the right amount of energy to make sure the other one will deliver smoothly, so when the milestone comes they both receive their compensation on time. And I never had to intervene again between them.

Back to corporate world,

Let’s consider a simple scenario where you have two divisions reporting to you. One is Engineering, and the other one is Sales. You have just released a new product, and you also have the previous product that’s accounting for most of your revenue.

Engineering is absolutely delighted to invest effort in the new product. It uses a Service Oriented Architecture, the back-end team is happy to expose microservices, front-end team has adopted the latest trends and it’s all new and shiny and appealing. Engineering team members feel they’re growing professionally when working on the new product, in opposition to the previous one that has some years since the last major update.

Sales however, sees things in a different perspective. They’re very familiar with the previous product that’s well known by the customers, the deals are closing easily, while the new product requires investing a fair amount of time to understand, to be able to demo and eventually sell.

Your target is a 70% vs 30% revenue balance between the existing product and the new one, and at the end of Q1 you notice an annualized 95% vs 5% proportion. You need to act quickly and change the game course as you won’t be able to achieve your annual goal. So, what do you do?

Step 1: Define the common goal

Before going further, both teams need to be aware of their expected behavior. In our case study, to simplify things, I would pass it along exactly as I’ve received it, and adjusted to each team’s specifics. While the common goal is clear – have a 70% vs 30% revenue on old vs new, the team specific goal needs to be tailored for each of the divisions, while translated to their level of understanding and interest. While Sales is familiar with terms like leads and revenue, Engineering resonates better to terms like effort and time.

Engineering Team will know that they do need to invest 30% of their time maintaining the existing product as that’s the one generating most of the revenue.

Sales Team will know they need to increase the sales for the new product, improving quarter on quarter until reaching 30% by the end of year, for company sustainability.

Step 2: Incentivize the leaders

We have defined the goal, and now we need to make sure the managers in charge have the right incentive to steer the teams towards the desired company goals. Since we previously noticed different behavior for each team, we’ll be applying different incentives to their managers.

Engineering Manager will validate his variable pay against the KPIs that monitor the effort invested in the existing project. These KPIs can vary from velocity alone (measured by existing product story points vs total story points) or even go further and include quality and product improvements.  The tactics of implementing the goal are also different, such as rotating team members for one week per month or even fully having some engineers allocated to the old product if they’re willing to do so.

Sales Manager will validate his variable pay against the number of new product sales vs existing product, so he does have a specific incentive to invest some of the team effort in understanding and pitching the new product. The tactics of implementing this can also be different.

Conclusion

The common goal policy makes things clearer to all the parties involved: we both need to work together – as a team, even if we’re different teams with different activities – to reach our objectives.

How a group of people is organized determines the group’s culture. What we’re interested in is to have informal approaches on solving problems and bottlenecks, rather than official escalations, we want people to have a quick chat at their desk rather than submit Jira tickets, and in the end, we want collaboration and interest in getting things done, rather than strictly following processes while missing the bigger picture and company’s objectives.

In today’s complex corporate world, the processes are the one determining predictable results while offering quick feedback loops to detect and improve deviations. Let’s remember though that we’re working with human beings, and being aware of our expectations and motivated to act on these expectations is always making a difference in the results of everyone’s work. And this does have a direct impact in businesses’ bottom line.