10 characteristics of strong Founding Engineers
What to look for in your starting team
When you start a company or a new product line, you have to decide if you build something to prototype or you build for scale. The two approaches can be at odds with each other especially if all you’re looking for is that quick feedback from the market to see whether or not what you’re doing is the right thing or not. No one wants to spend time on things that do not work.
One approach is to get to product market fit at the cost of building things the “right way” or “architecturally responsibly”.
If this is an absolutist position you might be unlikely to shake off the effects of this early decision even much later on in the life of the company.
On the other hand, you don’t want to invest too much time in the perfect system design you miss sight of the goal of what your company you are trying to build.
Ultimately what you need is the ability to iterate fast so you can adjust to the vagaries of the business while making technical decisions that you will not be encumbered by in the not-so-distant future.
In this illustration above, I am weighing creating value vs moving fast “responsibly”. The key word here is “responsibly” which involves also giving thought to mid-long term technical growth as well. When you weigh creating value against moving fast, there are broadly 4 types of outcomes -
High Craftsmanship, High Value (top right) - If you get this, you are all set. You are well positioned to create value, while building a strong foundation for the future.
High Craftsmanship, Low Value (bottom right) - While this is low value, this is might not be bad a place to be. You are able to sacrifice value for craftsmanship of development and experimentation, which might result in longer term value.
Low Craftsmanship, High Value (top left) - While you are producing high value outcomes, the risk of poor engineering could be debilitating and ultimately not a good overall outcome.
Low Craftsmanship, Low Value (bottom left) - If you are both not producing value or inculcating good engineering practices , this is the worst of all worlds.
So now you need to find people who can help you build valuable things quickly while ensuring a strong technical rigor.
Who are Founding Engineers?
Founding Engineers are the early engineers that you hire for your new company or assign to your new product lines. They are the people who are in charge of understanding what the business needs are and what tradeoffs to make in order to reach those goals. They are also heavily responsible for the initial foundation of your technical architecture, in terms of designing and building it.
I have witnessed first hand the luxuries you can afford if you make certain key decisions well early in your lifecycle. The platonic ideal is to ensure making the right technical foundational decisions, while helping move the business goals forward. Not doing so could result in a very shaky base which could be disastrous later on.
You can’t just rest on the laurels of your efforts early on and you need to make a conscious effort to ensure that that rigor is maintained through the course of daily execution.
This post is focused on first principles that I believe every Founding Engineer should have to ensure you aren’t compromising on quality for the sake of perceived velocity.
🟢 Keep things as simple as they should be until they can
Don’t fall prey to using the shiniest languages and frameworks to build your prototype/MVP. Stick to the tools you know best. It is easy to chase after the Rusts, GraphQLs, Protobufs from the get-go, but if thats not where your skillsets lie, do not use this as an experimental period to learn about tech while also ascertaining whether or not your MVP will work. The other category of “do not use” is things that involve using a bazooka to kill a fly kind of problem. For example, don’t use Kubernetes when you have an application that services 5 users. You don’t need that complexity, you don’t have that awareness of how/why you should tune your clusters and you certainly don’t have the need that justifies it.
Additionally, it is super important to keep the tech sprawl as low as possible and not have tech proliferation just for the heck of it. The cost of chasing the shiny toy can be very high. In terms of software practices, don’t abstract and create patterns unless you have to — direct implementations make it easier to read and make it easier to modify since you are still in the early stages of discovery and you don’t want to overfit to bad initial assumptions.
🧪 Introduce great testing practices
It’s easy to say “of course you need to test your application” but it is shocking to see how often this ends up becoming the first casualty in the name of velocity. Writing unit tests when you can quickly eyeball whether or not something works, feels like an unnecessary step. Additionally, unit tests could be easily gamed — ”I have 100% coverage” which still doesn’t really cover anything meaningful. On the other hand, having a robust functional test suite establishes a strong contract very early on between the business and the engineering team which is a healthy relationship to foster early on.
🏗️ Infrastructure as Code
Right behind testing, one of the other mistakes is not automating your code deployments and infrastructure. It is almost trivial to spin up things like Netlify or Digital Ocean to have cloud environments where you can deploy your applications. In addition to that, with tools like Github Actions or Travis CI having snazzy UIs to deploy your applications, you can very easily get sucked into doing all of these adhoc.
However, I think the provisioning your clusters and maintaining your deployment pipelines in code is of paramount importance to set the right tone for the long term health of your codebase. This helps hook in additional steps like testing or other forms of validations, that are reviewable through code. It allows you to not rely on “that guy” for their god-level permissions or for seamless transition to other platforms incase your business requires that in the future.
📊 Amazing Observability
Hooking in logs and traces as part of your initial development process will pay dividends later on. There was an engineer I had worked with who had said — “If you write code while thinking of testing it, you will write it a certain way. If you think of performance or observability or cost, you will write it a certain way”. Trying to keep this aspect of programming active as you build out your codebase is critical. This will not just help you get the right signals to determine service health and uptime, but it will also drive the rigor of feature adoption. Noticing how business metrics and KPIs can be gleaned from the outcomes that you are experimenting with will help build a team that is in tune with the direction of the business.
🔂 Mono-repo/lith until you really can’t
There is a fascination for microservices because its always hyped up from the perspective of “scale” or “cool tech”. However, most problems can be solved by staying single repo, single monolith until you cannot. Premature optimizations for the sake of it, will cause you to accrue so much cruft later on in the life of your company that you might never be able to fully get it back to a state that makes it easy to manage the codebase/services.
🤑 Build only if you can’t buy
Money can be tight early on but, as much as you possibly can, you should try to buy off-the-shelf products. It is attractive to build things from scratch, but the untold costs of maintenance, extension and debugging gets lost. If this is not a critical piece of your Intellectual Property or your value proposition, don’t waste time building it and instead invest it in a product that you can buy whose sole purpose is to do the thing you want to do.
⚙️ Automate if you can avoid toil
As much as possible and as early as you can, you should start automating things that you end up doing repeatedly each hour/day/week. This could be running processes or tasks that are required for the business or your software development lifecycle. There is certainly a risk here of over-engineering your automation routine in the name of elimination of toil, but if you are cognizant of what should and shouldn’t be automated, that sets up a great foundation.
🔐 Security as a first class citizen
It’s all too easy to store your credentials in envvars and/or not be too rigorous about how you maintain secrets and sensitive information. However, using encryption for your most classified information, and maintaining that through code as much as possible, will benefit you down the road. There are other elements of security such as certificate management that should all be thought about as soon as you possibly can. Security tends to be (and likely rightfully so — since things like penetration testing don’t impact you as much in the early days) a topic that no one wants to really talk about — but that shouldn’t preclude you from ensuring you do the due diligence for building your applications with some basic security checks in mind.
🔍 Show your work
Finding ways to “show your work” in the early days so that its easy for you or your co-workers to trace how things come to be is an extremely useful pattern to follow. Whether this is through metrics, reporting or logs, being able to have information to follow the breadcrumbs for an event sets a standard for operation — with regards to transparency and observability.
🪖 Be extremely opinionated and be consistent
Starting something new is no time to allow for opinions that aren’t strong. Strong technical architectures are built by experienced people who have strong opinions for the right reasons and who are consistent in their way of thinking, even if it is patterns they haven’t encountered before.
Finding engineers who are capable of doing all these while moving the needle is hard. It should be noted that strong engineers don’t need to be founding engineers but founding engineers need to be strong engineers.
I am sure there are some other key characteristics of strong engineer. If you have encountered that I would love to hear what those are. Please drop them in the comments below!
If you liked this article, please like ❤️ / restack 🔄 to spread the word!