kindel.com is no longer at home

September 12, 2020
Leave a comment

kindel.com has been hosted on my home network since 1996. Today, I finally moved it to a modern web platform. This includes migrating an OG Active Server Pages (pre .NET) & SQL Server app I wrote in 1997 for decoding Porsche option codes

By doing this I finally got to turn port 80/443 off on my home network. It’s been bugging me for a long time because it’s a really bad practice as it makes the home network a target for cyber attacks. But that Porsche Option Decoder app has been so popular for so long that I couldn’t just shut it down.

The new site is hosted as an Azure Static Web App using Hugo. The Porsche Option Decoder was re-implemented as an Azure Function using C# instead of ASP and vbscript. The database is simply a flat JSON queried with LINQ. SQL Server was massive overkill, but I did it that way because I actually built the thing in order to learn SQL.

After being alive with 99.9999% uptime for 24 years www.kindel.com has a lot of inbound links in Google/Bing search results. I’m still tracking them down and building redirects. And I have some theming/formatting yet to do, and some content I know people use is not in place, but it’s basically done. Yay.

Note, I’m talking about www.kindel.com here, not my blog at ceklog.kindel.com; that’s been hosted on www.wpengine.com for many years. They do a great job.

I’d love any feedback on the new site. Comment below or @ me on twitter.

© Charlie Kindel. All Rights Reserved.
September 12, 2020
Kindel
Leave a comment

Look Back Quotient (LBQ)

August 28, 2020
3 Comments

Look Back Quotient (LBQ) is a measure of how attractive a car is to the car’s owner. A car with a high LBQ will increase the car owner’s propensity to look back at their car after parking it.

Examples of cars with high LBQ:

1987 BMW 535is E28 "Vlad"

Examples of cars with low LBQ:

© Charlie Kindel. All Rights Reserved.
August 28, 2020
Cars
3 Comments

Broken Windows – Right Idea, Bad Analogy

July 10, 2020
6 Comments

It is well understood that no product is perfect and small issues will always exist. Without an ongoing mechanism to fix those issues, not only do they not get fixed, they pile up.

Having a clear Lexicon and Taxonomy is critical to getting large numbers of people moving forward towards a vision. Having the lexicon be composed of terms that make logical sense, disambiguate, and are memorable is important.

Over the years of building many hardware and software products I’ve developed a lexicon and taxonomy for categorizing the issues that exist in products and identifies the mechanisms required to ensure they get the appropriate amount of focus by teams:

  • Bugs – These are behaviors in code or hardware that are discovered either through quality assurance mechanisms or by customers. Bugs may be discovered before a product is released (best) or after (always bad, but common). Synonymous with Defect. Typical mechanisms: Backlog reviews, Bug triage, Bug severity and priority, monitoring and alarms.
  • Improvements – These are ideas to change product behavior by adding new functionality or changing existing behavior to improve it for customers or increase operational excellence. Typical mechanisms: Backlog reviews, usage telemetry, customer interviews, surveys.
  • Technical Debt – Technical Debt describes the parts of technical implementation where shortcuts were taken to get a product to market in a timely matter. Tradeoffs always need to be made across these dimensions. I found this blog post to be a great primer on Technical Debt and the mechanisms teams can use to manage and pay down technical debt. Typical mechanisms: Technical Debt Backlog, Allocating % of every sprint to Tech Debt, Architecture reviews, Principal Engineering Community.
  • Broken Windows – 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, packaging, documentation, our bug database, our knowledge management system, etc. Typical mechanisms: Broken Window Goals & Reviews.

I’m writing this today because I’ve recently discovered that I have ignored my own biases when it comes to picking lexicon. When I joined Control4 in 2018 I knew the products I would be responsible for had tons of little, annoying issues. That was not a surprise given they were built by a quickly growing company over many years. What surprised me, however, was the lack focus on continually fixing those issues. Not only had our customers become numb to many of these issues, team members had pretty much given up lobbying to fix them. I made it a priority to change the culture to one where these issues got regular focus and teams were not only allowed to fix them but took pride in doing so.

