Showing posts with label organisation design. Show all posts
Showing posts with label organisation design. Show all posts

Organizing for continuous delivery: redefining the role of a functional specialist lead


Power struggles are bad for business. Organization design should try to minimize power struggles. One way to do so is to have one power center per business outcome. Let’s say the business outcome is the success of a software product. We put one person in charge - say we call her the product manager. We make this person accountable for product leadership (quality, innovation, relevance), market leadership (revenue, mindshare) and customer satisfaction (support, training).
We don’t want to create multiple power centers in the form of specialist leads e.g VP of sales, head of marketing, director of engineering etc. in addition to the product manager. Yes, we need leadership in multiple specializations but that’s more about autonomy (influence) than about authority (power). As this pithy HBR post points out:

Managers create circles of power while leaders create circles of influence.
This ties in well with what I said at devopsdays Berlin in May this year. Continuous delivery needs cross-functional teams. But a matrix org with many functional specialist heads has too much potential for territorial power struggles to deliver effective cross functional teams. On the other hand, subordinating all functional specialist leads to the product manager robs them of their autonomy (and motivation). 
I suggest that we let the functional specialist leads retain autonomy but take away their authority (control over resources). Have specialist leaders by all means. Make sure they sit on the same level in the org hierarchy as product managers. But let the hierarchy be one of power/influence rather than just power. The product managers control resources - team and budget. It is an unconventional set up - one that tries to retain the autonomy/influencer attributes of specialist leads without the risk of devolution into non-collaborative, empire building behaviors.

Why continuous delivery needs devops, and why devops needs infrastructure-as-code

Update 02-Apr-13
Just came across this detailed relevant talk by Reinertsen - the author I reference for silo reduction and batch size reduction.


http://www.infoq.com/presentations/lean-product-dev
===============================================



Update 26-Oct-12

Slides, with notes
=========================

I'll present on this topic on 25th October 2012 as part of a ThoughtWorks Studios webinar series on continuous delivery. Please register from the webinar page.

Abstract
Continuous delivery and devops have gone mainstream, at least in terms of mindshare. As a result, a lot of vendors have jumped onto the bandwagon. Most products that have anything to do with deployment now try to associate themselves with devops and continuous delivery. In this webinar, Sriram will try to clear the air in a product independent manner. He will also cover common devops anti-patterns and explain the idea of infrastructure as code.