On Dates

There is a direct connection between distance to a commitment date and team morale. The further out a given commitment is made, the more toxic that commitment is to the organization. Your job as the leader or member of a team is to ensure that team is as functional as possible and remains as functional into the future. You can do your part in ensuring the functionality, happiness, and productivity of your team by reshaping your commitments away from far-future due dates.

First, let's look at some typical scenarios:

Moving Target

In the real world, the final destination is a moving target. Perhaps the expectations of your userbase changes over time. Perhaps a system you are integrating with evolves. Perhaps the goal of your business shifts. Perhaps your competitors innovate and you need to catch up. Perhaps there is new senior leadership in your company that provides a new unique vision or strategy. In the real world, all of these things are happening all the time.

By making a commitment far in the future, the team sets out on a course, blindly marching to the originally understood destination. If the team or organization is not aware of the actual moving target, where the team lands on that promised date is quite likely not where they should actually be. If they continue the original course, they will deliver the wrong thing. If they take an approach of learning and adapting in order to deliver the right thing, that original date commitment is most likely wrong.

Over-Aggressive Commitment / Procrastination

These are two sides of a similar situation, and both lead to team burnout and low quality. In this scenario, a delivery commitment is made and the team works at a normal or easy pace for the first 80% of the time commitment, typically finishing 50% of the project. The remaining 20% of the project calendar is spent working nights and weekends and taking shortcuts to deliver the rest of the project on time. Perhaps this sounds familiar?

Those nights and weekends are not yours to take from your team. That is your team members' valuable recharge time, time to connect with friends and family, and time to pursue personal interests that are not your company's software project. By taking this recharge time from them, you are also taking away their enthusiasm to do their work. Believe it or not, software engineers are humans first.

The pressure of the due date also leads to shortcuts in design and implementation that decrease overall quality. So not only are you burning out your employees, but you are shipping garbage at the same time.

The due date is an easy organizational and personal benchmark of success. It gives a stick to the engineering managers and project managers of the organization to beat their team with. It may feel good to talk about with stakeholders in the beginning, but it is completely irresponsible to the energy in your team and the quality of their work product.

Under-Aggressive Commitment / Sandbagging

Again, this is a two-sided coin of inaccuracy or waste. Typically this scenario is created by "experienced" teams that have been burned in the past by over-aggressive commitments. In response to their lost personal time, the team learns to pad their time estimates by 1.5x, 2x, or 4x. This gives the project managers of the organization the prized due date they desire, and gives the employees a nice and easy job. The team then enjoys a life of foosball and ping-pong and a trickle of productivity. Invariably, the lure of the table tennis table is so strong that the team ends up in the procrastination zone toward the end of the project anyway. They fritter away their nights and weekends to hit their ship date and end up resenting their job.

The net result is a double penalty of wasted opportunity from a team not working as efficiently as they can, followed by overwork and burnout.

What to Do? Reshape Your Relationships!

Do everything in your capacity to stop agreeing to dates far in the future. The farther out a given date is, the wider actual margin of waste is created. For instance, if your date estimations are on average 80% accurate (something to be proud of!), in a six month project, the actual delivery will happen in a window of 5 weeks before or after the committed date. Welcome to the waste / burnout zone of teams who "hit their date"!

You must begin now to shape the relationships and commitments you make outside your team. It's important to have a roadmap or strategy sketched out before embarking on any large project, but that strategy needs to be re-evaluated on a regular and frequent basis to make sure it is correct in the present environment.

Take your customers along with you on the journey. Help them understand the reality of the world of moving targets. Do not fall into the trap of people leaning on you to perfectly predict the future. That is an unreasonable expectation, and you should not set yourself and your team up for failure like that.

You will undoubtedly be pressed to name a date where the project will be "feature complete". Refuse to answer this question.

Instead, make your customers and/or stakeholders a partner in your endeavor. Do set up regular check-ins of progress, level setting, and goal alignment. Show them incremental progress. Help them understand the challenges your team is facing. Ask them for their help in resolving those challenges. Get their input on the team's priorities. (But make it clear that the team makes the final prioritization.) Help your customer understand that they are getting value sooner, and the end product will be better.

Invite your customers and stakeholders to your retrospectives so they can get to know your new, better, mode of working and expectations setting. Help them see that their involvement at this level helps you deliver the most important value in the best order to them.

A stakeholder who feels like they are a partner in your team's journey, who is receiving valuable incremental progress at regular intervals, who is involved in helping the team understand what is needed and when, will naturally stop pressing for dates far in the future. They will now understand and appreciate that the team faces unpredictable challenges and that they are necessarily chasing a moving target. They know that they are a key ally in identifying the movement of that target and enjoy their helpful position in the team.

But wait! My dates are set in stone!

sigh Yes, sometimes the date is totally immovable. Perhaps it's an industry conference, a public product launch, or there is a scheduled marketing blitz. These are factors that are decided and booked long in advance. The three variables in software delivery are capacity (team size), delivery date, and scope (feature set).

If you have already forged a partnership with your customers/stakeholders, shaping the relationship so that they understand the incremental nature of software delivery, hopefully the scope of delivery at that due date is variable. This way, you can have your same high-performing team focused on delivering the most important features first. The due date is simply a point on the team's timeline where the value they have already delivered is shown to a wider audience.

If the date is fixed and the scope is fixed, then you had better scale the team to the appropriate size, far enough in advance for the new members to become efficient, to hit the target. This situation is a justifiably wasteful one, since you will need to over-provision the team to guarantee the delivery. Otherwise, brace for a low quality / burnout situation.

Conclusion

By eliminating the wasteful act of commiting to long-term dates, you will be maximizing your team's happiness, quality of output, accuracy of output, and deliver value far sooner. These are virtues of a high-functioning team.