I defined a mechanism, gave it a pithy name (Broken Windows Mechanism) evangelized it, and then drove adoption of it hard. Each quarter I run a review with our teams where I ask, “show me the broken windows you’ve fixed this quarter”. I started small, asking each team to try to fix just three a quarter; by the end of 2019 we fixed over 300 of these issues across all of our products. Some of these fixes are in code. Some are in documentation. Some are in packaging. But collectively, they add up higher quality products across the board, and a better experience for you. Regular audits of the mechanism and customer feedback show it is working and now, in 2020, we’re well on our way to doubling the number of broken windows we fixed last year. We have more work to do, but these issues no longer get ignored, and the team culture has clearly changed in a positive way.

I started using the term “Broken Windows” in this way while leading the Windows Home Server team in 2007. I believe I was influenced by this blog post by Jeff Atwood (Coding Horror): https://blog.codinghorror.com/the-broken-window-theory/, but I also remember reading about the Broken Window Theory in other places. The image in my mind, when thinking about the “real world” concept of broken windows was a lilly-white neighborhood with pretty little single-family homes, white picket fences, and green grass lawns. This is where I failed, and where I’m now embarrassed to admit how skewed my own worldview is, based on my upbringing. I’ve never lived in a big city. I’ve never lived in the type of neighborhood described in the original research that led to the Broken Window Theory. Until a SnapAV employee pointed it out earlier this week, it did not occur to me this term was contentious and that my use of as a metaphor for a product development mechanism was a bad idea.

I created a situation where I led my company with mechanism that is clearly working to raise the quality of our products by fixing tons of those small issues. But I did so with a “pithy phrase” that not only uses a bad analogy but is highly offensive to some.

From end customers and dealers, SnapAV knows there is significant work to do on meeting core expectations from our existing offerings. Customers often tell us our products are not reliable and have failure points. Partners complain about complex time-consuming installations and flaky solutions. Our products must be even simpler to use, simpler to install, performant, and reliable. This requires investment in identifying more bugs and potential improvements. We’ve been using the term “First Mile” for this effort broadly. For our organization, our First Mile goals compel us to build products that are excellent. Excellent products only come from continual improvements, paying attention to everything, even the little things, that contribute to the overall experience.

Thus, I’m going to ask the team to help change the Lexicon used to describe these product issues to something relatable to “First Mile”. For example, “how do you walk a mile?” You start by taking a first step. Or, “How do you ensure your fitness is good enough to run a mile?” You engage in fitness regularly. What ideas do you have for a new term for “Broken Window” that aligns with First Mile strategic imperative?

This sentence is that last I will write where I use the term “Broken Window” as an analogy for the little issues in products that need regular attention; I’ll let you know what the new term is once the team helps pick one.

© Charlie Kindel. All Rights Reserved.
July 10, 2020
Customer & Product, Leadership, Technology & Execution
6 Comments

Kindel’s 3rd Law

March 30, 2020
Leave a comment

Kindel’s 3rd Law – Amazon will enter every existing business, channel, and market. If said business, channel, or market doesn’t already exist, Amazon will try to invent it.

Charlie Kindel – 2019

See also:

Kindel’s Law – Every payment system eventually becomes an anti-fraud system.

Kindel’s 2nd Law – Companies with a subscriptions-based business model eventually behave in ways hostile to that company’s customers.

© Charlie Kindel. All Rights Reserved.
March 30, 2020
Kindel
Leave a comment

Smart Home + PC = Better Working from Home

March 25, 2020
Leave a comment

Since the dawn of time I’ve considered the PC (and related devices like Macs, printers, etc…) to be part of my smart home. For some reason, most traditional smart home offerings have treated PCs et.al. as somehow disconnected.

Sometime after the dawn of time (2004), I built MCE Controller (mcec) as a way of ensuring my home PCs could be as tightly integrated as my whole-home audio system or lights. MCE Controller is a little app you run on a Windows PC that enables that PC to be controlled from a smart home OS (via TCP/IP or RS-232). This made tons of sense when we were building Windows Media Center Edition (aka MCE) which basically turned a PC into a glorified DVR.

I’ve continued to refine MCE Controller. Last fall I added the ability to detect keyboard and mouse movement as a way of detecting that someone is in the room. The idea being, if the PC is being used, the room is occupied and the ‘smart’ lights in the room should stay on. Most motion detectors can’t detect fingers flying on a keyboard and thus without this my damn lights would turn off while I was working.

There are other ways of detecting occupancy, of course, but in my experience the best way is to combine multiple sensors that are as context aware as possible. An IR-based motion detector is pretty stupid, actually. So are under-floor pressure sensors. Someday we may have cameras using video analytics too. And microphones (can you imagine?!?). I bet we’ll see devices that can smell people.

