When Is Offering Services "In the Cloud" a Good Idea?

Companies such as Google, Amazon and even Microsoft have shown that providing key IT services such as email, compute and office productivity software successfully as online "on demand" services. This has opened the floodgates across the market, with more and more services these days being provided to consumers and businesses in an on-demand delivery model.

I recently was at a large multinational company that was trying to determine how best to offer their software as an online "on-demand" service.  While they have a rather unique set of challenges before them, there were still a set of questions that I felt any company who might be considering moving into the online delivery model should really ask themselves before taking the plunge.

What are the Drivers for Making the Move?

This question is not as silly as it may sound.  Sometimes a business gets excited or ahead of themselves and the market, whether from reading about online service successes in other industries in the press or a Gartner analyst report.  While moving your products "online" might be that key angle that might help you beat your competition or gain significant market share, you need to look at how big of a leap it might be for the market and your customers.  If customers are familiar with using your software through thin clients or clean latency agnostic web service calls, and/or you are already losing sales because the up front costs and hassle for equipment and IT support for your customer is just too high for them to bear, then it might be a great move.  If, however, you are providing more traditional thick clients, and/or are providing software that tightly integrates with other internal software and systems, you may want to do much more legwork to see whether or not providing your services in an externally hosted manner is viable.

What is the Market Landscape?

Have you been confronted with requests to provide your services in an on-demand online way?  Are there competitors in the market who have offerings that are provided in a Software as a Service model? Have you seen customers wanting to move more of their costs from capex to opex?  Are there challenges with customers who want to see their costs more accurately reflecting their usage in order to get away from the trap of having to cover arbitrary license fees or having to scale up for some peak load that happens for only short periods during the year?  Are your customers frustrated at the level of skill and customer service that their own internal IT departments provide?  Any of these may be a good reason to seriously consider creating an on demand offering.

If, however, your customers are all scared by the concept of externally hosted solutions, either for security and control reasons, or worse they feel threatened that you might take away their jobs, you might need to ask yourself whether the market is ready yet for such an offering.  While it may still be possible, if you find yourself constantly in a missionary sales mode to potential sales leads who really like your software but are extremely skeptical of an online delivery model, you may need to either significantly bolster the strength of that model (and the way you sell it), or back away from it for the time being.

What is the Legal/Regulatory Landscape? 

Many businesses have to work within a rather tough legal and regulatory environment. Whether it is banking, medical, utilities, telecommunications, broadcasting, aerospace, government or some other industry, each has its own peculiarities with systems, security and data handling that needs to be well understood before diving in.  Some of these, such as safe harbor rules, severely restrict where data can be held and who can handle it how, often with not just organisational boundaries but even geographic and political boundaries as well.  They are complicated and often tough to deal with.  However, there are very few that, with awareness backed by solid systems, controls and policies in place to handle them, that cannot be overcome.  It is often a bar that is set extremely high, often by people who are scared of or highly skeptical of any software that sits outside of systems that they can physically touch and stare at the blinking lights on the chassis.  I have dealt with many of the toughest ones out there. In more than one instance I found myself in situations where the regulator was at first convinced it wouldn't work.  It was always tough, but by understanding what they were looking for and why we always managed to get through.

If you provide solutions for these sorts of industries and cannot effectively speak to and prove your compliance, you will either need to put in the investment to be able to do so or not offer them.  As a side benefit of getting your act together is that it not only helps strengthen you message, but if you do it right it can help you understand if you can provide your services effectively.

Can Your Software be Sold Profitably as a Service?

Providing service offerings is hard.  You need to get a lot more things right in order to ensure that you can not only provide a service that customers want to buy, but that you can make a profit while doing it. The first thing that you need to understand is if your service is perceived as usable by your customers in an online delivery model.  This means that you need to understand how they will access it, how they will work with it, and what sort of performance they will be expecting.  When I was at Yahoo!, we used to look very closely at people's behavior to better understand what their expectations were for product performance.  We noticed that people had different expectations depending upon what they were doing. If they were reading text they would have different expectations than toggling through an interface, and different again for consuming feeds, which even varied on the type of feed, and again there were differences in expectations of performance for watching videos.  When we began to understand these, it heavily influenced our architecture and deployment models.  We could perform a variety of very neat tricks that made things look and act responsive, even over dodgy internet links.  We even became sophisticated with how we would pair and serve solutions, and how and where we would host them.  Without understanding more about our customers, we would have just been stabbing in the dark.

