Author: Shlomo Swidler

Categories
The Business of IT

Culture of Learning

El Obelisco in Plaza de la República, Buenos Aires, Argentina
El Obelisco in Plaza de la República, Buenos Aires, Argentina

What does getting lost on the streets of Buenos Aires have to do with high performance? I could see my destination—a restaurant near Puerto Madero—clearly on the map in my hand, yet every turn I made seemed to take me farther away. It made no sense to me. I began to become frustrated. I always thought of myself as having an excellent sense of direction, yet none of my skills were helping me. What was wrong? I was about to give up and call an Uber.

Then I realized. I had been navigating using the context that I had learned in my childhood in North America, where the sun is in the Southern half of the sky. But I was in the Southern hemisphere, for the first time, where the heuristic must be reversed. So every time I turned left I should have turned right, and vice-versa. Once I realized the correct context, the map suddenly made sense and I quickly reached my destination (and had a delicious meal).

What had happened? I had been operating under assumptions that were not true for my current context. This disconnect happens often in organizations, and it kills performance.

Everyone in your organization should share a vision about the purpose of the organization. I don’t mean the goals—though those are important—but goals change, and I am referring to something more fundamental: an agreement that everyone’s purpose is to learn together. To learn how to deliver better products, more quickly, more safely, and more sustainably. To learn about the customer, the problem domain, and the tools that must be wielded to fill the customer’s needs. To learn.

This common agreement about how we make our decisions is what we call culture. And a culture of learning is paramount for achieving high performance. Seek to become a learning organization.

Categories
The Business of IT

What is a learning organization?

Now that you know why you shouldn’t become a software business, you need to know about becoming a learning organization instead. As discussed, a learning organization rapidly learns about the customer, the problem domain, and the tools they must wield to fill the customer’s need. But what are the ingredients of learning itself?

To learn about any subject, the following three elements must be present:

  • A clear purpose.
    You must have a goal in mind, a challenge you are trying to address, or a question you are trying to answer. Learning only happens when you are actually interested in the subject, as my classmates in my Hebrew class in third grade will attest—it was very boring and I retained next to nothing from that year. On the other hand, when you are genuinely committed to the subject, you will persevere despite challenges. As a child I didn’t have the “rounded” Lego pieces necessary to build the iconic black-and-white Airwolf helicopter, but I devoted hours and hours over several weeks in repeated attempts to constructing the best replica I could from the only pieces I had, mostly blue and grey rectangular bricks. It was really cool (in my pre-teen opinion). And I persevered because I had a clear purpose in mind: to create something really cool.
  • A commitment to and curiosity about truth.
    Curiosity and commitment to truth are the engines that drive learning via the scientific method. Brook no hidden agenda, accept no propaganda, and harbor no preconceived notion of what the solution must look like. As a young software engineer I once was helping a colleague debug some anomalous software behavior. We interrupted the program to debug it step by step, and watched the internal state of the program while it—we thought—was exhibiting the faulty behavior. Convinced we were witnessing a bug, we tried to explain every observation accordingly. But we failed to reproduce the issue, calling into question all of our explanations. Only afterward, when we allowed the program to continue running to completion, did we understand what had happened: I had pressed the wrong key, which executed a completely different function than the one we were trying to diagnose, so all of our explanations were wrong. Yet we had been doggedly trying to explain how correct they were! Respect the data: If the conclusions don’t match your hypothesis, then the problem is in your hypothesis, not your data.
  • Rooting out frustration.
    Adam Smith’s “invisible hand” driving economic progress is the human desire to eliminate frustration from our lives. We seek lower prices for commodities because it irks us to pay more than our neighbor pays for the exact same product. We invent new labor-saving devices because less labor means less frustration. Frustration points us to opportunity for improvement. In your organization, what frustrations are important? What are your customers’ frustrations, and what about the frustrations that workers encounter while building and delivering your product or service? These are the frustrations you should identify and seek to eliminate. Too much attention has been paid to “promoting empathy,” which cannot be measured objectively in a corporate setting. Frustration can be identified and measured. Rooting it out forces you to focus on the very areas that are opportunities for improvement.

