Why addressing errors effectively lies at the heart of team performance

No one wakes up in the morning excited to go to work and look ignorant, incompetent, or disruptive. While it's not true of everyone, I think it's fair to say that anyone who gets a job wants to be there and usually wants to do well--for the purpose of self-respect. Look at how elated most people are when they accept a job after getting an offer. It's when they enter into the "systems" at a particular company, that everything usually takes a left turn.

Modern Times (1936) trailer: capturing the essence of managing

In established companies, it's sadly common for employees to be habituated in a context of fear of failure. Especially if there is a lot of pressure from management to perform at a high level. There are ambitious goals, often coupled with a lack of clarity on how they will be achieved. In practice, employees focus on looking busy (however that is defined). They end up fearing failure, of not living up to expectations.

As a manager, there is a fine line to draw here. You don't want to set the bar too low and cause everyone to just slack off. The starting point here is one of psychological safety; according to the research, this is one of the main factors driving high performance in teams. In particular, how you handle errors, failures, or surprises in a way that keeps the team accountable while enabling them to believe that they will be listened to--if they speak up.

Common error types

According to Amy Edmondson in The Fearless Organization, there are 3 different types of errors which happen professionally, and their meaning is largely driven by context:

1. mechanical errors in a highly repeated process that just need to be minimized in frequency: this is what Modern Times parodied
2. interaction errors which result from highly complicated relationships, especially in a larger company
3. thwarted expectations around a goal in the context of experimentation, often a surprising result of an experiment

A large part of the challenge of large companies is that they treat all errors as if they were all #1 by default. This approach may be tied to political gamesmanship. But not everything is just a deviation from a standard (regardless of who actually decides and imposes that standard). Especially in knowledge work like software, where completing something requires you to learn something you don't know up front. Edmondson quips, “For knowledge work to flourish, the workplace must be one where people feel able to share their knowledge!”

Photographer: Sarah Kilian | Source: Unsplash

In my software experience, most of the problems encountered, especially around people and process, were due to #2. Company systems were wrong, inadequate or just misaligned. Unfortunately, this typically meant that a person or department was singled out and blamed. I tried hard to bring the discussion back into a discussion around how the work was done, and if something could be done to prevent a similar problem from re-occurring.

