MCE Controller V2 Released

I spent some time the last few weekends hacking on a product I first developed in 2004: MCE Controller.

MCE Controller lets you control a Windows Home Theater PC (or any PC) over the network. It runs in the background listening on the network (or serial port) for commands. It then translates those commands into actions such as keystrokes, text input, and the starting of programs. Any remote control, home control system, or application that can send text strings via TCP/IP or a serial port can use MCE Controller to control a Windows PC.

Why? Because I’m insane. And because I needed a distraction to blow off some steam. This tweet-storm explains:

What? A major refresh of almost all aspects.

The key feature is my home control system now has an additional room occupancy sensor: My PC.

The theory is “If the PC is being used the room is occupied”. In practice this works by having MCE Controller monitor mouse and keyboard activity and when detected, send a message to a Control4 driver over the LAN.

Where? Read more details and download it here:

© Charlie Kindel. All Rights Reserved.

Have Specific Conversations, not General Conversations

If you are discussing a topic with colleagues, it’s almost always better to have a specific conversation instead of a general conversation.

General ConversationSpecific Conversation
“We need to figure out how to scrub all open bugs.” Followed by a lot of non-specific debate…“There are 42 open bugs. 42 bugs fit on one screen in Excel. Lets look at them all right now and see if there’s a pattern.”
“Customers are angry. We need to put a plan together to make them happy.”“Our biggest dealers in the NE region are angry about a bug in product X. There are four such customers, and the contact name for each are listed here. Let’s get a plan together for each.”
“Sally is hard to work with.”“Situation: I sent Sally an urgent email last Tuesday on topic X.
Behavior: Sally didn’t reply until today saying she couldn’t fulfill the request.
Impact: The project is now delayed and I don’t trust Sally to be responsive.”

I think you get the point. If not, add a comment!

Tools I use to try to get conversations out of the general, to the specific:

  • Ask: “How many entities are we talking about here?” If it’s less than what can fit on a page or a screen DO NOT HAVE A GENERAL CONVERSATION. Dive in to the data right then and there.
  • If the number of entities in the problem is truly large (hundreds) then suggest a taxonomy that will enable the group to bucketize. In a conversation the other day we were talking about employees in my org. That’s hundreds of people. Someone suggested “how many are managers, how many are engineers, and how many are other?” That broke the problem down so we could get specific.
  • If you can bucketize the entities, prioritize the buckets. Very frequently you’ll find that you can completely ignore two out of three buckets, enabling a specific conversation about a small number of entities.
  • Ask: “What’s a real example of this issue that exemplifies the issue?” 
  • When dealing with people, use the Situation-Behavior-Impact (SBI) model for feedback. See and this tweet-storm.
© Charlie Kindel. All Rights Reserved.

Kindel’s 2nd Law

Woot! I now have two laws named after me.

Kindel’s 2nd Law: All companies where the primary business model is subscription-based eventually predominantly behave in ways inherently hostile to that company’s customers.

This law is a law due to companies’ getting focused on a made-up LTV (lifetime value of a customer), CAC (cost to acquire a customer), and churn rate. Especially churn.

Once a subscription business becomes real for a company, the motions of that company become dominated by a) acquiring debt to pay for ever increasing CAC, and b) trying to reduce churn.

Churn can (theoretically) be reduced by making the product/service better or by making it harder for customers to leave the service. Efforts to enhance the value of the product end up getting harder and harder to justify. Companies default to reducing churn by doing things hostile to customers.

Where’s the one-click unsubscribe button for your cable TV sub? Ever ask yourself why they make it so hard to un-sub?

If you don’t think this law is real, I’m willing to bet you haven’t really studied CAC and churn.

Related: See my 1st law:

© Charlie Kindel. All Rights Reserved.

Taxonomy and Lexicon

How many times have you been in a heated discussion only to find out that the two sides were talking past each other because they were reading from two different dictionaries? I bet you can also remember situations where just a little more structure got everyone aligned quicker.

Creating, explaining, and re-enforcing a strong Taxonomy and Lexicon is a critical skill for all leaders (reminder: everyone in our business is a leader, not just managers). What do I mean by the terms “Taxonomy and Lexicon”?

  • Taxonomy – A classification of the components of a system. A system could be anything from a technical architecture, a strategy, a marketing plan, or an organizational design. Taxonomies are most effective when accompanied by a simple and clear Lexicon. 
  • Lexicon – A list of terms and their definitions; also known as dictionary or vocabulary. When used in conjunction with a Taxonomy, a Lexicon clarifies each element of the Taxonomy. 

Often Taxonomies classify real things. For example a taxonomy for the devices that exist on a home network might be network devices, entertainment devices, security devices, comfort devices, and lighting devices. Sometimes a Taxonomy is ‘virtual’ and is just a mental model, like CBTO (see my tip from two weeks ago on Mental Models). 

