Before coding anything, make sure you’ve involved a decision maker, the person doing the work, someone with context, someone with fresh perspective, and whoever is going to be maintaining it. These are the five essential roles for planning a technical project. One person can cover all of these things with one exception: you can’t have context and fresh perspective at the same time, so at a minimum you need two people involved.
I’ve been part of several dozen projects, from the smallest application’s new feature to massive product launches, and regardless of how agile you are or desire to be, there’s always some amount of planning necessary to establish what you’ll be optimizing for and the constraints you need to factor in. Oddly, though, I find that in a rush to learn and produce, thorough planning gets a bad reputation for slowing down velocity or preventing progress. I won’t disagree that we can take discussions well past the point of usefulness, and I’ve seen that happen many times, also. The trick is to efficiently discuss what is known, and when moving into unknown territory, figure out next steps and get moving, and adjust as you learn. Still, the risk of not investing time in planning is missing out on a chance to collaborate instead of duplicate effort, reuse or enhance instead of create new, take on more technical debt unknowingly, and stall progress merely by alienating colleagues and damaging the culture of innovation and partnership.
Whenever plans come together, what I often find interesting is the variations of planners involved. Sometimes there’s one main designer or architect, other times it’s an entire committee or working group. No matter what size of effort is about to be undertaken, there should be at least two people involved in any decision about its direction and implementation. This doesn’t mean two or people need to agree on the decision. I’m a big fan of making it clear who the decision maker is and empowering them to drive the work forward. And part of the reason I’m comfortable doing that is because of this “role model”, or the working model I use to make sure the right people are involved. There are four roles to cover for any planning decision, and two of them are mutually exclusive, so at a minimum it has to be two people involved. And the first one to settle is who the decision maker is, and make sure that they’re aligning with your customers or product team and stakeholders.
The next role is the one I see most often play all the roles including decision maker. This role is The Doer, the one who is going to create the technical implementation or representing that team. Having the doer play all the roles is the most important pattern to avoid, because the largest missed opportunities come when we neglect to factor in that it’s nigh impossible to represent context and fresh perspective at the same time. Curiously, I’ve also seen situations where The Doer isn’t actually involved until after the decision is made by others and work is expected to start – please don’t do this, either.
The checkin at this point is vital: whoever is involved at this point, are they bringing in context or are they bringing in new ideas from experience elsewhere? Whichever way that goes, the key here is to put the time in to actively obtain the other point of view. This doesn’t need to take anywhere near the amount of time estimated to complete the work, so keep it light. But do not skip this. This also doesn’t mean the decision maker needs to include any or all things that come up from seeking alternate perspectives, either. The process is merely meant to front-load discovery to give you the chance to make adjustments early.
What if you’ve got new ideas, but the person with context is no longer here? Ideally they’ve left a legacy of information, and making time to go through that will cover that angle. If that doesn’t exist and there’s no one else to consult, then obviously you proceed despite the disadvantage. The point is to make the effort rather than risk missing the lessons learned or concurrent solutions happening elsewhere. And what if you’ve been working on this for years and this work needs to get into an area that isn’t well understood? Find a partner willing to hear you out and question your assumptions and plans.
And finally, don’t forget engaging the people who will keep the system up and support it. If this isn’t covered by anyone already engaged in figuring out the solution, then don’t go any further until they can weigh in.
By taking these steps early, not only can you set the work up to be more successful, as with anything you increase the diversity of opinions on, you also can build trust and gain buy-in by showing who was involved and the thought that went into the decisions. Add a step to make sure these roles are covered before signing off on a design. Even a five minute conversation can help fight bias in your solution from the start.
