Enablement Analysis by Example – Offshore Outsourcing

Today we are going to illustrate some key aspects of enablement chain analysis on a specific example: software development outsourcing, more specifically — its offshore variant. This is a particularly useful exercise as besides its utility to exploring the power of enablement chains, it will also shed some light on outsourcing-related issues; something many organizations engage in and not so many happen to benefit from. So, hopefully a win-win.

We will start in the simplest imaginable manner by capturing the most primitive picture we have in mind, which could be something as follows:

Let’s try to bring some clarity as to the business benefit. One of the key reasons organizations outsource is cost reduction. The other common one is access to a potentially larger pool of labor thus providing better scalability in terms of hiring new talent. Let’s stop there and capture what we just learned on our enablement chain:

Usually, the cost advantage organizations are looking to have is on the order of 50%-75% of domestic rate. Reality, however, can paint a much more complicated (and much less encouraging) picture where the precious numbers may actually cost us dearly, unless certain focused effort is applied in that regard. Let’s explore this a little deeper. For that we are going to focus the following question:

Does outsourcing inevitably lead to such cost reduction or are there some factors that moderate the connection?

Well, the answer is: no, not inevitably so. And a big reason for that is a whole class of phenomena that one can characterize as hidden costs of outsourcing that can be very significant and yet hard to put your finger on it. Here are some factors that must be in place to exercise the desired benefit:

Alignment. Tasking remote team members gets you only so far. Proper alignment in terms of what, how and why to build requires sustainable and significant overlap across involved locations, which in case of offshore outsourcing is inherently difficult to attain. The actual manifestation of misalignment is actually in both building the wrong thing and building it the wrong way. Despite its superficial simplicity, it is often pretty hard to catch this problem early enough, when the cost of fixing it is still tolerable.
Mitigated delays. Different time zones impose yet another problem: extra wait time. Often a question that could be answered in 2 minutes—should all the participants be in the same time zone—may take the a full 24-hour cycle. This ingrains a multitude of small delays that may have a significant cumulative effect of the group’s productivity. Those delays need to be systemically addressed.
Full devotion to a common goal. That is not always the case with offshore outsourcing. For starters, you are dealing with a different organization and, as such, it has its own priorities. What’s interesting, however, is that even if its not a different organization but an offshore subsidiary of the same company, it still manifests some behaviors that are not so well aligned with the common objective. Namely, remote offices tend to invest in showing that they are of value and that the business relationship should continue or, even better, expand in its capacity. In addition to all the non-value-added “we-need-to-look-good” activities, that naturally emerge as a result of dealing with a geographically remote entity, there are also contracts that tend to over-emphasize what’s easy to measure (scope, time, for example), often at the cost of the actual value delivered.
Effective risk management. “Effective” means that issues transpire early and there is enough time to address them before more stuff gets layered on top of an existing problem. For multiple different reasons, including cultural impact, customer-vendor pressure and others, remote groups may end up favoring delivery of the good news over the bad one, thus delaying and amplifying the effect of impediments encountered in the development process.
Different facets of the skill. There is a little trick to saying: “The full cost of an in-house Java developer is $100/hr but we can find a remote one for just $35/hr”. The reason it is tricky is in that it usually isn’t just knowledge and experience in Java that you are looking for. One has to take into account their exposure to organizational context, understanding of the enterprise architecture, business domain, specific technology frameworks and their local customizations, etc. When you are hiring someone new, expect a learning curve. Furthermore, offshore format may impose additional challenge: some commonly shared metaphors at the HQ may be quite foreign to people from remote locations simply as a result of fundamental differences in their countries’ economies and people’s lifestyles. Something that is a habitually established notion in countries like the US (the concept of credit score or social security, for example) may appear unfamiliar or even exotic to some locations in Eastern Europe or APAC and thus impose additional layer of complexity in communications.

As a result, we are arriving at an enablement chain of the following kind:

All of the added factors moderate the connection between outsourcing and the desired outcomes we envision to attain from it. One may think of them as of “valves” on the pipeline. But I wouldn’t recommend going too far with that analogy.

Our next question will be as follows: what needs to be done in order for this enablement chain to actually work as expected? In other words, are those new connections that we’ve added going to just work no matter what or do they need enablement of their own? Well, clearly there are things that are vital for the chain to actually work, such as:
• Regular travel
• Extensive remote communication
• Growing skills locally

