Communication is one of the most critical skills for anyone in our industry. I always say that just because I say a word and you hear the same word, we cannot trust we both understood each other. There’s so much ambiguity involved in language, and, like with dynamic coding languages, you don’t get a compile-time error telling you the other side didn’t understand things correctly.
A prominent example of this is the common misunderstanding of what a deadline is and how that, in turn, hurts teams’ velocity, innovation, and trust. After talking about this with several clients in the span of a few days, I decided to put some of my thoughts into writing. Let’s start with the concept of a “deadline.”
Every team treats these differently, which is why we have trouble understanding what they mean. When a deadline is set, at some of my clients (e.g., the team commits to finishing something by the end of the sprint), missing it will result in cascading issues and delays. Others don’t even bat an eye when that happens or when the team asks for additional time. Managers have the responsibility of performing the right expectations setting so that everyone is on the same page.
Start with yourself, as part of leadership: how do you view deadlines? A lot of engineers turned managers/executives have real issues with “arbitrary deadlines.” That is, they cringe when they consider telling the team to be done by the end of the sprint even though nothing major will happen—there’s one waiting, no external constraints. However, deadlines are a tool for pushing the team forward. Without deciding how much effort it is worth to invest in something, how can the team make tradeoffs and consider alternatives? Basecamp’s notion of a “betting table” where leadership makes six-week bets is an excellent example of this. Making the call of the amount of time something is worth helps, rather than detracts, as long as you are open to feedback from the team.
The other side of the coin is that you should decide how deadlines are treated in your company. I have seen miscommunications happening several times due to the individual contributors holding deadlines to a different standard than leadership. For example, when asked to provide an estimate, the team would supply a “100% certainty” estimate—an estimate that has virtually no risk in hitting, with buffers builtin and all. Those teams either keep finishing things way earlier or get used to doing things slower than they should. Either case makes management frustrated.
How do you treat deadlines? Are they sacred like at Basecamp? I.e., whatever is not done within six weeks will be put aside for the next things that are planned? Are you more flexible and expect the team to hit estimate about 80% of the time? The latter means the team will invest less time forming estimates and usually set more ambitious goals. This expectation setting is fundamental for creating teams that deliver rapidly.
I will leave you with a single thought: this whole ordeal was based on a common misunderstanding of a single world, the deadline. Can you imagine how many more instances of similar misunderstandings are affecting you and your team? Perk your ears up and listen intently. You might spot more opportunities for improvement just by hearing what’s really being said.