Fine, I’ll Do It Myself

I’m going to launch a product.  I’m going to start a company.  I’m an entrepreneur now. 

I see clearly that grabbing my best intellectual ally(s) and applying the combined, multifaceted, full-stack, full-spectrum brilliance we have is far more powerful than huge enterprises can compete with.  They are weighed down.  They can’t stop siloing.  They have enough money to survive their blunders for decades – that’s the only advantage they have.

With the inspiration of Austin Kleon’s Show Your Work! behind me, I will show anyone willing to listen exactly how I progress.  By doing so, I hope every potential user can be involved in the process, not just consume the product.

I’m not worried about having my idea stolen.  I care about it because it solves a pain I have and you might have it too.  I am building it based on selfishness, love, and empathy. 

“The special challenge of being a startup is the near impossibility of having your idea, company, or product be noticed by anyone, let alone a competitor.” 

The Lean Startup by Eric Ries

If you want in, Tweet with the mention @keenerstrategy and #ShareLighter to send me questions, requests, or ideas.

Image via Kaique Rocha

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

How to Fail at Performance Metrics

In my last post we reviewed Hawthorne Effect and other exciting topics.  Check it out!

Throughput Metrics:

So how do we find statistical process metrics that lead to better empirical process output (without dire consequences)?  The ramifications of an “ugly” metric cannot be understated.  The goal of implementing agile is to reap the benefits of higher team velocity, better fit-to-market, better quality products, faster time-to-market, while establishing culture and innovation as a competitive advantage.  These are lofty goals. The engineers and other functions you have gathered together likely joined with a desire for meaningful software creation. The natural undisturbed and unmeasured systemic state of such a group should be a collaborative effort to create products envisioned by executive leadership. Introducing an ugly metric will near-instantaneously disrupt whatever was gained through agile by driving symptoms of codependency in the organization. It will be a betrayal and undermine the creative process.

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

 

First of all “manager who don’t know how to measure what they want” need to try harder and ask for help from thought leaders, a Google search, or fellow leaders. There is no excuse for allowing a company to hum along without any guidance from its visionary executive leader(s). There are an enormous number of metrics possible.  An experienced statistician could produce probability distributions showing likelihood of correlation between any number of variables and an expected outcome. This does not make them valuable to an executive or appropriate for an organization. A metric must be easy (enough) to understand. Although a fair number of humans (especially engineers) can compute two-variable “fuzzy weighted logic” in their heads, I defy you to find an entire for-profit organization where every person can compute and make informed decisions based on complex multivariate calculus and probability distributions.


 

Vanity Metrics:

We have seen so far that the right reason to have a metric is as a purposeful tool for implementing executive vision while the wrong reason to introduce a metric is to correct the insecurity of executives when they feel “out of touch”. The latter are vanity metrics. They make the executive feel better at the risk of redirecting energy toward behaviors that run counter to success. One example is utilization.  It may feel good to track as a manager, because companies that pay people have taken a risk and want an appropriate return on the social contract known as “salary”.

Unlike some metrics, it is unlikely that utilization gets tracked with a purposeful tradeoff against lead time or cycle time. In other words, to the extent a company adopts agile and prioritizes “responding to change” – or responsiveness in general – maximizing utilization is mathematically counter to agile because it is detrimental to responsiveness.

This has been thoroughly analyzed in queuing theory. If you imagine any one engineer:

  • 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. Now you may have heard Google has 20% time as a benefit, but when looking at M/M/1 queue – applied to highway flow, server traffic, or people – the point at which the trade-off between capacity utilization and responsiveness becomes unacceptable is not solved statistically. All that is known is that handling additional requests will eventually need additional capacity.

“As the freeway approaches 100% capacity, it ceases being a freeway. It becomes a parking lot.”

Jim Benson, Personal Kanban: Mapping Work | Navigating Life

 

This is the problem with tracking utilization. What is the “right” utilization number? Executive strategy defines acceptable trade-offs. Unless you clearly articulate a benchmark and its importance, your employees will assume utilization is tracked against 100% of 40hrs, shifting their behavior to an inability to quickly respond to new requests. The Hawthorne Effect of tracking utilization purposelessly is over-commitment and burn out.

