No Deadlines for You! Software Development Without Estimates, Specifications, or Other Lies

In CodeSuite, I discussed one of the toughest challenges in software development services: how developers struggle to accurately predict project timelines.

It's good news; as I mentioned in that article, there's a way to ensure the software you create is valuable and the business team is satisfied, without the need to commit to precise time estimates (which, let’s be honest, I’m terrible at—even for tasks I think will take just a day).

This approach has become one of the most significant lessons I’ve learned over my many years of software development.

The key idea is to make uncertainty and risk central to discussions between developers and the business team, rather than ignoring them. This approach enables the whole team to face these real challenges together.

To explain what such a discussion might look like, I'll guide you through this approach with a detailed story.

Welcome to <Company X>, Here’s Your Spec

Imagine you’ve just started leading a small team of engineers at your first job.

On your first day, a person stops by your desk. Then they hand you a specification. As you read through it, you notice it’s the usual—a general outline for an upcoming report to be added to the company’s product. To complicate things further, it’s filled with office jargon and asks, “Can your team deliver this in three months?”

What do you do?

Here are some options I’ve tried (all unsuccessful):

1. Dive into the specs, asking for details.
2. Hesitate and suggest consulting the team.
3. Quickly agree, thinking, “Three months sounds doable.”
4. Push back, citing the impossibility of committing to deadlines.

Each of these approaches is bound to fail, leading to a project that disappoints everyone involved.

Alright, So What Should I Do?

When that important person is standing at your desk, use the opportunity to dig deeper into the business. Politely, but thoroughly, ask about the business model, the biggest challenges, risks, customer motivations, and leadership's goals. 

Your aim is to uncover the central problem the business is facing—often hidden beneath the surface of the proposed solution, like the report you're asked to deliver.

For instance, if you discover that the company is struggling with high customer cancellation rates and is eager to ramp up spending on sales and marketing, this is your real challenge, even if it’s not explicitly stated.

Once you understand this central problem, ask how the proposed report will help solve it. What’s the logic behind it? What concerns do they have about it potentially failing? Are there key questions that need answering before moving forward?

Understanding the real problem and how your work contributes to solving it is crucial to success.

How People Love to Hear Their Own Words

A key tip: during these conversations, echo back what the person just said. 

For example, “Let me make sure I understand. You’re saying this feature is crucial for upselling existing customers, not so much for acquiring new ones? Do I have that right?”

If you're correct, the person will appreciate that you understand the business. If not, you've just avoided a major misunderstanding. 

Use this template: 

1. a) “Let me echo that back,” 
2. b) repeat what they said,
3. c) “Do I have that right?” It’s simple, effective, and doesn’t require cleverness—save that for truly understanding the business.

This process takes practice but is incredibly valuable. Start by asking everyone you work with how they understand the business and its challenges. 

Keep asking, stay curious, and never hesitate to say, “I don’t understand—can you explain?”

The Knockout Punch

Once you’ve identified the central business problem and how your development effort fits into the solution, summarize it back to the person, using their words. 

For example: “Okay, so we’re adding this report to create a higher pricing tier aimed at upselling our most engaged customers, which should reduce revenue churn. This is crucial for improving our finances before our next round of fundraising. Do I have that right?”

With any luck, they’ll confirm, and you can respond, “Great, I’ll explore the tech we need and get back to you.”

Notice, you haven’t committed to a deadline. Instead, you’ve shown that you’re aligned with solving the real business problems. 

This builds trust and gives you the space to be creative in addressing the challenges ahead. After all, tackling tough, meaningful problems is what makes this work rewarding.

Man, If Only We Knew What To Do

The next day, your team tells you the new report is simple, except for a tricky part: importing data from a complex social network API. They can’t guarantee meeting the three-month deadline due to uncertainties.

What should you do?

Simply saying “we don’t know” is honest but doesn’t help the business solve its problem (reducing revenue churn before the next funding round).

The business needs to decide how to spend your time. If you were certain you could deliver the report on time and that customers would pay more for it, the right move would be to build it. If not, you’d pivot immediately.

In this situation, you need more information. 

1. Gathering that information is key to making the right decision, which could greatly benefit the business. 
2. Work on the aspects that will provide the most clarity about the uncertainties. 
3. Often, you can gather this info as part of the development process itself.

And, importantly, be upfront with the business side about this approach.

The Meeting Where You Earn Your Salary

You schedule a meeting with the important person and, beforehand, dive into the technical details of the new API and speak with sales and marketing to understand the target customer and the report's purpose.

In the meeting, you say:

“We’re optimistic about delivering the report within three months, but the biggest risk is the new API. From our initial investigation, we could likely show minimal data, which might trigger upsells, but sales and marketing aren’t certain.

We propose this: Two developers spend two weeks building a full integration with the social network, while our frontend developers create mockups of the minimal report for user research and potential sales demos. Does that sound good?”

This approach is vital for several reasons:

1. You propose sequencing work to quickly gather crucial information, like how much data can be pulled from the API and whether customers will be satisfied with a minimal data set.
2. Your deep understanding of the business problem allows you to suggest realistic solutions, like the minimal data report.
3. You offer the important person a clear, informed choice based on your current understanding of risks and business value.
4. By focusing on risks, you might discover unexpected, simpler solutions that can be implemented quickly.
5. You’re focused on the business's actual deadlines, not just project timelines, aligning your work with what truly matters.

What Happens Next

The important person might respond in several ways:

1. a) "Great, go for it." You reply, “Thanks, we’ll have more information and options in two weeks.”
2. b) "That minimal data is enough for upsells." You say, “Awesome, we’ll focus on delivering that minimal data quickly and have a prototype ready within a week or two.”
3. c) "That minimal data isn’t enough." You can respond with, “Would you like to see other restricted data options?” or “Let’s discuss the key questions this report needs to answer,” or even suggest exploring alternative plans to reduce revenue churn.

If the minimal data isn’t sufficient, it’s not a failure—it’s valuable learning. You’ve identified a high-risk area that the business is betting on, allowing you to either mitigate that risk or explore alternative solutions.

This Doesn’t Really Feel Like a “Process”

Building trust between developers and the rest of the business is deeply personal, not something that can be imposed by process. Developers must trust that the business is providing accurate information, while the business must trust that developers are honestly reporting what’s possible and the effort involved. Trust, built over time through shared experiences, is crucial—and any betrayal, like discovering work was pointless or broken promises, can destroy it.

Sometimes, You Should Polish Your LinkedIn Profile

A warning: If the important person isn’t actually important—like a middle manager stuck in a hierarchical structure—they may resist efforts to dig deeper into underlying business problems. 

They might see it as challenging their role, preferring to simply execute orders without questioning them. This can block the necessary flow of information, which is deadly for software development services.

If you find yourself in this situation, you have two options. :

1. Convince the Middle Manager: Try to show them how this new approach can make them look good. This rarely works, but it’s worth a try.
2. Quit: If you’re stuck in a system where questioning is discouraged, it’s likely that your project will fail. It may be time to find a place where you can solve meaningful problems and do your best work.

Your Mission, Should You Choose to Accept It

To summarize:

1. Understand the business.
2. Sequence work to gather crucial information early.
3. Make risks and opportunities central to ongoing conversations with the business.

This approach helps you tackle uncertainties together, leading to a more satisfying work experience.