Transitioning from Opinion-Driven Development
- People love talking about ideas, but they don’t always want to take charge and make things happen.
- In meetings, there are many ideas, but no one is accountable, and nothing concrete gets done.
- Some people are afraid of success because it might mean more work.
- To fix this, team members should write down their ideas in detailed plans, called design docs.
- A design document is a complete high-level solution to the problem presented. It should be detailed enough that somebody who already understands the problem could go out and code the project without having to make any significant decisions.
- Authors should share the document gradually with team members one by one, starting with the people who may passionately support the idea.
- Stop having long “brainstorming” meetings; they waste time. Instead, give team members time to think and come up with ideas using design docs.
- After the whole team looks at the document, set a limit on how long to keep talking about it.
- If someone doesn’t like the solution, they need to suggest a better one. If not, the proposed solution is accepted.
- If there are lots of comments on the Design Doc, it might mean the solution is not good. The author should go back and get everyone to agree before involving more people. This alignment must happen on a 1o1 basis.
- Different design docs can solve the same problem, so team members need to know to avoid doing the same work twice.
- Sometimes, having many proposals helps in comparing and making better decisions. It’s a good exercise.
- If proposals are similar, team members can work together.
- Design Docs should be easy for everyone, including business people, to understand. Technical details must be added at the end so that they can be skipped by non-technical stakeholders.
- Authors should not spend too much time overthinking the document; a few days of focused effort should be enough.
- The Design Doc is just a proposal, the team doesn’t have to implement it just because it was written. A rejected design doc is great progress by the team, as collectively they are aligned on what not to do.
- The presence of Design Docs does not merit its prioritization. Meaning, that you not should work on the solution just because you have a design doc. Prioritization is always decided based on business impact.
Design Doc Evaluation Checklist:
- What’s the problem?
- Who’s facing the problem?
- How are they currently circumventing it?
- ASAP or ALAP? How urgently does this problem need solving?
- What percentage of your customer base is facing the problem?
- Who aligns with you on the problem? (Customer alignment is crucial for problem-solving.)
- What’s the output?
- What’s the outcome?
- Does your solution address the core problem?
- What problems won’t the solution solve?
- What additional problems might it create?
- Is your solution simple enough for junior developers to implement?
- Can your solution be broken down into iterative steps, providing incremental customer value?
- What’s the maintenance effort on the solution? Is additional training required?
- Build vs buy: Are there existing solutions available in the market?
- Who aligns with you on the solution? Customer and team alignment are crucial.
The primary purpose of Design Docs is to expedite failure. Ideas lacking substantial potential should be identified early, allowing for rejection or iteration. Embracing this approach signifies success in the development process.