Building an Organization Structure that works for you
Checking session availability…
Hang tight while we load the latest updates.
Conways law states that organizations produce software that matches the organizational structure. Therefore the structure chosen affects an organization's success in carrying out its strategy and objectives to achieve maximum performance. In this session, Pamela will discuss what the leadership at SumUp looks for when planning around the organizational structure, and how the thinking and approach have evolved in the last 3 years:
- The impact of an organizations stage of development and organizational philosophy
- Moving from product-centric to customer-centric: the Evolution of SumUp from when I joined to what it is becoming today
- Org details that can make a difference in creating cohesive impact: Brand at SumUp
Building an Organization Structure that works for you
Pamela Mead at UXDX USA. Video: https://www.youtube.com/watch?v=ECwRhlopN0I
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.
SumUp and the mission to tribalize design
[00:00:01] I'm glad the lights are a little bit brighter, but it is quite bright. It's super exciting to be here and talk in person. First time in three years for me, so always a little bit nervous. But I'm really looking forward to talking to you about building an organizational structure that works for you, that delivers great experiences to your customers, and also builds value for the company.
[00:00:23] I joined SumUp in late 2019. Like Catherine said, we are a payments provider. We sell card readers, two million of them so far. We are global, in that we are in 36 countries. We have our main offices in Berlin, in Sofia, in São Paulo and also in Denver. We have grown to 3,000 employees in the last couple of years, including 100 designers. So a very, very big footprint, a very big mission.
[00:00:54] A little bit more background, so you can understand the story of what I've been able to do at SumUp. SumUp started as a company in 2012. It grew quite quickly, but also had some setbacks at different economic times that had the company downsize and then come back up. It made an acquisition of P1 [?], which gave us a pretty significant footprint in São Paulo in Brazil. It continued to grow to about a thousand employees in 2018, and by the time I joined, at the end of the year, it had started the journey of tribalization. Roughly when it hit about 500, 600 people, it realized that this semi-chaotic [?] delightful startup mindset doesn't really scale. Not only did it focus on tribalization, but also on agile transformation, not only in engineering but in terms of how it looks at product development and corporate strategy. Just before I joined, it had started focusing on markets, taking the same tribalization philosophy and creating market-centric teams for Europe, and then we had of course our big marketing organization in Brazil.
[00:02:15] When I joined, I was given the mission to tribalize design, even though I had quite a few reservations about it. I was pretty much told at the beginning of my interviews that any ideas I might have to not do that were not going to fly. So really the story I'm going to tell you is what I actually did to make this happen in a way that worked. We are going through another transformation as we speak, and I will talk a little bit about what that's beginning to look like.
[00:02:42] I want to keep coming back to: what is our role as design leaders in organizations that are really quite dynamic and adjusting? How do we embrace the forces that drive organizational decisions, with the goal, at the end of the day, of delivering experiences that are cohesive and that really work for our merchants?
Drivers of organizational decisions and Conway's law
[00:03:03] A couple of the drivers that I will talk to you about that were important in the transition at SumUp were, of course, the company culture, and John talked at length about it this morning, but also the product, tech and design maturity, and product development maturity, which was covered in some of the conversations yesterday. There is always a transformation when you go from startup to growth. Some of the learnings that I had might look very different if you're in a very mature organization, a big SaaS company, or a company that has a lot of different products, but hopefully with some of the learnings that I can share with you, you can figure out how to translate them to that setting. And of course the business climate that's changing is forcing us to make quite a few decisions today that are different from what we were thinking about even at the beginning of the year.
[00:03:48] Why do I talk about cohesive experiences? We have Conway's law, which says that organizations produce experiences, or designs if you will, that reflect the organization. While this example is quite old school and referenced SaaS companies, I would actually say that today, with tribalization, with this segmentation into autonomous teams that are focused on very specific parts of the journey, we're replicating the same problem, only we use different language today.
[00:04:20] I have three sections. I'll talk about the first two points, around organizational maturity and philosophy. Then how, as we grew, we were able to move from being a product-focused company to being much more customer-centric. And then I have what I call the cherry in the story: a particular way in which we think about brand at SumUp that became quite an important driver of tying this narrative together and giving us a foundation that can really scale for us.
Culture: autonomy, anarchy and roundabouts
[00:04:53] Culture. Again, John talked at length, with lots of really valuable information. It is really important for how you understand what can be done in an organization. One of the books I read quite early on joining SumUp, and it turned out it's one of our CEO's favorite books, is Brave New Work. Just out of curiosity, how many people have heard about it or read it? Cool, a couple of people. I highly recommend it. It really talks about the future of organizations, very much away from classic hierarchical structures, with command and control situations, to much more flat organizations that embrace and empower autonomous teams.
[00:05:41] What's interesting about it is a little bit the how you do it. When I joined SumUp, we were always talking about autonomy above all else. There were quite a few of us who were also standing up and saying, "Wait a minute, wait a minute. This is not autonomy, this is anarchy." My conversation with the CEO was very much around a metaphor that's in this book, that we didn't really have. The story in the book talks about the greater efficiency of roundabouts over stop signs. Stop signs are really good because the rules are really straightforward. I don't know how many of you have tried to get into a roundabout in Europe; that can seem like the most chaotic, frightening moment in time.
[00:06:28] It turns out there are some really wonderful rules that govern driving in roundabouts, if you know what they are, that allow roundabouts to work way more efficiently, because it adapts to the traffic flow. It adapts to how many cars are in the system, whereas stop signs don't adapt at all; they're just really quite rigid. Now, with IoT, that might change over time, but the fundamental is that one gives you really clear rules that are really easy to execute, but it doesn't give you the flexibility to scale to the changing situation.
[00:06:57] So I would say to Daniel, okay, look, we need these rules. We need these guardrails, so that teams that we really want to encourage to be autonomous have some level of framing that gives them parameters in which to make decisions. One of my missions was really to figure out how we articulate those guardrails, certainly from an experience perspective and from a technology perspective, so we would not be in a sense of anarchy, where teams would go off and pick any technology they want that we then, years later, would have to figure out how to reintegrate or rebuild, but they would have the right boundaries to make their independent decisions in.
Tribes, too few designers and design maturity
[00:07:38] This was roughly what the organization looked like. We had tribalization, which again meant that we had teams really focused on some of our domains, some of our products, some parts of the journey. We had our market-focused marketing organizations. And then we had a global design team that was about 35 people. We were roughly 1,700 people total in the organization. If you look at the number of tribes, and there were a couple more than this, it was really clear to me that we didn't even have enough designers to handle the work that was required. What had been happening up to this point is that the designers were working much more on a project basis as opposed to product, and I think we talked about that a little bit yesterday, in terms of the drawbacks of that. So I embraced the fact that I had to tribalize the organization despite my reservations, but I was going to do it my way.
[00:08:42] Then we talk about maturity: design maturity. This is a model from the Design Management Institute, but there's a much more elaborate one from the McKinsey report that was published a couple of years ago. I find this useful because it's quite simple, but it's always taking a look at where the understanding of the organization is around design. Most of the companies that I've joined in the last 10, 12 years are almost always roughly between two and three, at least by the time they decide to bring me in to help them grow the organization. I would say we are now between three and four, and in some parts of the organization even four. I attribute that a bit to the philosophy that I established quite early, in looking at how to do this tribalization in a way that addresses some of the issues that I saw.
Design as a peer to product and engineering
[00:09:35] I really focused on setting up design as a peer to product and engineering. Again, some of the conversations yesterday were already covering this a little bit. I really see challenges whenever design reports into either product or tech. That tends to be the relationship that's a bit stronger, and then the other relationship tends to be a bit more neglected. So I really wanted to establish this triad that I firmly believe in, where magic can happen and real innovation can happen, which is when you have product, design and engineering as peers, collaborating, working together, trusting each other and really making amazing decisions.
[00:10:16] Part of my journey, as we were looking to hire more designers, was to work with all the different tribe leaders around this fundamental framing of how I wanted to set up design in their unique organizations, and really set it up almost like a mini organization inside the tribes, where there was strong design leadership and also strong design mentorship and coaching, and many cultures and communities could be built around the product development cycles that the particular tribes were using.
[00:10:50] We proceeded, and it took about two years. We grew quite a bit. I would say we probably hired about 35, 40 more people in that time frame. I was deeply involved in most of those hires, especially for the design leaders, and I'll talk about that in a minute, because to me it was really important to set slightly different criteria for the kinds of designers that were able to grow and scale with us going forward. As I hired a design leader, I would put them in the tribe, and I'd move the designers that were working on the different products into the tribe, and very slowly tribalize the design organization.
[00:11:37] The final push was when a new tribe came into existence called the platform tribe, whose mission was to look horizontally across the organization and address issues, projects, teams and topics that weren't addressed by the individual tribes. I became a co-lead of that tribe, along with a partner of mine who was focusing more on product but also has a technical background, and a head of technology that came in. The three of us modeled the leadership of a very diverse tribe, because not only did we have design ops, but we had data strategy, we had CRM infrastructure and we had DevOps. It was a bit of a challenging journey for two years, but the three of us felt that all of us in this tribe had a similar mission: how do we work with all the different tribes that wanted to go do their own thing, when we really wanted to build these parameters, these guardrails, these rules for the roundabout, together, so it would allow the organization to scale.
Strengthening the weakest link: a cohesive design community
[00:12:42] I'm pretty much a firm believer that any organizational structure can work. I've worked in every kind of matrix. What I've learned and what I've observed is that the success of any organization is the strength of the people, and the culture that supports collaboration and encourages it. What I always try to bring to a conversation is: in whatever the organization is, where's the weakest link? Where do we need to really put our emphasis? At SumUp, with the tribalization into these different journey moments, very different parts of the product offering, the cohesiveness of the experience was really the weakest point.
[00:13:34] So I really focused design on addressing that collaboration and driving it through building a very cohesive design community, where in some ways I was asking people to make a commitment to that single journey. Like I mentioned, I was involved in most of the hiring of the next 30 people when I joined, and I would always be the final interview. It didn't matter if it was a really senior leader or a more mid-level designer; I always shared with them the story of what we're here to do, which is to build this cohesiveness across the organization. I always said they had to commit to the design system. They had to leave their ego and their freestyle at the door. And also really contribute to the community, to really engage and partake in it, so we could be forming a structure and organization that can rely on each other, where we share, so we could actually build that efficiency and build that cohesiveness across the journey.
[00:14:32] We wrote the focus on our commitment to community action into our career ladder, again to reinforce how important it was that it wasn't only about your own project or your own product. It was really about what contribution you are making to the community.
Blending: moving with the energy
[00:14:51] The way I like to think about my approach, because there were many times where I said I really didn't want to do it this way, is always as blending. I took a business course for several years, and we always talked about tai chi and learned some tai chi moves. This idea of not resisting but moving with it, moving with the flow, moving with the energy, and then turning it into something else, is something that I think about often, and I try to use it really consciously, especially when I feel like I would really like to resist the move, like I felt about tribalization. So it's something I encourage you all to think about as you try to work inside parts of organizations that you may or may not agree with: where is the opening to turn it into something that actually makes sense?
[00:15:40] We did tribalize when we were ready. We are now over 100 designers, and I think by far in the company we're one of the strongest communities. We have also set up some key practices, like design operations and building a design system, to help facilitate this kind of shared cross-organizational collaboration.
[00:16:03] As a small anecdote: I never resisted. I never said no to tribalization in all the meetings. I had a colleague who was a bit more resistant and managed a lot more issues. Last August, at an offsite of the extended core [?], Daniel surprised me by acknowledging that he'd been watching me. He said that he noticed that I was doing tribalization not the way he actually wanted me to do it, which was immediately and in the moment. He was very observant and very aware that I was doing it my way. As a tribute to him, he thanked me for showing that transformations could be done in different ways, and gave me quite a bit of credit for it. I was pleasantly surprised, because I didn't know that he was observing what I was doing; he never commented on it.
Agile teams and the limits of domain thinking
[00:17:01] That was organizational maturity and philosophy. Now I want to move on to what the drivers were for moving from being product-centric to being customer-centric. I know there were already some conversations yesterday about agile. Agile is super fascinating for me. I think it's a pretty useful set of tools and practices, but I've seen it really go sideways in a lot of companies. I think it was Rory who was talking about it yesterday, almost like agile wrapped in a waterfall process. That's something I've observed quite a bit.
[00:17:48] But there are some great things about it. The notion of agile and agile teams fundamentally speaks to the core values of SumUp. This notion of self-organizing interdisciplinary teams is a great concept, and it speaks to engineers, designers and product being peers together, when it actually works. I could talk at length about product designers, whom I consider the new unicorns, but then we'd be talking for another 30 minutes, so I'm leaving that for a side conversation if you're interested.
[00:18:23] What I want to focus on here is what I've observed in teams, not only at SumUp but also at a couple of the companies I worked in before: teams solve problems within the space or the domain that they're responsible for, and they don't have the practice to step back and say, okay, fixing a problem around registration, or drop-off in our onboarding, may not be a problem where they detect it, where they see the numbers. It might actually be on the marketing side, where we don't tell our people enough about what is going to happen. This is not something that makes agile bad. It's just something where you need to know what the problem is and how it manifests in your organization.
[00:19:11] Coming to the second part: how do we build a structure, or a narrative, that allows teams to come together, despite autonomy, to create these cohesive experiences?
From card readers to a multi-product company
[00:19:31] Going back to SumUp, tribalization actually worked quite well. We were a really quite straightforward company when I joined. We sold card readers. We had about three or four different models. Only for one model did you really need to use the app, because you had to input the amount that you wanted to charge, and then with the card reader you could take the payment. However, we had acquired a few companies, and we were on this mission to become a multi-product company. So we wanted to start to add a lot more services into this one app that was completely built and focused around just taking a payment, entering a credit card value.
[00:20:19] On top of that, we were also building our own hardware for the first time, because we knew we had reached some limitations with third-party hardware, and so we really wanted to invest in building our own hardware so we could start to create a much better experience.
[00:20:35] When I joined, I looked at this, and I looked at all the products we wanted to incorporate, and I was looking at the app and at our web dashboard, and I said, okay, our architecture has reached what I call end of life. It's not going to scale to creating a cohesive, meaningful experience. But it wasn't clear to me either exactly how one re-architects something when we are really focused on velocity and growth and getting things out to the market quickly, and, as a matter of fact, with a little bit more emphasis on breaking things than necessarily making things cohesive. So I was a little bit philosophically at odds with how we were talking about it.
Provoking the organization with a vision
[00:21:15] I think this was even within the first six weeks of joining: I had an opportunity to speak to one of the tribes and introduce myself, the tribe that had a lot of the acquisitions and was really going to be part of the core of our multi-product offering. I had two designers work with me for literally two days, and we said, okay, let's provoke the organization a little bit. What if we could really visualize money? Because money is becoming so ephemeral for some of the merchants in our region, and we know that that ephemeral quality is actually hard for them to grasp and understand. So how could we make money, or the value of what they possess, a little bit more tangible? How would we create business insights for them that would allow them to scale and grow? Because ultimately that was our mission, our purpose.
[00:22:05] And how can we really start to think about a much more integrated experience, where these products that didn't share any back ends, didn't really share any databases, barely even shared the same customer base, would start to come together, and really start to think differently about the product? I would say the success of this presentation was that the team really started to come together and plan for 2020 how to start to connect some of the back end, so we could at some point get to this kind of cohesive front end.
[00:22:39] Part of my story, which I still use and tell today: the invoicing team was talking about the merchants they wanted to target with their invoicing-first product, and the online shop people wanted to target different merchants with their online shop product, and of course the card reader business knew who they were targeting. I really wanted to emphasize continuously that at the end of the day we're talking about the same merchant, and we can't keep treating the merchant as if they don't have one experience with us. So from that moment on I always reinforced that we have to think about one merchant, one experience. That is not only how we market our products, but then how we deliver them and how we service them through customer care.
COVID and the super app
[00:23:26] In 2022 [?], when COVID hit and affected us like a lot of companies, our business really suffered quite a bit, and we scrambled on two fronts. One was to say, we have all these products, we just haven't really published them and integrated them. How do we get them on the marketing pages? I ended up driving a marketing page evolution, where I looked at my marketing colleague at one point and said, "Why am I doing this? Isn't this your job?" She said, "Great job, just keep on going." At the same time we also really started to look at how we make these products available, because now they were going live. We were actually launching them.
[00:24:08] In 2020 we focused on marketing and getting some of these out, and actually developing some products in three months and pushing them live, again to support merchants in their ability to do business online. But we also said, okay, we are now as a company really committing to the story that I was telling even a year earlier, about this really integrated experience, and we called it a super app. In 2020 we had a lot of discussions: is it all one app, is it separate apps? And we made the decision that no, it's going to be one integrated experience, and we called it the super app.
[00:24:40] Last year was our year of launching the super app. Now, that's a little bit of a misnomer, because quite frankly, all of our products were hidden under this "more" button, which of course nobody could find. There was this magical green dot that showed up when there was supposedly something new. And voilà, now it's on something called a home screen. There's a lot more vision in what we want this to become in order to be really meaningful and valuable, but this is what we actually ended up getting out the door.
[00:25:15] What I said to my design organization was: you can't hide anymore. All the things that don't work, that don't look the same, that behave differently, now that you're on one screen and you start clicking around all the different products, it's so apparent and so obvious. So we've been working on unifying a lot of the different bits and pieces in the organization to try to get a little bit more similarity and a little bit more cohesiveness. We're on the journey. We're not where I want us to be; I hope to be by the end of this year. But it is by far better than where it was when I first joined.
The design system and accessibility
[00:25:50] One of the key drivers for us, of course, was the underlying design system, which we started building at the beginning of 2020, because there wasn't even a mobile design Figma file. Yet we had mobile. We had people developing with bits and components that had been developed over the previous four years, probably by five different designers, and as my colleague Lucas always used to say, you can tell which designer was working on it by which version of blue they were using. So we really focused on unifying it.
[00:26:20] I'll talk about it in a minute as well, but for us one of the really important pieces was accessibility, because our merchants are out. They're not always in stores. They're not always in nice environments with perfect lighting. In Brazil they're frequently very small merchants out in the open. Some of them can read, some of them can't. Some of them have bad phones, really simple devices. So accessibility has been a core driver of all the adjustments we made to the color palette and the simplification of the elements.
A new transformation: journeys and business impact
[00:26:52] Now we are in another transformation, and this is the business climate part. We're in more of a market downturn. One of the things that started to happen in the last year, including with a couple of colleagues joining, is that people really wanted to start to look at: wait a minute, what are we really doing with our customer care? Is this costing us a lot of money? What's happening in the products? Let's fix the products before we get to customer care. And in the marketing organization, we're starting to really talk about customer journeys.
[00:27:29] Where a year ago I would have said journey mapping, we were starting very slowly. Every time we tried to do journey mapping, the company was so complex we just didn't get very far. Now is the time where we really want to start to look at journeys. We're starting to map them and look at what the pain points are, on one hand actually driving product improvements, and on the other hand also starting to say, how do we bring a journey narrative into how we think about our product development and even our design practices? The goal is also a business goal. At the end, we really want to know where we're investing our marketing spend and what business value we're driving, so we also get a lot more strategic about how we're growing as a company. We're moving away from pure growth at all costs to a much more thoughtful, efficient organization, as well as looking at what investment we need to be making strategically so we can grow.
Research that drives impact
[00:28:25] I have an anecdote I would love to share in more depth, but let me just say that when I joined, there was a bit of a misconception that research was not supported in the company, even though we have a really strong mission around being customer- and merchant-focused. After multiple conversations, specifically also with Daniel, our CEO, we came to realize that he actually is a really big believer in research, but what he doesn't like is academic research. His biggest fear was that people would do a lot of this work and then it would sit somewhere and collect dust and wouldn't really drive impact.
[00:28:58] So we have actually built a nice-sized research organization, but we've kept it at one size now for about a year. It's distributed. We also have a research operations team. But we're really, really focusing on this connection between what we are learning and how we actually drive impact, and how we show that. So we don't do research just for research's sake. Nor do we confuse research practices and interviews with what I call empathy building, which everybody should be doing. The session just now beforehand was really valuable in talking about that.
[00:29:35] We've started to look a lot more at customer-focused storytelling. This is not only coming into our product; it's also driving our marketing narrative. And, to be expected, we are starting to say, okay, maybe we need to be organized a little bit differently. We're starting to look at where we need to come together to build these efficiencies, where we need to focus on growth, and to work much more closely across tribes. So the emphasis on autonomy has really shifted towards how we build a little bit more cohesiveness. Our focus is a lot more about knowledge building, journey mapping and business impact.
Brand as the thread: true, pioneering, inclusive
[00:30:16] I'm almost out of time, and I want to leave some time for questions, so I'm going to speed up a little bit in this last section, which is what I call the cherry. Brand is usually associated with marketing. It's usually associated with logos. That's been bothering me for a long time, because I see brand as being much more holistic. The other thing that's interesting is design. I really tried to re-own the word design at SumUp. Design isn't just one practice. It's brand design, marketing design, UX, UI, experience design, also user research. In that context, when I came to SumUp, we discovered that brand was actually not part of marketing. Brand design was part of my organization.
[00:30:57] So I used that opportunity to reframe branding into something that, when you step back, really gives us this Leitfaden, and I had to use this German term because it's perfect: this guide that threads all these experiences together. Looking at this diagram, you see the brand characteristics. Those are the classic ones, and in a lot of organizations brand characteristics are used for marketing and then the rest of the organization ignores them. We really wanted to use the same characteristics to derive experience principles that could be used by the product organization, and service principles that could be used by the service organization.
[00:31:38] These are the new ones that we are working with: true, pioneering and inclusive, and there's my cheat sheet. With true, we want to evoke this sense of "I know what is happening" for our merchants. We really want to be reliable, which is something we have had problems with. We want to be supportive. We want to be really clear. We don't want to have any asterisks or anything like that. And how do we, in that context, help our merchants solve problems? How can we be true and honest with them?
[00:32:10] Pioneering: how can we be smart? How can we be forward-looking, make people feel like this is really easy, and also solve problems for them with that same mindset? What can we do that's extra, different, that allows us to solve our merchants' problems and go that extra mile? And then inclusive, which I mentioned already earlier, is super important to us because of the diversity of our merchants. How can we really be everything to everybody and make it accessible in that regard? Accessibility is really core to who we want to be, to our organization and to our merchants.
[00:32:40] So: simplification of the color palette, using semantic colors that are actually semantic colors, not brand colors; staying with the typeface as we had it, but creating a bit more typographic richness; and then redesigning the iconography so it's a lot bolder, a lot more understandable, and doesn't have any extra frills on it.
[00:33:02] And then, coming back to storytelling from the previous slide, we took this further. We said, okay, if this is who we want to be, how do we start to realize that in what we call the lighthouse, a storyline of what it could actually mean on our marketing side? We made a commitment, because of our Solo [?] devices being black and white, to black and white, which is still a little bit challenging for our designers, but I think it's something that can really work and be distinguishing. Of course, on the marketing side and in some of our comms, you might want to use some other colors, because it's appropriate for the form of communication. But how do we start to tie this together into an experience? I want to share with you this story.
[00:36:18] We have a ways to go, but people are really excited about starting to make it happen, and this year is really about building on the marketing side, building out our CRM campaigns and really starting to make it happen. Brand has been, for us, an unusual theme, because brand was in design, to really start to tie it together into something that creates a cohesive experience, really end to end. It is by now the definition that's framing, from an experience level, what the rules of the roundabout are. It's something that has helped us bring the designers together, and also helped the product organization around decision-making, and we're really coming together to make it real.
Summary
[00:37:01] To summarize: on organizational maturity and philosophy, blending has been my DNA, and how I work with the organization to accomplish what I see as important. Storytelling as a foundation for moving from being product-focused to being customer-centric. And then brand as an opportunity to create something unifying that I have not seen in other organizations that I've worked in. But maybe the last message is super important. Building an organization structure that works for you: it can't just work for you and your team. It really has to work for the organization, the company, coming back to John's point this morning about culture. I think that's really quite important. I want to thank you. I know I ran a bit over, but I hope this was valuable to you. Thank you.
Q&A
[00:37:55] Host: I think the intent was to have questions, but there's only probably time for one or two. Who has a question in the audience? I have one, if that's all right. My biggest thought, with all the experiences you have, is: there are a lot of challenges that you might encounter when building organizational structures. What are the most surprising things that you thought would be difficult but were actually easy?
[00:38:34] Pamela: In general, or at SumUp?
[00:38:37] Host: In general. Let's not put names.
[00:38:42] Pamela: In general, I think what is harder is figuring out what can work in an organization. I've worked in a big telco, which is completely the opposite of SumUp, and figuring out how you actually build something that can scale in the organization, and then distribute it and have impact in the larger organization: those are some of the things that I think can be harder. What I really learned at Telefónica, and I've seen now at SumUp, is there's a real difference between when you inherit a team that might have, like John was talking about, some behaviors and cultural challenges that are, even in design itself, negative and self-defeating, versus when you're in an organization where you can bring people in with a really clear mission.
[00:39:33] If you bring in just enough of the right people, there is such an incredible empowerment in teams that trust each other, that believe in each other, that support each other. This is now my second time where I can really say I can see how, when you have an organization that has all these characteristics, you can move mountains. That's pretty amazing and incredible when it works. But you have to know the organization, whether it allows you to actually build that kind of structure, because not every organization is ready for it. So I think John's talk this morning was really quite powerful, because it really talked about this. You have to know your company. You have to know what's possible within it.
[00:40:11] Host: I think you and John have a lot in common, with regard to your careers, but also in giving your feedback and your perspectives on everything. That's fantastic. Thank you very much, Pamela. That was fantastic. Well done.
More like this?
Mon, May 23, 1:00 PM UTC
Building A Unified Product Team In The Midst Of Accelerated GrowthWed, May 25, 5:10 PM UTC
Culture and Process: Making Change Happen