But even with all those sensors, the most robust solution will use a variety of sensors fused together. A smart, smart home OS uses “sensor fusion” to actually really be smart.

It turns out combining one or more IR-based motion sensors with a PC “activity detector” works pretty damn well. I’ve been using this at my office at work, my office at my home in Bellevue, and my home office in my apartment in Sandy, UT since last fall and it’s pretty slick. But not perfect.

In the past few weeks of working almost exclusively from home I’ve found more cases where it was not smart, but pretty stupid. For example, when I’m on a video-teleconference (and actually paying attention) I’m not using my keyboard or mouse. I’m also sitting still. So neither the mouse/keyboard activity sensor, nor the motion sensor “sees me”. So the lights go out.

I found myself on conference calls, regularly having to reach out and move the mouse (or wave my arms) to have the lights come back on.

I realized that there’s another PC-based signal that could be added to the mix: Whether my desktop was locked or not. I religiously lock my PC (Win-L on Windows) whenever I get up from it. I was trained to do this at MS and Amazon where co-workers would punk you if you didn’t. So, at least for me “If PC is unlocked, the room is occupied…mostly.”.

Last weekend I updated MCE Controller to detect whether the PC is locked or not. So now, if the Activity Monitor is enabled, MCE Controller signals my smart home every 25 seconds whenever the desktop is unlocked.

It still senses keyboard & mouse activity, but in reality what I’ve really done is made it so the primary signal is whether the PC is locked or not.

You can download and install MCE Controller v2.2 from here: https://github.com/tig/mcec

It offers plenty of connectivity options that should make it easy to integrate with any home control system. I also have a Control4 OS 3 driver that I can provide to folks who ask (use Issues on GitHub please).

© Charlie Kindel. All Rights Reserved.
March 25, 2020
Coding, Smart Home
Leave a comment

Mechanisms

March 6, 2020
3 Comments

Mechanisms are complete processes built around a tool, owned by a leader, that get adopted broadly and are regularly inspected, and improved to ensure things get done, not because everyone has good intentions, but because the elements of the mechanism structurally force the desired behavior.

“Good intentions never work, you need good mechanisms to make anything happen.” — Jeff Bezos

I’ve written previously about how Good Intentions are Never Enough and why mechanisms are needed, but I didn’t go deep into how to make mechanisms actually work. This post starts to rectify that.

Mechanism

Below are the elements of a mechanism.

Complete Processes

In a complete process, you build a tool, drive adoption of the tool, and inspect the results in order to make course corrections. A complete process has a “virtuous cycle” that reinforces and improves itself as it operates.

Tool

Within the complete process of a mechanism, the tool is the structure that a leader creates in order to implement large-scale change. The tool is what transforms the set of inputs into a set of desired outputs.

Owned

Each mechanism must have an owner. This is a leader (a human being) who defines, drives adoption of, audits, and inspects the mechanism. The owner of a mechanism can change over time, but for a mechanism to work, there must be an owner. 

Adoption

Leaders create mechanisms in order to accomplish things that cannot be done by one person alone. The larger their goals, the more leaders will need to rely on others. Leaders cannot “do” anything without getting others to broadly adopt and implement mechanisms.

Inspection

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 or results of the mechanism and to course correct and improve the mechanism.

Improvement

(this is where Mechanisms get recursive)

A complete process has a “virtuous cycle” that reinforces and improves itself as it operates. The leader that owns the mechanism, based on inspection and auditing routinely improves the mechanism.

Examples of mechanisms

Here are a few examples of mechanisms.

Types of mechanisms

