TL;DR: This article discusses the "obvious" and continuous issue that “product” and “tech” silos create in tech-enabled organizations and how we can start evolving from that. Why? So that we can improve teams and organizations abilities, effectiveness and happiness! We cannot achieve that by trying to create effective silos, instead we must focus on creating effective (non-siloed) teams and organizations. My thinking on this article builds on a sociotechnical systems framing, and I am calling it "ProdTech teams". I reflect on several traits and elements that should be considered in order to truly set up and empower ProdTech teams. Namely: creating well scoped teams ("Who") that are able to discover and shape product developments ("What"), which provides purposeful alignment for better building that tech-enabled product ("How").

These are work-in-progress (WIP) materials and ideas. Use it with caution! I have been thinking and working on this topic for several years now. My goal with this article is to put some of those forming thoughts down, connect some dots and start shaping things. With this I hope to start gathering further insights, perspectives and input from discussions it may trigger. I hope this enables discussions and evolution on this key topic. From my side expect more and complementary material in the near future. With that: all feedback is welcome!

Organizations of Silos

How many times have you heard tech colleagues saying: “…Business decided that. We are here to implement it”? Or the business/product people saying “…but those are implementation details, Engineers will figure it out”? Sadly these are still rather common expressions in the “language” of many tech-enabled organizations.

Note 1: I use the wording “Business” and “Product” a bit interchangeably in this article. I know they are two very things, but for the sake of this article I mean the people that traditionally mostly work and lead activities of understanding and shaping the “What” should be developed in the product.

Note 2: when I use the term “tech-enabled Organizations” I refer to organizations where Tech is a core asset of the organization. It is not just a “feature factory” or “cost centre”, but it is a key strategic element for the business. Nowadays, this is a huge number of organizations, if not the majority.

The figure below showcases those two big and prevalent silos and how they tend to collaborate and work. As we can see there are many issues with it, for example:

  • People are “2 hops away from…”
    • Product people are two hops away from understanding how the product is being implemented (and any challenge associated with that)
    • Tech people are two hops away from direct customer feedback (and understanding how customers are using - or want to use - the product)
  • Limited information flows between silos (mostly we see unidirectional communication of “feature requests”), and as such we are using partial information to make decisions
  • We also have many hops to go from idea to implementation, which inherently means higher lead time, less accurate information and learning abilities
Product and Tech Silos


It seems logical and obvious that this is hindering us… however, we are still doing it: this is still the prevalent model. Why does this “separation of work” still happen? This is a complex topic and there is a lot behind it. Nevertheless, in the following I share two of the main reasons I see feeding the existence of this situation:

  • Legacy Culture of Silos: at some moment in time “siloed ways of working” and dynamics provided high-efficiency mechanisms for some organizations. For example, this was popular on factory floors in the early days of the Industrial Revolution, especially in situations where processes were clear and could be fully understood and parallelized.
    • However, the type of work that most organizations (especially building software) do today is non-trivial and mostly comprises unclear problems (which cannot be fully understood and planned upfront, i.e.: what Cynefin [Cynefin] describes as “Complex” domains). To be able to successfully approach problems on those domains we must enable higher levels of creativity, information flow [OrgTypology_Westrum] and collaboration for the people working on the problem. The culture of (information) silos is a legacy that hinders the effectiveness in such modern organizations.
  • Mechanistic/Reductionist thinking and bureaucratic organizations: reductionism is still the prevalent mental model in our society. It promotes breaking things into parts and having groups working in separation on those, i.e.: “divide and conquer”. Those parts don’t mingle, they focus on their part in isolation. That means that such organizations are “bureaucratic”, i.e.: we have people on different levels coordinating the work people are doing in each of the parts of the system.
    • This leads to a major issue: people end up optimizing for the parts in separation, which means they are NOT optimizing the whole product/system. As Russel Ackoff said [System-Thinking_Ackoff]: “if we have a system that is directed at improving by approaching its parts separately, you can be absolutely sure that the performance of the system as a whole will not improve!”

