ºÚÁÏÃÅ

Episode transcript

Ìý

[Music]

Ìý

Rebecca Parsons: Hello, everyone. My name is Rebecca Parsons, and I'm one of your recurring co-hosts on the ºÚÁÏÃÅ Technology Podcast. We're here today to talk about product organization and engineering organizations. We have three individuals with us. Rick, would you like to introduce yourself?

Ìý

Rick Kick: Sure. Thanks. I'm Rick Kick, I am the North American Head of Enterprise Modernization, Platforms and Cloud for ºÚÁÏÃÅ. Kennedy?

Ìý

Kennedy Collins: I'm Kennedy Collins. I'm the Head of Product and Design for the North America Central Market. Tony?

Ìý

Anthony Maitz: Hi, I'm Anthony Maitz. I am a Product Consultant at Pariveda. I have been doing product management for a good long while.

Ìý

Rebecca: Excellent. Let's start with an introduction to the problem. This podcast is part of a series that are based on some articles that are being written about the challenges that scale-ups face. This product and engineering tension is one of those scale-ups. What exactly is the problem? How do we see it manifest? What are some of the characteristics of this problem?

Ìý

Rick: I'll take a first crack. One of the things that Anthony was just talking about is, this article had gotten picked up on some other websites. One of the pieces of feedback that came in was, we don't see friction between product and engineering in startups. That's a really important thing to start to focus on because we're not talking about startups, we're talking about scale-ups, and scale-ups, then they grow into larger organizations.

Ìý

When you think about a startup, there's some regular level of organized chaos, but as that organization starts to grow, and scale, you need to switch from organized chaos into more chaotic organization. Then you start to put product managers together with other product managers and engineers with other engineers in these structural organizational pods.

Ìý

What happens then, is that the organization generally starts to have some top-down goals, those goals get translated into localized OKRs, and now that management layer is actually focused on how do we make my product managers better product managers, and how do I make the engineers better engineers? That's where those silos start to evolve.

Ìý

What we're talking about here is, how do we start to break through those silos and build tunnels between those organizations around creating better value? The problem is normal for companies to experience, but it's also a problem that we have to solve for.

Ìý

Kennedy: I'll add a couple of things to explain one of the reasons we're talking about this in the context of scale-ups is an ounce of prevention is worth a pound of cure, but also because scaling this way, and choosing to organize, at least to some extent around functional organizations, and having a CTO or a VP of product and that kind of thing, it makes sense. It's efficient in a way that we found in organizational theories found is really efficient.

Ìý

It's often really hard to have folks who are not, at least to some extent, experts in the work that they're doing leading folks who are doing that kind of work. People trust and need that kind of expertise, but that organizational structure has a lot of downsides. It is really efficient, but we need to be careful and understand, where is it good, where is it bad, and how can we mitigate the bad parts while getting all of the good parts.

Ìý

Rebecca: Yes, it sounds reminiscent, actually, of some of the discussions that we often have about how you can either optimize for efficiency. You have pools of resources, here are my DBAs, here are my developers, et cetera. Or you can optimize for speed where, "Okay, I'm going to form a product team that has designers and DBAs and developers, and that you build it, you run it."

Ìý

If you need three-quarters of a DBA for one team, and three-quarters of a DBA for another and a half for a third, well, if you had a pooled resource, you could do that with two DBAs, but if you've got three teams, you're going to have three DBAs. You give up efficiency for speed to market or other kinds of more market facing goals.

Ìý

It sounds like this is just another instance of that, where we're looking to gain that level of organizational efficiency, as well as career development. I actually just got off a conversation with somebody that says, "A project manager can evaluate a developer on whether they met their deadlines on time, but they can't necessarily evaluate the strength of that developer, the cleanliness of their code, et cetera, and they can't really give that developer a vision of a career path either, because they're not a more senior technologist." I see some strong parallels there.

Ìý

Kennedy: Absolutely.

Ìý

Anthony: Yes, I think it's important to remember that the organizational changes that come along with this are required in some way. It's very different to run a team of 400 people than it is 40. I think a lot of the definitions that we use interchangeably for these development teams between these two realities, can get us into trouble too.

