A Guide to Scaling Your First Tech Startup

Hundreds of thousands of developers, engineers, and coders now hold important roles in software companies, steering growth, building structure, and enabling teams. Those developers hold the role of CTO or COO. 

Taking on the massive responsibility that is operations requires a shift in mindset, skillset, and outlook. It’s a journey of growth for any developer, and one you will follow at your own pace and in your own way. 

What is a Tech CTO? 

Once, starting a business was something only a few, privileged people did. If you had the capital, an idea, and enough investors, you could launch a startup and maybe run a business. Today, nearly anyone can. This is especially true in the tech industry, where developers can increasingly contribute to the creation and realization of their own ideas, creating a minimum viable product with only a few stakeholders.  

The GEM Global Report suggests over 100 million businesses are launched each year. In the U.S., which tracks startups by industry, over 50,000 of those are registered as software companies. Software accounts for some 10% of the global economy in the U.S., and it’s set to keep growing. And, with even service-oriented organizations like Amazon and Facebook technically being “Software” companies, software literally makes up much of modern business.  

This massive shift has resulted in a change in not just how many companies are formed, but also in who’s running them. Previously, companies needed business-savvy stakeholders to take the reins and drive investment and funding. It’s now common for software developers to partner with people who have ideas, or to simply work on their own. But, while vision starts small, realization quickly results in a product becoming a business. As a result, the very developers who put the man-hours into coding a project eventually steer business growth. The developer becomes the CTO.  

This journey is one that is exemplified in many small businesses, including my own with Nmbrs.  

I began my journey as a software engineer, when I was approached by my now-partner, Michiel Chevalier. His concept, to develop a payroll/HR application, appealed immensely. The opportunity to build a new product from the ground up, with the chance to design the architecture, write code how I wanted, and build an application I truly believed in was too much to turn down.  

When we started, the team included just 3 developers, including myself. The work was very technical, everyone sat at the same desk, had lunch together, aligned ideas, and built a product together. No one thought about organizational structure. 

The first stage of my company was about 6 months of pure development. Then, when we launched and began onboarding customers onto the platform, everything changed.  

The Need for Structure  

Once your platform starts to grow, you need organizational structure. Customers need to work in the application daily. You’ll have to organize work around the wants and needs of the customer.  

This greatly changed how my team worked, because we couldn’t push updates during business hours. We also had to start doing proper testing before deployments to prevent bugs and maintain product quality. And, we needed to push technical information and documentation with the product update to help with user questions.  

Companies in this stage need to structure technical operations. Someone has to take charge to ensure we could deliver and support a new product, while maintaining product quality and value.  

Who should take on this role? Most likely, it will be a developer, because you need an understanding of the application and the tech stack. But, rather than assigning someone to create operational structure, you’ll likely be pushed into making changes to support customers, ensure stability, and organize the application around delivering quality.  

As the senior tech in our team, I ended up taking on that role. My responsibilities shifted from purely technical to handling operations. I slowly left my coding role and focused on structuring technical operations, including development and test environments and a basic deployment pipeline.  

It’s my belief that this will remain the same in most organizations at this stage. The founding, co-founding, or senior developer will take on responsibility for ensuring continuous and predictable quality. Why? Doing so means creating structure to ensure quality testing, implementing deployment pipelines, and creating work environments. That requires a strong understanding of coding, the tech stack, and the platform that has been developed.  

It’s also a relatively easy step for some developers, especially to those accustomed to working in modern environments. For example, teams like Netflix already ask coders to make their own pipelines. Shifting to managing technical operations at this stage only really entails shifting your mindset. Like in Ram Charan’s “Leadership Pipeline”, moving up to the next step requires shifting your approach to work away from performing technical tasks and towards enabling others to perform them well, to specific standards of quality, and to generate repeatable results.  

As a tech CTO, you’re less concerned with creating quality work than with enabling teams to do so.  

• Development Pipelines  
• Everything is a Product  
• Deployment Pipelines  
• Quality Control  
• Processes and Documentation  

Building Structure for Tech Teams  