Getting up to the whiteboard and sketching a taxonomy will drive more creative thinking and effective debate than almost any other tool in a leader’s toolbox. Articulating taxonomy in narrative form is harder, but even more powerful. Don’t be afraid to amplify a written narrative description with some tight graphics. But be leery of the cases where the only way to express a taxonomy is to draw it. That’s usually as sign that the team has not simplified enough! 

Taking the time, early, to debate and agree on lexicon will ensure clarity of thought and will enable others down the road to get aligned faster. Literally write down (or type) ‘Term – Definition of term’ for each noun that the team is using. Don’t assume people are using the same definition for common terms. Write the definition down in the least ambiguous way possible – it is better to be more exclusive than inclusive. The more inclusive the definition the more vague the definition is and the less likely someone will disagree (and the point is to get people to vocally disagree and debate!). 

If a term is ambiguous, ensure your lexicon includes qualified versions of terms. For example, you’ll be shocked (or not) to find two different companies mean different things when the term “operating plan” is uttered. In one case, it means a yearly business (P&L) plan. In another case, it means an execution (product development) plan. By writing down definitions for BOTH “business operating plan” and “product operating plan” all ambiguity is removed and folks know there are two different (but related) beasts.

I recently read a doc that used the term “domain”, “program”, and “category” interchangeably. It turns out the folks involved viewed these terms mostly as synonyms. By taking the time to write each term down and debate (as a group) the definitions it will become clear there are duplicate terms. The taxonomy can be simplified through a reduction in lexicon. Reducing lexicon is a key skill in being a simplifier vs. a complexifier.

  • Simplifier – A leader who demonstrates effective skills in reducing complex topics and systems to their core essence. Routinely brings others along, Delivering Results, by creating and applying simple Taxonomies and Lexicons. Simplifiers raise the bar for what it means to Invent and Simplify
  • Complexifier – A leader who has not mastered the skill of simplification; someone who tends to make topics more complex than they need to be. Complexifiers struggle to Deliver Results and do not exemplify the Invent and Simplify leadership principle. 

Finally, great leaders re-enforce clear taxonomies and lexicons repeatedly over long periods of time. Just because the Taxonomy and Lexicon was agreed to early on, does not mean the job is done. Over time, be brutally consistent in using the correct definitions yourself and holding others to doing so (“Hey, Sally, you just said Function. According to our agreed lexicon, I think you meant Program.”). Use a wiki to document these things and link to them regularly.

© Charlie Kindel. All Rights Reserved.

One-Way and Two-Way Doors

Effective decision making starts with understanding, in the long-term, very, very few things actually matter. The vast majority of the decisions made day-to-day are either minutia or easily reversible and can be made quickly.

However, a small number of things (about 1 in 10) matter a lot (in the long term) and are worthy of serious pondering, discussion, investigation, investment, and decision making. Back when I was at Microsoft, a mentor introduced me to the pithy phrase 90% of the decisions you make don’t matter. When I got to Amazon I discovered another way of saying the same thing: One-way and Two-Way Doors.

Instead of articulating this in my own words to help you get your head around this fundamental leadership concept, I’m just going to quote Jeff Bezos from the 2015 and 2016 Amazon Shareholder Letters (which, BTW, are fantastic reads):

“Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation.” 

“But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal two-way door decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. These decisions can and should be made quickly by high judgment individuals or small groups.”

“As organizations get larger, there seems to be a tendency to use the heavy-weight decision-making process on most decisions…The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention.”

 “Most decisions should probably be made with somewhere around 70% of the information you wish you had. If you wait for 90%, in most cases, you’re probably being slow. Plus, either way, you need to be good at quickly recognizing and correcting bad decisions. If you’re good at course correcting, being wrong may be less costly than you think, whereas being slow is going to be expensive for sure.”

You can tell a one-way vs. two-way door decision by answering these questions: 

“What if you’re wrong? Can you go back to the previous state at all or go back without serious consequences?”

Examples of one-way door decisions:

  • Selecting a processor architecture for the next generation of Control4 controllers and touch screens. Deciding on the processor and chip set and associated tool chain is not reversible without a complete reset. 
  • Making a go-no-go decision on shipping a new product under development, e.g. we recently did this with OS 3. Once you ship a product to customers, you can’t take it back. If your specification of Minimum Lovable Product (MLP) is isn’t lovable enough, or you haven’t fixed the right bugs and you still launch you’re screwed. 
  • Hiring someone full-time. 

Examples of two-way door decisions:

  • Picking the default background for the Control4 OS 3 customer experience. As long as the software architecture enables us changing it later (see question 3 below), this is easily reversible with a software update. 
  • Hiring a contractor (with a clear, time-bound, statement of work and strong supervision, of course).

