Technical founders often hear the same advice: Once the company grows, you’ll need to stop coding and spend your time managing. I heard it, but it wasn’t clear to me what I’d be spending my time on if I wasn't knee deep in code.
At my previous job, I was able to manage the people on my team and keep up my coding responsibilities by allocating my time carefully. In hindsight, I could do both because the company already had a functioning recruiting engine, engineering policies and culture, development infrastructure, and an executive team steering the ship. With that wind at my back, I had plenty of time to indulge in coding on the side while doing my day job.
As a technical co-founder, it was my job to put all of these pieces in place. That’s where the traditional advice falls short. “Managing” extended way beyond technical oversight and people.
Here are five things all technical founders need to do beyond being a technical leader and managing people:
Recruiting. Building a team from scratch and then doubling the size of that team every few quarters is an incredibly challenging task and a full-time job in itself. There’s no better use of your time. Growing is the quickest way to get exponential output from your team, take on more ambitious tasks, and innovate faster than your competition. The sooner you’re able to establish a scalable recruiting machine, the more likely you will be to succeed as a team and leader.
Defining and reinforcing culture. Your engineering team is going to have a very important subculture within your company. Each team is unique and values user growth, visual design, hacking and data driven decision making differently. Your culture is largely going to be defined by the behaviors you reinforce and discourage. Establishing your team’s values early will help inform your decision making and help you develop processes, policies, and language that will form your culture. For example, Inkling QA has always been done through rigorous test automation. Habitat, our largest application, has over 10,000 automated tests.
Establishing standards, tools, and engineering processes. Old habits die hard. Introducing team-wide policies like code reviews, code standard, or integration testing is exponentially easier at three than 10. The earlier your standards are established, the fewer people will need to be involved in defining them and you’ll have less code to migrate. Once established, new hires will help reinforce your standards instead of deviating from them. Provide clear rails for your team so that they are writing consistent, quality code from day one. Every day that passes without these guidelines in place is more technical debt you’ll have to pay down in the future.
Developing an IP strategy. As the technical leader of your organization, you’re expected to have a grasp on patent strategy and open source. You need to identify the unique and valuable differentiators of the technology you’re building and make sure you’re protecting them. Whether you support the patent system as it exists today or not, patents are an important asset to your business. Similarly, it’s important to understand how your organization will use and contribute to open source. Open source can save you from re-inventing the wheel and even recruit.
Being a business thought partner. Being a founder extends beyond your functional role and into running the overall business. It’s critical to understand as much business context as possible in order to contribute to business strategy and be a great thought partner to your other founder(s). Knowing what a 4019 evaluation is, being able to read a balance sheet, and understanding terms like ROAS, OPEX and EBITA will help you contribute.
When starting out, I neglected most of these responsibilities and was focused entirely on coding. Through a combination of difficult conversations with my co-founder and CEO Matt, hiring mistakes, and a few very painful arguments over standards, I began to realize the breadth of the role I had taken on. While I initially gravitated toward the areas of responsibility that were closest to my technical comfort zone, I now realize technical leaders need to be excellent at all five in addition to being a technical leader and managing the team.
Even with a complete understanding of what is expected of you as a technical founder, you’ll always be tempted to dive back into the code, especially during “crunch time.” As tempting as it is, it’s almost always better to focus on the long-term scalable solution to the problem, rather than reverting back to your old days. Remember: Stepping in and coding to meet a deadline will help you out on that one deadline; hiring an excellent engineer will help you on every deadline.
Another problem I struggled with was the sense of guilt that came along with delegating my coding responsibilities to my team in order to focus on the short list above. It didn’t seem fair to push large portions of the codebase on an already busy team.
After handing over the coding reins, I discovered two very important things that made me comfortable with delegation. First, I found that by delegating I was empowering them. It gave my team a very well received sense of ownership and demonstrated my confidence and trust in them. Second, since they were able to focus entirely on coding, they were able to get things done faster and better than me given all my reduced focus and other obligations.
SO GET OUT OF THE CODE!