Another aspect is what does the cost structure look like for running your service.  Are you able to provide your services in a multi-tenant way, or do you have to have standalone setups for each customer?  Does your service require beefy and expensive systems that significantly stairstep your costs or can you scale horizontally with cheap systems?  Do you require expensive software licenses and vendor solutions that significantly push up your costs?  Can you match these costs to a sensible charging model that doesn't simply look like a pile of up front costs like they would see if they hosted it internally, yet still allows you to make a profit, even if it is down the line?  If the charging model is use-based, can it be sensibly measured in a way that actually ties to a customers usage (and optimally to their sense of value) and not an itemized list of the underlying systems, licenses and support costs? Many get this wrong, which is unfortunate.

The final elements are arguably the most important, which is are you and any partners/suppliers you are dependent upon capable of providing a sufficiently high level of service for your customers while being cost competitive and without destroying your bottom line?  Providing your services as an on-demand utility pushes customers to expect a far higher level of service than they could cobble together themselves.  They expect that you are going to be responsive and reliable, and are not going to lose their data or lock them out.  They do not want to have to think of or ever be concerned about what IT ugliness might be going on underneath the covers of your offerings.  They will want the services to always be available when they want them.  They will also want things like upgrades to be seamless and not require any effort or inconvenience on their part.  These are all very difficult to meet, however are often what can make the sale if you can confidently provide it.

Do you have the skills/know-how to Build and Support a Service?

Building and supporting a SaaS solution is very different than doing it for the same solution offered as shrinkwrap software.  You are now responsible for running the service, meaning that you can no longer hide behind a customer's internal IT group and environment.  You are responsible for designing, building and supporting the full stack that provides the service, and are expected to do it at a level far superior than any standard IT organisation.  That is hard, and requires a very different approach and thinking end to end.

First, you need to ensure that you are creating a design and architecture that is resilient and supportable. You need to think about how tightly coupled various subsystems are with each other.  You need to think about every way that your service can fail and try to ensure that it will fail gracefully if not seamlessly.  You will have to think through how to instrument up your entire stack to allow for better monitoring and management of it.  You will find that this will need to be far more than just heuristics style monitoring, but also will require understanding usage patterns and how the various subsystems perform on their own and with one another.  You need to think about how you handle data, how you can manage and ensure its integrity, and how you can clean things up and keep any necessary separation between users and customers.  You need to also think through access management at all levels, both within the service as well as across the entire service ecosystem, including the infrastructure.  Related to this, you will need to think through all security elements, including things such as intrusion detection, denial of service attacks, security perimeters, and how to ensure the sanctity of your environment.

Then there are the build and deployment aspects that need to be thought through.  How large and frequent are releases?  How are things built, packaged and configured?  Are deployments manual or automated, and can they be rolled back and reproduced?  How upgradable is the service and infrastructure, and does it require downtime?  How are changes sized up for their risk levels, and who makes those decisions?  These all sound fairly straightforward, though most companies get these very wrong.

Finally, do you have the skills and staff required to run and support your service operationally?  Can they monitor it and ensure its uptime and integrity?  Can they handle incidents and requests quickly and effectively?  Are they well versed in security and service continuity, always thinking about the safety of the environment and how to make it more robust yet still manageable?  Can they effectively work and coordinate with suppliers, ensuring both incidents as well as requests are handled quickly and seamlessly to both you as well as your customers?  Are they constantly aiming to and are able to continually improve the service and how they are able to manage it?  Have you thought through how your customers will engage with you from an operational and support standpoint across the service lifecycle, including onboarding, during run, as well as some eventual offboardings that may happen?

Final Thoughts

Software as a Service solutions are the way of the future.  It democratizes the market, lowering the barriers of entry for both customer as well as supplier.  It greatly reduces the level of cost and friction between customer and supplier, and should allow for customers to experience a level of quality and resilience that they cannot afford to provide internally.  However, it requires a great deal of end-to-end thinking in order to create a successful SaaS offering.  

Are You Aware of Your Differentiating Assets?

A week ago I had the pleasure of being invited to a private talk with Sir Jonathan Evans, former Director-General of MI5, on the theme of Digital Security. While many of the topics of the evening were quite pertinent to so many of the recent news events, there was one item in particular that really stood out. Evans stated that one of his missions was to try and reach out far and wide to government ministries, universities and corporations and ask:

“Are your important assets understood and secured from theft and sabotage?”

How many people and companies have properly asked themselves this question? How many can actually explain why those assets are important, and to whom? Do they differentiate you or your firm from the rest of the market? How many target the acquisition of those assets and then know once they have them? To take it even further, how many can articulate whether or not those assets that they have are effectively exploited?

These are questions that apply not only to businesses, but also to each and every one of us in our private lives as well. Let’s step through and explore a little more.

Assets

The first place to start is to look around at your assets. Assets are those things that have qualities or capabilities that can be somehow exploited to provide value. Assets can be physical (like tools, vehicles, property), financial (monetary instruments and credit), human (not only headcount, but also skills and culture), intellectual (which is not just things like patents, but also includes knowledge as well as data that has the ability to provide knowledge and indicators), and relational (these are usually things like commercial relationships or standing contracts that might allow for preferential or enhanced access and treatment not ordinarily available to others).

Most people and firms will go to some lengths to put in measures to secure physical assets. This is the reason for elaborate locks, alarm systems and guards. They may not do the best job of securing and tracking these and thus experience lossage, sometimes with severe consequences. Similar measures are often used for financial assets, which unless you are working with billions in financial instruments or are large enough to have your own Treasury Department, might be mostly outsourced to banks who are also simultaneously putting some of it to use for investment returns.

Human, intellectual, and relational assets, however, are far more elusive. Many companies only pay lip service to the value of their people. In some industries and areas people may be fungible enough that losing people has relatively low impact. However, as competition and innovation become ever faster and more knowledge dependent, losing staff becomes ever more costly. Often there are important skills and relationships that go into really making a product that are neither visible nor necessarily easily transferable to other staff. Understanding these dynamics, and putting in sensible safeguards to build staff loyalty and prevent poaching is important. For most companies, the best people are often the first to leave when conditions deteriorate.

Intellectual assets are even trickier. They are often invisible even to those within an organization. Theft through unauthorized analyzing or copying by external parties rarely leave any trace, even though the theft of such assets can have a significant impact. However, intellectual assets are even more vulnerable to two bigger scourges: tampering and neglect.

Tampering

It is rather easy to tamper with intellectual assets. Whether it be tweaking source code, fiddling with configurations, or twiddling with data without some form of tracking you are tampering and may not even realize it. Most tampering may be inconsequential, but occasionally unexpected mayhem may ensue, especially if the tampering is malicious. Tampering can not only cause vital systems to fail, but when it affects data and metrics can cause incorrect conclusions to be made that lead to disastrous actions being taken. Troops can be sent the wrong way. Investment firms can dump or buy assets that cause market instability and damage the firm. Companies can dump or damage their products, services and supply chains. The FDA has even warned recently that many medical devices and hospital networks can be tampered with, flooding patients with insulin or causing pacemakers to dysfunction.

Few properly think about and assess the dangers of tampering, with even fewer putting safeguards in place to minimize the risk of it happening. This doesn't mean that one needs to develop a high level of paranoia about everything, but there is value in understanding how exposed your assets are to tampering.

Neglect

Lack of awareness and neglect are potentially even more harmful. Data and assets are lost all the time, often disappearing through faulty storage, handling and backup. Many people know that NASA has lost large amounts of data from the early space programs, including the Apollo lunar missions, due to an inability to recover data stored on the 7-track reel-to-reel tapes used at the time. While that is an extreme case, I have run into many companies who have lost source code to critical systems due to general mishandling and improper source code control systems. In several instances I have personally witnessed, this has cost companies millions and severely hamstrung the business. I have also seen many cases where lost knowledge of systems, software, and even test harnesses built long ago have caused huge amounts of mayhem when they have later needed to be updated or replaced. It has been suggested that this may be part of the cause for the embarrassing mainframe outages at RBS/NatWest where people were locked out of their bank accounts for days on end.

Awareness of your assets and capabilities will help with ensuring that neglect does not become built in. It takes a great deal of effort to build in this sort of awareness, especially in large and well-established businesses. However, there are ways to gather and audit that can be put in place to first understand the size of the problem, then steadily fix it over time.

Differentiators

For both companies as well as individuals, both the understanding and being savvy with utilizing your assets is what differentiates you from your competitors. This is why it is important to both understand as well as protect and enhance them constantly.

