• rm@rmbastien.com

Short post

Note on the Notes

Notes on the Synthesis of Form

This book is in my view the equivalent of the Old Testament for designers and architects. It dates 1964. Although another Alexander book from 1974, The Timeless Way of Building, has been raised to quasi cult level as it paved the way to very important principles in software design, I believe that this seminal work from the same author is more profound.
In its 1971 preface, Alexander wrote this:

“No one will become better designer by blindly following this method, or indeed by following any method blindly. On the other hand, if you try to understand the idea that you can create abstract patterns by studying the implication of limited systems of forces, and can create new forms in free combination of these patterns – and realize that this will only work if the patterns which you define deal with systems of forces whose internal interaction is very dense, and whose interaction with the other forces is very weak – then, in the process of trying to create such diagrams or patterns for yourself, you will reach the central idea which this book is all about.”

That’s the high-cohesion-low-coupling principle in its most earliest form. The fact that I can just read the preface and grasp what he meant in this dense sentence is both a sign of the influence he has had on future generations, and the importance of the principle.

You will also note the wise recommendation about following methods without thinking.

The man is born on the same year as my father: 1936

Silo Generator #3

The two previous silo types could be labeled as structural silos. They are almost permanent and vary only after major reorgs or when applications are introduced or retired. The third one, the project silo, is the most damageable type of silo.
Although projects and their rigorous management are an absolute must for any organization to govern change endeavors, their very nature and the absence of strong counterbalancing mechanisms make projects temporal silos.
Because all projects are temporary endeavors with a start and an end date, anything that happened before is not managed within the project, and all that happens after is not either taken into account.

Learn more about how silos of all sorts that hamper business agility: https://rmbastien.com/book-summary-the-new-age-of-corporate-it-volume-1/
#CorporateITGameChange #ITMeasures #ITQuality #Sustainability #BusinessAdaptability

Silo Generator #2

The IT function is usually structured in a way to align itself with lines of business, which extends the LOB silo into equivalent silos within corporate IT.

Furthermore, IT teams are also aligned around applications, an ensemble of IT components that serves a LOB or a major business process.

Technology and knowledge walls are nurtured by those IT application teams that slowly build little fiefdoms based on the uniqueness of their application and a privileged relationship with the sponsoring business unit.

Learn more about how silos of all sorts hamper business agility: https://rmbastien.com/book-summary-the-new-age-of-corporate-it-volume-1/
#CorporateITGameChange #ITMeasures #ITQuality #Sustainability #BusinessAdaptability

Silo Generator #1

In most organizations of a certain size, IT budgets are allocated by business units, roughly following the organizational chart.  Business units need to present their investment projects which invariably require to purchase, develop or modify some information system component.  In many industries, business projects are often quasi exclusively made of IT activities.  The investment projects presented do need to show positive business returns when not clearly proven financial returns on investment (ROI).

But very often, the costs and the benefits of a given project are aligned with a corresponding business unit.  This impedes the sharing of IT resources across these lines of business.  It also hampers the creation of IT assets that could be eventually shared with other units.

Regardless of the benefits they provide, the more IT assets you have, the more you will spend in future change endeavors.

Learn more about how silos of all sorts hamper business agility: https://rmbastien.com/book-summary-the-new-age-of-corporate-it-volume-1/

Complex But Not-So-Adaptive

How the Usual Engagement Model Doesn’t Foster Quick Self-Adjustment in Corporate IT

Your organization is a complex, open system[1]. Open, because it needs to interact with its environment to exist. Complex because it is made of a great number of interacting components, is hard to understand, is difficult to change and often yields unpredictable results. 

The General Systems Theory and its adaptive cousin Cybernetics have been around since the mid-20th century and still provide a useful, high-level understanding of what systems are and how they work. At the most distilled level possible, adaptive systems —such as your organization— can be viewed with as little as a box and a few arrows, as shown in figure 1.  

Your organization is a complex, open system[1].  Open, because it needs to interact with its environment to exist, and complex because it is made of a great number of interacting components that are hard to understand and change with unpredictable results.  The General Systems Theory and its adaptive cousin Cybernetics have been around since the mid-20th century and still provide a useful, high-level understanding of what systems are and how they work.