People are the lifeblood of any tech company. In a product company, operations revolve around diverse concepts such as raw materials, work, production, design, and product testing. In a software company, people are your raw materials and your source of labor. Everything is designed to support people and the organizing structures that allow them to work on large projects. E.g., teams.  

Organizing teams is one of the first and most crucial aspects of ensuring an organization can grow. Without that organization, anything is difficult to scale. Startups rarely have any organization in place at all. Tasks are delegated on an ad-hoc basis, responsibilities are delegated based on who can do them, and there’s quite often little to no security, documentation, or transparency in place at all.  

Team structure including task and responsibility delegation, user access management, prioritization, quality controls, and team setup. Eventually, you’ll have to break the product into smaller modules, so that you can assign those modules to teams, and offer full ownership of that module to the team to encourage quality, pride, and innovation.  

Every organization will bring on more and more people as it grows. This is a necessary and desirable aspect of growth. It also brings new challenges. And, in a tech organization, it’s necessary that the person designing teams fully understand the product. Here, team structure, team size, and organization will literally make or break your organization’s ability to deliver products, deliver quality, and even function. This role almost always falls on the same developer who took over designing operations.  

Nmbrs grew quickly. As more people adopted our product, more customers changed demand and the need for increased and better technical support. We needed to improve our technical platform to support customers and their needs. We also wanted to continue developing features. Our team naturally grew. We went from three developers to 20.  

A 20-man team was, of course, too much. As product owner, I made the decision to design smaller teams. I took on the task of creating clear modules in the product. Then, I designed smaller teams, assigning each of them to those specific modules.  

Designing teams for your environment heavily depends on your environment, the stage of growth of your company, and internal factors such as the size and complexity of the product.  

General Developers – Skilled specialists cam be game-changing in nearly any organization. That’s why organizations fight over top talent and pay hundreds per hour for specialists who’ve made a name for themselves. But, these people are rarely a good fit in small organizations. Skilled specialists normally specialize in one thing. They need a support team if they’re to achieve anything at all. For that reason, I highly recommend focusing on hiring generalists until you have the structure and employees in place to support people like UX specialists.  

Cross-Functional Teams – Teams naturally form around work groups, usually either in a type of work (e.g., sales, marketing, IT) or based around a product. While the former has been popular for much of history, I personally highly recommend the second. 

At Nmbrs, I felt it was incredibly important to maintain our original approach. Teams should have full ownership of what they’re working on. And working in small modules with cross-functional teams allowed us to maintain that, even as we split into more teams.  

A good tech startup team structure incorporates cross-functionality so that teams can own products. Rather than creating silos by grouping specializations together, cross-functional teams group people who work on the same product or module together  

Designing Team – Agile team design means incorporating people from different backgrounds, cultures, and work environments together. It also means integrating people with different levels of experience, who can contribute in different ways. It’s always a good idea to build teams around senior or lead people who can guide the team, incorporate middle-experience people to do most of the work, and ensure you have juniors or new persons on the team to eventually take over.  

Team Size – Finally, team size is critical for agility and quality. Large teams can reliably perform the same work, with very little fluctuations in terms of work output, because there are always enough people, even if someone quits, is sick, or otherwise can’t perform work. Large teams are also slow. They have more hierarchy, more assigned roles, and more to discuss when something needs doing. Smaller teams (think 4-5 people) are faster, more agile, and better able to innovate and move quickly. With very little management needed to chase new ideas, these teams are ideal for taking on Agile projects. Both have their place, normally in different respects.  

Teams will naturally evolve as your organization grows and you have both more resources and more customer needs. As you grow, you’ll also have to consider how you want those teams to work.  

Going Agile 

More teams means more overhead, more management, and more task delegation. In the past, there was only one option. Create layers of hierarchy and management using Waterfall-style business practices.  

Today, most software companies opt for a different approach. Agile.  

With a team of around 20 people, Nmbrs needed solid structure to organize our teams and our growth. I researched our needs and we settled on adopting the Agile Scrum methodology. It aligned with our existing philosophy, and I believed we could implement it with minimal impact to how we were developing software. I also hired an Agile Coach to help with implementation. I’d strongly recommend Agile for most software companies.  

