Throughout the most recent years of my career, I’ve helped transform tech teams from some form of Waterfall process to Agile. A challenge I always seem to run into is the team over committing to work. Whether you’re on a tech team or are managing your personal life, many people struggle with saying “no” or “not right now” to work they had not planned for. Despite all your best intentions, not being able to say no leads to overcommitting. Overcommitting doesn’t come without its issues, in fact, this can affect your productivity, quality, and deadlines in the end.
We all want to make our customers (whoever they are) happy, but sometimes when we’re not vigilant, we can find ourselves in a position of overpromising (or being overcommitted). Here’s how and why we fall into that trap, how to get out, and why we MUST say no to ensure long term success.
Although many of the solutions I will describe are processes of Scrum and/or Kanban -- two incarnations of Agile –I’m purposefully trying to stay away from directly pushing an Agile methodology because, frankly, this is about managing your demand, and the processes I’ll describe can fit into almost any work management process.
How and why this happens
How long ya got? Maybe a friend in another team didn’t realize they needed you/your team to do some work on one of their critical projects. Or perhaps a new initiative came about as part of an organizational change. The reasons are many. And so you or your team is now faced with disappointing a friend or taking on work they really don’t have room for.
Overcommitting can be explicit, in that you or your team may say you can get something done at a requested time even if they aren’t sure when or how exactly to do the work. It also can be implicit if the culture at your work is such that it’s ok to send someone work and the expectation is they will complete it on time.
How to free yourself from the trap:
-
Create a visible backlog
It’s important to display all the work you’ve been tasked with and ensure you can tie it back to the organization’s strategic initiative. This is especially critical if your environment is particularly political – tie the request to its sponsor. Whether or not people want to believe it, they do compete for your time. It’s helpful for them to see who they’re competing with.
-
Track your throughput
For you to say you don’t have the capacity to do the requested work, you’ll need to know how much work you do. Start by tracking the number of completed “widgets” your team produces over a period of time. The units of measure are not terribly important but need to be something that resonates with your user community, such as environments built, user stories, features developed, sandwiches made. You get my point.
I should note I have mostly worked on Operational teams who are tasked with “keeping the lights on,” therefore, they may struggle with how much Project work they do vs. Operational work. This is a question that’s really more of a distraction. If the organization sees fit to have one group perform both types of work, then it’s more about tracking what you actually do. If these numbers drive the organization to invest in your team, then that’s an added bonus. Focus on tracking project work you complete.
-
Have an open and public time/forum for selecting work
It’s time to train your dragons…err…stakeholders.
Before the meeting, work with your stakeholders offline to prepare them for this process and advise them to stack rank their requests. I’ve seen many stakeholders try to have priority rankings of ones (aka needs immediate attention/most important) and twos, and so on. This isn’t good enough, however, you may not be able to get them out of that approach. To set expectations, be clear that they will likely not be able to get all of their ones completed in the first go around, so they had best be prepared to select which ones they want first.
Make sure your team takes the time to estimate the size of the requests in advance using the benchmark metrics you established when you documented your throughput.
When officially meeting, I like to go around the room -- not unlike a fantasy football draft -- and let people select their top request. You can track who goes first, then switch it up. I’ve heard of (not seen personally) groups having fun when coming up with a “draft order.” One of the things Agile has taught me is that if you can make a new process fun and engaging, it will diffuse some resistance (note: some resistance). What’s amazing is over time the stakeholders will begin to “horse trade” or manage themselves. They will say things like, “Well, I don’t need this in February. It can wait until xxx date, and you can take my spot this time around.”
Why you must say no to succeed
Plainly, when everything is the priority, nothing is. If you allow everyone to foist work upon your team, you will either work 80+ hours per week, which will drive burnout and team defection. Or you will disappoint many stakeholders, damaging your team’s image and credibility. You need your organization to believe in your word: when you say something will get done, that needs to be perceived as set in stone. For that to happen, you have to have been very close to hitting all your commitments all of the time. For that reason, you must get comfortable with saying no so you don’t overcommit.
It’s amazing when the team begins to “get it.” When they’re vigilant with their commitments -- and in fact when we tell someone no, or not right now -- it demonstrates that we are committed to the overall success of our organization. And that’s a goal we can all get behind.