Common organizational models in software firms

How an organization is structured internally can significantly impact its business performance. Internal efficiency is critical today because technological advancement and globalization have made the competition much fiercer than ever before.

Of all types of businesses, software firms are perhaps the most sensitive to the distinctions between different organizational structures. The software industry is fast-paced, and the structure of software companies needs to reflect that.

But how exactly should a software firm approach its internal operations? How should a software firm organize itself to achieve the best results? There’s no one-size-fits-all solution for software firms. However, some organizational structures are more common than others in software companies – more below.

Why organizational structure matters for software companies

An organizational structure defines three things in businesses (Devaney, Feb 11, 2022):

• Chain of command – determines delegation of tasks and the approval of work across the corporate ladder, from the top management to employees. Additionally, the chain of command defines the communication protocols for proposals, requests, and issues across different layers of the organization.
• Span of control – determines under whose management each employee and task fall in the organization.
• Centralization – determines who makes decisions, the rationale for the decisions, and the distribution of decision-making across employees.

Modern software firms favor flatter organizational structures. These structures:

• De-emphasize chains of command and minimize bureaucracy. Flat organizations can have chains of command that consist of only employees (Devaney, Feb 11, 2022). Sometimes, chains of command include employees, managers, and the organization’s CEO. In vertical (non-flat) structures, the chain of command can consist of multiple levels of managers, department heads, and C-level executives.
• Minimize the number of managers. In flat structures, employees report to as few managers as possible – often just one manager. Typically, this manager is responsible for a specific active project team.
• Are decentralized. Individual teams and departments have more autonomy and decision-making power in their projects. Department managers and C-level executives often have supervising functions.

Flatter organizational structures are more agile and allow teams to (Aghina, et al., Jan 22, 2018):

• React to market conditions and customer demands quicker.
• Achieve a higher degree of customer centrism.
• Achieve end-to-end accountability for their products.
• Deliver value to the market quicker.
• Reduce product development costs and simultaneously increase revenues.

With all that said, there’s no one-size-fits-all organizational structure for software firms. Some businesses might find that they will benefit more from a more hierarchical structure, while others might find it terrible for them. With that, businesses should pause and think about what they are trying to achieve.

Three common organizational structures in software companies

Below, we will look at three common organizational structures in software firms. While businesses use many other structures (Devaney, Feb 11, 2022), we will feature three that represent a wide range of organizations. We will see how the three structures differ and how exactly they can benefit or harm software firms.

Functional (technology) teams

Organizations that follow the functional team pattern have dedicated departments for their job functions, such as marketing, software development, or finance (Lange, n.d.a). Based on their specialization, employees are assigned to different departments. Each department reports to the specialized manager, i.e., the marketing department reports to a marketing manager, while the finance department reports to a manager of finance.

Functional organizations have a hierarchical, top-down structure. Top managers make decisions and delegate them to department heads. Department heads then divide the tasks and assign them to their teams.

Regarding IT staff, functional teams distribute the functions in areas like backend development, iOS development, or DevOps. Software projects are typically spread across multiple IT/tech teams that allocate software projects and rarely share code amongst the separate teams. Different teams usually use a variety of programming languages in their projects, reducing interactions between code reuse from various departments instead relying on programming APIs.

The functional team pattern has low agility and might represent older software firms that haven’t transitioned to a less hierarchical organizational structure yet. While the functional pattern has many advantages, it also has serious downsides that can make it undesirable for some businesses.

Advantages of functional teams

• Technical mastery. Thanks to its narrow specialization, each department has a high level of technical mastery in its area. Because employees are primarily working on similar projects, they can focus on improving their technical skills within their narrow specialization. Specialized teams often create code that is very high-quality and deeply optimized for the specific technology or toolset used by the team.
• Competent managers. Managers in functional teams are highly specialized and skilled in their line of work. They can provide in-depth feedback and guidance to their engineers. Additionally, specialized technical managers can better measure merit and identify when an engineer is ready for promotion.
• Organizational clarity. Functional organizations have a simple and understandable structure. The chain of command in functional organizations is transparent, and each employee knows who they should address with requests.
• Possibly simplified hiring process. Hiring and onboarding talent in functional organizations can be simpler than other patterns because of more precise distinctions between different specializations. As an example, a DevOps engineer might be able to visualize their role in a DevOps department better. In contrast, if a DevOps engineer were to become a part of a team working on monetizing a video streaming platform, s/he might initially not understand how the line of work relates to their position.

Disadvantages of functional teams