However, as a leader of an organization, an expectation of managers must be established. When are additional resources hired to ensure the desired level of responsiveness? As a rule of thumb, how much work – assuming there is significant work to do – assign to any given employee? Is it okay keep utilization at 50% for some employees? When is overtime acceptable? Acceptable management practices must be defined based on goals for responsiveness.

This is the difference between “utilizing” an hourly wage warehouse employee by having them sweep the floor an extra time on a given day due to downtime versus cutting a salary-based ambulance and firefighting team due to low “utilization”. The hourly employee typically would not want reduced wages because of a lack of work and there is always a floor to sweep while they wait – the manager knows they are suppose to keep the employee busy. In contrast, responsiveness to a major fire or someone going into cardiac arrest is prioritized through “excess” capacity by mitigating the risk that utilization of the capacity to respond to fires or medical emergencies ever exceeds 100%.

We can see now that tracking capacity and utilization is far less important than tracking responsiveness. In agile software delivery there are two types of metrics that ought to be meaningfully tracked and compared to achievement of company financial goals:

  1. Responsiveness to Change – In aggregate, from the time it is known a market demand has changed, how long does it take to “pivot” and address shifting market conditions.
  2. Feedback Timeliness – For any given point in the process, this is the length of time it takes to validate the intended change was implemented in response to change.

 

 

Proxy Metrics:

If the metric you want is nearly impossible to reliably compute or gain sufficient organization-wide understanding and traction around your vision, this is when you need to find proxy metrics that everyone can agree is an indirect leading or trailing indicator that the organization is properly taking the small daily steps that result in annual success. While a good expression of executive vision likely expresses strategic commitment and trade-off at a broad level, employees need an indication of how to make the daily hard decisions that directly impact their status and prestige within the superorganism.

Without this sense of “blessing” surrounding the commitment of time and resources, employees are powerless. Expect diffusion of responsibility and self-protective over-documenting of decisions that are made. In contradistinction, an executive seeking “the good” metrics needs a sharp eye on how a metric will create positive reinforcement of decisions that fit with the long term position in which the company is moving. If a metric does not reinforce the empowerment and authority you have blessed employees with, so that they make the correct decisions you expect your employees to make, it is a dreadful metric.

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

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.

 

Disrupt & Win: Next-Level Lean Process Improvement

Disrupt & Win: How to Achieve Next-Level Lean Process Improvements with Custom Apps

Is your business having trouble keeping up?

It is time to get lean.

Kaizen – Continuous Improvement

Kaizen is a core principle from Lean that lays the foundation of how we choose the right custom enterprise mobile and web apps for process improvement efforts.  Loosely translated from Japanese, kaizen means “change for the better”; but kaizen is bigger and bolder than tacking on an improvement to an existing structure – it is the process of continuously breaking down a process, removing unnecessary effort or waste, and rebuilding it as a more efficient and effective process.

In custom enterprise app consulting, kaizen is the ultimate goal of the discovery and analysis we follow in finding the key enterprise workflow that is both proprietary to an organization’s competitive advantage while (sometimes surprisingly) it is also a source of pain and waste.  Because this seems contradictory, companies rarely ask for the application that will make the biggest difference to their organization.  To plan a truly disruptive roadmap that will position your key processes for sustainable competitive advantage takes a level of honesty and vision that is not easy to tackle alone.   Here are some key concepts from Lean that we use to help you plan your enterprise app portfolio and take your kaizen to a whole new level.


The Three Actuals – Genba, Genbutsu, Genjitsu

