The 15 Minute Meeting Every Leadership Team Should Have

The internet went down at 8:40 on a Tuesday. No storm, no attack. A fiber cut two blocks over.

By 9:15 the office was still standing around. Not because nobody knew what to do. Because nobody knew who was supposed to decide what to do first.

That half hour is rarely a technology problem. It is a conversation that never happened.

September is National Preparedness Month. Most of what gets written for it is aimed at households: water, flashlights, a meeting spot. The business version is shorter than people expect.

You do not need an all day planning session. You need fifteen minutes, the people who can actually decide things, and five questions.

1. If we stopped operating tomorrow, what comes back first?

You already know which systems your team touches every day. Recovery planning asks something narrower: which ones protect customers, revenue, and payroll if you can only bring back a few at a time.

For a CPA firm in the middle of an extension deadline, that is document management and e-file access. For a credit union it is core banking and the phone system. For an architecture firm it is file access and the license server.

The answers differ. The point does not. Name what cannot sit idle, and your team stops trying to restore everything at once.

How long should a business continuity conversation actually take?

The first pass takes fifteen minutes. You are not writing a plan in that meeting. You are finding out which answers your team already agrees on and which ones nobody has said out loud. The written plan comes after, and it goes faster because the hard conversation is already done.

2. Who makes the call during a disruption?

Pressure exposes unclear ownership fast. When nobody knows who has authority, people wait for approval, duplicate each other's work, or pull three leaders into three separate phone calls.

Four roles cover most of it. Who starts the response. Who tells employees. Who tells customers. Who works the phones with vendors and your IT provider.

This is not a chain of command. It is four names, and it removes the pause that costs you the first hour.

Who should be in the room for this meeting?

Whoever can make a decision without asking someone else. For most organizations in the 10 to 250 employee range that means the owner or executive director, whoever runs operations, and whoever holds the money. If you have internal IT staff, they belong there too. Keep it small enough that everyone speaks.

3. How would we communicate if the usual tools were down?

Email, phones, and your collaboration platform feel dependable right up until they are not.

https://www.cisa.gov/resources-tools/resources/business-continuity-box

Three questions cover it. If email is unavailable, where do employees look for instructions? If the phone system is down, how do customers reach you? If your collaboration tool is offline, where does leadership post updates?

A group text thread and one posted phone number handle more of this than most elaborate plans do. The only requirement is that people know about it before they need it.

4. What is our largest single dependency?

Some risks stay invisible because they work every day.

It might be one software platform. One internet circuit. One vendor. Or one person who knows how a process runs and has never written it down.

Name it out loud. Then decide whether documentation, a second option, or a tested backup would bring the risk down far enough to stop thinking about it.

What is a single point of failure in a small business?

It is any system, vendor, or person the business cannot operate without and has no substitute for. The most common one in a small organization is not a server. It is an employee who is the only one who knows how something works. Writing it down is usually the cheapest fix available.

5. If this happened tomorrow, what would we wish we had done today?

This question cuts through the assumptions, because it puts people inside the moment they are trying to avoid.

The answers are almost never dramatic. Test the backups. Update the contact list. Write down the order systems should come back in. Confirm who actually holds the vendor account credentials.

None of that feels urgent during a normal week, which is exactly why it stays on the list.

What is the difference between a backup and a recovery plan?

A backup is a copy of your data. A recovery plan is the sequence that turns that copy back into a working business: which systems come up first, who does it, how long it takes, and how you confirm it worked. Plenty of organizations have the first and have never tested the second.

What to do with the answers

When you finish, you will have two piles. Answers everyone gave the same way, and answers that got a pause.

The pauses are the useful part. They are not failures. They are the list.

Some of them close internally in an afternoon. Others are technical: whether the backups actually restore, how long recovery really takes on your hardware, whether the dependency you named has a workable second option. Those are worth handing to an IT provider who can test them rather than assert them.

How often should a leadership team revisit these questions?

Twice a year is right for most organizations and once a year is the floor. Revisit sooner after anything that changes the answers: a new location, a system replacement, a merger, or the departure of someone who carried a process in their head.

https://www.cisa.gov/resources-tools/resources/cyber-essentials

Put it on the calendar this month

Pick a date. Fifteen minutes, five questions, the people who can decide.

If your team answers all five cleanly, you know where you stand. If two or three of them stall, you found something worth fixing while there is still time to fix it calmly.

A complimentary 15 minute Technology Confidence Score call gives you a clear picture of where your systems stand today, along with your score out of 100. Schedule at 10dtech.com/Tech_Confidence_Score. Albany, Corvallis, Eugene, Bend: 541-243-4103. Portland, Salem: 971-915-9103.