All of the business of software, but especially the delivery of product capabilities, is inextricably bound up in questions about time. What’s the estimate? If we have N people working on it, how long will it take? When will we ship?

Putting a finer point on it, if you’re building products iteratively, incorporating customer feedback from early prototypes, tacking and jibing your way toward the right solution, there’s no way you’ll be able to accurately estimate the work it will take to get there. Trying to do so is performative and it sets teams up for disappointment or even conflict when the date “slips.”

Change your relationship with time

I’ve come to believe our relationship to time is at odds with the reality of developing great products. Estimates are almost always wrong—teams can get better at estimates, but is that where you want to invest energy when it comes to honing your craft?

After quite a few years at this game, I’ve started to think of time as a blade, a tool that can sharpen focus and trim waste. We can’t be so loosey-goosey about time that we lose sight of its bearing on value, which is the key measure of product decision-making. The value calculus changes, sometimes a lot, depending on whether a product problem will be “small” or “large” to solve for customers.

Enter our cadence for product planning and execution at Honeycomb, from longest timeframe to shortest, which I outline in this blog post. What I would like to emphasize here is that we’ve been deliberate about setting a rhythm for our business that works well for us, and it’s effectively a set of graduated timeboxes.

With that framing in mind, time is giving us that sharpening effect we want without turning into a cudgel that we use to punish people (“you missed the totally made-up, arbitrary date someone decided on and are therefore a horrible person/team”).

Yearly: Product strategy and roadmap

Our product strategy is updated mid-year. The strategy is a 10-12 page document based on conversations with Honeycomb’s execs, product leaders, and other subject matter experts. It is intended to support the company’s strategy and goals, and not be overly prescriptive about “features” or other solution details. We update this mid-year so we have time to steer the ship in a new direction if needed, which leads us to the annual product roadmap that we build toward the end of the year.

I’ll be blunt: I’m not a fan of a roadmap that tries to detail what our plan for the product is for 12+ months. But I recognize the importance of sharing a look ahead within Honeycomb and also with our customers.

There are two keys to success with an annual roadmap—the first of them is to not present its contents with more confidence than you truly have. We use horizons (in progress, next, planned) rather than quarters or other measures of absolute time as a way to illustrate how sure we are. While it’s rare for something that is in progress to be put aside, it can happen—and the further out on the horizon you go, the more likely that things will change.

Second (and maybe obvious based on the first point), the roadmap should be continually evaluated for ongoing relevance. As conditions change in the market or in the needs of our customers, the roadmap can and should change to reflect those new realities. We use our “changing of the eighth” (see below) as the trigger for a roadmap check and update.

Quarterly: Objectives and key results-a-go-go

At Honeycomb, objectives and key results (OKRs) are our framework of choice for discussing, communicating, and measuring where we think we need to focus next as a business. Quarterly is a common cadence, and one that seems humane enough. My favorite part of OKR time is the opportunity it gives us to evaluate whether we are aligned across the business—for instance, if we are going to ship some new hotness in the product, do we see go-to-market efforts in Marketing, as well as advocacy/adoption efforts in Customer Success and DevRel that lineup? We’ve had so many great conversations over the past few quarters, and we’re getting better at this each time.

Eighthly: R&D planning and execution

Back in ye olden times (2018, before I joined), the leaders on the Honeycomb R&D team arrived at “eighths,” or half quarters, as their preferred planning cadence. Planning for a full quarter back then was too blunt given the pace of change in the business and the small size of the team, so our CTO Charity Majors decided to try chopping them in half.

When I arrived at Honeycomb, I was enchanted by the idea and quickly became a convert. Because we still do a fair amount of dynamic re-teaming, six weeks is long enough to absorb the overhead that comes with changing focus, but not so long that we get bogged down when we are trying to move fast.

We absolutely have roadmap work that spans multiple eighths, but using this unit as the baseline means we are frequently engaging in a lightweight but clarifying planning process. When I say lightweight, I mean it—each eighthly plan is a one-page document, all bullets, that is assembled via three 30-minute conversations between Emily Nakashima (VP Engineering), me, and different sets of stakeholders (Engineering, Design, Product, Security, Customer Success, Solution Architecture). It’s just enough process to keep us from going off the rails, but a long way from being overwrought.

Bi-Weekly: R&D update

Every two weeks, the leaders in Engineering, Product, and Design jam on a written update that we share with a pretty big distribution list (anyone in the company can subscribe). It’s organized by roadmap initiative where that applies or by functional team where it doesn’t. It’s chock full of goodies about what we’ve been working on for the past two weeks, links to resources for folks who want to learn more, and a look ahead at what we think is going to happen next. Because they’re written collaboratively I don’t think any contributor spends more than 15-20 minutes pulling together their content, and they are 100% Gantt chart-free.

Weekly: Demo day

MY FAVORITE. This is a tradition I picked up during my time at Chef Software. Every Friday afternoon, we host a 30-minute demo day where folks can sign up to share what they’ve shipped or a look ahead at their works in progress. While demo day is unequivocally fun, and full of good cheer and celebration, there’s a real business benefit here—demos make our work visible in a way that status reporting cannot, and allow colleagues who are not part of day-to-day product development feel connected to what’s happening. They are the heartbeat of R&D’s work that we radiate to everyone in the company. We even get demos from other parts of the org sometimes, like Marketing and Finance. All demoers are welcomed with warm hugs!

Daily: Team syncs

My colleague Ben Darfler wrote this awesome post about how his team replaced the asynchronous standup with meandering team syncs, so I won’t spend too much time here. Teams have different needs and styles, but we’ve all agreed to a daily sync with our faces four days per week (Wednesdays are “no meeting days” in R&D, so we skip them). TL;DR, keep talking about the work, make sure everyone’s got the plot, shoot the shit, and enjoy Zoom-based human contact for a few minutes each day. Nudge each other about what cool stuff you’ll demo on Friday.

The downsides of setting arbitrary, estimated deadlines

As I said earlier, estimates are almost always wrong, whereas mythical person months are extremely real—for any piece of work there is an ideal number of people who can contribute most effectively. The temptation to throw more humans at something to improve a timeline should be viewed skeptically indeed. And finally, setting release dates too early hems you in—now you’re balancing the tension between the commitment you’ve made to meeting a date, and the goal of delivering something that will actually have the customer or business impact you set out to create.

Wielding time as your blade

Phew. That seems like a lot when I write it all out, but you know what? It’s not. If you keep each of these processes lightweight and focused on the excellent conversations they prompt rather than the artifacts, they create far more benefit than burden. I’m not sure I’ve ever worked somewhere that felt so aligned but still adaptable, from those big yearly decisions and goals right down to the daily syncs. I doubt that our planning and execution cadence is the only factor here; we also have a culture of transparency at Honeycomb that invites us to experiment, kill our darlings, and challenge one another.

I do think that being intentional about the rhythm you want to move to in your business is very important. The way Honeycomb does it probably isn’t exactly the right way for your org—but I’d encourage anyone who feels pummeled by the truncheon of time to examine how they can change things up, and start using it as a tool that serves them well.

How do you manage time at your org? Share with us on Twitter or in our Pollinators Slack—we’d love to hear from you!