Reflecting on my first year at my first startup

I always wanted to work for a "startup", the HBO series Silicon Valley makes it look so much fun, and it inspired an entire generation of engineers to want to pursue that lifestyle, including me. After a few years at the Royal Bank of Canada, a close friend of mine referred me to the CEO of Pine, a seed round FinTech looking to disrupt the mortgage industry in Canada. From there, I interviewed and was eventually offered the position "Founding Engineer" as the first employee of Pine.

Today, about 13 months later. Pine has 26 employees, 7 of which are on the engineering team. In this time, I've helped build entire systems, refactor them & throw them out. Now it's time for me to reflect on the year, what I've learned, observed and experienced.

The idea vs. the execution

If you would have asked me 2 years ago what one of the most important part of a startup is, I would have said "the idea". The idea is this magical thing that determines the success of your company because ultimately it's what is unique about your company right?

It's what your company is, it's your idea. Well, yes but really no. Your company and its fate lives or dies on the execution of the idea.

My first exposure to this was when my co-founders shared their investor deck which they used to raise their seed round. While this deck included slides about their idea, it also included a lot of details about them, the founders, and how they have the expertise, experience and know how to execute the idea.

Overtime, as I thought about this more I began to see this pattern everywhere. A lot of companies will build, or even copy ideas from other companies, but it all comes down to the execution of the idea.

At it's core, our companies plan & "idea" is to build a digital first mortgage experience which should hopefully lower our operation costs and allow us to deliver a better experience with tech while passing on some savings to our clients. A digital mortgage experience is not new, in fact, most if not all the traditional big 4 banks in Canada have some form of a online mortgage experience today.

Where Pine will make it (or not) is in the execution of our idea. Building the best mortgage experience that is unrivalled by current offerings and executing on this idea across the entire home buying process.

People and their roles

To execute on an idea, you need people. You need engineers, product managers, ops & others, all laser focused on one problem.

Hiring at a brand-new company is quite the feat, because nobody knows who you are yet. You have nothing, no digital presence, and you may even need to convince people you actually do exist and are not trying to scam them. Most of the hiring we did early on was through our own personal networks (friends and old colleagues). Out of the first 10 employees, only one had been an out-of-network hire. Hiring this way was great. At the size we're at, one bad hire can ruin everything and you mitigate a lot of risk when you hire people through referrals.

Within our engineering team, the majority of people were hired at the same "level". Since all our hires we're experienced, everyone was classified as a "senior developer". It's really common for startups to have "flat" org structures & avoid or put little relevance on job titles. The idea is that there's less middle-managers, less unnecessary process, less invisible communication barriers and ideally everyone feels equal.

While I like this idea of a flat structure & title-less roles in theory, I think it's extremely hard to get right. What I've learned, is some people just want specific job titles. Even though it may just be text on a screen and seem meaningless. Job titles and levels are a way of recognizing work & experience. After talking with other colleagues, I kind of get it. People who used to be a "Staff Engineer" don't want to post on LinkedIn their new job title of "Software Engineer" because it seems like a demotion and could hurt them long term when looking for their next job. Another challenge I thought about as we were discussing this structure was our appearance to outsiders for recruiting. We don't want to lose new talent over a silly job title or decrease our SEO on job postings because people are looking for "senior" or "staff" level positions and our job titles omit those keywords.

I've learned that org structure, job levels, etc, go hand in hand with culture. They are something that may not seem necessary logically, but the human element of a company may deem it so.

The other difficult task with flat org structures is operating and having everyone believe in it. While the org structure may be flat, if some people are invited to meetings that others aren't, it can be perceived as that person being more important or higher level which can invalidate the whole point of the flat org structure.

Another observation I experienced was watching our engineering team grow to 6 senior level engineers. Up until recently, we hadn't hired any non-senior level engineers. Naturally, you would think that only senior level engineers means that productivity will be great. While I don't disagree with that, there are some dynamics that can slow down progress. As they should, people with lots of experience in the field - and are paid senior level pay - will naturally want to advocate their idea(s) to a solution. Having a diverse set of recommendations from experienced people with different backgrounds is something all companies strive for.

But for a startup, it can be unproductive if not organized well. We had times when a few different (all valid) solutions were proposed, and over the course of an hour or two we would spin our wheels discussing these solutions, effectively not getting any closer to a solution. In cases like this, it can be useful to have a decision maker who ultimately has the final call to make a decision. Having this person can prevent the "too many cooks in the kitchen" scenario from happening. Sometimes though, people don't see eye to eye on implementations and that can be tough to efficiently deal with. This can and does happen at every company, but with our team of 7 senior engineers I felt like it happened more than I had experienced in the past. Today, we're a lot better. I think that's because the expectations have been set and now everyone works between those lines.

Probably my biggest observation though from a people & operations perspective is how valuable it is for your engineers to understand the product in depth. At RBC, for my team of about 7 engineers we had 2/3 Business Analysts (BAs). These BAs worked for the Product Owner (PO) gathering requirements, answering any questions and in general ensuring that engineers understood what they needed to do their work.

This might not scale at your startup. Having a low ENG:BA ratio gets costly. Engineers who ultimately understand the product the best will be able to best design and implement new features. But with less process and BA support this can be tough. I think it's very valuable that companies take the time to really teach all new hires about the company and the product(s). When everyone has a small PO brain inside them, a better product will be made. Part of this is on each employee to take pride in understanding the "other side" of the business, and part of this is on the company to promote a culture where everyone should understand, challenge and work together when creating the vision of the product.

Process

Often times one of the greatest things you'll hear about startups and small companies in general is how there is very little to no process and your free to just get work done. But the question I pose to you is, when do you need process? Do you ever need process? How much process is too much process? This can be a loaded question but is something every leader needs to consider when they are looking at their teams and how they work.

I came from an employer with way too much process and then went to Pine where we had no process. Why? Because nobody had created it yet. In the beginning we didn't need it. But today, we benefit from some process. Processes such as creating Product Requirements Document (PRD) are a great way for the PO to organize features and communicate them to the eng or design teams.

There is this fine line between too much process which slows you down and not enough process which can also slow you down. Too much process, and you're spending time in meetings instead of building. Not enough process and your team might not be all on the same page, not running as efficiently as possible or just disorganized. This perfect line is different for every team. I think it's important that every team always be on the look-out for how they can better improve their process and workflow, which includes taking feedback from the team, reflecting, and re-adjusting.

Product & delivery

The last topic that I have is the product. My advice for anyone working for an early stage startup is expect to refactor, expect to throw out code and expect for requirements to change.

As a dev at heart, I take pride in what I build, and I never want to build something I believe is bad. But I have to remind myself that (at least in my case) we're not used by millions daily, we're used by dozens daily. Over-engineering is a serious delivery killer. I remind myself constantly that there's no point in building the most "optimal" solution (even though it would be the more fun) because today we don't have the users to justify it. By the time we do, the requirements could have changed or at the very least, we should have more time and money to build a even better solution learning from user patterns and the other data we've hopefully collected since releasing the first iteration of that feature.

At our stage (and in most cases), clean code > performant code.

Now on to year two

--