I have seen many businesses outsource large chunks of their business to outside firms. For non-core and undifferentiated parts of the business this often makes sense. However, I have seen large numbers of firms also outsource core, near-core, and differentiating parts of their businesses, only leaving the executive suite and some minor elements of sales and marketing within the business. Without careful oversight this can be extremely dangerous. I have seen cases where companies have become so dependent upon one outsourcer for a key piece of the business that losing them would mean that the business would stop, perhaps catastrophically. I have also seen where the business ultimately ends up in competitive situations with the outsourcer and are incapable of competing cost effectively. Outsourcing Research and Development means that without very careful shepherding you risk becoming beholden to the outsourcer for innovative progress. Outsourcing customer service and support can potentially risk losing control over the level of quality of contact with the customer, potentially harming both reputation as well as future sales. The quality of these services are often differentiators to your customer in the marketplace.

Businesses need to think through what are their differentiators, and whether they are effectively protecting and enhancing them.

Awareness and Exploitation

It is key to be aware of your assets, not only what and where they are but also whether they are understood and secured from theft and sabotage. As they are not always obvious or visible, it often requires regular effort to ensure that they are accounted for and used effectively. Both individuals as well as businesses should regularly take stock of what they have, and determine whether and how they are used to effectively differentiate you from the rest of the market.

The Confusion of DevOps

"What we got here is... failure to communicate."

                              -- Captain of Road Prison 36,  Cool Hand Luke (1967)

I am noticing more and more frequently these days that the term "DevOps" is being used to describe a staff position or department and sets of tasks that can best be described as deployment configuration management and automation.  The role seems to have been derived from so much confusion that has come out of a mixing of the heavily related Continuous Delivery, Infrastructure-as-Code, Service Engineering, and DevOps movements that have been swirling around in various forms for the last several years.  While it is difficult to talk about any one of them without referring to elements of another, the fact that they have all somehow been combined into a new job family is not only disconcerting, but may potentially represent a general misunderstanding of the larger issues that exist between IT and the rest of the business.

Businesses constantly seem to be struggling to come to grips with the constant changes that are happening across the business, especially in IT.  Business leaders barely had come to grips with the whole concept of the Internet, Just In Time manufacturing techniques and multimodal telecommunication methods when suddenly the Agile and Lean movements, Continuous Integration, virtualization, elastic computing, and on-demand software services arose.  Each of these innovations has demanded significant changes to interactions, behaviors and understandings of people across the organization.  In return they deliver ever faster and ever cheaper ways of innovating and serving the market. 

Mainstream businesses have struggled to understand many of these concepts, and are only now beginning to seriously make many of the necessary steps to adopt them.  Few have gotten far enough along to really effectively handle them while also absorbing the next wave of change that is already on top of us.  This next wave includes not only the significant changes at delivery and run that come with Continuous Delivery, Infrastructure-as-Code, and Service Engineering, but also more advanced topics such as the flows and collaboration required to actually achieve what is aspired to in DevOps, the complete mindset change that comes with Outcome Delivery in the Product Development space, and changes arising in the legal contract and financial spaces.  This next wave is building upon the knowledge, learning and expertise created by successful pioneers from the earlier wave. 

Anyone who has made significant inroads into these next wave approaches knows that true power in them requires proficiency if not mastery of earlier concepts.  Continuous Delivery is not terribly effective if neither Continous Integration or the short iterations of Agile methods are in use.  DevOps is really the next step in collaboration.  It further blurs the remaining team boundaries to eliminate any remaining friction and gaps in roles and responsibilities that negatively affect service health and continuous improvement. It simultaneously shores up and strengthens the professional rigor that once organizational boundaries tried to uphold. The mindsets that are established in the earlier movements, such as frequent and rapid adaptation to feedback and working collaboratively in cross functional teams, are all important prerequisites.

Businesses are finding themselves in an uncomfortable spot.  They are realizing that they need to make massive changes in order to stay competitive.  Yet so few people within their ranks properly understand these new ideas enough to effectively implement the changes required by them.  There just simply doesn't seem to be a nice and neat place to handle this sort of change in the traditional organization.

So they create one.

