Line item vetoes and cock blocking

In my previous life as a CEO of an enterprise-level software company, we did a lot of work on software design. But I always found this process to be slow, cumbersome and frustrating. More often than not a specification process died, or wound up with a lowest common denominator approach that lacked any real imagination or elegance.

In other words, I felt that there were always people out to cock-block vs working towards a happy-ending. These people were always quick to reject other people’s suggestions but slow to offer their own (another partial-solution is to remove these people from the process entirely).

The systematic and the dead

There are two types of spec design processes – the systematic and the dead. Creating an ad hoc specification of an ad hoc design change, all the way up to a full blown product specification, should be a systematic process that once started, should never stop. Frequently, disagreements result in the process slowing down considerably and even grinding to a halt and you are left with a lot of unfinished designs and blocked releases. One of the biggest problems is spec owners giving stakeholders a veto. By allowing any stakeholder to veto a provision in the spec, it will virtually guarantee the spec will compromised, at best, and delayed/aborted at worst.

To prevent this is it critical to have assigned roles

Specification owner – this is the person and or persons who own the feature, understand the use case, and are ultimately responsible for its implementation

Stakeholders – these are the people (internal or external) who can advise, comment, consult, disagree with or otherwise help the spec owner to ensure that the spec has a higher chance of success. These stakeholders will try to smoke out potentially problems, challenge design, look for errors of omission, make suggestions etc. They may be other team members, other teams, power users, customers etc

Epic specification owner – this is the person or persons who have approval authority over the final specification.

It is also critical to follow a defined process

The spec owner should initiate the spec and work iteratively and collaboratively with stakeholders to define it. This must not be design by committee, a “Boy, man and donkey” approach, or lowest common denominator (where only things that everyone agrees on get approved). Stakeholders must craft the best specification using a combination of their research, knowledge, critical thinking, design ability and stakeholder feedback.

If two or more stakeholders disagree with each other, the spec owner must determine the best recommendation or their own design. If any stakeholder disagrees with the design and can’t be convinced otherwise, then that disagreement must be noted in the Spec Appendix (vs ignored), but otherwise, development and completion of the spec must proceed. By giving everyone a voice, if not actually a veto, by citing all disagreements in the spec, empowers people to understand that their contribution was validated, if not actually implemented

Keep up the flow

Once started a specification process should never stop. It needs to progress systematically. It may slow down but never be blocked, have to wait for an inordinate amount of time or otherwise be delayed. Feedback and objections can be processed and internalized, even if they aren’t implemented, without stopping the design process