Let Your Teams Roam

Postlight has partnered with amazing companies and nonprofit organizations. We’re often brought in to take the client on the wild journey from “idea” (if they’re feeling creative), or “mandate” (if they’re terrified), to something real in their hands in a matter of months. At the outset though, we need to show the client how we’re going to get there.

Inside just about every Postlight proposal is:

• A diagram that shows how we work.
• A timeline of what is going to happen over the next four, six, or 12 months.

That timeline is the project plan. Sort of. It’s actually not much of a plan at all. In fact, it’s a “here’s-how-we-think-things-are-going-to-go” diagram, and we like that about it.

Change is inevitable in software development. Being inflexible with software development not only disappoints — it leads to a suboptimal product. In fact, change is an ally. If you embrace change, you can achieve better outcomes.

Gantt project plans vs. Postlight project plans

The typical Gantt chart–style project plan is a series of hopeful outcomes plotted out against time. It is not a prediction of what may happen in the future. It is not built to flex with the needs of the project, or to cope with changes.

It’s a visual set of instructions that hopefully all participants will respect (revere?) and adhere to. If Samantha’s avatar doesn’t finish QA by Week 24, a whole bunch of things get delayed. And so on.

For most consulting firms, a change in the plan leads to change orders and… more revenue! At Postlight, we rarely do change orders. Instead, we build in flexibility from the outset. We tell the client up front: Things are going to happen. Some stuff may not make it in, and some new stuff that we didn’t anticipate will make it in. And that’s okay because we plan for flexibility and we expect change.

Here’s what a Postlight Project Plan looks like:

There are a few things to highlight:

DUPLOs instead of LEGOs: We lay out time in months, not weeks. Micromanaging the week or day isn’t realistic and adds a layer of bureaucracy to what should feel like a fluid effort. Sometimes a design team needs one more go-round to really nail it, and they should feel like they have the freedom to do so. 

Icons instead of avatars: Specific team members and responsibilities are ambiguous. We want to be able to tap into whoever is best at any given task at any given time. There is a core dedicated team, but if there’s an expert on React Native outside that core team, we want the flexibility to bring that person onto the project for a few weeks. 

Expanding and contracting teams: Good technology products require different types of talent at different phases of an effort. There is no need to get caught up in exact team sizes. Sometimes you need more design firepower early on and more DevOps expertise closer to launch. Also, teams inevitably overlap. There is no design phase that ends abruptly followed by an engineering kickoff.

No dependency staircase: In our model, nothing is waiting for something to finish before it can start. Each swim lane is productive, with minimal time spent waiting for handoffs. This isn’t easy to pull off because it requires good product management coupled with sound architecture that minimizes dependencies. Done right, everyone is moving concurrently nearly all of the time.

Good results require some freedom

To some seasoned software project managers, this may all sound like fantasy. Shouldn’t this sort of laissez-faire approach lead to software never, ever shipping? You would think so, but that’s rarely been the outcome for us. In fact, it’s been just the opposite. 

We adhere to an unwritten rule: Play all you want within your guardrails, but we will police those dates. By committing to shipping early and often, we’re ensuring that we and our client stakeholders can meet their commitments.

All of this leads back to one core premise: Good collaboration that leads to quality outcomes requires some level of freedom. The above is — dare I say it — anti-process. The goal isn’t to play it fast and loose, but rather to minimize the constraints that come with lots of people working together. This approach isn’t for everyone. But if you’re trying to bring some creativity and the occasional burst of innovation to your projects, break out of those little boxes and let your teams roam. 

Rich Ziade (@richziade) is Co-Founder and President of Postlight. Drop him a note at rich.ziade@postlight.com.