At the most distilled level possible, adaptive systems —such as your organization— can be viewed with as little as a box and a few arrows, as shown in figure 1.

Figure 1

The grey box is your organization, a complex system.  What’s inside the grey box is of little importance at this point; it simply represents daily interactions happening within your business.  Your organization is a system, with its inputs, its outputs. Inputs can be anything that gets in, from the obvious resources (e.g. financial, natural, human, etc.) required to produce the output, but also, all other environmental inputs that your organization requires to take into account (e.g. legal, social, cultural, and more).  Outputs are what your organization aims at providing to justify its existence.  These outputs are targeted at customers or whomever benefits from what you are producing.    

This highly-simplified view of your organization is to allow me to draw your attention to something very important: your organization is an adaptive system.  It adjusts itself, as most adaptive systems do, or it would have died long ago.   Adapting means changing the internals of the system —the grey box— so that it continues to receive its inputs and to produce its outputs.  In order to survive through adaptation, your organization benefits from a feedback loop, which provides useful data about how well the system is doing. 

For most organizations, this response takes the form of ‘customer feedback’.  Feedback is sought through mechanisms such as surveys, focus groups and other tools to get better information on how happy the customer is about what your organization is doing.  But the most important feedback information type of all —the most effective one at triggering actual adaptation of your organization— is sales. 

Sales can be called market segment penetration, gross revenue, property taxes, or traveler miles, but let’s use that word to represent revenues coming back from your organization’s outputs. Positive feedback of this nature will signal your system to continue to operate in the same fashion.  Negative results in sales will trigger rapid change.  An important detail about sales: not only does it provide a very effective feedback, it also has a short to mid-term impact on one crucial input to your system —namely, financial resources.  If sales plummet, so do revenues, and revenues from sales represent, for most organizations, the sole source of financial inputs. Sales feedback is directly linked to the survival of the system, to the viability of your organization. This is one of the reasons why this type of feedback is so effective at affecting change.

The feedback loop allows your business to adapt.  One of the most effective types of response is revenue (or any other variation), since it has a direct impact on the existence and survival of your organization.

What about corporate IT in this simple but effective scheme? One could rightfully point out that the IT function of the organization is simply one more component within the complex system.  That’s true, but it would not serve the demonstration well.  Furthermore, IT’s business is not your business —unless of course your business is IT, in which case this whole demonstration does not apply to you.  Corporate IT’s business is to provide to your organization goods and services that compose the technological solutions that support the value streams and capabilities that allow your organization to still be in business.  Corporate IT has always been and still is a support function to the greater whole, regardless of the levels of collaboration and teamwork between IT and non-IT staff in your organization.  This statement might look hard or even outdated in light of the current trends of meshing business and IT and declaring out-loud that it sums up only ‘one team’.  This has great value at the shop-floor level to create processes and instill a culture that promotes efficiency. Whether you’re in the road construction industry and make very little use of information technologies, or you’re in the banking industry and your operations are totally meshed with IT, I nevertheless insist: it does not change IT’s position as a support function to the greater whole.  Corporate IT teams are composed of individuals with clearly different education, training, work culture and career paths than the rest of your organization.  They are not in the business of off-shore drilling, commodity investment, communications, banking, or social caretaking.

Now let’s add to this simple scheme another complex system representing corporate IT.  This function of yours can be viewed as a provider to your business within a larger value chain.  IT’s inputs are likewise resources comprised of technical apparatus, skilled individuals, and projects that provide requirements and funds for the IT function to create as outputs the technological solutions that will mesh into your bigger business’s value streams. This interaction is depicted in figure 2.  

Figure 2

So far so good, right? The latter figure looks like a copy-paste of figure 1. It is indeed very similar, at least from a cybernetics point of view. But there is a catch, and it hides itself in the feedback loop.  The most effective feedback mechanism, sales, is not part of the equation. 