Over the years of designing and driving mechanisms, I’ve found there are multiple flavors. Here are a few common types:

  • Do it Regularly Mechanisms. Every business has a cycle, and we need to regularly engage on topics. For example every year the company needs to go through a cycle of long-term planning, budgeting, and planning for the next year. We define and uses mechanisms to ensure these regularly occurring activities are effective and efficient. For example, an annual Operating Plan or Three Year Planning mechanism. 
  • Ass-u-me Mechanisms. The word Assume stands for “make an ‘ass’ out of ‘you’ and ‘me'”. Ass-u-me Mechanisms ensure the right questions are asked at the right times, the right data is presented clearly, and the right people are aware such that team members aren’t just assuming something, but they know. I also think of Ass-u-me Mechanisms as Details Matter mechanisms because they can ensure all the little details that might get forgotten, get surfaced early and often. Working Backwards Narrative Reviews are an example.
  • Audit Mechanisms. An audit mechanism is a system or process that forces details to be surfaced regularly. For example, in a weekly operational excellence review, use a wheel-of-fortune style wheel to randomly select a project each week where the lead must explain their metrics dashboard. This forces every project to be prepared, but scales because not every project has to be reviewed each week.
  • Behavior Change Mechanisms. A behavior change mechanism can be effective at getting results where an organization has underlying behaviors that need to change. A recent example at SnapAV is our First Mile Mechanism. This mechanism is enabling individuals throughout the organization to take the time to fix little issues that wouldn’t otherwise get prioritized. 
  • Anti-Silo Mechanisms. Organizational structure and geography naturally create silos (parts of organizations that become disconnected from the broader mission). A set of lightweight anti-silo mechanisms can mitigate the negative aspects of these natural silos. For example, a Weekly Release Readiness review where representatives from all parts of the org are required to attend makes everyone aware of what products are about to ship, while also acting as a Ass-u-me Mechanism.

In a future post I plan on dissecting one or more mechanisms I’ve invented that have worked well. Is there a particular mechanism you’d like me to discuss? Comment below.

© Charlie Kindel. All Rights Reserved.
March 6, 2020
Business, Clarity of Thought, Customer & Product, Leadership, Organization & People, Technology & Execution
3 Comments

winprint 2.0

February 21, 2020
2 Comments

Ever since I started programming on an Apple ][+ in 1981, I’ve had a thing for printing. My earliest apps focused on printing and my first money-making endeavor was “Tapes”, which printed casette tape ‘J-cards’ for all the mix-tapes of great ’80s music we made for the girls. Whenever I learned a new programming language or OS, the first app I’d write was Spit, an app for printing my source code all pretty (it “spits” source code out of a printer). Over the years, I wrote Spit for AppleDOS (Apple BASIC), UCSD-Pascal, CP/M (Turbo Pascal), DOS (8086 assembly and C), VAX/VMS (Pascal and FORTRAN-77), and Mac (Pascal).

In 1988, as a college junior at the University of Arizona (Go Cats!), I decided Windows was going to win over OS/2 and I was going to work for Microsoft. I bought Charles Petzold’s Programming Windows and conned my dad into buying me a copy of the Windows 2.0 SDK (which was like $300 back then!). On my amazeballs ALR 386/33 PC I set about becoming a Windows programmer. The first useful) app I wrote was WinSpit. In a rare moment of adulting, I renamed the app WinPrint and listed it on CompuServe as shareware ($25). For over ten years I received $25 checks the mail from folks all over the world. Even better, WinPrint demonstrated to Microsoft I could actually, really write code. So they hired me.

Winrpint 1.54

Several times in the early 1990s I started writing WinPrint 2.0. Each time I had the basics working and realized three things: 1) Nobody cares about printing source code, 3) I’d over-engineered things, and 2) the technology I choose was already dated (e.g. MFC). Two of those abandoned efforts can be found in my GitHub archive here (1992) and here (1994).

Last year (2019) I got a wild-hair to write some code as a way of blowing off steam, and proving to myself I was still cool. It all started with Microsoft releasing the Cascadia Code font. I have a thing for fixed-pitch fonts. It’s weird. Anyway, I installed the font in Terminal and VScode but just looking at stuff didn’t satisfy me. I needed to use the font in anger! So I fixed some long-standing issues in MCE Controller (another app I wrote that nobody uses anymore).

This all led to me re-discovering my old WinPrint 2.0 source code. Reminiscing on how much time I wasted back then, and how effective it was as a procrastination tool, I just had to try again. So I did. And, just to be clear, here’s what I did:

1) I wrote a printing app in 2019-2020. Nobody prints these days. I don’t even print anymore.

2) I over-engineered it. It has a full GUI with print preview. Headers and Footers with Macros. A full command-line interface. It can syntax-highlight over 200 different programming languages. It’s cross-platform. It’s written in C# using the very latest .NET Core. It uses NodeJS and C++ under the covers. And more.