Ìý

Speed, when you're 40 people or less, when you're a new startup, speed often does mean time to getting feedback from users. When we talk about speed, we're talking about learning speed. Speed, when we talk about an engineering group of 400-plus or an organization and upper hundreds, we're really talking about velocity. It's actually a lot slower and harder to measure individual impact of changes because so many changes are happening, and so many people are involved, but also the number of users tends to be a lot higher.

Ìý

There's a lot more stakeholder input and input from direct users as opposed to competitive input and market research. You're dealing with your own inertia and mass, and that mass gives you power in certain situations, but it does come with other considerations. You're never going to move as fast regardless, as a 400-person org, as you did as a 14-person org, for any number of reasons.

Ìý

I think we continue to use those same terms from earlier in the organization and it belies the reality on the ground. It ruins the ability to communicate about some of the nuance here.

Ìý

Kennedy: Yes. One of the things I spent a lot of time working in startups before I joined ThoughtWorks, and one of the things that I found, and I've heard over and over again, it's like when a company doubles in size, that's not a difference in degree anymore, that's a difference in kind. It's a different kind of beast, and the way you have to manage it is different.

Ìý

Anthony: The reality of a lot of these companies hitting startup or hitting their Series C, or D, is that the expectation, the requirement for accepting that funding is to double in size, and sometimes repeatedly. One year to the next, you'll need to double, and then the next year again, and the reality there is, it's not the same company.

Ìý

Even by the numbers, by percentage, it's just a different thing on top of the same product. It's just a thing that no one really ever acknowledges, like the mythos of the startup is that it's an unbroken line up into the right with only correct decisions made and only scaling and success. I don't think anyone who's ever worked at [chuckles] a company like that believes that's true in practice.

Ìý

Rick: One of the things that I think is important, though, that's specific to the friction that we're talking about between product and engineering, as it relates to the growth is that how this manifests itself in an organization is a litmus test of what the priorities of the organization are. That's where I think the friction actually escalates beyond normal friction between, let's say, a developer and a DBA.

Ìý

We're talking about what's the priority of the business, is the priority of the business growth, is the priority business stability? This is where that friction starts to come in because what we see are two conflicting camps that don't need to be conflicting. They need to be aligned. They need to be on the same page as to what the priorities of the business are, but often, we see them fighting for each other for a limited amount of time and scope, to deliver new value.

Ìý

Kennedy: As you say, that alignment is so hard when you're in that hyper-growth phase because it's just a mathematical truism. I can't remember the word I want here. If you just do the math, if you're doubling every year, then half your company has been there less than a year. That's what that means. It's so hard to keep that drumbeat to keep that alignment.

Ìý

Rebecca: It sounds like this is an inevitable place to get to, but how do you recognize when you've gotten to it? Then we'll talk about what do you do to get out of it. Let's start with, how do you start to recognize, is it simply the fact that you now have a head of product and a head of engineering or is there something more fundamental that you also see that gives rise to, "Oh, now the downsides of this organization are outweighing the benefits that we're getting from this structure"?

Ìý

Rick: I was on a roundtable yesterday and one of the attendees was talking about how they've been making some really evolutionary changes inside their organization. One of the other attendees said, "How did you do that?" He said, "I had a partner in product who saw the same problems that I did and wanted to solve them." Just because you've got an organizational split between product and engineering doesn't necessarily mean you're going to have conflict.

Ìý

As long as those two organizations are in the same mind and have the same ideas to what the problems are and the same ideas of how to solve them. I think one of the challenges though from what are some of the indicators., there's lots of indicators. One of the calls that I was having earlier is the growth of tech debt.

Ìý

If you think about some of the recent news headlines around the holidays, around some issues with companies not addressing their tech debt, those are good indicators of things that you can point to, to say, "How's that relationship between engineering and product working out," when you've got outages affecting, I don't know, half of the United States.

Ìý

Anthony: I'll even go back. I'll make it more fundamental to build on that. I think if you're using the euphemism tech debt, you're already gone.Ìý[Laughter]

Ìý