In the case of your own business, customer feedback through focus groups or surveys is collected, analyzed and leads to action because it will help improve sales, or at least help you understand why sales are not what they should be.  If you don’t make money, your business imperatively has to change, or will soon die.   But in the case of the IT function, something crucial is absent for there is no survival component; no presence of the ultimate incentive for improvement.  

Figure 3

There isn’t any survival component that could keep your IT staff on the alert. But there is more: they witness, from year to year, a steady flow of IT investments coming from your business. Projects come and go, priorities fluctuate, business strategies evolve, but the level of IT investment is in general correlated to the financial health of your business as a whole.  It is certainly not tied in any way to the level of satisfaction you have towards the corporate IT subsystem, or to the feedback given.

Corporate IT’s business success is totally dependent on your own business success.  In three decades of working in corporate IT, I’ve seen budgets vary, waves of layoffs, staff optimizations, outsourcing, offshoring and nearshoring.  But never have I seen IT-budget variations based on pure IT performance.

That is why the IT complex system can delay adaptation for quite a lengthy period of time. As long as the mother system —your business— can adapt itself and survive in its respective industry, corporate IT has little to no survival twist to the feedback it receives.

How effective would your organization be at listening to your customers, collecting feedback, or analyzing their behavior if it wasn’t linked, directly or indirectly, to sales increase?  How good would you be at rapidly adapting your business if you had witnessed, for the past decades, an uninterrupted flow of yearly funding, always commensurate with your client’s financial health, regardless of its satisfaction towards your products or services? Probably a pale imitation of what your organization can do today to improve customer experience or optimize revenue streams. 

And pale it is, indeed.   In this article, I describe the truly important measures of performance in corporate IT.  You will discover that job-keeping accountabilities are always paired with quantitative measures of performance.  There are two broad categories of accountabilities for corporate IT teams. One represents the run-of-the-mill responsibilities for which there is little space left for interpretation. These include the availability of systems, application response time, pace of deployment of new versions, call-center wait time, new employee set-up delay, etc.  This category is definitely the one for which corporate IT is best equipped, tooled and prepared. It is no coincidence that the run-of-the-mill chores of IT are also the ones that are best supported by cross-industry standards, are regularly purchased from third parties, can be outsourced more easily, are the most easily auditable and are supported by the most comprehensive set of benchmark services.  When performance issues in your work can directly lead to dismissal or when the provided service can be purchased from external sources, you’ve got the survival component mentioned above.

The second category of corporate IT accountabilities is related to its capacity to provide business change through new or revamped IT-based solutions.  This includes the realm of investment projects, deployment of new platforms, digitalization, and all the names given to the endeavors that require mobilizing business and IT to deliver something new that will make your business strive. This category is supported by little-to-no cross-industry standards, is highly customized to your company, doesn’t get outsourced easily, is costly and difficult to audit, and is supported by benchmarks that are too high-level or don’t fit with the peculiarities of your organization. That’s why most business people fall back on the only quantitative feedback they can understand: on-time and on-budget metrics. But there is a severe limitation to the effectiveness of these enshrined measures; namely the budgetary and temporal targets are set by the same team that is being measured for their attainment.  IT people do lose their jobs for not attaining such targets but it is fair to say that these are the rare cases. The impact of failure in this second category is nowhere near the acuteness of the repercussions of a faux pas in the first category.   There is no survival component in the latter.  

The rest of the feedback for change comes in the form of qualitative appreciations that are admittedly useful but do not make the cut since their impact on triggering adaptation within the IT function rarely represents a threat for people or teams. Moreover, because of the huge knowledge gap that exists between tech-savvy team members and the rest of your organization, most of these qualitative feedback items require substantial effort to be translated into actionable improvements at the technical level. No-one is against improvement, but when time comes to put the effort, the exertion is in direct competition with project priorities and the short term objectives of on-time and on-budget delivery.

The feedback loop that helps corporate IT to adapt and improve the delivery of change projects is weakened by the absence of a component that links it to true survival. Compared to most businesses, corporate IT has little skin in the game and not much to lose by perpetuating the status quo or making only small changes to its modes of operation.

