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\u201360 organization in three months. Wow, that\u2019s aggressive growth, you might be saying. It is indeed and yet this type of growth is more common than you may think.<\/p>\n
I\u2019ve 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.<\/p>\n
Regardless of what the reasons may be, as a senior leader of a technology organization, whether you\u2019re 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.<\/p>\n
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.<\/p>\n
Ask yourself, what kind of work will need to be done in the next six months to eighteen months for the organization.<\/p>\n
You might think it\u2019s 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\u2019s 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.<\/p>\n
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.
\nThe reason why it\u2019s 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.<\/p>\n
When you\u2019re setting up team structure for 40\u201360 people, you can\u2019t just hire all senior developers or mid-level developers. In fact, you can\u2019t hire only developers.<\/p>\n
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.<\/p>\n
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\u2019t 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.<\/p>\n
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?<\/p>\n
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\u2019re 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:<\/p>\n
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.<\/p>\n
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:
\n- a new hire understands the team\u2019s goals and how they contribute to them
\n- a new hire is aware of the team\u2019s rituals and participates in them
\n- a new hire is able to perform their duties while following the process that the team has<\/p>\n
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.<\/p>\n
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\u2019t performing to the expectation of their role during their probation.<\/p>\n