That’s Solutioning!

That’s Solutioning!

“Pain-Driven Design” is a great name for the discipline required to build the right thing rather than building the wrong thing the right way. Laura Klein defines this methodology in her book UX For Lean Startups, which you should add to your reading list.  “Pain-Driven Design” captures perfectly the heart of how product innovation needs to proceed when following the principles of the Lean Startup movement. Be forewarned, it is simple to understand but requires enormous discipline.  I have seen it done very poorly or completely disregarded by dozens of companies of all sizes. 

The steps are:

  1. Validate the Person – Be specific about the person you are planning to help (as an archetype and anecdote for a sufficiently large audience of people with behavioral patterns in common).
  2. Validate the Problem – Understand the pain experienced by the person in step one.  Listen to them.  Watch them.  Learn from them.  If you already have a product, learn what they hate about it.  If they use your competitor’s product, learn what is imperfect about the way it solves pain for the person.
  3. Hypothesize the Solution – Now you think up a solution.  Once you have a specific person to empathize with, communicate with, and build a relationship with (as a representative of a group called a “target market”) you can truly understand their pain and address that pain.
  4. Validate the Hypothesis

Of course, I entitled this post “That’s Solutioning!” so let’s start over at the problem phase.  The reason most product innovators fail at solving pains is that they are too busy solutioning to notice all the pains in the first place!  While facilitating groups in enterprise software customization, I saw this all the time.  The discipline required to truly analyze the pains and painful inefficiencies locked away in a workflow – physical or virtual, while shopping or at home or on the job – is tremendous when we are all so excited to get our ideas out there!  I had a colleague who could jovially point right at someone and say “That’s Solutioning!” to keep the group on track.

Obviously (in retrospect), when I wrote about my perfect agile processI glossed over the critical difference it makes to empathize with a real person to understand their pain.  This is the test every “idea” in the Idea Backlog needs to pass prior to validating hypotheses, experimenting, or developing anything. 

It was nice to see I’m not alone in thinking this way:

The vast majority of time I talk to entrepreneurs, they present me with solutions rather than problems.  They say things like, “I want to add comments to my product,” not “My users don’t have any way to communicate with one another, and that’s affecting their engagement with my product.”

By rephrasing the problem from your user’s point of view, you help yourself understand exactly what you are trying to do before you figure out how to do it.

– Via UX for Lean Startups by Laura Klein

This is the part of Product Ownership – more specifically, backlog grooming, prioritization, and decomposition – that ought to happen prior to Sprint Planning.  This is part of the “half her time with stakeholders” that should occur. It should be a significant amount of effort ensuring the market risk of building the wrong thing is overcome prior to mitigating the technical risk of the team’s ability to build the feature or the project risk of aligning resources and timing.

Here’s how to know an idea, an epic, or a user story has failed the Pain-Driven Design process:

  • If I say my target user is “women with an iPhone” then I’m not being specific enough.
  • If I state my solution without a problem then I’m not empathizing enough.
  • If I build a feature without empathizing with a person, my work is meaningless and my solution cannot be properly validated or a source of disciplined learning.

Imagine a bridge.  Everyone else who read this probably imagined a slightly different bridge.  What you most likely did not do is imagine a person who experiences pain crossing a river.  However elaborate your imagined bridge was, however perfect your engineering certainty about its development you may be, however robust your process for ensuring timeline and budget – that bridge is meaningless on its own.  That is the essence of solutioning: a decontextualized answer.

Do this instead.  Imagine a mid-twenties mother of one on the prairie in Kansas during the 1870’s.  Imagine a stream, only two feet wide but ice cold.  She jumps over this stream on her way to town, holding her child, husband by her side, every Sunday.  As the child grows and becomes heavier, jumping over the stream becomes more painful.

Now you have context.  Now you have a User Narrative and a person to empathize with.  There is a real pain that you can solve.  You can write a meaningful user story in-context: “As a mother on the prairie, I want a foot-bridge I can cross on the way to town because I’m starting to experience back pain that might hurt my ability to support my family’s health and well-being.”

Contrast that with an eCommerce executive yelling “We need SOCIAL!”

Don’t be that guy.

 
Photo via Kevin Sequeira

You have my permission to enjoy your vanity metrics.

I know I talk about valid metrics.  Ad nauseum. I won’t stop anytime soon – and seriously, you do need to get your act together.  That said, I empathize with where you are coming from.  So many numbers yet so little time!

 You have my permission to enjoy your vanity metrics. 

They feel good. When you’re winning, and they seem to scream SUCCESS! 

Getting more Twitter follows, higher site traffic, increasing revenue – focusing on whatever metric makes you feel better about the direction of your product, division, or company can be the little push that keeps you enthusiastic about your work.

I love my vanity metrics too: but this isn’t a “have your cake and eat it too” thing.  This is a “don’t eat cake when you’re dying of dehydration” thing.

So have fun and brag about them – to yourself.  Do not make any decisions based on them.  More importantly, as a leader, don’t let your followers waste time and energy justifying their decisions based on them.  

If you don’t know the one or two metrics that are an actionable, VALID, driver for hypothesis-based product innovation – find an expert who does.

“Managers who don’t know how to measure what they want settle for wanting what they can measure.” – Russell Ackoff

Photo via Luis Llerena

My First MVP.

Notice the blank spaces.  Notice the technological wonders that – despite my imaginative artist-engineering mind, you’d never actually see.

Tentatively Entitled – ShareLighter

Product Vision

Do you love reading physical books, but wish it were easier to share the insights you’ve gained and quotes you love via social media?  

Value Assumption

People want to share quotes from physical book pages with virtual highlights, blackout, or underlines as a form of expression. Someone – somewhere – in the fantastic conversations that grow from this narrative of noting, quoting, and sharing, wants to pay to be a patron for this game of reader-response, learn it and share it, cultural-criticism-gone-viral.

Growth Engine

Viral. People will love the app enough to share it with two or more friends. 

Success Metric

Viral coefficient, tracked by release version cohort analysis. If the viral coefficient is increasing, the cohort is correlated with the newest features, indicating they have tentatively proven their success hypothesis. 

Minimum Viable Product

To establish our baseline, we need the core functionality of taking a photo, highlighting text virtually, and sharing the photo with a caption to a social network.  To track our success, we will need an “invite friend” feature and the ability to correlate the act of inviting to the version of the app. 

“Blue Sky” Potential Features

You’ll have to see the Trello board…

Do you care?

You have other ideas, because you want this app too, right?  @mention me on Twitter for glory or shoot me an email. andrewthomaskeenermba@gmail.com 

How to Lose the Innovation Game

How to Fail at Agile, Ruin Your Culture, and Lose the Innovation Game

Cover photo via Andrew E Weber

There is one major issue that – if not properly addressed – is going to kill your company.  In fact, many companies FAIL MISERABLY when trying to break down silos, increase collaboration, and begin competing as a culture of innovators.  Every company must innovate or die.  Every product will face competition from a connected variant supported by a mobile app.  Mature enterprises who have never competed on innovation before are now suddenly competing with innovative tech companies!

Tearing down functional silos so that solution-oriented, self-contained, fully-functional and ultra-innovative collaborative teams is now THE biggest overarching challenge that will make or break enterprises that are struggling to maintain their decades-old success and strategic position.  Moving to agile in maturing industries, that are now being utterly disrupted, has become unavoidable for most companies.

The most common label for repositioning to compete on innovation is “agile” and breaking down silos is labeled “agile transformation”. 

There is a major failure that is gradually breaking many companies as their agile and high-tech endeavors fail miserably.  This is issue is caused by executive leadership’s denial and insecurity to face the terrifying reality that to truly “break down silos” is NOT (exclusively) a process transformation or change management issue.

Ready?

Here it is:  Breaking silos REQUIRES organization restructuring.

This major issue is two-fold and occurs simultaneously:

1. Failing to have “tech” report to “business”

2. Failing to have “business” people report to “tech”

There is an unwillingness to break apart and completely restructure the separation of “tech” disciplines and “business” disciplines, despite the growing number of roles that are impossible to clearly classify as one or the other.  In the sad but traditional approach massive enterprises take in the face of a major strategic decision, many companies are attempting a straddle-the-fence strategic position by attempting to leave their existing antiquated structure intact while building entirely new divisions modeled on the structure of successful tech companies.  This is likewise problematic – to succeed at this, revenue growth must accelerate enough to both maintain the old organization while building the new division(s) and the corporate efficiency gains of sharing administrative and brand resources means the new groups will adopt many of the dysfunctions of the old organization.  To the extent this is a Zero Sum Game played out against other competitors and multiple competitors are attempting this simultaneously, no one is likely to “win” the game.

What is the problem?

Let’s look at the first hard lesson facing companies attempting to compete against innovation-base startups and high tech for the first time.  They bring in consultants to help them break down silos, communicate cross-functionally for the first time, and establish a shared vision.  They bring together teams across various business functions, bring in agile coaches, and try to get everyone to collaborate.  They bring in vendors who seem to be better than them and try to “copy their homework” so to speak.  With enough cash, they may even implement widespread training and certification and bring in new employees who are from flat, agile, startups.

The problem that companies introduce when they do this, at any given level of the organization:  without restructuring, there is a “business” and “tech” person set together in equal standing.  If they get it down to two, that is an accidentally triumph.  It is more likely a three to four person group representing a) marketing/sales b) technical leadership c) requirements and project management d) creative design.  There is no clear empowerment for any of them, because mentoring, performance review, and promotion or disciplinary power are all linked to other pieces of the organization.

This diffusion of responsibility was the failure of waterfall in the first place!

Attempting to preserve a forced distinction between “business” and “tech” as well as the hierarchical position of leaders, then forcing “equals” into a nightmare arranged marriage on a per-project basis is a recipe for a slow but unmitigated disaster.

Taking a step back to “Core” Scrum

In software development today, virtually every high tech, innovation-based company is delivering products with some mix of agile values, Scrum ceremonies, Lean improvement efforts, and XP best practices.  While companies may call their process Agile, Scrum, Scrumban, Kanban, etc – let’s talk generically about “core” Scrum and why it succeeded where “waterfall” failed.

Our imaginary “Core” Scrum team is a small startup with a visionary leader who is a fantastic mix of technical proficiency, business acumen, and management skills.  We’ll call this person the Product Owner but in remember, this is the CEO, product manager, and sales-plus-marketing all at once.  For simplicity, everyone else in this company of about 12 is part of the software delivery team (all other roles like accounting are outsourced).  They are The Team, and one of them is the Scrum Master who keeps the process of delivery rolling smoothly, constantly challenging everyone to collaborate more.

