BBB: Deadlines and Developers
Bala discusses why developers hesitate to commit to timelines, tells you how to build trust with your dev team, and quotes Taylor Swift.
As you can tell I love good alliteration.
Back at Tucows, I inherited a dev team responsible for building the WHOIS publicity service. Think about the service as the opposite of the WHOIS privacy service, which the new GDPR regulations had made extinct. The main benefactors for the WHOIS publicity service was a large parent company that owned several domain brand names. They wanted their name displayed in the public WHOIS as a way of marketing to others in the domain industry. So the mission was to display real domain owner information in the public WHOIS. Easy right? Nope. Like with most things in the domains world, this was a change that was wrapped around so much legalese they could have put gift-wrapping supplies out of business come holiday season. When I inherited this dev team, the product manager who was leaving did not bake any of the time or effort it would take to unpack, discuss, and accommodate requirements our public WHOIS service was obligated to meet. They had given the leadership team, including the EVP of Domains, and the CEO of the company, a significantly shorter timeline to launch than what it would really require. For the three additional months, it took to ship the software, there was a lot of pressure and frustration from leadership on why this was taking so long, why we weren’t making much headway, why the team didn’t understand how upset our main benefactors of the service were.
What’s the timeline, you ask?
Have you ever asked a developer how long something would take? A lot of the time, they shy away from giving you a timeframe. And if they do, they stress that it’s an estimate, something hypothetical. Why is this?
A developer’s role is to help you solve your user’s problem in the most effective way possible. Let’s say you want a developer to build you a simple landing page that collects a visitor’s email address. It is the developer’s responsibility to not just engineer a page to life but also do so intelligently. Otherwise, the page could take too long to load, run into issues with the emails being collected, and your developer will need to fix them. These two problems are two of millions of problems that could arise when constructing this simple landing page. Think about how many problems could arise for something more complex!
When bringing something to life on paper, we’re working in an ideal world. Just think about what running a real restaurant looks like, compared to its business plan on paper. Similarly, when a developer is at their desk, actually coding your solution, they will 100% run into issues along the way. And when they do run into issues, they’ll need to resolve them as they come up. Some could take minutes, others could take days to resolve. If you as the PM have told your organization that you’ll ship Feature X within two weeks, and a developer has spent 3 days trying to resolve a pretty mean issue, that’s more than a quarter of your timeline spent away from actually building the solution. If resolving the issue requires re-imagining a part of the build, which takes another 2 days, that’s half of your 2-week timeline spent on surprises.
So how do we avoid surprises?
We can’t. We could anticipate a certain level of surprises and build a conservative timeline to make room for any issues that come up. But even then, there’s no guarantee you’ll meet that timeline.
Instead, here are some things I do to better manage surprises.
Focus on the level of effort, as opposed to time
When writing code, it’s difficult to predict exactly what errors may come up but simpler to gauge complexity. Developers may feel more comfortable discussing work in terms of its level of effort. By doing so, they are not committing to an explicit timeline, but still giving the team a sense of the development work involved.
But we still need to get things to go live, don’t we?
Yes, we do. But in this instance, I urge you to think about an agile approach in product development, where you release products in small increments that still deliver customer value. Going back to the landing page example, where your goal is to market relevant content to your users, perhaps the first iteration simply has the title of the company, a small blurb about why you’re collecting emails, and a box where users can enter their emails. The next iteration can have users answer a question before they are prompted to enter their email, so you can segment them better. By layering functionality incrementally, you make sure the scope of the work isn’t so large that the development team is stuck with it for months on end. Moreover, it will give you more opportunities to infuse your product with customer feedback.
Develop trust with your dev team
If your team doesn’t trust you to have their back, especially when a top-tier exec is frustrated with the team performance, they won’t feel comfortable discussing the actual level of effort that the work may require. They may inflate the effort something may take, or even get defensive when you challenge their approach to a solution. It took me a bit of time to build that trust with my own development teams. But once you do, it’s easier, and also fun, to politely challenge their approach if you think there is a better way to build something. This encourages healthy debate, clean development, and also informs you of the complexities of in-house systems, developer language, and even the style of problem-solving a particular developer may have. You’ll keep these things in mind the next time you’re building your roadmap. Maybe it will give you an idea for a project in reducing technical debt that you can now make a strong business case for (and trust me, your developers will love you for that), or allow you to speak more informedly when another stakeholder makes assumptions around timelines.
Finally, always have empathy
As a team, you win together, and you lose together. If despite your team’s best efforts, the project is running into a lot of roadblocks and is nowhere close to being completed, take it in your stride. This may be easier said than done, but ultimately getting frustrated will do no good. Your development team has worked just as hard as you have in bringing your solution to life, and they are just as disappointed at the hurdles as you are. Your development team will appreciate it, and as Taylor Swift knows best —
‘My reputation's never been worse, so
You must like me for me’.
Like what you see?
Let me know in the comments below! And don’t forget to follow me on Twitter, LinkedIn, and Instagram.