From Silos to Synergy: Cross-Functional Mechanisms for Design, Product, and Engineering Leaders

It is such a privilege to be able to come together and learn from each other about how our teams can collaborate better because, let's face it, the truth is it's so easy to suck at working together. Cross-functional collaboration doesn't just happen, and the bigger our teams get, the more pervasive this suckiness becomes. It's human nature. We make small decisions to take the path of least resistance, and these add up over time and build into bad habits that lead to misalignment, constant meetings, and a "not my circus, not my monkeys" mentality between teams. It's like the ground is tilted—if we're passive, we're kind of sliding in the wrong direction. Neutral is not really an option here.
That's why we need to resist and instead work actively, intentionally, and continuously toward the opposite. As a designer, I believe we should treat collaboration as a product itself—your cross-functional operating system, if you will. And just like the products we design, our cross-functional operating system should be intentionally designed, nurtured, and continuously improved over time.
My name is Andrew Bolis, Lithuanian descent if you're curious, and I lead design research, analytics, and experimentation on the product team at Sephora in North America. We've spent the last eight years reimagining pretty much every experience in our ecosystem—customer-facing, employee-facing—and it's been a real journey. From my early days as an entrepreneur to my time in the agency world to now, my time in retail and e-commerce, my experience has kind of broadened from designing screens to teams and now to how entire organizations function and collaborate.
If I could give my former self a piece of advice, I would say, "Why not you? Stop waiting for someone to come and save you. Your operational design ideas are just as good as your UX design ideas, so put them out there." If cross-functional chaos feels like an injustice to you and you have an inner flame and a vision for how life could be better, you can and should disrupt the status quo.
Today, I'm going to give you 12 practical ideas—small upgrades for your cross-functional collaboration operating system. Proven things I've seen in my career that can help reduce meetings, increase alignment, and make more space for work to be fun again. These are going to be practical, bite-sized, and super basic. Nothing groundbreaking or revolutionary here. I want to give you ideas that you can walk away with and implement. Just like the best design is obvious, I hope a lot of these things leave you saying, "Well duh, obviously, but why aren't we doing that?" Because based on the conversations I've had with other design leaders and peers in the industry, it's surprising how often these things are overlooked.
Whether these feel obvious to you or new, I'll share what worked for me and some practical steps so you can do the same. Whether you call it design operations, anything from design operations all the way to operating system management—call it whatever you want. My point is that this needs to be treated as its own distinct thing, and you can impact change regardless of your level. But the biggest onus is on us as leaders to make sure our ways of working are not a living hell for our teams. We've all been there and experienced it ourselves.
As leaders, we talk a lot about empathy. This is our chance to walk the walk. Oh, I'm getting a call. Hello? Oh, we hired a new front-end developer? Great! Oh, no one from design or product was on the interview panel? Just 20 rounds with engineering? And they'll primarily be working with design and product every day? Cool, can't wait to meet them. Bye.
Sorry about that. Number one: Make interviews cross-functional. Cross-functional collaboration starts before projects—with people and hiring. If the people a candidate is going to be working with day-to-day are not on their interview panel, that's whack. Design, product, and engineering should all be able to contribute and feel good about each other's hiring decisions. If people are just appearing out of thin air, speak up—that's not okay. People are the foundation of everything else. Literally, everything else is secondary. So don't rush hiring decisions. They're the most important decision you'll make as a manager. They have to be intentional, inclusive, and cross-functional. That signals mutual respect and empowers your teams for downstream success.
Okay, now we can talk about projects. In fact, let's move on and check in on Project Hot Dog—code name top secret project. Okay, so product is in discovery, design is in empathize (we love empathize), and engineering is also in discovery. Okay, that seems aligned. Oh, but product is in discovery of customer needs, and engineering is in technical discovery. Okay. And design is designing solutions, but engineering architects are doing solution designs. Stop the madness.
Map and unify your processes across teams. Call it a service blueprint if you will. It's natural that over time disparate, bottom-up processes where everyone's kind of marching to the beat of their own drum have arisen organically. But ambiguity in the process and unclear expectations about what is expected of each function at each phase of the product lifecycle is stressful and frustrating AF. If your processes across functions feel like a bowl of messy spaghetti, some housekeeping is in order.
So here's how I've seen this done well in the past. Start with a mapping exercise—FigJam is great for this. This is a very simplified example that, you know, a five-year-old could understand, but yours will probably be more complex. As a service mapping exercise, get all the leaders from each function in a room. Map out each team's phases, activities, artifacts, and ceremonies on a single timeline, and see where they overlap. Work together, put on a holistic lens, and align on new phases, activities, artifacts, and owners that keep the greater good of your cross-functional team in mind.
I recommend producing a high-level global view with just the key things that can be used for the entire cross-functional team and then separate layers for specific functions to go into more detail on the nuance and detail that are specific to them. Obviously, socialize and iterate. Treat this as a product—continuously improve it. But something here is better than nothing.
If you need a starting point for a framework, I've seen them all—I know there's a hundred out there. My personal favorite is this one from Forrester called the Design Framework. I think it does a great job balancing product, design, and engineering activities. It feels intuitive and very true to real-life experiences.
Oh, I'm getting a phone call. Hello? Go for Andrew. Oh, you're not quite ready for a meeting to share your work? Okay, you've said that for the last three weeks, and now we're behind. Okay, hold on, I'm getting another call. Oh my God, the only time the stakeholders have available for a meeting is in 20 years. Okay, you want to just do three kickoffs to accommodate? Okay, works for me. Bye.
If this sounds like you, you should automate with recurring product ceremonies. Waiting for when people feel ready is a disaster waiting to happen. Again, it's human nature—we never quite feel ready, and by the time we do, the calendar is already filled up. Scheduling ad hoc meetings and finding time that works for all the stakeholders is a full-time job, and it's not the best use of a manager's time.
There's a better way. Ceremonies are recurring structured gatherings for consistent alignment, collaboration, and progress across teams. These are reserved times in the calendar. You're probably familiar with agile ceremonies like sprint planning and retrospectives—those are great for engineering, but you don't have to just stick to those. People invented those. Your people. So invent. There's no reason you can't invent your own that work for your scenario.
Here's how I approach this: I audit my calendar. I look for trends in my manually scheduled, sporadic, reactive meetings and replace them with cross-functional ceremonies that run on autopilot. Invite all cross-functional partners, update agendas a week in advance so people can self-select if the subject matter is applicable to them, and off you're off to the races. The consistency, predictability, and structure do wonders for productivity. Sharing progress weekly—rain or shine—becomes the culture.
It also creates a culture of openness, transparency, and visibility where other functions or people who have bandwidth or curiosity can drop in, share opportunities for synergy, or call out dependencies that wouldn't have otherwise come to light. Set the system up and let it work for you.
Next, another scenario that really grinds my gears—tell me if this sounds familiar. Product meets with stakeholders to capture the requirements. Then product meets with design to kick off design. Then design meets with the stakeholders to ask more questions and review designs. Then product meets with engineering to kick off the engineering activities. Then design meets with engineering to share more details about the designs. It's a heartbreaking game of broken telephone.
So here's a radical idea: Replace all that and start every project with a cross-functional kickoff. Number four. It sounds so obvious, but it's not happening at a lot of companies that still have a siloed culture. Ah, how refreshing. Get stakeholders, product, design, and engineering all in the same room at the same time so everyone can get the context, ask questions, hear the same answers, and leave aligned and excited.
Excuse me, I'm getting another call. Hello? No, I can talk. Oh, you're waiting for John to ask Susie what price format she wants to use? But you know Susie—you present design to her like every single week. Why not just ask her directly and CC John? Yeah, you're totally allowed to do that. Okay. Bye.
One of the worst habits I see and hear about is relying on product managers and project managers to be these middlemen or go-betweens for design, engineering, and stakeholders—i.e., a bottleneck. It's fundamentally bad for productivity to have bottlenecks, and it's a poor use of a product manager's brain. It's not their job. Instead, talk directly to each other.
Number five: Establish direct lines of communication. It makes things faster, builds rapport and trust, and influences within the cross-functional team. Let's look at it linearly. Design asks product, who asks the stakeholder, who then tells product the answer, who tells design, who then tells impacted teams like engineering. That's five hops. Five opportunities for something to get lost in translation or misrepresented—which it always does.
Enough of this nonsense. Compare it to this: Design asks the stakeholder directly, CC's product and engineering for visibility, and everyone gets to hear both the question and the answer directly from the horse's mouths. Plus, this allows for follow-up questions that are function-specific and probably wouldn't have occurred to the middleman to ask. Everyone gets that context and the latest information instantly.
If you notice yourself becoming a middleman, take it as an opportunity to empower your team and change your team's behavior. Say, "Hey, great question—why don't you reach out to so-and-so and CC the team for visibility?"
Uh oh, one second. Oh, this time it's a message. Okay.
Uh, okay, I just got added to a thread between product and the stakeholders. Okay, it looks like they aligned on a new flow for the big Hot Dog project, and... oh, this was a week ago. Oh, and design and engineering were not on the thread. Um, let me just zoom in here. Okay, and I can tell immediately that this is going to be not feasible.
Uh, okay. Esteemed colleagues, I hate to be the be—actually, I'll finish that later. Um, is that relatable or what?
So, the solution for this—and this is one of my favorite things that I've seen in my career—is to create cross-functional Slack and Teams channels for each project. Number six. This really supercharges and systemizes the previous point about direct communications. As we move fast, conversations happen on the fly, requirements are constantly evolving, and people find it hard to keep up. Keeping everyone in the loop is a big challenge, so we often just ping the first one or two people that come to mind and forget to loop in everyone else who might be impacted. Sometimes we don’t even realize all the people who may be impacted.
Here’s how we set it up: in Slack and Teams, for example, create a general public channel for everyone, including stakeholders, for open conversation and questions that affect everyone. Then create private, function-specific channels and function-to-function channels for safe, more focused conversation. I've noticed that people are very good at self-selecting the right altitude and the right audience for their questions and messages, and the concern about spamming really doesn’t come to light.
Make this part of your new project checklist so it happens with every new project. Empower everyone to set this up. In my experience, UX often is the first one to set up these channels because concepting happens early in the process, and there are a lot of discussions that come out of that. But really, anyone can do this. The philosophy should just be: if there's no channel, create one.
Number seven: Practice iterative, cross-functionally inclusive design and PRD refinement. I know that’s a lot of words. PRD, by the way, if you're not familiar, is a Product Requirements Document. It’s a mouthful, but I want you to focus on the words iterative and inclusive. Sharing work in progress can be very vulnerable, and human nature, again, tends to retreat into silos, letting perfectionism get in the way of progress. But product building is a team sport, and working out in the open is non-negotiable.
We often think iterative is just for design, but embracing an iterative mindset is actually transformative in all areas. You can use it for PRDs, for scoping documents, for strategy decks, and even timelines. All of these things start off kind of loose, and as you work through, they get tighter and more concrete. Taking this iterative approach opens the door for collaboration and synergy a lot sooner, ultimately leading to increased effectiveness and quality. Stakeholders and partners adapt to this model quite quickly, as long as you set the tone for progress over perfection and explain that it’s an iterative, collaborative, and open process. Psychological safety is also important to keep in mind.
People generally love to be involved and come along for the journey. Here’s how it looks: each week, we come together at review ceremonies to discuss the latest work in progress. The best results are when everyone comes along early. Then individual teams go back, refine, and come back the next week to review. We often invite "guest stars"—like merch, legal, or marketing—people who aren’t in the product triad, as needed, depending on the project. This repeats weekly, and as we go, the fidelity, confidence, and accuracy of whatever we’re working on crystallizes.
If you don’t have this type of system, I highly encourage it for all functions.
Number eight: Templatize your PRDs, research plans, Figma files, release announcements—everything. We’re working on 20+ PRDs at any given time, and Joe’s KPIs are at the top of his, Rita’s are 50 scrolls down, and Millie Bobby Brown didn’t even know they’re supposed to do that. Creating a PRD template and treating it like a product—publishing it quickly and iterating—can really help. There are many brilliant templates out there. My favorite is one from a partnership between Atlassian and Lenny Rachitsky.
The challenge is to make your template general enough that it applies to most projects but specific enough to take the guesswork out of "What does a good PRD mean at my company?" A templatized structure and starting point free up product to focus on higher-value activities than formatting documents. Your partner teams, who traverse tons of PRDs daily, will appreciate knowing exactly where to find information in a consistent format.
Oh, another call.
Hello? Okay, so you’ll send us the PowerPoint file, and you want us to leave our comments and add our slides. No problem. Oh, you want us to email the deck back to you—all 10 of us? Okay, and you’re going to deconflict all the comments and then merge all our slides across 10 files? Okay, and it’s already 100 megabytes? Not my circus.
Oh, one sec.
Hello? Oh, the Figma screenshots in Jira don’t match the ones in the design file? Please hold.
Hello? Okay, the objectives for the Hot Dog project in the research plan don’t match the ones in the strategy deck? Okay, and the Excel roadmap doesn’t match the Jira roadmap? Oh, and the stakeholders have started creating their own version of the roadmap in PowerPoint? Cool. Sounds like everything’s going great. Thanks for the update. Bye.
Why is it like this? Multiple sources of truth are insidious. Left untreated, they snowball and wreak havoc. Everyone’s acting on different information and wasting time trying to chase down which truth is the truest. So it’s incumbent on all of us, as the type of people who come to these conferences, to be the "one source of truth" police.
Number nine: We’re tech people—use the cloud. Multiplayer mode is the norm now. Send a cloud link, invite collaborators, and set permissions. Attaching huge PowerPoint files to email and calling it collaboration? Banned. Hostile to your collaborators and yourself. Attaching Figma screenshots in Jira—or whatever issue tracker you use? Banned. Out of date the moment you upload them. Link directly to the Figma frame instead, so people can see the latest source of truth and the surrounding screens for context.
Finally, regurgitating content that already exists in a more reliable source of truth elsewhere? Banned. If you see it happening, speak up. Are you sure you need to add a screenshot of the timeline to the PRD? You going to update that every morning? Just post the link to the live file.
Oh God, what now?
Hello, design team. How can I help you? Oh, the build starts in two days, and you forgot to submit a UX intake form? Okay, you want to hop on a quick call? All right. The whole team’s at capacity, but sure.
This is how I looked for my first years as a design leader: sitting around bitter, waiting for a personal invitation to meetings I knew I needed to be a part of. I was constantly brought in late—me and my team—and I just always thought it was a failure on everyone else’s part. Kind of pathetic.
Number 10: Outlaw intake forms. It turns out this was a failure of my mindset and of our intake system. Intake is a sign of a failed engagement model. This is a quote from Peter Merholz, one of my most influential design leadership gurus, and it blew my mind when I first heard it. It means you’re not being a good team player, a good corporate citizen, and your systems are flawed.
Don’t wait to be invited. You want to be respected as a team player? You have to act like one. It’s on you to actively track the roadmap, attend planning ceremonies and meetings, and ensure your function is represented where you know it needs to be.
Number 11: Present your own work. Okay, awful AI image, but I could not help myself—what is happening in the background?
Okay, so design and engineering have a tendency to hide behind product and let them do all the talking. Stop that. In the short term, it can seem faster and easier to present someone else’s work or let someone else present yours. But in the long term, this erodes an ownership mentality and pride of work that are so important. You’ve got to be a team player, so it’s occasionally okay and permissible, but this should be the exception, not the rule.
Instead, picture this: Product sets the stage, explaining the strategy and the business opportunity. Design shares the research insights and walks through a quick prototype. And engineering gives an overview of the tech architecture and demos the code. And the crowd goes wild. When you have a culture of presenting your own work, teams feel more ownership, accountability, and pride, which again leads to better quality and business outcomes.
Whoa, did you see that? The elusive final requirements. I swear I just saw it. They said it didn’t exist. They said, "When pigs fly." But I knew it was real.
Wait—was that final designs? I knew there was such a thing.
I’m just kidding. Final requirements and final designs do not exist. There’s literally no such thing. Final implies frozen in a moment in time, but we’re never frozen. Everything’s constantly moving and changing. As you go through discovery and build, you’re continuously adapting and updating your designs and requirements based on feasibility and effort in partnership with engineering, up until the very last second.
Sometimes I like to think of production as the final design. But even there, there’s a constant flux of content and functionality layered in. It’s just too dynamic to call anything final. It’s just a moment in time. That’s why we should all stop waiting for final requirements and final designs.
Oh my God, one more call.
Hello? Hello? You’re ready to start design, but requirements aren’t final? Do you know how exciting this is? Let me call you back.
Okay, ambiguous requirements mean design and engineering have an outsized opportunity to influence and shape the product’s direction versus being handed a finished script. The most successful projects in my career have started this way: design and engineering getting scrappy, testing hypotheses, and often what we came up with turned into mandatory requirements once product managers came on board and helped us get organized.
So banish the "final" from your culture, and rebrand with more accurate names that describe the level of fidelity you’ve reached. When you’re in the strategy phase, things are very high-level, loose, low fidelity, so call them "concept designs" or, for requirements, "opportunity overview." I’m not going to go through all of these, but you can see we call them "discovery-ready designs" and "requirements" or "dev-ready designs" so that each phase outputs something just enough fidelity for the next phase to pick up and continue working on.
So there you have it—12 practical ideas to upgrade your cross-functional operating system based on what I’ve seen be most impactful in my career. Individually, these seem small, but if you implement even three, I promise you’ll see exponential outcomes that will drastically improve the quality of life for your teams and the business outcomes.
Implementing these has allowed my teams to generate more innovation than we ever thought possible, take on more ambitious initiatives, and—what’s been most meaningful to me as a leader—it’s created an empowered, effective, and unified culture across teams, freeing people up to do the best work of their careers and have fun doing it. And, of course, business results follow.
I want to leave you with some closing thoughts and a call to action. Today’s chaos doesn’t have to be tomorrow’s reality. You have the power to transform the ways your teams work together. If you’re that person who feels that inner flame of frustration and feels like chaos in ways of working is an injustice—lean into that. Don’t settle for the way things have always been done. People aren’t as attached to them as you think. Don’t overthink it—just start small. For a lot of these, you can just do them. You don’t have to get paralyzed by committees and approvals.
"Ask for forgiveness, not permission" is always a good mantra. I’ve learned time and time again: if it’s more efficient and makes life easier for most people, it usually catches on on its own and becomes the new norm. So disrupt the status quo. The future of collaboration is in your hands.
Thank you.