When you have clear purpose, commitment to and curiosity about the truth, and a relentless pursuit of rooting out frustration, learning ensues. You learn about your customers, the problem domain, and your own tools and processes with fresh eyes, open mind, and focused energy. That is what it takes to be a learning organization.

Categories
The Business of IT

Don’t become a software business, become a learning organization

Watts S. Humphrey famously said, “every business is a software business.” Unfortunately, this statement has been misconstrued by well-meaning IT practitioners to demand primacy in the organization’s strategy, budgeting, and focus. But nothing could be more dysfunctional than letting technology lead your business.

A business exists to serve customers, and nothing else matters. Customers don’t care about anything “behind the curtain,” only the elements of your business with which they interact.

Here it is laid out in a convenient table:

Customers don’t care about:Customers do care about:
The tools you use while creating itThe tools they use to consume it
The clothing you wear while building itThe clothing you wear while interacting with them
The corporate mission statementThe company’s impact on their values
How easy it is to create itHow easy it is to consume it
Your share priceHow well you will serve them in the future

Do customers care what technology you use? No. The technology you use is just a tool to create the product/service.

Stop letting your technology organizations lead with technology. Instead, transform your entire organization—including the technology functions—into a learning organization. A learning organization rapidly learns about:

  • the customer
  • the problem domain
  • the tools they must wield to fill the customer’s need.

What are the elements of a successful learning organization? Watch this space for my next article.

Categories
The Business of IT

The value of planning for unplanned value

Your organization has one job: Deliver value to your customers. But not all kinds of value are the same, and not all manners of working to deliver value are equivalent. Do you know where your organization is devoting its resources? Let’s examine these parameters and how you can improve the way you work to deliver both kinds of value.

Value and Work

There are two types of value you can deliver: You can maintain old (already-delivered) value, for example you can restore your website when it goes down or you can repair a failed product. Or, you can develop new value, for example performing R&D for new or improved products. Both types of value are important to customers.

Likewise, there are two ways you can work to deliver value: in a planned fashion—following a product roadmap or pre-scheduled plan, or you can perform unplanned work, addressing acute issues as they arise—for example changing dead batteries or replacing depleted printer toner cartridges. Both manners of working are necessary and important.

Value vs. Work

Let’s take a look at the diagram showing Shlomo’s Value Investment Vault for some interesting insights. In the top left quadrant you have planned work that maintains existing value. We all know that light bulbs and printer ink will eventually need replacement, and we could (given the discipline and metrics) plan to replace them on a schedule. This kind of work is repetitive and enervating, devoid of creativity, but performing it in a planned fashion is preventive and avoids frustrating interruptions. Such work is ripe for automation and robotics.

In the lower left quadrant lies unplanned work that maintains  existing value. Most often we don’t know when the website will suddenly go down or the truck will get a flat tire, yet we must repair them in order to restore service. This kind of work is characterized by interruption, frustration, and urgency. While there is no way to eliminate this type of work, you can reserve enough extra capacity in your organization so it does not unduly impact planned work.

The upper right quadrant is where innovation happens. Your products and your teams improve in measured, planned steps. But don’t forget about serendipity: The lower right quadrant is where you can capitalize on discovering new value from previously unknown or unpredictable situations.

How is this Useful?

Use the Value Investment Vault as a diagnostic tool to analyze your current activities. How much of the work your organization performs falls in each of the above quadrants? Poor performers find themselves on the left side of the diagram most often, and seldom have the capacity to innovate, let alone exploit and discover new opportunities. Elite performers spend most of their time on the right hand side—and most of that in the upper right quadrant delivering innovation—and they reserve enough capacity to easily handle unplanned work.

If you need help getting there, you know whom to call.

Categories
The Business of IT

Cost vs. Value