Here are some questions leaders should regularly ask:

  1. Are we being intentional in identifying which decisions are one-way and which are two-way?
  2. Are we using all tools available to us for driving clarity of thought in making one-way doors? See my blog post on some of my favorite tools here
  3. Are we inventing ways to turn one-way door decisions into two-way door decisions? For example, inventing ways to get closer to the continuous integration/deployment (CI/CD) ideal in product development (see the 2nd example of a one-way door above).
  4. Do the right owners have the autonomy they need to make two-way door decisions?
  5. Are we actively looking for and identifying and correcting bad decisions? Do we ask the 5-whys and then engineer something that corrects the underlying error (e.g. Control4’s Engineering of Error Corrections (EEC)s or Amazon’s COEs)?
  6. Are we applying positive re-enforcement to teams to encourage autonomy and ownership of two-way door decisions?

Relevant Amazon Leadership Principles:

  • Invent and Simplify
  • Are Right, A Lot
  • Deliver Results
  • Think big

More reading:

© Charlie Kindel. All Rights Reserved.

Mental Models

You’ve probably noticed people you work with who are effective at leading can frame complex ideas simply. They’ll lead conversations like this:

“Well, I think there are three things we should focus on, not 15, and they are…”

“Folks, I think there’s another way of looking at this problem. What if we viewed the problem through these four lenses…”

A key to doing this effectively is being conscious about the concept of Mental Models. I blundered through a large part of my career not being overtly conscious of the concept. But once a mentor coached me on utilizing them intentionally I quickly found I was able to be much more effective driving debate and getting people and organizations aligned.

“A mental model is an explanation of how something works. It is a concept, framework, or worldview that you carry around in your mind to help you interpret the world and understand the relationship between things. Mental models are deeply held beliefs about how the world works.”

James Clear

There’s no shortage of good Internet content on Mental Models. I encourage you to search yourself, but as I sat down to write this tip, I immediately found this post which is a solid (if a bit academic) primer. This post is also good.

You can invent your own Mental Models. For example, I developed a Mental Model that has helped me navigate building technology products at scale. I call it CBTO. It provides a great way to reason about the work we do everyday to build and sell fantastic products. See my primer on CBTO here.

You probably already use Mental Models and not realize it. For example, Control4 employees probably already use the Mental Model of our primary customers: Control4->Dealer-Customers->End-Customer. We sell products to dealer-customers who sell them to end-customers.

The tip here is to learn and practice skills for being conscious and thoughtful about the mental models you use. An example of such a skill? Get good at writing your Mental Models down on paper such that others can understand and adopt them.

What are some of your favorite Mental Models? How are you going to apply them next time you’re debating a topic with a colleague? Where’s the wiki page you’ve written that describes the mental models to others?

© Charlie Kindel. All Rights Reserved.

Lead Without Authority

There are two forms of influence in the world:

  1. Influence by authority
  2. Influence without authority

When a ‘boss’ (a manager or someone with a big title) attempts to influence change or drive action using only their authority, it is rarely successful in the short term, and never in the long term. “Because, I told you so” may work a few times on a kindergartner, but doesn’t inspire confidence or long-term results in the business world.

“You do not lead by hitting people over the head — that’s assault, not leadership.” – Dwight D. Eisenhower

Instead, the best leaders (whether or not they have authority) learn how to use non-authoritarian skills to influence others. The worst managers (and people with big titles) just boss people around.

Some of the Amazon Leadership Principles inform the skills required to be great at influencing without authority. For example:

  • A leader who learns to Dive Deep and stay connected to the underlying data or technical details of a problem, can propose a solution based on facts. Facts trump opinions.
  • People and groups respond better to leaders who listen attentively, speak candidly, and treat others respectfully. When a leader doesn’t do these things, or is afraid of ‘being proven wrong’, people will lose trust in them and thus their influence will diminish.
  • Bold ideas that are clearly articulated motivate people. Leaders who are good at thinking big can use those skills to influence others to follow their lead.

In thinking about this tip, I found this blog post on the Internet. It’s worth a read for more tips on how to influence without authority:

© Charlie Kindel. All Rights Reserved.

Focusing on users is not Customer Obsession

Let’s talk Customer Obsession and how it is different than user obsession.

My definitions:

  • Customer: An individual (or entity) that pays you, directly or indirectly, for value you provide.
  • User: An individual that is forced to use something you provide.

Users fall into three buckets 1) people unhealthily addicted to something (heroin), 2) employees forced to use something in order to do their job (IT systems), or 3) people who are products of services that sell them to advertisers (Facebook, Google, etc…).

Customer Obsession means you explicitly avoid making people into users. While we should aspire to drive virality in our products, customer obsession means we never aspire to make that virality addictive. The best IT products are built by teams that treat the people who end up using the products as though they were the ones actually paying the bills. I see that Google is now charging for a premium YouTube service. I find it outrageous that a product would be willing to actually pay the company that is selling it money.