Lean consulting begins with finding the 3 Gen or “actuals” of your enterprise.  Kaizen is impossible without direct insight into the organization, so these three “actuals” are critical to finding the right apps that can succeed big and drive the adoption of innovation and mobility as a competitive strategy:

  1. The Genba – By visiting the Genba or “Actual Place” where business is done, products are built, and revenue is generated, an enterprise solutions consultant can view and understand the operations that create value, whether in a factory, a medical facility, or a sales showroom.  Through first-hand observation, rather than conversation, far more can be learned about what an organization does, how it is done, and why it is done.  Whiteboards and conference calls can never convey the real heart of an enterprise, the “What’s the point?” or the “What’s it worth?” as it is experienced by the people who keep each process moving, so coming to the actual place is critical to building out a solution that speaks to the pain felt by the people performing the work.  These pains tend to originate from inefficiencies and information asymmetries that workers will protect out of a fear of change.  Changing a process through training or a set of new rules often fails for this reason.  The disruptive influence of a mobile solution shortcuts this fear – mobile adoption rates are accelerating and new generations of employees demand the simplicity and focus of apps in the workplace.  These employees must capture real value in order to drive higher revenue and operational cost savings – getting to know their daily workplace experience is crucial.
  2. The Genbutsu – If possible, a great consultant doesn’t just watch, it is even better to directly interact with the genbutsu or “Actual Thing” – the real equipment being moved throughout a hospital or the customer “hand-off” artifacts.  In Lean Manufacturing, this often focused on the actual parts being assembled, the path those parts travel in a factory, and finding ways to simplify repetitive motions, reduce unnecessary travel distances through better placement of the work stations, or reducing the complexity of a step in the process by changing the order in which pieces were added to the final product.  In enterprise mobile solutions the “actual thing” is often information and the path it takes before and after that information becomes data and drives actions that produce revenue.  Information is easily decontextualized, so minimizing context-switching in the information-data-action flow is critical.  Mobile solutions drive context-awareness that turns social information into actionable data immediately and cuts out waste.
  3. The Genjitsu – Jitsu is an art, skill, or practice; a word that evolved etymologically from the characters meaning “a step along the middle of a road”.   In Lean consulting, this means we must grasp and communicate the “actual situation” as it pertains to one process as a step in an overall flow.  More importantly, we must quantify the reality of the process as objectively as possible, separate from emotional responses due to ego, social status in the organization, or feelings of blame.  We do this by obtaining data, making hypotheses, documenting workflows, and validating assumptions.  The goal is to not only make a well-informed decision about the most valuable apps that can be created, but to validate the features that will be part of it.

Once the three “actuals” are known, sources of waste can be objectively identified, solutions crafted and prioritized, and an initial Minimum Viable Product can be determined.  First, let’s review how we can create custom apps using proven Lean process improvement tactics.


Just In Time – Why mobile?

Mobile apps are fundamentally on-the-go and on-demand.  The instantaneous nature of communication using mobile allows the Just-in-Time management philosophy  to apply to operations processes, delaying resource commitment and investment until it is absolutely necessary.  This allows the shortest possible feedback cycle between demand and supply and removes waste due to information asymmetry.  If you have ever been left alone as a sales rep checks inventory or watched someone wait on hold to obtain manager approval, you know you know how painful – for the employee and the consumer – a lack of instantaneous information-data-action can be.

Just-in-Time is well defined by its original proponent, the Toyota Production System:

Supplying “what is needed, when it is needed, and in the amount needed” according to this production plan can eliminate waste, inconsistencies, and unreasonable requirements, resulting in improved productivity.

via Toyota

Since our app strategy is founded on upgrading key resources by removing wasted time and effort, mitigating inconsistent process throughput and output, and unreasonable rules and requirements to “protect” against costly mistakes, Just-in-Time is central to every great enterprise app portfolio.  Social information becomes actionable data, from answering time-sensitive questions to triggering purchases.  Real-time communication can replace unnecessary meetings, a highly focused and intuitive user experience can replace training memorization of rules.  The ability to ignite a chain reaction from 3 taps of an iPad is an incredible time and cost saving that can also create enormous additional value that can be captured more quickly.

Implementing Just-in-Time through custom apps allows real-time analytics about the process and its evolution, a “version history” for process improvements, gamification of as-you-work training, and a real-time feedback system for future kaizen.  This means creating continuous flow, level-loading process steps, creating “smart” tools, standardizing quality of work, and balancing minimal investment against highest value productivity is not only simplified, it is easy to validate process impact quickly.


The Yamazumi Board – Creating Continuous Flow

