Increasing flexibility and agility Archives

Increasing flexibility and agility

In this series of posts I discuss how you can design organizations for greater flexibility and agility,

Fighting complexity with subtractive change

November 14, 2021 By Nicolay Worren Leave a Comment

Internal complexity seems to increase gradually over time in most organizations.

Earlier this year, a study was published in the prestiguous journal Nature that looks at the underlying causes of this tendency.

The authors conclude that there is a cognitive bias, which they call subtraction neglect.

As the name suggests, it leads people to add things and to ignore the possibility of subtracting things in order to solve a problem.

The authors mention some initial observations that led them to examine this issue.

For example, they analyzed improvement ideas that were submitted to a new university president. Of the 651 proposals, only 70 (11%) were subtractive, that is, involved removing something or stopping an activity.

To study this tendency more systematically, they set up a series of experiments.

In one of the experiments, they showed the participants drawings of a minigolf course and asked them for ideas about how to improve it. The experimenters coded whether the ideas were additive (e.g., “add a windmill”) or subtractive (e.g., “remove the sand trap”).

It turned out that only about 20% of the ideas were subtractive.

So with regards to organizational design, this may explain why we tend to add new roles, units, processes and reporting lines on top of the old ones, instead of removing and simplifying the organization.

Or, in our personal and professional lives, why we commit to too many goals and activities and end up with overburdened schedules (I am guilty of that myself.)

However, all hope is not lost.

In the minigolf experiment, they did another variation, where they offered cues, for example, reminding participants that they could “add or substract”. Offering a cue increased the likelihood that participants would submit a list with at least one subtractive idea.

This suggests that by raising awareness of the issue, we may be able to counteract subtraction neglect, at least to some extent.

In another recent article, Denise Rousseau suggests that this should be a key concern for everyone interested in organization development and change:

Learning how to subtract things is critical to overextended people and organizations—and a new frontier for change scholars and practitioners. (…) I suggest that change scholarship and practice incorporate subtractive change into the suite of change processes they recognize, study or deploy.

She adds that not all subtraction is good.

We need to distinguish between subtraction that adds value, by removing unecessary elements, and subtraction that removes elements that we actually need for the organization to function.

What are the appropriate organization design methods that we can use?

I think many of the methods and principles that I have discussed on this blog in the past are relevant.

For example, the proposal by Prof. Nam Suh to periodically start from scratch and re-set the system. Or, in the words of organization development expert Paul Tolchinsky – do a yearly “Spring cleaning” of the organization instead of just assuming that everything should continue the way it is.

If we you have ideas for how “constructive subtraction” can be accomplished, I would like to hear from you – feel free to add a comment below.”

Implementing “Agile at scale”: The aftermath

October 27, 2020 By Nicolay Worren 2 Comments

I am all for agility and flexibility – we need more of that in large companies.

But I have long been a sceptic of “agile at scale”.

I wrote a blog post about it 2018.

A recent article confirms many of the concerns that I described then.

The article was published in the California Management Review (It is written by Maria Annosi, Nicolai Foss, and Antonella Martini.)

It is based on a detailed 5-year case study of a large telecom company (called “Company E” in the article) that implemented agile methods.

The authors interviewed more than 100 people at the team level, middle management, and top management levels, and also analyzed internal document and archival records.

Here are some noteworthy quotes from the article:

Middle management played a key role in facilitating agile implementation, but they often struggled to make sense of the changes themselves. Charged with implementing such changes, they experienced intense confusion (…)

(…) management of Company E increasingly had to realize that its adoption had massive, unanticipated, and far from beneficial consequences

(…) the data revealed high coordination costs due to relevant information being increasingly dispersed across different teams

(…) the application of Agile reduced individual employees’ motivation to learn

Our findings suggest that the innovation goals were not achieved.

Getting what you ask for

The authors write that the effects were unanticipated, but are they that surprising?

If we look at the effects that they describe, arent’ they precisely what you would expect based on the agile philosophy?

According to the agile approach, you should work in “sprints” and shorten the delivery cycles. Well, isn’t it natural, then, to expect that the consequence will be more short term focus, more stress, and lower quality (with less time for testing)?