It's just debt. It costs money to fix. It's just debt. The euphemism of tech debt, and I've heard lots of variants-- I've been guilty of this. I've used lots of variants, product debt, tech debt, whatever. You make up words as a way to justify to stakeholders who are pissed about it that you're not going to be doing the necessary work to keep the thing you just made stable.

Ìý

I think if it's said at all, it means that there's been some compromise along the line because it was more important to get the feature out or the story done than it was to do it thoroughly and correctly. You're always robbing from the future.

Ìý

Kennedy: Yes, but oftentimes with hydro startups that's necessary, right? You are making a bet on the future and you are borrowing from the future in order to make it possible today, which is an acceptable decision, but you just got to be careful about it.

Ìý

To go back to the question quickly though, one of the heuristics I've found really helpful is, like, there is a moment-- it depends on the company and what you're doing and how aligned it is, but in the 30 to 60 range, in my experience, where you stop having a sense of what everyone's doing. There's a point where you can know what everybody's up to. There's a moment where you're like, I don't even know who that person is in the kitchen.

Ìý

Anthony: Kennedy, you had said something earlier about this-- I'm going to paraphrase it wrong, so I'll just rephrase it. You get to a point where there's so much going on that as you hire new people, they're not added to existing teams. They're used for new things, new functions, and it's a lack of focus, and it's hard to tell what the right amount of focus should be.

Ìý

I do think if you've lived through the start-up into the scale-up, you start to notice not only that you don't necessarily know what's going on, but there are whole parts of the org you've never heard of. I think we talk about the tension and I don't want to derail this too much. We talk about the tension between product and engineering, but that's just the one that we, I think most often articulate.

Ìý

I think there's a similar tension between engineering and customer success or product and sales or product and business development because it really has to do with every individual part of the organization starts being responsible for their own goals and outcomes. Then you have to align those goals as opposed to it being focused at the company level of what you're trying to accomplish. I do think that happens between multiple orgs, although I do think product engineering is probably one of the first to cause real pain when you're in this scale.

Ìý

Rick: One of the things that we talked about in the article that I think is really important is culturally, when you start to get into the rhythm of finger-pointing. When you start to get into that rhythm of us and them. Of, "Well, they don't give us what we need," or, "They're not delivering fast enough," or, "That conversation is really, really good indicator that that friction exists." You've got a wall to break down.

Ìý

Anthony: One that's a reality of where we're at. Rebecca earlier mentioned, and I love that you mentioned this, career development. One of the things we want as ICs in these organizations is a sense of progression of our own career. Very often, if you're hired as part of the doubling of one of these groups, you haven't been there very long and you don't know that you will be there very often in these startups. You're trying to see your own path forward. We expect a maturity.

Ìý

With that maturity comes a lot of, let's say, questionable incentives, incentives that happen maybe accidentally at first, but are important. I think a new middle manager being hired, they really need to make an impact in their first quarter to show their value, especially at a company that's moving so fast, where next year, if they're successful, their team will double and if not, they'll be relegated to the sidelines.

Ìý

That's a real economic incentive for that person and a personal incentive for them to make an impact. I think there are hundreds of these going on. It doesn't mean that it's a good decision for the business necessarily, but it is a real consequence and something that those people need. They need to understand their own progression and stability. It does, I think, introduce a shadow stakeholder in a way of your career self versus your what you're supposed to be doing on the team.

Ìý

Rebecca: That gets back also to what you all were talking about earlier, the fact that they clearly do have to be lower-level goals. If they don't roll up in support of a unified and aligned goal, then you're going to have people running in different directions because that's what they feel like they should be doing to succeed. I've been given this set of goals and therefore, I should achieve these goals.

Ìý

If they aren't properly aligned and don't sync up properly, then obviously, it's going to all go horribly wrong. Then how do we fix this? What are some things that we can do to start to break through these silos? I did hear one thing about we need tunnels between our silos but what kinds of approaches have you seen work?

Ìý

Anthony: Well, I'll start this one. For me, there's only really one approach at the team level. I think there's lots of ways to accomplish it from the managerial perspective. On an individual team, you're looking at getting all of your representatives included in the solving of the problem.