These, in turn, need enablement of their own: on the one hand they require regular investment of time by leadership and various subject matter experts and additional funding will be needed, too.

Besides what’s been presented, there are some factors that influence the entire chain, such as:
• The chasm between those who make a decision to outsource and those who will have to face direct consequences of this decision (a negative factor, obviously)
• Lack of proper feedback mechanism that would allow to understand if the outsourcing strategy is working out or not (also a negative)
• Development leadership is quite enthusiastic and eager to make this work at all cost (a positive factor)
The first two seem to be reinforced by the traditional stage-gate mentality. Our enablement chain will look as follows:

The chain allows us to conclude a few interesting things. First and foremost, we seem to have a better understanding of what kind of enablement is needed for outsourcing to work in our case. In fact, if it does look a bit complicated, that is for a reason: we actually are dealing with a complex decision and it has been a problem that such decisions are approached through unreasonable oversimplification, omitting the bulk of critical enablement that has to be in place. Now, our thought process as based on this diagram may inform a decision to continue on or to scrap the idea. One way or another, it will be based on a far better approximation than a mere comparison of domestic vs. offshore hourly rates and the job pool sizes. We may realize, for example, that as an organization, we are not prepared to invest in regular travel, all additional communication, extensive virtual knowledge sharing, etc. Or on the opposite, that we are totally willing to accept the investment because we have reasons to believe that we can still benefit from the model.

Second, if we were to continue, we would want to know what areas of our enablement chain should we expect to have the highest impact on the outcomes. This brings us to two important elements:
A) leverage points (in blue), and…
B) problem areas (in red)

The logic behind these elements is quite simple: leverage points is where you primarily want to focus your enablement effort and problem areas are what is inhibiting good outcomes and thus should be addressed. From both of those the organization derives action items in pursuit of the desired outcomes.

As a little commentary to the article, have you noticed how quickly the complexity of the “chain” has grown from the two connected dots to a whole cobweb of factors and enablement connections between them? Please note that all the diagram does is just reflecting the relationships that are out there. In other words, every time you look at an enablement chain like this and think “Oh goodness, this is quite complex”, keep in mind that your actual decision domain is complex and all the diagram does is simply reflecting that and helping you navigate through possible choices. This prompts an important takeaway that one of the goals here is to appreciate the complexity of the environment and make a judgement based on a reasonable consideration of important enablement factors and their connections.

Lastly, unless proven differently, every diagram is a hypothesis and thus requires validation. But this, as well as some de-biasing techniques is a matter of future articles.

What’s The Business Value of … Anything?

What’s the value of a new software feature, a corporate training or a marketing collateral? Sounds like something we should be able to answer at least because one way or another each of those assets have their cost, so we naturally want to know what is the benefit. And this is where things usually get tricky. The cost is quite easy to figure out; the benefit (or the business value) are not so much so. Here’s why…

A software feature, in and of itself, rarely represents business value. What usually happens is that it may enable some new user capabilities that subsequently create new user value. So, for example, de-duplication of business transactions data (as a feature) enables an analyst do provide a better sales forecast and thus the organization to more effectively plan the manufacturing process. A corporate training, similarly, does not represent direct value, but through instilling new techniques and behaviors in workers, will result in certain business benefits. A marketing collateral represents value only as much as it enables better brand and product awareness. So, here’s the common trait across all our examples:

An asset (like a software feature, a training, a marketing material, …) may itself not represent direct business value at all; it’s utility is in how it enables business value.

Today’s organizations are incredibly complex and often we need to determine value of an asset that is so far down in the long enablement chain that it takes many “transitions” for it to result in something that is ultimately valuable to the business. No wonder that organizations happen to waste precious resources on doing things of little value as the proper understanding of enablement chains is missing.

In a few subsequent blog posts we will make a deeper dive into the specifics of analysis of enablement chains and thus advancing our understanding of the value an asset represents to the organization. But as a little teaser, I’d like to outline an example here. It outlines one specific aspect of enablement, namely understanding the required enabling factors and their connections.