In the past some companies simply made the move to outsource their IT in the hopes that the problem can become that of their outsourced partner. Some may still opt for this option in light of these challenges. This often only makes the problem larger by putting entire corporate entities and business profit models between IT and critical business functions.  Many of these companies have learned that IT is in fact a critical capability within their business, one that can only effectively be outsourced when doing so neither impedes business change nor lets go of the company's value add in the marketplace in a way that leaves the business completely hostage to the outsourcer.

Perhaps it is worthwhile to look deeper into the industry to see what is going on.
Much like the mess that is "Cloud Computing", the term seems to be pervading ever further across the industry, to the point where it is being used so frequently that otherwise intelligent people are starting to give in and use it to get a point across.  

By packaging "DevOps" into a nice compartmentalized role in the organization, many businesses seem to be tipping their hat to the problem and hoping that filling those roles will somehow accomplish what is needed with little additional need for change.  This is similar to the relatively recent fallacy that buying VMWare and virtualizing your legacy server estate will allow them to avoid the legacy architecture headaches and somehow give the organization "Cloud Computing".  These water down not only the meaning of the movements, but also provide fodder for those who are actively resistant to change by creating compromising stillborn half measures they can point at to say they aren't real.

Having been brought in time and time again to sift through the damage and placate the injured in such poorly implemented change efforts, I hope that this half-baked compartmentalized trend will somehow reverse and not damage yet again another great set of ideas.

I am speaking at Agile 2013

I have been very busy over the past few years honing my arsenal of techniques for creating high performing services and organizations.  In particular, I have been actively working with clients in live situations methodically trying to capture the key essence behind my most effective techniques.  Having seen so many otherwise smart people struggle for so long, I hope to add to the collective knowledge out in the industry to not only help others but to also hopefully reduce the amount of dysfunction that so many have to deal with on a day to day basis.

The talk that I will be giving at Agile 2013 covers one of the elements that I have discovered, which is how to find and improve flow and transparency across an organization.  I have found that many of the techniques I use, including looking for places where friction develops and queues build up, places where communication breaks down or is misinterpreted, and where there are knowledge gaps that form across organizational siloes, have very similar analogues in Lean.  The spirit and mindset that has been built up in the immense body of work within Lean can, when added to both the technical and architectural techniques that have been steadily arising from XP and elastic computing as well as the rapid product development techniques that have been coming from HotHousing and Lean Startup, go a long way to helping IT organizations improve and better serve customers.

Human Cognition - Cultural Bias Beyond the WEIRD World

Anyone who has lived for any length of time in a culture that is different from the one they were originally raised probably noticed differences, sometimes subtle, in the way that those in the different culture observe the world and things around them.  The more different the culture, the sharper these differences become.  Many people simply discount these differences are quirks.  What scientists are beginning to find is that these "quirks" are often significant, and the differences challenge long held assumptions of human psychological universality. A recent write up in Pacific Standard (found here) goes into detail on what scientists are beginnning to find.  Both the article as well as the research study behind it are an excellent read.

In short, it states that the "generalized standard" for the vast majority of human psychology, cognition and behavior research studies in the world's top journals is based almost entirely upon people who come from Western, Educated, Industrialized, Rich, and Democratic societies (WEIRD).  What scientists are now finding is that there is substantial variability in the way that different cultures perceive the world, from fairness, cooperation, spatial reasoning, categorization and inferential induction, moral reasoning, reasoning styles, self concepts and related motivations; and that population groups from the "generalized standard" are particularly unusual and frequent outliers compared to the rest of mankind.  Americans in particular fall at the extreme end of the scale even within the unusual population of Westerners, making them "outliers among outliers".

This brings into question a wide body of underlying assumptions, ones that form much of the foundation of societies.  If there are fundamental differences in the fabric of how people from different cultures observe the world, how can this be reconciled within the rules that make up everything from civil norms, the ways that people do business, and even education?  Might it even be possible to exploit the potential richness of different mental models within a business or community to make it a business or community more successful?

While different models can and do cause confusion and misunderstanding, they can also provide a richness that spurs creativity and innovation.  Perception that is different than your own is neither necessarily better or worse than your own.  It is simply different.  Exploration of these differences allow you to see potentially useful concepts that otherwise you may have missed.  People, from businessmen to the intellectually curious, have studied concepts as far ranging as Japanese business practices to Buddhism and Eastern mysticism. Steve Jobs, someone that many find to be a creative genius, was inspired by Zen Buddhism.  Others have been heavily influenced by experiences they and their families have experienced, from famines and depressions to wars and idealogical conflicts. They all leave imprints upon the way people approach problems, and being aware of them and their impact upon your mental models goes a long way to allowing you to not only better understand yourself, but also to help open yourself up to other models as well.