Let’s endeavor to treat the humans we build products for as customers, not users. Be more Customer Obsessed by striking the word “user” from your vernacular. It’s Customer Experience (CX) not User Experience (UX). When you read a doc where someone has used the word “user” or “end-user” challenge them on it. Are they explicitly trying to drive an unhealthy addiction? Are they expecting to force the experience on someone? Are they treating humans as products to sell to someone else, like an advertiser?

P.S. I’m not alone in this view. See this eloquent blog post by Jack Dorsey, CEO of Square.

© Charlie Kindel. All Rights Reserved.

Debate Tenets

If you read my ancient blog post “the 5Ps” (Purpose, Principles, Priorities, People, Plan) you’ll see I’ve long thought having a set of guiding principles for any project is important.

At Amazon I learned there was a synonym to the word principle: Tenet.

I’ve heard Jeff Bezos say repeatedly “A team can never spend too much ime debating their tenets.” My team at Control4 is likely tired of me repeating this mantra. Why is debating tenets so important?

First, debating (and writing down) tenets ensures everyone is in agreement about critical questions that can’t be verified with data or facts. For example, should we build a new Control4 lighting feature centered in the cloud or on-premise? Because our lighting team has debated and agreed on the following tenet, the answer is clear:

On-premise compute comes first. Lighting is a mission-critical capability for our end-customers, requiring low-latency, and resiliency to Internet outages. As a result we choose to invest in on-premise vs. cloud-based infrastructure for our Lighting products.

Second, tenets enable intellectual honesty. The topics around product development can be complex. There’s a tendency for the team trying to ship something to focus on the trees and not the forest; to get mired in the details, losing sight of the overall goal. The best tenets are oriented for the long-term and when a team steps back and debates tenets they create a framework that can be used later, when the ‘trees are closing in’, to keep track of the broader strategy.

The best tenets are memorable, with pithy descriptions. They are specific and not “motherhood-and-apple-pie”. Great tenets take a stand; you know you’re debating a good one if someone in the room has a negative reaction to it. Tenets are relevant today, but are oriented towards the long term; they rally around things that will always be true for customers. If a tenet covers more than one idea, break it into multiple that individually cover a single, essential idea that is memorable.

Here’s another example from Control4’s Comfort team:

We stand on the shoulders of giants. We recognize controlling the climate in a home is not a core competency for our company and for the Comfort program we choose to focus on integrating versus inventing. For example, we white-label a quality ODM thermostat device vs engineering one ourselves and ensure our interoperability APIs work great with the popular 3rd party smart thermostats.

If a set of people debate and then get aligned on tightly written, pithy, guiding principles (tenets) early, all decision making down the road becomes far easier.

Extra-credit if YOU can articulate what Amazon Leadership Principles get exemplified when tenets are utilized.

© Charlie Kindel. All Rights Reserved.

The Tension is Intentional

It is no accident many of the Amazon Leadership Principles seemingly contradict each other: they were carefully selected and crafted to encourage leaders to be thoughtful about the gray area.

E28 Clutch Over-center spring

Bias for Action vs. Think Big represent favorite example of this tension.

Bias for Action – Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.

Think Big – Thinking small is a self-fulfilling prophecy. Leaders create and communicate a bold direction that inspires results. They think differently and look around corners for ways to serve customers.

On one hand, Bias for Action tells us to move quickly without perfect information; to take short-term risks. On the other hand, Think Big tells us to take a long-term view, cover all the bases, and consider audacious and unconventional ideas. In the moment, you as leaders will discover these are clearly at odds with each other. Great leaders practice testing this tension and build skills for navigating it. For example, get in the habit of always asking:

“Is this decision a two-way door we just need to move quickly on, or does this decision have unambiguous long-term impacts that should be carefully considered?”

What other examples of this intentional tension resonate for you? Comment below.

PS, If you love lexigraphy as I do, head down the rabbit hole of the difference between the words “intention” and “intension”.

© Charlie Kindel. All Rights Reserved.

Good Intentions are Never Enough

Everyone has good intentions… Everyone WANTS to do the right thing (e.g. read the doc sent out by email the night before). But good intentions are never enough.

Stuff doesn’t get done based solely on people’s good intentions. Change can’t happen based only on good intentions. What you need is a way to mechanize people’s good intentions.

“Mechanisms” are the way. A Mechanism is complete processes that ensures things get done. A complete process is a ‘virtuous cycle’ that reinforces and improves itself as it operates. Like a snowball rolling down hill.

Within a complete process is a tool. The tool is the structure that a leader (everyone here’s a leader) creates in order to ensure stuff gets done or change happens. The tool is what transforms a set of inputs into a set of desired outputs.

Next you need adoption. Leaders cannot “do” anything without getting others to broadly adopt and implement mechanisms. So strong leaders actively encourage and reinforce adoption of mechanisms.