Assume an organization considers buying a training for their sales people. The training delivery will cost the organization $60,000. By dint of astrology and crystals, the organization has figured that they should expect $800,000 increase in sales within 12 months following the training. Let’s ask ourselves a question: is the $60,000 investment going to inevitably turn into an $800,000 payoff? The answer is actually: no, not at all. There is no inevitability in that outcome. The enablement connection contains quite a bit of complexity:

The training has to actually be relevant (i.e. apply to the organization’s environment), the instructor needs to be really good (and that’s never a given), attendees have to be 100% present and engaged (not so easy with sales people)… But even more importantly, the new approaches and behaviors that the training encompasses are going to need to be further adjusted to the organization’s context, some additional software enablement may be required (different functionality of the CRM system, for instance), and over time some additional coaching may be needed to properly adopt the techniques across the diverse customer base. So, all of a sudden, we are talking about a more complex picture.

This example shows how multivariate enablement is and how easy it is to commit organizational resources to something that may, despite the great expectation, produce zero business value. It also shows us that alchemy and crystals have very limited applicability in enterprise context (despite the fact that almost every organization uses their version of “supernatural” means to rationalize desired outcomes).

But there is a better way and we are going to incrementally uncover it in this post series.

Hope you enjoyed this little blurb!

Webinar: Faster Value Delivery

Hi guys,

We’re gonna have a webinar on improving value delivery throughput in software and systems development. If you are familiar with the basic concept of throughput, register and you will be surprised how inaccurate conventional notions can be in the environment of complexity and uncertainty. More info regarding the webinar:

Every organization wants to be able to improve their speed of value delivery. Far not every company, however, realizes what it actually entails. In this webinar we will talk about the following topics:

  • The actual meaning of value throughput in software and systems development
  • Uncertainty-based flow model
  • Structural changes to improve value throughput
  • Changes in planning and execution
  • Further optimization

The talk is for coaches, facilitators and leaders of all levels.

Insight: Faster Value Delivery

Everybody cares about the speed of value delivery. And why wouldn’t they, it makes so much sense. The higher the speed of value delivery, the more value you can deliver to your customer, the better the business outcomes. Well, it is, but only if you understand what it really means.

First and foremost, it’s not “speed of delivery”, it’s “speed of value delivery”. The difference is everything! You can actually learn to be faster in terms of development and deployment of new scope (and some organizations do), but what is being delivered may have little-to-nothing to do with value: the functionality produced may not be something customer wants or likes or finds useful. Or, even though customer likes it, it produces no economic benefit to your organization and sometimes even on the opposite – leads to negative economic outcomes. So, takeaway one: speed of value delivery matters only when what is being delivered is valuable. Seems trivial. But isn’t so in a real life. Often it is automatically assumed that “what we deliver is a value” and the only thing we need is “to speed up”. Big mistake and often leads to poor results.

Two… Once we’ve realized that value comes first, we naturally begin seeking faster ways to create and deploy it. And this is where things get a little tricky. We used to this common perspective: stickies (that represent valuable backlog items) moving left-to-right on the board. All you need to do is make them move faster, right? Well, actually it is not in software and systems development world. To understand why we need to look a little deeper into what is contained in those items. But first, let’s begin with a different case where moving them fast left-to-right makes a lot of sense. That would be in the case of a predictable environment. In that case, your backlog items are containers of value and your job is to drive them left to right through the process as fast as you can.

Repetitive processes or processes composed of a relatively small set of basic variations are usually like that and that often is the case in manufacturing and logistics.

What’s different about software and systems development is a significant amount of uncertainty involved. By definition it’s not a repetitive process, composed of a small set of basic variations. Instead, it’s an inherently complex process that inevitably contains impactful unknowns. The “speed of value delivery” is now not all about moving backlog items left-to-right in a fast manner. That may actually be detrimental. Different thinking is needed. Let’s start with updating our model with more adequate for this type of environment:

Backlog items now contain not only value, where we have strong reasons to believe that such exists, but also unknowns. Unknowns may relate to any aspect of development, such as whether this is the right requirements, whether the architecture will work, implementation, etc. etc. Importantly, unlike in the previous example, the actual content of a container is changing throughout the process itself! New unknowns transpire, existing ones resolve, producing value or damage, respectively:

A simple example of such progression could be as follows:

Our backlog item is a product feature “horizontal browsing of a media collection on mobile devices”. There is certain strong belief at the beginning that it has some value to the customer as it creates a more engaging user experience. But there’s one big unknown – this hasn’t been implemented yet and nobody knows what to expect. Over time, it turns out that the unknown resolves into damage: it doesn’t appear possible to make this a smooth movement; besides other problems occur like automatic shift of the slider after a media item was opened, watched and closed. And so forth.

Now it is obvious that our goal is not to get a backlog item as fast as we can across the finish line. What we would like to do is to 1) achieve high business value for an item and 2) do it fast. Generally speaking, the speed with which backlog items are moving through the system is no longer a key indicator of value throughput, as the actual content of those “containers” changes. Therefore, high-value throughput requires effective progression of backlog items “content”, rather than just quick execution of the initially planned work. Trying to make it faster may actually have an adverse effect on value.

Managing unknowns becomes critical to maximizing value throughput. “Managing an unknown” means devising a strategy of dealing with the unknown in a way that provides a better outcome. This brings an important perspective: the flow of value can rather be thought of as a flow of unknowns from identification to effective resolution in the form of business value.

By Alex Yakyma, Org Mindset.

Webinar Recording and Downloads: Enabling Dynamic Interactions and Flow with Integrated Footprint

Hello folks,

The webinar took place earlier today. Great discussion, good questions from the audience. This was a first time I presented the concept of Integrated Footprint in a systematic manner. Much of this material goes into our Enterprise Coach course (OMEC) v2.2 and Enterprise Facilitator course (OMEF). See our course schedule and course description for OMEC and OMEF.

Here’s the presentation download in PDF format:

…And the webinar recording itself:



Mile High Agile – Presentation Download and More

Hello folks.

Mile High Agile, even though just a two-day conference, felt like a whole week of focused effort. As you probably know, Org Mindset was a platinum sponsor of the conference and I had a presentation on day 2: “Addressing the Reductionist Mindset in Your Lean-Agile Transformation”. Very many people came by our booth, discussed our trainings, we talked about their challenges and plans in terms of transformation effort. Many old friends came to the conference, many new people we’ve met.

At the end of day one our impatience took over and we decided to do an experiment and provide a little transformation self-assessment handout that would allow people to quickly perform self-assessment just with a pencil, right on the spot. That seemed to have worked really well plus what could be more Agile than creating a deliverable overnight (including printing job; thanks to local Kinkos for quick turnaround).

BTW, you can get the electronic version of the same in our Products menu. It’s a method-agnostic (like everything we do) 50,000 ft view on your organization. Hope you’ll find some valuable insights out of that.

The room was full for the talk I mentioned above. We had plenty of people standing at the back wall. Good interaction with the audience, good questions! I enjoyed presenting it a lot to that audience!

Here’s the presentation file:

Lastly, I think the conference was really well organized. We were interacting with the committee for quite a while (as a sponsor, we had a ton of things to do leading to the conference itself) and that collaboration was really effective (thanks to Lissette Wells, among other people who helped us in the process). The conference was fully ran by volunteers and they did a very good job!

A quick reminder on side topic. We have a webinar on May 30 on “Enabling Dynamic Interactions and Flow of Value“. You are very welcome to join!

Stay tuned and have a great Lean-Agile rest of your day,


Webinar: Enabling Dynamic Interactions and Flow of Value


Hello folks, please join us for our next webinar: “Enabling Dynamic Interactions and Flow of Value”.

When: May 30, 2018, 11 am MDT.

How to register: Follow this registration link.


Modern organizations are complex organisms and one of the aspects of complexity lies in the dynamic nature of work to be executed. It is due to insufficient understanding of this important fact that facilitators, coaches and leaders struggle to effectively implement Lean and Agile in their environment. As a result, team structures, interaction patterns, specific processes and success indicators become obsolete and further improvement ends up being impossible.

In this webinar we will talk about solving the problem and will touch on the following topics:

  • Dynamic work footprint and team formations
  • Planning that preserves flexibility
  • Facilitating dynamic team interactions and swarming
  • Applying contextual success indicators to measure and improve flow

This talk will be useful to Lean-Agile coaches, leaders and facilitators.

See you there,

-Alex Yakyma



Coaching Organizations to Accelerate

Is high speed good or not?