The engagement model between corporate IT and the rest of your business is at the deepest root of many issues that impede their ability to provide more value to your organization. It is also one of the fundamental reasons why you may have the impression that the IT function is in an everlasting state of immaturity.  To get a better understanding how your corporate IT works (or isn’t working), I invite you to take a quick read of this book: What You Should Know About Corporate IT But Were Never Told.

You will realize that changing these patterns requires radical change in the way corporate IT engages with the rest of the business, and more specifically, how accountabilities are distributed and measured.  Nothing less than a major revolution, triggered by business people, will allow IT to become a true adaptive system that can change itself to provide what you deserve.



[1] The working definition at MIT for complex systems is: “A system with numerous components and interconnections, interactions or interdependencies that are difficult to describe, understand, predict, manage, design, and/or change.”
– Magee, C.L., de Weck, O.L., Complex System Classification, Fourteenth Annual International Symposium of the International Council On Systems Engineering (INCOSE), June, 2004


Small, Autonomous and Fast-Forward to Lower Quality

I am a jack-of-all-trades.  Admittedly  — and proudly  —  I realize that a lifelong  series of trial and error, crash courses, evening reading and incurable curiosity have  resulted in this ability to do many things  —  especially things involving some manual work. I feel self-satisfaction to think about all the situations that could arise in which I would know what to do, and how to do it.  I can help someone fix a kitchen sink on a Sunday afternoon.  I can drive a snowmobile, sail a catamaran, or connect a portable gasoline generator to your house.  My varied skill-set affords me a serene feeling of power over the random hazards of life.  That, and it’s also lots of fun to do different things.

There is currently an interesting trend in many organizations to favour highly autonomous teams.  The rational is quite simple: autonomy often translates to an accrued operational leeway that offers a better breeding ground for innovation.  By not being weighed down by other teams, there’s a hope that the group will perform better and yield more innovative ideas.  There is also the expectation that the team, using an Agile™ method, will produce tangible implementations much faster if it can be left alone.  The justification is founded in  the belief that small teams perform better.  Makes sense:  the smaller the team, the easier the communication, and we all know that ineffective communication is  a major source of inefficiency  —  in IT as well as in any  other field.  And if you want your team to be autonomous and composed of as few individuals as possible, then there is a very good chance that you need multi-skilled resources. 

Jacks-Of-All-Trades and Interchangeable Roles

You need jacks-of-all-trades or else either the number of individuals will increase or you will need to interact with other teams that have some of the required skills to get the job done. As a result, you will not be as autonomous as you’d like.  

But there is more: the sole presence of multi-skilled individuals is not enough to keep your team small and efficient in yielding visible results at an acceptable pace.  You must have an operating rule that all individuals are interchangeable in their roles.  If Judy —a highly skilled business analyst— is not available in the next two days to work on sketching the revamped process flow, then Imad —a less skilled business analyst, but a highly motivated jack-of-all-trades nevertheless— needs to take that ball and run with it.   You need multi-skilled resources and interchangeable roles.  That’s all pretty basic and understandable, and your organization might already have these types of teams in action.

For a small and autonomous team to keep its low size and independence upon others, it needs to be made of jacks-of-all-trades and roles must be interchangeable, or else it will either grow in size or depend on outsiders.

Conflicts of Roles in Small Autonomous Teams

Before you declare victory or you rush into hiring a bunch of graduates with a major in all-trades resourcefulness and let them loose on a green field of innovation turf, read what follows so that you also put into place the proper boundaries.   If you want to ensure maximum levels of quality and sustainability of what comes out of small, autonomous, multi-skilled teams, you need to ensure that there are no conflicting roles put on the shoulders of the individuals that need to juggle them.

Conflicts of role occur when the same person needs to do work that should normally be assigned to different persons.  The most obvious —and, in corporate IT, the most abused — combination of conflicting roles, is creating something and quality controlling that same thing.  This can be said of any field, really  — not just IT.  Industrial production process designers have understood for centuries now that he who quality checks should never be the one that is being checked.  Easily solved, might you think. You just need to have Judy check Imad’s work in two days when she’s available, and the issue is solved!  Maybe  —but there’s a catch. 