Those who are open to exploring often find entirely new ways of thinking, allowing themselves to question the previous certainty of the world around them and opening up entirely new opportunities that they would have otherwise completely missed.

Can businesses also take advantage of this?  Many businesses talk about diversity, but more often than not retain a certain rigidity to their own internal culture.  Opening up to different models, not in a soft HR-led politically correct way but in a much more scientific approach, may allow businesses to be both more innovative.  They also may help companies spot potential "perception misalignments" that may introduce risks to the business.

I apologize, but we appear to be separated by a common language

 "I apologize, but we appear to be separated by a common language"
  -- overheard in the hallways of an international corporation

The role of communication is enormous in the modern world. It has become the backbone of entire industries, allowing for ideas to spread ever more quickly, merge with others to create completely new paradigms, all while destroying many of the monopolies of old. In many fields the speed of communication is the new arms race. However, as we all become ever more interconnected, we increasingly have to run the obstacle course that is our unique backgrounds, cultures, mental models, and even speech patterns. While mental models is a big enough topic for another post, I thought it would be worthwhile to start with the joys of communication in what many mistakenly think of as one consistent and unified language: Modern English.

For those of us who were (un)fortunate enough to grow up with English as our native tongue, one would think that we would be seemingly blessed with the fact that our language is becoming ever more ubiquitous, especially in booming fields such as technology and business. While it is definitely great to be able to convey thoughts and ideas in your first language (as those of us who have tried to in a language we came late to knowing can attest), the infinite flexibility, adaptability and regional differences of English have opened a myriad of opportunities for misunderstanding, confusion, hilarity and very occasionally complete system failure even between native speakers. What are non-native speakers to do? 

Having now lived and worked internationally for a long time, you encounter misunderstandings and lost meaning amongst people almost every day.  After a while, you have to learn to watch your language and to check to see that you were understood, especially when using cultural references. Amusingly, one of the places where I have found some of the biggest and most dangerous misunderstandings were amongst those native to the supposed birthplace of the language:  England.

If you are from a large and fairly cultural and linguistically homogeneous place like Canada/US (where I am from originally) and Australia/New Zealand (where my wife is from), you might occasionally run into communication problems if people are either non-native speakers, not American/Canadian or Kiwi/Australian, or have one of a very small number of challenging regional dialects (such as Cajun, Newfoundland English, Deep South, and some New Yorker and Bostonian accents).  It is generally very rare for the misunderstanding to last long, and (unless it is a Québécois trying to be difficult) rarely does it devolve into complete communication breakdown.  Perhaps it is due to the relatively recent settlement of these countries and the rise of modern media that has helped.  Regardless, this homogeneity gives a false sense of certainty that what you say will be understood, at least for the way you meant it to be.

Across English speaking country groups the confusion really begins.  Even though the language and structure is more or less the same, and even many of the literary and media references are mostly shared, regional terms and cultural references are often lost. Between the North American cluster and the Australia/New Zealand one there are occasional misses, though whether it is due to similar historical backgrounds or the more direct nature of the cultures to quickly catch and fix these usually keeps these to a minimum.

This all seems to go out the window in the UK.  While one would expect some differences between Wales, Scotland, Northern Ireland, and England, there are also significant difference across England itself, sometimes even between two towns that sit right next to each other.  There are the many better known dialects such as Cockney and Geordie, but there are also many dialects and subdialects across Yorkshire, the Midlands, East Anglia and across the south.  These dialects are far more distinct than those found in the Americas.  Few speak the BBC English that many outsiders would be familiar with.  There are also differences between people from different classes, even those from the same area. The class boundary is a particularly odd one for Americans who, despite all of the recent press lamenting growing socio-economic gaps in the United States, simply have little grasp of the class concept. 

While this is all rather confusing for a foreigner, many English also suffer from a similar problem that many Americans have:  they expect by default that everyone will understand what they are saying.  The empire once was strong, and it is technically called "English".  But even when there are plenty of examples within one's own country that hint that this assumption may be flawed, it does not seem to affect the prevalence of complete communication breakdowns, many that often compete with Monty Python sketches for their absurdity. 