Are you in an organization that can not or will not fund improvements because there is zero cost-savings accrued as a result? Are important decisions forcefully hammered flat into a single-dimensional cost metric? Must you justify every action with a business case that boils down to a price tag? If so, I feel sorry for you. The most respected organizations in every field take a more mature view: Value, not cost, is king. And value attracts business.

Value is not cost. Your organization already knowingly or unknowingly invests in value without knowing the associated cost or without being able to guarantee a monetizable benefit. Consider these activities:

  • Improving customer loyalty
  • Delivering innovation
  • Assuring quality of product or service
  • Maintaining relationships with partners
  • Fostering employee satisfaction
  • Improving relationships with suppliers

None of these activities would ever be conducted if cost-savings was the yardstick by which the decision was made. If you do not invest in earning customers, you will have no customers whose satisfaction matters. In fact, no new venture would ever begin if cost-savings was the overriding criteria. And if cost-savings is your only criteria for operating an existing venture, then your venture is not accruing value—it is stagnating, slowly dying in place. You can’t cut your way to growth.

Explore these and other dimensions of value when you next consider a business decision. Business is about more than maximizing revenue and minimizing cost. Business is about value, and value is multidimensional.

Categories
The Business of IT

Digital Transformation, DevOps, and the Bugaboo of Change

How do you feel when you contemplate the idea of changing the way your organization operates? Scared? Jaded? Excited? Your answer—and the answers your employees give—to this question reveals how difficult it will be for you to pursue Digital Transformation and DevOps.

This photo, “change machine,” is copyright © 2009 tracyshaun and made available under a Creative Commons Attribution-ShareAlike 2.0 Generic License.

Ron Westrum described three types of organizational culture: pathological, bureaucratic, and generative. The names are unfortunately clinical, but I summarize them as follows:

Pathological culture: Change is fatal.

Bureaucratic culture: Change is futile.

Generative culture: Change is fertile.

DevOps and Digital Transformation demand new ways of operating, and your organizational culture will determine your success. If your organization feels that change will be fatal, your transformation will require intensive expert help. If the feeling is that change will be futile, your transformation will be merely difficult (and expert help is still warranted). And if the pervasive feeling is that change is ground for excitement and innovation, then you have already slain the main bugaboo of change.

Categories
Case Studies

Case Study: Innovation at Ticketmaster

One day I got call from an executive at Ticketmaster. They are a multi billion dollar company selling tickets to the world’s largest concerts and sporting events. Ticketmaster was having three problems.

One problem came from the marketplace: Lots of companies were trying to get into the online ticketing business, like StubHub and other startups. These companies, since they were small and nimble, could do disruptive things quickly, so Ticketmaster was scared of them.

The second problem was customer satisfaction: Too often, their web site went down. When it did, customers experienced a world of anguish. They were trying to buy tickets for concerts that were selling out in seconds, yet when they went to pay, their shopping cart would just hang, unresponsive, and they were unable to purchase tickets. Not only were these frustrated customers not getting the tickets they wanted, Ticketmaster wasn’t getting their money, and its reputation was taking a horrible hit. So Ticketmaster wanted to get its web site up quicker when it went down, and wanted it to be more reliable so it wouldn’t go down so much.

The third problem was technology: Ticketmaster relied heavily on decades-old technology. They knew that a newer technology platform could allow them to move faster, but they were terrified. The new technology platform held the promise of working better and alleviating some of the downtime, but they feared the incompatibilities and unknown amount of work to adopt the new platform.

So they hired me.

I spoke to their executives. I interviewed their technical leaders. I reviewed their structure, goals, and strategy. And I noticed something they weren’t seeing: Their product teams were often fighting each other. They were all vying for resources from the same pool, including time, money, and executive attention, often stepping on each other’s toes in the process. With all that conflict and tension, the important stuff just wasn’t getting done. And this issue was slowing everything down, causing their main problems: the hesitation to adopt new technology, the slow progress to create a more reliable web site, and the worrisome pace of their competition against upstart newcomers. I knew we would need to solve that one problem—the problem of teams working at cross purposes—and it would be a linchpin for relieving all three problems they were having. So I said, “If we give the product teams the ability to conduct multiple projects simultaneously, without conflict between them, the three other issues you’re having will be solved too.”

