It Always Comes Down to Leadership

I think Todd Biske was bold in writ­ing a book around SOA Gov­er­nance that focused mostly on the peo­ple side of things. From mem­ory, two key points Todd made were:

1. Edu­cate peo­ple on the gov­er­nance poli­cies, and
2. Man­age ser­vices like a prod­uct, rather than a project.

I’ve thought quite a bit about the book, which I liked a lot (and ref­er­ence quite reg­u­larly), and the things I learned came out in yet another form at today’s Cloud Com­put­ing Expo. I was talk­ing about a best prac­tice for suc­cess­fully imple­ment­ing cloud com­put­ing in the enter­prise. In par­tic­u­lar, how to build momen­tum and drive a cul­ture of col­lab­o­ra­tion… and I said:

Tell them what you want them to do, and they’ll resist. Tell them why you want them to do it, and they’ll amaze you with the ways they get it done.

It’s inter­est­ing… the way we com­mu­ni­cate in the enter­prise. It often doesn’t reflect our goals or the trust we put in the peo­ple around us.

Devel­op­ers are often known for their “not invented here” atti­tude… and in my expe­ri­ence they (and really any nor­mal per­son) resist change in how they get their job done. What worked in the past really has the upper hand when decid­ing what to do in the future.

When try­ing to build momen­tum for a new tech­nol­ogy, walk­ing around telling peo­ple what to do is way more likely to upset them (and meet resis­tance) than explain­ing (and show­ing) why you would like them to do some­thing different.

By telling peo­ple what to do, you at some level are telling them that what they’ve done has not been suc­cess­ful. That’s prob­a­bly not what you mean. How­ever, tell them why you want some­thing, and ask for their help, and the under­ly­ing mes­sage is “you’ve done well in the past, so here’s some­thing new.” Even when you put rules in place (gov­er­nance rules, if you will), you can still edu­cate as to the “why” and get more accep­tance than you would oth­er­wise. And, if you have the oppor­tu­nity to get input, and adjust your rules with feed­back, even bet­ter. Much better.

This approach is a sub­tle, but effec­tive difference.