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

Andrew Birgiolas at UXDX EMEA. Video: https://youtu.be/lWhx6Xbmzd0

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Treat collaboration as a product

[00:00:07] And can't wait to see what's in store for tomorrow. 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.

[00:00:50] It's like the ground is tilted. If we're passive, we're 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 towards 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.

[00:01:33] My name is Andrew Birgiolas, 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 and 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 broadened from designing screens to teams, and now to how entire organizations function and collaborate.

[00:02:15] If I could give myself a piece of advice, or 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 for you and you have an inner flame and a vision for how life could be better, you can and should disrupt the status quo.

Twelve practical ideas, starting with hiring

[00:02:46] 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. And 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 convos I've had with other design leaders and peers in the industry, it's surprising how often these things are overlooked. So whether these feel obvious to you or new, I'll share again what worked for me and some practical steps so you can do the same.

[00:03:40] Whether you call it design operations, anything from design operations all the way to operating system management, as I said, call it whatever you want. My point is that this needs to be treated as its own distinct thing, and that 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.

[00:04:13] 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.

[00:04:39] 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 function's hiring decisions. If people are just appearing out of thin air, speak up. That's not okay.

[00:05:07] 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, and that signals mutual respect and empowers your teams for downstream success. Okay, now we can talk about projects.

Map and unify your processes

[00:05:30] 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. 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, the architects, are doing solutions designs. Stop the madness.

[00:06:14] Map and unify your processes across teams. Call it a service blueprint if you will. It's natural that over time, disparate bottoms-up processes, where everyone's 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 life cycle is stressful and frustrating AF. If your processes across functions feel like a bowl of messy spaghetti, some housekeeping is in order.

[00:06:50] 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 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.

[00:07:26] 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. And if you need a starting point for a framework, I've seen them all, I know there's 100 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.

Automate with recurring ceremonies

[00:08:08] 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.

[00:08:36] 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, 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.

[00:09:03] 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 retros. 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.

[00:09:26] So 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, again, 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 you're off to the races. The consistency, predictability and structure does wonders for productivity, and sharing progress weekly, rain or shine, becomes the culture. It also creates a culture of openness and 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. So set the system up and let it work for you.

Cross-functional kickoffs and direct communication

[00:10:18] 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. And then design meets with engineering to share more details about the designs. It's a heartbreaking game of broken telephone.

[00:10:49] 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, 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.

[00:11:14] 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 every single week. Why not just ask her directly and CC John? Yeah, you're totally allowed to do that. Okay, bye.

[00:11:40] One of the worst habits I see and I hear about are relying on product managers and project managers to be these middlemen or go-betweens between 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 the job. Instead, talk directly to each other. Number five. It establishes direct lines of communication, makes things faster, builds rapport and trust and influence within the cross-functional team.

[00:12:20] 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, CCs 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. And here's that colorful diagram with the bottleneck removed.

[00:13:06] Becoming a middleman, if you're feeling that happening, 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?"

Project channels and iterative refinement

[00:13:21] Uh oh, one second. Oh, this time it's a message. 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. Let me just zoom in here. Okay, and I can tell immediately that this is going to be not feasible. Okay. Esteemed colleagues, I hate to be the... actually, I'll finish that later. Is that relatable or what?

[00:14:08] 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. Everyone 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. And sometimes we don't even realize all the people who may be impacted.

[00:14:44] So 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, questions that affect everyone. And then 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.

[00:15:17] So make this part of your new project check-off or new project checklist so it happens with every new project, and 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's 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.

[00:15:42] And 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. I want you to focus on the words iterative and inclusive. Sharing work in progress can be very vulnerable, and human nature again, we tend to retreat into our silos, letting our perfectionism get in the way of progress. But product building is a team sport, and working out in the open is non-negotiable.

[00:16:21] We often think iterative is just for design, but I've seen that embracing an iterative mindset is actually transformative in all types of areas. You can use it for PRDs, for scoping documents, for strategy decks, and even timelines, because all of these things start off loose and as you work through get tighter and more concrete. Taking this more iterative approach on things opens the door for collaboration, buy-in and synergy a lot sooner, which ultimately leads to increased effectiveness and quality. And stakeholders and partners adapt to this type of 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 something important to keep in mind as well. People generally love to be involved and come along for the journey.

[00:17:18] So this is how it looks. Each week we come together at review ceremonies to discuss the latest work in progress, and the best results, again, are when everyone comes along early. Then the individual teams go back and refine and come back the next week to review. We often invite guest stars like merch, legal, marketing, people who aren't in the product triad, as needed depending on project. This again repeats weekly, and as we go, the fidelity, the confidence, the accuracy of whatever we're working on crystallizes. So if you don't have this type of system, I highly encourage it for all functions.

Templates and one source of truth

[00:17:59] Number eight: templatize your PRDs, research plans, Figma files, release announcements, everything. We're working on 20-plus 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. So 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 this one that was done in partnership between Atlassian and Lenny Rachitsky.

[00:18:32] The challenge is to make your template general enough that it'll apply for most projects, but specific enough that it'll take the guesswork out of what does a good PRD mean at my company. Templatized structure and starting point frees up product to focus on more high-value activities than figuring out how to format their document. And your partner teams, who are traversing tons of these PRDs day to day, are really going to appreciate always knowing exactly where to find the information they need in a format that's consistent.

[00:19:02] 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, Mo. Okay, you want us to email the decks 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. Okay, 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. Oh, and the Excel roadmap doesn't match the Jira roadmap. Okay. 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.

[00:20:04] 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.

[00:20:32] 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. And 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.

Outlaw intake forms and present your own work

[00:21:10] 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.

[00:21:46] Number 10: outlaw intake forms. It turns out that 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, who's one of my most influential design leadership gurus, and it blew my mind when I first heard it. It means that 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.

[00:22:23] 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 there's times where it's permissible, but this should be the exception and not the rule.

[00:22:58] 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.

Nothing is ever final

[00:23:26] 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.

[00:23:56] As you go through discovery and build, you're continuously adapting and updating your design and requirements based on feasibility and effort and 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. And that's why we should all stop waiting for final requirements and final designs.

[00:24:24] 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 a product manager came on board and helped us get organized.

[00:24:55] So banish the final from your culture and rebrand with more accurate names that describe the level of fidelity you've reached. So 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 is outputting something with just enough fidelity for the next phase to pick up and continue working on.

[00:25:25] 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 is that 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.

[00:26:08] 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 that 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.