How important is meeting this deadline?
How it all got started
It started as a very small feature request by another team driving a big initiative. As we dug in and better understood the big picture, more doubts grew on whether this is the right approach. What was originally assumed to be a very small fix (option b), turned into something even comparable in size to the ideal solution (option a), still relatively smaller though. Here, the problem was, the work was estimated to take 8 weeks, which was all we had up to the key date in which we were going to announce the feature to our customers. Even a single day spent evaluating our options would risk not meeting the deadline. Anyways, we assembled the team and started working as hard as we could. The feature lead was busy constantly reassessing the situation and the team was hard at work. Some corners were cut, and a few things got pushed out. Despite a few setbacks, the feature was ready on time. What happened next, another dependency didn’t make it on time and the whole initiative was delayed by 2 weeks.
What if?
It felt like all those efforts didn’t matter anymore. Questions started to come up in private and team conversations. What if we didn’t cut so many corners to ship on time? What if we went with the ideal solution on day one? What if I helped my teammate with their complex investigation (only I could do) the other day? These are all the opportunities lost, but on paper, this was a success story and the feature shipped right on time.
Tom DeMarco and Tim Lister, in their famous book Peopleware, have identified main causes for teamicide (what kills healthy teams). Among those are “phony deadlines” and “quality-reduced product”. We managed to inadvertently introduce both of them here. With the hindsight, we know how it could have been prevented, but that’s a different story for another day.
Worse then a phony deadline, however, is a non-deadline. You can imagine the team in this example would at least be happy about the fact that they were not the long tail of the project. What if a similar thing happened in a project with no deadline? Enter roadmap planning.
How did we end up here?
Here is what happened: During quarterly planning, we made a high-level estimate of all the projects we were planning to do. Based on the estimates, we allocated people to each project, and shared the project allocation with the whole team so they know what’s coming up in the next few months and who’s going to work on what. As you already know, a lot changes between planning and execution, and you can’t really trust these dates (even if they are accurate). In this case, the scope of the project had changed enough that it had to be even renamed. Perhaps I had not clearly communicated to the team about the intentions behind sharing the plan, therefore some people took those dates on the face value and pushed themselves very hard to be able to be on track. It’s sometimes necessary to push hard in order to meet some deadlines, but you generally don’t want to be in an environment where this is everyday occurrence. Resilience is a finite resource, and you can only draw so much from it. Therefore, it is important that you pick your battles wisely, and communicate the fact very clearly to the team.
My 3 take-aways
This experience made me be more conscious of deadlines and the impact they can have on the team, just by existing. Here are my top takeaways:
- Always communicate the reasons behind a date. People tend to take dates seriously by default, without asking too many questions. Ask and encourage these questions: Why was this date set? How accurate is it? What input was used to make this date? What happens if you don’t make it? Who will be impacted if the date slips?
- Align incentives for project leads, and don’t reward them mainly by shipping projects on time. Be aware of the long-term impact they have on your people or on technical complexity of your work. There are things you will keep paying for, even long after the project has shipped.
- Fight the urge to resolve all the uncertainties. Sometimes you are pushing for a complete solution in a time-constrained environment, therefore the only possible option for you is “option b” which can be shipped on time but is not great in the long run. However, you can probably do “option a”, make it say 70% ready, have some manual steps at the end and hand-hold early adopters. Engineers are naturally very uncomfortable with an in-between situation and will most likely oppose this approach. However, they might be more satisfied with this in the long run, therefore it is worth a real shot. There is a good chance that you can bridge the gap even before the first customer tries your feature.