And that’s what we did. We restructured the organization to reduce interdependencies between teams, granting each product team full control over the financial performance, technical performance, feature roadmap, support, and work priorities for its product. We refined the product strategy in order provide more relevant guidance to these newly independent and empowered product teams, yet allowing them to set their own priorities within the strategic framework. And we established clear criteria for product teams to judge the value of the various investment options they faced simultaneously at any moment.

As a result, tension between product teams was dramatically reduced, allowing the work to proceed much more quickly and with a much more healthy mix of short- and long-term projects. This encouraged both maintenance of existing services—short-term investment—together with rapid innovation—longer-term investment. The newly-independent product teams were able to significantly improve the website uptime because they now had the time and inclination to work on addressing the underlying core technical issues, instead of firefighting the issues as they occurred—and customer satisfaction skyrocketed. Very soon thereafter product teams began to seek guidance on how to move to the new technology platform—now that they could invest in the long-term, they quickly appreciated the benefits of the new technology platform. And over the next several months large numbers of product teams migrated their software to the new technology platform. The pace of product development was dramatically increased, and innovative new features and services were coming to market more rapidly than ever before.

We could have solved Ticketmaster’s three problems by creating multiple problem solving teams, but that would have been duplicate work. What I saw allowed them to solve the one problem that had a cascade effect on solving all the problems they had with minimal effort: If the teams were freed up to work without conflict, they could take on all these problems in the normal course of their work. And that’s exactly what happened.

And today Ticketmaster is still number one in their space.

Categories
The Business of IT

Innovation Motivation

Have you ever seen someone sporting the latest and greatest in technical wizardry—perhaps they are very proud of their new iWatch—but you are unimpressed by it? Sure you have. You have also seen someone sporting the latest and greatest in technical wizardry—perhaps in 2007 you thought this about the brand new product called the iPhone—and you thought to yourself, “that really solves a problem I have; I need that.” What differentiates those two types of products? What can a producer do to ensure customers have the latter reaction, and not the former? I call the distinction Innovation Motivation, and it is described well by Shlomo’s Innovation Motivation Matrix (IMM).

The IMM shows how customers react to different types of innovations. Horizontally, we have two different types of motivations for innovation: The innovation being introduced can be motivated by the wish to help the customer, or by the desire to use new technology. Vertically, we have different degrees of novelty being introduced in the product: Either low novelty, which represents incremental improvements to existing products, or high novelty, representing dramatically different capabilities.

When the producer introduces new products with low novelty and motivated by the desire to adopt technology, as depicted in the lower left quadrant, the customer is puzzled. Who needs a toaster with an internet connection? Of what use is a coffee machine that snaps a photo each time you load it? These products fail to connect with the customer because they are conceived without the customer and deliver no special benefit.

In the top left quadrant, the company introduces great novelty, but for the sake of the technology, not the customer, and the result is customer alienation. Personal 3D printers might be technologically new and cool, but they are (as of today) hardly useful for the general public. Roomba, the giant hockey puck that autonomously vacuums the floor, is amazing technology, but in every household I’ve seen it, it sits in a corner gathering dust once the novelty has worn off. It’s not very useful, the customer regrets spending money on something so cool that quickly becomes so useless, and so they feel alienated from the company, unlikely to buy anything from them again.

But when the company focuses on the customer in developing new products, great things can happen. At the very least, the product will offer satisfaction, shown in the IMM’s bottom right quadrant. RFID-enabled luggage tags are an incremental improvement to the traditional luggage tag, and they deliver great benefit to the customer: reduced anxiety about, and incidence of, lost luggage. Fitbit is not very novel, but customers love tracking their vitals and challenging themselves to meet fitness goals.

At the best, when the customer is the focus and the novelty is high, the product can deliver amazement. 2007’s iPhone was truly revolutionary, and everyone had to have one. The Dyson hair dryer is orders of magnitude better than the standard appliance, and worth the matching price tag. Amazon’s Alexa is a completely new class of device, and it delights customers with its ability to orchestrate so many elements of the household.

