What is a technical team? A technical team is a team that does not deal with business tasks. So, what does it do? There are several approaches to structuring technical teams. Some companies create specialized teams for particular tasks: supporting development tools, breaking down a monolith, building component libraries, etc. This approach is straightforward: there's a project, we assemble a team, and get to work. It's quite similar to product development. Alternatively, a team might not have a specific specialization, which introduces some differences. In this scenario, a customer is essential. Just as a product manager brings tasks for grooming to product teams, a technical team requires a customer, usually the CTO and a group of tech leads in our case. Once we've identified our customer, the next step is to create a backlog, ideally for a year. This may seem trivial (technical tasks are always plentiful), but try convincing someone to join your team when you only have plans for the next two months. Now that we have a backlog, we need to ensure the tasks in it require a dedicated technical team. If all your tasks can be handled by frontend developers alone, then a separate team isn’t necessary. Such tasks should be integrated into the technical backlog of product teams or included in individual employee goals. If these elements are in place—a defined customer, a long-term backlog, and tasks that necessitate a specialized team—then you indeed need a technical team. How to build a technical team Okay, let’s start assembling the team. We have two options: recruit people from within the company or recruit people from outside. For technical teams with a specialization, both options may be suitable. It won't be difficult to explain to outsiders that you need to create, for example, a component library, just as you would to developers from your own company. For non-specialized teams, external developers are not suitable. Most often, the tasks will be highly specific and difficult to track — more on this later. So, for such teams, it’s better to recruit people from within the company. But who? A simple and effective option is to recruit the best developers in the company. They know the project best, the weak points and peculiarities. But here are a few problems you’re likely to face: Product teams won’t be happy that you’ve taken their best developers. This will be noticeable in about six months.
Potential conflicts within the team, especially among specialists of the same competence, as the team will consist of the most experienced developers, with their own ambitions and desires to grow within the company.
It may happen that no one within the company wants to join the technical team. We had such a situation with front-end developers because they are used to seeing the results with their own eyes and having others see them too. In this case, we decided to wait, and after six months we found a developer who wanted to switch teams, so we offered him a job. Perhaps, in your case, you should consider someone from outside. Although I think our case is quite rare.
The best option for non-specialized technical teams, as practice has shown, is to gather people who have ideas that they can agree on with managers and implement in a team of developers from other specializations. Peculiarities of a technical team In this section, I will use our team as a reference. It might be different in your case. Technical tasks are generally larger, which can add complexities when planning sprints, so in our case, we simply abandoned them. There is no point in taking one or two tasks into a sprint.
Technical tasks are harder to estimate, and the evaluation accuracy is always lower. This means you have to account for uncertainty in planning and allocate more time for research. Almost all our tasks start with a separate research task.
Each team member has a lot of responsibility. Most often, technical tasks are created and implemented by the developers themselves, which means that neither testers nor product managers can understand the context of a task without talking to the developer, unlike with product tasks. Because of this, the entire path of the task from creation to implementation, testing, and deployment must be accompanied by the developer. This can be unusual, and we discuss this during interviews to avoid misunderstandings.
The problem of which tasks can be assigned to this technical team. It may seem that such teams can be given all the technical tasks that didn’t fit into the product teams, but this is not the case. Each team should have its own plan, which the team can influence and access. The team is assembled. What’s next? After the team is assembled, it may turn out that many developers in the company want to join it. It’s important to make people understand that the technical team is not a career ladder, but a team like any other. It turns out that constantly pulling the best specialists to expand or maintain the team won’t work, and you will still have to hire people from outside. And here are the problems this can lead to. When a team consists of senior developers who have been working in the company for a long time, know the product well, and have their own ideas, it is very difficult to integrate people from outside. This happens because developers in the team already "know everything" and sometimes might ignore the established workflow. Because why describe a task if you came up with it, you are the one doing it and you already know how it will affect the project. Therefore, it is very important to establish a workflow, it will help the new people coming in or during any changes in the team. Evaluating the effectiveness of technical teams can be challenging. We attempted to measure the impact of technical tasks to gauge their usefulness for the project and business. This was only feasible in the most objective scenarios, like code coverage with tests. In other cases, the influence of technical tasks on aspects like memory consumption or the number of bugs is too ambiguous to serve as a reliable metric for evaluating a technical team's performance. It's akin to evaluating product teams based solely on the profit they generate—a responsibility that falls to product managers and customers. However, the tools used to assess product teams can be useful here as well: tracking deadlines and the number of story points completed can provide valuable insights. Good luck with building your technical teams! What is a technical team? What is a technical team? A technical team is a team that does not deal with business tasks. So, what does it do? There are several approaches to structuring technical teams. Some companies create specialized teams for particular tasks: supporting development tools, breaking down a monolith, building component libraries, etc. This approach is straightforward: there's a project, we assemble a team, and get to work. It's quite similar to product development. Alternatively, a team might not have a specific specialization, which introduces some differences. In this scenario, a customer is essential. Just as a product manager brings tasks for grooming to product teams, a technical team requires a customer, usually the CTO and a group of tech leads in our case. Once we've identified our customer, the next step is to create a backlog, ideally for a year. This may seem trivial (technical tasks are always plentiful), but try convincing someone to join your team when you only have plans for the next two months. Now that we have a backlog, we need to ensure the tasks in it require a dedicated technical team. If all your tasks can be handled by frontend developers alone, then a separate team isn’t necessary. Such tasks should be integrated into the technical backlog of product teams or included in individual employee goals. If these elements are in place—a defined customer, a long-term backlog, and tasks that necessitate a specialized team—then you indeed need a technical team. How to build a technical team How to build a technical team Okay, let’s start assembling the team. We have two options: recruit people from within the company or recruit people from outside. For technical teams with a specialization, both options may be suitable. It won't be difficult to explain to outsiders that you need to create, for example, a component library, just as you would to developers from your own company. For non-specialized teams, external developers are not suitable. Most often, the tasks will be highly specific and difficult to track — more on this later. So, for such teams, it’s better to recruit people from within the company. But who? A simple and effective option is to recruit the best developers in the company. They know the project best, the weak points and peculiarities. But here are a few problems you’re likely to face: But here are a few problems you’re likely to face: Product teams won’t be happy that you’ve taken their best developers. This will be noticeable in about six months. Potential conflicts within the team, especially among specialists of the same competence, as the team will consist of the most experienced developers, with their own ambitions and desires to grow within the company. It may happen that no one within the company wants to join the technical team. We had such a situation with front-end developers because they are used to seeing the results with their own eyes and having others see them too. In this case, we decided to wait, and after six months we found a developer who wanted to switch teams, so we offered him a job. Perhaps, in your case, you should consider someone from outside. Although I think our case is quite rare. The best option for non-specialized technical teams, as practice has shown, is to gather people who have ideas that they can agree on with managers and implement in a team of developers from other specializations. Product teams won’t be happy that you’ve taken their best developers. This will be noticeable in about six months. Potential conflicts within the team, especially among specialists of the same competence, as the team will consist of the most experienced developers, with their own ambitions and desires to grow within the company. It may happen that no one within the company wants to join the technical team. We had such a situation with front-end developers because they are used to seeing the results with their own eyes and having others see them too. In this case, we decided to wait, and after six months we found a developer who wanted to switch teams, so we offered him a job. Perhaps, in your case, you should consider someone from outside. Although I think our case is quite rare. The best option for non-specialized technical teams, as practice has shown, is to gather people who have ideas that they can agree on with managers and implement in a team of developers from other specializations. Peculiarities of a technical team Peculiarities of a technical team In this section, I will use our team as a reference. It might be different in your case. Technical tasks are generally larger, which can add complexities when planning sprints, so in our case, we simply abandoned them. There is no point in taking one or two tasks into a sprint. Technical tasks are harder to estimate, and the evaluation accuracy is always lower. This means you have to account for uncertainty in planning and allocate more time for research. Almost all our tasks start with a separate research task. Each team member has a lot of responsibility. Most often, technical tasks are created and implemented by the developers themselves, which means that neither testers nor product managers can understand the context of a task without talking to the developer, unlike with product tasks. Because of this, the entire path of the task from creation to implementation, testing, and deployment must be accompanied by the developer. This can be unusual, and we discuss this during interviews to avoid misunderstandings. The problem of which tasks can be assigned to this technical team. It may seem that such teams can be given all the technical tasks that didn’t fit into the product teams, but this is not the case. Each team should have its own plan, which the team can influence and access. Technical tasks are generally larger, which can add complexities when planning sprints, so in our case, we simply abandoned them. There is no point in taking one or two tasks into a sprint. Technical tasks are harder to estimate, and the evaluation accuracy is always lower. This means you have to account for uncertainty in planning and allocate more time for research. Almost all our tasks start with a separate research task. Each team member has a lot of responsibility. Most often, technical tasks are created and implemented by the developers themselves, which means that neither testers nor product managers can understand the context of a task without talking to the developer, unlike with product tasks. Because of this, the entire path of the task from creation to implementation, testing, and deployment must be accompanied by the developer. This can be unusual, and we discuss this during interviews to avoid misunderstandings. The problem of which tasks can be assigned to this technical team. It may seem that such teams can be given all the technical tasks that didn’t fit into the product teams, but this is not the case. Each team should have its own plan, which the team can influence and access. The team is assembled. What’s next? The team is assembled. What’s next? After the team is assembled, it may turn out that many developers in the company want to join it. It’s important to make people understand that the technical team is not a career ladder, but a team like any other. It turns out that constantly pulling the best specialists to expand or maintain the team won’t work, and you will still have to hire people from outside. And here are the problems this can lead to. When a team consists of senior developers who have been working in the company for a long time, know the product well, and have their own ideas, it is very difficult to integrate people from outside. This happens because developers in the team already "know everything" and sometimes might ignore the established workflow. Because why describe a task if you came up with it, you are the one doing it and you already know how it will affect the project. Therefore, it is very important to establish a workflow, it will help the new people coming in or during any changes in the team. Evaluating the effectiveness of technical teams can be challenging. We attempted to measure the impact of technical tasks to gauge their usefulness for the project and business. This was only feasible in the most objective scenarios, like code coverage with tests. In other cases, the influence of technical tasks on aspects like memory consumption or the number of bugs is too ambiguous to serve as a reliable metric for evaluating a technical team's performance. It's akin to evaluating product teams based solely on the profit they generate—a responsibility that falls to product managers and customers. However, the tools used to assess product teams can be useful here as well: tracking deadlines and the number of story points completed can provide valuable insights. Good luck with building your technical teams!

This story contains new, firsthand information uncovered by the writer.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

How to Build an Effective Technical Team: A Comprehensive Guide

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Our Journey to Micro-Frontends

10x Growth in 7 Months: How we Invest by Developing Software

10 Ways You Can Make Money Online From Your Home

10 Trendy Web Design Options to Make a Website That Converts

10 Tips to Develop a Strong B2B Relationship

Our Journey to Micro-Frontends

10x Growth in 7 Months: How we Invest by Developing Software

10 Ways You Can Make Money Online From Your Home

10 Trendy Web Design Options to Make a Website That Converts

10 Tips to Develop a Strong B2B Relationship

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps