Three Project Management Lessons I Actually Use

I'm not a certified project manager. I don't have a PMP or a formal background in managing teams. But I've been running projects with developers and deadlines and a lot of moving parts, and I've picked up a few things that actually work. Here are three of them I thought I’d share:

Moving Quickly, Then Clearly

I tend to be more of a doer than a manager. Give me a task and I will research the best approach, find the fastest tools, and get it done. The challenge comes when I need to hand off work to someone else. My instinct is to spend hours writing the perfect brief: every question answered, every credential provided, every edge case covered. The problem is, most of that effort gets wasted.

What actually works is moving fast first. Record a quick brain dump, hand it to an AI to process into a rough project doc, do a quick review, and send it off. The developer only asks the questions they actually need answered, ones I often wouldn't have thought to address anyway. Those questions come in as they hit them, not all at once, which means I'm answering in small bursts instead of one massive pre-work session. An hour and a half of upfront work becomes 30-45 minutes… 15-20 to create the brief, 15-20 to answer the questions. That scales significantly on larger projects.

Terrible analogy #1: spray the window, then scrub

Planning to Be Reactive

Not everything can be planned upfront, and trying to do so is often a waste of time. I had a meeting with a developer where we were going over a large project plan. Instead of spending hours trying to map out every access credential, tool, and integration he might need, I told him to go ahead and make changes to the proposal and project tasks as he saw fit and to request access to things only when he actually needed them.

We planned to move reactively on that point. Instead of front-loading a pile of credentials he might not need for weeks or at all, he would hit a wall, message me, and I'd handle it in minutes. Things only get shared when they're needed. Nothing gets lost. And as a bonus, it's usually more secure that way.

Terrible analogy #2: don’t block a punch that isn’t coming.

Always Two Tasks, Rarely More

This one comes from aviation. When air traffic control gives instructions to a pilot, they typically give two things at a time, not four, not six. Go here, then go here. Report back when done. The reason is simple: you don't overload the person doing the work.

I realized I do the same thing with our developers at Dovito. Each developer always has two active tasks. One might be a complex system integration, the other a custom development project. When they hit a wall on one (waiting for an access request, blocked on a dependency), they shift to the other. No downtime, no confusion, no overload. Just a clean left-right switch between two clear priorities. Sometimes a third task is added if it's lightweight, like generating documentation with AI. But as a rule, two is the number.

Terrible analogy #3: how to run fast: two legs; one on the ground at a time

That's it. Three lessons. None of them require a certification or a fancy methodology. They're just things that are currently working.