Skip to main content

I intend to ... : Avoid asking for permission.


Recently while listening to a Soft Skills Engineering podcast Correcting English and Tyranny of the Urgent, a topic was brought up about solving technical debt and escaping the "Tyranny of the Urgent". The discussion that followed was informative, but one of the hosts mentioned a phrase "I intend to ..." that originated from a book called Turn The Ship Around!.

This one little comment got me really thinking, so I went off to do some of my own research on the subject. I'm not a big book reader, so I didn't read the above referenced book, but I did listen to some interviews of the author from another podcast called EM Weekly. They did two interviews with the author that were very informative and aligned quite well with Lean methodologies and Agile philosophy. The two podcast episodes were:

My Takeaways

Don't Brief, Act

Time and time again, management will brief, dictate, or speak on improving collaboration, improving productivity through philosophies like Lean/Agile, and effectively directing the group to sing "kumbaya" on cue. This type of action is likely nothing but hot air and lost on the audience.

Jerry Sternin is quoted as saying, "It's easier to act your way into a new way of thinking, than think your way into a new way of acting".

The point to make here is that leaders should be setting ground rules that have workers acting differently that inturn cause them to think differently. In contrast, attempting to have folks act differently based on what the leaders are saying or thinking almost never works. It also should go without saying that leading by example is a great way to show thing kind of action instead of leading by position.

Pause To Encourage Thinking

Often, we do repeated tasks that can cause us to go into auto-pilot mode. When driving to work, sometimes you look back on the experience and wonder How did I make that merge onto the highway and not remember doing it?. In the workplace, taking a moment to pause before doing any action, that will have side effects, can give your brain time to process whether your immediate intention is a mistake.

When dealing with actions that have safety ramifications, a good way to encourage folks to slow down and think about their actions is to have ground rules that force workers to say out loud what their intention is before executing the task. When working in close proximity to others, this can easily give peers the opportunity to suggest course corrections in the moment. I like to think of this as similar to a bunch of kitchen cooks yelling out orders and their current cooking station's state to the entire kitchen as well as the chef.

Encourage Solicited Feedback

One of my top key values in an organization is having continuous feedback from the customer or user of the product I am contributing to or developing. Often, this kind of feedback is driven by me as the contributor. In contrast, you could be a peer or user of something and provide unsolicited feedback. This can become an awkward situation where folks feel more judged or attacked.

Instead of encouraging unsolicited feedback, as a leader, you should be attempting to instill a culture where everyone sets aside a time and process for feedback. In other words, a healthy organization is one where workers are asking for feedback instead of providing unsolicited feedback.

A Summary of Growth and Fixed Mindsets is a blog post on different mindsets. Knowing that some folks are predisposed to a fixed mindset instead of the more desirable growth mindset is the first step in being able to shift a culture where the goal is to achieve excellence instead of aiming to not mess up.

Knowing and Not Telling, Returning Problems Unsolved

This knowing and not telling is a subject that I've really only become aware of over the past 2 years. The idea that even if you think you have the solution, as a leader you should avoid always providing the answer is a great piece of advice. Allowing folks that report to you to solve the problem themselves gives them a sense of ownership, encourages more critical thinking, and decreases their dependence on you as a senior engineer. David Marquet refers to this as "Knowing and telling vs knowing and not-telling." and "Returning the problem unsolved."

For more junior engineers, one approach is to provide some rhetorical questions for the engineer to answer on their own:

  • What do you see as the problem?
  • What do you think about the problem?
  • What do you want to do about it?

3 Minute Meetings

Marquet also had a great idea for leads that find themselves more unavailable to their workforce than they'd like. This kind of unavailability (unmitigated) may inhibit Lean methodologies or Agile philosophies in the organization. The idea is that you can have quick turn around meetings (~3 minutes) to allow the lead to determine whether the worker in on track or not. One way to structure this is:

  • Have a 30 - 45 minute block in the day to talk with ~10 people, each 3 minutes. Depending on the type of culture in the organization, this could be as simple as having everyone lining up outside the lead's door or giving each person at a conference table their time to talk around the room.
  • These meetings are not a design session or discussion. They are simply an update with a "Good, proceed!" or "Stop work. Let's schedule some time to discuss." response from the lead. The worker with the update should be given the majority of the time to speak!
  • Allowing folks to quickly explain their situation gives you the lead the availability to ensure that tasking being performed isn't wasted and that the task aligns with what you know at your level. (This is fundamental to Lean.)
  • The extremely short meeting time encourages engineers to be efficient in their talk but also, instead of being spur of the moment like an elevator speech, this is predictable time and process that can be planned for.

Encourage Intention (not Permission)

All of these, IMO, are good points that build us up to the final take away which is to implement a culture of stating intention, not asking for permission. When you ask for permission to do something in an organization, you're shifting responsibility to someone else. This isn't fair to the proposer or the lead making the decision. Instead, having the engineer or contributor stating their intention and giving the lead the opportunity to reject the intention allows the contributor to keep ownership and responsibility of their idea.

Marquet stated that this kind of culture shift doesn't always work and he sees it as depending on two major factors:

  • Technical Health and Competency - Not the just the ability to perform the job, but the ability to see how systems work and why they are implemented/designed the way they are.
  • Well understood Clarity and Priority of the organization - As in having a good road map and appropriate levels of priorities for the workforce to understand what needs doing without dictating how things should be done.

This pretty much goes hand in hand with traditional systems engineering and requirements development. When developing requirements, you write down what needs to be done, not how something should be done.

In a healthy organization, all members of that team will understand what needs to get done. If that team is technically healthy and has a depth of knowledge on how to accomplish the goals and priorities of the organization, they are likely to be a good candidate for stating intentions culture instead of asking for permission culture. In practice, you schedule time with a manager or team lead and use the words "I intent do do a thing to solve problem X because Y." Without an explicit rejection, this wording implies permission to go forth and do good things.

The idea here is to prevent leads from ever having to give specific direction and instead allows leaders to control how their workforce efficiency and communication. Because this type of culture allows folks to keep ownership and responsibility of their decisions, it has the additional benefit of embedding leadership qualities into that same workforce.

Marquet has mentioned that he's enforced this in times of emergency as well as in more calm situations. But it really depends on allowing the workforce to master their skills and have the ability to act in situations instead of depending on a process and analysis paralysis.

A fire fighter isn't going to wait until a fire chief arrives to point the hose at the flame. They simply point the hose at the flame with an understanding of the ramifications when they do.