There are other points, but in my view, these two already provide a very strong motivation as to why many tech-enabled organizations still struggle when building complex products. To overcome these challenges I think we should take action in two main areas:

  • We must stop organization and team silos and enable higher levels of trust and information flow so we are able to better build our products (i.e.: enable close and trusting collaboration by the people that can best achieve what we are trying to do). In a nutshell: strive for creating a learning organization, where information flow is maximized, and as such there is more ability to understand problems and come up with better solutions.
  • We must be able to understand and optimize the overall product (the “Whole”), instead of focusing on optimizing separated parts (“local optimizations”). In this specific case, stop having teams (and organizations) where “product people” look at “what” shall we build next in the product in isolation; and then “tech people” simply build what is requested (classic “feature factory”). Instead, these two groups of people approach this process together and consider all the aspects of the product development, namely: understanding, design and implementation activities.

Bottom-line: tech-enabled organizations with these challenges (silos & bureaucracies) need to work on evolving to a state where the Product and Tech silos are broken and replaced with strong collaborations between all the disciplines in the product team. In the following section, I will introduce “ProdTech” as a way to frame this desired evolution state. Furthermore, I will also share some ideas on elements we need to consider and address to enable moving towards ProdTech.

Interesting fact: we can learn from history that breaking silos has proven to be a great strategy to address similar challenges in Tech departments/organizations. We have had this realization about a decade ago when we started breaking the Dev and Ops silos, and embracing DevOps [DevOps-Handbook] - check Figure below. This has led to great improvements in how we build products. However, this is still a thing from the Tech side/silo in the organization. You can find some extra thoughts of mine on this specific topic in this old talk here [Well-Rounded-Prod-Teams_Silva], and more recently also touched that in this interview [DevOps-Not-Enough_Silva], entitled “DevOps is Not Enough for Scaling and Evolving Tech-enabled Organizations”.

DevOps Evolution


From Prod + Tech Silos to ProdTech Teams & Orgs

In this section, I give some insights on concrete traits that I have been looking into to approach the challenge introduced in the previous section, namely: stop Product and Tech Silos and move into what I am calling “ProdTech” teams & organizations. So, ProdTech can be seen as a sort of next step of evolution that brings together Product and Tech alignment, collaboration and purpose.

ProdTech Team Evolution


Note 1: I think that this evolution will be extra challenging if the organization does not yet do DevOps and also has no foundations of Product Thinking [Escaping-Build-Trap_Perri]. If that is the case, it may make sense to first invest in developing those pillars, while keeping ProdTech ideas as north star.

Note 2: “Product” and “Tech” tend to be the two biggest and most prevalent silos in tech-enabled organizations. However, it is important to notice that there are a lot of disciplines and perspectives that are needed to successfully build a product. They may not necessarily be disciplines that typically are part of “Product” (e.g.: PM, PO, Business Analysis, etc.) or “Tech” (Engineers, Engineering Managers, Architects, etc.) organizations, e.g.: Design, Marketing, etc. So, although “ProdTech” highlights those two prevalent groups, my intention is not to suggest that other disciplines should be kept out of these teams. I believe ProdTech teams should be able to have all the disciplines they need to make their product successful. Bottom line: ProdTech teams and organizations should strive to not have function silos.

Note 3: what I call “ProdTech” is basically what many call “Product Teams” modern product-led organizations, where you have small autonomous teams with all the people that are needed to successfully build the product. However, I want to stress the fact that these (ProdTech) teams have no function silos (Product + Teach groups).

ProdTech in a Sociotechnical Systems framing

In order to better understand and position ProdTech, I use a sociotechnical systems [Sociotechnical_Silva] framing, see figure below. This framing assumes a silo free setting where teams should have all the necessary skills to maximize their ability to understand customers and build their products at high velocity. This approach also makes clear we are treating the system as an Open Sociotechnical System [OST_deGuerre], which considers teams (socio), the product (technical) and its environment (customer, market, etc.).

Sociotechnical Evolution Loop


