Snausages

So now I’m the guy wielding the process stick.  Stranger is the wonderment by many that I am “a process guy”.  I guess it just goes to show one that you’re never quite able to see yourself as others see you.  Certainly, I’m a “process guy”.  Process is how you deal with the inevitable problems with groups of people trying to do things.  It’s called “protocol”.  Considering that all my professional life has been focused around the problem of consensus in distributed systems and the engineering of distributed protocols, I do find it slightly bewildering that people are surprised when I bring up process and my belief in good process.

One of the more painful lessons that I learned in business is that good contracts keep good friends as good friends.  I had to learn the hard way how stressful it is on even good, solid relationships between very smart and honest people when misunderstandings occur about things that mean something to them – i.e. MONEY, or more generally BUSINESS.  When things are just left up to good intentions and the belief that “we can all just work this out like normal people”, I invariably find the trail of debris in broken friendships and business partnerships.



Now, in this particular case,
I’ve been accused of “not reading” the plain and obvious and that I simply should
have done my homework.  The point in question is the interpretation of
the following from the process documents:

5.6.2 Actions
The SDE (Specification Document Editor) shall
create the appropriate documents based on the content of one or more
RFCs. Under ideal circumstances the formulation of the Specification
would be a mechanical process but it is expected that the SDE will
uncover inconsistencies or other issues in the RFC(s) which require
clarification by the appropriate EG. In this case the SDE shall liaise
with the appropriate EGs directly to resolve the issue. The SDE shall
have at least one and preferably several review cycles with the
appropriate EGs to ensure accuracy prior to completion of the
Specification.

Certainly,
this is something that I completely understood.  It is unfathomable to
me that the SDE wouldn’t uncover inconsistencies and have to come back
for “clarification by the appropriate EG”.  However, this is not – imho
– what actually happened.  What happened was that the SDE came back
with the recommendation that we fundamentally change the specification.  This is not “clarification”, in the way I understand the term “clarification”.  Clearly (to coin a phrase), clarification means to make more clear.  It does not mean to “change the specification in fundamental ways” because there are time issues which force us to make difficult decisions.

A specification, particularly the final RFC, represents a compromise
amongst many competing business interests.  If you want to change that
compromise, you’re invariably going to work against at least one of
those interests and thus destroy the compromise.  That is not the
process of clarification.  Now, perhaps I have completely misunderstood
the use of the word “clarification” in section 5.6.2, but then that
just shows that the process itself needs – ahem – clarification.

Further,
one of the deep issues with the process as practiced, has been the
underlying assumption that the only vote we would get would be on the entire specification, not just the particular
specification under question.  This was not just my confusion, but
seemed to be a shared understanding by many – on both sides of the
issue.  Certainly, the way it was repeatedly represented to me in my
queries was that the only chance we would have for another vote would
be on the full specification which contained the array of individual
specifications.  After much investigation did it turn out that this was
not a correct interpretation, but the odd thing was that it was somehow
considered to be the “nuclear option” – that is, actually taking a vote
on the SDE’s rewriting of the specification was considered to be in
poor form and something that would cause deep divisions.

Now, of
course, I could be confused about this as well.  Certainly, at this
point, I’m wondering what all the fuss would be about if, in fact, that
a vote following the SDE rewrite of an individual specification was
actually spelled out and understood as part of the process – certainly
that wouldn’t seem to be a “nuclear option”, nor would it seem that
standard operating procedure should be a source of divisions within the
group.  So, color me confused yet again.

In any event, I think
it is still necessary to understand exactly what the SDE’s limits on
“clarification” are.  If “clarification” means making fundamental
changes to the specification, then I don’t think it should be all that
controversial to have a good discussion and another vote on the
“clarification”.  It’s a fundamental change to the compromise and we
should be required to see if the compromise still holds.

But then, I’m just a process guy.  What else would I think?

Leave a Reply