arrow-left arrow-right brightness-2 chevron-left chevron-right circle-half-full dots-horizontal facebook-box facebook loader magnify menu-down RSS star Twitter twitter GitHub white-balance-sunny window-close
Consistency through Meritocracy
1 min read

Consistency through Meritocracy

This is an old post and doesn't necessarily reflect my current thinking on a topic, and some links or images may not work. The text is preserved here for posterity.

Dan Pritchett wrote a good post about the friction between innovation and consistency. The bit that resonated with me was the conclusion that if you want to achieve consistency, you have to do it by providing solutions people want to use:

The traditional role of architectural governance can be very useful though in sorting out which of the 4 scenarios exist when someone wants to introduce a new solution to a problem. Most teams have a tremendous backlog of work, so looking for ways to ensure they aren't inventing for invention's sake is useful. It is also an opportunity to mentor and mature your teams.

Ultimately, I believe the answer is consistency through meritocracy not governance. The key challenge to a meritocratic process though is communication. Your organization must have open, consistent, frequent, and quality communication between teams. Wikis and issue tracking tools are a minimum. Social networking tools like Yammer are hugely valuable and an improvement over email because they provide broader visibility and context.

By actively choosing to use your solution, people tend to take ownership over that choice. That means they work harder to ensure it's successful. After all, if it comes crashing down, they'll look silly too. By "selling" your solution to people and having them actively choose to use it, I think you're more likely to be successful.

On the other hand, when people are given a solution and forced to use it, the reaction tends to be more negative. While they might use it, they'll have no reason to ensure it is successful. In fact, when I've been forced to use certain tools in the past due to company policy, I've found myself secretly hoping they'll fail so we can switch to something better.

While I've been on the receiving end of "governance" many times, my own solutions tend to be team or project focussed, and not organizational. As my own career progresses, it will be interesting to see how my solutions are adopted. Will I gain adoption naturally through providing a good solution, or will I take the easy way out, turning into the "governance" ogre I fear? Time will tell.

Paul Stovell's Blog

Hello, I'm Paul Stovell

I'm a Brisbane-based software developer, and founder of Octopus Deploy, a DevOps automation software company. This is my personal blog where I write about my journey with Octopus and software development.

I write new blog posts about once a month. Subscribe and I'll send you an email when I publish something new.