5 Learnings After 5 Years — Becoming a Successful Engineering Leader at a SaaS Startup
I have previously written “5 Thoughts After 5 Years — Building a Successful Engineering Team at a SaaS Startup” where I shared five key tenets to which I owe my current success as a technical leader.
Though, my success over these past five years was far from a foregone conclusion; actually, I had expected that I would fail a lot and from that I would discover the areas I needed to grow. My journey to become a better technical leader these past five years has taught me a few things, which are surprisingly not technical at all:
- Emotional intelligence is far more important than any other type of intellect you posses; it is the key that unlocks your full potential.
- Stagnation will lead to collapse; never accept a plateau in performance.
- An awesome idea can evolve into an equally incredible product but that does not mean it will be a success; success requires a commercial vision and plan, which is likely driven by product and engineering.
- Plan for scale, in every aspect of what you do; if you are not prepared for the eventual success of your product then it will never succeed.
- Know when to let go; holding on too tight to a single idea or approach can create a level of toxicity that no team or product can survive.
I would like to go deeper into each of these points.
According to Susan David, a writer for Harvard Business Review, we speak, on average, about 16,000 words each day. I think about a quarter of those words I might deliberately select. The rest fall into my ‘story telling’ which, according to family lore, I got from my grandfather. I am certain that I could better curate the words I use each day to create better stories — but that isn’t where I want to focus. Our unspoken words are the ones that I would like to delve deeper into.
Over the past five years, I have grown to be more selective with my spoken words in conversations with co-workers; careful to lift up, to encourage and to lead — nothing was surprising about having to do that as the team grew. What did surprise me was that as I did this more and more I started having unhealthy discussions with myself; I either was or had grown lazy in making sure my anxieties did not impact my thinking and from time to time I did find myself in a dark place.
I had never had to confront this as directly and as honestly as I have been forced to do over these past five years. There are an unlimited number of reasons in a startup, especially a pre-series A startup, that can drive negative thoughts, starting with things like: 1) how is our funding? 2) that bug is taking too long to fix, am I technically deficient, 3) hiring growth is focused in other cities, am I being left behind — an so. When you are in an early stage startup and tasked with ‘turning nothing into something’ you really will not have a deficit of doubt. But let’s work to make that doubt healthy!
I had to learn to identify when these negative thoughts were causing me to think and then act differently about any given situation. It is important to learn to grab hold of that feeling or internal conversation and not let it run away with you or visa versa. Let’s call this “recognizing”, as Susan David does in her article.
The next thing I had to learn was how to label these thoughts and then move on to accepting them. This is where your core values will play heavily, as well. Why? Because you must learn to act on those negative thoughts in a way that reflects who you are— instead of letting that negative coaching you have been offering yourself take control.
I’ll admit that having worked in large enterprise environments, government environments and even my own small business that I never had to face this. I was not even aware of it and it is likely the key reason I did not stay or grow in some of my previous roles. It took these past five years in a “nothing to series A” experience to finally get this.
I will call this my number one learning from my last five years and I encourage anyone just starting out in the engineering space or at a startup to really explore this before jumping in.
You can find the HBR article here: https://hbr.org/2013/11/emotional-agility
Stagnation will lead to collapse
If you ever find yourself showing up just for the paycheck, you are lost. I have not personally found myself in this position these past five years but I have seen some team members who came and went because of it. That plateau of “I made my contribution” is as toxic as an engineer who commits directly into “develop” without a peer review.
Every day should mean growth for you and your team; if you have plateaued in what you think you can offer in a startup, I would imagine you are not seeing the larger picture.
As an engineering hire, it may be tempting to think “you just write code” — let me assure you that if you only bring that value in your position you will soon find yourself looking for employment. Engineering hires, especially early in the startup space, are many things, or should be. All at once you will likely have to play the roles of CTO, IT Helpdesk, Chief Marketing Officer, Customer Success, Sales engineering and often times a psychologist. You should seek out ways to contribute beyond ‘writing code’; get outside of your comfort zone and stay there as much as possible.
This is not something I expected when I started this journey five years back; but, being agile and learning the ability to jump between roles and context is something that has done well for me.
Success requires a commercial vision, which is often driven by product and engineering
I think it is common, unfortunately, for those of us in engineering organizations to measure success based on how well our product works or how it measures up in value conversations. Unfortunately, the success of our product or the things we build rarely rests on either.
Without a clear plan to commercialize and take the product to market, it will never be a success. I think many amazing ideas end up in a trash bin because of this lack of foresight. Worse, for us in engineering, we may say or think “that is not my job or what I do” and we could not be more wrong.
Rare is the unicorn of a sales or engineering profession that understands both sides on the business. The responsibility, I have learned, of launching a successful product lies as equally with engineering as it does with sales.
The engineering group should not be responsible for leading the commercial vision or go to market planning; though we cannot abdicate our responsibility of being an equal partner in the commercial success.
The closer a product gets to be ready for scale, the more anxiety the sales or commercial organization may have about it. It may be something very real, perhaps a UX issue that they feel will impact their success in making the sale or it may simply be a lack a confidence in their ability or in the product itself.
As product developers, our role here is to treat the commercial organization as our internal client. Their needs and anxieties should become what drive your work day to day.
The UX issue is something easily resolved; the latter two issues are not. If your commercial organization does not live and breath the value of the product they will never be able to sell it. Some of that you should interview and hire for; the other part of solving that is that the engineering has to build the necessary confidence with the commercial organization. These are company busting a product killing issues and the product development team own them.
When building your commercial organization later in the startup phase, near series A, you are likely to run into more of this. The new commercial hires especially need proper support an onboarding from engineering.
In my case, I learned this through the school of hard knocks. The product isn’t the only thing we engineer; company culture and in many ways actual commercial success is the product of a healthy engineering organization.
Plan for scale
Never underestimate the impact of inefficient code or processes.
Over the past five years I have lived through several of those “if we had planned better” moments; indeed, who would have every thought S3 would be so expensive? As an engineer in a startup, you will be placed in charge of making product decisions that seem simple but will likely have an impact as you scale.
To this, the most destructive thing a product developer can ever say is “well, it worked on my laptop”. Nothing is more toxic than an engineering mindset like this.
To mitigate this and help prepare for the day that you are asked to roll out your product to twenty new clients, plan for scale from day one. You do that by taking your worse case scenarios, usage wise, and 3x them. And then do that in a “production environment”.
I once asked a developer to load test their application and I was horrified to see them using selenium to “load the web application” over an over. Do not assume people understand what writing or testing efficient code looks like much less what scale means. I guarantee if you ask 3 people you will get three different answers; all correct and all horribly wrong. You see, it is not a single answer, indeed, it is a culture.
Push yourself and your team to think in extremes in terms of data, usage and infrastructure; use peer reviews, even as an organizational leader, to stay on top of this. Challenge everyone to think beyond their laptop.
Planning for scale should begin before ever writing a line of code. Game out what a successful product would look like. Wildly successful. If it does not scare you then you have chosen the wrong profession.
Thinking back to my early days using python and django to create newsroom applications, I recall my infrastructure counterpart having to actually give our postgres database a name; a human name. He did that so I would be less likely to kill him (or it) and would think about the consequences of poor “Frank” before deploying an application.
I will leave you with this — do your best to care for Frank and certainly do not put him an a situation where he may die. Plan for the wild success you dreamed of. Plan for it.
Know when to let go
Your grip on something may very well be the thing that kills it. It could be a thought, a section of code or even a process.
I had had to to learn, as the second employee in this “nothing to multi-million dollar series A startup”, that the absolute worse thing you can do is white knuckle things. If you find yourself doing this, immediately let go and then ask yourself why you were fighting so hard to hold on. As an engineer, it is easy to let the code you write define you, I think. As a leader it is similarly easy to want to defend a process or idea that you have implemented.
I lot of what I am referencing here could easily fit under the emotional intelligence heading but I think it is so important that it should be its own section.
As an engineering leader in a startup, you will experience the growth of your product, team and company. As part of this growth, learn to recognize when to let go of things you may have spent years building. This handoff, so to say, is critical to the overall growth of the organization. New team members with specialized skill sets will likely join your organization; your role as a leader is to quickly identify those skills and off board that from your direct responsibility.
Not being able to do this will result in an incredible amount of frustration in your organization and you will be viewed as someone who is afraid to empower your team or even worse as a “boss” who doesn’t trust anyone except himself.
My learning here is that I needed to let go of the more “day to day” things so that I could return to making a real contribution to the success of the company; pushing code or managing a process was no longer enough and the team could easily handle it. It is equally terrifying and liberating at the same time. The true measure of an engineering leader in a startup is being able to navigate that and let go. Learn to let go. When you do you will be surprised at how things grow.
In the end, these five learnings have been a key part of my growth as an engineering leader. It is no joke when I say these five learnings were life altering growth points for me.
If you have not read it yet, check out 5 Thoughts after 5 Years Building a Success Engineering Team at a SaaS Startup.
>>> import this