The model in a nutshell:

  • Teams (without silos) focus on understanding customers’ problems and market challenges (the environment) and with that they discover & shape how they should build and evolve their product (the technical systems). (They obviously balance that with the business/company mission and objectives).
  • This does not mean everyone on the team is always working on all tasks that the team needs to work on. Product (& Design) people tend to have a higher intensity of work on shaping the “understanding of customer problem”, while Tech people will have a higher intensity of work on the setting up the technical architecture and building the product. However, they are involved in each other’s activities, especially “initial shaping” of things, and are available to exchange knowledge, in order to maximize their ability to to solve the different problems they face.
  • This working closely together should also enable building the product better and faster (achieving what Jon Smart says “Better Value Sooner Safer Happier” [BVSSH_Smart]), i.e.: maximizing value exchange with customer while achieving “continuous delivery” at high-velocity and having “happier” teams. (In this article I will not develop this last perspective - “team happiness”. This will be the topic of future writings - but it is known that creating conditions to have a trusting and safe environment is fundamental for performing and sustainable organizations).

ProdTech Thinking Model: Who ⇒ What ⇒ How

As discussed in previous section, ProdTech must consider all the key dimensions that are at play in the sociotechnical system, namely: ProdTech teams and organizations (“Who”), who are key to understand the customer problem (discover and shape the “What”) and with that clear alignment they find ways to build the best Product (shape the “How”). Another key from architecting such sociotechnical systems is the importance of learning and embracing that the “What” and “How” (and other environment elements) will influence the ProdTech teams’ setup and topology (the “Who”).

ProdTech Thinking Model


In the following, I will look into each of the dimensions of this thinking model (Who, What & How) and share some remarks and ideas to consider when approaching them.

Note: due to the focus of this article, I do not depict the “Why” in this sketch (you can find it in other of my articles). Nevertheless, it is primordial that there is a clear “Why” on the multiple scopes of the organization, namely: the “Why” (purpose) of the company, which provides “overall purpose, mission and vision” for the whole company, and then the “Why” of each scope in the company, which also defines those elements per scope. The latter should always be aligned and contribute to the former.

Who: Well Scoped Teams & With all necessary disciplines

The starting point for setting up effective (and happy) ProdTech teams and organizations is to have a well scoped team, with a clear purpose (contributing to the bigger mission) and with all necessary disciplines and abilities to build the product they own.

To successfully enable that, teams must have a clear scope of work [Minimalistic-Arch_Malan]. Clear scope of work means having a well defined boundary where the team can be as autonomous and effective as possible on building their product (including having enough “cognitive load” to own that particular scope, as described in eam Topologies [Team-Topologies]). Boundary here touches on the idea of “information hiding” [Decomposing_Parnas], which is key to enable effective modularization. One can accomplish that scope/boundary definition in different ways, for example using Domain-Driven Design (DDD) techniques [DDD-Crew] to understand the (sub)domains at play and how to shape clear scopes of work per team. However, it is very important to acknowledge that ProdTeam teams and their scope of work are (almost) always part of a bigger surrounding scope, see figure below (where I share a typical product org taxonomy [Prod-Taxonomy] and relevant inter-relationships between scopes). As such, teams must also be aligned and contribute to that bigger surrounding scope/system (as described in Systems Thinking [System-Thinking_Ackoff]). This means having alignment with the surrounding scope, collaborating and exchanging information when needed (which means having clear interfaces with related scopes). This tends to lead to “information hiding” within the scope, clear interfaces and purpose that align with the surrounding scope/system purpose. With this the team scope can be effective and clearly contribute to the product scope they belong to.

ProdTech - Who - Scopes


This is important, since the scope of work for the team and the ambition defined for that scope/product, also defines another key element: the disciplines needed to be successful. This is where we start seeing the mix of Product and Tech people and disciplines. A very important point here is that the team is the unit (as defined in Team Topologies [Team-Topologies]): we do not treat the team as a grouping of product team/individuals + tech teams/individuals! It is also key to acknowledge that sometimes the complexity (and required cognitive load) and scope of work within a team scope becomes too big. At that moment we must re-evaluate how to adjust (re-organize/evolve). This is all normal and should not be seen as a “bad signal”, especially if that complexity comes from addressing new relevant customer problems. It is essential to embrace this sort of evolution (i.e.: team evolution influenced by the customer problems and/or evolution of the technical product). This may mean that we need to have some people continuously sensing the signals from the different teams and furthermore bring alignment across them. This team may be seen as a sort of “Enabling Teams” (as in Team Topologies [Team-Topologies]). In the example below I share one example of such a team, which I call “Product Leadership Enabling Team”. This team focuses on enabling the teams within the product scope. They focus on the essential sociotechnical systems dimensions, namely: Who, What & How. This is typically a “trio” [Leadership-Trio_Kua], who leads those core perspectives across product teams: Engineering Manager (Who) + Product Manager (What) + Tech Lead (How). These work very closely with each other to balance all those key dimensions and with that make sure the ProdTech team is happy and successful.