That’s “Core” Scrum in a nutshell:  The Product Owner is roughly 50/50 split-focus between the Team and stakeholders, the Team only needs to converse with one voice of prioritization, and the Scrum Master keeps this one small group on-time, ever-learning, and un-impeded.  The CEO owns the company, its only product, and all stakeholder relationships (investors, customers, end users).  This is “pure” Product Ownership – the entrepreneur “lives and dies” by the sword of her decisions because the power, responsibility, and accountability for every promise and decision is firmly on her shoulders.

The purity achieved here is simple to understand:

the company role and its associated place in the superorganism’s Prestige Economy is perfectly aligned with the project role.

The Scrum Master manages no employees and builds culture, collaboration, and keeps the Product Owner’s relationship with The Team healthy and strong.  If this were a highly technically complex product, the ScrumMaster could be a very experienced architect who is can assist in code quality decisions, pair-programming to overcome tough coding challenges, and resolving any risks to the long-term sustainability of the code.  In an extremely technically complex engineering environment, it would make sense that this (dare I say) Architect is a thought-leader but not a people leader.  This Architect knows all of the code and is on speed dial for production issues.  The strength and trust it takes to successfully push the CEO to prioritize refactoring over new features, hardware investments versus new hires means the Scrum Master must be a right-hand-man to the CEO but have no agency dilemma or conflict of interest in making certain the CEO (Product Owner), the Team, and derivatively (via total process quality) the Product are at any given time healthy.

Naturally, we can assume a different but very valuable breed of Scrum Master is also possible.  If we imagine a software product where technical uncertainty is easily handled by an experienced team of engineers but the business rules are extremely complex, a business analyst may be the perfect Scrum Master insofar as Backlog Decomposition and the precise details of User Stories will require a business person with the Product Owner on speed dial who can resolve every business rule uncertainty.

Just like our anecdotal Product Owner, we see in each anecdotal Scrum Master, due to the nature of the product, the company role and the project role are perfectly aligned.

Scaling vs Scaled

This simple paradigm is compelling due to the clear accountability and laser-sharp focus  that makes it successful.  With the single, properly-sized team described above, it is easy to understand why it works and how emulate it.  Confusion tends to set in as the number of contributors and teams grow.

There is an important distinction to make between scaling this pattern and implementing the pattern at scale. 

Continuing our narrative about this successful “core” Scrum team, we can imagine the company grows organically as the product becomes increasingly successful.  Revenue is great, margins are fantastic, and more engineers join.  It becomes clear to the CEO (and Product Owner) that second product would be a perfect strategic fit.  The product, focused on different niche in a similar industry will leverage the skill set of the engineers, design patterns, and the libraries and APIs that have been built over time.  Stakeholders are excited, ready sign on the dotted line.  The engineers are thrilled.  As a group, they decide to split into two teams, each focused on their product.

This Scrum implementation has begun scaling.

The shared code and strong culture combined with the mature agility and engineering best practices allow the ScrumMaster to happily work with two teams.  Unfortunately, the CEO is now  splitting time roughly 20% stakeholders and 10% team on product #1 while 40% stakeholders and 30% team on product #2.  Days get longer and attention to the backlog is suffering.

The CEO is no longer effectively owning either product.

Her trusted colleague, the ScrumMaster talks through the risk of “Hero Scrum” and the need to delegate, and the risk of poor feedback or lack of actionable backlog when more engineers and another designer will be joining in the summer.  There is demand to have the APIs and an SDK consumed B2B.  The decision becomes clear – two experienced Product Owners are hired, one to manage the consumer apps Scrum Team and one to manage the B2B cloud platform. 

The CEO sees that leading the company’s strategy, defining new products, and the need to build a brand, while mentoring the Product Owners on great management of their categories and teams is her new “job role” and “project role” – it evolved organically, and the two still align perfectly. 

This is a happy company.  More products follow, and while not all of them are an instant success, the values, vision, and identity stay strong.  Camaraderie, disruptiveness, and culture of innovation keeps this company profitable at-scale, through a constant assurance that the job role and project role, whether a Jr. Developer or a Marketing Specialist, are always properly aligned.  People are asked to own “one big thing”, empowered to succeed, and held accountable.

Paternalism and Guild-based Hierarchies

If you work at a large company and this happy anecdote sounds ludicrously fictional, it is because implementing agile in a scaled environment – whether due to the success of an isolated team or a management decision to copy Silicon Valley – rarely looks like this.  Large enterprises in mature industries were born out of organization and management practices dating back to the British Empire and the industrial revolution, and function-based guild preservation that began in the Dark Ages. 

Blacksmith best practices evolved, certainly, but not so fast an entire practice community couldn’t keep up.  The capitalists in the industrial revolution could invest in a few big innovations, paternalistically demand new behavior from a new “guild”, and reap benefits for decades. 

Marketing, even as the internet bubbled, consumer product research and development despite the worldwide adoption of desktop computers, and a whole guild built around Information Technologies did not disrupt this proud history of dividing the troops into functional units held together by rules, history, and strong paternalistic leaders.

Transforming Project Roles While Preserving Job Roles

The United States Military is realizing, unit-based combat in an urban setting full of emerging demands and uncertain risk.  Cross-functional teams are being built tactically insert their blend of skills into situations that require empowerment and responsiveness.  The days of marching pikemen and flanking with cavalry are gone.

Enterprises are realizing the same is true of innovation-based product markets.  A level of guided group-think is needed to courageously build an innovative product for a still-emerging market segment.  The capacity to “lock everyone in a room” that you need, and risk market and technical uncertainty requires executive mandate and tenacious teams.  Limiting investment to two weeks of team effort at a time, fierce concentration, no politics, and freedom to experiment are essential.  This is a creative process that requires adventurousness and tenacity.  Let adults succeed and celebrate or fail and learn.  Otherwise management is simply holding back the potential of their most brilliant engineers.

To do this, one thing must happen above all else.  The job role must perfectly align with the project role.  If job descriptions align to guilds, as a talent “pool” of human “resources” to get allocated like widgets in a managerial accountant’s spreadsheet, the project – which is intrinsically finite will always suffer.  The job is linked to performance and salary. 

Predictably, people behave like a faceless number on a spreadsheet when you manage them (and pay them) that way.

The move to “agile” is in large organizations is nothing more than an attempt to move to a company that has established a culture of innovation as its sustainable competitive advantage.  The four cultural choices are simple to understand, but they inevitably fail without a strategic mandate from executive leadership, and the “blessing” to fail when overcompensation in the effort to change occurs.  As a leader, tell your people these four virtues are the key to success and back it up in your daily actions:

Collaboration Focus  Put all the right people in seats next to each other, tell them they have one goal: unlock your full potential by learning from and investing in your team as you solve tough problems.

Product Focus – A project is finite, a product is a living platform for an ongoing conversation.  Build a dialogue, tell a story, and leave a legacy.  Do you really want to control your budget and schedule, or do you want to change the world?

User Focus – The ideal information symmetry cycle:  The user Tweets a feature they want, the team codes it, knowing exactly what the Story means to the User, and the user has it in-hand within a month.  The further you alienate the producers from the consumers, the more wasteful and less innovative your organization will be.

Innovation Focus – Taking risks and learning from mistakes is mandatory.  Encourage it and live it. There is infinite content available and your well-formed team’s natural curiosity are their default state.  If they aren’t innovating, you’ve burned them and overburdened them.  Give them some slack and encourage their interests – you’ll be amazed what the unbridled human accomplishes.

Issues At-Scale:  Agency Dilemma

At scale, reorganization – not just redecorating – is going to be critical.  There will be politics to deal with.  It will take immense courage and backbone as a leader.  Middle managers will be your biggest problem until you change the seating chart and pick the right people for those seats.  Agency dilemma from the guild-based job hierarchy will ALWAYS impede the success of cross-functional teams.  Functional managers encourage non-collaborative activity.  Over-documentation.  CYA.  A lack of focus on the team and product. 

Why is this so prevalent? 

It is not simply the change management of restructuring, changing number of direct reports, flattening the organization – that is all incredibly well-known turf for large, established enterprises in mature industries.  The new political problem is two-fold and pragmatically simple:

1. Failing to have “tech” report to “business”

2. Failing to have “business” people report to “tech”

Unfortunately, the politics of putting previously separated guilds in charge one another is  not the root cause here.  You could put an abstract painter in a direct management position over a cross-functional software team so long as they had the skills to lead them to success and prestige.  Instead, it is a symptom of leadership not understanding the team-product-user relationship.  In “core” scrum described above, this was simple.  The start-up was built around it.

How you should restructure, once you “get” it, would be fairly simple: If the user has needs that are solved by a product that will need a team that must overcome technical uncertainty first and foremost – a more technical manager for that product team makes sense.  If the user has needs that are solved by a product that will need a team that must overcome market uncertainty first and foremost – a more business-savvy manager for that product team makes sense. 

In other words, when an old business problem can be solved by new technical innovation, let an engineer lead the cross-functional team.  When an old (enough) problem can be solved by technology by changing the complex business problem (think finance) – put a subject matter expert as the team manager. 

If the multiple products fit into a “category” where the users are likely to consume multiple products, scale to a director who can set strategy, build a brand, and ensure cohesion.  This person will likely be a mix of skills so significant that designating them “business” or “tech” simply makes no sense. 

Diffusion of Responsibility

This brings us full-circle back to the reason why organization restructuring needs to occur at all – multi-bossed employees are easily distracted.  Too many leaders goes hand-in-hand with sharing resources.  No one knows what any given employee is doing while no employee is terribly confident which leader to follow.  In a guild-based system, they fall back on their functional allegiances and their job description.

When you make an engineer (with experience taking new products to market) the direct manager of a cross-functional, self-contained product team that can collaboratively handle business+tech roles needed for a highly technical product – planning, design, engineering, quality, and marketing – that manager has a pulse on what everyone is doing and everyone knows who to go to when their workload gets too light.  The same is true if this manager is from a business background.  The end user is well-known, the backlog is simple to build, and the product is the professional focus of everyone in the room. 

This independence and focus is the building block of a culture of innovation.

Shared resources and functional guilds perpetuate agency dilemma, information asymmetry, and diffusion of responsibility.  Kill it by restructuring before it kills you.

Scaling Issues: Copying Enterprise Dysfunctions