No Accountability and No Independence

Proper quality control requires at least one of these two conditions: (a) the person being checked and the controller must be both accountable for the level of quality of the work, or else (b) the person doing the quality control must be able to perform the reviews independently.  If Imad and Judy are both part of a team that is measured on the speed at which it delivers innovative solutions that work, then there is a good chance that quality is reduced to having a solution that works, period.   Other quality criteria are undoubtedly agreed upon virtues that no-one is against, but are not as important as speed.  As described in another article, in IT more than any other field, a working solution might be ‘under-the-hood’ a chaotic technical  collage, hardly holding itself with haywire and duct tape— but it can still work. 

These situations often occur when IT staff are put under pressure and are forced to cut corners.  As such, speed of delivery becomes in direct competition with quality when assigning the person hours required to deliver excellence.  If the small, autonomous, multi-skilled team’s ultimate success criterion is speed, then Judy’s check on Imad’s work is jeopardized if the quality of his work has no impact on speed.  In this case, because Judy and Imad are both part of a group that must deliver with speed, then none of them is really accountable for any other quality criterion than simply have that thing work. As long as it doesn’t impede delivery pace, any other quality criterion is just an agreeable and desirable virtue, but nothing more. Judy is not totally independent in her quality control role and worse, there is no accountability regarding quality.

When a small and autonomous team’s main objective is to deliver fast, any quality item that has no immediate impact on speed of delivery becomes secondary, and no-one is accountable for it.

And it doesn’t stop there: considering that quality control takes time, the actual chore of checking for quality comes in direct conflict with speed, since valuable time from multi-skilled people will be needed to ensure quality compliance.  After two days, when she becomes available, Judy could check on Imad’s work, yes, but she could also start to work on the next iteration, thus helping the team run faster.  If no-one is accountable for quality, Judy’s oversight will soon be forgotten.  Quality is continuously jeopardized, and in your autonomous teams there is a fertile soil for the systematic creation of lower quality work.  

There’s No Magic Solution: Make Them Accountable or Use Outsiders

So, what precautions must be taken to ensure maximum levels of quality in multi-skilled, autonomous teams?   The answer is obvious: either (1) the whole team must be clearly held accountable for all aspects of the work —including quality— or (2) potentially conflicting role assignments have to be given to individuals who are independent; that is accountable and measured on the work they do, not for the team’s performance.  

If you go with the first option, beware of not getting trapped into conflicting accountabilities again, and read this article to understand how quality can be challenged by how it is measured.  To achieve independence (second option), you will require having team members report to some other cross-functional team, or allow an infringement to your hopes of total autonomy by relying on outsiders.  Although multi-skilled and autonomous teams are an enticing perspective for jacks-of-all-trades, the agility they bring to the team should not be embraced at the expense of the quality of the assets you harvest from them.

Lower Quality at Scale

If you want to understand how and why unwanted behaviors such as those depicted above are not only affecting small autonomous teams, but are also transforming the whole of corporate IT into a mass complexity-generating machine that slows down business, read this mind-changing book.  It will help you understand why lower quality work products are bound to be created, not only in small, autonomous and innovation-centric teams, but almost everywhere in your IT function.

Innovation: Where IT Standards Should Stand

The use, re-use or definition of standards when implementing any type of IT solution has very powerful virtues. I’m going to outline them here so you can see how these standards play into the (often misunderstood) notion of innovation in corporate IT. We’ll then see where IT innovation truly happens in this context, while underpinning the importance of using or improve IT standards to support overall innovation effectiveness.

