Consulting During a Software Client’s Reorganization

My product team is a mix of Atomic and client individuals. We’ve worked in this blended manner for years. Now, our client’s business is consolidating, laying off individuals, and it could (probably will) impact our team. I’ve been through this before as a consultant, and it’s some of the hardest consulting work I’ve experienced. Ambitious goals are no match for the fear, uncertainty, doubt, and anger that plague this time. Yet, as a consultant, I’m still responsible for looking and planning ahead and keeping us focused on the right work, even during a software client’s reorganization.

Here’s what I’ve learned through these experiences.

Be empathetic.

People at risk of losing their jobs will likely feel all sorts of emotions throughout the day. This can manifest in a lack of engagement, quick retorts that are less tactful than usual, and decisions or behaviors that are uncharacteristic.

I’ve found it helpful to:

  • Go above and beyond providing valuable context to the meeting or question at hand.
  • Seek to understand why. If a decision is unusual, ask clarifying questions. If the request doesn’t make sense, have a conversation to get to the heart of the concern.
  • Be flexible and adapt, move meetings if someone needs time.

Keep it simple.

A preoccupied mind makes it 10 times harder to do the mental gymnastics that are often required with our work. Thinking of edge cases, trade-offs, or long-term impacts can get to be too much.

Sometimes the easiest path through is the best one, right now. Teams can also make things easier by distilling down options to two, or better yet, one great recommendation to unblock complex questions.

Define your indicators.

Every project has risks, and during a software client’s reorganization, those risks increase. The key is to focus on what the team can control, identify the indicators, the canaries, that give signals as to when those risks might be coming true.

I’ve considered signals around:

  • If our throughput decreases, when will I know that a new plan or strategy is needed?
  • What will traditional agile metrics show about the team, the work, the pipeline, during this phase?
  • How might we know if leadership sees our project as core/important to the business post re-org?

Remember this, too, shall pass.

A software client’s reorganization can take a long time. It could be months if not more than a year from the time of the announcement to when the dust has settled. Most of us aren’t wired for this level of uncertainty.

I’ve found it helpful to “surf with bent knees” (as our own Elaine Ezekiel would say), meaning you should make some plans, but not too many. Things will change. As new information emerges, we will have new options and opportunities to be successful.


More than anything, what I’ve learned is to engage humbly, lift each other up, be reasonably ambitious, and support everyone in taking the time to restore so we can return to the good work that’s ahead.