👨‍💻 The job every aspiring Technical Founder should try

After my second startup failed in 2016, I found myself doing something I never thought I’d do — taking a full-time job. You have to understand, I’d spent all of my entire professional career up until that point working exclusively in the startup world — much of it as my own boss (and determined to keep it that way) — and so getting this job felt a bit like I was admitting defeat in some way. But after over a year in my current role, I’m happy to conclude that this has been a really good move for me. So much so, that I’d like to share the following recommendation:

If you are an aspiring technical founder, you should consider spending some time as a Solutions Architect at an agency-side company before you do your next startup.

To explain my recommendation, first, let’s dive into the most common mistake that technical founders make when building a company. Then, I’ll elaborate on how you can double-down on lessons learned with this recommendation.

The Technical Founder’s Achilles Heel

By far the most common mistake technical founders make is this: they over-index on writing code, and forget to do “everything else”. I was guilty of this in 2016, and many incredibly intelligent founders I know in the Toronto ecosystem are guilty of it too.

When I should’ve spent an hour evaluating my progress and figuring out if/how I need to need to adjust my plan, instead I just spent that hour writing more code. When I should’ve spent an hour talking to customers and understanding if I was actually solving their problems, instead I just spent that hour writing more code.

If you are a solo technical founder, the ratio should be something like 20% writing code to 80% other activities, instead of the other way around. Remember, the goal of starting a business is not to build shit. The goal of starting a business is to create a profitable feedback loop between providing a product/service and getting paid by customers. And that takes a lot of planning, conversation, and course correction. Yes, one of your Herculean tasks is to get shit built, but the “coding” aspect is actually just a small portion of what it takes to assemble that profitable feedback loop. As a founder, you must have ownership over the entire process — not just the writing code part.

If you haven’t done your first startup yet, you might not see it, but the symptom I described above is a very real problem that all technical founders are susceptible to. Sometimes writing code is just more fun. Sometimes, we simply lack the experience to know there is a better way. Sometimes, we know but just forget, because our egos get in the way of using our time wisely.

Or, if you’ve already done a startup, maybe you can already relate to the problem.

In any case, avoiding these traps is a muscle that you can practice. If this resonates with you, please read on.

The Growth Opportunity

Okay, let’s break down my recommendation and how it will benefit you as an technical person in the business world:

If you are an aspiring technical founder, you should consider spending some time as a Solutions Architect at an agency-side company before you do your next startup.

There are two key aspects to this recommendation: “Solutions Architect” and “Agency-side company.”

1. The role: Solutions Architect

This is pretty much a role where you do all of the things that a software engineer might ever do, except for the writing code part. You spend your time gathering technical requirements, identifying an architectural solution to fulfill those needs, helping sell the client on it contractually, and finally guiding an engineering team through building that solution architecture. Basically, you do all of the planning, and none of the coding. In this role, you get really good at planning and oversight. Some profound lessons I’ve personally learned are:

  • Thinking about software in terms of RISK. As an aspiring entrepreneur, it is tempting to drink the coolaid of unending optimism. But while optimism is a necessary ingredient to creating something new, it must be grounded in reality. That’s where risk comes in. Instead of thinking “how quickly could I build X?”, thinking in terms of risk leads us to ask “which part of this project is most likely to cause me trouble?” The former is ego-driven and often leads to unrealistic expectations and missed deadlines. The latter is a tougher question to ask but often leads to better outcomes. Think “professional paranoia.”

  • The cost of taking shortcuts. When you are a lone-wolf writing code in a scrappy startup environment, it’s easy to take shortcuts, skip certain planning phases, and make up for them later on your own time. In truth, this is sometimes necessary to make shit happen. However, do you really know what price you’re paying by taking those shortcuts? As a solutions architect, when you take a shortcut in planning, it is usually multiple other people in the engineering team that pays the price. This incentivizes you towards good planning, rather than towards spending more time writing code. It teaches a higher level of awareness over what the critical path really is, and what price the entire project actually pays when you make these compromises.

At some companies, this role is referred to as “Technical PM”, but at Symbility Intersect where I’m in the role, it’s called “Solutions Architect”. At the time of writing, the team is actually hiring, so if you’re interested, check out openings.

2. Type of company: Agency-Side

A lot entrepreneurs subscribe to the idea that they should always be working for a startup — whether it’s one that they founded themselves, or by someone else. I know, because that was me too. And if it’s not a startup, it has to be a product company. It makes sense — surround yourself with like-minded people, right? Yes, but to a degree — it can be counterproductive to over-index to polar extremes. Consider these benefits of spending some of your time at a well-established agency-side company (e.g. a “dev-shop” or “consultancy”):

  • Process. If you spend too many years in small and scrappy startups, you’ll never experience good process, and you’ll never know how big of a difference it can make. Agency-side companies are especially good at this, because they have to spin up teams very quickly to fill client needs, and teams can only be spun up quickly if you have tight processes on lock.

  • Iteration. At product companies, it is commonplace for software developers go years on a single project with the same team, without being exposed to anything different. On the other hand, because software agencies go through so many different projects, typically with a different team each time, you get to iterate in a way that isn’t possible in a product company. At Symbility Intersect, I’ve been on almost 10 projects in the past year and a half. With each of those projects, I got to experience working with different teams of different configurations, try new approaches to process, and learn the lessons from when things go wrong.

Recap

If you are an aspiring technical founder, and you want to do a startup — stop over-indexing on the “building shit” + “optimism” formula, and get good at planning and process first. You can do that as a Solutions Architect. And if you want to learn fast, an agency-side company is a great option.

P.S. So Anson, is this your way of telling us you’re starting another company?

No, not quite yet. But I am way more prepared to start one today than I was 3 years ago. I have more to say on this topic, but I‘ll save it for another post.

🙌 Thanks for reading! 🙌