The Innate Virtues of IT Standards

  • Sharing knowledge.  Without standardization, each team works in its own little arena, unaware of potentially better ways of doing things and not sharing its own wisdom.  It is much easier to make all IT stakeholders aware of practices, tools or processes when they are standardized. Systematic use and continuous improvement of IT standards act as a powerful incentive for knowledge sharing.
  • Setting quality targets. Standards minimize errors and poor quality through the systematic use of good practices.  They encompass many facets, from effectiveness to security, to adaptability, to maintainability, and much more.
  • Focusing on what counts.  A green field with no constraints and no prior decisions to comply with might entice your imagination, but it can also drive you crazy if everything has to be defined and decided.  IT standards allow you to focus on what needs to be changed, defaulting all other decisions to the use of the existing standards.  
  • Containing unnecessary complexity.  The proliferation of IT technologies, tools, processes and practices in your corporate landscape is a scourge that impedes business agility.  Absence of standards interferes with knowledge sharing and mobility of IT resources.  Multiplicity of similar technologies makes your IT environment more difficult to comprehend, forcing scarce expert resources to focus on making sense out of the existing complexity rather than building the envisioned business value.

The use and continuous improvements of IT standards is one of the most effective cross-enterprise safeguards for IT effectiveness, IT quality, and in the end your business agility.

Despite all these advantages, there is a trend emerging in many organizations that puts these virtues at risk of not being present.

The Lab Trend

In the last few years, it has become mainstream strategy for large, established corporations to create parallel organizations, often called “labs”, that act as powerhouses to propel the rest of the organization into the new digitalized era of disruptive innovations.  This article is not about challenging this wisdom, which may be the only possible way —at least in the short-term— to relieve the organization from the burden of decades of organic development of IT assets and processes that slow down the innovation pace. 

Unfortunately, there are people in your organization who associate standards with the ‘old way’ of doing things.  After all, aren’t all standards created after innovation, to support the repeated mainstream usage of innovative tools, processes or technologies that came before them?

Making the leap that IT  standards should not be considered in the innovation process, not included in the development of prototypes or proofs of concept, or   — more simplistically  — not be part of anything close to innovative groups, is a huge mistake.

 The decision to use or not use a given IT standard depends on what you are innovating, and at what stage of the innovation process you are in.   The IT work required to implement business innovations is rarely wall-to-wall innovative.  Standards cannot —and should not— be taken out of the innovation process from start to finish.  I’d a go step further: standards should always be used except when the innovation requires redefining them.  But the latter case is exceptional.  To help you grasp the difference between true business innovation and its actual implementation, here’s a simple analogy:

The Nuts and Bolts of Innovation

In the construction industry, there are well known standards that determine when to use nails, when to use screws, and when to use bolts in building a structure.  It stipulates the reasons to choose one over the other (e.g. because nailing is much faster to execute and cheaper in materials costs). The standards also spell out how to execute: how many nails to drive, the size and spacing between them, safety precautions, etc.

Now suppose that your new business model is about building houses that can be easily dismantled and moved elsewhere. Let’s say to support a niche market of temporary housing for the growing cases of climate-related catastrophes.   You decide to build whole houses without ever using nails or screws by bolting everything.  You would make this decision to simplify dismantlement, easily moving the house and rebuilding it elsewhere.  The technical novelty here lies in the systematic use of bolts where the rest of the industry normally uses nails.  Bolts are slower to install and more expensive, but they would allow you to easily disassemble the house.  

But when a worker bolts two-by-six wood studs, the actual execution of bolting is not an innovation; it has been known for centuries and the execution standard can be used as is.  In other words, when a worker is on the site and bolting, the innovation has already occurred when the choice was made not to use nails or screws. The market disruptive strategy was determined before, and it is now time to apply bolting best practices and good craftsmanship.

No Ubiquitous IT Innovation in Corporate IT

For IT based business solutions, when the teams are in the phases of implementing the processes, systems and technologies, most of the business innovation has probably occurred in the previous phases.  

When IT staffs are actually building the technical components of your new modes of operation, the business innovation part has already occurred: it lies in the prior choices made during design.

The techies might be testing the innovation through some sort of a prototype, but it doesn’t make their work innovative. When you look at it from a high enough viewpoint, isn’t implementing a new business process with information technologies what corporate IT has been doing for decades?  

When building the IT components of innovative business solutions, where is the actual innovation?  Is it in the new business processes or in the way they are technically implemented?  Chances are that the real value is in the former, not the latter because your initial intention was to aim for  business value, not technical prowess.    