To be thorough, this is not exclusively an issue faced by enterprises shifting to innovation and high-tech at-scale.  Growing from a startup to a mid-size company and beyond means personnel growth and collective skill-set via true talent acquisition.  However successful a small company was at innovation through collaborative, cross-functional problem-solving, pulling in new people is incredibly dangerous.  The temptation is fill in the top and middle with highly experienced managers and individual contributors.  Enough new hires with more than a few years experience inevitably bring with them the “baggage” of their guild-based past and the political self-protection of the toxic culture they left behind. 

If you are currently scaling, learn from the issues facing scaled transformation and protect your culture, mission, and values from the threat of new and toxic influences.  Grow teams into categories, categories into industries.  Agency dilemma, information asymmetry, and diffusion of responsibility are the inevitable dysfunctions of a company that loses its sense of identity by growing too fast through acquisitions. 

First of all, grow from your bench.  Being a small company is no excuse for constantly showing employees they will never progress in their career by hiring knowledge and leadership from the outside.  Second, when a subject matter expert can only be acquired, it makes no sense to put them in a leadership position as well – they need to spend their time educating the organization. 

To succeed in scaling a small culture of innovation, keeping every person at every level fully focused on their end user, their team, and their product is the only path. 

5 Reasons I Would Fire You

Originally posted April 2016. 

Disclaimer: I currently work solo on this blog and could only fire myself – so this isn’t veiled threat.  I have done my best to mentor individuals and lead teams aways from these dysfunctions; and disrupt processes that perpetuate them.  These are also part of my personal introspection process.  This is not an accusation of anyone  in particular.  Instead, these are traits we can all continuously work to improve.  On the other hand – “You’re so vain, I bet you think this song is about you.”  

The Top 5 Reasons I Would Fire You

Tech professionals on teams trying to innovate:  Speaking on behalf of managers, your peers, and individual contributors everywhere, these are the top five reasons you aren’t just a poor performer, you’re bringing down the people around you as well.


Reason #1 – You Default to One-Way Communication

Collaborative problem solving cannot happen without meaningful and timely feedback.  There is a time for group chat and a time for well-argued prose (email).  To avoid death-by-chat and long CYA email chains, you need to set clear expectations about when you need to focus and when you can discuss issues – and respect that prerogative in others. 

Whining about documentation, instructions, or a process as document brings you no closer to a better workplace experience for yourself, improved team health, or a product you can feel a lasting pride, prestige, or sense of legacy about.  Bring a solution to the table, own your responsibility for following up, and escalate to a scheduled meeting if needed.  Folding your arms and leaving work unfinished is childish.  You know you can do better – do it.

Mantra – There are no documentation problems, only communication problems.


Reason #2 – You Repeat the Same Words When I Say I Don’t Understand 

Speaking of childish, self-advocacy is an important milestone.  It requires enough vocabulary, understanding of abstract concepts, and recognition of similarities and differences to allow a child to not only imagine a future state that is desirable, but also solve the most likely path to attain it, and make a rational statement to an adult who can permit, empower, or provide.  My three-year-old daughter, forgivably, needs an enormous amount of assistance, and patience, when she attempt this.  As an adult, you should not.

As a leader, I will do my best to bridge the gap between your words and my words.  I will cue you when I am unable to build that bridge, repeat back to you what I understood you to say, and ask you to demonstrate or show me where and what you mean so that I have the context I need for a deliberate and logical decision.  I will do all of this without patronizing you, even when it is mentally exhausting for me.

Not everyone has learned to lead this way, and I admit I can be imperfect at it as well, so you absolutely need to learn to self-advocate.

That said, I cannot heroically be an adult on your behalf.  The real dysfunction that brings down team performance through your own sub-par performance is the continued repetition of the same words when I (or others) explicitly ask you to re-word the request, argument, or question.  You are obstinately anti-try-something-else.  You refuse to paraphrase, assist my incorrect understanding, or demonstrate the meaning of your words.  It is only through my strong personality and insistence that I convince you to show me exactly what the problem is so that I solve it rather than answering a question that sounds like utter nonsense out of context.  Unfortunately, even that is not always effective.  I can carry my pre-school daughter to the cabinet and let her pick the exact afternoon snack she wants.  I cannot “carry” you as an engineer into a realm of creative solutions where emerging technology and emerging market segments meet.

Mantra – Communication is the responsibility of the communicator.


Reason #3 – You Feel No Pride of Ownership Over Your Work

Having coached, worked with, or heard the complaints of hundreds of tech-focused professionals in various, I have found this can often be more a symptom of the dysfunction of an organization than the root cause of poor performance.  The tech industry today is too mentally demanding and excitingly disruptive to attract genuinely lazy people, looking for a free ride.  So when you start giving into distraction, procrastination, or laziness, my leadership spidey-sense goes off.  I will tell you the secret to motivating innovation-based technical teams – empower them to know the impact a line of code will have on an end user. 

Karl Marx’ philosophy describes this exact phenomenon in its examination of the individual worker’s separation and alienation from the product.  Superficially, the question seems quite simple:  Which is more rewarding, a carpenter who makes custom-installed wooden shutters, getting to know the customer, their home, and tastes in the process, or working in a factory running a machine that produces millions of shutters for a big-box store’s generic one-size-fits-all product line?

If you have lost pride of ownership over your work as a software professional, though, shame on you.  You have no excuse for complacence, apathy, or becoming disengaged.  Your skills are a premium product in a seller’s market.  Companies of every size will fight to win you to their side. With one idea and a few colleagues, you could start a company of your own in a heartbeat.

Now, let’s be adults here.  We all have to collaborate and negotiate.  When the majority or a manager makes a call that goes against your individual dissenting opinion, don’t stomp away and pout.  Losing pride of ownership over work, and settling into a free-rider paradigm brings down the team, the product, the end user, and your career.  You better woman-up or man-up and either do a great job that you can be proud of, work to change the organization that is stifling you and your peers, or move on.

Change takes courage, but our virtue is the outcome of our habits.  When you accept and justify your childish, dysfunctional, lazy, sub-par effort and excusing yourself through an external locus of control hurts no one more than you.

Mantra – Anything worth doing is worth doing well.


Reason #4 – You Hide Behind Uncertainty

Deconstructionism is a dangerous game, especially when you are part of a team that is teetering on the edge of a cliff overlooking the seas of chaos, moments from falling into market risk or technical risk that could engulf you.  Since I coach teams on how to become a room full of adults solving the pains of a real person through a collaborative, unified, inspired collective brilliance and sheer power of will, I have a radar for someone  who is hiding. 

You are playing a dangerous game.  You signed up for this, after all.  You wanted to be brilliant, in the thick of it, defining emergent market segments using emerging technologies – but the minute you lost faith in the cause, lost hope for your job security, or lost belief in yourself as a builder and creator of new tech that can change the user’s world… that was the moment the inherent uncertainty of our goals became apparent.  You shut down.  You got stuck.  You became intolerant of technical risk AND market risk and looked to your leaders to spoon-feed you.

At first, a good leader can give a big speech, host a team-building event, or roll up the proverbial sleeves to help.  When the team as a whole needs some slack but they still have their eye on the prize, I have a long list of tools and tricks to re-energize the whole team.  When an individual begins the process of deconstructionism, and moves every conversation into an infinite regress in which the certainty of any word or any intention or any risk is now more important than the product discovery process, that’s when a tough love heart-to-heart happens.  Agile demands small increments.  Innovation requires trial and error.  You must remain infinitely curious.  You must self-advocate for the size of the risks you take.  Escalate when time-to-feedback is hurting you.  Sturdy yourself and your tenacious attitude about the “failure” intrinsic to empirical discovery – otherwise you don’t belong in this work space.

Mantra – Fail fast to succeed sooner.


Reason #5 – You Give Up Before Attempting to Solve a Problem 

This issue if often comes hand-in-hand with insecurity toward uncertainty.  When it comes to coaching a product visionary in agile, this means whipping them with the importance of setting goals for the product, an end user to empathize with, and a pain to solve in the target user’s particular context.  Once that is in place, a team – as a whole – may need some encouragement that a 100% success rate is not the goal.  Innovative, defect-free software that fits the user’s needs is the goal.  As it turns out, some people fear failure too much to risk it.  If that’s you, make sure you are in the least innovative technical space possible.  Sink your teeth into a legacy system and never complain about the spaghetti code you manage again.  That slow-moving space is perfect if you prefer to play it safe.

Innovation may not be important to SOME people, but it is VERY important to the REST of US.  The courage to risk failure is essential to experimentation. 

The real issue, of course, is not the fear or the failure.  It is a lack of proper perspective that puts your short-term ego ahead of long-term viability.  It is a base rate logical fallacy in which you are ignoring the most important variables.  Pretend for a moment that we have a product for which any given User Story – which we’ll restrict to less than two weeks of effort to get from planning to production – has a 70% chance of success (completion in two weeks) due to technical uncertainty and 20% chance of success due to market uncertainty (i.e. “is it really what the end users need?”).  If you take the risk of a false-positive – succeeding in releasing a working product increment that the market doesn’t demand – as the only indication of your own failure, you are sure to be unhappy. 

Now, imagine a breathalyzer has a 5% probability of a false-positive.  A police officer pulls over drivers truly at random at a random time of day.  What is the probability that a driver who tests positive is actually drunk?  Guess what!  A dreadful 2% chance.  Luckily, officers are trained not to play the odds like that.  The time of day, the day of the week, the location selected, and driving behavior all weed out the risk of a truly random selection.  Then recognition of symptoms, through human interaction must give probably cause. 

When you stop trying to overcome technical risk or market uncertainty prior to even attempt to solve a problem, you’re like a cop who stops pulling over anyone due to the statistical uncertainty of a false positive.  If you attempt to solve 0% of the problems you face, you’ll come away with a 100% lack of solved problems. 

Tackle 100% of the tough challenges tenaciously, courageously, and look for an assist as needed.  Anything else makes success incredibly unlikely.  The market risk of success is hard enough.  Don’t ruin the odds further by quitting in the face of technical risk.

Mantra – You miss 100% of the shots you don’t take.


Grow Up or Move On

If these sound like you, work to grow as an individual or you are likely already on your way out the door.  If you, your peers, and even your manager exhibit these traits and the organization seems unlikely to change despite a heroic group effort – it’s time to move on.  Complacence, apathy, and passive aggression is terrible for your career.

I’ve taken to saying, “Some people just want to watch the world burn – the rest of us build it anyway.”  If you aren’t a builder, at least stop burning down what the rest of us will happily accomplish with you.

Measuring What Matters to Innovation

Competing on Innovation

