Hypergrowth is the dream of all startups. But once you hit hypergrowth, it can quickly turn into a nightmare.
Everything is in constant flux, and no one has an instruction manual.
We don’t have it either, but this is the next best thing.
We bring you insight and tips from Ákos Kapui, VP of Engineering at Shapr3D, about managing a company in hypergrowth, doubling employee count every year. He has the experience you need, and he’s sharing it with you. Interview by Karolina Toth on episode 39 of the Level-up Engineering podcast.
Ákos Kapui is an engineering leader with experience in building world-class mobile products and engineering organizations on hyper-scale.
He co-founded and served as CTO at Distinction Ltd., a mobile development agency. They built products for international companies and came up with their own products while building up their organization. Distinction was eventually acquired by Skyscanner, where he became Engineering Director.
His job at Skyscanner was to help to transform the company into a mobile-first organization. At the time of the acquisition Skyscanner employed about 500 people, but the number of employees doubled to about 1,000 during his tenure. He was responsible for the company’s mobile app strategy and execution that included close to 100 people across five offices
He joined Shapr3D two years ago as VP of Engineering. They’ve been doubling their size every year since then. They currently have around 100 employees and expect to scale to about 180 by the end of 2021.
I was responsible for close to 100 people at Skyscanner, but Shapr3D only had eight engineers when I joined; now we have about 40 engineers. These numbers bring different challenges and expectations to my engineering leadership role.
I consider engineering management a problem-solver function.
It’s my responsibility to make sure that things don’t break and that we learn our lessons when they do. I’m not solving most of the problems on my own, but it’s my job to make sure they’re recognized and handled. When the team releases bad code to production, it’s on me for not foreseeing the possibility and not creating a process that guarantees quality.
Minimizing turnover is essential in hypergrowth. Everything is changing constantly, which can deter early hires.
It’s among my responsibilities to create an environment where people want to stick around and are motivated to build great products. As an engineering leader, I need to ensure that each individual can contribute to our journey and they know they can talk about any problem they might have
People who had joined the company at an early stage may not understand the need and value in hiring people with more experience later on. Be super transparent and prepare your team for these additions in advance to avoid conflicts.
I was the first VP at Shapr3D and software engineering was clearly the function with the most pressing need for additional growth in the company, so it has become my job to set up and perfect the hiring and onboarding process.
You continuously need to hire people who are as good or better than your existing team. Small companies usually don’t have a strong engineering brand, and it is difficult for them to compete with giants like Google and Facebook, especially if they try to copy their strategies. You need to come up with something different and unique, and you often end up relying on your own network.
I often use the phrase “Moneyball recruiting.” In case you haven’t seen the movie (or read the book), Moneyball is a story of a former baseball team manager who went against the odds by dropping the mainstream scouting approach to build an all-star team.
Shapr3D operates in an interesting domain. Success at our company requires deep experience in computer architecture, computer science, linear algebra, and operation systems. You rarely come across engineers who are equally experienced in all these aspects of software engineering.
As an example for Moneyball recruitment, in my early days at Shapr3D, I decided to scrape the university websites for essays and thesis projects, looking for people who had researched our field.
Successful hiring doesn’t exist without conscious decisions on what exceptional talent looks like. As soon as I realized that we need to explicitly document the requirements, we’ve started to build out the new recruitment function and establish a consistent hiring bar across the organization.
This had the most impact in the first months.
You can find materials online about interviewing, but they don’t solve your problems unless they’re tailored to your culture and environment. We ended up starting from scratch.
As recruitment scales, you will end up doing hundreds of interviews each month. Our engineers have deep knowledge of the field, but if most senior engineers spend most of their time in interviews it will impact productivity and morale.
Training engineers to do interviews takes more effort than it saves in the beginning. You need to train them; otherwise, your hiring becomes inconsistent.
Due to our human nature, we unconsciously look for people that are similar to our character. If I were the single individual making hiring decisions, it would result in building a team where everyone has a similar way of thinking to mine. To make hiring less subjective you need to have a framework where people with different mindset and expectations can have open discussions.
Different roles require different types of people.
The CEO role in tech requires an entrepreneurial spirit to make a company successful, and CEOs often hire people similar to them. When you have about 20 people, you should consider a shift to hiring people with experience in building long-lasting products.
Your decisions today will have an impact on the product in the future. Unless you are conscious about these decisions you end up with a lot of technical debt, product debt, and organisational debt. This is my rule of thumb; the sweet spot depends on your organization and its growth.
Entrepreneurial people are proactive in building and shipping features. They’re great when you’re experimenting, and it doesn't matter if you ship the wrong feature or something breaks. Conscientious people are happy to write the documents, discuss consequences and they push back when development is going in the wrong direction.
Interestingly only about 2% of candidates indicate in our job interviews that they receive enough feedback in their current job. Most people lack experience in receiving feedback and incorporating it into their personal growth, because most companies don’t invest in establishing a great feedback culture.
It's important to understand how candidates think about their development and how they seek input from their colleagues. I test this attitude during the cultural interview:
When you’re in hypergrowth, you need structure and management. If employees don’t receive enough feedback about their work, you need to improve management. This helps your employees understand priorities, expectations, the company’s needs, and what they can do to make an impact.
You can get 10 people in the same room to discuss interviewing, but this will become impossible as your team grows. In a discussion, you may get away with saying generic nonsense, but it won’t be helpful. You need everyone to test and assess using the same principles and requirements.
Put everything in writing to set a consistent standard. This forces you to be specific and to make sense, and you can use it as a reference point.
We’ve created “interview packs” for every position. They consist of the following materials:
We have specific requirements. We’ve defined what good, bad, and excellent look like for each role.
Motivation is essential when hiring a junior engineer. We aren’t looking for in-depth knowledge with our tech stack, but we’re looking for the will to put effort into learning it. Be specific about the profiles of the people you’re looking for, and explicitly share them with your employees to gather feedback.
We give feedback to every applicant we don’t end up hiring.
The recruiter has to write feedback, and they also note that if they want more specifics, we’re available to talk. Just this week, I’ve had three conversations like this. People invest time and effort into our hiring process, so the least we can do is give them feedback.
Be specific about your reasons. A technical mismatch is easy to explain, but a cultural mismatch is difficult to discuss. It’s hard to tell someone that they lack intrinsic motivation or focus on personal growth, but you must explain why that matters to your company.
These conversations help them find a job in tech, and the people who have a good experience with you are likely to talk about it to others or try again with you later. We’ve hired people who we rejected at first, but they came back later with an improved skill set.
Many startups are successful in the early days, but as consumers pick up their product and they hit hypergrowth, they slow usually down.
I was working at Skyscanner in Edinburgh. After hours, I went to a pub wearing a badge on my shirt, and a guy asked me, “Are you working for Skyscanner?” I said “Yes,” and he said, “Great, I have a question. What are 400 people doing in that big office, if your website hasn't changed in four years?”
I wanted to argue at first, but we did have hundreds of employees, and the iteration speed had dropped. When you hit that size, decision-making slows down; you need to deal with more legal issues and other things.
However, this doesn’t have to be this way. As long as you aspire to maintain or improve team performance and speed in hypergrowth, you may hit this goal. If you accept the slowdown and don’t even try to counter it, there’s no way you can keep up velocity.
An organization works like a settlement.
You grow vegetables, keep animals, there’s no one around, and your productivity is fine because you can feed your family. A new neighbor moves in. They’re supportive, distribute work effectively, specialize in different fields, and so productivity increases, but contribution to global GDP remains low.
Cities have the highest overall productivity.
How do settlements increase productivity by scaling while startups decrease it?
It’s because everybody has ownership of their work. Nobody tells the butcher how to slice meat. They make their own decisions, and they’re invested in doing it right; otherwise, they lose customers and their livelihood.
Startups often don't recognize that the teams in the frontline should make their own decisions. The top leaders are far from the problem; their insight is limited, and their knowledge of the ground level work may be outdated. Micromanagement has its place, but it often leads to bad decisions.
As you grow from 20 people to 40 and 100, you need to start making decisions differently. As a high-level leader, your job is to help your employees make decisions, show them how to align a good decision, spot a bad one, and help them learn from their mistakes.
Cities don’t involve the prime minister in every decision; the frontline workers make a lot of them. The problem is that people lack experience in making decisions quickly, sticking with them, learning from them, and taking responsibility for them.
This also became an issue in Shapr3D.
The company's growth led me to start hiring more engineering managers. I could no longer oversee the entire engineering department, and I wasn’t there to make all the decisions alone. My team played a key role in shaping our environment.
This extra layer in management makes it more difficult for senior management to understand the workings of the organization. This wasn’t any different in my case. The information flow slowed down and it became harder to see whether:
My decisions don’t have an immediate effect at our current scale. They’re about approaching problems, future plans, and priorities.
I tend to have strong views, but I’m often wrong, so I expect others to disagree with me. If you set up an environment that lacks psychological safety, people won’t disagree with you, and you end up making bad decisions.
Shapr3D lacked management experience before I joined.
The experience our employees brought from different companies either articulated the idea of management badly, or they didn't have clear expectations towards management. When your employees aren’t happy, motivated, and enabled, you have to fix that. You can’t expect employees to ask you to make them happier in their job.
Set the expectation toward yourself to listen to your employees and try to solve their problems. If people raise problems and no one does anything about them, they will stop speaking up about issues. Sometimes, they may raise invalid issues and you need to educate them to understand it’s the best option.
This is the job of management in an early-stage startup. I enjoy working in scrappy organizations, but you will run into problems if you keep your organization scrappy while scaling. Unsolved problems go into hypergrowth with your company, and can cause your best employees to leave, and the product quality to drop.
Figuring out accepted behaviors in a company is constant work. For example, you allow discussing politics in your company culture. This has upsides and downsides either way, but refusing to take a stance and allowing these discussions to run their course will lead to conflicts.
You can’t make these decisions yourself; you need to work with people to figure out whether a behavior is useful. Keep in mind what you want to achieve, and make decisions to support that.
We maintain a large Excel sheet that estimates the aspired growth for the next year. Our prediction is that we'll have 177 people in the company by the end of 2021. I can’t tell yet whether we’ll manage to hire so many employees without lowering our expectations, but this is what we're aiming for.
Most of the new hires will go into software engineering. The engineering department is at around 40 people, and we expect it to grow to 90 by the end of the year. I’m not sure if we’re prepared for this level.
It’s a wrong preconception that you need to decrease the quality of new hires when the company is in hypergrowth. Hiring junior employees with the ability to grow is okay, but hiring B+ people will lead to them hiring C people, setting you on a downhill path.
Create a consistent bar and stick to it.
Analyze the situation, set expectations towards your growth, and set up benchmarks for organizational health. In my current situation, I'm constantly afraid of something going wrong, but I'm growing more confident as I see how we’re handling our size and growth.
When problems arise, you need to slow down and fix them.
Currently, we’re going full speed, but we may run into unforeseen issues. For example, we may hire great software engineers but fall behind on hiring designers and managers. These imbalances can become a bottleneck for the entire organization.
I work with about 20 people on a daily basis. At this point, there are employees who joined recently, and I haven’t had a chance to talk to them since their last interview.
I scheduled introductory skip-level meetings with these employees and asked them the same questions:
I found that the motivation, health, the feedback culture and the atmosphere fits the way we introduce ourselves. I also found existing problems that I’ll have to work on. Half of our 40 engineers joined in the last six months, so this feedback gives me confidence that we can continue growing.
Newly hired developers need mentoring. The first 20 who have been in the company the longest are the obvious choice to mentor new hires. Make sure to mix in the newer employees as well, so you don’t put extra load on all your best engineers and so you can keep up velocity.
Doubling the organization size every year is the most ambitious plan an organization can achieve in a healthy way. The forced remote environment has made this even more difficult recently.
There is pressure to hire or train engineering managers internally. This can be a bottleneck in hiring software engineers. I’m not confident in hiring employees without making sure they get support and quality feedback about their work.
Our region doesn’t have an established engineering management culture. Only a handful of companies take engineering management seriously and educate their employees accordingly. This limits our ability to hire managers from the market.
Engineers who move to management are often less technically erudite. We want engineering managers with strong technical knowledge, and this often comes with less management experience. Shapr3D is at the maturity level where this is important.
It was still important for Skyscanner at a larger scale, but they’d already started to put more emphasis on management. At that point, they were looking for engineering managers who had a solid understanding of the code but may not have done hands-on work in a few years.
Focusing only on management requirements would be an easy solution to hire more engineering managers, but we decided against it. We need the managers to help our software engineers improve. If they aren’t great at engineering, they can’t inspire trust in their team to go to them with technical issues.
We have the same technical requirement for engineering managers as we do for senior software engineers. We give them similar homework in the hiring process. In evaluations, we focus more on software design with managers, and more on code optimization with senior engineers, but the exercise is on the same level.
When you scale an engineering organization, you need to create a plan for them for 6-12 months ahead. Here’s the problem with hypergrowth:
These decisions are based on prediction rather than tangible information.
Planning based on predictions is like zooming into a map.
In a high-level view, you may estimate a coastline to be 600 kilometers, but as you zoom in, you realize the coast isn’t a straight line, and its complexity may make it 5,000 kilometers. This is how estimates work, but you still need them to make decisions and to improve your projections over time. You can cut corners in those 5.000 kilometers, but the journey won't be as simple as it seems from afar.
We’ve come up with a plan for the next past 6-12 months.
The HR, product, and engineering functions put together what we want to build and how many people can deliver that. We predicted that this could require 260 employees in the long run. Hiring this many people takes time, so we started to prioritize development to match the company’s current capacity.
This became a big document we're actively working on. The further I look ahead in time, the less details it has.
I know the open positions specifically for this quarter. For the next quarter, I know the specific goals we want to hit. For Q3 and Q4 of this year, we plan on hiring 20 people into engineering, but we may need to revise that depending on our growth in the coming months.
It’s like playing chess.
Chess masters take each step to gain information and to be able to make a better decision. My philosophy is similar. I often take steps aimed at finding out what I need to do afterwards, and this helps me set specifics and adjust the projections every week.
Creating a new team locks in more details, and it gives me a better idea about what team to build next. There are variables like training employees to take over a position, or hiring for a position you haven’t advertised yet. Everything is in movement, and the step you take gives you a higher resolution view of the future.
Leaders need to set clear goals, break them down into steps going backwards, and act every day to realize these goals.
You need to have hired two recruiters by the time this year began to be able to hire 60 employees by the end of the year. You need to work on your product ideas today to have built them six months from now. When there’s nothing you can do today to reach a goal, it’s either low priority or you can’t see the details yet.
I have a model of the current organization with names, positions, teams, and more details. I also have copies of this model for our plans three and six months from now. The future models show the complexity of the organization and visualize the allocation of employees based on seniority.
You need to balance experienced employees with junior employees and new hires. A team with two inexperienced engineers and four new hires isn’t going to fly. When these situations come up, you may need to pull the brake on hiring.
Never make these decisions alone. Talk to the team, talk to the leadership, and share with the entire company. Expect them to ask questions and challenge you, then learn from that and incorporate what you’ve learned.
If you have problems and you hire more people, you end up with bigger problems.
We’ve had issues with our interviewing process. When I looked at the data, I learned two things:
I set a goal to fix this: no engineer in the company should have over two hiring-related tasks in a week. These are either homework reviews or interviews.
When you can’t have interviews because there isn't enough capacity, you need to train more employees to do interviews. Training takes two months at least. We lacked numbers in senior engineers to balance this.
My solution was explaining the problem to the engineers and asking them to do more interviews for a couple of months until we train others to take on some of the load. Once they understood the issue and the purpose, they were willing to help. Give them a sense of purpose; a sense of urgency won’t buy you goodwill.
One of the top qualities engineering managers need is processing a lot of information. I’ve been reading thousands of Slack messages daily, designing documents, planning products, engineering, and writing interview notes. You need to process it quickly and make sure everything is going in the right direction.
I’m doing this interview right now, but I’m about to go back to recruitment numbers, write a report for investors, or argue with the CEO.
When a buggy code is pushed to production, I don’t intervene. I absorb the information and work with the related engineering managers to help them solve the problem. It still takes effort to play all these different roles and to stay on top of different situations.
🚀 Need developers for your team or project? Hire our experienced Angular, React or Node.js developers! Click here for a FREE consultation.
About the author:
Gabor Zold is a content marketer and tech writer, focusing on software development technologies and engineering management. He has extensive knowledge about engineering management-related topics and has been doing interviews with accomplished tech leaders for years. He is the audio wizard of the Level-up Engineering podcast.