Agile is one of several methodologies built around the Toyota Method, an early work management methodology developed by Toyota. While each has its own pros and cons, I won’t go into that here, (see Vision to Value for more). Instead, I’ll talk about why I recommend Agile, and why it’s important to integrate methodologies such as Kanban and Scrum.  

Why Agile? – Agile is a methodology designed to help software organizations operate quickly, reduce costs, and reduce waste. It takes many of the principles of Lean management to reduce upfront investment and planning and instead break plans into smaller sections that can be completed quickly. The idea is that quickly producing small pieces of a greater solution allows organizations to discover problems sooner, deliver value more quickly, and respond to the need for change more quickly. Agile is typically broken into two primary frameworks, Scrum and Kanban.  

• Kanban – Kanban is a framework built around continuous development and delivery. It uses visual planning to help teams consistently tackle small tasks, moving from start to completion in quick but loosely structured bursts.  

• Scrum – Scrum splits complex tasks into stories, which are visualized in a workflow. Work is structured around sprints, where teams commit to consistent workloads, performed in set periods, enabling predictable long-term delivery. 

So, which do you need? It’s my firm belief that any software company needs both. Your team structure must incorporate frameworks that meet the needs of those teams. Not all work will be the same across every team. Teams with predictable workloads and a strong need for quality control and predictability should work with Scrum (e.g. maintenance teams). Teams with more ad-hoc work likely need Kanban because they will fail in a Scrum environment.   

Agile Development  

Early-stage organizations rarely need a strong deployment pipeline. Your initial efforts to create technical structure will likely be rudimentary at best. Your organization won’t have the time or resources to do more without significantly sidetracking actual development. Eventually, this will change, and work debt will increase. It will cost more to not have a strong pipeline in place than it will to set aside time to develop one.  

When will this occur? That really depends. But, eventually, you will have to meet compliance regulations, manual repetitive tasks will become overwhelming, and managing quality will become a full-time job. Making changes to tech structure will improve quality, reduce investment, and empower teams to do more.  

Deployment Pipeline Gating – Most developers work in their own environment and must push work to the live environment. Establishing quality gating, with multiple steps of approval, quality control, and approval. Here, code must meet criteria for code analysis, performance, security, and functionality before moving on to the next step. This allows you to root out issues early-on based on time-to-fix, to greatly reduce costs of solving those issues later.  

QA Automation – QA automation allows developers to move more quickly, pushing code into quality assurance without waiting for a QA to be available to do so. While you need manual QA review, QA automation means that a developer can push code from their own environment directly into a QA testing environment and simply move forward with code.  

Everything from Source Control – The larger your organization grows, the more difficult it will be to roll back changes and problems. For this reason, it’s crucial to create a structure that supports bootstrapping from source control. Here, all artifacts (code, database, configurations, libraries, tests, etc.) are in source control, allowing you to bootstrap the full application without pulling from external configurations or database states.  

Code Versioning – Application size becomes an issue in more ways than one. The larger an update, the more complex it becomes. Ideally, developers can create code and push it to the live application when it’s done. In a large application, doing so will break the app or result in massive bottlenecking because there are always interdependencies. Larger applications must use techniques such as code versioning, red/black environments, code flagging, or a combination of each to push updates. Doing so means creating structure and technical capability.  

Process Management – Processes and documentation are one of the most important aspects of Agile compliance. Here, you must have processes in place to specify quality and standards, you must document changes and their reasons, and you must maintain logs of tickets, incidents, and updates. These should be integrated into daily work and into tooling used by teams to ensure continued usage and relevance.  

Organizing teams for growth  

Simple team design will help your organization scale to a certain point. Afterwards, you’ll want an additional layer of organization on top of teams. It’s crucial to allow experts to communicate with each other while preventing silos. Teams that are too large get in each other’s way, but smaller teams often can’t take on big projects together. Cross-functional teams still have to communicate with others in their fields. And, ensuring communication across all teams is important. How do you navigate these disparities in a technical environment?  