But nothing’s perfect. No mechanism is perfect. So leaders need to be able to see if a mechanism is being adopted and to understand if the use of the mechanism is leading towards the desired outputs. Inspection requires leaders to *audit* the output and course correct.

Leaders use audit mechanisms (yes, this gets recursive) to effectively dive deep into how the other mechanisms are working (or not) and drive improvements.

Pithy recap: Don’t rely on good intentions. Instead invent complete processes based around a tool and drive adoption. Inspect and audit to improve over time. Repeat.

The best non-internal-to Amazon resource on Mechanisms I’ve found is this AWS Summit Talk.

© Charlie Kindel. All Rights Reserved.

Have Strong Opinions, Weakly Held

This week’s tip relates to the Are right, A Lot leadership Amazon Leadership Principle:

Leaders are right a lot. They have strong business judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.

A great mnemonic for remembering how to get better living the Are right, a lot LP is: Have strong opinions, weakly held. This term was coined by Stanford University professor Paul Saffo.

“Allow your intuition to guide you to a conclusion, no matter how imperfect — this is the ‘strong opinion’ part. Then –and this is the ‘weakly held’ part– prove yourself wrong. Engage in creative doubt. Look for information that doesn’t fit, or indicators that pointing in an entirely different direction. Eventually your intuition will kick in and a new hypothesis will emerge out of the rubble, ready to be ruthlessly torn apart once again. You will be surprised by how quickly the sequence of faulty forecasts will deliver you to a useful result.” – Paul Saffo

However, having strong opinions (weakly held) is necessary, but not sufficient. For example, CX designers and PMs know that I get pretty bent out of shape when I see a UI mockup with ‘placeholder’ text in it like this:

The PM and designer that mocked this up are both very smart with tons of real experience. They should have taken a few more minutes to make their best guess, no matter how imperfect, for what the text in that placeholder would be. If they had we could have debated it (or moved on). Instead we rat-holed.

Take a stand. Articulate it. Encourage debate. Change your mind if the debate is convincing. Not doing so will prevent you from ever raising the bar for being right, a lot.

“People that are right a lot admit they are wrong quickly.” – Jeff Bezos

For a deeper read on “Have strong opinions, weakly held” check out this blog post:

© Charlie Kindel. All Rights Reserved.

Everyone’s a Leader

The word leader is defined as:

leader noun
a person or thing that leads.

The word leader is not a synonym of manager. Everyone is a leader. It’s entirely possible for a people manager to be a poor leader (which would be bad). Likewise an individual contributor who’s a great leader might be a horrible people manager (which would be good as long as he/she stays an individual contributor). The only question is how well each individual leads. The Leadership Principles provide a framework for all of us to become better leaders.

That said, in practice LPs can play out differently depending on your role. Let’s use Learn and Be Curious to illustrate the difference between an individual contributor and a people manager:

Learn and be curious
Leaders are never done learning and always seek to improve themselves. They are curious about new possibilities and act to explore them.

Given this LP, as an individual contributor do you…

  • Take time to learn something new or understand your systems better; read a book, watch a training video, build a PoC?
  • Actively mentor someone else?
  • Take on responsibility outside your area of expertise to stretch and grow?
  • Actively seek out advice and feedback on your performance from peers or customers?

And, as a people manger, do you…

  • Create space and time for your employees to explore and learn?
  • Focus on how you arrived at the results rather than the results themselves?
  • Support your employee’s moving to other teams so they can learn new skills?
  • Encourage risk-taking by engineers on your team, and support them in doing so?

I’ve found asking the question “what does <particular LP> look like in my role?” is a great way to firm up my own thinking about the Leadership Principles. Give it a try.

© Charlie Kindel. All Rights Reserved.

Have a Plan (With Dates)

I’ve written a lot on the importance of having a plan. This week’s Leadership Principle tip doubles-down on that.

Consider a status update:

Bad: “The team will investigate the issue.”

Good: “The team will complete the investigation of the issue by Tuesday afternoon and will share a plan for how to fix it by Thursday.”

The Good version of this does a few things:

  • It enables accountability on the next steps.
  • It conveys the appropriate sense of urgency.
  • It ensures the work to investigate the problem is not open-ended, further enabling accountability.
  • It conveys ownership.

My good friend Dwight D. Eisenhower was famous for saying “No battle was ever won according to plan, but no battle was ever won without one.”  I’d like to be famously known for saying “A plan without dates is fantasy.“

By putting in just a *little* more effort & being planful (with dates) you enable the entire organization to have confidence the right things are happening. This leads to better delivery of results and earns trust.

© Charlie Kindel. All Rights Reserved.

How Meeting/Not-Meeting Goals relates to Earn Trust and Insist on Highest Standards

This week’s Leadership Principle tip is about how setting goals, and holding yourself accountable, relates to Earn Trust and Insist on Highest Standards.

