Product Perils: Dummy Deadlines, Zombie Development, And More…
How can you, as a product owner, work with your engineering teams to produce better outcomes? I’m a software engineering coach who is often tasked with mediating between engineers and business interests, and as such I’ve seen a lot of the good, the bad, and the ugly — especially the ugly. I’m also a software engineer with nearly two decades of experience participating in and leading development teams, and there are plenty of practices that I’ve experienced throughout my career that were repeatedly responsible for inflicting ton of damage to product teams and relationships.
These perilous pitfalls can easily split open a chasm of cooperation and widen the gulf between a product owner and an engineering team to the extent that all of the interactions between the two become irreparably toxic. Let’s start the conversation with worst of these — by far — the Dummy Deadline.
A Dummy Deadline is a deadline conjured from the aether by management and plopped on the calendar for no particular reason, usually tied to arbitrary delivery goals set without any engineering context in mind.
Choosing deadlines without engineering representation or context inevitably leads to the potential for a death march. Nothing is more demotivating to an engineering team than crunching for no reason. Often, one Dummy Deadline will lead to another as the previous fear, angst, and Mountain Dew-fueled state of crunch that barely managed to meet an unreasonable date is noted by management as the new baseline, rather than recognized as an anomaly that the engineering team had to nearly break themselves to deliver. Repeated bouts of crunch are dangerous to an engineer’s physical and mental health and can often take a toll on their families and relationships as well.
To add insult to injury, often these deadlines are accompanied by drive-by changes to requirements or brand new features…that for some reason never seem to change the original deadline. Teams will begrudgingly continue to strain and push to meet their goals but will subconsciously disengage, with many members beginning to aggressively search for a way off the crunch-filled crazy train.
In the worst case, I’ve seen a death march induced by a string of Dummy Deadlines destroy an entire product team over the span of a year. Each consecutive deadline from leadership was accompanied by a period of intense crunch, inevitably resulting in one or more resignations, making the next deadline that much harder to meet as the team began to shrink. This culminated in the abrupt exit of the team’s own engineering manager, who checked out right before the proverbial crap really hit the proverbial fan. This manager hadn’t been engaging with their team for months and was instead spending most of their time trying to force open their own escape hatch. To the surprise of absolutely no one, the product itself didn’t survive either.
Engineers that are victims of a Dummy Deadline induced development cycle don’t forget their awful experiences, and will inevitably share information with friends and acquaintances in the industry about organizations that used them to get work done in an unhealthy manner. In the case of the product team I discussed, several of the engineers went on to lead large organizations including at the CTO level, while others became subject matter experts, well-known industry figures, and technical book and course authors. They were an extremely talented group of folks that the company in question completely mismanaged. They were a great team. The organization missed out and managed to completely pollute their reputation in the process. Teams will respect real deadlines, or at least provide you with the context you need in order to explain to leadership why their original ask was unreasonable. Fight for your teams.
Introvert Illiteracy — All people, not just engineers, can have difficulties speaking up in meetings from time to time. Communication issues have been exacerbated by the pandemic, where meetings are remote, instantaneous, and awkward, plagued by technical and human difficulties alike. As an ambivert (someone who both gains and loses energy in various amounts from engaging with large groups of people), I understand this dynamic all too well. Often, in a particularly heated meeting, it will take me time to process and communicate a response to a particularly contentious decision…usually long after the discussion surrounding decision in question is over. I like to think hard before I provide an opinion and I’m positive I’m not alone in this. It’s caused issues around important decisions at the team level more times than I can count.
I’ve heard stories of product owners in planning sessions balking at introverts for not “speaking up” during remote meetings, and even assigning sprint stories with an auctioneer’s battle cry of “Who wants this one?” without keeping in mind the psychological and emotional capacity of team members to respond instantaneously. By the way, saying “Let’s let the introverts talk. Speak now or forever hold your opinions!” in the last moments of making a decision isn’t a psychologically safe way to engage an introvert or solicit an honest response. You’ll get crickets every time if you do this. Having decisions made by a moment of uncomfortable silence is the worst and usually leads to groupthink. Be mindful of silence and don’t be afraid to “parking lot” a decision if it seems like there’s a lot of tension.
Additionally, the exact same videoconferencing tools that have led to a bit of angst around meetings also have the power to give the introverts on your team a voice. Anonymous Zoom polls, or online tools such as Ideaboardz, can provide a safe space for the more cautious members of an engineering team to think through their responses and provide their input in a less confrontational manner. Use them.
Zombie Development — I can’t take credit for this term, a student in the product management course I was recently attending made multiple references to this phenomenon: the continual engineering of a product of questionable value. The product is technically “dead”, but development continues to press on. This could happen for any number of reasons: it could be a specific leader’s pet project. It could also be caused by the all-too-common scenario of teams re-inventing the wheel over and over again in large organizations due to a chronic lack of communication or alignment. It could also be an entire team is running on auto-pilot, battered from corporate re-alignments or restructurings, or simply ducking their heads into their shells to avoid being targeted for redundancy. It could be a change in corporate priorities that has yet to impact the development organization at large.
Zombie products are extremely demotivating for skilled engineers. One of the most difficult development positions I’ve ever had was working as an engineer on a team building zombie products for mainframe servers. I didn’t know who was using the software I was writing, why it was important, or why it was useful. I simply showed up, wrote some front-end code, received a drop from the backend developers two days before the sprint was over, crunched over the weekend to fix the changes and make everything work together as well as modify the test cases to take the new behavior into account, and then do the whole thing all over again. I ended up leaving the team suddenly, taking a lot of folks by surprise in the process. The product in question was moved to my team by a layer of middle management who outsourced the product we were previously working on to an overseas group, leaving the mainframe stuff for us to fix. Nobody really wanted to be there and over time the lack of context demotivated the team. The Dummy Deadlines forcing me to crunch over the weekend during the second half of each sprint made the situation even worse.
To avoid Zombie Development, make sure you have context of what you’re building. Do the needfinding. Identify your users and the problems they’re experiencing. Identify your use cases. Back them up with data. And, most importantly, make sure both your leaders and your engineering team understand them. It sounds so simple, right? But I’ve been on so many development teams where the “why” of the product wasn’t clear to the people building it. That’s a recipe for disaster on any number of levels. Products don’t transform into amazing user experiences in and of themselves. Not without your help.
If you’ve recognized any of these practices or the situations that accompany them — good for you! Pop quiz: can you recognize the common theme across all 3 ill-fated product practices? If you thought “communication”, great! When product teams come to me asking for technical help, often the instigating issue of their problem isn’t their technical stack at all, but rather a “people problem” — usually stemming from communication issues within the team or with their product owner and stakeholders. A little communication goes a long way, both in terms of avoiding the practices I’ve discussed above, but also in delivering useful products.