Ìý

I think even at very large organizations when you see them be successful, they have aligned teams around value and purpose. They have given a team everyone that they need within the team to accomplish the job and the team will have a very clear understanding of the value.

Ìý

I think when that happens, it is automatic that everyone is seen as a puzzle solver together and the problem becomes the focus. It sounds, I think, very simple, but it is hard to do this. I don't want to pretend like it's very easy to reorganize, but by having your teams organized around specific value adds or purposes as opposed to-- I'm not very into sports, but I'm going to strain a metaphor here.

Ìý

Instead of a zone defense, instead of owning an area of code, you own a function or an actual output of the business. It gives you purpose, it gives you autonomy. You're able to develop, I think, a little deeper and that's possible in any of these org structures that comes down to just the individual team-building level.

Ìý

You could still have a product org, a QA org I've seen. You can still have separate organizations as long as at the actual doing-the-work level you've aligned a team and given everyone that team needs in the team. I think you want to avoid the teams having to go back through the rigmarole because you'll have to go through the management layer again.

Ìý

Rick: To go off of Rebecca's rowing analogy, making sure that we're all-- if you see it in an organization where you're having conversations at a leadership level of how do we make sure that the product, organization, the engineering, and the QA are all rowing in the same direction, that's the wrong conversation. You're all in the same boat.

Ìý

It's how you get your organization to understand that we've got different product teams, they are all in one boat. Now the question is, do we all get them rowing in the same cadence, but you're all in the same boat and if you're thinking about you're all in different boats, you're having the wrong conversation.

Ìý

Kennedy: Yes, a couple of things there around how you actually get those things aligned. One of the things that I've found-- two things that I found really helpful, one, is creating information radiators, going to pull-based places where people can go and learn and go and find out what other people are working on and go and find out what the organizational goals are.

Ìý

Having to ask someone, having to find out for yourself, having to waiting, creating an expectation that someone's going to deliver that to you on a silver platter is challenging. Saying, "Hey, you can go look and you can find out at any time." It's your job to know where you're supposed to be rowing is a really helpful mechanism. The other thing I was going to say quickly if I can, and then please, is this idea of singular accountability but shared responsibilities. This is when we get into, "How do you have a cross-functional team that's all pulling in the same direction?" Well, I am as a product manager accountable for certain things. You are as an engineer accountable for certain things. We're all responsible for the outcomes.

Ìý

Having splitting it that way and it feels lovely and clean and messy or whatever to chop everything up and say everyone has their own responsibilities in their own little buckets. That doesn't actually work. Saying, "Oh, we can all be responsible for shared stuff and you and I can both be responsible, but ultimately, someone's accountable at the end of the day," that tends to be a pattern that works really well in my experience.

Ìý

Anthony: I think along with that, one of the anti-patterns I see very often is that the roadmap becomes owned by a specific person or role on a team, as opposed to being the marketplace where the different factors or the different realities that we're dealing with are debated and prioritized as a group.

Ìý

Again, that's where tech debt, and things like that, I think start coming into play is when you have one person who isn't representing that debt describing it, but I think, Kennedy, to build off what you're saying, is if I'm responsible for market fit, if I'm responsible for delivering the thing that our customers are requesting and you, as an engineer, are responsible for making sure it's stable and actually performs the function, and the QA is there to make sure that we understand that it actually did the thing.

Ìý

Each of those are important prioritizers when we think of a roadmap. All of those people should be involved in the prioritization. All of those people at the team level should be involved in that. I think that an anti-pattern that happens very often that if you catch yourself in you can break is when PMs, I think this happens very often with PMs, when they prioritize in a bubble and then they compare their priorities to other PMs, as opposed to comparing their priorities to the engineer on the team, or comparing their priorities to what customer success is saying is the reality of the operational cost of what you've made.

Ìý

When you start saying, "Well, between the PMs, we all need to figure it out, because then we're going to move engineers around and try to resource it." I think that's a time to reflect and say, "Okay, wait a second. Let's bring those other people in and have them prioritize these individuals before we start comparing them to each other," because you lose a lot if you start trying to treat individuals, PMs, engineers or anyone, as widgets that can be changed between priorities in that way and I think those come hand in hand.