The rate of technological innovation and adoption has accelerated to a level that would have been impossible to imagine centuries ago. As such, an amazing number of startups have been able to succeed from strategic position based on niche-market differentiation and a culture of passionate innovators.

Established – and well-funded – large enterprises have taken note. Adoption, disruption, and even disappointment and abandonment of products are forcing every company to tackle what cloud computing, mobile, and IoT mean for their categories.

Every company is trying to become innovative, because we are all competing based on technological innovation.

Unfortunately, building a sustainable competitive advantage around culture of innovation is far more complex than previous strategic positioning was. Nash equilibriums a few decades ago could be easily resolved with a few long-term commitments that ensured indirect competition and margins for all major players. Innovation could actually be stifled – purposefully – by industry oligarchs to minimize the risk of new entrants. The rate of innovation today has made this control impossible, to the benefit of the consumer.

However, building a culture of innovation requires an entire new way to structure the organization and reinforce its behaviors. This is made even more challenging by the abundance of data available that was inaccessible before. Measuring metrics is the formalization of what decisions are worthy of notice. Thus, to understand what to measure, a leader must know not only how to measure a metric but also why the metric matters to the achievement of long-term goals.

To explore this, I’ve been discussing the connection between individual motivation and the company’s goals as a Minimum Viable Superorganism:

‘Selfish individuals pursuing shared goals (arising from shared underlying incentives), held together by a Prestige Economy which consists of two activities: (1) seeking status by attempting to advance the superorganism’s goals, and (2) celebrating (i.e., sucking up to) those who deserve it.’

The executive and visionary of the company must be the purposeful “mind” leading the activity of the superorganism. The relationship between employee motivation and company outcomes rely on this Prestige Economy, so leading a company means guiding this economy.

Naturally, it easiest for me to discuss this in terms of scaling agile or scrum, or technological innovation in start-ups versus large established enterprises. Discussing each, if you are hoping for very specific metrics for you company, will take the rest of my life so I will leave those conversations to a per-company basis. However, the fundamental issue confusing the connection between innovative teams and enterprise-level accounting metrics is the virtually insane forgetting of what has truly changed in our new and rapidly accelerating tech-adoptive society.


 

Market Risk vs Technical Risk

If you recall the example of the terrible metric (for innovation-based companies) “allocable resource utilization” we saw the well-established, consistent distribution – i.e. strategic trade-off – between utilization and responsiveness.

If you imagine one very capable engineer you’ll find:

  • Demands arrive to the employee at a variable rate.
  • Work is accomplished at a variable rate.
  • There is one worker.
  • The possible queue of demands is potentially infinite.

This type of queue is an M/M/1/ ∞ queue.

Whether the “1” here is a server, an interstate, a mobile developer, or a 1990’s movie hacker’s CPU, increased utilization of total potential results in rapidly-accelerating diminished returns as utilization reaches 100%. Likewise, you can occasionally “overclock” with appropriate support and recovery, but constant over-use results in chronically poor responsiveness to demands, a pile up of unmet requests, and finally, a CRASH.

HOWEVER, competing on innovation requires additional variables for our M/M/1/ ∞ queue because it treats “requests” as a discrete abstract entity. It accounts for the possibility, because it is a Poisson distribution, of requests not being the same size or difficulty – technical risk – by stating that work is accomplished at a variable rate.

What the M/M/1/ ∞ queue fails to account for is whether or not the request was the correct request. In the case of a server handling API requests, we could assume the incorrect initial request probability is zero if we believe retrieving unwanted data is the failure intuitive front end or simply user error (the API and the server is not the guilty party). If we are imagining a highway over an extended period of time, drivers who intended to take a different route and got on the highway by mistake are virtually an outlier, and an even less noticeable percentage behave in a way that would impact the flow of traffic.

In technological innovation and the development of any given software product, the risk that the request was the correct request at the time it was made and still the correct request by the time it has been fulfilled is EXTREMELY HIGH. The variable that prioritizes responsiveness over utilization in technological innovation is Market Risk.

After all, when we say “competing on innovation” what we really mean is “responding the fastest to disruptive market shifts while also creating market disruption or new demand and adapting quickly enough to capture value profitably”.

We don’t say the latter, of course, because it isn’t as sexy.

The reality is that a culture of innovation requires a few things that run counter to the leadership methods of old school consulting or manufacturing organizations. Don’t go on a request for quantifiable metrics on these, but an innovation culture requires things like:

  • Excess allocable brilliance
  • Willingness and aptitude for adaptation
  • Vigilant feedback-seeking
  • Permanent restlessness

The greatest risk of any innovation-based company is not the technical risk of learning to implement what was promised or the project risk of time-to-market or delayed advertising campaigns. The primary risk when competing on innovation is the market risk that, for any new product:

  1. The market knew what to demand
  2. Supply correctly met that demand
  3. The product still met a need by the time it went to market

In the App Store alone there are thousands of new apps per day. The market risk not only for a software product in this one market is unprecedentedly high, likewise shifting immense market risk to every feature added and every update released to your company’s increasingly less loyal consumer base. That is why Scrum works sprint-based, with increments that should always require less than a single sprint (2 weeks, ideally) of development team effort – not to mitigate project or technical risk, to mitigate the market risk that the end users or stakeholder knew what they actually wanted, knew the impact on the overall product, properly communicated it, and still want it by the time it is delivered.


 

Fail Faster to Succeed Sooner

We can see that when competing on a culture of innovation, receptiveness and relevance are the necessary compliments to responsiveness. This is the most important way in which agile delivers higher-quality software. Code quality, user testing, and market fit are all checked as often as possible. A great Scrum team fixes cosmetic, logic, and intuitive experience problems as they go, looks for feedback immediately about the demand for the feature, then enhances each tiny increment of the product prior to each release. In agile we call this “failing fast” so that we can assure we succeed sooner. The tight feedback loop means creating the right thing very well, based on the newest information available.

Time-to-irrelevance is the greatest risk to every innovation-based project. Not only the market risk of irrelevance, but also the loss of relevant context – both code and product vision – when ensuring the quality of the software and resolving defects or maximizing the return on a feature by improving it before moving on to the next feature.


 

 

Metrics that Matter

If we are driving a superorganism comprised of teams that are focused on product innovation – not only in software – we can see there plenty of metrics that will reinforce a Prestige Economy built for succeeding in innovation. I’ve described a handful below. One last note of caution here while these metrics are powerful and valuable, it will still be essential to clearly express who is accountable for each metric and empower that person or team so that they are in control of that metric. These are also defined rather philosophically. If you have a documented Work In Process flow to share, I can give you specifics.

Measurement Goal #1 – Receptiveness

Feedback-to-Answer cycle time – the total process time from the market making a demand to the market receiving an indication of response. In classic “core” Scrum, this may simply be the time from a customer making a request to the Product Owner telling that customer a valid expected release date. In a large-scale environment, this may be the time from a Tweet received by Marketing to the time Marketing announces the planned features in a new update that contains the feature requested on Twitter. To the extent your large enterprise is attempting to compete with small startups, this is the crux of your challenge. An entrepreneur leading a small team only needs manage her or his reputation for accuracy of promises and find a reliable way to ensure that single-mind heroic vision for the product becomes a reality. The cycle time from neuron to neuron is infinitesimally smaller than any scaled cycle time that includes multiple business units, functional teams, vendors, and a PMO.

The Feedback-to-Answer cycle can also be measured at the Work-In-Process level – when a card in a latter step is kicked back to an earlier step, how long does it take for that feedback to receive an answer? If it takes a long time and there is very little work-in-progress, this is a sign that receptiveness is poor. Maybe the Scrum board isn’t visible enough or the daily stand up is not as effective as it should be. On the other hand, if there is a huge amount of work-in-progress, capacity is over-utilized and responsiveness is suffering – setting WIP limits may be necessary (even if only for a short experimental period).

Feedback-to-Answer Quality – This is likely to be a qualitative measurement if used ongoing, and is likely a tertiary metric looked at only occasionally. The most relevant use for this metric is electronically documented support tickets that receive a rating by the requestor after it is closed. The problem with qualitative responses, of course is the possibility that only the most positive or most negative reviewers to surface. This makes this a poor metric for individual or team performance but should summarized more broadly for an indication of the process. Don’t set a target, just learn from the insights.

Supply-to-Demand Receptiveness – From a buzzword standpoint, this is your “Social Listening” as an organization, both internally and externally. From the time you meet a demand, how long does it take to discover that you met the right demand? How long does it take to know if you met the right demand correctly? For software, don’t leave this purely in the hands of social network listening – build into your software trailing indicators like usage analytics, product-wide ratings, and (sometimes) per-feature ratings and feedback soliciting.

In a large-scale product environment, pay attention to listening from all sources. A few new “ceremonies” are going to be needed to encourage collaboration from Epic Owners, program/division-level alignment of a shared backlog across products, and Stakeholder Gathering to solicit additional feedback.

Receptiveness is the precursor to responsiveness. If you aren’t “listening” to your market, you will never respond to demands correctly.

 

Measurement Goal #2 – Responsiveness

Demand-to-Supply cycle time – This is the traditional definition of cycle time and the best metric that carries over from Lean Manufacturing to Lean Startup principles. From the moment a market demand is made, assuming receptiveness is held constant, what is the total process time until supply can meet that demand. Anecdotally, the highest performance with this metric in a Scrum team I led as Product Owner was on a large enterprise tool. We released to stakeholders twice a week and released to production weekly. A feedback feature was created that gave the users direct input into our product backlog. We were able to respond to improvement requests made on Monday in a fully-tested Production Release that Wednesday. Statistically, these wonderfully short feedback cycles were outliers and relied on circumstances more than team performance. I share that anecdote as challenge to whatever complacence you may have about That said, if average Demand-to-Supply cycle time is greater than 90 days I would challenge you to consider if you are really “listening”.

Demand-to-Supply lead time – This is the traditional definition of lead time and is the time from initiation to completion of a production process. In classic Scrum, that’s the time from commitment at Sprint Planning to the time it is called Potentially Shippable by the Product Owner. This is a once-in-awhile metric that should be checked as an indication of whether teams are sizing stories and committing properly.   Whether a team is new or old, they will need extra reinforcement from a manager when average lead time is consistently greater than the sprint length. This is a sign of over-commitment and sprint carry-over. Too much WIP, over-utilization, and poor story sizing will leave a team hamstrung. Quality will suffer, context-switching will breed deceleration of velocity, and burn out will occur. This is at the heart of Little’s Law. When lead time is consistently greater than sprint length, this isn’t a performance metric to track – it’s a trailing indication that management needs to set clear expectations around the trade-off between velocity and quality (including market fit). Set WIP limits and enforce true swarming activities. Because WIP is a leading indicator for Lead Time, reducing WIP should lower lead time back below sprint length.

