Just Begin: How to Fight Design Paralysis
Do you frequently find yourself stuck without being able to execute? This post is for you! Read on to learn about how to cut through decision paralysis!
When I typed out the title for this post, I realized that the subtext could be "fight procrastination". I personally find that kind of content online to be unhelpful and a little annoying 🤦♂️. That kind of content is akin to "Are you sad? Then stop being sad" 🤣. It's not always easy to fight procrastination and tackling it is a much broader topic than this post.
Rather, in this post, I will tackle the more specific problem of engineers finding themselves stuck in "design mode/decision paralysis", rather than execution mode. That may or may not be due to procrastination, but I'm gonna focus this post on the case in which the "stuck in design mode" behavior is not due to procrastination. I'll explain how an engineer may find himself/herself in this position and how to work his/her way out of that.
Where does the problem begin?
As in all things in life, balance is important and that is absolutely the case when it comes to implementing new features in your role. There's a spectrum between continuous code generation and tech spec writing. You shouldn't be just trying to submit new code immediately (although that would likely have some checks and balances anyway with code reviews), and you shouldn't be just continually writing tech specs to solicit review from your team. Either extreme is not good for sustained output at a high quality. This balance is hard to strike, especially as the complexity of features you need to implement increases, or if you have to start working with more arcane tech stacks.
As indicated by the intro to this post, we're gonna talk about the right end of the spectrum mentioned above: being stuck in design mode.
The engineers who are in this position are absolutely coming at it from multiple perspectives at the same time: Considerations in their minds might be:
Wanting to make a good impression on their team by implementing a rock solid feature/system/etc.
Not wanting to create more tech debt
Making sure to identify all use cases, edge cases, etc.
Not feeling as though they have enough clarity to begin writing code
How to detect if you're stuck in design mode
The answer to this question is fairly simple, which is a good thing!
If you have been annoyed for some time that something has not been implemented yet.
That's it. It's that simple. If you are a driven individual and you want to achieve your goals, then that feeling of not having made progress may indicate that you have been in "design mode" for too long.
Note:
If you feel this way due to perceived pressure from your team to build something, then that is not healthy. You are the one in the driver's seat and it's your project to execute on. That means you can set your goals, align them with your manager and/or PM, and then work away at them. If your inner monologue is saying, "Oh my god, it's been too long that the feature hasn't been implemented, my team is gonna get so angry at me." then you should absolutely address this with your manager or a trusted team member. More often than not, they will jump in to help and unblock you because you win together as a team, not separately.Steps to start writing code
When you've been in design mode for awhile, and then you detect that you are in fact, stuck, then you're already on your way to being able to implement what you have to. These are a few steps you should take:
Take a step back and just write down (or type) your thoughts somewhere else. Stream of consciousness is perfectly fine! The goal is just to pull your thoughts from the deep recesses of your brain and address them when you can see them all consolidated in front of you (almost like how Dumbledore pulled his thoughts and memories into his Pensieve; any Harry Potter fans in the house 😁?).
You will likely start seeing that there are a lot of dependent, entangled things that could be contributing to that feeling of being stuck because you just don't know how to proceed. Maybe you're dependent on some team to implement a feature, but they can't do it until another team helps them with something they need, in order to be able to write the feature that you need. Maybe you need to refactor something in order to develop a new feature, but refactoring will break API contracts for other teams that use that API. There could be many reasons for you to feel stuck, but identifying those reasons is the first step.
Once you have identified the blockers, make sure to concretely define them, either in prose, or through dependency diagrams, or both. The reason why you want to do this is to help yourself and potentially anyone else you need to loop in. Concretely defined problems are easier to solve than ambiguous ones.
Start a discussion with your tech lead, manager, mentor, or another teammate regarding the blockers you have identified. They will likely have some ideas on how to start taking action, or may recommend chatting with another person to surface one or more of the problems you found. Keep talking to people until you have an idea of something you can do.
Once you've got that idea, try prototyping something in code to test that idea. You'll find that even if it doesn't work, it actually was successful in a sense, because it provided you the activation energy you needed to begin coding, to begin doing. This is absolutely a win for you and you should use it to propel yourself into the next thing you gotta execute on, whether that's another prototype or the next feature of solving the problem (assuming the first prototype was successful).
Keep stakeholders and your manager in the loop as you continue exploring the problem space, cutting through ambiguity, refining your understanding, and executing toward your goal.
Even as you generate steam to push your inner flywheel, make sure to take breaks to recharge. They could be as simple as a short 30-45 minute workout after you have completed a train of thought. It's a little counter-intuitive, but to sustain the progress you're making, you can't just continuously code. Make sure to be in tune with yourself, your mental health, and your energy level.
Word of caution: Patience is a Virtue
Sometimes you're not stuck. It's just that the thing you have to achieve is difficult because of a lot of moving parts. This is a fairly common phenomenon once you get past a certain level of experience/seniority because the projects you take on get more ambiguous and likely more ambitious as well. They tend to have larger scope and require buy-in from stakeholders, as well as active communication. That just takes time. There are ways to communicate more effectively to reduce the amount of back-and-forth, but generating that alignment can take time.
That doesn't mean that you can't take any action while all of this discussion is going on. There are probably some small pieces you can take on, or even some educated guesses you can take on the parts that you don't entirely own, but are necessary for success. And the best part is: if you take that initiative, people will tend to gravitate toward you and follow you because you are the intrepid leader. You're the one hacking away at the metaphorical vines in the jungle of ambiguity, defrosting the windshield during a cold night, lighting a torch in the darkness, <insert some other visual imagery for "making things clearer" 🤣>.
The first step is to just begin. Enjoy the journey!