According to a CB Insights study, difficulties and discrepancies within the team destroy 23% of startups. If the team members’ collaboration fails, the startup will fail as well. Fieldbook, having shut down after failing to develop a viable business structure for its database solution, co-founder Jason Crawford claimed in his post-mortem blog that the company’s failure to make crucial recruits was one of the causes of its demise:
However, an imbalanced team composition in terms of individual member capabilities frequently hinders the company’s growth.
Why is Structuring an Engineering Team so Important?
A good structure gives the group enough liberty to succeed while preserving uniformity and interoperability among the teams. The capacity to develop product features at tremendous speed and quality is the primary success indicator of a tech organization as a start-up. To achieve this, an organization needs teams that are aligned with the product’s objective, either tackling distinct customer issues or user personas, if your solution serves different personas.
sbb-itb-0774674
Deep Dive into Structuring Your Engineering Team
According to Harvard University professor J. Richard Hackman’s research, the structure of a team determines 60% of its success. But then, it just takes a few conversations with senior executives to realize that their teams are structured entirely differently. What’s the reason behind this? Why hasn’t the tech industry discovered and established a team structure that surpasses all others as best practice? If team structure is the most significant factor in achieving success, there ought to be a big drive for this to occur. The quick answer is that the ideal team structure is determined by the company’s priorities — is it speed in competition, technical quality, or something else?
While tech companies or startups form their teams in a variety of ways, they typically structure their engineering teams around one of three basic team architectures, which they then adapt to their specific circumstances:
- Technology teams: A horizontal method in which your teams are organized along with the levels of your technology platform; for instance, a backend, a frontend, and a database team. Each team is built around a certain technology, like Android, and all members of the team report to a director who is also knowledgeable about that technology.
- Product teams: A vertical method in which you structure your teams as per the business areas of your solution, such as a customer and also an order team. Every team is cross-functional and possesses all of the necessary expertise to deliver its product.
- Matrix teams: A hybrid strategy in which teams are organized along with product and technological aspects at the same timeframe. The developers answer to a development manager in the team structure, but they are “loaned out” to project teams where they execute their daily work.
Technology Team
A technology team is a group of software developers working on the same technology. For instance, a startup company may have a front-end as well as a backend team, whereas a larger organization may have teams for various technologies such as Oracle Databases or Java EE. This means that there are no developers, testers, or product managers working with other technologies on the technology team. All teammates answer to a development manager who is knowledgeable in this field.
An iOS team, which creates apps for Apple devices, is an illustration of a technological team. The team is made up of many iOS developers who answer to a development manager who is well-versed in the production of iOS apps:
The technology team structure’s major strength is technical proficiency, which will also be greater than in any of the team structures.
The codebase of a technological team is expected to be of high quality, to make the best of the most recent breakthroughs in the selected technology, and to have relatively low technical debt.
It may also be simpler to get top-tier technical specialists for such a team. For instance, if an engineer is deeply committed to Django, the prospect of performing in a Django team, answering to a Django supervisor, and being surrounded by Django specialists is enticing. Hence, engineers should be hired based on their passion for that particular technology.
Product Team
Product teams are structured around a company’s product areas, like customers or orders, rather than the technical levels. The objective for connecting team structure to product structure is to better link team success with corporate success. The measure of success in a product team is far less likely to be technical prowess, like in a technology team, and more likely to just be how the product will perform in the global market.
A product team requires all of the many roles, including software testers and developers, that are necessary to build and manage its product area. A senior manager is in charge of the team, and so all teammates, regardless of profession, report to him or her.
So, whether a member of the team is a front-end developer, a UX designer, or a tester, they all answer to the same supervisor.
A fundamental rationale for having all teammates report to the same manager is to improve strategic planning — regardless of job role, the buck stops with the line manager. Also, it motivates team members to learn much more about the business sector that the solution serves. Tech companies that adopt the product team model tend to have leaders who are adept at bringing diverse specialties together and directing them toward the creation of a cohesive product in which all of the pieces fit together well.
The pattern also motivates leaders to focus on creating a product that truly solves a challenge: it ties the manager’s and team’s performance more closely with the company’s success, making it much easier to create relevant KPIs for the engineering team, like monthly active users.
Matrix Team
A matrix team is a short-term product or project team made up of professionals from several functional areas such as product management, development, and testing. The matrix team’s structure is intended to improve collaboration between functions in order to create better and more improved products. The core concept is that matrix teams enhance collaborative partnerships since various specialists are working in the same team with the same aim of producing a viable product. The specialists answer to a supervisor who guarantees excellence in that area.
The matrix team framework is adaptable and may be deployed in a variety of ways.
The matrix team’s edge over the technology team is that it encourages cooperation across functional specialties. Collaboration is enhanced now that testers and developers are on the same team. This is especially true if the product owner has an interesting idea for the product area that connects the many functional disciplines. In addition, the matrix team, like product teams, has a shorter product development time than technical teams.
Although the matrix team structure connects engineers closer to the company and makes it simpler to identify how they add value to the company’s success, engineers may continue to pursue mastery in their preferred technology and answer to a direct supervisor who respects and appreciates their technical work.
Conclusion
Understanding a tech start-up or company structure is not a difficult process when it is properly laid out. Remember that allocated positions and tasks have a significant impact on how an organization operates. Clearly defined responsibilities will lead to a more effective operation with no additional costs, which is critical for startups. Check out Genvalues for engineers or engineering teams that would be ideal if you are seeking engineers that would fit the team structures you prefer.
Back to Genvalues.