There is an important call-out here. While experienced Scrum teams know all too well the relationship between team WIP and Lead Time – this only covers the process states for that team. In a scaled implementation, where the stakeholders have an internal proxy voice (imagine a product division large enough to include a Social Listening Analyst on the marketing team) WIP limits at the Epic, Feature, Theme/Campaign, and Product may be necessary. Putting too many items on the Work In Process flow of the Product Marketing Managers that must A) Add Epics to the Product Backlogs and B) Give feedback that the right thing was built and properly fits market demand will create terrible inefficiency in the overall innovative delivery process. The same is true when new Business Development or long-term relationship-owning Account Managers are part of the input and output. No amount efficiency gained by the teams building the products will EVER MATTER without tightening the every other feedback cycle. Restrict stakeholder WIP to ensure they pay attention, provide meaningful feedback, and properly communicate new features and gather end user and customer feedback of their own. If average lead time per story is 7 business days but it takes an entire quarter for a minor enhancement worth millions in revenue to “circle back” through the organization to the development team – YOU WILL LOSE. Pack your bags, a startup is about become a category killer.

 

Measurement Goal #3 -Relevance

Cycle-Time Feedback conversion – when an end user or stakeholder makes a request, the WIP cycle ought to have a traceable “funnel” for requests making it through to market. This is not a performance metric but a continuous improvement metric. If a product is in its infancy and market share growth is on the rise, but product innovation is stagnant, ask for more requests to go through. If a product is mature and market share accumulation has plateaued, but the conversion rate is extremely high – the process may be building for the sake of staying busy and a new product should be innovated.

Lead-time Feedback Quality – This is another qualitative metric that may be useful in a 360 review process. From the time a team starts working on a product increment to the time it is delivered, each time an opportunity for feedback occurs, what is the relevance and value of the feedback that is given? Putting metrics around this can be very valuable for a short period of time if approval processes and quality assurance are failing. If it is right for your scaled environment and will not cause unnecessary inefficiencies, this can even be formalized and automatically enforced (e.g. make a Resolution Type and Comment Field mandatory when the Product Owner moves a Story card to Closed, with the expectation that the quality of the feedback will be a topic of review by a manager for purposes of mentoring and career development). At scale, think very hard about the inefficiency this may create and its fairness across the organization prior to roll out.


Conclusion

These are a handful of metrics that actually matter for innovation and success. For specifics that apply to your organization, feel free to reach out to me for free advice anytime at andrewthomaskeenermba@gmail.com or Tweet me @keenerstrategy

This is part of a series!

Part 1 – Metrics: The Good, The Bad, and The Ugly

Part 2 – How to Fail at Performance Metrics

Part 3 – Rules For Measuring Success

Part 4 – Measuring What Matters to Innovation

Throughout the series I tie together ideas from two great resources:

Kevin Simler’s Minimum Viable Superorganism

Steven Borg’s From Vanity to Value, Metrics That Matter: Improving Lean and Agile, Kanban, and Scrum

Rules For Measuring Success

Corporations as Superorganisms

Like metrics for products, the meaningfulness of each number should directly relate either to the “one number” that truly matters, or indirectly but transparently tie to easy-to-prove related, secondary, or proxy metrics – especially to the individuals being tracked!

To understand the rules I’ll lay out for determining metrics that can bridge the gap between individuals, software teams, business divisions, and corporate goals, I will lean heavily on the concept of the Minimum Viable Superorganism described by Kevin Simler because, to understand what to measure, a leader must know not only how to measure a metric but also why the metric matters to the achievement of long-term goals.

“Here’s our recipe for a minimum viable superorganism: ‘Selfish individuals pursuing shared goals (arising from shared underlying incentives), held together by a Prestige Economy which consists of two activities: (1) seeking status by attempting to advance the superorganism’s goals, and (2) celebrating (i.e., sucking up to) those who deserve it.’

The executive and visionary of the company must be the purposeful “mind” leading the activity of the superorganism. The rules for the relationship between employee motivation and company outcomes rely on this Prestige Economy, so leading a company means guiding this economy.

“Effective leadership is not about making speeches or being liked; leadership is defined by results not attributes.” —Peter Drucker


 

Prestige Economics

So what can be tracked that scales meaningfully from the individual contributor to a multi-division organization? How can motivate great performance across a company with GOOD metrics that encourage correct behaviors for serving the goals of the superorganism? First, we need to look at the Prestige Economics motivating employees in a specific company:

In exchange for doing work that advances the company’s goals, employees are granted social status, most of it in the form of money. But some compensation also takes the form of good old-fashioned prestige, i.e., the esteem of coworkers (often reified in fancy titles or corner offices). Either way, employees are rewarded for helping the company, regardless of whether it ultimately succeeds or fails in achieving its goals.

It is easy to see why metrics are so powerful and dangerous – if executive leadership tracks a number, employees anticipate that managers will use that number in the Prestige Economy. Praise, bonuses, perks, salary increases, and training or conference allowances are all – implicitly or explicitly – impacted by the individual’s contribution to the metric. So when company-wide stock options or bonuses are provided based quarterly revenue goals, this increases cohesion. Everyone is knows they have a reward for the success of the group. Obviously there a few caveats to the success of this metric – if an employee cannot clearly articulate the impact they have on company revenue, or they accurately believe they are not positioned or empowered to control their impact, the metric is unlikely to work.

Now imagine what happens when executives begin tracking a performance metric that is counter to best demonstrated practices. Employees will watch closely for changes in praise from colleagues and supervisors, and judge that cohesion as an indication of that metric’s impact on her or his long-term status, prestige, and rewards.

With the Prestige Economy in mind, let’s look at rules for “Good” metrics – the numbers that, when tracked, provide leaders the insights they need while also positively reinforcing behaviors that culminate in the achievement of company goals.


 

Rule #1 – Reinforce the discovery process, not the processes that are discovered.

Although many team-level empirical process metrics are a natural part of agile software development and the team’s collective desire for continuous self-improvement, scaling any of these metrics to the enterprise restricts team-level experimentation!  As an example, a newly-formed Scrum team may find their velocity will double or triple over the next 6 months as they remove impediments and learn to work in smaller increments.  Tracking velocity is an exciting indication of finding their “flow” as a team. However, comparison of story points per sprint across individuals and across teams in an organization will fail miserably. It is a good team metric as a short-term trailing measurement for experiments; it is an ugly metric for executives to track due to Hawthorne Effect. Velocity is relative to team maturity, product lifecycle stage, certainty of technical environment, and predictability of market demand.  A team consistently driving bleeding-edge innovation will frequently disrupt and re-calibrate team velocity and commitment. Velocity is an occasionally valuable metric to the team only to the extent it validates a hypothesis.

Imagine if an organization standardized a target for two metrics – 1) hours per story point  2) story points per sprint – and set these a benchmark for each in order to review employee performance.  These two team-level measurements may have been handy, after all. Perhaps a process change was at point justified based on its impact on them. In their excitement, they assume setting a target per individual, team, business line, and for the enterprise is a fantastic control for productivity.

Instead, terrible things happen. Setting these targets focus energy away from the strategic goal of rapid innovation:

  • Individuals have a target to meet rather than a team having the freedom to experiment
  • Teams pursue risk avoidance (don’t endanger burn rate) rather than risk recovery (grow to be a team that easily adapts to disruptive innovation)
  • Business managers encourage fail-safe processes over safe-to-fail processes (variance is now a sign of poor management and performance)

Thus, what was once a handy measurement is now the death of continuous improvement, innovation, and the competitive advantage the company hoped to standardize!

This is known as Goodhart’s Law:

When a measure becomes a target, it ceases to be a good measure.

– via University of Cambridge

Professor Charles Goodhart FBA postulated this economic law while Chief Adviser to the Bank of England, analyzing the government regulation of instruments that are also critical to the measurement of economic trends:

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.

As soon as the government attempts to regulate any particular set of financial assets, these become unreliable as indicators of economic trends [because] financial institutions can […] easily devise new types of financial assets.

– via University of Cambridge

The same phenomenon is true for performance metrics in innovative software development – the moment a target is set for a measurement, the culture of innovation will either collapse (innovation energy is suppressed) or a new practice will emerge that circumvents and actively undermines the measurement (innovation energy is misdirected).

This is once again the key difference between statistical process control and empirical process control. In a childhood chemistry experiment, the children may mix varying quantities of vinegar and baking soda and measure the amount of salt that results. All three are measureable and are variables important to the discovery process. If the teacher gave grades based on variance around a desired amount of salt, it would focus the experiment on finding that quantity rather than learning about the variety of possible outcomes. Consistency of outcomes is detrimental to innovation and learning about anything other than ensuring consistency.

Rule #2 – Metrics must reinforce respect for individuals

For innovation to occur at scale, process metrics must reinforce the empirical processes that encourage organizational learning to continue.  From the Kantian perspective: Ugly metrics communicate a Subject-Object relationship and by communicating that each person is a means to an end, that person now expends energy to overcome her or his feeling of objectification. After all, a Prestige Economy requires a level of sovereignty per person.   Prestige is only attainable by two rationally self-interested individuals that respect the recognition and prestige earned from one another. By undermining this, any ugly metric wastes the combined energy of the superorganism. Bad metrics maintain the Subject-Subject relationship, so that a Prestige Economy is able to grow but reinforce the incorrect behaviors.  Good metrics maintain the Subject-Subject respect while reinforcing the behaviors that maintain this respect.

This is the fundamental problem when an organization suffers from Johnson’s “Confusion of Levels” –

“Confusion of Levels” – failure to see that whereas in a mechanical system one-dimensional quantities can both describe results and enable one to control the linear process that produces those results, in a living system quantities can only describe results, but cannot explain or enable one to control the multi-dimensional interactions and feedback loops of the process that produces the results.  – H. T. Johnson, “Lean Dilemma”

In companies competing via their culture of innovation, this means leadership must carefully ensure the correct emphasis for the goals of the superorganism for each of the five basic phases of any process as defined by Steven Borg:

  1. Queue – Understand what to do
  2. Setup – Get the necessary “resources” ready
  3. Run – Complete the goal
  4. Wait – Look for feedback on success/failure
  5. Move – Find the next goal to accomplish