Ìý

Kennedy: Yes, to elaborate, just to take that accountability and responsibility thing I was talking about, I think your product manager, someone should be accountable that there is a good roadmap that has everyone's input. The product manager can be accountable for that but everyone's responsible for making sure the roadmap is good and pointing in the right direction and providing that input.

Ìý

Rick: I know we've been talking a lot about the specific members of a delivery team but I also want to make sure that we don't forget the importance of management. What we talked about earlier was this idea that your delivery teams are a good mirror of the relationships of management.

Ìý

If your leadership at the VP of Product and the VP of Engineering, if that relationship is contentious, you're going to have contention in the delivery teams. Making sure that at that VP level, at the director level, at the manager level, there is cohesion of vision, cohesion of purpose across those two different teams, that's going to pay off in dividends in your delivery teams too.

Ìý

Anthony: A shared definition of success between those orgs, that is so often skipped over and because of that, definition of success can fall through often from a strong CEO or from someone who is really dictating from pretty far away from it but a clearly defined value metric for what you're accomplishing can negate so many of these situations you're in.

Ìý

Even if you started that way, when you get to brass tacks of trying to move a specific value for the company, if it's real, you'll self-correct these because you'll throw enough elbows.

Ìý

Kennedy: Yes, absolutely. One of the core ideas that come out of XP in particular is this idea of focusing on principles over practices and saying, what are the principles we're trying to achieve here? What are the values for the goals? Then the practices, they can come and go and we should be skeptical of our practices if they're not achieving the goals, values, and principles we're trying to achieve.

Ìý

I think exactly the point, velocity, and having a good roadmap, these are all input metrics and these are all proxies for the thing we really care about, which is creating real value for customers in ways that also create real value for the organization. When you have that you can have a reasonable discussion about, "Well, is this actually getting us where we want to go?" If not, you get into stupid arguments about velocity because you don't have something that you're evaluating that against. What's our velocity? If we're making dollars, does it matter?

Ìý

Anthony: It's a great point, but it's also another checkpoint to catch yourself and if you find yourself arguing over capacity and velocity, it's a good indication that you should try to reframe that conversation to value for the company and the impact that you plan to have. This comes from an old thought worker that I love and hope is doing well somewhere but Scott Moots would say, "You need to call your shots."

Ìý

I feel like it's very often overlooked in these elaborate planning processes for someone to say, "This is what I think will happen when we do this," as opposed to saying, "I'm going to make this metric go up 20% to start with the assumption that I don't know what the ultimate impact will be. I think it's this so I'm going to say it out loud for everyone so that you can anchor against me and I can learn against you."

Ìý

That often, it's scary to communicate in that way. It's scary to say you don't know. It's scary to say-- on paper for your promotion you want to say, "I'm going to raise this 20% because I was told to and I did. Look, we did 24%. I beat it by whatever." I think just that humility that comes with like, "I don't know what's going to happen, but I think it's going to be this," is another way to diffuse when you catch yourself in that situation.

Ìý

I really like what you said about that because arguing about velocity happens constantly and it quickly becomes moral and philosophical. It quickly becomes this argument against widgetizing humans when really, I think it's much simpler than that. It's just two different teams that don't know how to measure each other and this is the lowest common denominator. It's the easiest thing to get quickly and it works best for spreadsheets.

Ìý

Kennedy: This is where we get into other stuff that's probably a little bit out of scope here, things like safe and scale, agile frameworks and stuff. To some extent, one of them, I think, exactly our point is like if you give teams business goals, if you give teams goals based on the value they're trying to create and that can be based on a theory.

Ìý

If we increase this user behavior metric, then it'll help our business, sure, but if you give them that, then who cares what process they're using? Now, if they're not succeeding, we should, as leaders, come in and intervene and help them figure out a process that's going to be successful but if they're succeeding, scoreboard. That's what matters.

Ìý

Rick: I mean, within limits. You don't want to spend $10 million to make $1 million. Within limits, we want to make sure that we've got some level of efficiency in our engineering organizations but tying all of that efficiency to customer and business values is ultimately the punchline.