The Spotify Approach is one solution, and one that I highly recommend. This is especially relevant for software companies, where product development, customer support, and technical operations are heavily intertwined.  

• Squads – Squads are teams, owning end-to-end functionality of a module. Squads are self-starting, self-organizing, and cross-functional (allowing them to be autonomous).  

• Tribes – A collection of squads inside the same business area or module. This allows squads to work on modules or business areas that might be too large for one squad, without losing communication.  

• Chapter – A large organization of people across teams based on work-area such as front-end or back-end application, business area, etc. This allows the Chapter to discuss ideas, insights, methodologies and to work together outside of squads.  

• Guild – Guilds are cross-squad structures based on common interests such as quality assurance, design, development, etc. This allows you to see the benefits of having a IT in a single room, without actually creating that kind of silo. 

This sort of Agile team structure allows you to reduce silos across your organization, so that you avoid isolating technical experts from others in their field, while creating autonomous and cross-functional teams capable of cross-friend interaction and collaboration.  

Agile team structures help keep overhead light, so you spend less time managing day-to-day work of teams and more time creating value. Agile teams manage themselves, and methods like the Spotify model help them to do so on a larger scale. They should also scale for growth, which means implementing mentorship for new employees, employee development, resource management, and measures to prevent teams from growing too large.  

Scaling to a next level 

The further your organization scales, the more challenges you and your organization will face. Aspects like automation, monitoring, delegation, and hiring strategies come into play as essential for growth and organizational security.  

When I first stepped into my role as CTO at Nmbrs, I was involved with everything. I made decisions relating to hiring, team delegation, quality control methodology, and much more. When we scaled past 50 employees, it was no longer possible for me to stay involved with every little detail. My role became about delegation, ensuring that someone was responsible for everything and that stakeholders and product owners were revising and improving processes themselves. I can’t be everywhere at once and neither can you. Instead, you have to step back again and learn how to delegate previous responsibilities to others, so that they can perform and improve.   

It’s crucial that teams have the opportunity to monitor and improve themselves. This necessitates integrating monitoring tools, frameworks to automate monitoring for application events, infrastructure resources, cost management, support, and much more. It also means setting up a system of triggers and actionable reactions so that teams have the tools to respond to triggers.  

Quality Monitoring – Implementing frameworks to measure and manage the quality and health of teams, of the application, and of anything associated with the application is crucial to support scaling. Organizations need automated quality management, security, and health monitoring. It simply isn’t possible to manually monitor an application containing hundreds of modules. Instead, you’ll have to set up triggers directly linking to tickets, problems, and responsible parties. When something goes wrong, teams need the tools to recognize it automatically and to alert relevant persons to problems.  

Standardizing Processes – The larger your organization, the more people who will work on the same things. It’s crucial to have standardized processes and work methods across the organization, so that everyone can seamlessly collaborate, share work, and integrate into each other’s work. Standardizing processes supports documentation, transparency, and handing work off to new teams as products and work change.  

Collaborating with Other Departments – Software companies bring many business areas closer together. Finance isn’t its own department because invoicing is integrated into the tooling. Sales and marketing often have overlapping jobs. Sales and marketing need to know what development is doing when customers ask questions. And customer support needs to know what customers were promised by sales and what new product features do and why. And developers need to know what customers want, what they don’t like, and why, which they’ll only get by communicating with sales and customer support. Developing scalable teams means integrating this collaboration and communication into team structure.  

Whether your organization is in a startup phase or well on its way to growth, you are in a journey of growth. This was my journey, but of course, everyone’s is different. You might follow a different sequence of events, learn different things, and experience different problems. Was yours different? Contact me to share your story. 

My journey is continuing. I’ve moved into new roles at Nmbrs and am in the process of starting a new organization. Chances are, that will eventually apply to you as well. Your journey of growth should never be complete. 

I wrote Vision to Value to share my experience with designing organizations from the perspective of a developer. This article shares a brief overview of some of what I thought was relevant for developers on their journey to becoming CTO, but you can, of course, learn significantly more from the book itself.

Learn more about the Vision to Value Framework