It may very well be that, at the IT shop-floor level, what needs to be done is to apply good practices and standards that have been around for years, if not decades.

In our era of multi-skills, cross-functional, autonomous, self-directed and agile teams  —  which are all busy growing new solutions that support constantly evolving business processes  —  there is a line that should not be crossed: thinking that innovation applies to everything, including the shop-floor level definition of good craftsmanship.  

Don’t Pioneer Without IT Standards

My observations are that when IT practitioners are part of teams dedicated to innovative business solutions, they often become overzealous, abandoning standardization and tossing tried-and-true practices out the window.   I’ve seen IT people making a clean-sweep of all established standards and proclaiming every part of a solution as innovative.   I’ve seen technical staff blindly pulling so-called innovative technologies into the equation with little understanding of their real contribution to business value.  This has a direct impact on the quality of the resulting work. Here’s how:

  1. : IT staff end up using bolts where nails would be fine or using nails where they should have used bolts;
  2. : new platforms are built with no standards used or defined.

In both cases, the impact on your future change projects is catastrophic: lack of shared knowledge, unknown quality levels, lost time and effort reinventing the world, and most importantly, creation of more unnecessary IT complexity.  The resulting assets will be hard to integrate, impossible to dismantle, incomprehensible by anyone else but those that created it, and costly to maintain.  In other words, your business agility will be seriously jeopardized.

The results from innovation without standards will fast-track you to the same burdensome position you tried to free yourself from with your old, outdated platforms.

The only way to avoid this unhealthy pattern is to make sure that the mandate is not just about innovating at any cost.  It must include the use and creation of standards, and limit the scope of change to what creates business value.

Set the Standard

First, your innovation team should not only devise new ways to do business: it must make it a priority to use and reuse standard practices and technologies, unless required to innovate. When a given standard is not applicable, their job should include to define the replacing one.  The idiom “to set the standard” earns all its significance: re-inventing business models that others will now run to catch or match, and defining the standards for your organization and future projects to use and leverage.  Your future business agility heavily depends on the systematic application of good craftsmanship in your current innovations.

New Technologies Need to Bring Value, Not Novelty

Secondly, your new parallel ‘lab’ organization should bear the onus of justifying the use of any new or different technology. How will it contribute to the innovative, business-oriented end-result that you seek?   When technologists are put in front of the enticing prospect of having no obligation to the use of any of the standards in place in your organization, they will jump at it.  It will often lead to the introduction of new technologies for the sake of it, based on no other justification than hunches, hearsay, or how attractive it may look when printed on a resume.

The use, reuse, and redefinition of IT standards should always be part of your innovation team’s mandate.  If not, your future business model will be made of foundational assets built as if there was no tomorrow.

Beware of falling into the trap of catching the contagious over-excitement about the scope of innovation.  Most of IT processes and components that result from business innovation can use mainstream practices and standard technologies. The legitimately innovative portion  — the one that really makes a difference —  is just a fraction of the whole undertaking, and very often, the truly novel part is simply not technological.

Provide Leeway But Set Quality Expectations

So, even if you rightfully decide to go down the path of creating parallel organizations, don’t allow these organizations to have too much leeway when it comes to standards..  Do not sign the cheque without a minimal set of formal expectations regarding sustainability, which must include standards compliance.  

The key is in clear accountabilities and coherent measures of performance. If you want to learn more about how poorly-distributed roles can sabotage the work of your corporate IT function, read this short but mind-changing business strategy book.

The Word is Out… and It’s in a Book!

Ready to read, share, and think about.   Available at Amazon in various formats.

If you believe these ideas should be shared, please write a quick review on Amazon, so that the book has more chances to appear on search results for potential readers.

Special thanks to all those that helped or supported me in this voyage.

I  will now try a totally new thing before the dive in volume 2:  summer time leisure…

Available on July 24th

In less than two weeks, all loose ends should be tied up and Volume 1 ready to read, share, shock or mull over.  Get it on amazon.com, either as eBook, paperback or hardcover version.