Ìý

Anthony: I think something that I've very rarely seen but would help with a lot of this is the idea of calling when something is meant to be retired, killed, or when you know that it didn't work. So much of this is focused on the fact that it is imperative for each individual manager and team who wants to progress, to show success and progress.

Ìý

Things that aren't working, things that are taking longer than they should, things that should probably be shut off because they didn't have the impact, instead get tainted by a narrative that a handful of people needed in their political reality or personal reality, but then the company just has to carry forward.

Ìý

The 10 to make 1 is a great example of before that got launched, was there a statement? It shouldn't be hard to make. It is hard to, I think, execute politically, but it shouldn't be hard to say, "If this doesn't show X by this date, our hypothesis is wrong and we should reevaluate whether or not to support it at all." Instead of what often happens in these scale-ups is that you have all these weird, unending experiments that just continue in the code and drag everything else down.

Ìý

Kennedy: Yes, I mean, it's zero-based budgeting applied to software priorities. It has to justify its existence. It's not the other way around. It doesn't stay unless you can say why it gets killed. It goes unless you can convince us it stays.

Ìý

Rebecca: Well, and organizationally though it is very difficult to say, "This hypothesis did not turn out but there was a valid reason to think it would," and therefore, it's not that people messed up, it's that there was something there to learn that we didn't know verses maybe it was just a bad idea, or maybe it is a good idea, but the team screwed it up so much that we couldn't even see whether or not it might succeed because there was a delivery failure.

Ìý

Organizationally, it's much easier to just always declare success and anything that doesn't look good, failure. As opposed to seeing what you can learn from those middle areas where there is actually a lot of learning to be had.

Ìý

Anthony: Well, everyone talks about failing fast, but have any of you ever seen that supported in practice at beyond the earliest startup phase? No one is saying, "Oh, your $6 million initiative failed in three months." What a great learning. Maybe they should, but I think you're absolutely right, Rebecca. It's very hard in an organization to think that way, even though that's the truth of what's happening very often.

Ìý

Rebecca: Yes. Is there any sense in which as a scale-up continues to scale and grow that we can ever declare this problem done? Or, does it actually change character and need constant attention? Even once you've address, the initial instance of, Oh, we've got enough versus them now.

Ìý

Kennedy: Yes, my opinion on that is, if your organization and its goals never change, then you can get to a finishing point. If your organization's changing or its goals are changing, then you probably can't, which is to say no.Ìý[Laughter]

Ìý

Anthony: All living things change over time. I agree. If you're in a situation where your org and purpose is completely static, and I'm sure some astute listeners can articulate a handful of very specific cases where that's true, but the reality is the economy changes, the expectations change, the individual employees' expectations change.

Ìý

People leave your org. There's any number of reasons why, and many of them are healthy reasons. You're going to always be renegotiating this relationship. I think that is not only healthy, I think that's a good thing. You should be renegotiating. I think that the earlier you think of it as an ongoing negotiation, that the healthier those discussions are going to be for you.

Ìý

Rick: I would add that and we were talking with a global FinTech company who was suffering from this exact problem. One of the things that was said in the conversation I thought was really impactful was, while the scale of the problem has been magnified globally, the number of opportunities to solve it has also magnified.

Ìý

The chance that you can solve it locally, you can solve it regionally, you can solve it-- then your opportunities to knock down this wall has also magnified. It's just whether or not you take the energy to do it.

Ìý

Rebecca: I also think it goes back to what Kennedy was saying earlier about principles over practices. The specific implementations of some of these fixes are going to vary based on scale. The principles of alignment that we're trying to achieve, those are probably not going to change and are not, or should not be driven by things like personalities and things of that nature, but more this is the value that we're trying to deliver and everything is going to be focused around this.

Ìý

Rick: How you solve it locally can be varied. The point is solve it.

Ìý

Anthony: Yes. I think being aligned around real value fixes so many of these issues. So often, the frustration comes within, and this is not just between product and inch but within an org. Within engineering talking to their managers or within product in their roadmap planning. So much of it comes from the fact that a lot of the effort isn't measurable and isn't value-based.

