A Project Management Playbook for Website Development Teams

A team of seven, and a hundred people who each have one quick request

Picture an in-house website development team of six to nine people, responsible for a company's main marketing site and a handful of smaller client or campaign microsites. The work itself is a mix: a planned redesign of the pricing page, ongoing performance and accessibility fixes, and a steady, unglamorous stream of small requests from marketing, sales and leadership, update this headline, swap this image, add a banner for the event next week.

None of those small requests is unreasonable on its own. The problem is their number and their channel. They tend to arrive as direct Slack messages, "can you just quickly," addressed to whichever developer the requester happens to know personally, which means the team's actual workload is invisible to anyone outside it, and a bigger planned project, the pricing page redesign that's been "in progress" for six weeks, keeps losing time to whichever small request landed most recently.

This is the situation many website teams are in before they adopt a system that gives every request one front door and protects planned work from being quietly outcompeted by it.

Before: everyone's a stakeholder, and nobody can see the queue

The first problem is that requests bypass any shared queue entirely. A marketing lead messages one developer directly because that's who helped last time, a sales lead messages another because they sit near each other, and the team as a whole has no single, current view of what's actually been asked of them this week. Two stakeholders can end up asking for conflicting changes to the same page without either knowing the other made a request.

The second problem is that small requests, individually quick, collectively consume the time meant for larger planned work. A redesign that should take two focused weeks stretches to six because it's worked in the gaps between "quick" asks, and from outside the team, it just looks like the redesign is taking unusually long, when the real cause is invisible interruption.

The third problem is memory. Someone asks, months later, why a particular button links where it does, or why a section was removed from a page, and the honest answer is buried in an old Slack thread that's aged out of search, if it was ever written down anywhere at all.

After: requests that don't quietly outrun the real project

The realistic shift for a team like this isn't that stakeholders stop having quick requests, that's the nature of owning a company's public-facing site. What changes is that those requests land somewhere visible and shared instead of scattered across personal messages, and a bigger planned project gets a column with real protection instead of losing time invisibly to whatever felt urgent that hour.

It's honest that a triage inbox doesn't reduce how many small requests come in. What it does is make the tradeoff visible: when the redesign is behind because the team absorbed an unusual number of urgent asks that week, that's something the team and its stakeholders can see and discuss, instead of a mystery about why a two-week project is somehow in its second month.