Our strategy at Fractal was to schedule a minimal amount of touchpoints on each of our companies' calendars. Each touchpoint was meant to be a forcing function of some kind. For instance, our MVP Workshop was meant to force them to take the abstract concept of releasing a MVP into a tangible thing by simply explaining to us the plan. We weren't necessarilly there to grade their plan per se, but the exercise forced them to come up with a plan, which is half the battle sometimes.

It was not uncommon for someone to walk into this MVP workshop with a plan that didn't have a whole lot of meat on the bones. A lot of times, it wasn't from lack of trying. It's a genuinely hard task.

At that point, we would give advice and ask questions designed to help them through it. They were rarely struggling with only one of these points. There's a mini flywheel that happens once these three points are in your culture.

Small chunks helps you take the abstract into the tangible. Once you have small units of work, making deadlines become easier because the deadlines become smaller. Once you have deadlines, you have some clear indication of whether or not the team is on the right track. Once you have that feedback it becomes input into your next set of work. And the cycle repeats.

So once I saw one of these issues, they were inevitably having issues with all three. And thus I would end up touching on all three. I started making the speech so often it became colloquially known as "Colby's Holy Trinity".

I don't know if it's holy, but it's effective.

For a lot of the CTOs we worked with in their first official leadership role, the fact that deadlines can have a positive impact is usually a little jarring at first. Most companies use deadlines as whips to keep the huskies pulling the sleigh and thus most first-time CTOs understandably don't want to replicate that culture now that they're in charge.

There's a mindset shift that has to happen to realize you're going to need them. Frankly, a lot of times, they had to do some simple math on their own in order to trigger the shift. There's only a finite amount of cash in the company's bank account, meaning you have a finite amount of time before your company seizes to exist. Once a CTO is forced to do math on how much time is left and sees the ticking clock, they're forced to reckon with a harsh reality: you already have a deadline.

At this point, they're usually way more willing to discuss this idea. And it becomes a simple question. Would you rather miss the big existential deadline or miss a smaller deadline that gives you feedback 

Because these points are so closely related, most startups don't have the luxury to implement only one. But for a larger company, the iteration culture becomes a keystone value. If you manage to build in regular retrospectives for the team, it becomes the way you improve everything else.

Did you do a sprint where the work was too big? You'll catch that in your retro. Was a deadline too aggressive and more tense than it should be? You can discuss that with the stakeholders in the following retro. Do your retro meetings become too long because everyone starts to discuss implementation? Make that an item on the next retro. (Meta!)

Doing this right is easier said than done. It's more than just a ceremony on the calendar everyone's forced to go to. It's about building a culture where people aren't afraid of failure because they know the org will learn from those failures.

But when you get there, you'll have a cultural habit that helps build all the other habits.

Colby White

At Fractal I was advising several (100+) CTOs of small startups and I would end up repeatedly giving the same three advice points at a certain stage of the startup. Those points eventually got rolled up into a doc to help them out.

Three things to focus on when attempting to level up how your company approaches planning/roadmapping.

It’s important to avoid boiling the ocean as you start your journey of building a company from scratch. Thinking only in big, long-term goals will make planning difficult and overwhelm your team.

Instead try to break everything down into smaller chunks of work. It can be tempting to think in terms of goals like 

 but breaking that module down can make the goal easier to navigate. For example, perhaps the invoicing module needs the following.


Allow for printable PDF versions of the invoice

Send email notifications when invoice is billed

Send email notifications when invoice is overdue

Allow users to customize the sales tax logic

Account for discounts at the time of purchase


These smaller units of work allow for you to start to see a map toward your destination, thus aiding both your roadmapping and the day-to-day rhythm of your team.

This also gives you more pieces on the chessboard. You now have more items to maneuver when it comes to figuring out what’s in or out of a MVP (or other milestone). Deciding if invoicing as a whole is in a milestone is a tougher (and more tense) conversation than deciding on when to account for discounts.

Seeing all the pieces explicitly defined also gives you a chance to see dependencies among them. Building out overdue notifications might be significantly easier to do if you build out billing notifications first. Knowing that once again allows you to maneuver when it comes to piecing together a roadmap.

It can be easy to fall into the habit of letting deadlines be a hammer that you beat your team over the head with repeatedly. As a result you find your team scrambling and working late on a Thursday in order to meet a deadline on Friday.

The point of deadlines should be to help make sure you are doing the right work, not to make you do more work. If a deadline is Friday, ideally your team recognizes they’re not going to make it on Monday. (Note: this is more likely to happen when your deadlines are centered around small chunks of work.) This should then force conversations on what is and isn’t important for Friday.

These are good conversations to have and you want to have them sooner rather than later. Knowing that a part of a feature is tougher to build than thought is the exact type of knowledge you need when roadmapping. Setting firm deadlines will force that info to bubble up.



If you’re chunking your work up into small bits and using deadlines to force conversations about the realities of that work, the last piece of the puzzle is to build an iteration mindset into your team’s culture.

After as many deadlines as possible, you want to take a moment and look back on the work itself. Was the deadline unreasonable from the get go? Was there an unknown that bit us that we should have foreseen? Is there a certain type of work that always breaks our expectations? These are the type of questions that you want your engineering culture to routinely ask.

The most direct way to build this habit is to lean into regular retrospectives. At some cadence set aside time on the calendar for the team to reflect on things since the last retrospective - i.e. a retro after every sprint. This at least reserves time for your team to think about iteration.

But an invite on the calendar is only part of what you’re looking for. You want to make sure you’re building a blameless environment that way your team feels safe to come up with new ideas and critique the current processes. These are key for truly iterating on your team’s processes.

You don’t want someone to withhold a critique like 

The deadline was way off out the gate because of X, Y, and Z 

because they fear reprimand. You can tell your team that the convo is focused on improving the team, not judging the team. But it likely won’t sink in until you’ve had a handful of retros under your belt. (Actions speak louder than words on these types of topics.)

Once your cultural muscle memory around iteration is built, you’ll be able to a more agile organization. The small chunks of work (and the deadlines around them) will give you multiple opportunities to pivot and retros will be the lever for deciding when and how to pivot.


Holy Trinity of Dev Team Planning at Fractal

Three things to focus on when attempting to level up how your company approaches planning/roadmapping.

Small chunk

Sign up to see more