1. Airplane Mode - No Proper Communication
Producing scalable, high-quality code is commendable, but it can conflict with business constraints like limited time or budget, especially in startups. That's why timely communication is essential. Work out a path forward together instead of hiding in the digital cave.
Scenario
Request
"We need Feature X to be available next Monday."
Your Estimation
At least 2 weeks of work.
Your Steps
Say nothing, try to have it ready in 1 week.
Possible Outcomes
a. Not done, rep down - You tried to write perfect code, cover all potential edge cases. Now, it's close to the end of the deadline, and you realize that you're not going to make it - business goal is not reached, and you got yourself a bad rep.
b. Task done, health gone - If you're "lucky," you push yourself too hard and have everything ready on Monday; you risk burnout.
There are a couple of potentially viable routes you could've taken instead:
- Stretch the Horizon - Discuss with stakeholders whether the deadline is flexible: can you extend it a little bit to have a properly implemented solution?
- Less is more - Discuss with the team and stakeholders whether you can strip the feature down and/or only deliver the most essential parts of it.
- I've got another confession to make... - If the deadline is dead-set and all parts of the feature are absolutely essential, clearly communicate that the probability of completing the task within the suggested timeframe is very low. But it's important to end the message with potential acceptable solutions and leave room for further discussion.
As always, there are exceptions. In the real world, it’s not always easy to have conversations about deadlines, strip down features, or communicate delays. Sometimes you just have to burn that midnight oil for your, the company's, and other stakeholders' benefit. Make sure the price you pay is equivalent to the gains.
2. Over-engineering - Designing a More Complex/Scalable Solution Than Required
Temporary, suboptimal solutions can sometimes be more effective than long-term, perfect ones. To know why, you need to first understand the startup mechanics. It boils down to:
- Build something impressive and in-demand
- Acquire new users
- Pitch your idea, impress potential investors with usage stats and shiny features
- Get investments to work on new features or improve/extend existing ones
- Start over
Usually, the deadlines for these cycles are pretty tight, so they require agility. Working on a more scalable solution might hinder the efforts to meet the expected goals due to the higher time cost.
That said, prioritizing business goals doesn't always mean sacrificing quality. The objective should be balancing solution quality with delivery speed.
Working in a startup requires skills like strategic decision-making and adaptability. It's crucial to understand when to invest in a more complex solution and when to go with the good-enough one.
After securing investment, startups can expand the team, hire specialized talent, and integrate tested solutions or services to enhance the product.
3. Tunnel Vision - Only Focusing on Tech Aspect, Ignoring Context
Your primary job as a dev is not just moving tickets to the "Done" column. You're more than just a cog in the machine; you're a key contributor to the product's success.
In order to deliver effective solutions, consider expanding your knowledge of the product domain. It’s essential to grasp the product’s concept, the problems it solves, and the profile of its target user.
You don't need jet fuel if you drive a bicycle.
If you're developing an admin panel, usually the blazing-fast performance and fancy animations are not the main concern. Similarly, if the project is a landing page for a coffee shop, you don't need 17 containers and a messaging queue system. If the primary users are elderly, the main focus might be a simple and legible interface, illustrative examples, and visual feedback on action.
Understanding the context and learning about different domains can boost your confidence, sharpen your decision-making, and help you contribute more meaningfully. In fact, this knowledge could even set you on the path to launching your own startup one day.
Afterword
You may find that the article contains a mix of opinions and facts. It reflects the author's (my) experiences in the startup world so far. If you notice missing points, areas for improvement, or inaccuracies, feel free to share your thoughts.
Top comments (0)