We generally believe that it is. But it’s not all that simple. True, if you ask any given enterprise whether they would like stuff being delivered faster or slower, they will pick “faster” every time. Here’s an important question though: the speed of exactly what are we so concerned with? Feel free to fill out the blanks:

We are trying to accelerate the ______________ in our organization.

What did you put in there?

Here’s what’s interesting: for very many organizations the phrase in the blank is “scope delivery” or “delivery of functionality” or “delivery of features”. (Note that here by “delivery” we mean development and deployment, altogether). Now, I wrote about this a number of times before that scope does not equal value and trying to approximate value by scope is a dangerous business as, generally speaking, one has little to do with the other. Today’s solutions are so complex that any significant step forward in the development of new functionality pushes us into an unknown territory where all we have is assumptions that require validation. Will the users like the new feature? Will it solve their problems? Is this new feature-set a sufficient reason to increase the license cost? Will this new caching algorithm work well under various production scenarios? Will our business partners find this API easy to use? Will this UX simplify conversions or we will keep losing potential customers? Etc.…etc. The scope itself has little to do with this. Moreover, the more you add to your solution, the more difficult it gets to add new functionality in the future. So, if we stuff our system with much fluff, then when the time comes to implement something really important, it will be a very difficult and painful process. So, takeaway #1:

We want to speed up the delivery of actual business value, not just any functionality.

That sounds better, doesn’t it? But here’s the catch: how do you determine what’s more and what’s less valuable? Well, someone may suggest a kind of prioritization process, and that immediately makes us feel so much better… while it probably shouldn’t. Here’s why. Let’s ask ourselves, how are those priorities being assigned? Well, a few decision-makers get together and figure it out, right? Well, too bad, because that’s the easiest path to indulge confirmation bias in full. And then whatever we call “value” is no more than our wishful thinking. Since when an isolated, internal opinion is a sufficient substitute for customer feedback or proper technical or market validation? But what a great sense of false security it creates!

An organization needs to establish a process by which they properly learn what’s value and what’s not. Instead of sweeping assumptions under the carpet, those assumptions need to be properly managed. In some cases, it means consulting with the customer and end users, in others – test-driving a prototype, yet in others a fully functional system for a subset of users and so on. And yes, sometimes there will be no other choice than to learn by doing, but that has to be clearly understood by decision-makers and treated respectively. Hence, takeaway #2:

The speed of value delivery is contingent upon organizational learning.

Now we are getting somewhere. Learning requires feedback cycles that cut across organizational levels and even the organizational boundary itself, therefore involving external parties that pay for, support or use the solution. In fact, this second statement is paramount: if the organization cannot learn fast, but keeps pushing hard in terms of delivery speed, it turns into a high-throughput poo-poo delivery vehicle.

Now’s the time for a few coaching tips (again, as always, mind your context when applying anybody’s suggestions):

  1. Disrupt the conventional isolated decision-making pattern by involving people from different levels (and, importantly, from outside the org.) as part of the routine.
  2. Coach the management to encourage alternative thinking and disagreement. Creating psychological safety around it is a primary goal.
  3. Start to manage assumptions explicitly. They need to be identified and acknowledged, for starters. Imagination is one thing; reality is quite another.
  4. Establish reliable feedback for functionality already delivered and have decision-makers compare expectations with empirical evidence.
  5. Coach the organization to operate with thin vertical slices of end-to-end value (emphasis on end-to-end). Move away from deep hierarchical work breakdown structures, as those are optimized for implementation (where we pretend that there’s no unknowns) and what you need instead is to optimize for learning (where you explicitly acknowledge and effectively manage assumptions). In some cases WBS is unavoidable. Then at least subordinate it fully to vertical slicing.

Want to learn more? Then it’s time to up your game and attend our Enterprise Coach class.

5 Tips for Better Organizational Coaching

Organizational coaching and change leadership are tough disciplines that lie at the intersection of social and neuroscience, systems thinking, complexity theory and more. If you are a coach, continuously improving your professional skills and knowledge is like oxygen: the organizational landscape is so broad, complex and diverse that you can never be “prepped enough”.  Here are some tips that can help advance in that direction.

Tip 1. Work with key decision-makers.

