Imagine this scenario. Your startup has successfully closed a Series A funding. You were asked by founders or investors to grow your small tech organization of 5 developers to a 40–60 organization in three months. Wow, that’s aggressive growth, you might be saying. It is indeed and yet this type of growth is more common than you may think.

I’ve been through such growth a few times in my career. One time it was at a startup, and the reason was that the startup received a large amount of funding from venture capital, exactly like the scenario we are talking about earlier. Another time, this happened at a public company and the reason was due to a change in strategic direction and investment in growth for a particular product. Then, there was this time at a mid-sized company where a large project was decided to be on-shored after an unsuccessful attempt at having a development team off-shore for two years, and I was involved in finding talent locally so that my tech team would be able to take on the extra work.

Regardless of what the reasons may be, as a senior leader of a technology organization, whether you’re acting as a CTO, a Head of Engineering, or a Technology Director, the following five areas should be taken into consideration when scaling a tech startup for growth.

1. Roadmap

The first area to think about is a roadmap. Before you say a roadmap is too low-level details, hear me out. The roadmap is the magic that transforms vision to action.

Ask yourself, what kind of work will need to be done in the next six months to eighteen months for the organization.

You might think it’s a bit short-sighted to be thinking ahead only for the next one and a half years, but the truth of the matter is that the technology landscape is changing at a rapid rate. If you plan and over-optimize for something that is so far away, you might struggle to build an organization that can execute and deliver on immediate goals. Besides, it’s not like you will not be reviewing your organization structure regularly. Creating and managing a tech organization is never a one-off event; you will constantly be reviewing and optimizing your set up to meet the needs of the business.

With that in mind, think about the business goals that your organization needs to deliver and whether they are project-based or discovery-based. A project-based work usually consists of of work where you already have a good idea about what needs to be done. For example, rewriting your software to work on a different operating system. Discovery-based work are usually those ideas that your company believes in but are yet to be validated. For example, a shiny new feature that will potentially solve a pain-point that customers have.
The reason why it’s important to understand the type of work coming up is that different kinds of people thrive in different environments and knowing the answer to this will help you find the right people with the right characteristics.

2. Team composites

When you’re setting up team structure for 40–60 people, you can’t just hire all senior developers or mid-level developers. In fact, you can’t hire only developers.

You need to think about what kind of skills will be required to deliver the roadmap you have and use that as an input for making a decision about team composites.

You may have heard of the Spotify model where each team is a cross-functional team that owns a specific piece of work; for example, a part of a user journey. These cross-functional consist of developers, product managers, data analysts, and product designers. This type of team works pretty well for startups but they don’t always work for other types of work environment, for example, a technology department within a financial organization who are only responsible for the implementation of fixed-term projects.

3. Type and shape of roles

What type of roles are you looking for? Is it full time, part-time, contract, or remote? What kind of skills & experiences mix are you after? Do you allow for distributed teams where team members may work remotely in cross-geo, or do you need your team members to be co-located?

For job seekers, these questions are easily answered. Job seekers know what they are looking for. However, for you, as someone designing a new organization, or growing an existing organization, do you know what you’re looking for? While this question is not going to be an easy one to answer, here are some prompts which will help you come up with job descriptions for various roles that you be hiring:

• What’s the shape of your organization? Do you want to create a triangle-shaped organization with a lot of junior and mid-level developers and then a few senior developers at the top of the triangle, or the other way around, many seniors and a few juniors? Or do you want to create a hexagon-shaped organization that is mostly made up of mid-level developers? Or do you want to have just one level of developers, and create a square-shaped organization?
• What is the order of hiring these people? Would you hire senior developers first so that they can be involved in early technical design and help onboard junior developers later? Or would you hire mid-level developers first because there is already enough work to be executed?
• Lastly, what kind of skills do you need? Not all developers are the same. Some are generalists, some have deep knowledge on a specific domain, some are unicorn engineers. You need to know what your organization requires because hiring the wrong type of person is an expensive mistake when you’re building a new organization.

Sometimes, the type of employees you hire is limited by what the market can offer. For example, if you want to find a senior developer with specific domain knowledge, they are only available on contract basis.

4. Onboarding goals

When do you think your new organization will become productive? If your answer is as soon as all the headcounts are filled then you might be in for a disappointment. When designing an organization, headcount and hiring goals tend to be more widely discussed than the onboarding goals. Examples of onboarding goals are:
- a new hire understands the team’s goals and how they contribute to them
- a new hire is aware of the team’s rituals and participates in them
- a new hire is able to perform their duties while following the process that the team has

While it may seem like simple goals, there are many attributes to a successful onboarding process. For onboarding developers, having a system for backlog of tasks, having a process for executing work, having a definition of done, having educational materials to ramp them up on current technology, architecture and best practices that their team uses, and having a shared understanding of overall goals that their team is aiming for are a few critical must-haves.

As for how long the onboarding period should be, in Australia, most companies have a standard one month probation period for their employees. But some companies, especially large organizations, have a longer probation period. It may make sense to have an onboarding period to be slightly shorter than the probation period so you can make a fair judgment call as early as possible and have time to course-correct it if a new hire isn’t performing to the expectation of their role during their probation.

5. Success criteria

So you’ve filled all the headcount. Give yourself a pat on the back but your job is not done yet. In fact, it’s only just begun.

Your job of scaling a technology organization can only be considered done if and only if you know what the success criteria are and make a point to review your progress against the success criteria afterward. Remember to only measure what matters.

Common measurements of success are:
- business impact; eg: customer acquisition, revenue, increased sales
- operational efficiency; eg: time to market, velocity, process improvement, efficiency indicators like time, quality, features delivery rate
- culture; eg: team engagement, growth opportunities, psychological safety, knowledge management

Once you know what you want to measure, it’s time to make them S.M.A.R.T — Specific, Measurable, Achievable, Realistic, and Time-bound. An example of a S.M.A.R.T goal with business impact would be the percentage of new customers you aim to acquire by the end of the year, taking into account normal growth and other marketing efforts.

Grow, but don’t lose sight of your goals

Any organization, big or small, strive for growth. Growth is a good thing for startups; it means the startup is getting traction, its vision is being shared by people other than the founders.

My recommendation for senior technology leaders who are at the beginning of growing your organization is: be mindful about how and why you’re hiring more talent; begin with an end in mind, take a structured approach, grow, as aggressively as you need to, but never lose sight of your goals. I’ve personally found that the best way to make sure you don’t lose sight of your goals is to have them written down in the first place.
Growth is never by mere chance; it is the result of forces working together. — James Cash Penny

---

If you enjoyed this article, you might like to check out my latest book on engineering management. It's a practical guide for engineering managers at tech companies.

The Engineering Manager’s How-to Guide is very targeted for engineering managers, and in this book, you won’t find generic advice like having regular 1:1’s, giving feedback, etc. Yes, those things are absolutely important, but they are not specific to an engineering manager’s role. It’s my goal to make sure this book provides a concise and actionable guide for engineering managers, the specific and niche content for engineering managers that you won’t find in other leadership and management books.