We build software platforms for large companies. And when Postlight drafts a proposal for work, like many other shops we like to tell you a bit about ourselves. Before getting into the actual proposal for work and all its bits (timelines, costs, etc.), we describe how we work.
This is pretty common for technology firms. The “how” usually falls under the mildly awkward Our Process. In the world of technology consulting proposals, it’s highly likely that the agile development process is a big part of it.
There’s a lot of good in agile methodology. It’s a direct attack on the see-you-in-six-months-with-some-software model. The problem for us is process and the rigidity and pseudo-bureaucracy that comes with it.
While we pride ourselves in our agility, we’re pragmatic about what really happens when digital products and platforms get built. Our approach is to over-coordinate, over-communicate, constantly iterate and ship…all the time.
In every proposal, we share an image that visualizes this more fluid approach to shipping great products. We call it the Mountainside:
It is a diagram that represents how we think about a product or platform effort. The X-axis is time and the Y-axis represents energy and resources. The four “ingredients” represent the various centers of discipline at Postlight. It’s a little messy. And we’re ok with that. It’s sort of like a Gantt chart that was left on the stove too long, leaving all those neat and tidy bars melting into one another.
Here are some key highlights worth noting:
- No boxes. Instead we have peaks and valleys. Skills and capabilities are not switches you can turn on or off. Early on product strategy dominates. Design is in the room and as the strategy comes into focus, design heats up. Architecture engages and joins the conversation as design is turning a corner and artifacts are firming up. Finally engineering takes the wheel with all the other disciplines nearby.
- Embracing overlap. We don’t believe in “phases” in the traditional sense. Nor do we believe in discrete walled-off teams. Notice that product strategy and design layers linger throughout the effort — together. Designers talk to engineers. Architects talk to product. There is no wall to toss your work over. It’s highly collaborative by design.
- Product and design are in the mix. Most software methodologies like agile don’t talk much about product and design. The focus is mostly on the engineering. We don’t see it that way. Product and design heat up early and never really leave. The owners of the experience visit the work site constantly, hardhats and all.
- It’s not the real plan. It’s not the actual project plan for any particular project. We share the same mountainside with everyone. It’s conceptual. We don’t presume to be able to draw out exact phases and timeframes when we haven’t started working yet. Anyone that bothers to do so at this phase is just creating filler.
The mountainside is a clear declaration that the software development effort — all the way from conception to launch — is a messy endeavor. The key to tapping the value behind all that great talent is to acknowledge and embrace that chaos.
Don’t get confused: We have timelines, commitments, and deadlines. People get desks and laptops and work steady hours. We also work closely with our clients and sometimes they like to do daily standups and follow orthodox agile, and we do that too.
We’re not trying to reinvent work. We like our work! We just want to tell the truth, to ourselves and to our clients: The line to the finish is never straight. It’s more like a set of gently overlapping hills of interlocking effort. Or as we like to call it, The Mountainside.