At Control4 we set goals each year a part of our annual operating plan. One goal I took this year was for every program in my org to fix three Broken Windows each quarter. Broken Windows are defined as:

A bug, defect, or missing feature directly impacting the customer experience that won’t normally get fixed due to resource constraints. The best examples of Broken Windows are things “we’ve known about forever, but just kept pushing down the priority list.” Broken Windows exist in products, code, our bug database, our knowledge management system, etc… The idea is to take pride in fixing them so the neighborhood is a great place to be. See:

We ended Q1 last week I had to set the status on this goal. We didn’t meet the goal so I had to set it to “Did Not Meet” (which always means RED as well) was painful for me. I have a pit in my stomach seeing a big RED blob in my list of 2019 goals. I’m going to see this every week for the rest of the year. It is awkward and embarrassing.

The reality is the organization came really, really close to hitting this goal. All but three teams met the goal, and those that missed only missed by one fix! Plus in some cases we fixed far more than three! The goal was clearly defined, and *I* did not meet it. So I have to set the status accurately.

I could have done more in the last few weeks of the quarter to drive the team to be more buttoned up on their goals that roll up to this one. I could have pushed PMs to take a hard one off their list and add an easier one. I also failed to fully document the Quarterly Broken Window Goals mechanism and thus there was some confusion about what it mean to fix a BW (the BW must be fixed from the customer’s perspective). See how this relates to Earn Trust with the italic-bold below?

Earn trust – Leaders listen attentively, speak candidly, and treat others respectfully. They are vocally self-critical, even when doing so is awkward or embarrassing. Leaders do not believe their or their team’s body odor smells of perfume. They benchmark themselves and their teams against the best.

I will only feel bad about this goal result until I’ve taken the steps to ensure I CAN’T feel bad about it NEXT TIME. This morning I spent 20 minutes creating the Broken Window “user’s manual” wiki, for example. This way, when we hold the Q2 Broken Window review meeting, I will be reminded to ask more questions and audit teams’ goals in such a way that we hit the goal.

Insist on Highest Standards – Leaders have relentlessly high standards—many people may think these standards are unreasonably high. Leaders are continually raising the bar and driving their teams to deliver high-quality products, services, and processes. Leaders ensure that defects do not get sent down the line and that problems are fixed so they stay fixed.

I hope this helps. Please feel free to comment if you have thoughts or questions.

© Charlie Kindel. All Rights Reserved.

Dive Deep != Micromanaging

You’ve said it. You’ve heard others say it. You are not quite sure how you feel about it.

“So-and-so is a micro-manager. He/she’s always in my shorts and doesn’t let me just do my job.”

This week’s Leadership Principle tip may help you navigate this common meme more effectively.

The following has been my pinned tweet for the past year:

“The more details you know, the better questions you can ask. The better questions you ask, the faster everyone gets clarity of thought. Better clarity of thought leads to better decisions. By everyone. Essentially.”


Great leaders know the details. They are willing to roll up sleeves, dive in, and get their hands dirty. Folks confuse dive deep with micro-managing. This is not accurate.

Diving deep is about understanding the details which enables robust debate, articulate questions, and clear thinking. Better debate, people asking great questions, and clear thinking mean better decisions that stick.

Diving deep is about setting up auditing mechanisms where leaders can be closely connected to the details without being overwhelmed and without needing to control minutiae. Auditing is a skill where leaders who exemplify dive deep test assumptions then step back to let owners own what they own.

BMW E28 Seat Gearbox Detail

The Dive Deep LP is highly coupled to Ownership. Leaders who demonstrate strong Ownership are great at proactively helping peers and managers dive deep into areas. Instead of saying “you’re micromanaging me” a strong owner says “let me figure out how to get you the details you need”.

So next time you find yourself feeling like someone is micro-managing you, consider how you can dive deeper into the details that matter to the areas you own and pro-actively helping the “micro-manager” get those details.

© Charlie Kindel. All Rights Reserved.

Just Right Porridge and Leadership Principles

Last week I wrote about Have Backbone, Disagree and Commit. This week the topic is about how to get the balance right when living Leadership Principles.

Just as it is possible to not live a leadership principle (under-index), it is possible to over-do them. The key is to find the balance and be like mama bear’s porridge: Just Right.

“Moderation in all things” ― Aristotle

Yes, it is possible to over-do even Customer Obsession. A great way to be thoughtful about this is to apply a “Just Right/Over/Under” taxonomy. Consider this example for Customer Obsession:

Making decisions:

  • Just Right: You are dedicated to meeting and exceeding customer expectations. You seek customer feedback and use it to make improvements.
  • Over: You make too many exceptions to best practice processes based on individual customer feedback.
  • Under: You don’t consider customer needs in decision making, instead focusing on technology, strategy, or internal operations. You fail to put the customer experience first.