According to the agile approach, you should minimize written documentation. Isn’t it natural to expect that there would be less knowledge transfer and more difficulty in accumulating shared knowledge about products and processes as a result?

According to the agile approach, you should decentralize decisions to autonomous teams. Without a simultaneous focus on integration across units, isn’t it natural to expect that people will focus more on internal team matters, and spend less time on coordinating with other teams?

All of these problems were observed in the “Company E”.

Paradoxically, an approach that was intended to lead to more innovation actually led to less innovation for this company, as measured in the number of patents or new products.

How did we get here?

I have wondered why agile methods have become so popular.

(It has even invaded my home…one day, late at night, my wife (who works in a government agency) was busy going through a big binder. I asked her what she did. She told me that she was preparing for a test to become a certified scrum master…)

There are probably multiple reasons. One is that most of the consulting firms have marketed the approach heavily. And it is becoming institutionalized with standardization and certification.

Another may be the influence of Spotify. They created a video about the implementation of agile in their organization. It seems like it has inspired people in many other organizations.

The video itself is rather good. But some key factors about the company are left out, and it is hard to say what you can generalize from it.

For example (and now I am guessing), Spotify may have a very good and well structured product architecture (or rather, software architecture).

This may make it relatively simple for them to set up the right teams and allocate tasks. However, firms that don’t have a good understanding of their products and processes may struggle with this.

And as we know all too well, “one size does not fit all”. As I have written about many times on this blog, we need to understand the local context, analyze and diagnose our organization, and tailor the solution to our goals and challenges.

Only then can we have a hope of succeeding.

Do small and innovative firms need “structure”?

September 14, 2020 By Nicolay Worren 4 Comments

Photo by fauxels from Pexels

“Structure” is associated with large and well established firms that serve stable and mature markets.

Such firms need the clarity and predictability provided by roles, hierarchy, rules, procedures, and control systems. Innovation is not so important for such firms; efficiency is what counts.

Small firms, and in particular, start-ups, require a more fluid, agile, and flexible form in order to grow and succeed. Speed counts. Having a (formal) structure would slow things down. It would also hamper innovation, which requires freedom from constraints.

Sounds logical, right?

It is what students have been taught in business schools: Efficiency requires a “mechanistic “organization, while innovation and change require an “organic” organization.

Yet a growing number of studies is challenging this view.

Several empirical studies have been conducted on this topic. They have been published in well-known journals, and are based on data from hundreds of small, fast growing firms.

Let me mention the key findings from three studies (see references below).

The first study was conducted by Wesley Sine from Cornell University with two colleagues.

They looked at several indicators of formal structure, including the degree of formalization of roles, the degree of specialization among the employees, and the number of executives relative to employees (which they call “administrative intensity”). The data came from 449 internet start-ups.

Conclusion: The firms with more role formalization, more specialization, and more administration outperformed the others.

Another study collected data about 1411 Dutch firms. The findings are similar:

..we find hierarchical, centralized structures with strongly specialized employees to occur frequently and to perform well in terms of growth.

A third study is based on data from 2,431 high-tech start-ups in Germany. It considered the role of hierarchy, and introduction of middle managers more specifically.

The autors explain that entrepreneurs are usually reluctant to introduce middle managers, because they fear that it will lead to bureaucratization and less innovation.

Instead, they find that the opposite is the case. In fact, among these firms, hiring middle managers early increased the chance of launching product innovations by 33% (!).

So the answer seems clear: Small and innovative firms do need structure.

In his book “The unicorn’s shadow”, Wharton professor Ethan Mollick concludes:

…the founders that pay attention to the boring details of people and structure will succeed where others fail; a strategic focus on growing your team wisely is the most important thing you will do for long-term success.

You can find the studies referenced here:

Grimpe, C., Murmann , M. and Sofka, W. (2019). Organizational design choices of high-tech startups: How middle management drives innovation performance. Stratagic Entrepreneurship Journal, 13, 359–378.

Meijaard, J., Brand, MJ. & Mosselman, M. (2005). Organizational Structure and Performance in Dutch small Firms. Small Business Economics. 25, 1, 83-96.

