Tell me about a time when you had to change priorities. How did you gain your team’s buy-in and keep them motivated?

Keeping the team motivated when priorities change

I try to help the team understand why the work matters, give them room to raise concerns, and recognise their contribution. This becomes especially important when we ask them to stop something they are excited about and move to work that feels repetitive.

Let me share an example where we had to pause a product we were building and move the team to an urgent customer onboarding.

Situation: a product the team wanted to finish

At Joveo, one of my teams handled the publisher domain. Publishers are job sites like LinkedIn, Indeed, and Monster, and there are thousands of others.

We send our clients' job ads to these publishers to get the best return for the client and margin for Joveo. We create XML feeds for each client and publisher combination. Each publisher accepts a particular format. If we send the wrong format, they stop pulling the jobs, which means lost traffic and revenue opportunities.

At that time, the XML creation was handled directly in our Scala code. We had publisher-specific files that took job objects and created the required XML.

This legacy approach had several problems:

• Every new publisher or format change needed a code change and deployment.
• Client-specific customisations added more conditions and workarounds.
• A change could break feed creation for other clients and publishers.
• The code had become difficult to navigate and maintain.
• Customer requests kept pulling engineers away from their planned work. The lead time for a request was around two weeks.

So this was both engineering debt and a product limitation.

We started building a feature that would let non-engineering users, like the customer-success team, configure publisher schemas without writing code. It would support both publisher-level and client-specific formats.

Three developers were working on it. We had finished the design and planning and had started implementation. The team was excited because this would remove a lot of the repetitive work they were doing.

At the same time, our business team was trying to enter the European market and was working on onboarding Adecco, a large staffing agency with a substantial client base in Europe. Several teams were involved.

Adecco used publishers that were different from those we supported in the US. To make the onboarding work, we needed to integrate around 40 publishers across Europe.

Task: change priorities without losing the team’s buy-in

Using our existing approach, this meant roughly 40 new Scala files, with additional conditions for customisations. It was a large amount of manual work.

When I discussed this with the team, there was resistance. Their argument was reasonable:

• We expected to finish the new product in about a month.
• Manually integrating 40 publishers would also take about a month.
• Why not use the deadline to finish the product and then onboard the publishers through it? That would also give the team more motivation to finish the product sooner.

But after talking to Business, I understood that the deal was not yet secure. Adecco wanted to try our system first and would move its clients over gradually if the trial went well. They had a hard deadline and needed integration to start immediately.

My task was to get Engineering and Product aligned on pausing the product and taking up the onboarding, while taking the team's concerns seriously. The manual work was exactly the kind of work they were trying to remove with the new product. I needed to explain why doing it now was worth delaying that product.

What I did

1. Bring the business context to the team

I brought Engineering and Product together and explained the opportunity.

• Adecco represented a potential multi-million-dollar business.
• It was also a strategic way into the European market.
• The publishers we integrated would be useful for other European customers too. This work would not be limited to one client.

Business joined the discussion and explained the revenue potential and why the onboarding needed to take priority.

2. Take the team’s alternative seriously

The team had a valid point. They were suggesting a way to solve the customer need and remove the manual work at the same time. The question was whether the new product could actually support this onboarding in time.

Our product had been designed around the publishers we already knew. We had not yet covered all the requirements of European publishers. So finishing the current implementation in a month did not mean it would be ready to onboard all 40 publishers. That made the two one-month estimates difficult to compare: the product still had requirements we had not planned for, and Adecco needed integrations to start immediately.

The manual integrations would also help us understand those requirements. We could use that learning to update the product design. The product was still needed; the onboarding gave us a better understanding of what it had to support. This connected the immediate work to the product the team still wanted to build.

3. Help the team see the value of the work

I also shared a similar experience of my own. I had once stopped work on an OLAP database project that I found very interesting to build a feature needed for Wells Fargo's onboarding. Wells Fargo was a US retail bank and Joveo's biggest revenue-generating client.

We built that feature in ten days. It became an important part of converting new business, and I received recognition for the contribution.

I used that example to explain why work that seems less interesting technically can still have a large impact. I wanted the team to see what their contribution would enable.

With the business context and the discussion about the product gaps, the team became more positive about the change and took on the onboarding work.

Result

The same team worked on Adecco onboarding for the next four weeks and completed all the publisher schemas.

Adecco was onboarded successfully. As promised, the team received awards and rewards for the effort.

The integrations also gave us an opportunity to learn about European publisher requirements. We could take that learning back into the product design. The immediate result in this example was the successful onboarding.

What I learned

One thing I could have done earlier was involve the European sales and publisher operations teams during product discovery. Their input could have helped us identify the missing requirements before implementation.

Looking back, explaining the business impact was only one part of handling the change. I would also make the plan for the paused product explicit: what was moving out, how the onboarding work fitted within the team’s capacity, and when we would review the product work again. That would help the team see what the change meant for their existing commitments.

I would also check in with the team during those weeks to understand whether the repetitive work was becoming frustrating or the workload was too much. Completing the work tells me we delivered; it does not tell me how everyone felt about the change. Recognition matters, but I still need to listen to concerns and manage the workload.