This organizational design for a technology department aims to optimally blend the need for the technology team to be an engine of innovation, a customer-service organization and technically excellent.
- Products and projects the technology teams work on
- Partners, customers, and stakeholders of the technology department
- Professions of the various technology staff members
It refers to a digital entity, a physical good or a combination of the physical and virtual. For example, it could be a communication app that people use via their smartphones and computers. It could be a health device that people wear and access via their smartphones and computers.
The goal of a product is to meet customer’s needs & desires, to solve problems for customers including ones they didn’t know of, and to delight them. Many products aim to help make the world a better place, be it in small or big ways.
A Key Difference Between a Product and a Project
A project has preset start and end dates. A project, by definition, is supposed to be complete when it delivers its desired outcomes.
A product typically does not have a preset end-date. Most products are meant to exist and evolve for the foreseeable future. Products are (and should be) discontinued for good reasons (e.g. when they no longer have a viable future, or the organization needs to divert resources to other products).
Upgraded versions of the product are delivered via projects.
Projects are successful when they end.
Products are successful when they persevere.
These roles are not necessarily each held by different people. There is no prescribed restriction on who can hold which role or how many roles. Depending on the team’s needs, people’s skills & interests, and budget & resource situation, any permutation of the roles can be held by the people in the team.
A team should make the best decisions in allocation of the roles. The roles held by people are expected to change as the team scales up or down. The team should give importance to checks and balances via separation of duties where required for compliance of regulations.
As a minimum requirement, at least three people are required for it to be a product team that encompasses a sufficient set of the roles required. In a few rare cases, the team might be able to start with just two people.
An important recommendation is that the team “resides” together, i.e. works together on a weekly if not daily basis. If the team works out of the same office, then they should work in close proximity. If the team is geographically separated, like the teams at Auttomatic/WordPress, then they should have “virtual proximity”, i.e. be in close contact using video conferencing and other online collaboration tools.
The technology partner is a senior, widely-respected and influential member of the technology management team who serves as the primary technology leader for that business, department or product/service. Excellent client-relationship skills are a requirement.
The technology partner is the go-to person for all technology matters for the client department, including for engineering, project, and technology, areas that the technology partner does not directly manage. For example, a large department like Advertising will have projects that could span multiple tech departments.
- Assess Current Capability: Evaluate the current technical capabilities of all the technology systems.
- Define Future Capability: Understand strategic industry trends to plan future technology roadmaps.
- Technical Lead for product development: Responsible for technology execution, bringing new products to market and optimization of existing offerings.
- Plan Capacity: Translate roadmaps into future year capacity plans.
- Collaborate with other tech teams: Work with other product teams to service the needs of the business needs / departments / products where other teams in the technology organization are the owners of systems.
- Subject Matter Expert: As the primary contact for a business / department / product act as the SME for all technology.
This is a sample list of professions and roles gleaned from companies that have products in the digital media space. This list can be easily adapted to other industries, for example, by including the relevant subject matter expert roles. This was compiled between the years of 2007 to 2014 and reflects some prominent roles from then.
Software Development Engineer, Server-side “backend” Software Engineer, Client-side “frontend” Software Engineer, Mobile iPhone and Tablet Software Engineer, iOS Software Engineer, Android Software Engineer, Content Management (CMS) Engineer, Testing Engineer, App Release Engineer, App Operations Engineer, DevOps Engineer, Systems Administrator, Database Administrator, Security/Privacy & Compliance Analyst
Some people believe that “reporting relationships are irrelevant in today’s world”, but social science research has repeatedly proven this to be false.1 Reporting structures and hierarchies are an essential and integral part of any organization of humans.
Let us start by acknowledging that human relationships are complex, nuanced and changing, so there is no one formula to organize your teams. Every approach to organizing reporting relationships has its advantages and drawbacks. Here, we present a reasonable but imperfect model.
This model applies to medium to large size organizations, but not to small companies or very-large companies. In a small company of less than 10 people, there are unlikely to be departments by profession where people report into. In very large companies’ each business unit may operate as an independent company with its own departments by profession (e.g. their own finance, HR and engineering).
We also make some assumptions. For example, that it is preferable that each team member has exactly one primary boss who they formally report to.2
- Does a boss’ role include the long-term development of the employee’s career, existing skills and new skills?
- Does a boss need to be a subject matter expert in the chosen profession of the employee? Or, is the employee best served by being part of a team of others with the same or similar professions?
- Does a boss need to objectively and independently look at the employee’s work as serve as a checks and balances relative to the product/project team the employee is presently doing day to day work in?
What does reporting relationships by profession mean? It means that primary (and formal) reporting relationships are organized by departments of people in similar professions. For example, HR professionals report into the HR department, finance professionals report into the finance department and software engineering professionals report into the software engineering department.
In medium to large sized companies, having the primary reporting relationship by professional departments often has advantages over having direct reporting into the product/project team. In fact, most consulting firms use this model. Some of the benefits include:
- As new products are created, old products decommissioned and projects start and end, employees don’t need to switch from boss to boss. By having a boss who has seen an employee’s work over multiple products, services and projects, the employee can receive better coaching and development support.
- A boss who manages a team of employees of the same profession helps share best practices, standards and development opportunities across the organization.
- Such a boss can also serve as a check and balance for a product/project team’s short-term needs vs. the best long-term interests of the company. The employee has a primary person higher up to consult with outside their current product/project team.
Most medium to large size companies have departments by profession. For example, they have departments for finance, HR, sales, marketing, software engineering, design, etc. This makes good sense for reasons like the above.
Such departments often assign (or even embed) their professionals within other departments and product/project teams. For example, finance (or HR) may assign a finance person or team (or HR person or team) to work with the technology department. This person would likely be assigned full time to the technology department and work in close proximity to a part of it.
The organizational model recommended here views technology as a collection of departments by technical professions. For example, software development, quality assurance and testing, infrastructure engineering, and project management. Each of these technology departments embeds their staff into product/project teams.
In setting up direct reporting relationships by professional departments, it is critically important to not let the departments become siloed. Each employee should be focused on, deeply care about and feel accountable to the product/project they are working on.
When the person’s primary boss is a functional head outside the team they are currently doing day to day work in, both the employee and the boss must ensure the employee is highly committed to their product/project team whether it is in their department or outside it. One way to accomplish this: Each employee can also be accountable to a lead within the product/project team via a dotted line if needed. In some cases, the employee’s boss and their lead within the team can be the same person.
While this article was written for organizing technology departments at companies where a substantial amount of work involves software engineering, the thinking here might be adaptable to other types of departments. If you have thoughts on how to do that or have other approaches to organizing teams in organizations, please do share them.
- Hierarchy is Good. Hierarchy is Essential. And Less Isn’t Always Better by Professor Bob Sutton at Stanford University https://www.linkedin.com/today/post/article/20140112221140-15893932-hierarchy-is-good-hierarchy-is-essential-and-less-isn-t-always-better [↩]
- If someone has scientific evidence supporting this, please let me know. [↩]
Also published on Medium.