The first step in improving a process with one or more apps is documenting the existing workflows as the focal point of discussion and as the baseline for hypotheses about potential improvements.  There are software tools for this, but post-it notes on a whiteboard can work as well.  Yamazumi literally means “to pile in heaps” and this is exactly what how the analysis is completed, by stacking each step in a process in columns representing each person or role in the workflow.  This could be fairly high-level, tracking the flow of a paper form across the organization, or extremely granular, such as every step in the manufacturing and assembly of a complex product.

via Michel Baudin

By documenting the steps of a process in this way we can easily visualize the imbalances in a workflow, identify the “pace maker” process, discover bottlenecks, and clearly see the cost of unproductive downtimes.  Combining roles that cause diffusion of responsibility, separating roles that cause unnecessary task switching, and removing unnecessary “fail-safe” measures will remove waste and reduce cycle time, making the process more efficient overall.

Once each process in the workflow is organized into an ideal future state on the yamazumi board, we can easily see the specific tool each role will need to be as effective as possible at creating value.  If each tool has a unique user base, we will consider each tool a separate app that we can evaluate and prioritize based on expected returns.  Next we evaluate how strategic disruption using a mobile-first mentality will create impact above and beyond simply reorganizing existing resources.  Whether we are targeting information, inventory management, or customer interaction, our app portfolio needs to work as a seamless ecosystem that facilitates continuous flow across the entire value stream.  Through notifications, context awareness, and on-the-go data connectivity, we are able to brainstorm solutions to each identified pain that can achieve heijunka.

Heijunka – Level Loading

The Lean Lexicon, 4th Edition defines heijunka as:

Heijunka is leveling the type and quantity of production over a fixed period of time. This enables production to efficiently meet customer demands while avoiding batching and results in minimum inventories, capital costs, manpower, and production lead time through the whole value stream.

Once we have seen how our piles of work are should be distributed to achieve continuous flow we then need to identify the pains and inefficiencies that exist even when the process is running smoothly.  Before we can prioritize a roadmap of custom mobile apps, it is important to know the elements of a process that are consuming unnecessary time and resources, find and remove batch-and-queue systems that create process bottle necks, and smooth out supply and demand.  Because we have distributed process steps across focused roles using the yamazumi board, we can now look at the specific pain points that each tool can address for each role.

In Lean Manufacturing, the concept of heijunka is taught using forecasting in supply chain management.  The more unpredictable the demand, the more advanced the forecasting algorithm may be but delaying differentiation, stabilizing production, and reducing inventory holding costs is always possible.  When creating disruptive-grade process improvement with custom mobile apps we can apply the same principles to “memes” and look for the inefficiencies, loss of fidelity, and bottle necks in processes that transform context-specific social information into data that is actionable across multiple roles.  To win at disruption and to resolve internal information asymmetries and bottlenecks, we need to think through solutions that remove the noise from the signals we rely on to forecast processes.  To this, we use custom apps to control selection, throughput, and output.


Jidoka – Autonomation

From the Toyota Production System, the concept of jidoka – “automation with a human touch” means that machines are “smart” enough to identify their own failure, empowering human operators to rectify the problem before faulty parts enter the production line.  Before autonomation these parts were only tested at the end of the production line, so a single machine creating bolts for engines could make an entire day’s work unsuitable to ship!  To mitigate the immense risk of an entire factory-day’s production being scrapped, an operator could be placed at each machine, checking quality of output at regular intervals.  Jidoka is the next evolution of this process improvement, so that machines judge their own quality and a single operator is able to validate the accuracy and quality of several machines, reducing the number of resources required per machine.