This becomes a huge problem in business, especially within multinational companies.  I have seen time and again language subtleties causing misunderstandings that derail teams, projects, and even big initiatives.  All of this affects morale and trust, let alone the productivity and success of the business.  Assumptions that everyone understands what you mean can be extremely dangerous, even, as with the English, everyone happens to come from the same country.

I have found when trying to convey and idea or concept, that it is always good to test in a non-threateningly way, whether it is by asking questions back of people of their thoughts or what they think they might do in response to the new information, to see whether it was really grasped.  This also works well the other way, which I use often.  That way drift can be caught early, leaving far less room for wild and dangerous surprises later. 

This can go further, and certainly is not restricted to just English speakers.  When looking at the health of a company, it is also useful to look at the means for which people communicate.  We all have stories of misunderstandings developing because someone misinterpreted something said, especially if a low bandwidth medium such as email was used.  Teams and companies also suffer when communication quality is not up to the mark.  I have personally seen very bad situations develop, not only in English and polyglot companies, but also in German and Spanish speaking ones as well.

People who have to interact with one another often work much more effectively together when they know each other well enough and both sides have the ability to further develop communication links. This allows people to better understand each other's context, and correct small misunderstandings at a ground level very quickly. 

Visual indicators, whether they be facial expressions, pictures, or even trends on a graph are also high bandwidth ways to convey complex information.  They work quickly and can be very effective to communicate concepts from diagnostics to thoughts to emotions, bringing truth to the old adage that "a picture is worth a thousand words".

Companies need to pay attention to the quality of communication across their organizations.  Without doing so, they risk creating a tower of incomprehensible babel and failure.
 

Release Batching - When is it a Problem?

I have seen quite a few flame-ups, particularly in the Kanban community, around release batching. It is a subject that I have spent a considerable amount of my career addressing.

Most IT Operations teams abhor and resist change. Change usually brings with it uncertainty and the potential for sleepless nights around a failed service. As it is often impossible to replicate the exact production environment in a test setting, there is a real risk that changes have not been tested adequately. There is also the problem that changes often mean a service outage is required, directly affecting customers.

What makes this worse is the fact that most software engineers as well as IT Operations people are less than sufficiently diligent with properly utilizing configuration management techniques in order to track the changes they make.  It is always far easier to hack in a change directly into a production system than it is to write it, check it in, package it and release it properly while managing all the dependencies.  But such changes cause configuration drift  that makes even the most ideal situation where development and test hardware is identical to production still produce different behaviours.

Release batching is the way that many organizations try to solve this conundrum.  By piling up all of the changes into one big release, the number of change events goes down.  This gives false security to the IT Operations people, who feel that they can heavily man those few events and field all the failures at one time.  It comforts the testers, who feel that they can spend the time to test through all the various changes.  It also allows the developers to be a bit lazier about the way they check in code and manage builds, as there are long periods where they have to code and fix builds.

But all of these supposed benefits not only hide dysfunction, but take value away from the business.  The longer that code is sitting waiting to be shipped, the longer it is sitting not being used to provide value to the business.  While the code is sitting, assumptions that were made that resulted in the code being written are not being tested, and even if they were correct at the time the moment may have been missed and the  market may have moved on.

The idea that fewer big changes means less downtime is also flawed.  Bigger changes, by definition, usually mean that more has changed.  More changes often make for more things to potentially go wrong.  It also means that when something goes wrong, the haystack you are having to dig through to find the problem is far bigger.  The idea that QA is going to be able to catch all defects, especially with large changes, is also flawed.  The measure of defects found is a gauge of how effective your QA team is at finding them against an always unknown metric of the total number of defects.  It is not a particularly good indicator of the number of defects in the code, the quality or maintainability of the code, or even the amount of problems you might encounter when releasing the code.  Lots of changes mean an exponential increase in the number of potential test cases required to find issues.

While pull mechanisms such as Kanban help capture an understanding of flow within the development phase, release batching tends to counteract much of the benefits by hiding dysfunctions under a false security blanket.  Difficulties in configuration management and automated deployment are solvable, and can be tackled incrementally to reduce release cycle time.  By moving progressively towards a system of continuous delivery, ever smaller changes can be understood, tested and released, allowing for very quick feedback and even faster rollback in case of problems.  Changes become far more atomic, risk becomes better understood and easier to manage, and pull can ultimately be achieved across the entire product lifecycle.