"Almost done" is a rumbling of a disaster

::Summary::

Thanks for reading this post. I will cover:

1. Getting clarity if the team is going to deliver the commitments
2. Three simple questions you can ask as a leader to understand the status of the work
3. Actions you can take to prevent and course correct it

::Signals of disaster::

"We are almost done", I heard on the program meeting consisting of Senior Leaders and program managers. The work would be blocking five different launches, including my teams but for now, it created an inconvenience for end to end testing. Not diverting too much from the camera, I quickly dug through my inbox and checked out three last reports. With infinitesimal deviation, the signal was eerily similar. What was frightening is that the optimism radiating from a young, growing leader was contagious. Leadership was nodding, someone started to scratch the surface and asking pointed questions but the allocated time for that team ran out and attention diverted to more pressing topics. The meeting ended but I was still pensive.

:: Twinge ::

Any large program is a thorny road filled with fire, pit stops for re-work, back routes and more scope that any human organisation can handle. There are top priorities for each and every team that S turns manager's day into a conveyor belt of plannings, dailies, check-ins, alignment calls and ever-escaping Slack madness. There is not much work you can do except if you carve it intentionally and defend it with the gusto. My teams were doing great, we just hired few people to run critical new scope and they were killing it. I rumbled through the backlogs for any signals, sent few Slacks about the details I needed for the alignment meetings later and stared at the open tabs I did not dismiss. Something was not sitting right. I knew it'd become a massive black hole screeching majority of the program to a costly halt. My weekly meeting with executives would be 2 days later and I wanted to know more about the work.

:: Do you know what the work is? ::

I started my investigation looking at the most obvious place - the backlog. We introduced three week cadence instead of six, goal setting for every cycle and the teams were re-working the backlogs. The backlog was ruffled and took me a while to connect the dots. "It is still being worked on" was a common reply from the leaders as they went through the change. What did not sit right is that the state should be transitive and with that team it seemed permanent. It took some time to connect the dots and I praised myself on spending significant amount of time with my teams to align on the direction, goals, dependencies and expectations. After spending a couple of hours and Slack checks, it started to make sense but only just. I did not see the integration changes we would need in few months. I did not see a team quality plan. Cut-over plan was still in the heads of people whose calendars did not see the strip of focus. I had visibility into entire program not the little details but I learnt to trust my twinge and it pinged way above the threshold. I added a mental note to keep an eye on backlog structure and its evolution. What was clear though is that the team did not know what the work is.

::Do we connect the goals forward?::

I am a stickler to outcomes. Not the goals for the sake of goals but coherent, defined direction where we must be. It brings clarity, create cohesion for the team and frees up huge chunks of time for me. Delegation becomes easier, people do not pester managers with direction every time they finish the tickets and life becomes slightly easier. You cannot check out after hand-waving the direction but outcomes grow your leaders, allows the team to focus and creates trust downward and upward. What's most critical though is that your goals should connect forward.

I will explain. Let's say a success criteria is to deploy a work load to production. Back-of-the-napkin (let's call them Tier-1 goals) goals will be:

Let's say those goals span 6 months. No sane team runs 6 months cycles in isolation. Some teams do (hey, waterfall) but I would save my sanity and would just say they never ship on time and budget. With 6 months goals and a team running 3 weeks cycles, it is a total of 8 cycles x 3 weeks. Let's unpack those 7 goals and connect them to Tier-2 goals for each cycle.

If Tier-2 goals are too big for the team to execute on, you just keep unpacking. On and on until it fits and can be executed by the team.

Mastering packing and unpacking business outcomes into technical roadmaps is one of the the most valuable time investment for leaders and their organisation to succeed.

Now, we have a Tier-1...Tier-N goals. Now, there are two questions you need to ask:

1. Can you connect what the team is doing right now to a Tier-N goal?
2. Is it the right time to do them?

If the answer is no to both - the team is in trouble. Most likely, they do not know what the work is, coming up with busywork or doing nice but not critical work. It means you need to have a conversation. That bucket of nice work can be exciting (and you, occasionally, need exciting work to keep your team cohesive, growing and happy) but you may also, happily, draft the communication memo with new dates for the leadership.

The team I mentioned was 2 x No to those questions. They were 110% busy, merrilly executing on the wrong work, creating more scope in the same bucket and adding people to the dumpster fire.

::Are our dependencies aligned and committed to?::

One big bucket of challenges for any project in general and the team in particular was dependency management. Getting dependencies executed, especially in constrained teams ( Platform, Security) that do not report to you, is a very tall order. Experienced leaders start planning and getting commitments to dependent work very early. You are increasing probability of hitting the dates of your commitments if you start those conversations. In majority of cases, that's the priority #1 for the leader that who needs it. There is no single, right way to do it. It all depends on your organisation dynamics, politics, bandwidth and business priorities. You need to find a healthy boundary to start those conversations. This is a big topic, I will cover in another post. For now, I want to say that's the most common pitfall of any failed project.

It turned out nobody was talking to dependent teams, was not thinking about the dependencies. Since it was not on the radar, "almost done" transitioned to "we need another 3 months to flesh these things out".

::Key Takeaways::

1. Ask 3 questions
   1. Does the team understand what the work is?
   2. Do we connect the goals forward?
   3. Are our dependencies aligned and committed to?
2. Listen and act on your twinge
3. Help and guide your leaders connect the dots forward
4. Plan dependencies as early as possible

Until next time.