Ìý

Our quarterly structure doesn't really give us the time it takes for complex things to get feedback. The idea that you have this whole list waiting for you next quarter, and the engineering's, their private list is growing each quarter. It's easy to pretend you're still organized on value, but really you're organized on a to-do list and making sure that that to-do list doesn't get very big.

Ìý

Just truing up to the actual value, everyone knowing and caring very deeply about what actually is happening and what the impact was, and being as an organization trying to learn patience to wait for the real results as opposed to using those leading indicators. I think it's easier to do them it seems, but I do think it's scary to make that change for a lot of people because there are individual implications for your career, for your position, for your political clout. It is the balm. I think it's a universal balm for this.

Ìý

Rick: Yes. I think one of the other challenges though, sorry, Kennedy, is that there's a level of trust that has to be developed between the business and the product plus engineering delivery team to say, "I actually entrust this team with this business value outcome." So many people in the business believe that they own business outcomes when that's somewhat of a fallacy.

Ìý

If you start to peel back the any of the layers and so that trust that has to be developed that you've only ever been able to move as fast as your engineering and product organization just own that and lean into it. That's really hard for a lot of organizations to come to grips with.

Ìý

Kennedy: Yes. I think that's something to say. We wrote this article with the frame of scale-ups but this is something that applies to any organization that's larger than one team, basically.Ìý[Laughter]

Ìý

The way it looks is really different. I think in particular though, to your point, Rick, this applies to more and more organizations, even ones that aren't technology startups or coming up with technology-based digital products, that kind of stuff. Exactly your point. The software is eating the world to quote Marc Andreessen.

Ìý

You don't have a business without the software. If all the software went away tomorrow or the technology went away tomorrow, your business would be unable to run in materially different probably. To me, it's strange not to entrust those folks who already run part of your business whether you want them to or not with the business outcomes you're trying to achieve.

Ìý

Rick: Whether you acknowledge it or not.

Ìý

Anthony: Well, I would offer, just I've seen these people suffer so many times in these orgs. If you ever find yourself even congratulating yourself that engineering and product are aligned or that your viewpoint has been successful, go talk to customer support. Go and actually sit time with customer support.

Ìý

Even in aligned teams, it's easy to pretend like this is the crux of the world, but the people actually talking to the individuals suffering through your decisions every day, I think is a humbling experience that more people should experience. I really liked when you said it's any team with multiple orgs. It really is multiple orgs that we're talking about.

Ìý

Product and engineering are the two that I think scale super fast. They run into some of these problems in a more dramatic and immediate way. All of the scale-ups I've been at have suffering customer support teams with queues that are going long and customers getting frustrated, it's very rare for someone to have prioritized that along the path.

Ìý

The same reason or the same point of this relationship in product and engineering needs care and feeding over time. Once you think you have this one solved, go and build bridges to other parts of the org. At the end of the day, all of them are necessary to delivering their value to customers. They might represent different edge cases or different types of customers. I think you're going to find the same situation anytime a team has a different way to prioritize.

Ìý

Kennedy: Yes. You're calling out specific customer support I think is so important too. Often, I see with our clients this like, "Oh, the business wants, the business wants." I am so allergic to that. The thing I do all the time is just like, "Who do you mean? Do you mean Dave in marketing? Do you mean Sharon in sales? What do you mean the business? We're all part of this business, so who are you actually talking about, both organizationally and the person, because business is not a monolith. It's a bunch of people too, just like we are over here."

Ìý

Rebecca: Excellent. Well, I'd like to thank you all, Rick, Kennedy, Anthony, for quite a wide-ranging conversation. It got a little dark there for a while, but it feels like this is actually a problem that can be solved if we acknowledge that it exists. I would like to thank you all for your participation.

Ìý

Rick: Thanks, Rebecca. Appreciate it.

Ìý

Anthony: Thank you so much. I agree it is solvable. It's not all darkness.

Ìý

Rebecca: Excellent.

Ìý

Kennedy: It's just work.

Ìý

[Music]

Ìý

[END OF AUDIO]