The logic is very simple here: if you want real change to happen, you need to drive the mindset shift in those whose decisions affect the organization a lot. Here lies an increasingly common mistake among enterprise coaches and transformation agents: they get stuck at lower levels, and they get stuck for good. Often various excuses are readily being made, like “I’ll start downstairs and will gradually make my way to the upper levels of the organization” or “When the leaders see what we’ve done with teams, they will quickly change their thought process”. No, they will not, and no, you will not naturally move upstairs just because you’ve worked with lower levels. One needs to start working with key decision-makers as early as possible, and that has to be an intentional (and big) part of your transformation and coaching activities. We’re going to publish some suggestions of how to enter those levels as a coach in the future. But some of those you already know and just need to execute. Getting to do this is not easy, and you will be dealing with a lot of differences in thinking as well as resistance, but you will also know that you are doing a very important thing for the organization. So, again, begin addressing the area where critical, impactful decisions are being made. When to start doing that? You guessed it correctly: right now!!

Tip 2. Utilize your knowledge of methods, but expect adjusting or even drastically altering the actual constructs to meet the unique organizational context.

Enterprises are very different in their structural and behavioral aspects and carry unique cultural DNA. There is no way in the world to know what ways of working will fit the organization the best. Instead, best ways of working emerge through experimentation, trial and error. Therefore, knowledge of various practices, concept, and ideas can be very helpful, but only as long as we are conscious of the emergent nature of optimal organizational behaviors. Sometimes this adjustment or tailoring is quite moderate, but sometimes it can be very significant, leaving very little in common with the initially selected “starting point”. In OMEC we go over a number of ways for making such adjustments. Here I will mention one: adding/removing constraints. Every practice or construct can be viewed as a set of constraints. Modifying those constraints at a more granular level provides a whole spectrum of future paths for evolving context-specific practices.

It is vital, however, that the adjustments reflect the objective nature of the organizational environment and are not used as a way to avoid any significant change. The temptation of staying in the current comfort zone is too great, and you as a coach have to be aware of that.

Tip 3. Watch for long-term effects.

And that is if you care about the actual results of your work. Change is often not so hard to initiate. It’s a lot harder to sustain, however. Declaring victory after a few months of using new ways of working, is simply premature in systems of complexity, like modern enterprises. In fact, it is very common that the change gets well received from early on when the initial wave of enthusiasm seems to keep everything going in a right direction. Later, however, the unaddressed issues in organizational mindset and culture strike back and may obliterate everything that has been built so far. Creating sustainable organizational habits, therefore, is key to transformation success. We focus on specific tools to achieve that with coaches: “reinforcing feedback loops” (second-order loops that provide vital information on the process itself), “enabling practices” (and the overall understanding of connections across practices and constructs implemented in the org), “embedded mental models” (mental models associated with a specific practice or construct) and more… Have to keep in mind that sustainability doesn’t occur on its own. It takes focused effort!

Tip 4. Keep your eyes open for organizational impediments.

Solving systemic impediments to change is no easy job. But quite often the actual causes are right on the surface and for a coach, ignoring them or putting them on a back burner, pretending that they will be addressed later, is a poor strategy. What are these impediments? While every organization has its unique twist on everything, there are some common suspects, including rigid organizational planning and funding processes, measures and KPIs that favor individual heroic effort and enforce ultimate conformance to the long-term plan, leadership behavior that creates a wrong example to others and so forth. Without addressing real problems, it is useless to work on introducing new ways of working. Your time is precious so focus your effort on the right thing!

Tip 5. View every transformation as a learning journey not only for the organization but also for yourself.

There’s nothing more damaging than a change agent or a coach that “knows everything”. Usually, that means that they fail to realize that they operate in a highly complex environment where experimentation and emergence of qualitatively new constructs are far more important than a large bag of “known tricks”. The worst thing about this is that such coaches miss most of the opportunities to advance the organization’s performance and can only move within tight boundaries of their self-imposed myopia. Don’t be that and keep your ear to the ground. Some of your expectations will work out, some assumptions will be wrong – that’s the rules of the game. What makes real difference is whether you will show enough flexibility to regroup and exploit improvement opportunities that emerge every step of the way. You can either “know everything or actually be useful” and I want to think that you choose the latter, as per your life’s mission.

Alright, folks, that’s the message for today, and I wish you to be productive in your coaching endeavors.

Want to take the next step as a coach and organizational change agent? Then what are you waiting for? Learn advanced tools for enterprise coaching.