Designing products or features:

  • Just Right: You focus on articulating the optimal customer experience early and then work backwards from that to determine how to make it true. You deliver value in increments and regularly assess how the product delighting customers.
  • Over: You over-engineer the product, trying to make it meet all customer demands at once.
  • Under: You build something hoping customers will come. You fall in love with a programming language, technology, or process.

As an aside, the internal Amazon wiki has an amazing set of pages for each Leadership Principle that gives a dozen or so examples like the above for each LP. The examples above are from my memory. Last year I sent Jeff Bezos an email requesting that he publish those pages publicly. I mean, if he really is serious about enabling other companies to copy the Amazon way as he’s publicly said, this would be a great step. I never got a reply.

© Charlie Kindel. All Rights Reserved.

Have Backbone, Disagree and Commit

We’ve decided to adopt Amazon’s Leadership Principles at Control4. For a while we debated creating our own, or modifying Amazon’s, but in the end we decided just running with Amazon’s as-is would work best.

Last week I sent a mail to my org pointing out some bar-raising behaviors for “Hire and Develop the Best”. I got several replies from employees encouraging me to share more ‘tips’ on LPs. So I’ve added a reminder to my calendar to write an internal blog post each week. This week I wrote a post on what it means to Have Backbone, Disagree and Commit.

Photo credit Kai Schreiber

After posting it, I decided to share it here too. So here you go.

The actual Leadership Principle reads:

Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

This Leadership Principle actually combines two principles that go hand-in-hand. First there’s the “Have Backbone” part and then the part about disagreeing, but committing anyway.

Having backbone: We all find ourselves in situations where we don’t fully agree with a proposed plan. In these cases, we should think like an owner (see the Ownership LP) and argue (ideally with data and strong anecdotes) our point. If we are unable to affect the decision, the next step is to meet with other stakeholders. We need to ask questions so we truly understand the problem and be open to the possibility that we may not have all of the information that went into the decision (e.g. highly confidential info). We must listen to the other stakeholders’ points of view and share ours openly and respectfully.

After considering the data and other points of view, if we still have concerns, we can escalate. Deciding whether to escalate or not should be what I call ‘a highly considered decision’. Over escalating is a sure way to demonstrate we have poor judgement (we’re not Right A Lot). We escalate only if we truly feel the decision is not in the best interests of the company. We use data, facts, and strong anecdotes to support our opinions before we escalate. Escalations are not effective unless they include alternate proposals; we must be solution-oriented.

It’s hard to know when to give in. This is what good judgement and wisdom are
all about (see the LP Are Right A Lot). Sometimes you just need to fold like a cheap lawn chair. Other times you need to keep fighting. The trick is getting good at judging the situation. I wrote a blog post long ago titled “90% of the decisions you make don’t matter” that might help you figure out whether to “stand or fold”.

But once a decision is made by the group, we are all expected to support it wholeheartedly and commit 100%.

This is where Disagree and Commit comes into play. D&C is what happens after a decision has been made. Even if we originally disagreed (and may still disagree) we all get behind the plan and commit to it.

People who raise the bar for Disagree and Commit openly show support and commitment to the plan, even though they may not have originally been aligned with it. They avoid statements like “I’m only doing this because I was told to”, “I did not agree with this and tried my best to convince folks otherwise”, or “management said”. They regularly get everyone aligned with the decision and then re-enforce their commitment to the plan (even if they still disagree).

Disagree and Commit applies to everyone, including individual contributors and
managers. Exhibiting this principle is particularly important for people managers because they are responsible for effectively communicating and streamlining information from their team to upper management and vice-versa. As a result, you need to be cognizant of how you communicate these decisions to your team. As a people manager, what you say or write, carries additional weight and it is your responsibility to exhibit conviction in your communication. If you don’t disagree and commit, your employees will lose trust in you and won’t execute effectively.

If you have questions or comments about this topic, please feel free comment below.

© Charlie Kindel. All Rights Reserved.

Kindel’s Law

I’m not sure how this law thing works. But I’m jealous of folks like Moore, Atwood, and Shannon. I think everyone should have a law named after them.

In 2013, when I was tasked with build Amazon’s equivalent of ApplePay I had an epiphany. After studying all of the payment systems going back to the invention of currency up to credit cards, Amazon’s payment products, Bitcoin, PayPal, and so on, I noticed they all ended up being far more about defending against fraud than anything else.

This was certainly true at Amazon where the largest amount of resources, the most energy in reducing costs, and the place where the highest IQ was applied was on fraud.

So I coined Kindel’s Law:

Every payment system eventually becomes an anti-fraud system.

-Charlie Kindel, 2013

So there you go. My law is now on the Internet. It must be true. Someone please write a Wikipedia article.

Update! I now have two laws named after me. See: Kindel’s 2nd Law

© Charlie Kindel. All Rights Reserved.

