e took off from Anchorage and turned south, climbing to cross the inlet, my dad at the controls of our Cessna.

The engine started sputtering.

We were a thousand feet above open water water in a single-engine plane.

I was scared.

Thoughts flashed through my mind. Had I told my mom I love her? What would it feel like to land in water? Did I have clean underwear on?

My dad, though, was calm and collected. He checked gauges, flipped switches, and pulled controls. The engine smoothed out, and we continued our flight.

Disaster averted.

My dad flew the plane all the time. He knew the engine and how it ran. Even when it stumbled, he knew it could continue producing power. He knew how much throttle he could add. He knew what the engine was capable of because he ran it regularly.

Businesses have engines, too. They have sales engines, recruitment engines, delivery engines, and other sources of energy. They must run them regularly to know how they are performing and what they are capable of.

Managers are tasked with running these engines. They work with the employees, talk to the customers, run the processes, and deliver results. When things aren’t running well, they suffer the consequences. Conversely, when things are going well, they benefit.

Managers know how to improve things but have too much on their plate. They can’t improve the engines because they are so busy running them.

Many managers carry individual contributor responsibilities in addition to managing their team. They are considered the experts and get called in for ad-hoc troubleshooting. Their schedules are littered with meetings to collaborate with other departments, communicate with their bosses, and keep their teams informed. They learn people skills as they go, and when they make a mistake, they vow to work harder.

It is a problem across the board. According to Gartner research, managers have more direct reports than ever and more responsibility than they can manage.

No wonder managers are burning out in record numbers. How could they possibly have time to make changes and improve processes?

Below, I describe a framework for continuous improvement called the Iterative Improvement Engine. Managers can use this to create a self-perpetuating system for making changes that benefit their employees, the department, and the organization. It focuses on the process rather than the size of the change. Small changes done consistently over time can yield significant results, and running this process regularly becomes a source of power.

To get started, the manager should identify changes that would benefit them directly. Otherwise, it is one more thing added to their plate rather than something that can improve their job. The manager should make a list of things they don’t enjoy doing, take too much time, or would provide a personal benefit to them.

Although acting on those ideas immediately will be tempting, using them to initiate a process will yield more significant and longer-lasting benefits. For instance, an ongoing process allows the manager to develop their leadership skills and enhance teamwork.

Any mechanic will tell you that engines work best when they are run often. The longer an engine sits, the more effort it takes to start. Similarly, to start an Iterative Improvement Engine, the manager will need to make an investment and prepare a few things.

• Identify a core team of staff that will be involved in every iteration.
• Identify objectives and key results (OKRs) that support the overall business objectives. A team will need only two or three OKRs to get started.
• Gather other materials needed to support the team during the iteration.
• Decide when to kick off the first iteration.

Once the manager has completed this, they are ready to run their Iterative Improvement Engine. Each iteration lasts one calendar quarter and has three phases: Engage, Accelerate, and Cruise.

The Engage phase consists of a kickoff meeting, which requires a few things from the core team.

• Create an iteration plan. Outline the OKRs to be worked on during the iteration, and create a risk register and communication plan.
• Identify the iteration team. This includes the core team and any other employees required to work on the OKRs.
• Schedule the kickoff meeting at a time when everyone on the iteration team can attend.

The structure and feel of the kickoff meeting will vary by organization. Still, a good kickoff will help everyone feel enrolled and invested in the OKRs selected, promote trust, and generate optimism for the work ahead.

The kickoff meeting must include the entire iteration team, and everyone involved should plan on leaving with action items. During the kickoff, the team will review the OKRs, and each member will identify the results they are working toward. The team will also review and discuss the risk register and communication plan.

Lastly, the team will review the schedule and commit to the weekly meetings, the midpoint review, and the demo day.

Now it’s time to run the process, which consists of weekly check-in meetings and a formal midpoint review.

The weekly check-in is a short status meeting. Everyone on the team gives an update on their progress and what support they need.

The midpoint review is a chance to make course corrections. The manager interviews team members to assess how things are going. Then they present their observations to the group to discuss necessary actions.

The iteration wraps up during this phase, and the core team prepares to reengage in another iteration. The most essential activity in this phase is the judgment-free demonstration day, where accomplishments for the iteration are displayed as objectively as possible.

People feel a lot of pressure and expectations when demonstrating their results. Understandably, they try to present themselves in the best light. While results are important, the true purpose of a demo day is to understand how well the engine is running. That can’t be accurately assessed unless everyone is transparent with their accomplishments and focuses on results, not just activities.

The manager must emphasize and reinforce the judgment-free nature of the demo day in the meeting setup, responses to progress demonstrations, and any follow-up discussions.

Following the demo day meeting, the core team conducts a post-mortem review of the iteration. Several items are covered during this meeting.

• Review the iteration and determine what worked well and what didn’t work well.
• Contextualize the progress made by the team. Was it more or less than expected, and why?
• Capture lessons learned and decide what to carry forward into future iterations.
• Create and revise the backlog. The backlog contains all the changes, improvements, and suggestions collected by the team. It will be empty when this process starts, but it will quickly fill up.
• Review the OKRs. Add new ones and revise existing ones. Then, organize the backlog using the OKRs. These are used to plan the next iteration and create a self-perpetuating process.
• Discuss what feedback to provide the iteration team and how best to provide it.

After this phase, the team will start another iteration and keep the engine running.

A running engine provides constant feedback, can be tweaked and tuned to improve performance, and powers movement. The same is true for this process.

It provides the manager with a chance to make changes in their department and improve things at a sustainable pace. The manager gains leadership skills and builds a team invested in the growth of the business.

It allows employees to be involved in change initiatives and see the work being done to improve things. This increases engagement and transforms the culture, which will directly impact results.

When an Iterative Improvement Engine is up and running, it becomes a source of energy for the manager, the team, and the organization.

Managers are responsible for running many engines in the business, and they need a way to make improvements and affect change. This framework can help them do that. When the business’ engines run regularly, hiccups and sputtering don’t cause panic. The manager checks the gauges, flips some switches, pulls some levers, and keeps going.