[nstart]

While this example feels pretty obvious, I think in practice, these conversations conflict with the third caveat mentioned:

"Your team is always working on the next most important thing (as prioritised by the business)"

When the business functionality and marketing needs compete with technical advances, there's a decent amount of negotiation that needs to be done and that negotiation varies wildly from company to company.

Early on in my career I felt angry at these kinds of negotiations. As I've become more mild and open to business needs across the board I realise that most people will agree with the goodness of the idea but it becomes the duty of the proposer to sell it in terms that the business unit can agree to.

Overall, this is a great thought provoking article. Concise. Yet nuanced.

[KronisLV]

> When the business functionality and marketing needs compete with technical advances, there's a decent amount of negotiation that needs to be done and that negotiation varies wildly from company to company.

I think that this is the crux of the problem, but the solution lies elsewhere rather than just in negotiations.

After all, if you plead for some time to address technical debt and do platform improvements, you might just get told "no" to, given that in certain cultures people won't view these things as something that generates value directly and convincing them otherwise will be an uphill battle.

So why not just announce that X% of the following sprint or month will be spent on these things, to ensure successful continued operations? That's about the same as writing tests instead of having bad coverage due to an ever growing backlog and scope creep which eat up all your time.

After all, you don't ask business about using a version control system, do you? You just go ahead and do what's necessary to version your project. Tests, CI/CD, configuration automation etc. should be treated the same, since we're paid to be engineers and a part of that engineering is ensuring at least decent quality.

Note: this probably doesn't apply to larger efforts, like changing the entire architecture of your application etc.

[nstart]

I agree with the idea that solutions can lie in more than just negotiations. But I will also say that I’m at the point in my life[1] where I believe the vast majority of solutions do lie almost purely in some form of negotiation.

Take your own example:

> After all, if you plead for some time to address technical debt and do platform improvements, you might just get told "no" to, given that in certain cultures people won't view these things as something that generates value directly and convincing them otherwise will be an uphill battle.

This right here is a negotiation between business and engineering. The business unit cares about technical debt only if it affects successful delivery of business goals. As such it needs to be negotiated along those lines. In fact, I’d say you make a wonderful negotiation right after:

> So why not just announce that X% of the following sprint or month will be spent on these things, to ensure successful continued operations?

That is an excellent negotiation right there. The business cares about successful continued operations. Stopping everything to focus entirely on technical debt is not successful to the business. Allocating x% time to a mutually beneficial goal where x can be continuously tweaked is an acceptable point.

> After all, you don't ask business about using a version control system, do you? You just go ahead and do what's necessary to version your project.

The thing about this point is that it is:

A) easy to get setup.

B) well understood enough now to know the benefits to the organization

I’d argue that ci/cd is coming closer to that point now. Definitely is on the right trajectory and for the same reasons. Easy to setup and the benefits are well known and easily understood.

More nebulous topics like testing and tech debt will for the foreseeable future be topics requiring decent negotiation.

[1] I may change my mind on this in the future. Definitely been around on topics where I believe one thing, believe an alternate point of view, and later have a softer or accepting view of the original idea :).

[jiggawatts]

> well understood enough now to know the benefits to the organization

Maybe to you, but unless your business is 100% IT focused (like a software startup), I guarantee you that virtually nobody outside of the dev team knows what version control is, let alone the cost-benefit considerations.

A surgeon doesn't ask the patient whether to use antiseptic or latex gloves.

An engineer doesn't ask the client if the concrete should need steel reinforcing or not.

The lawyer doesn't ask the defendant if he should reference precedent.

The developer shouldn't ask the business for permission to automate their workflow.