The Deets

You’re managing a project that’s a mere two weeks from its long-awaited (and reported) deployment date. The sh*t hits the fan. The vendor is late, the enterprise infrastructure has a hidden “gotcha” that doesn’t play nice with the code, the team has discovered a major bug, and InfoSec is requesting a brand new scan. There’s no way you’re going to make that date. What happens now?

For most in management, this is when you set up a daily full-team status meeting. You want visibility and daily discussions on where things stand. You draw up a complete list of the known issues, soliciting a brain dump from everyone involved. You set up a separate daily status meeting with the vendor, burning through your support hours. There are thirty people on the management call, the most expensive meeting of the day, but you need to show that you’re taking things seriously. Every day you methodically talk through the status of the ever-changing list of issues, valiantly trying to keep things clear and accurate for an audience that includes on-the-ground technical personnel and concerned VPs.

What’s wrong with this picture?

The Problem with “Tracking Issue Status”

All of the steps taken above come from a genuine desire to try to meet that impossible date. The problem is that this “lock-down-and-report-out” approach will ultimately hinder the team’s ability to deliver and management’s ability to focus on what’s truly important.

By holding that status call we are choosing to highlight the issues the team is facing rather than the goals they are trying to accomplish. The revolving issues list that takes up so much valuable time is not the most important thing for management to track. As anyone who has worked with a technical team knows, the team will face all kinds of issues on a daily basis. You can argue that that is the heart of their jobs: to combat and resolve issues that come up while trying to make progress on a plan. This is their bread and butter, business-as-usual work, and most of the time what they are tackling on a daily basis is no one else’s business but the team’s. This is because it does not benefit management to be involved in the day-to-day, particularly as you go up the chain. If management is involved in the minutiae, who is steering the big-picture, strategic vision?

The daily issues list is both too small and specific to be discussed at a larger group meeting and also too variable - the smaller and more specific the content, the more frequently it needs to be discussed. This is why that’s a a job for the team itself. For management who are working with multiple teams, knowing what specific part of the code a team is working with today versus yesterday is a waste of their time. Add to that the fact that most management is not close enough to the work to know what it represents and you’ve got a recipe for misunderstandings, miscommunications, and missed opportunities to perform more meaningful work.

The Benefits of “Tracking the Goals”

So if management should not be spending their time meticulously tracking the issues, what should they be doing with all this freed-up time?

Tracking the goals they are trying to achieve, rather than the specific, ever-changing issues that are blocking those goals, will give management much more clarity around the current status of the project and, most importantly, what that status means for the enterprise. At its heart, the reason we care about the issues at all should be because they are blocking what we are trying to achieve by doing the work in the first place. Focusing on daily issues rather than desired outcomes is like the captain of a ship using her fingernail to scratch bird poop off of a railing while the vessel is engulfed by a raging storm. Someone will need to clean that railing, but the captain needs to be focusing on the big picture or the ship will capsize.

One of the problems with this approach is that all too often the intended goals of technical work are neither defined nor understood. Oftentimes there will be beautifully rendered, detailed architectural diagrams and elaborate approval processes hurdled over without anyone wondering why we need to do this work at all. But the good news is that it is never too late to take the time to define your purpose. Having that clarity of vision is key to the success not only of the project and the enterprise, but at the heart of why we have or need management at all.

Once the outcomes and goals are defined it becomes much easier to see what is truly at stake two weeks before deployment. What outcomes have we achieved, and which are still pending? Is this pared-down vision of the product enough to merit a deployment in two weeks? Management can spend time performing “if/then” analysis to determine what the path forward looks like from an outcome-oriented perspective, rather than fretting about this version, or that process, or this server, or that specific email. It’s time to free up our leaders to do the job we hired them for: steering the ship.

Want to learn more about agility and ways of working, check out our group coaching programs centered around advanced scrum, teamwork, and leadership.

Learn More

About the Author:

SARAH FRIEDMAN-CINTRON

Connect with us