The inherent flaw of most productivity metrics, and the incredible inefficiency of the productivity-focused superorganism, is over-emphasis on the “running” state of each individual. All additional energy expended in a system or process on the “run” state of each respective functional discipline is a source of waste – a true “confusion of levels” – because the value of the outcomes of a cross-functional, superorganism-based, has more to do with the efficiency and effectiveness of the product as each increment flows through the other four process states.

A good metric must reinforce the superorganism’s Prestige Economy around the most effective and best focused coordination of the five process states by individual functions that are inherently in different states as work moves through the queue. The ugliest metrics in software development creates competition around the functions that take a product increment through the process – performance metrics that maximize each function’s run state rather than the outcome of the cross-functional team.

Here are a few terrible metrics. If you track them now, stop immediately:

  • Lines of code written (as a judge of a developer)
  • Individual burn rate (as a judge of a developer)
  • Bug cards created (as a judge of a tester)
  • Percentage of cards rejected by a tester
  • Hours per story point (as a judge of estimation accuracy)

You can see that any energy expended improving any of these individual “performance” metrics removes energy from collaborating on creation of the best possible software.

Rule #3 – Build Superorganism Identity

The problem of undermining the creative, cross-functional, creative process extend beyond tracking performance metrics that produce inefficiency. Performance metrics, after all, are powerful precisely to the extent they are a leading indicator of status in the superorganism Prestige Economy. If employees see there is no relationship between a performance metric and their salary, position, perks, respect amongst peers, or recognition from management, that metric has no power. Time spent tracking it, evaluating it, and discussing it is all unnecessary waste in the process, of course, but the real danger for executive leadership is that metrics like this erode the power of metrics to redirect the superorganism. On the other hand, the more a performance metric (for better or worse) is formally tied to the Prestige Economy – via awards, bonuses, salary increases, promotions, corner offices, better parking, flying first class, etc – the more powerful (and potentially dangerous) that metric becomes.

It is critical to the viability of the company that executive leadership envision and purposefully craft a Prestige Economy that reinforces the identity of the superorganism and its ability to achieve its strategic vision.  Obviously, the overarching goal of viability is insufficient to ensure its viability! The individuals of a company are part of multiple superorganisms they contribute at any time – a citizen of their national government, a member of a professional guild, part of a social or cultural movement – so viability for each company must contend with the fact that its Prestige Economy could at any time be at odds with multiple other Prestige Economies. The more the individual employee sees a cohesive fit across each superorganism to which they contribute, the better energized, empowered, or inspired they are to pursue a goal that will simultaneously give them additional prestige across their multiple superorganisms.

However, the moment your company’s goals and Prestige Economy are at odds with an employee’s power to earn prestige in their other superorganisms, they will find a new company that ensures better fit and maximizes their capacity for aggregate prestige. For instance, when the company goals for a Six Sigma Black Belt at a manufacturing company or a Scrum Master at a software company have great “fit” with the prestige available from their certifying body or community of practice – each is likely to work that much harder. If the Prestige Economy of their superorganism becomes sufficiently detrimental to the Prestige Economy of their professional guild, their long-term career may be jeopardized. Dropout is a natural outcome.

To that extent, insofar as a performance metric is a formal measurement of variables in a company’s “Prestige Engine”, it is critical that they reinforce the superorganism identity that ensures its viability.

This is the reason why so many companies have adopted not only a vision statement but also a set of values or principles to which every individual – and the company as a superorganism – ought to aspire. These create the “rules of thumb” that let each employee know how long-term strategy should be applied to trade-offs in the day-to-day hard decisions each employee must make. If the values are not properly expressed or inconsistently praised in the Prestige Economy, cohesion will fail and strategic positioning will be incomplete.

We have a clear first step in establishing good metrics: they are quantifiable indications of whether or not a company’s Prestige Economy will reward a behavior that contributes to the identity (values) and direction (strategy) of the superorganism. Put another way; if your accounting KPIs don’t align to your company vision while your employee performance metrics don’t align to your company values you will never accomplish your goals. To succeed, what you measure must align to what you want.

“Managers who don’t know how to measure what they want settle for wanting what they can measure.” – Russell Ackoff

Rule #4 – Reinforce Superorganism Intent

In a small “flat” organization, positive reinforcement and the mutually self-reinforcing Prestige Economy can emerge fairly organically. The visionary of the organization can build a Prestige Economy through attention, praise, and charisma on a one-on-one basis with employees. To the extent the “flat” structure of the organization grew out of a general equality of its members, position, perks, and salaries at this stage can be safely held equal as they grow, leaving public recognition of contribution and aptitude as the “premium currency” of the Prestige Economy.

As a company scales, the capacity of a single leader to personally create, manage, and re-direct the necessary Prestige Economy becomes unimaginable. The recognition and praise of the leader becomes less important the respect of peers because the merits of behaviors – through lack of exposure – seem painfully de-contextualized and thereby de-valued. Likewise, a growing number of employees inevitably necessitates a formalization of an emerging pecking order as experience, tenure, and aptitude all become simpler to segment.

We should note that at a certain size, the primary executive is no longer able to meaningfully reward daily prestige directly to employees without undermining Prestige Economy. The feeling will prevail that the chief executive is showing favoritism or simply rewarding haphazardly. Once that happens, without the company visionary guiding a formalization of the Prestige Economy, the superorganism will dismantle, as agency dilemma pushes individuals to preserve their value outside of the values of the superorganism.

 

This is part of a series!

Part 1 – Metrics: The Good, The Bad, and The Ugly

Part 2 – How to Fail at Performance Metrics

Part 3 – Rules For Measuring Success

Part 4 – Measuring What Matters to Innovation

Throughout the series I tie together ideas from two great resources:

Kevin Simler’s Minimum Viable Superorganism

Steven Borg’s From Vanity to Value, Metrics That Matter: Improving Lean and Agile, Kanban, and Scrum

Metrics: The Good, The Bad, and The Ugly

Metrics and the Superorganism

“A foolish consistency is the hobgoblin of the small-minded.”

– Ralph Waldo Emerson

Metrics are frequently the greatest challenge managers and executives face. The vast majority of companies are so bad at defining metrics below the highest possible level (e.g. standard accounting KPIs) that they would be better off with no metrics at all.

The worst possible approach to performance metrics is constantly changing them. However, when executives lose their sense of company “proprioception” they look for easy to digest numbers they can be provided as a substitute for regaining an understanding of the organization.

“Managers who don’t know how to measure what they want settle for wanting what they can measure.” – Russell Ackoff

In my next few posts I’ll build off the idea that metrics can be the mental “cue” that compliments the proprioception of the executives of a superorganism (the company). In weightlifting, maximizing force and controlling process function often requires “cues” – proprioception is a complex system to interpret and control and the Central Nervous System doesn’t take direct orders from the lifter’s mind. On the squat this means a coach may say “Back on the heels!” or “Screw your feet into the floor.”

Metrics are just like this when used correctly. Naturally, my focus will be on agile software development in an environment with scaling issues – but the relationship between employee motivation and company outcomes holds true across every for-profit superorganism.


 

Process Control Methods

Six Sigma is a Statistical Process Control methodology. Using a Statistical Process Control methodology is perfect when the process environment is stable and the goal is static and repeatable and known before the opportunity occurs.  As a rule of thumb, if planning is done up-front and the same product is built repeatedly, statistical process control will have meaningful metrics for throughput. Imagine one automated drill in a factory that produces billions of parts per year. The holes drilled are one step in an easy-to-view process and performance is simple to judge – the holes must be within less than a .02mm of variance or other steps in production may fail and the overall product will be unacceptable.

However, software development is not like this at all.  The business context, market expectations, tools, and process environment are in a state of constant evolution, so an Empirical Process Control methodology (some combination of agile, Scrum, Kanban, and XP typically ) is needed such that that the process gathers and inspects short-term results after they have occurred to inform the next set of short-term adaptive goals. A single engineer writing code, due to the unlimited number of possible demands and her/his nearly unlimited paths to supply each demand has a virtually infinite potential to succeed or fail and the throughput process has zero visibility.


 

Control Metrics vs Performance Indicators:

While the visibility and the tangible nature of throughput makes it possible determine the relationship between statistical process control metrics and company Key Performance Indicators, the continual change inherent in innovation-based software makes empirical process control metrics more difficult to tie out to KPIs. This is because accounting metrics are statistical in nature based on the consistency or predictability of the value of the currency being used and stability of the institutions assuring the long-term meaningfulness of the accounting measurements.

In other words, the success of statistical process control against a variance of .02mm requires a shared understanding and valuation of the unit of measure “millimeter” just like accounting measures are all built on a shared valuation of the monetary unit of the company. Just like companies can choose to measure in inches or centimeters, most countries currently value exchange rates for currencies relative to the dollar. Currently, the world economy is a faceless superorganism that is cohesive to the exact extent that every individually is mutually self-interested in the shared valuation of the U.S. dollar. Even those who deny the right of the U.S. dollar to play this role live in a world in which their continued engagement in the global economy requires them to interact with rationally self-interested entities that will ultimately compare the non-USD valuation of their currency with the USD-based practices of others.