Sine, W.D., Mitsuhashi, H. & Kirsch, D.A. (2006). Revisiting Burns and Stalker: Formal structure and new venture performance in emerging economic sectors. Academy of Management Journal, 49(1), 121–132.

Organization design implications of COVID-19

April 27, 2020 By Nicolay Worren 4 Comments

What are the implications of the coronavirus on how we lead and organize firms?

I have been pondering this issue (as I assume many of you have done, too, in this period). I don’t pretend to have the final answer; nobody does in this time of uncertainty.

But let me at least offer my thoughts regarding three topics that I think are important.

I group them according to the time horizon: Short term, medium term, and long term.

Short term: Handling the coordination load

Although most countries are gradually easing the lock down, most people are still working from home, and many of us have to home-school our children and work at the same time.

Most of the time we can dedicate to our job may be spent keeping up with email and participating in one Zoom meeting after the other.

So basically, people (at least those who are parents) have most of the same responsibilities as before, but with less capacity.

In addition, video conferencing drains your energy pretty fast.

The more time you spend coordinating with others, the less time you have available to perform tasks that require individual effort.

This leads me to the first intersection between COVID-10 and organization design.

The number of people that every employee has to coordinate with is not only dependent upon the tasks themselves, but also a result of the design of the organization.

Simplify your organizational structure, and you reduce the “coordination load” on people (see the links below for more details).

Medium term: Downsizing

The next question is what consequences the crises will have. As I write this, economists estimate that there is a very high chance that a recession will follow.

Many companies have already started cost cutting efforts, and many more will need to downsize and cut costs later in the year.

Whether a downsizing affects the basic design of the organization depends on the degree of severity.

If you need to downsize about 10-15% of your staff, you may (in most cases) keep the existing structure and remove the required number of positions from the organization chart.

I am not saying that this is easy; it never is, but my point is that you don’t necessarily need a re-organization on top of the downsizing (You may have to re-design roles, though, in order to make sure that the tasks carried out by the people who leave are transferred to others.)

But with a more severe downsizing, you can’t just remove positions, you also need to re-design the formal structure.

First, the span of control will become smaller when positions are removed (as indicated in the illustration above). This will require a re-grouping of roles into a new unit structure.

Secondly, the overall size of the organization may also decrease so much that you should reduce the number of management layers.

So in other words, even though the circumstances are exceptional, the key issues that need to be addressed are the same as in any re-organization.

Longer term: From agility to resilience (?)

What about the longer term? What does this crisis mean for how we design and manage organizations?

Julian Birkinshaw, a professor at the London Business School, has suggested that building resilience is the new boardroom imperative. As he writes in Forbes magazine, agile rhymes with fragile.

Unfortunately, there is no consensus on what a resilient organization looks like.

It is easier to say what is it not.

For example, even before the current crisis, there were concerns about the concept of lean manufacturing and logistics.

Critics pointed out that it focuses too much on efficiency improvements, and makes the supply chain more prone to disruptions.

Lean implies a reduction in buffers and tighter interdependencies between the parts. This means that there is a greater probability that a disruption in one place will propagate through the entire system.

There’s a nice analogy in the local newspaper that explains this principle:

In the city where I live, Oslo, there are plans for a new addition to the university hospital. The architect has drawn a modern, tall building.

It is intended to be cost effective and facilitate an effective “horizontal” and “vertical” patient flow.

We can draw the contrast to the old hospital in Oslo (called Ulleval). It was built during the 1880’s, in a period when the city was plagued by diphteria and scarlet fever.

Not surprisingly, then, it consists of several low rise buildings, well separated from each other.

What was considered old fashioned should now be considered the modern solution.

Relevant tools and frameworks:

Should you use agile principles to organize a firm?

October 17, 2018 By Nicolay Worren

“Agile” was intended as an approach for managing software development teams.

But it has become one of the hottest business trends – and it is no longer restricted to software firms.

Many leaders – more than 90% in some surveys – now say that they want their entire company to work in “agile” ways.

But can you “scale” agile principles, intended for teams, to organize an entire organization?

Traditionally, software people used to create extensive plans for how they work. The dominant approach used to be the “Waterfall” method, where you basically analyze, design and budget everything up front. Then you monitor progress as you write the code against key metrics that were set in this planning process (cost, time and scope).

