Ask Your Dev Team about their project management style

You don’t need to know the difference between Agile, Scrum, and Kanban. But you do need to know that your developer has a process and actually uses it.

Does someone own the process?

Every development team needs someone responsible for keeping work organized and moving forward. That’s usually a project manager or a tech lead. It doesn’t matter what the title is. What matters is that someone is accountable for making sure tasks get prioritized, deadlines get tracked, and nothing falls through the cracks.

If you ask “who manages the project?” and the answer is “we all kind of do,” that’s a concern. Shared responsibility without clear ownership often means no one is actually responsible.

Ask them: “Who on your team is responsible for project management, and what does that look like day to day?”

The process matters more than the label

Developers love their methodologies. Agile, Scrum, Kanban, SAFe, the list goes on. You’ll hear these terms thrown around in discovery calls, and most of the time they won’t mean much to you. That’s fine.

What you should care about is whether the team has a process they’ve refined over time. A team running “Agile” poorly is worse than a team running something unnamed but disciplined. The methodology is just a label. The discipline behind it is what delivers results.

Here’s what a good process typically includes:

• Regular planning sessions where work is scoped and prioritized
• Short delivery cycles so you see progress frequently, not just at the end
• A clear way to track what’s in progress, what’s done, and what’s blocked
• A feedback loop that lets you weigh in on priorities without derailing the team

Ask them to explain it

This is one of those cases where you should just ask directly: “Can you walk me through your project management process?”

You’re not looking for a textbook answer. You’re looking for clarity. A developer who has a real process can explain it simply. They can tell you how work gets planned, how priorities shift, how they communicate progress, and how they handle it when things go sideways.

Vague or hand-wavy answers are a red flag. “We’re pretty flexible” or “we just figure it out as we go” might sound easygoing, but what it really means is there’s no structure. And no structure means missed deadlines, scope creep, and a lot of back-and-forth that should have been avoided.

Match it to your needs

If you already have a preference for how projects are managed, say so. Some clients like weekly standups. Others prefer async updates. Some want access to the project board. Others just want a summary every Friday.

A good developer will adapt their process to work with you, not force you into theirs. But they should have a strong default. You’re hiring them for their expertise, and that includes knowing how to run a project well.

---

Expect better. Build better.