How to Deal With a Seismic Change in Strategy

Problem

My department was organized across geographies and parts of the journey of transportation. We had a team in North America focused on the North American transportation network and a team in Berlin, Germany, focused on the EU and UK transportation network. Within these two, we had teams that were working on the first, middle, and last-mile part of the journey. The teams were relatively independent and each was looking at their section of the problem space. Coming into 2020, our leadership team decided to eliminate the organizational structure by geography and miles. They decided to have one transportation team for both North America and Europe and instead of being organized by miles, to organize teams by functions (for example, Planning, Drivers, or Warehousing Technology). However, not only did the leadership team announce this seismic change in strategy, but they also introduced an initiative to revamp our entire transportation network by the peak holiday season of 2020. My fellow leaders and I were left to figure out how we could respond to all these unfolding challenges.

Actions taken

This significant strategic change was initiated by a series of reorgs that had to be executed at full tilt.

Reorg One

There was a team focused on middle-mile warehousing technology for North America, and another one focused on last-mile warehousing technology also for North America. Furthermore, there was a team in Europe responsible for warehouse technology, and we had to figure out how to consolidate all of these. It was decided that the team in Europe would be responsible for global warehousing technology that left us with extra 12 engineers here in North America. I had to find an adequate engagement for them while also managing through the transition.

Reorg Two

The second reorg was a bit more subtle since we were not restructuring teams but changing their focus and ownership. They had to change their roadmaps to incorporate the new global strategy that was disruptive and felt disempowering. Their past effort of developing these roadmaps was suddenly overwritten by leadership.

A month into the reorgs, the Covid-19 pandemic hit, and all of a sudden we were thrust into working remotely without having a solid plan for executing against the soon-approaching deadline. In other, more regular, circumstances, we would all come together for design sprints dissecting what we would try to achieve and how. Because we were all thrown remote unexpectedly, this turned out to be a communication challenge as well.

Finally, the plan itself was rather aggressive. It implied rebuilding top-to-bottom everything about our system and attempting to roll that out within nine months.

Reorgs -- What to do

We had to be fully transparent to the team involved. I brought the team together and shared with them what was happening. It was important to impart to the team Why this was happening, Why it mattered, Why this is the right thing to do for both the business and the team and help them get bought into that.

Also, we had to make sure that we were able to bridge the gap between where we were and where we would like to get. That meant doing two things. First off, we had to ensure the transition of ownership of what the team was building to the team in Europe. That included compiling a list of all the things that this team owned and ensuring a smooth transfer of ownership over to the other team while maintaining continuity of service for our users.

We also had to continue running a legacy system and a new system in parallel for at least some time. Therefore, we needed to build some type of bridge solution that would allow us to operate using both of those in parallel. To do so, I repurposed the warehousing technology team to build this bridge-layer solution that I called the transportation interface. I wrote up a team charter, set prioritization for the team and got them bought into it. That went well, the team was excited about new opportunities but I had to shrink the team a bit. I found other teams within my department that had a strong need for engineers and I was able to identify engineers that I could move over without sacrificing what we needed to do on this interface.

As for the other reorg, revisiting roadmaps was done on a case by case basis. I would sit with each team and discuss how these changes impacted their existing roadmap, how we could leverage what they had already done, how they should proceed with the planning, etc. Since they already completed most of their planning, we looked at their objectives with an intent to make them global instead of having them be focused on North America. That required a lot of talking with our European partners and learning about things they were previously solely responsible for and knowledgeable about. We established a close relationship with people within our company that we never worked closely with before and better understood their problem space. This intensive exchange allowed us to craft roadmaps that were encompassing of global technology and allowed us to develop a holistic approach to the problem.

Changing the strategy
Considering the significance of the announced change, we made sure to implement our activities without boiling the ocean. We had to rebuild our entire technology stack and re-architect everything in an exceedingly short amount of time. Also, we had to be iterative and break off work into small pieces. The bridge solution allowed us to run legacy and new in parallel and launch a single warehouse. Launching warehouse technology in our pilot facility helped us learn what we needed to learn before bringing it to the rest of the network.

That, too, enabled us to be methodical and roll it out over time since we would have the bridge solution in place to facilitate the change. We also had to bring together senior engineers and leads from all groups to look at the architecture and the architectural vision as a whole and provide feedback. That was something we tried to do early on and then continuously as our vision evolved.

Lessons learned

• Leverage positive momentum. While we were trying to figure out how to execute the new strategy, we kept working and adapting to the change in the roadmap. We found some vital pieces that we could include in the new roadmap. For example, one of my teams was focused on building a platform for managing truckloads and we were able to use that platform and make it central to some of our new system designs. That gave us a real leg up and allowed us to build on top of the already existing framework.
• Simplify the scope wherever possible. We wouldn't have been able to deliver if we hadn't cut some things down. We could only complete scaled-down versions of the final solution -- it would allow us to test our hypotheses and deliver something tangible instead of looking two years ahead.
• The Covid-19 pandemic made us suddenly transition to working remotely and we were not entirely prepared for that. We should have cleared everyone's schedule, done a design sprint and gotten everybody together upfront to align on things before going forward. Instead, we ended up having ad hoc 30/60/90 minutes calls over several months to get aligned and figure out how we would fit all the pieces together. In hindsight, I wish I had spent more time up front doing the design sprint.
• Make sure that the team feels bought into the changes and understands the Why. By no means should the team feel ordered around for no good reason.