3) I used .NET and C#. Ok, this part I can defend (assuming you get past point #1 and #2): First, I know C# well and it is awesome. Second, no other modern language/app-framework can even SPELL “print”. I tried both Electron and Flutter and both suck when it comes to printing.

So, there you are: I present to you winprint 2.0 (alpha).

I hope you enjoy it.

© Charlie Kindel. All Rights Reserved.
February 21, 2020
Coding, Kindel
2 Comments

Path To Green

February 16, 2020
1 Comment

A Path To Green (PTG) is clear, crisp, and complete statement describing a team’s plan for how to get a project from yellow/red status to green. This post describes the concept and provides some tips on how to be excellent at articulating a PTG.

Organizations that routinely deliver great results hold individuals and teams accountable for delivering those results. Ensuring everyone is clear on the status of projects is key to this (e.g. is a project red, yellow, or green?). More importantly, teams need to have discipline around how they move projects that are a bit off the rails (yellow) or really off the rails (red) back on rails (green). A great “Path to Green” is a key element of this discipline.

None of this works without clarity around what the various status of projects mean. At SnapAV we use the following definitions:

  • GREEN : The Project is on track with risks that are well understood and mitigated. 
  • YELLOW : The Project has encountered some serious unknowns or blockers, but there is a clear Path to Green that should enable the project to hit the current date. 
  • RED : The Project has unknowns or blockers that either make it certain we will miss the date and/or there is not yet an agreed on Path to Green. 

A Path To Green should include:

  1. A clear identification of who (as in the name of a human being) is responsible for each action.
  2. Dates. Dates. Dates. For every action that will get the project back on track, there should be a date. It’s OK for a date to be a “date for a date”, but it’s NOT OK to not have dates.
  3. Clarity on what the criteria is for determining the project is back to green.
  4. If the project is Yellow and trending Red, a clear statement on the criteria (with dates) that will cause it to turn red. And a statement of what will then happen (e.g. “If we go Red we will have no choice but to change the due date”).

Examples

Path to Green:

  • Work with vendor to resolve issue.
  • Verify the problem in the field is fixed.

This is a poor example because

  1. There is no identification of WHO is responsible for each action.
  2. There are not dates that hold the WHO accountable
  3. There is no clarity on what the criteria will be that will result in the project being back on track.

Path to Green:

  1. Sally to get fix from vendor to Doug by noon, 04-Feb.
  2. Doug to deploy the fix to 10 beta sites by 05-Feb and report results no later than 12-Feb.
  3. If results are positive, Sally will update project to Status to Green on 12-Feb.
  4. If negative results come back before or on 12-Feb we will not have enough time for manufacturing and will have to slip the project launch date by at least two weeks to 01-Apr.

This is a good example because

  1. There is no ambiguity around WHO is doing the work and WHEN they will do it by.
  2. Clear criteria is provided for what getting back to Green means.
  3. Clear criteria is provided for what will happen if s*** continues to hit the fan.

Being diligent about project status and getting engineering leaders to think in terms of great “Paths To Green” is key to better execution in product organizations. What tips do you have around driving projects? Please comment below.

© Charlie Kindel. All Rights Reserved.
February 16, 2020
Clarity of Thought, Leadership, Technology & Execution
1 Comment

Tenets

February 10, 2020
Leave a comment

This post was inspired by a recent LinkedIn post by Dave Glick who was apparently the “Godfather of Tenets” at Amazon. Much of the content of this post is from notes I took in a class on Tenets at Amazon. I’ve subsequently used it to teach others how to be excellent at writing and using Tenets.

Tenets are a few, carefully articulated guiding principles for a program or business area. They act as a guide for the team, stakeholders, and senior leaders to align on a vision and decisions. Tenets simplify decision-making and help with being right more often; they can be used as tiebreakers when making tough judgment calls. Tenets are ultimately aligned with our company’s mission and core values. At the same time, tenets are specific to the program or the business area and aligned with its mission and vision.

Pro tip: Don’t confuse “tenet” with “tenant.” A tenant is someone who occupies land or property rented from a landlord. There is a pronounced second N in tenant, but not in tenet.

Tenets appear at the beginning of narratives, to help ensure that the plan put forth by a team is consistent with its beliefs. Tenets are the “Principle” part of a 5P’s Plan.

There are two kinds of Tenets: Foundational and Aspirational. Foundational tenets describe why your team or product exists and describe its intended value for customers. Aspirational tenets describe how a team or product intends to operate, even if it doesn’t do so today.

