How do you create a scalable tech team capable of tackling and building on thousands of lines of your own untested code? If you’ve ever faced this question, you know how daunting it is — so I’d like to share some lessons from my own experience.
In high school, my friend Neal and I started a company together. Initially both he and I coded, but soon we split up our responsibilities: He promoted our website, and I continued the technical development. This worked out great at the time; together, we could run all aspects of our startup. We didn’t need anyone to help us, nor did we have to pay expensive developers or outsourcing firms to build out our product.
Seven years later, we decided to pursue our company full time with the same self-sufficient approach. For a while, it worked well. Other than a of couple hires, we maintained control of our development and could move quickly. Emboldened, we decided to raise our goals — higher revenues, new products, and more features. And to do so, we were going to hire a lot more developers. This was going to be exciting, right?
Except it wasn’t.
Frowning, I looked at all the code I had written. Thousands of untested lines of code, full of shortcuts that only I knew about, written in a style that would stymie even the greatest developers. I looked down into the abyss. How will anyone build on top of this mess I built?
Compelled to meet our goals, I began the long process of extraction. Now, years later, we’ve finally overcome the complications of a single tech co-founder. Here’s what I’ve learned:
1. Start the new stuff off on the right foot
The first rule to follow is to not increase your technical debt. Technical debt is code cruft you’ve built up over the years that needs refactoring. However, your goal shouldn’t be to immediately reduce your debt — this will take time and you have more important things to do, like create features that increase revenue. Just like in personal finance, reducing debt is a long-term goal. Your short-term goal is simply to not increase your technical debt.
That means that for new features, start them off the right way. For every new class you create, add tests; add docblocks if you need to; follow a standardized set of coding styles. That way, it’ll make future refactorings less painful.
2. Move on to to old but easy stuff
Eventually, you’ll want to tackle that technical debt. Don’t go after the whole hog at once. If you want to build a new feature that relies on some older code, improve only the places you need to touch. Over time, you’ll reduce your long-term debt without becoming overwhelmed.
3. Find the right first hire and build from there
Everyone tells you hiring the right people is important. If your goal is to get your dirty code refactored, find someone who knows the tools and code you use and has a really amenable personality. Engineering talent is important here, but having patience and a good sense of humor is going to be critical as well. It will take a long time to find this person, but that’s ok — you only need one. After that role, mid-level engineers who are highly tech-oriented will be able to depend on this person.
4. Be generous with your time
As you hire, you need to spend double the time explaining and re-explaining the same thing over and over again. You’ll be surprised at how hard it is for people to understand the nuanced domain knowledge you have combined with the “interesting” way you coded it into the application. Or maybe you won’t be surprised. Either way, overcommunicate.
5. Eventually, all that’s left is the core. Wait for the right opportunity to kill it.
Once you have a team in place, they’ll start helping you. Over a year or two, you’ll start to see that your codebase has transformed from one you built to one that your team has built. But you’ll still find that there are core components that people have been too afraid to touch — they’re too deeply embedded in the system. Maybe people attempted to change this in the past but ran into difficulties and there’s a sense of reluctance to go back in again.
How do you solve this? Well, it turns out that the best solution here is to wait. Keep the product humming, and you’ll find there will be a opportunity that presents itself that will let you bypass some of that old code. Maybe your authentication system is that core — suddenly your product team recommends switching to Facebook login, and you get to ditch some of your old work. Or your product pivots and the old code is no longer relevant.
Going from being a sole technical co-founder to a tech team manager isn’t easy, but hopefully these guidelines will help you along the way.
Darshan Somashekar graduated with a B.A. in Public Policy from Brown University. He has worked as an Associate Consultant at Bain & Company and co-founded the company drop.io. He’s one of the co-founders of Imagine Easy Solutions and manages the development team.
The Young Entrepreneur Council (YEC) is an invite-only organization comprised of the world’s most promising young entrepreneurs. In partnership with Citi, YEC recently launched StartupCollective, a free virtual mentorship program that helps millions of entrepreneurs start and grow businesses.
VentureBeat’s VB Insight team is studying marketing and personalization...
Chime in here, and we’ll share the results