[Hasu]

> The value equation of a software development team isn't a product of their time and salary compared to the code/features/whatever-unit they produce. It's the theories and knowledge they build in their heads and share through the process of understanding problems and developing solutions. You can't optimize that process in a Taylorist fashion.

There is no value equation for "the theories and knowledge" that developers build in their heads. Value in software happens when customers pay for software. That's how business works. It happens to be true that developers need to build theories and knowledge in their heads, but that isn't unique to software engineering and doesn't prevent deadlines from being effective.

> "It gets done when it gets done," is a glib way of saying that progress is more important than deadlines. The idea that systems take time and what's important is that people know where we're at and where we're heading more than threatening punishment for not delivering what we estimated at an agreed upon time.

I understand the argument, having heard it from teammates ten thousand times in my career. I'm somewhat sympathetic to it, but it is not a full picture of the software business. A business that fully adopts such a strategy has no long-term plan and can't make promises to customers. That can work if you lucked into all the money in the world (Google), but most of us are not so lucky and need to deliver to customers within reasonable timeframes or the customers go to someone else who can.

I get that estimation can be hard, conversations about scope can be hard, and managing expectations can be hard. I don't care. If you still have a job in this industry you are extremely well compensated to overcome those difficulties.

[agentultra]

If you don't care, I can't help change your mind.

I took a small company that was living contract to contract into a world where they started making millions in annual recurring revenue.

There's no secret, magic bullet. All I did was make sure we were delivering progress at a regular cadence. Kept communication channels open. And tried to, but ultimately failed at, training the sales team to stop with the secret deadline negotiation.

I understand the sales cycle at the enterprise SaaS level is a long song-and-dance of promises and and punishments. I understand that money only changes hands when the customer feels like they will get their money's worth or else your business will go out of existence. It's a difficult game to play.

However... they were never unhappy. Steady, reliable, and consistent beat out guessing, promising, and hoping to deliver every time. The dollars proved it.

[Hasu]

I think we're talking past each other.

> I took a small company that was living contract to contract into a world where they started making millions in annual recurring revenue.

> There's no secret, magic bullet. All I did was make sure we were delivering progress at a regular cadence. Kept communication channels open. And tried to, but ultimately failed at, training the sales team to stop with the secret deadline negotiation

This is what I call hitting deadlines.

[agentultra]

> I think we're talking past each other.

Perhaps. I'm not saying that deadlines don't exist or shouldn't. I am saying that they're often unnecessary and most software teams can deliver value without them.

If you're in the embedded space there's no dodging deadlines. If you need to flash ROMs it could be months before you can do a release if you miss your deadline. You might not have enough money to survive until then.

If you're shipping boring, line-of-business enterprise SaaS you don't need deadlines. Customers want software that solves their problems and are happy with something that works for 80% and a steady rate of improvements over time. They want progress and milestones. There's nothing wrong with taking an extra week or month to reach the next milestone.

Where you get the "deadlines equal dollars," mentality in enterprise software is from the long sales cycle with the big price tags. A business is going to have reservations about dropping a few hundred thousand on a new software product. And so you end up with these negotiations between sales, management, and the software teams where you're lying about the deadlines to different parties in order to keep everything in line. I don't think that's a good way to go about it.

Especially when most of the time it's not even necessary. This was the finer point I was often finding myself in opposition to the sales folks with. Their reality was that deadlines are a negotiating chip they can't ignore. The software developers' reality was that any estimate about a deadline is completely made up of hopes, dreams, and unicorns. The easiest way to get people to work together, in my opinion and experience, is to cut out the lying and just be honest.

Some organizations like that, some don't. I went back into being an IC because I just can't operate at that level and keep my sanity/energy.