• Barriers between departments. Functional teams typically do not have direct lines of communication with each other. The lack of direct lines can lead to silos and knowledge gaps because isolated teams might not see the bigger picture and might be unable to align well with other departments and the organization’s overall business goals.
• Longer time to market. Each department in a functionally structured organization operates independently. This independence can be a problem with projects that span multiple departments. When transferring work from one department to another, the next department in line might be unable to immediately pick it up due to communication issues or other commitments. The resulting time gaps between departments can significantly increase the time to market.
• Waterfall-like tendencies. Functionally structured organizations might have waterfall-like tendencies in their workflows. These tendencies, first of all, manifest themselves in the sequential nature of the work transfer between teams. Isolated functional teams cannot start working until previous teams have completed with their project responsibilities. In addition, making changes in already completed work can be extremely challenging because a given team in the sequence might not have a direct communication channel with the previous one. Teams might need to raise issues to their department heads to have them solved, which can be highly inefficient.

Matrix teams

In the matrix structure, employees are assigned to teams that work on one product or project (Lange, n.d.b). A single team can have specialists from several areas, such as QA engineers, DevOps engineers, Android developers, and data scientists.

In matrix teams, each employee has two lines of reporting:

• Functional line, where the employees report to their department heads. QA engineers report to a QA manager; backend engineers report to a backend engineering manager, etc.
• Product- or project-based line, where the employees report to the manager of the specific product or project they are assigned. All employees in a team report to their project manager regardless of their specialization.

The balance of decision-making power between department heads and project managers can vary in matrix teams (Team Asana, Aug 26, 2021). Matrix teams can be weak, strong, or balanced, depending on the balance of authority. In weak matrix teams, department heads have more authority and control the project budget and timelines more tightly. Weak matrix teams have less control over their workflows. In strong matrix teams, project managers have full ownership of their projects and can direct them in any way they see fit. Department heads, in the meantime, oversee the project and ensure quality across their line of work. In balanced teams, the distribution of authority is more or less equal among department heads and project managers.

Matrix teams can exist for varying amounts of time, depending on the goals and culture of an organization. In this sense, there are two types of matrix teams:

• Short-lived. Short-lived teams are formed each time a new feature needs to be developed and are disbanded after completing their work. Short projects tend to be simpler and can force teams to release more often and not over-invest in their mistakes (Editor, n.d.).
• Long-lived. Long-lived teams are persistent and stick to a project for a long time. In 2012, Spotify used a matrix-like structure with squads that worked on long-term missions (Kniberg and Ivarsson, Oct 2012). The main benefit of long-lived squads was that employees could become experts in their product areas.

Matrix teams have multiple advantages over functional teams, as we will see below. Consequently, numerous management lines can significantly complicate the operation of a matrix team in different ways.

Advantages of matrix teams

• Close collaboration across different disciplines. Knowledge flow in matrix teams is unrestricted, and collaboration between different disciplines is greatly simplified compared to the functional team pattern. Employees don’t have to go back and forth between various departments to solve issues or make change requests.
• Shorter time to market. Transferring work from one domain to another can take very little time in matrix teams. Skills are immediately available to each member of a matrix team, and employees can quickly pass their work to the next specialist in line.
• Broad knowledge of a product domain. Matrix teams expose employees to other specializations, which helps them better understand how their product works overall. This cross-fertilization also encourages employees to hone their skills in their business or technical domain, which can be especially important in complex industries like finance or healthcare.
• Employees can better see how their actions contribute to company success. Because specialists aren’t confined to their specific departments, they can better see their impact on their products. This perspective can help them recognize their role in the success of their product and can make them feel involved.

Disadvantages of matrix teams

• Limited autonomy. Instructions from several managers can severely limit a matrix team’s options and restrict its autonomy. This potential for ambiguity might be an especially big problem in weak teams where the project manager has relatively little decision-making power. If different managers push conflicting priorities and controls, managers may exacerbate the issues.
• Prolonged decision-making. Decision-making can be delayed when multiple managers are involved. As work passes from one employee to another, it may need to receive approval from different managers. This delay can cause gaps between different stages in product development, complicate decision-making, and increase time to market.
• Risk or suboptimization for a specific line of work. Managers and department heads who don’t see the bigger picture might try to optimize the project for their specific area. This prioritization unnecessarily complicates certain product development aspects and increases market time.

Product teams

Product teams are similar to matrix teams because they focus on a specific software product or project (Lange, n.d.c). However, a critical difference between product and matrix teams is that product teams report to the same manager. Essentially, product teams do away with the lines of reporting to department heads.

There are no strict definitions of what constitutes a product in product teams. Businesses are free to break down their development activities into products in any way they see fit. For example, the online lodging company Airbnb maintains dedicated teams for customer personas, such as guests and hosts (Curtis, Jun 5, 2014). Airbnb views guests and hosts as separate user demographics with distinct goals and needs.

Regardless of the structure of product teams, they should generally be small to keep communication simple, clear, and quick. Airbnb, for example, keeps product teams size to 10 people or less. Amazon founder Jeff Bezos’s two-pizza rule is often cited as a guide for team size. According to the rule, teams should be small enough to be fed by two pizzas (Amazon Web Services, 2020).

