Forget Bimodal IT

Nickel sitting on its edgeThere has been a LOT about bimodal IT being written and everyone is chiming in on how to manage bimodal teams. Bimodal IT is something Gartner keeps pushing, claiming 75% of IT departments will be operating bimodally in 2017 (pdf). They also claim that half of them will make a mess of it.

Why is that? It’s simple really.

Going bimodal is an unnatural way to run a team, group, or product.

If I’m an aging business in danger of being disrupted then sure, I’ll spin off a newer, more agile team to try and disrupt myself. Better to disrupt myself than to let it happen to me. Let the new team innovate and create new things while I try and get as much revenue as I can from the pre-disruption market.

Running a more rapid, innovative set of teams alongside separate teams that are essentially keeping the lights just doesn’t work long term in a healthy organization.

Not One Or The Other

Here’s the deal. IT manages systems. Some old, some new. The goal is to make sure that the function of all of those systems is operationalized as much as possible. This isn’t just to make life easier on staff. It is to make sure that fighting fires from system issues doesn’t detract from the ‘real’ work.

Everyone in IT should be given the freedom to look into new technologies that might improve either system efficiency or provide possible value to the users. Everyone in IT should be working with the business to learn what the business needs to be more effective. Some IT staff prefer to not do these things. Those are the same people you need to eventually replace.

Everything should be agile. When I say agile, I’m not necessarily talking Scrum. I’m talking daily stand-ups, pulling from a prioritized queue full of tasks across all systems, and continuous deployment. Even improving backup performance and system stability work that way. Iterative actions that allow flexibility as things change.

There may be the occasional big-bang replacement project, but that is a project, not a permanent state. The people on that project are the same ones who pull from that overall queue.

The Three Party Structure

I will concede that some technical people have a preferred way of operating but the options aren’t bimodal. The best description that I’ve seen, one that applies to all skill domains, was put forth by Simon Wardley.

Simon describes three parties, or groups, and argues that if you want to operate in a bimodal manner, you have to give something up. The three parties are:

  • Pioneers: These are the people playing with bleeding edge stuff. These are the researchers.
  • Settlers: These are the people that take the ideas discovered by the pioneers and turn them into practical things of value.
  • Town Planners: Once you have a good system, it is time to enhance, improve, scale, and operationalize. Town Planners make things into commodities.

All three require smart people. Everyone on your teams need to be able to communicate and work across the spectrum even if they primarily excel in one role. You can’t have a pioneer that can’t explain to settlers or town planners how the tech is changing. Town planners need to understand the new ideas that pioneers are investigating so they can be ready to incorporate new ideas into existing systems and processes.

There needs to be communication. There needs to be understanding. There needs to be cooperation.

Blend it Together

The teams that I’ve been on that were the most effective didn’t work in one mode. We worked across the different modes as needed. Sometimes we’d all be working to solve a problem but as we got a handle on it, some would take the reigns and ride the solution to completion while the others returned to other efforts. Everyone had primarily responsibilities but when anyone found something new that could improve another part of the whole, it was shared with those that worked on that component to see if it lived up to potential.

The best teams self-organize and get things done. There has to be a final decision maker for when there is no agreement and everyone still has to answer to the client, but not pigeon-holing people into a set mode is critical. Not only innovating, but it is also important to make sure the people on the teams have a fulfilling job.

When your staff is happy, they’ll move heaven and earth to solve a problem that impacts the team, even when they could just leave and go home.

And that is an effective team.

2 thoughts on “Forget Bimodal IT”

  1. People work with the assets and talent they have, and there’s lots of different ways to do that based upon the task(s) at hand and how well those said same assets and talent address it. Then, other people like to put a name on that way of working and call it a “methodology” or some such and put forth that it’s better than another way of doing it.

    In the end, “methodology” aside or not, you’re only as good as your team. Agile, Scrum, DevOps, bimodal, I’ve seen a lot of organizations at a lot of different levels of scale do it well on a handful of occasions, but most of the time, regardless of scale, not so much. It’s about smart, motivated people and execution.

    What’s next?

    Liked by 1 person

  2. I did not understand bimodal IT as being team and team composition. This should basically be a result of how a company positions platforms. I can very well understand that an IT strategy defines platforms for which a defensive, close-to-vendor OOTB, backoffice-type change cycle is required, while other platforms are defined to have fast paced short cycles delivery driven approaches. Team composition -and managing such team- is resulting from this. I think we see too much that we customizing core backoffice type platforms very much while setting strict change controls (impact analysis) on platforms that require agility.

    Like

Comments are closed.