Have you ever gotten to the end of a day and looked back and wondered what it was you accomplished all day long? You were in back-to-back meetings for most of it, hardly a moment to get a bite to eat, and yet… What actually happened?

I think we’ve all had days like that. But why are some of those meetings so… Unproductive?

An early 2010s billboard from GPS maker TomTom proclaimed:

You are not stuck in traffic.

You are traffic.

We are desperate for a “solution” to this neverending “meeting problem,” but the question we never seem ready to ask ourselves is… What can I bring to improve this situation? Well, let’s get into that.

This is part one of a multi-part series. In this article, I focus on the low-hanging fruit: how to be a stellar meeting organizer.

All meaningful change is an act of creation.

In fact, when setting out to make substantial change happen, I believe that most people overlook one key element that must be woven through all successful, durable change: understanding.

Today, let’s build a new framework for change that puts understanding at its core.

The best work is done by teams who, frankly, give a shit about what they’re doing. If your team is showing up just to get paid, you aren’t getting the optimal results, period.

That doesn’t mean you need teams of single-minded idealists who exalt the team and company’s mission and would walk over hot coals without question if asked. Rather, it means you, their manager, need to connect their work to a purpose greater than them.

In today’s issue: how do you do that?

In part 1, I looked at simple methods of delegating or prioritizing decisions, and one option for making decisions quickly based on “operating principles.”

This part will dive deeper into more complex methods for wayfinding within decision-making scenarios and processes that create confidence and alignment within your surrounding team or teams.

Long ago, I read this piece of advice, which has lived rent-free in my brain ever since:

First make the bug easy to fix, then fix it.

What I think it meant was to approach a bug as an opportunity not only to improve the software by removing the bug, but also to make it harder for the software to become buggy later (by adding tests and consequently improving the architecture).

As leaders, one of our primary exports is decisions. We all make them, every day, and sometimes those decisions have far-reaching downstream consequences.