Tenets are not written in stone. At Amazon, where Tenets are widely used, they usually include the catchphrase “unless you know better ones.” This indicates that tenets are evolving. Teams are encouraged to improve their tenets, perfecting them over time, by welcoming input from others or by learning from writing a narrative or from past decisions that have revealed opportunities for refinement.

I wrote another post on the importance of debating Tenets here.

“You can never spend enough time debating the tenets for a program.” – Jeff Bezos

Tenets for Tenets (Unless you know better ones)

Use tenets to focus your program on delivering value to the customer. In a set of tenets, at least one should describe a program-specific principle for delivering value to the customer. In addition, there is value in considering what each tenet (or the tenets as a whole) would look like when framed as explicitly stating a benefit to customers. Customer obsession in tenets helps your team concentrate effort on what matters.

  1. Be memorable. Being memorable is correlated with effective teaching. Experience shows that the best tenets are memorable. Two attributes of memorable tenets are challenging the reader, and being concise.
  2. Be program-specific, or more specific than that. Good tenets get people excited about what the team does. People outside the team find that the tenets surprise them and give them insight about the team. Don’t make the most common tenet-writing mistake – creating a tenet that applies to many teams and communicates virtually no information, such as, “Our team builds scalable systems.” Each tenet should be as specific as possible while not suppressing innovation or excessively violating other tenets such as being durable.
  3. Counsel. Tenets help individuals make hard choices and trade-offs. A tenet takes a stand by declaring that a team cares more about one thing than another. Tenets guide rather than prescribe detailed actions.
  4. Each tenet has only one main idea. Chiseling a tenet down to a single essential idea makes the tenet memorable and clear.
  5. Find a minimal cover. Each program operates in a space of ideas – its semantic space. A program team’s tenets cover most of its semantic space, using the minimum number of single-idea tenets needed to do so.
  6. Orient for the long term. A tenet is durable and strategic. It may challenge or affirm traditional mindsets, and cause individuals to work in strategic directions they might not otherwise pursue. Tenets survive multiple rounds of goal-setting, achievement, and failure.
  7. A tenet is not something to be done later. A tenet captures an idea that team members could conceivably apply every day. Tenets are present-tense; using the word “will” or “should” in a tenet is common and is almost always a mistake. 
  8. Distinguish rather than elevate. Tenets capture what makes a team different, not what makes it superior.

Why Write Tenets?

Tenets get everyone in agreement about critical questions that can’t be verified factually. For example, is it better to be customer obsessed or competitor obsessed? It’s hard to gather data and prove that one is better than the other. But specifically choosing that the whole company should be ‘customer obsessed’ helps us work together without re-hashing a nuanced debate for every product. Having tenets at many levels (company, org, team, project) can be used to narrow down on the critical, unprovable decisions specific to that org, team, or project.

Tenets keep you honest with yourself. – It’s easy to get caught up in group-think or distracted by the nuances of a specific project and lose sight of the overall goals. By stepping back, setting tenets, and then considering those tenets along the way and only changing them when you step back again will help you keep track of the wider strategy.

Examples of Great Tenets

I think the Tenets on Tenets above are pretty great (they were borrowed from Amazon). Please comment below if you have more examples!

© Charlie Kindel. All Rights Reserved.
February 10, 2020
Clarity of Thought, Writing
Leave a comment

Work Backwards From The Customer

February 4, 2020
6 Comments

At the 1996 Microsoft Professional Developer Conference (PDC) I stood up in front of 8,000 customers and announced what I’d been working on for the previous two years: the Distributed Component Object Model (DCOM). On stage, in front of all those people, we wrote and demoed code running on one Windows 95 PC talking over the network to code on other PCs. This was back in the day when being able to write programs that worked across a network was a very fancy idea™. Every attendee at the conference got a CD-ROM with a beta version of DCOM to try once they got home. This was back in the day when the only way to get software on a PC was to insert a little plastic disc into an actual computer that sat on a desk.

DCOM

A few weeks later, one of those 8,000 customers (yes, only one) called Microsoft Support to point out that the most critical file (ole2.h) required to make DCOM work was missing from the CD-ROM.

You read this right. A team of highly-paid, smart, and passionate engineers spent two years (actually more, because I joined the effort late) pouring our hearts & souls into building this AMAZING TECHNOLOGY and when we literally GAVE IT AWAY to 8,000 developers ONLY ONE noticed it didn’t work AT ALL.

