I'm Sergio, VP of Engineering at a great startup headquartered in Miami called Papa.
I joined two years ago as the first engineering hire. My role was Director of Engineering. The technical team at the time was an offshore engineering firm with a specialty for Elixir work. The co-founders, Andrew and Alfredo, wanted someone local to Miami, experienced in leading engineering teams, and experienced with our tech stack.
I'm writing this article because there is such a draught of content for engineering leadership in that "growth" phase. All I've seen is "CTO" articles from people leading a 2 person team, or articles from an experienced CTO that is leading a public 600 person engineering team. No real in-betweens.
Here are some of the lessons I learned leading Papa's engineering organization from Series A all the way to Series C. What I learned when our engineering team grew to 2 people, 4 people, 10 people, 25 people, 55 people.
This is the start of what I like to call "Growth CTO" lessons.
2-10 Engineers
velocity and one goal
Our tech stack has always been very modern and included things like Elixir, Graphql, and React Native.
The first thing I did when I joined was soaking in the technical choices that were made by the outsourcing firm. A lot of the choices made were great, and some had to be changed more to my liking.
As I hired our first 10 engineers, my responsibilities transitioned more to people management. I still spent most of my time coding, but right around hire #5, I noticed more time spent on planning and building the engineering culture. A lot of time spent talking about our products, how our business functions, how we make money, who are our customers -- I wanted my engineers to understand this well so they knew who they were building these products for and why it was important.
This is when you want to set your org foundations.
As an engineering org, what do you value most? Some teams care about quality, others care about velocity, others care about adhering to a process.
Whatever you choose, make sure to make it explicit and repeat it over and over to your team. Something new managers do not realize until it's too late is that what you say seldom sticks the first few times you say it. Whatever you value most from your team, put it in the engineering handbook and bring it up often during all-hands. Make people realize you care about this first and foremost and you are judging performance based on it.
I set up 1-on-1s, sprint planning sessions, and daily standups with the engineering team. I had the engineers reporting directly to me but we didn't really have skip-level reporting structures set up.
11-30 Engineers
no more coding, much more teamwork
We started growing very rapidly, making deals with really great customers and I found myself working with thirty engineers. Suddenly coordinating work between team members was much more difficult.
We used the "Spotify" method to organize our product teams. Each team had a proper mixture of backend/mobile/web/design and they focused on one product. We called them a "Papa Pod".
At this stage, I was promoted to VP of Engineering and I promoted my most senior backend engineer to Director of Engineering. As I hired more people into our teams, our engineers with longer tenure began asking about promotions and career opportunities at our organization. Understandably, they were concerned that I was hiring a lot of very experienced engineers.
My tip to you reader is to get a career ladder on paper as soon as you close your Series B. Work with your HR department, look online (I'm going to write an article about this in the future), or ask around your personal network. You may notice one person's stress, but a team hides stress very well.
I set up clearer reporting lines. We had people who enjoyed doing player-coach type work with at most 6 direct reports. I had my 1-on-1s with the coaches and executive team. I did very little coding at this stage. I focused entirely on our culture, optimizing our delivery process, unblocking teams when they needed assistance, recruiting, and onboarding.
The decisions you made earlier in the company's life start to take automatic shape here and both good and bad are amplified.
31-55 Engineers
Building a strong team culture
When we hit the 50th Engineer milestone, almost all of my time was spent focused on management and training other engineering managers. I hired a Director of Engineering QA as well. Every decision I made at the start of this journey really started playing out before my eyes. All the training you gave your managers really pays off at this size. Keep your ears open, it's very easy to not know if bad things are happening within your org at this size. Have bi-weekly engineering all-hands to talk with your entire team about the company, the team, the work being done.
Platform team! I found people within the org that had a knack and desire for this kind of work and they began working on the infrastructure behind our software. Early discussions about service-oriented architecture, as our monolith setup was becoming very complex to maintain and ship.
The love I have for this job now comes from getting other people big wins. I spend time unblocking our product teams, empowering my engineering teams, and comforting people who have worked so hard for us and making sure their needs are thoughtfully considered.
60-150 Engineers
What's next? We have grown tremendously fast, our clients love us and we love them. I've seen this company grow from 24 people to 450 people and somehow still maintain such a warm inviting culture. As the engineering org grows it will require a lot of deliberate effort to maintain our culture and scale our reporting lines.
This will be my primary responsibility.
In my next article, I'll talk about how to identify player coaches for potential future management roles in your engineering organization.