All in all, product teams have more autonomy and flexibility compared to matrix teams. However, even though the lack of supervision from different management lines can be overall beneficial, it can introduce new challenges that aren’t present in matrix teams.

Advantages of product teams

• Simplified decision-making compared to matrix teams. Because product teams report to just one manager, decision-making is greatly simplified. Drastic changes go through fewer layers of approval, and product teams get more autonomy than matrix teams.
• Unified products thanks to improved collaboration. Product teams get the chance to develop more balanced, unified products that deliver value both to the business and end-users. With no department heads to influence the development process, product teams can focus on the important things, not on what a department head thinks matters the most.
• Alignment with business success. Product teams have a great degree of alignment with business success, perhaps even greater than matrix teams. Again, this is because of the improved focus and the minimized number of conflicting instructions from different managers.

Disadvantages of product teams

• Less attention to technical excellence. In pursuit of business success, product teams can start neglecting technical excellence. Managers can be especially susceptible to this as their attention is divided between multiple technologies and skills.
• Higher risk of code duplication across teams. Working independently, product teams often come up with duplicate code that serves the same purpose. This redundancy isn’t necessarily an issue because independent codebases can reduce dependencies between teams. However, some businesses might prefer to avoid reinventing the wheel every time and instead prefer establishing code-sharing channels between their product teams.
• Challenging moves between teams. Each product manager can instill a distinct working culture into their team. Furthermore, some managers possess better human qualities than others. If a product team member likes their current manager, they might hesitate to change product teams. This hesitancy can complicate talent transition between teams and prevent businesses from allocating their best employees to high-priority positions.
• More responsibility on the product manager. Product managers are responsible for both the technical and business qualities of the products they supervise. Therefore, the managers of product teams need to be proficient technically and business-wise.

How Instagram reorganized its engineering department to optimize its operation (mini-case study)

To demonstrate the difference between functional and product teams in the real world, let’s consider Instagram (Everingham, Nov 27, 2017). The company snowballed from 2015 to 2017, scaling from 115 engineers to over 400. To sustain such growth, Instagram had to rethink the structure of its engineering department. It took Instagram three months to reorganize the department and another eighteen months to scale it up in size.

Before the restructuring, Instagram’s engineering department had three teams – mobile, backend, and data & monetization. This structure had elements of the functional pattern and had many issues known by Instagram’s management. Mobile and backend departments had employees specialized in mobile and backend development, which is a typical example of a functional pattern. As for the data & monetization department, the product team pattern was predominant because it focused on a specific business area rather than an employee specialization.

Nonetheless, this organizational structure was sub-optimal for Instagram at the time. It had the classical issues of the functional pattern – dependencies between departments, unclear ownership and accountability, and not only.

Instagram decided to reorganize the engineering department to achieve these five outcomes:

• Minimum dependencies between teams and code.
• Clear accountability with the fewest decision-makers.
• Clear measures for groups.
• Roadmaps for top-level organizations.
• Ownership of performance, stability, and code quality.

As a result of these priorities, Instagram broke its engineering staff down into the following teams:

• Core infrastructure and core client teams—maintaining Instagram’s back- and front-end functionality as new features were added and as the user base grew larger.
• Engagement team—focusing on delivering value to end-users.
• Business platform team—focusing on how businesses connect with their audiences on Instagram.
• Growth team—focusing on increasing the user base of Instagram.
• Protect and care team—focusing on the security of the Instagram community.
• Creation team—focusing on the creative tools that allowed Instagram users to express themselves.
• Communication team—focusing on how Instagram users could connect and share their experiences with each other.

This structure leaned more toward the product team pattern, with each team specialized around a specific area of Instagram’s operations. The new teams received autonomy and had the full-stack talent to work on their projects independently. Reliance on other teams became minimal, allowing Instagram to improve its workflows’ speed and add clarity to its operations. Employee satisfaction and career opportunities improved, leading to better talent retention.

Next steps

Reorganization might be a necessity for some software firms, but it can be extremely challenging. Employees seldom feel safe during a reorganization, which requires months of planning. Making sure that executives are on board and supportive of the planned changes is also crucial to success.

When planning reorganization, each software company needs to consider its unique situation and capabilities. Restructuring requires a careful, tailored approach, so businesses must evaluate what they have today and establish what they want to have tomorrow. A clear vision of the future is critical, and so is the communication between stakeholders. Team members could consider trying their hand at a number of free or inexpensive courses to build a further foundation in an understanding of organizational design and structure:

• Alison Course – Organizational Design: Power Control and Bureaucracy
• Alison Course – Introduction to Organizational Theory and Structure
• Coursera Course – Designing the Organization
• Coursera Course – Organisational design: Know your organisation
• Harvard University – Designing Organizational Structure
• MIT OpenCourseWare - Strategic Organizational Design
• Udemy Course – Organizational Design and Structure: Definition, Elements, Types, Pros and Cons
• Udemy Course – Organizational Structure and Design – Foundation