Scaling — insights from engineering (I)
Startup stories have always fascinated me. Every successful company contains a wealth of stories, often about the founders, the company’s origins, and all the ways plans have grown and changed. Sadly, the engineering perspective on those stories is often overlooked.
This is my second journey in a startup. I’ve spent 18 months on Social Nature’s engineering team, and today I’d like to share some of my personal insights and stories about the process of scaling from the engineering perspective. These insights may apply to all kinds of companies and software products, but I find these especially true for startups.
The business leads the way, and the technology follows
We all have heard great stories about genius coders and visionaries that built the products everyone recognizes and loves. I would argue that their genius did not come from the technical side, but from their ability to see the opportunity and action upon it.
It is the market that leads the way to building great products. Engineers build what the market needs to be built. That’s why Product Teams are so important, they translate the market needs for us. Especially when a company is still discovering its place in the market, having a dedicated team charting the rapids for us is truly helpful. Without them, we can get lost in solutions designs and architecture discussions that can make us proud but solve ultimately nothing.
An engineer’s job is to keep the machine running, reduce drag, and create new sources of thrust, but we are not piloting. Product, Marketing, Sales, and Customer Service are the ones looking ahead to where we are going, and our job is to listen carefully for their useful insights. Sometimes discussions with clients or even those hundreds of customer service tickets per week can be transformed into a feature or automation. We pride ourselves on being the smartest in the room, but our real skill is listening to the team and translating their insights and details into working software.
Workarounds are technical debt
Quite often a new business request arrives and our technology platform is still being prepared for it but isn’t ready yet. “Sales already promised to the client”, someone says. And we come up with a workaround: we unplug a couple of wires here and there, make a bypass somewhere, plug everything back, and there we go. The client is happy and we are Sales’ heroes.
But workarounds do not scale. What happens when instead of one, we have hundreds of clients asking for the same promise? Should we let it run like that? Scaling on top of a badly designed solution is like running a marathon wearing steel-toed boots: it will definitely slow you down.
More often than not, engineers let it run with the patch. And as time passes we grow what is called Technical Debt. This is work we will have to do at some point, we can not escape from it, and like financial debt, the longer we postpone it, the bigger it becomes.
Instead of allowing workarounds to become technical debt, we should always keep an eye out for signals on those pieces of our systems that are the foundational, money-making features, and those should remain well designed, without workarounds or debt. When the time for scaling hits, those building blocks are what we rely on.
For the most disciplined team, whenever a workaround is necessary, creating the “right engineering solution” ticket should be part of the process, so that we won’t forget it needs to be done.
Technical support is drag
I meant dealing with bugs. Having a long list of technical support tickets waiting for engineering time is no way to work. The longer we wait, the longer the list grows. Bugs need to be fixed, problems need to be solved, that’s what we do. On the other side, the main challenge of a growing Startup is to move quickly into the market by building new features and capabilities.
The technical support work consumes valuable time; it is frustrating, boring and drains out the team’s energy. Therefore we should try to keep the support backlog as short as possible by responding quickly and identifying which parts of the system need the most improvement. Then we execute a good strategy to refactor, stabilize, and protect using unit tests. Only then can we redirect our energy towards new projects: the fun part of the job.
Things move fast in Startups, and engineering teams are small. Being agile is not enough; we need to be smart and strategize at all times. These are some of the learnings I can share, along with a couple more coming soon in a second post. And to the engineers out there building great new products, I’d love to hear your stories and your struggles. That’s how we learn. Happy coding.