On that foundation, when you are an executive leading a brick-and-mortar retail chain, managerial accounting statistics are relatively simple to choose.  As an example, retail stores create semi-homogenous shopping environments across sufficiently similar demographic regions, train and compensate based on similar sales techniques, then track revenue precursor metrics: Traffic (customers through the door, Conversion (sales per customer), Items per ticket, dollars per ticket, etc.  Daily statistics give a clear indication of the trend toward longer-term goals.

Similar metrics can be applied to an e-commerce solution to the extent that a high sample rate can give insight into the conversion funnel.  The empirical tuning of these KPI’s has a long feedback loop based on the assumption that missing the target statistic is a failure for which managers can be held accountable and the process can be corrected.  To restate – when a sales team or web site fail to hit a target, the KPI is not immediately put under review because they are based on benchmarks consistent across an industry.  Instead, the sales organization is expected to improve to meet the benchmark.

Note that the KPIs are valuable to the owner of each company (whether a sole proprietor or millions of shareholders) only insofar as they are comparable between two groups or time periods, stable over time, simple (enough for your audience) to understand, and honest in origin (whether trusted or proven). If you analyze enough Annual 10K reports to shareholders, you will note that in addition to the metrics that “everyone” reports you can also report virtually any measure you believe gives a positive and accurate portrayal of the current and future potential value of shares.   A carefully written explanation for each of these is required both in law and in practice. If it is too difficult for shareholders to understand it will likely be ignored. If it misrepresents the value of shares, there are grounds for action by governing institutions and lawsuits by those with a fiduciary interest in the value of the company.


 

What about innovation?

In companies that pursue innovation as a competitive advantage, any “benchmark” is by definition emergent.  The learning organization is constantly seeking out new tools, processes, practices, and behaviors that will lead to a unique product offering, ideally with significant learning curve advantage over competitors.  Unlike the retail company’s use of weekly conversion as a leading indicator for quarterly profit, most innovation-based companies are unable to find a leading indicator for “successful innovation” because the success being pursued has not yet been discovered!

While managerial accounting can trace the market risk of an investor based on quarterly earnings, the innovation-based startup company is often creating supply for a product prior to also creating the demand AND the market for what it will supply!

So, if you do not know your price, your market, your product, or your demand, how can you possibly guide the process of product creation to ensure successful innovation? The executive must:

  • Ensure cohesion around a shared vision and values
  • Ensure the identity and evaluation of a company is consistent enough for isolation of variable in experiments
  • Strip every risk down to its smallest possible impact

This is where empirical process control for agile software development starts to look more effective the innovation-based company.  The emerging next practices are monitored using hypotheses and experiments such that metrics are selected as appropriate to a given learning opportunity.  The problem is tying the Scrum metrics that are meaningful to a team understanding itself now may have no meaning later after they have evolved. Because these metrics are not comparable across teams and not meaningful when compared at one time versus another, they cannot be used as an indication of performance for individuals or the company!

Metrics and KPI’s are still possible, but executive leadership must be careful not to lead the learning organization into non-learning behaviors constrain the innovating company into anti-innovating practices. Note that in the retail store example, the validity of performance indicators tying into accounting metrics down to the store level and the Store Manager is meaningful to the manager. If the associates staffing the store are wage-only earners, comparing conversion by employee is pretty nonsensical. However, if a new initiative like a Loyalty Card is rolled out, incenting employees at Point of Sale for sign-ups can be effective at driving change.

This is an important distinction. The length of time a fast food chain cook keeps the French Fries in the hopper is not a performance metric – it is a minimum requirement. Behaving in a way that encourages sales is a minimum requirement for the store associate. It the manager’s duty and power to be engaged enough to whether minimum requirements are being met and reward, correct, or discipline accordingly. The Store Manager therefore manages toward a company-wide performance indicator while the employee manages their own behavior in a way that ensures continued employment.

H.T Johnson wrote a terrific analysis of the tension between Lean principles and Accounting metrics and supplies this terrific summary:

Quantum physicists have suggested that undisturbed systems in the universe naturally stay in multiple states simultaneously, unless someone intervenes with a measurement device. Then all states collapse, except the one being measured. Perhaps what you measure is what you get. More likely, what you measure is all you get. What you don’t (or can’t) measure is lost.  – H. T. Johnson, “Lean Dilemma”

 

This is commonly called Hawthorne Effect in organization psychology – the moment an organization knows a behavior is being observed, the behavior will change from its natural state (typically to match the state the members of an organization believe to be desirable).  Because time and energy are finite per resource, shifting to a new behavior is always at the expense of another behavior.  This does not mean by necessity that observation should never occur at the enterprise level, it means that every metric must be extremely strategic.

 Moreover, the undisturbed natural state of the system includes the organic self-maintenance of the minimum requirements for membership.   This self-maintaining state is the emergent Prestige Economy of the company as a superorganism.

Metrics that have an impact on the relative value of individuals within the superorganism must be selected as a way to purposefully protect behaviors against change or to drive new adaptation.   In a company where what outcome means success, executives must be that much more careful with metrics because organizational energy will be expended in response to the metric – potentially at the expense of behaviors that will result in future but unknown success.

We can break metrics into three simple categories:

  1. The Good – Metrics that reinforce known successful behaviors – or less-certain but expected to drive success and judged by executive leadership as worth the risk – thereby reinforcing organization attention, energy, and output in the direction of strategic goals; with the known trade-off of less energy being expended on less-important processes.
  2. The Bad – Metrics that reinforce non-priority behaviors often due to leadership not possessing a sufficient understanding of strategic goals and what drives their achievement.
  3. The Ugly – Metrics that shift attention directly into bad behaviors, leaving the process that was being tracked worse rather than better.  These are typically a symptom of systemic co-dependency – the members of the organization see that there is a parent-child relationship, they are misunderstood, and they act out or lie in order to avoid punishment or gain attention from leadership.

 

Measure Strategically

Good metrics can only come from leadership, because only leadership is empowered and accountable for strategic trade-offs.  Know what you want for your organization, what you must prioritize, and what you are willing to sacrifice.  Measure the few key numbers you are certain positively reinforce what you want.  If you find yourself relying on consensus, or measuring in aggregate anything organization members are already measuring for their own purposes, slap your own wrist.  You have failed at leading.

A pilot has dozens of metrics available to her.  In context, many of them are important to a safe and comfortable flight.  You may have noticed that – while Average Aggregate Flight Altitude could be meaningful for scientific research – it is meaningless on an airline Annual 10K.  Many organizations do the equivalent of asking a pilot – “What is the most important metric in your cockpit?”  Don’t be that leader.

This is part of a series!

Part 1 – Metrics: The Good, The Bad, and The Ugly

Part 2 – How to Fail at Performance Metrics

Part 3 – Rules For Measuring Success

Part 4 – Measuring What Matters to Innovation

Throughout the series I tie together ideas from two great resources:

Kevin Simler’s Minimum Viable Superorganism

Steven Borg’s From Vanity to Value, Metrics That Matter: Improving Lean and Agile, Kanban, and Scrum

You Look Dumb – 5 Mobile Marketing Mistakes

Your smart presence looks pretty dumb.

Welcome to the “smart” era – smart phones, smart cars, and smart homes are finally here! You can officially go to display rooms in your local appliance store instead of booking a trip to Orlando to see the home of “the future”.  In our smart era, a fair percentage of the population now carries supercomputers in our pockets with computing power that would have filled a warehouse even in science fiction during the baby boom.

Unfortunately, as “smart” as all this technology should be in your business, I’ve noticed your company looks pretty “dumb” because things are getting done exactly the way they were before, but now on a smaller screen!   As much as technophiles may blame late-adopters for not buying in to new devices and new apps, wake up – if you’re asking people to do the same old story, same old song and dance, but you’ve given them a more difficult form factor to do it on, they have no reason to adopt!

In that light, here are the 6 mobility mistakes you might be making RIGHT NOW that keep your mobile presence looking dumb where it ought to be smart:

 

#1 – You Encourage Channel Hopping

If your mobile marketing strategy has shifted consumers from one conversion funnel (web or brick) to another (apps) but hasn’t resulted in increased revenue, you’ve encouraged channel hopping.  This is a nightmare scenario that often pits employees of each channel against each other internally, fighting for additional budget, unable to fully justify forecasted ROI.  What happened? When you built your native app, the value created by your investment was captured 100% by your consumers!

This looks dumb to the smart consumer, because it is painfully obvious when the only difference between the native app and the responsive site is Touch ID. The choice between a link on the home screen versus a downloaded app comes down to space on the phone and speed of content loading.

The math for the mobile marketing individual is so simple that this mistake looks extra “dumb” to your boss. When traffic stays constant, but an additional channel is added, aggregate conversion across the channels must increase or else your funnels are just cannibalizing each other. That’s the ROI problem every mobile marketing initiative must overcome: when you invest $200k in mobile eCommerce and revenue stays constant, your consumers have captured all the value created. Sure, they may be happier. They might say “how convenient to have a desktop site AND an app for researching and executing my purchases!” Unfortunately, the return on your investment they capture doesn’t inherently result in more traffic, conversion, sales, or loyalty.

Admittedly, companies don’t make this mistake in a vacuum. They see traffic and sales moving from their desktop site to a new competitor’s mobile app – panic ensues – and they build an app of their own to stop the bleeding.

Remember, a bad bandage can be more dangerous than no treatment at all. The smart mobile marketing plan requires one of two approaches to respond to the threat of new entrants:

  1. Double-down on web. Yes, I make mobile apps and I’m saying its okay not to have a (native-coded) mobile app. If your plan for mobile is to reproduce a brochure, a paper form, or a website, don’t do it. Seriously, just throw your money in a pile and set it on fire like the Joker in Dark Knight.  If your site is working great but it isn’t a responsive site – start there. If it is outdated and anything is unintuitive, fix it. If you can’t create a unique relationship with consumers through your native mobile presence or capture the channel-specific value created, double-down on making your web presence best-in-class. This is Game Theory 101 – If you can’t win at both web and mobile, win big at one and forget the other.
  2. Create a unique market via app(s). If your audience is shrinking or your relationship with your consumers is suffering due to the mobile presence of a competitor and a truly unique relationship can be built through a mobile app – do it. This means your mobile presence needs to accomplish at least one of two things: augment the physical experience in ways a website can’t (to increase conversion) or create a completely new experience for a totally new audience (to increase aggregate traffic). Which path is right for you will depend on your market, products, and competitive landscape – so do your homework (and get a “tutor” as needed).

 

#2 – No Context Awareness

This is at the heart of what is so dumb about the way many companies establish a market presence on smart devices. If you have the opportunity to look “behind the curtain” you will notice this problem is not isolated, but occur on two fronts for that firm – externally in their consumer native apps and internally in their custom enterprise solutions. I’ve touched on specifics of Context Awareness several times. The differentiating power of a native app is in its intimate knowledge of where a user is, where they are going, and how they think. Segmented push messaging, one-tap deep-linking, and social API integration make the native app capable of a completely new relationship with your consumer. They are using a supercomputer that aggregates an unprecedented amount of personal information – all you have to do is offer a reward that justifies opting in.

Don’t fall prey to the opposite though – opting out should be easy, transparency on the use of private data is key, and you typically have one “strike” per consumer when it comes to keeping an app on their device. Whether it is download size, loading time, or privacy betrayal, as W.B. Yeats wrote, “Tread softly because you tread on my dreams.”

Talk to technology professionals so you don’t plan your mobile presence in a vacuum. Geofences, iBeacons, IoT hardware, Photos integration, BLE, IoT, QR, wearables, and triggered messaging are all tools of the trade for ensuring you are able to create a unique proposition in a native app. Find the biggest impediment to solving your consumer’s pain in a way they will pay money for you to solve. Do NOT invest in native mobile unless the pocket supercomputer is going to augment physical realities with digital awesomeness.

 

#3 – No Business Intelligence

Ignorance is bliss. Unless you are driving a drastic paradigmatic shift in how you engage fresh generations of consumers through a new and constantly-evolving medium. In that scenario, ignorance is death – the death of any success you could have achieved.

“No Business Intelligence” is the bad-joke-telling best friend of “No Context Awareness” who crashes the wedding reception of your otherwise-integrated-marketing strategy. Where context awareness can drive new forms of engagement by proactively anticipating needs and supplying easy answers, business intelligence is a trailing ROI that takes effort to reap.   Business Intelligence is like planting a vegetable garden, as much as the visual presence of a lovely variety of plants may have delighted you on its own, you are leaving ROI out in the field until you harvest it. The same is true in mobile marketing. Until the big data you have created is collected, curated, and learned from in order to provide better plans, more focused campaigns, and the tightest possible updates to forecasts, you are creating white noise that should have been a joyful symphony.

At a minimum, it is essential you collect enough meaningful data to justify that you have accomplished your goals. The less you can prove directly that you have created new traffic, new converted sales, or new revenue sufficient to justify your investment in mobility, the more you need business intelligence to prove the indirect benefit provided to other channels. Better yet, even when new revenue is both directly and indirectly attributable to your mobile presence, you should drive BI insights like you are starting a company that will sell its knowledge. You may start by “selling” it internally to help justify you P&L, but don’t rule out the possibility external buyers may exist.

 

#4 – No Game Plan for IoT

If you don’t have concrete plans for drone technology or self-driven cars, I forgive you.  Not every industry will need direct adoption for these new technologies.  However, if you haven’t given serious thought to what your products and services can be in a connected world – called the “Internet of Things” – you are going to find yourself left behind over the next five years.

IoT is already within reach and less cost prohibitive than you may think. Connected power indicators, pipe flow sensors, BLE chipsets for detecting and communicating almost anything – they are all out there. Today what is being “tacked on” to products by R&D will tomorrow be a seamless experience seen as the baseline for market entry. You can afford not to be the first mover to the extent Silicon Valley startups are learning the hard lessons for us all today. That said, don’t get out of touch and don’t get left behind.

The Internet of most connected Things means at least one of two potential realities your business:

  1. Some products you currently market “dumb” will be expected to connect soon – a significant event in your product strategy because the value proposition of your physical Thing will not matter as much as how it connects to the app you provide with it. Think today what that app must be in order to compete. In fact, you should probably be building that app instead of reproducing your already-responsive web site. Then, more dauntingly, think about that product and app and their ability to connect with other Things that are connected in a way that creates a meaningful brand relationship.
  2. Widespread IoT products will further segment your target market and the position of players across your competitive landscape. If your product’s three year plan does not clearly indicate whether you will focus on selling non-connected versus connected variations or both, including the business case for how each will be priced and marketed, schedule meetings right now to drive those discussions.   The threat of new entrants on both sides will be higher as major players struggle to straddle the fence strategically.

 

 

#5 – You’re Stuck in Analysis Paralysis

Speaking of sitting permanently on the strategic fence, one of the dumbest responses to the introduction of smart technology is analysis paralysis. As my strategy professor emphasized while introducing Michael Porter, refusing to make a decision is your decision. That favorite Porter quote – “Strategy is the art of making choices”. In a Zero Sum game with multiple players and finite economic resources, strategy is the art of committing not only specific resources, but also commitments as a competitive position to the long-term continued investment of resources. By holding resources – even in the most uncertain times – you’ve made a decision to wait. The key to the good life, as Aristotle would say, is that the decision to wait, if virtuous, must intrinsically be deliberately decided.

If your organization is stuck in analysis paralysis, overwhelmed by the amount of aging IT investments behind you and the mountain of new (and sometimes unproven) technology ahead of you, a lack of action may preserve some capital in the short-term, but you are racking up immense opportunity cost and learning curve disadvantage. If your company has too many ideas and no commitment to a roadmap, here is how to get smart:

  1. LESS IS MORE – Don’t try to reinvent your entire IT and Marketing infrastructure in one big push. Define Lean Startup-style MVPs that give you a “quick win” (or a few) while getting you past the rookie mistakes, first-time jitters, and growing pains that are inevitable out of the gate.
  2. SOLVE REAL PAINS – Mobile for the sake of mobile fails the stakeholder, the end user, and leaves a bad taste in the mouth of executives and investors. Look for the biggest complaint of your customers or the biggest inefficiency in your operations workflow. If the solution is mobile, do the smallest possible iteration of that solution. If it isn’t mobile, fix the pain without mobile. Rinse and repeat as needed.
  3. OFF-THE-SHELF is an OKAY START– On that note, with the thousands of tech companies out there, don’t go custom on everything. Open or paid APIs, packaged solutions, and white-label solutions, and SDKs are all alternatives to re-inventing the wheel in a vacuum. Review your options carefully (but keep the scope of your goals tight enough your review doesn’t paralyze you).

Warning: Your Company is WASTING Money.

Warning: Your Company is WASTING Money.

Companies are throwing away money.  The bottom line is sick.  Margins are dying.

In my last post I said the number one sign of “Information Inefficiency” is the clipboard.  To take Lean and Six Sigma to the next level, a disruption must occur.  The workplace experience must be transformed.  However, accomplishing true disruption will take more than replacement of each paper process one by one with a virtual process.  Replacing each clipboard in your company with a tablet is simply not enough.

Your company is losing money to the clipboard mindset.

The clipboard mindset has several symptoms:

  • The worker capturing information cannot easily pass that expertise to new employees.
  • The information lives in an abbreviated form until the worker adds context elsewhere.
  • The form/paperwork itself requires training before it can be utilized.
  • It takes more than a day for the information to “go digital”.

The clipboard mindset is pervasive in the digital era.  Your workforce may not carry around paper forms on a clipboard with a No. 2 pencil anymore by my experience with hundreds of companies is that the inefficiencies of the clipboard mindset spread like a virus into our laptops, tablets, and smart phones.

What’s the real cost of clipboard mindset?  

#1 – Delayed information symmetry.

Imagine the three most important pieces of information for your P&L.  Where did it originate?  Where does it go?   How long did that take?  In economics, information asymmetry is a crucial element of Game Theory and the Nash Equilibrium.  In a zero-sum game in which each player tries to make a decision based on the potential decisions of every other player, “information asymmetry” is like being the only poker player who can see another player’s cards.  While we typically apply this to businesses competing with one another, the same can apply to every decision that will impact more than one person.

Although it is not possible to know the same information that your competition knows about themselves, minimizing the time it takes to know your own business is critical.  In the information age, information symmetry up and down and across the organization must be instantaneous to keep decisions informed.  A clipboard delays information symmetry between the person who gained the insight and the person who needs to make a decision about it.

 

#2 – Social Decontextualization.

Whatever piece or pieces of information you’re imagining right now, this information is fundamentally social in nature.  How often does it need additional explanation?  How long does it take to get that explanation, or – worse yet – how often do you dismiss it because an explanation isn’t available?

Whether that information came from a conversation with an employee, a site visit by a sales manager, or diagnostic output from specialized machinery, every clipboard – physical or digital – is missing human context.  Every checkbox strips out nuance, every fill-in-the-blank limits information sharing, every abbreviated word gambles against forgetfulness.  Context is fundamental to human expression.  Why is it decontextualization so inefficient?  The social and tribal part of our brains and makes decisions has no capacity to understand language.  As Simon Sinek shares,

Our newest brain, our Homo Sapien brain, our neocortex, corresponds with the “what” level. The neocortex is responsible for all of our rational and analytical thought and language. The middle two sections make up our limbic brains, and our limbic brains are responsible for all of our feelings, like trust and loyalty. It’s also responsible for all human behavior, all decision-making, and it has no capacity for language.

Sharing the feeling of the moment is the most important element of taking one person’s social context and passing it to another as actionable information.  A clipboard captures very little of our context so that is not passed from the person who felt the moment and the person who needs to make a decision about it.

 

#3 – Decision Fatigue.

If your company has introduced a wellness program, you may have already heard of the idea of “presenteeism” – showing up to work for your normal day but so “out of it” that the contribution is well below 100%.  While the wellness community focuses on the impact of poor-but-not-quite-sick “physical” health, the clipboard mindset is the root of another form of presenteeism: decision fatigue.

The neuroscience of decision-making shows that the entire brain and even a fair amount of the body uses up resources in the process of turning executive function into action.  The more you have to recall from long-forgotten memories, the higher the level of attentiveness required, the more stress or other emotions that get involved, and the greater the threat or potential reward of the moment – these drain taxing multiple systems in a smartphone (geolocation, graphics processing, bluetooth) drain the battery of a smartphone.

Problematically, while we can make other plans for getting directions if our smartphone battery dies, when our decision-making “battery” is exhausted, we often have several hours of work and decisions to make!  Feeling stuffy due to allergies may reduce your attentiveness, but hitting the decision fatigue wall at 2pm causes the brain to rely purely on fight, flight, or freeze.  This type of presenteeism doesn’t just make us less efficient, it makes us overreact, avoidant, or complacent about the status quo.

While productivity experts will recommend structuring your day and creating a routine that removes unnecessary decisions, these are the low-hanging fruit of decision fatigue.

Transformative mobility revolutionizes businesses by tackling the the toughest, most painful consequences of decision fatigue – adding context, recommending information, removing fear of failure, minimizing the need of distant memories, communicating instantly rather than adding the fear of forgetting the meaning of your own notes.

 

Breaking the Clipboard Mindset

If your current Mobility Strategy has left the clipboard mindset intact, move the conversation to finding ways improving the workplace experience can increase the engagement and effectiveness of your employees:

  • Capture context seamlessly – location, weather conditions, and biometric data are all becoming simpler to capture along with the information the employee adds
  • Use visual cues rather than words – The decision-making part of the brain doesn’t read the words, use photo, video, and metaphor rather than words
  • Help answer questions – don’t just fill in the blank:  one choice should simplify the next choice by narrowing the possible options, reducing the stress of poor decisions
  • Proactively provide information – from geofencing to notifications, employees should not hunt for what they need – it should already be there
  • Rely on search over personal memory – a simple front-end and powerful back-end will empower workers to find what they need rather than memorizing it

 

STOP wasting money!

The clipboard mindset is destroying the ROI of your human and IT resource investments, perpetuating bad margins through inefficiency and ineffectiveness, it is time to break yourself and your company free.

If you are looking for ideas or training on these concepts for you and your team, send me a message.