The fundamental work expectation for software engineers is to deliver their assigned work on schedule—engineers should be productive and reliable. Many engineers, particularly inexperienced ones, focus too much on productivity (writing lots of code) and not enough on reliability (delivering quality on time). Yet, anyone depending on them (managers, peers, partner teams) would rather get working code on schedule than fancy code eventually.
One key to being reliable is providing accurate estimates of when you’ll deliver. (No, others can’t just wait—they’ve got plans and obligations too.) I cover how to estimate quickly, effectively, and easily in I would estimate. Unfortunately, even the best plans run into issues from time to time. Sometimes you make a mistake. Sometimes a partner team lets you down. Sometimes there’s a change in plans beyond your control. Regardless of the reason or who’s at fault, you’re going to be late.
How do you deal with being late? You could work hard to catch up. You could count on others to also be late (schedule chicken). You could announce a schedule slip. However, the best way to deal with being late is to engage your stakeholders and agree on a revised plan. You’re not an island, and you don’t know what’s best for others. Take responsibility, respect those depending on you, and work out a solution together. Need more details? Read on.
Eric Aside
For more on what to do when the mistake is yours, read I messed up.
We need options
When issues arise that will make your deliverable late, you need to tell your stakeholders immediately while you all still have time to replan. (Hiding the information makes a bad situation far worse.) While slipping the delivery date is always an option, it’s not necessarily the best choice. Here are a variety of options you could present to your stakeholders, with pros and cons for each.
| Option (my rating) | Pros | Cons |
| Slip delivery date (★★★) |
|
|
| Death march (★) |
|
|
| Add resources (★★) |
|
|
| Treat as preview (★★★★) |
|
|
| Reduce functionality (★★★★★) |
|
|
Why are we here?
When you meet with stakeholders to review your options, skip talking about blame. Understanding the root cause is useful to avoid future issues, but you lose the respect of your stakeholders by placing blame on others, however deserving they may be. Your focus should be on how you’ll deliver going forward.
Start by reminding your stakeholders why you chose your current plan and design. Review your original goals, scenarios, and concerns. Then discuss your options, identify any new requirements, and select the option (or combination of options) that best meets the current situation.
It will be a compromise, so not every stakeholder will be happy. That’s okay. Difficult decisions rarely make everyone happy. Instead, the goal is to find a compromise that everyone can live with and accept. Keep debating possibilities until no stakeholder objects to the solution.
The times they are a-changin’
While all five options I list above are viable, my favorite is reducing functionality. Slipping the schedule tends to break trust and reduce confidence while not actually resolving the problem (you might slip again). Adding resources causes teams to work more slowly as new team members ramp up, which only makes it an effective strategy early in the project—not when issues arise. Treating functionality as a preview is nice but leads to delivering prototype code—a classic anti-pattern. As for the death march, the name speaks for itself.
Reducing functionality means redesigning the feature or scenario to focus tightly on exactly the value needed and no more. It’s the concept behind a minimum viable product. Aside from helping you deliver on time, tightening your focus helps the team prioritize, deliver the core customer experience, and then iterate on the code in future releases based on customer feedback. I love iteration.
Eric Aside
You can read more about my least favorite option in Marching to death.
Is never good for you?
The most extreme version of reducing functionality is cutting the feature or scenario entirely. That’s a valid option in a surprising number of cases. We all like to believe that our work is essential, but markets and strategies change. What was important yesterday may not be today. Be open to moving on from an obsolete plan. Not only will your professionalism gain you the respect of your stakeholders, but you’ll transition to a more impactful project sooner.
Even if you’re open to it, both you and your co-workers may feel empty and disappointed by cutting work you’ve started but left unfinished. Acknowledge this common and valid feeling. Help yourself and your peers move on by taking a day or two to document your work and round off rough edges, making it easier to return to the code later. Then focus on the new, exciting, and impactful work that awaits you.
Eric Aside
Sticking with an obsolete plan is such a common mistake that it has its own name: the sunk cost fallacy. To get over the pain of cutting a big project, an old team of mine had a “Sink” party (with dunk tank) and “Sink-it” stickers to put on our “Ship-it” awards. This approach worked well, and I still cherish that “Sink-it” award.
Lean on me
Great engineers must do more than produce code to prove their worth. They must also be reliable, delivering quality on schedule. However, even the best designs, plans, and estimates can be foiled by unexpected events and unanticipated issues. Rather than blaming others, hiding the issues, or slipping the schedule (again?), be a professional and engage your stakeholders.
Remind your stakeholders of the original requirements and design choices, inform them of the current situation, and then provide them options for moving forward. Your stakeholders may lean toward slipping the schedule, insisting on a death march (I’d object), adding resources, or rebranding the feature as a preview. Alternatively, consider redesigning and refocusing the feature tightly on the minimum value needed, then iterating over time. If the market or strategy has changed, consider dropping the feature and redirecting your efforts.
Promptly taking responsibility for being late, being open to feature cuts, and providing your stakeholders with options enhances your reputation and builds trust. Everyone knows life rarely goes as planned. People who tell you in advance when a commitment can’t be kept and provide you with choices for moving forward are people you can depend upon. Be one of those people.
Eric Aside
Special thanks to Irada Sadykhova, Bob Zasio, and Clemens Szyperski for providing valuable feedback on the first draft of this month’s column.
Want personalized coaching on this topic or any other challenge? Schedule a free, confidential call. I provide one-on-one career coaching with an emphasis on underrepresented, midcareer software professionals. Find out more at Ally for Onlys in Tech.
Be First to Comment