Provoking thought

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

Any book that covers management at some point has to mention Frederick Taylor’s Scientific management, often simply referred to as Taylorism. Rather than postponing this inevitability, let’s get it over with right away.

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. Work where our bodies aren’t used as carbon-based machines, but that involve our brains more: ingenuity, cleverness, creativity.

As it turns out, our creativity does not respond very well to attempts to being controlled. In fact, any type of control mechanism (and as we will see, there are many) are a great way to kill creativity. Except if we want that creativity to be geared towards circumventing those control mechanisms, of course.

Therefore, lately, more and more companies take a different approach. The approach of relinquishing control rather than tightening it.

Netflix is likely one of the more visible pioneers in this area. Back in 2001 the “Netflix culture deck” was shared online. Their approach: no more rules. No more vacation policies. No more expense approvals. No more working hours.

Since then, various companies have followed suit. What does that mean in practice? Often, contracts do not specify how many hours you should work, when you should work, nor where you should work. They also do not have a limit on how much paid time off you can take.

The message is clear:

We hired you. We trust you to do the right thing. Now go do that thing.

No more control.

That sounds appealing, but what does management without control even look like? Isn’t the entire point of management to prevent chaos, which would inevitably ensue with all this freedom?

This idea comes from what is referred to as “veneer theory” which roughly says that the only reason civilization works is because of the rules we put in place, and our enforcement of them. It only works because of the control we exercise. If we wouldn’t have laws, and wouldn’t be stringently policing those laws, anarchy would ensue immediately. Because — veneer theory claims — humans are animals, when the rubber hits the road. Luckily, we will find in a later chapter that this theory is likely very wrong and actively harmful.

Until we get there, please bear with me and assume I’m right (spoiler alert: I am). This changes everything. How would one even approach management without the carrots, sticks, rules, close monitoring, and whips?

Netflix’ CEO Reed Hastings in his book No Rules Rules puts a nice label on the general approach, which he dubs leading with 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.

Netflix has a very specific implementation of this concept that is adapted to their specific culture and circumstances. However, I believe the concept of leading with context is widely applicable. It’s been my approach for the last few years in various companies, and I found it can be applied at all levels.

However, it does require a specific mindset.


While it can be applied widely, I have found leading with context only works if you buy into a few foundational things — some may be controversial:

  1. People have good intent and ought to be trusted by default. While there are certainly exceptions, the vast majority of people are decent, and have good intentions. Therefore, the most productive approach to people is to trust them by default. We assume people want to do the right thing, and in case this appears not to be the case, we should reflect on the environment and context we created for them that may have lead to this problem.
  2. People want to contribute. People are not naturally lazy. We all have the natural need to do something of value. That said, we all have our preferred ways to contribute, and our preferred areas of contribution. It is the role of management and leadership to help people find, nurture but also not actively kill this interest in contribution. Similar to point (1) if people are disengaged, by default we should reflect on the environment we created for them that may have lead to this problem. There is a lot of skill involved in nurturing motivation (more on this in later chapters).

In practice

If we buy into these two things, we can now move into our new lead with context-leader role.

It consists of two core parts:

  1. Being a source of context
  2. Being a coach

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, how, and when to share any relevant parts with people.


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

That may not always be the case for us; therefore we need to adapt our approach contextually (context all the things!).

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 with context approach, initially. That said, we will make sure to always spend time to explain the context of your instructions. This is how we build up to leading more with context down the line.

For instance:

“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.”

In time, people will start to use this context. “Ok, but if that is why, then why do we not approach it this way?” Many of those ideas will be good. Implement them.

Then, as the team matures, the level of context we 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: Shrug

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 to a specific A/B testing tool 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 is 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.”

And your job is done!

In the coaching role, your role 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. More on this topic in the next chapter.

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 we learn.

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. Exciting times!

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 may actually be good to let this run its course. If things indeed go wrong, it’s a learning opportunity. However, I found that more often than not, things will actually work out just fine. Let’s remain humble, we don’t always have the (only) correct answer.

Trust people.

Provide context.

Coach people through things.

No more control.