I joined Microsoft right out of college. I was just a kid who wanted to build technologies that lots of people would use. I had no idea what I was doing, so I found people at MS who looked like they knew what they were doing, latched on, and followed their lead. When in Rome, do as the Romans, right?

Before the PDC, six years into my career, I was feeling pretty awesome about inventing this new-fangled technology. After the PDC, when I realized we had built something that NONE of our customers cared about, it was a total punch in the gut. I was devastated.

I vowed then and there to never again build something without starting with the customer. Never again would I start with a technology and THEN look for ways customers might use it. Never again would I “build it, and hope they come.” I finally understood what it meant to be a principled leader; to have a set of rules that dictate how an organization operates. I decided one of MY principles (or tenet; the words are synonyms) would be “always start with the customer, not technology.” 24 years later I’m proud of how I’ve lived that principle.

In 1999 I had my first real chance to lead brand-new product development when I helped found the MS Connected Home Business Unit (CHBU) which ended up building Windows Media Center. I invented my own version of “working backwards” where I asked the team create mockups of the “back of the box” (this was when all products, including software came in cardboard boxes) as a first step in product ideation. We also wrote the review article we’d want our favorite PC Magazine reviewer to write, long before technology was selected. The commercial success of the resulting products proved to me focusing on the customer-centric outcome, before discussing technology (or even business) was right-minded. At Amazon I found everyone, from top to bottom, held this same strong belief and that consistency is a critical success factor for Amazon’s growth and profitability.

We use our own forms of “working backwards” at my current company (SnapAV) and it’s gratifying to see team members embrace them. We are all still learning how to do it effectively, and we’ll all continue to learn and adapt, to make it work for us.

Don’t be shy about commenting on this blog post, if you have questions or ideas on working backwards from the customer.

© Charlie Kindel. All Rights Reserved.
February 4, 2020
Customer & Product, Leadership
6 Comments

MCE Controller V2 Released

October 8, 2019
Leave a comment

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:

https://twitter.com/ckindel/status/1177629706239148032

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: https://tig.github.io/mcec/

© Charlie Kindel. All Rights Reserved.
October 8, 2019
Smart Home
Leave a comment

Have Specific Conversations, not General Conversations

August 9, 2019
Leave a comment

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 https://www.radicalcandor.com/blog/give-humble-feedback/ and this tweet-storm.
© Charlie Kindel. All Rights Reserved.
August 9, 2019
Clarity of Thought, Leadership
Leave a comment

Kindel’s 2nd Law

July 30, 2019
Leave a comment

Kindel’s 2nd Law – Companies with a subscriptions-based business model eventually behave in ways hostile to that company’s customers.

Charlie Kindel – July 2019

Woot! I now have two laws named after me. This law was originally coined in a tweet:

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.

See Also:

Kindel’s Law – Every payment system eventually becomes an anti-fraud system.

Kindel’s 3rd Law – Amazon will enter every existing business, channel, and market. If said business, channel, or market doesn’t already exist, they will try to invent it.

© Charlie Kindel. All Rights Reserved.
July 30, 2019
Business, Kindel, Leadership
Leave a comment

Taxonomy and Lexicon

July 3, 2019
Leave a comment

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.
July 3, 2019
Clarity of Thought, Leadership
Leave a comment

One-Way and Two-Way Doors

June 27, 2019
Leave a comment

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.
June 27, 2019
Clarity of Thought, Leadership, Technology & Execution
Leave a comment

Mental Models

June 22, 2019
Leave a comment

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.
June 22, 2019
Clarity of Thought, Leadership
Leave a comment

Lead Without Authority

June 11, 2019
Leave a comment

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:  https://coachingforleaders.com/influence-without-authority/

© Charlie Kindel. All Rights Reserved.
June 11, 2019
Leadership
Leave a comment

Focusing on users is not Customer Obsession

May 30, 2019
1 Comment

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…).

https://www.flickr.com/photos/findrehabcenters

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.
May 30, 2019
Customer & Product, Leadership
1 Comment

Debate Tenets

May 23, 2019
Leave a comment

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.
May 23, 2019
Leadership
Leave a comment

The Tension is Intentional

May 16, 2019
1 Comment

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.
May 16, 2019
Leadership
1 Comment