In an enterprise app portfolio, the ability to focus a user on completing a single workflow quickly with context-based help and input validation accomplishes similar autonomation.  The more focused an app is on a single user completing a specific task, the less we will need restricted access and complex logic.  Instead, the technological investment can be focused on context awareness and assistance.  This creates a powerful ability to the guide subjective observation of an employee into objective judgment.  Rather than increasing training, creating new policies and punishments, and increasing managerial oversight – an a attempt at a “fail-safe” environment – we want to create intuitive “smart” solutions that create a “safe-to-fail” environment in which some mistakes are no longer possible and consequences are minimized.  This empowers employees to consistently succeed and removes the stress of failure, all while reducing the need for direct managerial oversight and human approval processes.  Anywhere your employee is asked to supply critical information or responsible for continuous flow to the next process step, we want to facilitate responsiveness and guided interaction, then capture and aggregate data as Business Intelligence that can inform both the worker and organization leadership about decisions being made.  Anywhere an employee must manage machines or technology, the inner working of which only a specialist would understand, we want to create an interface into the health of the process rather than set the false expectation that every employee can be skilled at

Once the solutions to process pain and waste are imagined – with an eye on “smart”, intuitive mobile workflow tools – we want to look for ways to ensure that throughput and output are consistent in time, effort, and quality.


Standard Work

Through effective information architecture and user experience design, the mobile app user is able to follow an established and intuitive workflow of interactions that are ideally context-aware.  So in addition to the focus, empowerment, and autonomation improvements, going mobile is a time to analyze current best demonstrated practices internally and externally, and standardize them.  Standardizing what is done, how it is done, and creating consistency of output not only reduces the necessity of identifying and addressing under-performers, it creates a context for the employee in which output quality is held constant for them, enabling focus on critical thinking and social engagement rather than policies and spreadsheet-like information tables.  Even more importantly, once work is standardized with a mobile application (e.g. instead of a document template) the consistency of output and capture of Business Intelligence will allow an objective review of “best” practices, assist with hypothesis and experimentation removing some of the emotion and politics from the kaizen process.

Once changes are identified, effective MDM enables your organization to control the shift to a more effective practice by simply releasing a new version of the software.  Build any training (using interstitial screens) and feedback (with modal per-feature ratings) directly into the application.


Minimum Viable Product

The end goal of removing interruptions to continuous flow, level-loading processes against fluctuations in supply and demand, and removing information asymmetries and process waste is to attain Minimum Viable Production – a process state in which we find a “sweet spot” in the tension between minimizing invested value while maximizing return on that investment.

This goal will need to be reached on three levels:  the process being improved upon, investment in improving the process, and prioritization of the custom app investment portfolio.  Because we are disruptively and potentially drastically rebuilding a process we need to understand the point of diminishing marginal utility for inputs to the process itself as a precursor to determining the investment we should make in it.  If we are attempting to increase revenue through an improved sales representative process, we need to recognize that increased capacity does not increase demand – we will need to identify stabilizing and increasing supply can result in an unfair advantage in the market.  If demand for a process output is unlikely to grow, investing in increased capacity is ill-advised.

If we focused purely on minimalist production, we would drastically rebuild our core operations processes – stripping out anything unnecessary to gaining the “easiest” productivity possible.  A true focus on minimalism might even cut revenue in favor of margins by creating less value.  Opposing this approach would be a total focus on viability, in which we invest to upgrade processes and resources regardless of ROI to achieve the most robust value stream possible.  Ideally, this would give us sustainable competitive advantage, assuming we raise so many barriers to entry that we create near-monopoly conditions.  However, most gaining economic rents in this way can take years to capture, making the investment risky.  By maintaining a tension between minimal investment and maximal viability, we can minimize necessary inputs while holding output constant, increasing process ROI.  If desired we can then establish a path for increasing input while holding ROI constant.

With mobile apps, we facilitate minimum viable product by transforming the nature of the steps taken in a workflow, the number of steps, the number of operators required, and minimizing time to complete each step.  By removing all delays in information transfer and introducing autonomation we are able to bring downtime to an absolute minimum.  Maximizing ease of completion and minimizing time to completion is therefore the overarching goal of mobilizing any process.

Once we have a full understanding of the next-level lean processes, we take the mobile apps we have dreamed up and create a prioritized roadmap for investment in our app portfolio.  While the “big dreams” white-boarding session is an important first conversation, defining Minimum Viable Product for both the processes we will disrupt and the process improvement investment we will make is critical to ensuring the app roadmap is continuously focused on the improvement with the highest incremental impact.

How to use the Lean Canvas for App Planning