Note: not all organizations need these formal functions. In more mature organizations these may be roles taken by members on the teams within the product scope. However, from my experience these functions are very helpful to reinforce the knowledge networks in the organization and with that enable better conversations. Furthermore, they cater to all the different key aspects for all the teams in the product scope.

ProdTech - Who - Product Leadership Enabling Team


What: Discovering & Shaping the Product together

Well scoped ProdTech teams with all necessary disciplines working closely together are key to building great products. To accomplish that, a particularly important activity is “starting things together” (as John Cutler explores here]). This is a rather important activity that tends to still be overlooked in most organizations currently, as in general product people do the whole “discovery and shaping of problem” in isolation (from the rest of the team) and then pass that to Tech to build. Basically, that means: discovery and shaping are not done using the information and knowledge of the Tech people (i.e.: do not use maximum information and knowledge available). Furthermore, and to make things worse, those two “silos” will also lose this opportunity to maximize their shaping and alignment on the outcomes they should strive for. This is not conducive to maximize the abilities of the team. Teresa Torres covers this topic here [Engineers-Prod-Discovery_Torres], where she goes over the opportunities we miss when engineers/Tech are kept out of product discovery activities, and why we should avoid that. A very interesting advantage of involving engineers into the product discovery activities is: they bring very different skills and perspectives, which complement the ones from Product people.

Another interesting related research with this topic comes from Ron Westrum [OrgTypology_Westrum]. Basically, Dr. Westrum research indicates that modern tech-enabled organizations should strive to be what he calls “Generative Organizations”. These are organizations that maximize information flow in order to increase their ability to find creative solutions for their complex problems. For that to happen, and again, it is key to stop information silos, even more in team scopes.

Given this, it is essential that ProdTech teams are able to discover and shape “what” to develop in their product together. For that to happen effectively, they must also nurture a safe and trusting environment where the different disciplines/people can “speak up”. This should enable maximizing the information flow and also be able to move at high-velocity on building the product.

How: Building Tech Product for the best outcomes

With a well scoped ProdTech team, who is able to discover and shape the product development together, we maximize our ability to approach the actual building of the tech product for the best outcomes. Best outcomes here mean being able to maximize the value exchange with customers at a sustainable pace. What does that mean? Again touches the ability of the ProdTeam (together) to understand what is important to build and evolve in the product and execute it in a continuous fashion.

This means balancing and prioritizing, as needed, the activities of product innovation (i.e.: building features or elements that maximize value exchange with the customer) and technical innovation (i.e.: evolving the technical architecture to enable product innovation to be built at high-pace continuously). Being a ProdTech team means catering continuously for this balancing act, which should enable the best overall outcomes for the product.

Although this sounds logical, to me this is one of the biggest challenges we face today when building tech-enabled products, especially when we have strong product + tech Silos. The common pattern I see in those organizations is: product pushes for product innovation and Tech is on a continuous stress to build those in a “house of cards” (as they tend to not be able to accommodate the necessary technical innovation - due to the classical “business feature has higher prio”). This also means technical debt and in fact inability of having the best technical architecture to build the product at high velocity. This is why being capable of understanding these multiple dimensions and how to prioritize work across them to achieve the best outcomes is a fundamental trait of ProdTech teams. This is difficult to do if we keep on having those silos and politics in the team.

I see a lot of interesting work emerging that can facilitate these discussions. For example, Site Reliability Engineering (SRE) principles (e.g.: SLI, SLO, Error Budget) [SRE_Google] offer a simple and systematic language to discuss the balancing of product and tech innovations. Another interesting practice is “Mobbing” [Mob-Programming], which typically is applied to software development activities, where the whole team assembles to work on something, and with that develop trust and maximize information flow/availability. However, these practices can also be applied to collaboration between product and tech people in teams, i.e.: involve the whole team, and stop with “silos” per task, especially in complex tasks (e.g.: when starting a new activity). However, these are just some examples of tools and methods, a healthy and trusting ProdTech team should be able to have the space and agency to have the conversations on product and technical innovation continuously and not have the pressure of just doing one (in general business/product innovations).