The lesson for product companies is clear: Focus on the customer, not on the technology, in your innovation. The early 2010s saw many software companies avidly adopting cloud computing—a technology—for its own sake, without pausing to consider why the customers would care. Predictably, these companies failed to impress customers and sank into irrelevance.

If any of the following signs are true about your product development efforts, you are likely puzzling or alienating your customers:

  • The product label or advertisement contains jargon or three-letter-acronyms (TLAs).
  • You can’t explain why customers will continue to use this product a year later, after the novelty wears off.
  • The customer’s emotional state is not altered significantly by the product.
  • Customers have not been involved in the product design and development.

Where do your company’s products fall on the IMM? What motivates your product development efforts, and how novel are they? Answering this will help you discern what you need to do to satisfy and amaze your customers.

Categories
The Business of IT

How am I doing? That depends who is asking

How good are you at your favorite activity? Wait—don’t answer yet, because you’re probably wrong. Your perception of how good you are is influenced by how good you actually are. This is explained by the Dunning-Kruger effect, which is cognitive psychology’s name for the disparity between self-perception and reality. Here is what it looks like:

The Dunning-Kruger Effect demonstrates that the less you know the more you think you know.
The Dunning-Kruger Effect demonstrates that the less you know the more you think you know.

Low performers think they are high performers. High performers think they are high performers. Only medium performers think they are worse than they actually are. Consequently, if I were to walk into a room of people and ask for volunteers to help me solve a problem in an esoteric field of study, such as partial differential equations, I would likely be better helped by asking a person who did not volunteer!

This quirky reality underscores the need for objective assessment, and it is true for individuals as well as organizations. To avoid the pitfall of the Dunning-Kruger effect in your assessments, seek help from an outsider who is, by definition, not self-assessing your software organization’s performance. Until recently there were no objective statistics available for software organization performance, but now the industry benchmarks and scientific evidence-based models are available—I know, I have been using them with clients. Companies ignore these objective data at their own peril.

Contact me for hep evaluating your organization’s performance.

Categories
The Business of IT

Software Factory Taxonomy

Do you wonder why your software organization struggles to deliver value rapidly, reliably, and consistently? It’s because something is wrong with either the organization’s structure or its relationships—or both.

The software factory consists of its structure and its relationships. Some combinations are much more effective than others.
The software factory consists of its structure and its relationships. Some combinations are much more effective than others.

The following diagram, which I call Shlomo’s Software Factory Taxonomy Matrix, illustrates this effectively. Organizations are structured horizontally, delivering a single functional area such compliance or QA, or vertically, delivering a single product or service. The inter- and intra-organization relationships are simple, when they don’t distract from forward progress, or complex, when they do.

Most large organizations are structured horizontally and have complex relationships. This is the bastion of bureaucracy, where more energy is devoted to internal relationships than with the customer and her needs. The Department of Veterans Affairs is a painful example, notoriously mired in paperwork and hoop-jumping and poor on results. Most legacy IT teams reside here.

Simplifying the horizontal organization’s relationships can dramatically improve service. This is the domain of steady performance, or “tanks,” who make progress very reliably but relatively slowly. Single-function teams often reside here, such as an internal Infrastructure as a Service function.

Vertical organizations with simple relationships are swift, like fighter jets. They move very quickly, perhaps leaving some pockets of resistance behind them, but they achieve their objectives (delivering the service) rapidly. A cross-functional single-product silo lives here, as do product-centric DevOps teams.

Vertical organizations with complex relationships are what I call “wasted potential,” like grounded jets. If only they could get out of their own way they would be effective fighter jets, but they must devote too many resources to the complex relationships instead of making forward progress. A failed DevOps transformation often ends up here.

At least 80% of software teams are stuck in the Bureaucracy quadrant. What would it take to reorient their structure and simplify their relationships to unlock high performance? Contact me for help.