 I'm Becky. I'm a consultant with Pivotal, a tech products and services company that helps enterprises adopt cloud-native development and product development practices, lean product management, and user-centered design. I work with our clients to develop, ingrain, and adapt methods for leading teams of software engineers, product designers, and product managers. This is the awesome group of folks that I work with. We color-coordinated on accident, I promise. So my background is in graphic design. I'm a huge fan of all types of art and design, and I'm so lucky and proud to be part of design today because we are in a really exciting time for our field. Business is now understanding the value of design, and I'm even more excited to see how much they're investing in it. There's been a huge explosion just in the past few years of how much value people place on experience design and product design. But of course, with greater exposure comes a greater set of problems for the design community to solve. So today I'm going to talk about two problems that we face as designers or as people who work with designers. And I'll also talk about a very simple and perhaps even obvious solution. So problem number one, tech moves fast. Some of our speakers this morning talked about this. It's almost too fast for us to really comprehend all of the new technologies available to us today, all the new products and services. The world around us is changing rapidly. And as designers, we're scrambling to figure out how to design within that change so that we can build the best version of tomorrow. So when we think tech, we often think screens, but as Steven was talking about this morning, you have to broaden your thinking when you hear the word tech. We're bombarded with screens right now, but we're moving past that. That's just one corner of the vast landscape that is technology, right? It's our washers and dryers, it's trains, it's solar power, it's augmented reality, virtual reality, conversational robots. It goes on and on, right? This is all stuff that needs designing. And most of what we experience today is infused with technology. So the pace of technology is accelerating, the pace of change is accelerating, how do we keep up with it? How can we as designers effectively design around these constantly shifting modes of interaction? So the pace of change is only accelerating, tomorrow's products and services will be different from what we create today, and we have to be able to meet that challenge head on and adjust. Both for the success of the work that we do and for our careers, which brings me to problem number two, confusing job titles, roles and responsibilities. This is especially prevalent in industries that emerged in emerging tech, where job titles change as often as the products and services we create. There's a proliferation of new job titles even just in the past few years. It's also led to confusion about what people who hold different job titles are responsible for. So I hear a lot of questions lately like should designers code? Should I specialize in a specific skill or try to be a generalist? What is the relationship between visual design, content strategy, information architecture, experience design, user research, et cetera? And what should I call myself? Am I a product designer, just a designer, a UX designer, a service designer, an experienced designer, some other type of designer, right? We keep changing our titles on LinkedIn trying to make sense of what it is we do for our jobs. But perhaps even more illustrative of this problem is this list of jobs that did not exist 10 years ago, right? So for those of us who thought that our formal education was gonna prepare us for a specific career and we would do that for the rest of our careers, it may come as a shock to find that the tools we used and the things we learned are now obsolete. So I got an education in graphic design. I spent a lot of time designing posters and magazines. I can't find work doing that anymore. So I have to adapt. So if the job that you do today may not exist tomorrow and the job that you do tomorrow doesn't exist today, how do you stay relevant? And how do you work with all of these new roles that pop up? So as a protection against the rate of change and a tool for embracing it, we must work together. Seems simple, right? But consider for a moment how we treat collaboration or working together today. We often think that by handing off a deliverable to the next person in the process or by sending an email that we're working together, we're collaborating. I communicated what I needed to communicate. I'm done here. I can move on to the next thing. Designers, we hand off designs to developers with no conversation. Developers then change those designs because the delivered design wasn't implementable. Product managers deprioritize features because they don't understand what users really need. Major projects get scrapped because teams get blindsided by tech advancements and teams are constantly putting out fires. So what do we do about this? We could make things more formal. We could institute review and feedback cycles, create highly detailed project plans. All of this would delay delivery, need constant revision and ultimately still not achieve our goal of true collaboration. So what if instead we work together? Working together across disciplines enables a team to respond to change faster. Additionally, it helps a team learn and grow as professionals so that they're able to respond to the broader marketplace with a diverse and effective set of skills. So as examples of how people in different roles work together, I'm gonna share with you three stories of collaboration across disciplines from my work. And while my examples are from software development specifically, these are applicable across any team regardless of your makeup and the type of products you're working on. So there are a lot of processes and methodologies and consultants including myself that will tell you how a team should work. But what a lot of these things don't do is tell you how to work together. The Agile Manifesto, which many of you are familiar with explicitly states individuals and interactions over processes and tools. But many Agile teams still haven't figured out what to do with designers in particular and they struggle to work well with product people in general including PMs, POs or whoever's driving prioritization. So the stories I'll tell today will give you some concrete examples of how you can actually work together and be Agile to meet the changes in technology. So enter Balanced Team. BalancedTeam.org has some more detailed information. It's a methodology, it's a philosophy that explores processes and methods that allow teams to work together and be happy, which I think is very important. I encourage you to check out their website for more info. I'll just go through a quick intro to it here. Balanced Teams are comprised of a few key roles working collaboratively and transparently to deliver a solution. So no one team member on a Balanced Team is in charge of the others and each role on the team has a particular responsibility to that team. The most common way that you see this play out and the end stories I'll share today is for software teams with these three key roles. Product management, product design and software engineering. So if you take any two of these you've got a fantastic cross-functional pair. Take all three and you've got a powerhouse of discovery and delivery. There are teams with other configurations but for today let's just assume this model. So how do these three work together? I'll share one story from each cross-section and how it led to learning insights and innovations. So design and engineering. These two roles breathe life into a product concept. When they're working together well quality effective experiences are built but when they're out of sync it can be really painful to get something shipped let alone something you're actually proud of. So in a Balanced Team because design and engineering are working closely together on the product their conversations about implementation details can generate new ideas and elegant solutions. So I've experienced countless times where a software engineer knew an easy way to simplify and enhance an experience because of their deep understanding of the technology and times where designers were able to help a developer understand the intent of a design choice so that the best possible feature was delivered. Another benefit of working closely with engineering is learning more about development and how things get made. This has made me a better designer because I have a deeper understanding of my options and how my choices impact the product. So on the teams I work with software engineers practice something called paired programming so they're used to having a collaborator and they're used to talking aloud as they work through solutions. So one day one of our engineers was working solo because someone on our team was out on vacation and he asked if I'd like to pair with him on building out the interface of a new feature. So as a designer with little experience with code I was pretty nervous. I barely knew my way around HTML and CSS and this is a native iPhone app. I don't know how to build that. But the engineer is super nice and he was fun to work with. So I was like okay I'll give it a shot and I'll sit down with him at his work station and try it out. So we only worked together for a couple of hours but as he showed me the code and which parts created various aspects of the layout I started to learn more about how his work brought to life the visions that I had imagined. So by the end of our session in just a couple of hours I was manipulating some of the values in the code base to change the elements on the screen myself and honestly feeling rather proud of myself. While that specific pairing session isn't gonna teach me everything I know about development everything I need to know and it certainly doesn't make me a software engineer. Each time I sit down with an engineer and take a look at the code I deepen my understanding of how our product works. As a designer that knowledge informs my design choices so that I know what's easy versus what's difficult and what's downright impossible. So rather than having arguments about I wanted it this way and you made it this way we can work together across our disciplines to come up with a more effective, simple solution than we ever could have come up with working separately. So moving on to engineering and product management it's important to the balanced team methodology that engineers are empowered to make decisions about implementation and to make recommendations about the direction of the product. I think part of what contributes to that empowerment is that the whole team looks to engineering for their expertise on the technical aspects of product development. This helps not just on product delivery but also when it comes to helping the team understand the product as a whole and the implications of their choices. So several years ago at my previous company a lot of hype had built up around the topic of application programming interfaces or APIs. Everyone was scrambling to get funding for an API for this or an API for that and it had really become a buzzword that came up in every meeting regardless of whether anybody knew what it actually meant. At the time I was working as a product manager and I was responsible for making decisions about whether or not we should integrate with this API or that API and I was getting a lot of pressure to do so. It was like make the connection, do it for every single one. I didn't really understand what all the hype was about so I asked one of our engineers to give me and the whole product team a little API for dummy's crash course. So one of our engineers agreed to take the time for us and we went to a whiteboard and he told us what an API does. The difference between older APIs and more modern ones and what an API can't do. He included some examples of APIs in use at our company and we talked about how the new prevalence of APIs would give us more flexibility in how we built software. So in just 30 minutes we were able to sit down as a team across disciplines and get educated on a technical aspect of our work. This equipped us to speak intelligently about the importance of APIs as well as understand when that was even a relevant discussion to have about our products. It gave me the knowledge I needed to be an effective product manager and to build trust with our engineers because they knew that I knew what the value of that technology was. So by working together, engineers and product managers are able to understand how their work influences the other discipline and build a better product overall. Product managers and product designers work together to turn user needs into value realized. In other words, they're creating software solutions for problems that real people have, right? PMs and designers often collaborate on research plans, feature brainstorming, user research and usability testing and defining the minimum viable product to meet the team's current goal. So while working as a product designer at a large health insurance company, I worked very, very closely with a product manager on an Apple Watch app called Q, CUE. Q was a free to anyone wellness app that would demonstrate the company's commitment to wellbeing and helping people live healthy lives. So we had just five weeks to design and build this app and by working together to determine what features would be most useful to our users, we were able to deliver a simple and elegant product. On the day the Apple Watch was launched. So Q is a hugely successful product for our company and I attribute that success to this balanced team approach. So as a designer, I worked directly alongside the product manager on a variety of aspects. We literally sat next to one another and we did user research together, we tested paper prototypes together, we prioritized features based on the feedback from our users together. So as I iterated on design concepts with my product manager standing next to me, we fell into an easy cadence of checking in with each other informally to talk about our options. He had a background in marketing so he would come up with ideas that he thought would best market the product, he had a really good visual sense and so by working really closely together and allowing each other to be a part of the process, we were able to share ideas. By collaborating on translating feature ideas and feedback from our user research into the designs as we went, we eliminated a ton of back and forth and document creation which we simply didn't have time for. So five weeks is not the amount of time that most of us would ask for to create an app from scratch and get it built and shipped to the app store but in this instance, that's what we had. We didn't know until two months before the app, before the watch actually showed up in stores when it was gonna launch so it was really difficult to plan six months in advance. So in this instance, to meet our goal, we had to work within five weeks and so by collaborating fluidly across our disciplines, that was really key to making that tight timeline work. So these are just a few examples of how no matter your background or the particular role that you occupy on a team, people can work together to make something greater than the sum of our parts. I credit the balanced team approach and the collaboration it encourages with my career growth and my ability to remain relevant in a rapidly changing industry. Each of these stories I've shared with you today was a point in my career where I felt I leveled up. I was gaining experience that helped me be a more valuable contributor on my team, not just as a designer but as a well-rounded contributor in a variety of situations. So rather than arguing about which tasks belong to which person or what the bounds of a specific job are, we are better served and we serve better by setting those concerns aside and working together at the intersection of our disciplines. So your role on a team is about the position you take in a discussion and the responsibility that you have, not about what tools you use or what deliverables you create. So if we want to stay relevant and grow as practitioners and innovate in a world of rapidly changing technology, we have to work together and we have to learn from each other. So go forth, collaborate and make magic. Thank you.