Bonus point: Emergence (1 + 1 = 3)

When we are able to approach the elements and traits shared in the previous section, we “unlock” a super team power, namely what Systems Thinking [System-Thinking_Ackoff] calls “emergence”: 1 + 1 = 3.

What does that mean? By having ProdTech teams where all disciplines can work more closely together, have a holistic understanding of the problems and alignment on how to approach them, we maximize the ability to solve them. That is an obvious consequence. However, there is more to this, namely: by enabling everyone to interact/discuss/relate with each other, we create conditions for “emergence” (i.e.: discover things that are not possible/visible when you approach problems from a single silo/part point-of-view). This means that by having product and tech people working more closely with each other, and understanding each other better, we enable them to experiment on business and tech innovations and together figure out new things. This means, they start seeing problems, ideas and solutions that they would never consider if not collaborating. For example, being able to experiment a new feature that requires deep technical insight and can be positioned as an enabler for a new product opportunity.

Another important consequence of this property is the fact that ProdTech teams understand each other better and are also more equipped to better understand their environment. They can embrace that by being truly Open System [OST_deGuerre] and as such comprehend the relations with neighboring scopes in the organization, their customer and also the market forces that influence their product. They will also be more able to handle other things that impact their team’s health, e.g.: be able to better react in extraordinary situations, such as the recent pandemic. This awareness and sensitivity comes from embracing and developing truly “Generative” [OrgTypology_Westrum] sociotechnical systems.

The Unicorn Project book [Unicorn-Project_Kim] has several interesting examples of this “super power” in its last chapters, where basically the sort of collaboration I emphasize for ProdTech teams unlocks “disruptive innovation” at Parts Unlimited (the company where the story takes place). This is a fiction book, but from my experiences it is rather realistic and touches a key point I share in the previous section: we have Product (led by Maggie, Product Manager), Tech (led by Maxine, Tech Lead) and People (led by Kurt, Engineering Manager) perspectives working very closely together and with a clear aligned outcome (the Unicorn Project goals).

Conclusion & Next Steps

There are a lot of open threads and questions on this “evolution” step (from Prod+Tech silos to ProdTech teams and organizations). Some organizations are already exploring this, but most are still shy on how far they go on breaking these silos. However, in the vast majority of tech-enabled organizations, the silos and division of Product and Tech organizations are still grounded in extremely strong pillars.

Changing that will not be easy and maybe in some cases may not even be a good idea as the next step (i.e.: they may need to evolve some other elements, e.g.: DevOps and Product Thinking practices). However, I believe that striving for no-function silos and enabling stronger flows of information, i.e.: having truly learning organizations will always lead to better outcomes. The legacy silo cultures and the mainstream reductionist thinking will continue making these changes difficult. This is especially challenging in cases where companies’ leadership are strong supporters of those ideas (and heroic principles). However, I would argue that any tech-enabled organization that really wants to maximize their abilities must empower highly effective and happy (ProdTech) teams. Failing to do that will mean not achieving their full potential and most likely with a lot more investment to achieve sub-optimal outcomes.

With this proposal of “closer collaborations” I am not saying that the ProdTech team is now all the time working together in all the different activities (although that may even be something interesting to explore in some situations - as Mobbing experiments are showing). However, I believe we must create conditions where the whole team can help understanding and shaping the direction for the product development, with all the information and perspectives in the team.

I consider the sociotechnical systems framing and the ProdTech elements I share in this article provides a good starting point and thinking model to start conversations around this evolution. However, this is just the beginning, and I reckon this is not a trivial topic, so it is key to further research and learn how to develop this topic. From my side, expect more developments, especially on how to link this to my sociotechnical systems and architecture writings and activities [Sociotechnical_Silva] and especially more ideas and guidance on “how to approach” this seemingly obvious but not trivial evolution (given all the dimensions that require change).

References

Conversation

ℹ️ I offer consulting services and products on this topic

If you are looking for help on these topics feel free to contacting me, and/or check my consulting and products pages for more details on how I may be of help.