The Pillar that Wins by Default

Your deadline is looming. UX has UI changes they want in before launch. Engineering is still working through security concerns. Which one gives?

Software is valuable when it meets needs, and those needs come in three types. Business needs ask questions like: is it Innovative? Timely? Compliant? Technical needs ask: is it Functional? Scalable? Maintainable? Secure? User needs ask: is it Intuitive? Accessible? Supported?

Each type tends to have a natural owner. Product usually speaks for the Business needs, Engineering for the Technical needs, and UX for the User needs. Each of them is right to push for their own pillar.

The trouble starts when one pillar wins by default.

I've led teams where new business priorities kept arriving and nothing ever came off the list. The technical work that kept the software Maintainable waited, quarter after quarter. Nobody decided to neglect it. Nobody decided at all.

A house with one tall pillar and two short ones doesn't hold up a roof.

You can't push on everything at once, so make the tradeoff explicit. Across your Attributes, name which ones you want to improve, which ones you need to hold steady, and which ones can slip because the current level is more than you need.

Then watch the whole house, including the Attributes you meant to hold steady. A change that improves one Attribute while degrading another just trades one problem for another.

I created the House of Software Value Delivery to put all three types of needs in one picture, so that tradeoff gets made on purpose and in the open.

Next
Next

Most Transformations Are Just Changes