One of the first articles I wrote was on the topic of collaboration (you can read it here). That was almost 10 years ago. At the time I had been working in the Technology/Software world for 5 years, after a stint doing Interaction/UI/UX work in agencies. While agency work has a lot of positive aspects to it, I didn’t think I was a good fit for it. I found the relationship and ultimately sense of ownership with a solution very fleeting, since in essence the engagement with the client had a time stamp on it, after which you simply started working on something else. For some Design professionals, that’s what they crave the most: diversity of projects, jumping around from challenge to challenge. Personally, I’ve always preferred to have a sense of continued storytelling, meaning, launching a product to market doesn’t close that narrative, quite the opposite. It opens a new chapter, where there’s constant engagement with clients, and where the utilization of the product produces findings that are fundamental for the growth of that solution and the business that is behind it. The opportunities to take something from 0 to 1 are immense, and taking something from 1 to infinity are even bigger. It all depends on vision, strategy, and much like the title states, overcoming silos. I know these past sentences have been a very run around way for me to come to the topic of this article, which is actually a reflection on the silos that I’ve always witnessed when working in the Technology world, and how even in 2025 they are still very much felt, even if everyone is betting that AI will revolutionize how we work and collaborate (and that may well be the case, but probably not in the way everyone thinks). Here’s what my experience in the field has taught me, and that hopefully I can synthesize in this brief article.

Silos are the default operational process. Everyone wants to stay in their lane, if we adopt a racing metaphor. Meaning, everyone working in Technology and delivering solid product solutions wants to do well, have good performance evaluations, and that typically means excelling at what they do, with their teams, in their own ecosystem/microcosms. For all the articles, training, Design Thinking conferences that exist, it’s always been surprising to me how easy it is for people who work in Software development to quickly fall back on archaic view points of how these solutions should be delivered. By that I mean, Product Ownership conceives a strategy, writes users stories and a builds a roadmap, Design crafts the information architecture and UI, and Development receives all the previous chapters and goes about implementing everything according to what is outlined. This waterfall process of building solutions, is something that many people in the field dismiss as something of the past, but in all the years I’ve been working in this universe, it seems to be the process that is always present. And it’s easy to understand why: it allows for everyone to have a sense of their scope of responsibilities, all actions follow a logical approach, and everyone is a master of their own domain/craft. The problem as it turns out is that this process is rigid, doesn’t take into account enough research, and removes partners from a true connection with their users/clients. Design Thinking hasn’t been a methodology/approach whose goal is solely to introduce more research and awareness of clients’ expectations and needs: it has been in essence a way to humanize the process, and bring more collaboration between all teams. Terminology such as “synergy” and “user centric” are brandished around continuously, firstly because they sound great, and it has become a de facto pitch for any consulting firm selling Design services, but what it actually surfaces, is the underlying aspects that products resonate further, produce more engagement and adoption, when there is indeed stronger collaboration between teams, when more research his leveraged, and where there’s flexibility which allows teams to quickly share their learnings and implement sound decisioning based on those data points. This rapid decisioning process can’t be implemented when silos exist: these are per default a way to keep teams in their own compartments. And that invariably is a recipe for frustration.

Are Silos full proof against failure? No, they don’t. Silos create an appearance of organization and structure. They provide this false sense of security due to the fact that teams are so narrowly focused on their own scope and activities. Every task is itemized in a sequence that is logically illustrated, one where the ultimate goal is always in sight. The problem with this type of approach, lies with the lack of agility to respond to market and research data that is presented. Software/product solutions are the result of research that occurs in the market, something that is ever evolving and that is conditioned by macro (and micro) economic factors, political headwinds, environmental progress, social dynamics, and the list goes on. Nothing is created in a vacuum, no solution is devised in an insulated bubble, since the teams creating it live in the real work and the solution itself has to eventually live in that real world, be experienced by actual users, all factors that influence the gestation but also how a solution itself will exist (one only has to think about how much digital product experiences had to morph from web driven experiences and move towards the direction of applications, and now how AI is altering the way we all work, thanks to this ability to parse through large swaths of information to provide recommendations and summarizations that enable insights to be delivered that much quicker). The point is: I’ve witnessed organizations with siloed approaches which invariably resulted in archaic ways to deliver product solutions, impacting users/clients, and ultimately the business itself. The lack of silos doesn’t mean teams work in a perpetual state of chaos: it means teams are aware of their responsibilities, and they all play a part in converging their view point/point of view, in making sure what is being crafted is meaningful, timely, and relevant (for clients and the business itself).

Overcoming Silos. Silos are a comfortable blanket, almost a type of inertia that is welcomed for organizations who feel they have nothing to prove, or the ones who think their market can’t be disrupted. If life has taught us anything, even Jeff Goldblum in Steven Spielberg’s “Jurassic Park”, is that “life finds a way”. Meaning: while silos may gave the illusion of control, of discipline, of premeditated outcomes, it’s an illusionary state. The world moves incredibly fast, and with the introduction of a catalyst such as AI, everything in product gestation moves even faster. This perpetual movement can’t and shouldn’t be done without ethical considerations obviously, but when it comes to how teams work in Product development, this is something that all teams should always take into consideration: seek collaboration with your peers sooner rather than later. There’s a path for everything, and that path is easier to track when you have a clear support of other teams, when your statements are empowered by your expertise, but also grounded on the view points and insights of your collaborators. Overcoming silos is not solely about how teams and tasks are organized, it also refers to how mentalities are meant to be more open, to be far more flexible, and seek partnerships that bring co-ownership, but also a robust intellectual prowess that can otherwise be underutilized, and worse yet, completely wasted. As much as AI is a catalyst, there’s no lab in existence where there aren’t scientists who know how to experiment, how to bring compounds together, leveraging catalysts when the timing is right. Product Development, Product Design, Development, are those scientists, and if AI is indeed a powerful catalyst, removing silos will only make these processes and these paths that much more exciting, informed, and ultimately relevant for users and the business itself.

Silos and sabotaging other perspectives. The Apple TV show “Silo” is an apt metaphor for what this article is aiming to touch upon. There are always those who are interested in maintaining silos, preventing tighter collaboration opportunities. I’ve witnessed that countless times, and that usually results in technical and design debt that just keeps expanding further and further, much like a virus that is never addressed. Failing to to look beyond your own silo, or point of view, isolates teams (in terms of knowledge base, in terms of technology stacks, in terms of research findings, and the list goes on), and eventually becomes a blockage and a burden that everyone complains about (the countless times I’ve heard complaints from teams on certain decisions that had been taken, and their consequences, and the lack of action to address them). Not to be overly dramatic, but my point here is: be weary of those who are always very intent in maintaining a status quo, those who refuse to look elsewhere, to learn from others, who blankly (and bleakly) stare at facts and data, refusing to grow in any meaningful way because it challenges their perceived notion of what their roles are, and where they stand in the perpetually moving engine of Product Conception and Release. The world is moving faster and faster, and these silos, be they mental or organizational, will have to rethink their existence because agility, dexterity, and ultimately ability to creatively engage in the market with clients/users will only become more and more pressing.

I’ll end this article with a quote from Theodore Roosevelt:

“The most important single ingredient in the formula of success is knowing how to get along with people.”

Overcoming Silos was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.