The “Agile manifesto” was published by a group of software developers in 2001. It was a protest against the Waterfall approach, which was seen as too cumbersome and inflexible. A new set of principles were proposed as an alternative.

There are many different definitions of Agile. But in software development it is typically associated with three key features (illustrated with the icons above):

Speed – one works in “sprints”, typically 2 week periods, and try to release small things early and often
Teams – one works in small teams that are empowered to take decisions
Customer involvement – one receives frequent customer or user feedback on the releases

We can add a fourth element: Face to face communication. The authors of the agile manifesto preferred face to face communication over written communication.

This approach makes a lot of sense, and has been widely adopted.

But unfortunately, it has gone too far.

Agile has become a fad. It’s being sold as a universal prescription to any kind of affliction that a company may suffer from.

Instead of starting with a diagnosis, leaders now start with a conviction that Agile is the right way. Or they try to copy agile companies, like Spotify.

Not surprisingly, the reality on the ground is different from what is being promised.

Trying to copy another firm’s model is a terrible way to do organization design (read, for example, this tale).

It is also worth noting that the people who adopted Agile first – IT leaders – now have doubts about the merits of the approach.

In a recent survey of 150 CIOs (Chief Technology Officers), 34% of all Agile projects were considered partial or complete failures. More than half of the CIOs indicated that Agile is a discredited approach (see these slides from a presentation I gave recently).

What is the explanation?

Agile was developed to support flexibility at the team level, and basically prescribes (local) experimentation and informal ways of working as the solution.

An organization is usually not one team, however. An organization consists of multiple teams that each develop and deliver a piece of a larger system.

The teams depend on each other. Or in academic speak, there are interdependencies between them. This is simply not addressed in the agile approach, which only speaks of “the team”.

The implication is that if we want flexibility at the organizational level, we need to ask ourselves how teams (or other sub-units) can best coordinate and integrate their efforts.

What we need is flexibility (e.g., reconfigurability and scalability) at the organizational level, not only at the team level.

This is simply impossible by using pure Agile methods.

You need a certain degree of planning, coordination, and control to do this. You need an “architeture” that describes the overall system that you are developing, and which specifies how the different pieces fit together.

And somebody needs to be responsible for this overall planning and coordination.

In IT firms, this role is called “IT architect”.

This role lost prestige with the introduction of Agile, but it is now being reintroduced in many firms (There’s an excellent article by Martini & Bosch on the functions that IT architects perform and why they are needed. You can find it here.)

So paradoxically, you need to use “un-agile” methods if you want to scale Agility.

For firms that want to increase flexibility, my recommendation would be to use the modular approach as a guide.

Unlike the agile approach, which only considers one level (the team), there are two levels in the modular approach: The architecture (or overall structure), and the modules (or components).

A key point in the modular approach is that the most cost-effective way to achieve flexibility is by combining planning and formal structure (or architecture) with local experimentation (within modules).

The architecture specifies the overall design (of the process, product, or organization), including the interfaces between the modules (or sub-units or components).

By formalizing and “freezing” interfaces for a certain time period, you actually stimulate innovation at the modular level, because the teams and sub-units can now introduce new innovations without forcing other teams and sub-units to make costly changes (this is avoided if one works within the defined interfaces).

In my book I describe how one can use modular principles to design an organizational model. The key is to establish small, semi-independent sub-teams that can be reconfigured according to the circumstances.

However, I am not saying that we should forget the Agile approach completely. The intention is good and the principles are sensible in most cases.

But you need to modify it quite a bit to make it scale.

Video

I gave talk about this topic at two HR conferences in 2018. One has been posted on YouTube.

Three misconceptions about the matrix organization

Acknowledgements: Icons by Daniel Falk, Annette Spithoven and Sharon Showalter from the Noun Project.

Fighting complexity with subtractive change

Implementing “Agile at scale”: The aftermath

Do small and innovative firms need “structure”?

Organization design implications of COVID-19

Should you use agile principles to organize a firm?

Sign up to get updates via e-mail

Sign up to get updates via e-mail

About

Recent Posts

Search

Sign up to get updates via e-mail