The Blueprint : Building a Tech Team

As a CTO, I have had the luxury of building a team from what I believe is a solid blueprint. I am going to share some of my thought processes as I built a team from the ground up. Hope this can help anyone in a similar role with that same challenge.

First thing to understand is that, in my opinion, you have to understand the organization before you can truly build the best team possible. Everything from company culture to budgets, it all plays a role. It also matters what you are building for. Are you building a SaaS product or a platform? Maybe a service offering? Teams will be structured differently based on this knowledge. For this article let us look at the most common startup in the marketplace today, the SaaS company.

Team Design

Everything starts with a plan. You know you cannot do everything all at once (unless you have limitless resources). Because you don’t, sketch out what your ideal organization looks like. I like to start with the basic constructs of every successful R&D organization.

• Product Management
  • Product
  • UX Design
  • UX Research
• Engineering
  • Front-End Development (Implementation)
  • Back-End Development (Service)
  • Quality Assurance (QA)
  • Development Operations (DevOps)
• Analytics & Data
  • Data Engineering (Automation)
  • Data Engineering (Implementation)
  • Insights & Analysis
  • Research (Data Science)

If you are building apps for devices or web apps, the only thing that will change would be the implementation roles and how they apply the skillsets. Here is a sample org chart and what it might look like. I have chosen to align the teams around purpose, not product lines. For a startup, its critical to have a lot of players that can play different positions. As you mature, you can realign the teams to fit the evolution of the company (more on that in a minute).

You should create a 12-month plan that shows the current org structure and at least one (1) evolution that supports the growth plan. Personally, I like an 18-month plan with iterations every 6 months. The changes should eventually get your teams in a place to match would your product structure needs for success. For example, you might start out with a product manager, data engineer, devops engineer, front-end engineer and a back-end engineer in the first 6 months, leading to adding QA, an engineering manager and maybe a director at 12 months. You have to examine the business to determine what setup is best.

How do you determine which hires are most important?

It really depends on the hires you make. If you get the right level of engineering talent, you can delay some of the hires. An example of this is around QA. I like to look for engineers who have a QA mindset before I hire QA. If engineers can test their own code, you can get by (probably). Whenever possible, reach out to experienced leaders to help the decision process.

This is where true agility becomes apparent. You need to work closely with Finance to make sure you know your runway and burn rates. There have been times that I think I need an engineer, then something happens and immediately, a QA engineer becomes the most important need. It is ok to change focus, just make sure you are using data to drive those decisions. React, don’t overreact.

Schedules

Make sure you get some baseline processes in place for teams. They need schedules and good teams have weekly rituals that keep things moving. It is important to manage for daily business values. My teams will tell you that I stress the importance of that. Its more of an expectation that I think people should have for themselves.

• Standups (daily) – 15 min meetings to discuss the work for the day, blockers, etc
• Retrospective (retros)
• Planning (Lots of great information on planning and other types of product meetings)
• Grooming – In my opinion, one of the most beneficial meetings. drives focus.
• “No Meeting Wednesdays” – Give the team a day of full focus with no meetings. They (and the business) will thank you.

Get them in a groove.

Onboarding

A critical concept for any growing technical organization is to have an onboarding process. It won’t be perfect but without a solid plan for onboarding new employees, it will cost you time you don’t have. A quick set of tasks for HR, IT and engineering will make a huge difference. If you are a remote team, its all that much more important. Here is an example:

• Equipment Requisition
• Organizational Information (Org chart, handbooks, expectations, etc)
• Application Provisioning
• Engineering mentors/buddies
• Data Governance (training, documentation)
• Post Onboarding surveys (you should always gather feedback and try to get better)

Budget Allocations

An important item to add to your budget allocations is training and education. If you have good partners, you can negotiate many free training programs for your employees. Amazon is a great partner for this. If you are using their services, ask your account manager to help you set up free and paid training programs. Depending on the experience of the team, I would also look into personalized agile training (Kanban, Scrum, etc). I would set aside at least 10K for the first year for a training budget.

Year 1 Budget might look something like this.

Don’t Overreact

The key is to stay the course. Nothing happens overnight. If you have a plan, stick to it. Make smaller adjustments as needed but teams will be looking to leadership for strength and confidence. Most importantly, believe in your plan so don’t overreact and change things because someone says something. Trust in yourself. It is ok to be afraid but fear is the number one reason for failure.