A FAQ About Frequently Asked Questions

1. What’s a FAQ?

A list of questions with answers written in English are a great way to drive clear thinking on all the stuff that surround the central idea presented in a narrative. This ‘stuff’ includes things like strategy, execution, technology, business, and resources.

The main text of any narrative should be so clearly written that FAQs are unnecessary. To accomplish this, make a list of ten questions a reader might ask. Answer them. Then determine if those answers should be integrated into the main text or handled verbally in the review meeting. Put the answers that don’t belong in the document but might be needed during the meeting (verbally) in a back-pocket appendix. Repeat. By doing this, the author is forced to do the critical thinking to generate more questions and answers.

As the author does this, she or he will find questions that simply can’t be answered cleanly in the main document or are too critical to leave for the back-pocket appendix. These become FAQs in the FAQ section of the narrative.

2. Where should FAQs appear in a document? 

FAQs should generally come at the end of the document, after the prose. 

3. Should FAQs be numbered? 

Yes, you should number them. Numbering FAQs makes it easy for readers to call out which FAQ they want to make a point about. If there are multiple sections of FAQs in a document (e.g., a Customer FAQ and an Internal FAQ), make sure the numbering is continuous across all sections. This way readers can precisely call out a specific question. (The FAQs in this wiki would be numbered if confluence made it easy to do so. It doesn’t).

4. How many questions can be asked and answered in each FAQ? What if the question is complicated? 

Every FAQ should be comprised of a single question with a direct answer to that question (and only that question). Ask and answer only one question at a time. For example, the question I’m answering right now is a horrible example (intentionally), because it asks two questions. The second question (what if the question is complicated) makes writing a simple answer impossible. Figure out how to simplify the questions so there’s only one question, or just make two FAQs. 

5. Is a FAQ a required element of a narrative? 

A perfect six-page narrative would answer all the readers’ questions in the main body prose. However, often there are aspects where the FAQ format is the only way to simply and clearly answer a question. 

In fact, over-using FAQs can lead to sloppy writing, which results in less clear thinking. 

Some narrative forms (e.g., Working-Backwards (WB) narratives) have a set of required FAQs. 

6. What’s the trick for identifying good FAQs?  

Here are a few tips for identifying good FAQs: 

Seek the truth: Ask yourself what questions about the topic would you least like to answer verbally. Anything you come up with is likely a good candidate for a FAQ. 

Imagine the most hostile (or rude) thing a reader might ask. A classic is “Why are we wasting time on this idea?” 

Consider the obvious or negative cases. For example, if your narrative describes a new product and target customer segment, a FAQ might be “What customer segments will this product NOT be attractive to?” 

Sometimes there is a set of standard FAQs that every narrative of a type (e.g. a WB narrative) must answer (e.g. “What geographies will this product be launched in?”) 

7. What tips will help keep the questions simple? 

Less is more. The fewer words in your question, the better. Long questions are hard to parse and read. 

Ask the question. Seriously. If you find you are having trouble phrasing the question simply, find another human and verbally ask them the question. Often this will cause you simplify how you ask it.  

8. Is there a trick to answering only one question at a time? 

The trick is to only ask one question at a time (I added this because I have found it incredibly common for writers to stumble on this obvious point). 

Should questions and answers use proper English (grammar, spelling, and punctuation)? 

Yes. It is important both the question and answer use proper English to accurately and concisely answer the question. 

9. Does the order of questions in a FAQ matter? 

The order in which things are presented always indicates an order. We wouldn’t use the word ‘order’ if there wasn’t an ordering. More important things should be presented before less important things. Related questions should be kept together. If you have another heuristic that would determine the order for your FAQs then use it (but you better explain it explicitly and clearly to the reader). 

10. How many questions can be in a FAQ? 

There is no limit to the number of questions in a FAQ. A well written six-page narrative (with included FAQs) can be read by most careful readers in 20-30 minutes. For a 60-minute review meeting, this leaves 30 minutes for discussion. Six pages is the maximum, not the ideal. A one-page document that describes a simple solution to a complex problem clearly is vastly superior to a six-page document that does the same thing. 

Start with a goal of having no more than ten FAQs works. 

11. Can an entire narrative be structured as a FAQ? 

I’ve seen it work for narratives that explain a technique, like in a blog post describing how to write great FAQs. However, FAQs are not a great way to describe a concept such as a new customer experience or product plan. For those, actual narrative (words in sentences that make up paragraphs that flow from beginning to end) is far more effective primarily because writing actual prose is what forces the writer to really think clearly. 

12. When reading a FAQ, should I carefully read the questions? 

The author of the document wouldn’t have written the question if they didn’t think it was important. So, yes.

13. What’s a FAQAFAQ?

A FAQ about Frequently Asked Questions. Of course. Credit @ctpierson.

© Charlie Kindel. All Rights Reserved.