The Job Every Aspiring Technical Founder Should Try

INTERSECT helps businesses create and deliver exceptional digital products that marry business objectives and user needs. Learn more.

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.

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.

When I should’ve spent an hour evaluating my progress and figuring out if/how I need to need to adjust my plan, 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, I just spent that hour writing more code.

The Growth Opportunity

Okay, let’s break down my recommendation and how it will benefit you as a 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, our team is actually hiring, so if you’re interested, check out our openings.

2. Type of company: Agency-Side

A lot of 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 to 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.


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.

Also, if this has sparked your interest to work with some pretty great people while building innovative and cool products as a Solutions Architect, Intersect is hiring for this role and many others right now. Check out our Career page.