The Muselet #44: No More Control

“It doesn't make sense to hire smart people and then tell them what to do. We hire smart people so they can tell us what to do.”

― Steve Jobs

Every book that covers management at some point has to mention Frederick Taylor’s Scientific management, often simply referred to as Taylorism. At the end of the 19th century, Taylor closely studied how physical workers in factories performed their manual tasks. He then proceeded to optimize and prescribe their exact movements. This way he managed to squeeze a lot of additional productivity out of workers by essentially treating them as machines to be optimized. The system was based on closely controlling workers as much as possible.

This was a reasonable approach in the 19th century, but in the 21st the world has evolved a bit. Many of the tasks that were candidates for Taylorism have since been automated and are performed by machines now, and the trend continues. 

What is becoming more prevalent today is a different type of work: knowledge work. As it turns out, Taylorism cannot be applied to knowledge work, and we have to depend a lot more on people’s creativity.

Creativity is a lot harder to control. Setting very clear performance targets is rather difficult, for instance. And measuring productivity is hard as well. Imagine I ask you to deliver 5 innovative ideas by next week. Likely, that pressure won’t really result in anything good. In fact, exerting this type of pressure would likely make results worse.

Lately, there is a trend to relinquish control rather than tightening it. 

The hit of the pandemic in 2020 probably accelerated this process a fair amount. Even if companies wanted to, tools were simply not available to continue to exercise the same levels of control with people working at home. Although… some try.

So, what does management without control look like?

Netflix is likely one of the more visible pioneers in this area. And my employer, Mattermost, applies many similar ideas. Let me briefly cover Mattermost’s practices to give you a sense of where the industry is heading, what sooner or later will become the new status quo.

At Mattermost, my contract does not specify how many hours I should work, when I should work, nor where I should work. Like Netflix, there is no limit on how much paid time off I can take. I have a defined role, but it is very flexible. As an employee, what this tells me is: we trust you to do the right thing, now go do that thing.

This is the opposite of leading through control. 

If not through control, how does an organization ensure that things continue to happen without looking over the shoulders of employees all the time?

Lead By Context

Netflix’ CEO Reed Hastings in his book ”No Rules Rules” puts a nice label on this approach — he calls it Lead by Context.

Leading with context (…) gives considerably more freedom to employees. You provide all of the information you can so that your team members make great decisions and accomplish their work without oversight or process controlling their actions. The benefit is that the person builds the decision-making muscle to make better independent decisions in the future.

In practice, this means that the role of a Lead by Context-leader is two-fold:

  1. Being a source of context

  2. Being a coach to the team

Source of context

Context comes in many shapes and forms:

  1. Context about the company: what is the company’s history, mission, vision, values, strategy? Is the company growing? In what areas, any upcoming organizational changes? What are the other departments in the company and what are they working on? Who are the people to talk to about what topics?

  2. Context about customers: who are they, what are their needs, what are their frustrations and asks? In which customer segments are we doing well and why? How do customers use our products?

  3. Context about the product: what does the roadmap look like, what are the priorities?

  4. Context about technology: what technologies do we have in use in the company and why, how much flexibility to we have, what parts of the system are considered legacy? What tools do we have access to and which ones should be used for what?

  5. Context from experience: what are common practices in the context of software development: team collaboration, process, architecture, testing, managing technical debt?

It is the role of the leader to gather as much context as possible, and then figure what and how to share any relevant parts with the team, when.


The approach to sharing context will vary based on the team’s maturity. Netflix’ strategy is to hire only extremely senior people, who given limited context can go out on their own.

That may not always be the case for you; therefore you need to adapt your approach contextually (of course, more context).

In case of a very junior team, likely a lot of handholding will be involved. Yes, it likely makes sense to exercise some micromanagement of tasks. This is not the best level to lean heavily on the Lead By Context approach, initially. However, make sure to always spend time to explain the context of your instructions. This is how you build up to leading more with context down the line.

“This is how we tend to write code, and this is why.”

“Before we merge code we ask for code reviews, and this is why.”

“This is how we use JIRA, and this is why.”

As the team matures, the level of context you provide will increase.

Provided context (customer knowledge): “Customers somehow never seem to get to this stage of the ordering process.”

Team: “Do we know where they get stuck?”

Provided context (customer knowledge): “Generally when they need to provide the shipping details.”

Team: “We could try changing the order of the form fields…”

Provided context (professional experience): “How will we know if that has any effect?”

Team: “🤷‍♀️”

Provided context (professional experience): “We can run this as an A/B test: give the tweaked form to 50% of customers and the old one the the other 50% then see if it makes a difference.”

Team: “Nice, do we have a system to support that?”

Provided context (technology): “We have a license at the company.”

Team: “Let’s create the tickets and prioritize!”

Note: this is an example where context is supplied immediately on demand, often it may actually be a better idea to let the team explore for themselves a bit, rather than supply answers immediately.

Eventually you will get to a level of context that is purely focused on the customer:

Context provided (customers): “Customers are going to use this feature every day.”

Team: “So it’s critical we don’t break it. Got it, we’ll increase our test code coverage, and put monitoring in place, so we are notified when things don’t work as expected. We’ll also ensure that on-call gets paged in case of any regressions in production. We’ll create some tickets. Since this is more important to customers than some of the other other more fancy features on our roadmap, we’ll prioritize this before doing the fancy stuff.”

In the coach role, the approach is to engage the team, provide context, ask questions, and unblock conversations. It is not to supply all the answers. In fact, the fewer answers supplied the better.

At first, not spoiling the waters with your answers will be hard. However, soon it will pay off. Why? First of all, this is how they learn. And second, the team will come up completely different solutions than you had in mind, and guess what... they’re good. Perhaps even better than yours.

Sometimes the team will take things into a direction that you are not convinced will work. One reason may be that you did not provide sufficient context. However, often it’s actually good to let this run its course and let things go wrong, if that’s indeed what ends up happening. More often than not, things will actually work out just fine. Let’s remain humble, we don’t always have the (only) correct answers.

Provide context. Coach your team through things. Don’t control. Lead by context.