The last type (#3) is essentially an opportunity to improve the company, the product, or the workflow, packaged as an intellectual surprise. Sometimes, the team would come across a much better way to solve or define a technical problem than they had originally wanted to do otherwise. This was particularly common in the early days of designing a large system. The same can be true on the business side, if the company is open to experimentation on that end. These are so valuable, that most innovation circles try to maximize the number of these errors through structured experimentation and record-keeping, in order to speed up overall progress.

Be open to taking ownership and admitting mistakes

From the perspective of psychological safety, it's critical to start with assuming any error is a #2. This includes assuming that the leader in the system is responsible for the system. More importantly, he is also part of the system. Which means that the manager needs to be open to letting their ego bruised, and be willing to admit mistakes in front of their fellow team members, in the service of improving life for everyone. Once I did this enough times with my team, they realized and eventually believed that I was genuinely interested in optimizing how the team worked.

Photographer: Jen Theodore | Source: Unsplash

Essentially the way to solve the misaligned expectations problem (bar too high vs too low) is to view the work as a system. And that way, you depersonalize the work enough, that fears become less of a driver for action. Instead, employees follow their genuine interest in improving their own work life. This allays fears of failure. And gets everyone more involved and excited.

Ultimately, you care about the output your team produces, so focus your management on that, rather than on policing individual effectiveness. Paradoxically it produces better results.

Key Takeaways

• Psychological safety lies at the heart of high performing teams
• Most commonly errors are assumed to be individual mistakes, rather than the result of complicated interactions gone wrong.
• Get the team excited about improving the workflow

Why building for the entire market bloats timeframes, and what to do instead

In High Output Management by Andy Grove, Intel's founding CEO, Grove suggests that Intel operated in an environment where they needed to manufacture units to a market forecast. From the beginning in the 1960s, they didn't have the luxury of selling up front and building exactly what was sold. Nowadays, this is pretty much the defacto environment for product development. Even in the case of software, where there is no manufacturing or reproduction cost, timing the scope to match demand is a core component of a software company's success.

In order to plan the release of a product, you need a clear scope of what product development needs to happen first. This includes breaking down tasks, estimating them, and then mapping the specific features to expected customer value. This way you come up with a set of features that need to be created, in order to release the product (or release it again).

How this typically plays out in practice

In practice once this is agreed, new ideas come up. New stakeholders propose specific changes or additions to that original scope. You might even want to try reaching more prospects in a related segment.

1. Add a bit more scope: The natural impulse-in this environment- is for product development teams to simply add scope to the list of stories or tasks which were already agreed.

Vicious feedback loop for scope

2. Push the release back a bit: As soon as they add another feature, this effectively means more work needs to be done. So the effective date when everything will be done is pushed back. Usually this means the estimated completion date needs to be adjusted, even if this isn't explicitly acknowledged by the team.

3. Delay market feedback a bit: If the release date is moved back, the team delays getting market feedback. Depending on the size of the feature, it might be a few days in a software context. Or a few weeks.

4. Reduce probability sales: of If the feedback is delayed, you reduce the team's confidence that the product will sell. The less feedback you have, the lower the probability of hitting your sales forecast when you ultimately do release. So your probability-weighted revenue goes down, the later you release. In a sales context, "money follows speed" is common knowledge. Being able to close a deal quickly is really important, because if you don't, it's likely the customer will change their mind. And finally, if you are less certain about your sales forecast, this typically influences your overall confidence level in the product. And one of the most natural things done in this case is too...add a bit more scope.

Deja vu. The cycle repeats.

Paradoxically, the more scope you add, the lower the chances of market success of the release. Because you're innovating in a vacuum/ivory tower/echo chamber/<insert favorite metaphor here>. Even though you think you are improving your product's chances. Having too many features is overwhelming for prospects and difficult to communicate for you. The paradox of choice kicks in.

Also, if you delay the release date, you are likely to struggle to make sales until that date. There are "forward contracts" or "letters of intent", however customers will only go for something like this if they are highly motivated to get your solution. It also adds a layer of complexity and obviously a delay, thus making it harder to sell the product.

Implementation notes for startups

In the startup case, you need to get enough scope to attract early adopters in Moore's technology adoption curve. This will typically be one or a handful of related features which address a core need of theirs and which they can't address anywhere else.

Source: Harvard Innovation Lab

The idea is that you need enough scope to go after a narrow group of people, just to get started and out the door. Trying to build enough scope for the entire market will mean you'll never actually move ahead with your business. Because you need to launch it first. The sooner you get it out there, the better for you.

Once you have nailed that first segment, you expand to adjacent segments. You modify the product to appeal to the adjacent segments. And then go sell to them. Do this incrementally, so that you have the benefit of revenues from the first customers. And confidence from initial market success.

Implementation notes for established companies

The above is true for larger companies; however, they have internal operational challenges to overcome also. In particular each of the 4 parts of the circle are often represented by different department heads. Each has his or her own agenda to push.

And while each incremental change might seem to make sense in the short term, the overall effect is the delay of a release. And no one is individually responsible for it.

source: Randy Olson | the operational usefulness of pie charts

Moreover, in a large company environment, go-to-market decisions are often made based on overall market size. While this is useful to think through e.g. positioning of a new product, thinking in terms of top-down market pie charts doesn't translate into a plan to enter the market. Different slices of the pie will want different features, with some overlap across the market.

It's ok to plan to enter the entire market eventually, but it's smarter to prove the approach works on a small corner of the market--before you expand outwards.

Acknowledge it's uncomfortable, and just do it anyway

I get it. It feels unnatural to be selling something that isn't perfect. It's easy to succumb to a fear of rejection, and just put off the prospect of releasing the product for as long as you can. I've done it in the past on my own dime. I hear the mechanism at play when mentoring founders. I see the dynamics play out in larger companies every day. Every product team with an ounce of humanity is susceptible to this.

Focus on a small subset of customers with a similar set of needs, and only build the scope that they need. Keep it laser focussed. And get it out there, even if it's not perfect. Especially in a business context, if your product addresses the core need they have, they will be happy.

Ultimately, fear of rejection just a bias that prevents you from learning what you need to know to make your new product a success. If necessary, speak to customers about their problems only--and don't show them your solution right away. Most people are happy to gripe to a friendly ear, especially if it's about something they care about. Don't make promises you don't expect to keep. But start speaking with flesh and blood customers right from the beginning.