Lean Canvas

The Lean Canvas via http://www.leanstack.com

The Product Vision Imperative

Imagine a Ferrari with no steering wheel and no tires – no amount of horsepower or torque will win the race if a car has no direction. Increasing resources or efficiency without alignment and traction on a common strategic vision is utterly ineffective.  While agile, scrum, and XP will maximize velocity, it is critical that we ensure the well-formed team has ultra-clear, laser-like focus on the goal.   After all, no increase in velocity or decrease in impediments can supplement a lack of understanding of what to build and why it should be built.  This is why the ability to clearly articulate the product vision of an app is critical to ensuring we don’t just build the right app and build it fast – we build it for the highest possible impact.

There is a natural 3-level taxonomy to an app.  The app Narrative (the entire app) is made up of Epics (major features), Epics are made up of Stories.  Because an app (as we’ve previously defined it) is a relatively small and ultra-intuitive tool with a highly focused outcome, stating the Narrative is the Lean way to succinctly express the workflow being created, who will use it, and why.  It conveniently looks like a massive user story:

  1. The Narrative – A a sales rep, I want to support customers without having to turn my back or leave the room so I can build better rapport as their consultant.
  2. Some Epics – Check inventory, Answer questions, Take payment, Notify inventory team
  3. A User Story – As a sales rep on the sales floor I want to use Apple Pay to accept payment from my customer  (Part of the Epic “Take Payment”)

The simplicity of this description will help align the team on the product vision, but it glosses over the business case that justifies the vision.  This can be done efficiently for multiple apps using the Lean Canvas approach to documenting the business case for an app.


1 – Identify the Problem

Because the scale and scope of any given app MUST be laser-focused we must start with identifying the key problem we want to solve.  Building the right app – A Billion Dollar App – means we don’t build a hammer and start hunting for nails.  We identify the nut, bolt, or screw, take stock of the complex setting in which we find it, and build the right tool for the job at hand.

“Customers care about their problems – not your solution.”

-Dave McClure

This begins with the Problem Statement.  The top three major pains for a single (existing) operations workflow often tie together in one overarching “problem”.  The Billion Dollar App for an enterprise should also have no feasible existing alternatives.  We aren’t reinventing the hammer!  Instead, we want to identify the problems that are unique to the organization, making a custom solution the best approach.  If a SAAS product for a non-core process is available for a client’s pain, we do the right thing and suggest the correct existing solution.


2 – Know the Target User

An appropriately sized and focused app must have a well-defined target user base.  In marketplace consumer apps, this means identifying the target market segments in which an app will compete.  For enterprise apps, this is typically limited to single business function (e.g. sales).  While there may be a subset of users that have customized versions of the same experience, we avoid creating apps that lose focus by combining multiple unrelated workflows.  For example, if managers want a dashboard for their sales rep app, the manager narrative (focused on analytics and the big picture) should be separate from the sales rep narrative (focused on point-of-sale conversion).

This is often accomplished by creating User Personas that describe an imaginary but likely user for the app.  In order to properly determine Minimum Viable Product, it is essential to know the “80/20 rule” for the target user base.  There are three personas that will assist with effective planning discussions:

  • The Early Adopter – Knowing your early adopter is critical.  Whatever initial revenue or increased productivity the app will drive, the early adopter will drive it and provide the initial wave of feedback that can inform a pivot.
  • The Average User80% of people will use 20% of the app.  That first 20% of features will also deliver 80% of the value created.  Prioritize the high-impact feature that the average user will make use of and defer the rest until later. 
  • The Power User – This user is both useful for building out the longest-term set of possible features and for helping define what type of person will likely not get everything they want.

3 – Summarize the Unique Value Proposition

Once we identify the problem at hand and who it impacts, we quantify the value a solution has the potential to generate.  In enterprise process improvement apps we call this “Impact” – the time or cost savings potential or the potential increase in revenue associated with solving the pains we have identified.  A business case is incomplete without this.  It is easy to gloss over this in the excitement of imagining an app solution, which is why the App Roadmap Workshop is specifically designed to maintain this discipline – we need to know the value proposition before determining the solution.

