The Power of a Bimodal IT Model


As a tech com­pany, we’re con­stantly walk­ing a fine line be­tween sta­ble and re­li­able de­vel­op­ment and ex­per­i­ment­ing with new, in­no­v­a­tive fea­tures. We’ve learnt that the abil­ity to mas­ter both these de­vel­op­ment modes is ex­tremely valu­able for our part­ners. That’s where a bi­modal IT model comes into play. It’s the prac­tice of man­ag­ing two dif­fer­ent styles of work; one fo­cused on pre­dictabil­ity, the other on ex­plo­ration.

Lets look at these de­vel­op­ment modes in more depth. Mode 1 is your typ­i­cal house builder, who builds a brick and mor­tar house in a pre­dictable way. He im­proves and ren­o­vates the house in well-un­der­stood ar­eas us­ing well-tested meth­ods. Mode 2 is your mad sci­en­tist builder. She is an ex­plorer to the nth de­gree. She loves tin­ker­ing around with new and in­no­v­a­tive tech­nolo­gies. She might even build a shower that au­to­mat­i­cally turns on to the per­fect tem­per­a­ture de­pend­ing on the weather.

When it comes to soft­ware de­vel­op­ment, mode 1 com­pa­nies can de­liver rep­utable ser­vices that work re­li­ably and quickly, work­ing from es­tab­lished pro­ce­dures and processes. On the other hand, Mode 2 com­pa­nies are able to ex­plore what was pre­vi­ously un­ex­plored ter­rain. Ensuring you have the ca­pa­bil­ity to cre­ate pre­dictable and re­li­able tech while ex­plor­ing the un­known is the crux of a bi­modal IT struc­ture.

CTO’s and CIO’s can of­ten feel re­stricted when it comes to in­no­vat­ing. The busi­ness’ re­sources are tied up main­tain­ing their cur­rent sys­tem, mak­ing it im­pos­si­ble to de­velop new soft­ware and pur­sue other goals. That’s where a bi­modal model can work in your favour. You can use your in­ter­nal de­vel­op­ment team to main­tain the cur­rent soft­ware in a re­li­able, mode 1 fash­ion. You can then out­source the new pro­ject to an ex­ter­nal de­vel­op­ment team (like WorkingMouse). By sep­a­rat­ing the two pro­jects - in­ter­nal main­te­nance (mode 1) and ex­ter­nal in­no­va­tion (mode 2), busi­nesses utilise the bi­modal model. It also means there are two ded­i­cated teams with a clear fo­cus, help­ing you achieve your goals.

We prac­tice what we preach. At WorkingMouse we’ve sep­a­rated into small pro­ject teams who can be used in dif­fer­ent de­vel­op­ment modes. We en­sure we have the right processes in place to sup­port our in­ter­nal pro­jects while de­liv­er­ing re­li­able soft­ware to cus­tomers. Download our Bots that Code book to see how our Codebots plat­form al­lows us to utilise a bi­modal model.

Implementing a Bimodal Structure

It is im­por­tant to note that bi­modal is a style of work de­scrib­ing how to de­liver pro­jects. It does not dic­tate who should be work­ing on what type of pro­ject. It is pos­si­ble to have de­cen­tralised units that op­er­ate solely in a Mode 1 fash­ion, with other ded­i­cated de­cen­tralised units op­er­at­ing in a Mode 2 ca­pa­bil­ity. Alternatively, these IT units could func­tion so that they cover both modes of de­vel­op­ment. Bimodal is not con­tin­gent on how the or­gan­i­sa­tion op­er­ates, whether that be with a cen­tralised, de­cen­tralised or fed­er­ated man­ner.

Bimodal Goes Beyond Software Development

Even though the term bi­modal is com­monly used in the soft­ware de­vel­op­ment in­dus­try, it is not con­fined to de­vel­op­ment alone. Mode 2 ini­tia­tives may have lit­tle or no de­vel­op­ment in­volved. For WorkingMouse, our Mode 2 ini­tia­tive (Codebots) is pre­dom­i­nantly cen­tred around a process, rather than de­vel­op­ment.

Mode 2 and Agile

Mode 2 pro­jects can be dif­fi­cult to grasp. The way in which you achieve your end goal can change con­stantly. As a re­sult it’s ben­e­fi­cial to start small, it­er­ate and get quick wins on the board. You can’t spend long pe­ri­ods of time ex­plain­ing a pro­ject. People need to ex­pe­ri­ence the mode 2 method. This is where the ag­ile method­ol­ogy comes into play. Agile is cen­tred around build­ing lean, learn­ing and it­er­at­ing. The build, mea­sure, learn cy­cle makes it easy to adapt on the run. Given the un­cer­tainty of a Mode 2 pro­ject, adapt­abil­ity is an es­sen­tial char­ac­ter­is­tic. Mode 1 pro­jects are usu­ally more pre­dictable. Because of this, a wa­ter­fall ap­proach can be taken (if de­sired). WorkingMouse sup­ports both method­olo­gies. This al­lows our part­ners to de­cide how they want to de­velop.

Entry Points

Gartner pro­vides that there are three main en­try points for a Mode 2 pro­ject.

IT Driven

This is where the CTO uni­lat­er­ally de­cides to cre­ate or grow a Mode 2 ca­pa­bil­ity.

Business Driven

An ex­am­ple of this is where an ex­ec­u­tive (CEO) man­dates that the IT or­gan­i­sa­tion or a spe­cific part of the de­part­ment, re­spond to an op­por­tu­nity that re­quires a Mode 2 style of de­liv­ery.

Vendor Driven

This is where a com­peti­tor’s of­fer­ing dri­ves Mode 2 changes.

WorkingMouse has adopted a bi­modal struc­ture to pur­sue our in­ter­nal pro­jects while also work­ing on cus­tomer pro­jects. We’ve im­ple­mented the nec­es­sary processes to cater for other busi­nesses who are look­ing to de­velop Mode 1 or Mode 2 pro­jects (or both).

Discover Software


David Burkett

Growth en­thu­si­ast and res­i­dent pom

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­per­tise