Guidance over governance

Being part of a large IT organization, I’ve become acutely aware of the need to provide a central policy or governance over critical IT operations.  While greenfield/product teams can largely operate in independence, the risk associated with large, complex, and business-critical systems demands some degree of oversight.  However, an IT governance team can fall into some huge traps in their effort to set and enforce policy:

• Overstepping their bounds and enforcing governance where only guidance is needed
  • Failing to measure the outcomes of governance decisions</ul> For governance bodies to be effective, there needs to be accountability for decisions made.  If teams feel negatively affected by governance decisions, there needs to be a feedback loop back into the decision-making process.  Strong leadership needs to be in place to ensure fact-based decisions and not personal, political, or selfishly reasoned decisions.  As governance has so many opportunities to fail, it becomes even more important to harvest policies internally, grow them from observed best-practices, and encourage adoption through prescriptive guidance.

  Since how a team delivers is at least as important as what a team delivers, how can IT influence the “how”?  There are basically two approaches:

  • Guidance
    • Governance</ul> From the team’s perspective, the only difference between the two is where the decision gets made to incorporate a policy.  With guidance, the team makes the decision, and with governance, someone else does.  This not-so-subtle difference should be a top consideration when IT decides to enforce policy through governance or encourage policy through guidance.

    Removing decisions

    One of the key ingredients in self-organizing teams is putting the trust in the team to make decisions in how and what to deliver.  Attempts to remove any abilities to make decisions can quickly have negative impacts to the team unless care is taken to get buy-in from the team.

    The more decisions are removed from the team, the more the team feels like an un-creative cog in a machine or a code monkey.  Strong teams thrive on the opportunity to be creative, and teams without creative opportunities become lethargic, disinterested, and largely brain-dead.  It’s an enormous waste of resources not to harvest talent available, so the bar needs to be exceedingly high when removing decisions from the team.

    It’s possible to allow team decisions to be made concerning policy by choosing the scope of the policy.  For example, instead of mandating TDD, require that features have automated tests, then provide guidance on how to do that.  Teams can then decide on specifics.

    Favoring guidance

    Policies are more effective if they represent a set of core values and principles.  Certain meta-principles are appropriate for governance, such as “automated builds” or “continuous integration”.  Once IT governance crosses the line into specifics, that’s when decisions are removed from teams and problems arise.

    Instead, IT governance bodies can offer guidance on specifics and even support.  They can provide guides to help teams get started, pointing teams in the right direction.  Some teams may have enough internal experience to feed back their experiences back into the governance team, providing even more collective knowledge that the entire organization can take advantage of.

    As the saying goes, “people are our most important asset”, so if accountability is held for a team, it needs to be able to make decisions that ensure success.  If the team is accountable for decisions they didn’t make, morale suffers accordingly.  By favoring guidance, the governance team can focus more on growing appropriate policies by measuring the impact and success of their guidance.