Once we know the value proposition we are in a position to move from problem to high-level concept.  This is often easiest to do by drawing from apps familiar to the audience, identifying both similarities and differences that we would expect to see. 


4 – Provide the Solution

With a high-level concept and a quantified value proposition, we are ready to brainstorm the solution.  The goal at this stage is to determine what an app would do for each of the pain points identified.  At this stage, avoid over-thinking whether the solutions are separate apps or features combined in a single app.  Instead, focus on the Narrative that uniquely solves the Problem for each User with an identified pain.


5 – Determine the Product Channels

Determining the Product Channel for each app means determining which devices and operating systems will be supported and how the app will be distributed to users.  For web apps, we need to define the internet browsers that will be supported based on the target demographic or based on insights from IT.  For enterprise iOS apps distributed through a Mobile Device Management (MDM) platform this will require an Apple Enterprise Developer Account that may take several weeks to secure – do not delay this process.  Android, iOS, and Windows consumer apps each have a unique consumer marketplace with their own policies for content and distribution as well as unique marketing requirements (description fields, screenshots, etc).  Regardless of which channel is right for the solution to the problem, add to your to-do list to look through the policies, terms and conditions, and Human Interface Guidelines for that channel.  If your personal device or browser is not the product channel for your target market, be sure to look up a few “Top Ten Best Apps” and “Top Ten Worst Apps” to get a feel for trends in design and performance.


6 – Revenue Streams

The next step in the Lean Canvas method is determining revenue streams for the product.  In the consumer mobile app marketplace this is often referred to as “monetizing” and may be a combination of selling a paid app, using in-app purchases, making space for iAd, sponsored content, or selling data that is collected.  When planning web or mobile apps for the enterprise, the App Roadmap Workshop looks at how much cost or time savings or additional revenue (of the potential identified at the Unique Value Proposition stage) can likely be captured by the business given the possibility.  This is part of an overall Balanced Scorecard that ranks the apps the business has identified in order of Return On App.


7 – Understanding Cost Structure

As part of the App Roadmap scorecard, we work with clients to identify the impact of the cost structure of the business processes we will impact.  This can be done using relative estimation by rating a handful of subjective influences:  switching costs, disruptiveness to employees, cost of waiting, and timeline to capture the value created.  For example, if our goal is to improve the in-store sales process to increase revenue, we need to understand any costs associated with training employees to use the app, costs to change the layout or technology infrastructure of the stores, and the extent to which the change will be disruptive in a way that has a negative impact on revenue as the employees adapt to the new process requirements.

When planning a consumer app, fixed and variable costs associated with the longer-term product strategy are important to identify – an information website, hosting fees, product support, and ongoing development costs should all be taken into consideration.


8 – Identify Key Metrics

Because we identified the numbers associated with the problem we will solve, understand the unique value proposition, and have planned our monetization or impact, agreeing on key metrics should be relatively straightforward.  If an app is tightly focused, there is typical “one number” that we want to move and a few numbers that we are certain contribute to our goal.  Secondary metrics are important because our primary metric is often a trailing indication of success or failure and is therefore difficult to use for short-term planning.  For instance, if the “one number” is increased quarterly revenue, the impact of new features may not be represented for several months.  Secondary metrics like increased traffic conversion, increased items per sale, and increased revenue per sale may provide insights more quickly.  

While the business case metrics identify the how we measure success or failure of the app itself, the Lean Canvas method can be repeated on a per-feature basis to prioritize Epics on the app roadmap.  Key metrics at this point are typically called “analytics” and focus on the impact of any given feature on the user.  This may include a combination of time-to-completion, time per screen, crash-free users, and user-provided subjective ratings (i.e. 1 to 5 stars).


9 – Competitive Advantage

While identifying revenue streams or process impact and establishing the key success metrics for an app allows us to prioritize and understand feasibility, identifying “unfair” or competitive advantage is essential for determining how to sustain long-term margins.  At this stage, a Five Forces or Resource-Based strategic analysis can help determine how barriers to entry can be raised and also identify what quality about the new product or process improvement will be difficult for competitors to copy.