Continuing our discussion that I mentioned in my last post, Greger Wikstrand tweeted the following:
I encourage you to watch the video, it’s short (7:39) and makes some important points, which I’ll touch on below.
Serendipity, when it occurs, is a beautiful thing. Serendipity can occur when heads-down order taking is replaced with collaboration. Awareness of business concerns on the part of IT staff enhances their ability to work together with end users to create effective solutions. Awareness, however, is insufficient.
Woody Zuill‘s early remarks about the bureaucracy that gets in the way of that serendipity struck a nerve. Awareness of how to address a need does little good if the nature of the organization either prevents the need from being addressed. Equally bad is when a modest need must be bloated beyond recognition in order to become “significant” enough for IT intervention. Neither situation works well for the end users, IT, or the business as a whole.
So what’s needed to remedy this?
In “Project lead time”, John Cook asserted that project lead team was related to company size:
A plausible guess is that project lead time would be proportional to the logarithm of the company size. If a company with n employees has a hierarchy with every manager having m subordinates, the number of management layers would be around logm(n). If every project has to be approved by every layer of management, lead time should be logarithmic in the company size. This implies huge companies only take a little longer to start projects than medium-sized companies, and that doesn’t match my experience.
While I agree in principle, I suspect that the dominant factor is not raw size, but the number of management layers Cook refers to. In my experience, equally sized organizations can be more or less nimble depending on the number of approvals and the reporting structure of the approvers. Centralized, shared resources tend to move slower than those that are federated and dedicated. Ownership increases both customer satisfaction and their sense of responsibility for outcomes. Thus, embedding IT staff in business units as integral members of the team seems a better choice than attempting to “align” a shifting set of workers temporarily assigned to a particular project.
The nature of project work, when combined with a traditional shared resource organization, stands as a stumbling block to effective, customer-centric IT. IT’s customers (whether internal, external, or both) are interested in products, not projects. For them, the product isn’t “done” until they’re no longer using it. While I won’t go so far as to say #NoProjects, I share many of the same opinions. Using projects and project management to evolve a product is one thing, I’ve found project-centric IT to be detrimental to all involved.
Having previously led embedded teams (which worked as pseudo-contractors: employed by IT, with the goals and gold coming from the business unit), I can provide at least anecdotal support to the idea that bringing IT and its customers closer pays dividends. Where IT plays general contractor, providing some services and sub-contracting other under the direction of those paying the bills, IT can put its expertise to use meeting needs by adding value rather than just acting as order-takers. This not only allows for the small wins that Woody Zuill mentioned, but also for integrating those small wins into the overall operation of the business units, reducing the number of disconnected data islands.
Obviously there are some constraints around this strategy. Business units need to be able to support their IT costs out of their own budget (which sounds more like a feature than a bug). Likewise, some aspects of IT are more global than local. The answer there, is matching the scope of the IT provider unit with the scope of the customer unit’s responsibility. Federating and embedding allows decisions to be made closer to the point of impact by those with the best visibility into the costs and benefits. Centralization forces everything upwards and away from those points.
Operating as a monolithic parallel organization that needs to be “aligned” to the rest of the organization sounds like a system that’s neither effective nor efficient, certainly not both. When the subject is the distance between the decision and its outcome, bigger isn’t better.
Form Follows Function 
Isn’t what you are describing the failure of the concept of “economy of scale”? I suspect that while a monolith is a bad idea in some processes like IT, it has value in others (like access to cash). The issue is we bad a distinguishing where it works and then backing away when is messes the works up.
LikeLiked by 1 person
Exactly – we gravitate toward the ends of the spectrum and avoid the middle where the answer so often lies. And backing away from mistakes? Fuggedaboutit!
Economy of scale applies to most things, it just doesn’t apply infinitely. Some things are better centralized and more bureaucratic (can you imagine if GE’s CFO adopted “move fast and break things” as a motto?) while others whither and die in that environment. “One size don’t fit all” is one of my recurring themes.
LikeLike
Coming back for round two – I don’t want to minimize the problem of the lack of customer-centricity because that is reinforced by the poor organizational structure and aggravates the effectiveness problem. The pigeon pattern isn’t working!
LikeLike
I have written a lengthy response to this blog post on LinkedIN: https://www.linkedin.com/pulse/serendipity-greger-wikstrand
LikeLiked by 1 person
My response here: https://genehughson.wordpress.com/2015/11/16/inflection-points-and-the-ingredients-of-innovation/
LikeLike
Pingback: Inflection Points and the Ingredients of Innovation | Form Follows Function
Pingback: Organizations and Innovation – Swim or Die! | Form Follows Function
Pingback: Changing Organizations Without Changing People | Form Follows Function
I tend to disagree with Mr. Zuill on nearly everything, it seems, with the possible exception of the banjo, and this is anything but an exception.
Cries of “bureaucracy” often come up at inflection points in the growth of an organization, but that doesn’t mean that they’re justified. I’ve written a longer post on this, “Speed vs. bureaucracy: management issues confronted by companies in transition”, which can be found here: http://www.peterkretzman.com/2008/08/21/speed-vs-bureaucracy-management-issues-confronted-by-companies-in-transition/. Also related is a post of mine called “Cementing a formal work initiation process for IT projects” at “http://www.peterkretzman.com/2008/01/25/cementing-a-formal-work-initiation-process-for-it-projects/
In a nutshell: you don’t WANT people working on hundreds of things, most of which tend to get spawned in random hallway conversations. Letting that happen is the kiss of death for productivity and even worker satisfaction in the long run. As I wrote, “The result is that lots of stuff ends up getting worked on informally, and resources get overcommitted and stretched, and both quality and timely delivery suffer greatly.”
Structure is not bureaucracy. Planning is not antithetical to serendipity.
LikeLike
Agreed: structure isn’t bureaucracy, planning isn’t antithetical to serendipity, and too little control is at least as problematic as too much. When the knob is too far to one side, too little benefit is realized for the cost incurred due to overhead. When it’s too far to the other side, time wasted because no one knows who’s responsible for what or exactly how it’s supposed to be done swallows up value.
In my opinion, two principles apply. The first is to ensure that policies are coherent, effective and as efficient as possible subject to the first two (efficiently doing the wrong thing or something that cancels out another policy isn’t helpful). Regular reviews should ensure that processes continually fit these criteria. The second is pushing decisions down to an appropriate level. When someone makes decisions that rightly could have been made by a subordinate (generally characterized by all the leg-work was done at a lower level and they’re just double or triple-checking compliance), then they are introducing a bottleneck and taking up time that could be spent on concerns more appropriate to their own level.
Long story short, organizations are social systems and intentional design is required for them to function well.
LikeLiked by 1 person
Pingback: Innovation on Tap | Form Follows Function
Pingback: A Meaningful Manifesto for IT | Form Follows Function
Pingback: Accidental Innovation? | Form Follows Function
Pingback: “Want Fries with That?” | Form Follows Function
Pingback: Building a Legacy | Form Follows Function
Pingback: Trash or Treasure – What’s Your Legacy? | Form Follows Function