Europe 2022
Product Org Design: Flow Follows Form
Product Org Design: Flow Follows Form
Dr. Mik Kersten
Founder and CEO, Tasktop
TRANSCRIPT
Thank you, Soja and Nigel. Okay. The next speaker is someone who should be very familiar to most of us in this community. Dr. MC Kirsten wrote the amazing book project to product four years ago, which is being used by so many organizations to change how they think about their software development efforts in this community. We all know how important architecture is to enabling fast flow. Over the last two years, I've been exploring with Dr. MC Kirsten and my mentor, Dr. Steven spear on the lesser known corollary, which is that the architecture and the structure of the organization must be isomorphic. In other words, we can create an organization that is structured so that teams can work independently where local problems stay local and amplify as important signals of performance, fully supported by the software architecture. Or we can design an organizational structure that prevents teams from getting done, what needs to get done and dampens or extinguishes entirely the signals that leaders need to know that the system is working regardless of how good the architecture is. I am so excited that Dr. Kirsten will be presenting our real life case study of an organization that he did at his company task top the benefits that he expected, what actually happened and what he did about it. I think this is an important talk because he models so explicitly and so well, how we need to think through organizational design is something I've rarely seen, but I think it is so important to getting the outcomes that we want. Here's Mick.
Hello everyone. My name is Mick Kirsten. I'm delighted to be joining you virtually from Vancouver since founding tasked up 15 years ago, I spent a lot of time trying to better understand the intersection of organizational design and software architecture. And I personally come back from a come from a software background and I've been helping the organization grow and understanding how these different kinds of modules, which are teams and people, and, uh, things actually with feelings and aspirations, uh, can actually be structured in a more effective way for the growth and happiness and productivity of every organization. And that's actually what led me to my work on studying flow, how we can better make teams deliver more value to customers and the things that impede that. So over the past few years, I've been working with enterprises, making this shift from project to product. And what I've noticed is that many organizations have nailed organizational design at the agile team level, but at the team of teams level above that level, things seem to be a, a bit of a mess and the different approaches are being taken.
Uh, the fact that people would copy paste the, uh, Spotify model and not even recognize the fact that Spotify has moved on from the Spotify model, I've noticed causing all sorts of problems. And the fact that we're not actually measuring these designs is in a problem in itself measuring the outcomes of organizational designs. So personally, on my own journey, I have found the work of the DevOps enterprise community as critical to the toolkit that I, for understanding how to configure evolve and, and measure the effectiveness of organizational designs. And in this talk, I'll share with you how I've used it and some profound steps and actually some, some really big missteps I've taken along the way. So this talk is about how flow follows form, and it really plays on this architecture concept of building architecture, concept of form following function, where buildings actually look like they're intended use.
Uh, there's, there's some very neat buildings in this presentation backgrounds. Uh, they're all art by Zaha. Haddi, uh, sorry, architecture by Zaha. Haddi, uh, who's actually the person who designed the BMW Sik plan, which was featured in, in project to product. So the point being that just as physical spaces have an impact on our creativity and our wellbeing, organizational designs have an even bigger impact on, on our wellbeing, uh, in our day to day work and our day to day, day life. So the key lessons I've learned is that the flow that we get from the organization, the happiness of the staff organization is really a, a function of the structure of that organization. As the question is, how can we improve this? And how can we design organizations that are better for their, their staff and for their customers? The thing that we've seen as organizations adopt, uh, this shift from project to product is that it is being used as a catalyst for change, I think for some very important change.
So the, for example, on the architecture front, the fact that you start thinking about software architecture as decoupling value streams, to accelerate flow to the customer and to minimize dependencies, it's actually a pretty profound change in how we look at architecture. Uh, the fact that if bottleneck detection that comes from studying and understanding flow will actually mean that you automate everything away and you start making more and more of a business case for your DevOps transformation for more automation actually has a pretty profound impact on an organization. Uh, the fact that budgeting, changing to changing to become more iterative and more capacity based and not something where we're creating these projects and can honestly throwing work over the fence is another significant change as is reporting the fact that with the change in budgeting, we actually need better visibility into our flow is our transformation is our move to cloud actually producing the customer outcomes that we want.
Uh, is it producing the, the acceleration that we wanna see in our flow metrics or is it not? And do we need to adjust and pivot and finally organizational design, how do we, if we are not going to bring business and technology together, as we need to do in any project to product transformation, how do we actually design the organizations? What are the roles, what changes, uh, with what we've got today? So at the core of this shift is actually designing under understanding and measuring our value streams, how we deliver value to the customer, be that an internal customer and external customer or a business or a business partner, and these value streams, they need to be aligned. So they need to be aligned to customer value. They need to follow that, that ideal of customer centricity, they need to be autonomous so that they're decoupled and can move us fast.
And for the needs of that particular, uh, customer, and they need to be cross functional. We need to bring in together business design operations and all of the different stakeholders needed to deliver value to the customer. However, that all sounds nice. In theory, the, the challenge for the starting point level of organizations, it's all different if you're, if you're building a new organization today, but we have to implement this on top of our existing organizational structures and designs. And often those, those have evolved around a very specific set of functions, and they often evolved from a project orientation, not a product orientation, they're functional hierarchies, they're geographies to consider in large and complex organizations. We have multiple sourcing partners. We're actually dealing with multiple organizations. And what we get from this is, is it's being increasingly called as this messy matrix. The fact that we wanna have these very horizontal, these very flow oriented value streams, but we have to implement them on top of our existing organizational structure.
And the challenges that these, the, this, uh, these organizational designs tend to be all over the place. So models are changing, uh, the way that hierarchies work are changing, but oftentimes organizations go through these larger reorganization, again, bring in something like the Spotify model, basically copy and baseline to the organization, and then actually measuring. Did we improve things that did we make make were better for people? Did we move remove burden, or did we just introduce a whole other new set of bottlenecks? And one thing that I found really fascinating is that technology companies just nailed this. So they, the way that they continue to evolve organization design the way Amazon has moved way beyond what started as two pizza teams is fascinating, has become very effective. So as a leader myself, I want to understand, well, what, what are the first principles I should apply to organizational design?
What should I have in this toolkit? How should I work with, with the teams, without the other leaders in the organization to again, make a better structure and bear dynamics for their, for, for the company. And this is where I really have been drawing on the most recent work of gene Kim and Steven spear, where what the concepts they introduced are these structure and dynamics and how leaders actually get to set and configure system level goals around organizational design. And of course with, uh, this architecture mindset, we get to configure, and then we get to run. We get to execute that new organizational design, that new model, and then assess how it's doing. So the job of leadership becomes designing this organization. Uh, and then actually assessing the organization, understanding with the design that we created did, did we actually get the outcome that we wanted for customers, for our staff, for our shareholders?
Now, the toolkit what's interesting is I'm finding is, is actually evolving quite well. These pattern, we now have these much richer pattern languages. This is I think to me, one of the most important contributions of team topologies is that it gives our organizations a, a language to talk about team structures. And of course we need a way of measuring those structures. The goal of team topologies is to, uh, better design for flow and there we've got the flow framers. So I'll show you how, uh, in the way that we've evolved, our organizational designs have actually used both those concepts and then measuring and assessing through, through measuring flow. But the key thing I wanna get across is what's, what's underneath all. This is again, these two principles. And these, these to me are the, these first principles around organizational design of structure. Again, how we, what the HIEs, what those matrix lines are.
Uh, and then the dynamics, once we've got that structure, which signals got amplified, which signals are being, are being suppressed, uh, what's working where, where are we actually succeeding with decision making, being lower in the organization and where's actually flowing too high, or, or should it actually fall higher, uh, than we, than we shot it would than we thought it should. So with a SI on designing and on assessing, uh, we've got, I think it's, it's actually very easy to, again, leverage some of these new tool things in our tool, get some of these pattern languages. Uh, so we've got team topologies here. There's working safe and scrum and Spotify and single for ownership. They all start with us for some reason. And then we've got the flow framework. We're can actually measure flow and understand are we improving flow are making it easier to contribute the value to the customer.
And how's that translating to outcomes through these business results of value of cost of the value stream, the quality and the happiness of the staff working on that value stream. And what's so interesting is when some great designs on the left here actually don't translate into what we want on the right. Uh, a couple years ago, I was working with an organization who decided that they really needed to shift to a more automated testing and create some platform teams for automated testing. And as part of that, they end up actually reallocating over a hundred manual testers, but they did that without making their core software components, their business applications, more testable. And so it was a complete disaster <laugh> in terms of the actual quality metrics that they got as a result. So they seemed to do all the right things from an organization design point of view, but because they were able to see that their flow was reduced, their quality was reduced.
They were able to quickly pivot and, and realize, okay, we actually do need some manual testing until we make our software more, more testable. So the whole goal here is that organizations are complex dynamic systems flow is complex, and we need to be able to measure that and actually have that inform our organizational design. So here we're actually, but at, uh, at Z hahas designed, uh, BMW live plant, and this is the story I'm gonna tell you of how I actually applied some of these principles in this toolkit. And some of the things I learned along the way. So this was, this story starts about a, a decade ago. And task had always been a, a product oriented organization, but really started out with just engineers. So just open source engineers. And 10 years ago, we added product managers, uh, and we created product management function.
And of course that was a really important improvement for us in terms of our, our design terms of getting closer, our customers and making that a, a first class function. Uh, then four years ago we realized, okay, we're actually getting a little bit too siloed ourselves. And of course we're always preaching not being siloed. Uh, so we realized, you know, why do we really have a separate product management and engineering organizations in the HR hierarchy and how the hypothesis that merging product and engineering or the, the two organizations that two hierarchies will actually accelerate our flow? So the desired outcomes we were after of course is even more customer focused, not just for the product managers, but, but for the entire product development organization, less us versus them of saying, you know, you didn't understand the architect, or you didn't understand the performance constraints where everyone's in the same boat decision making is lower in the organization does not need to go as high because both the product engineering functions are together and actually elevating our platforms to be products.
So each platform has its own product manager it's on the roadmap and all of that. So those were all of the goals. Uh, we actually documented this, uh, in the, in the talk at DevOps and summit in 2019 in London, 2019, this is the, the Rio happened in 2018. So it's actually available in the it revolution video library. And you can go back and check the sort of things where you were thinking back then, uh, versus the sort of assessment that, that you'll see me provide right now. So fast forward two years. And here's what we saw in terms of that assessment. So that was, you saw the configuration of merging those two. Here's how we assessed it. First of all, in terms of these business outcomes, uh, the value metrics, things are going great. So, uh, our, the new product that we launched task op vis it had 200% year your growth for the course of over the span of those those two years.
So from a business perspective, everything looks, looks hunky door, uh, from a cost perspective. This was as planned that would continue to grow our R and D. So we've, we actually end up doubling each year, the size of the product and engineering organizations together, the product development organization and the, that there's the cost on the head count, the flow velocity, of course we're growing quickly. So we understand that, well, it takes time to onboard these people, uh, and we kept being hopeful. The full flow velocity should start accelerating, uh, in terms of our basically flow velocity per Ft. But, but we realized it was going in fits and spurts. We did some replatform things in the process to help, uh, but, but it really was trending to flat. So we were not seeing the same kind of output from the investment that we were making.
And we're trying to understand, well, we are scaling, uh, looks like we're scaling effectively. Why are we not getting that? And then there's this other really important signal again, from one of the main, uh, metrics in the full framework is the happiness in which we measure quarterly through an employee more score. And what we were seeing is that it was actually, it was also never in the straight line, but it was actually trending down over time. And so together each one of these things and themselves, you know, part, part, part of the metrics look good, the business, the business, and the finance metrics look looked amazing. Uh, but we were seeing some really significant problems when we measured the system. The fact that the flow velocity was effectively flat and happiest was declining. Something seemed wrong. And then I had this, as we realized we actually needed to go into this diagnosis phase to understand what was going on.
And I had one of the most profound moments of my entire, uh, history at task stop over the last 15 years, which is, uh, a session with all staff was an asked me anything session and what step Pingle one of her most senior engineers in front of everyone, which, which is a great thing that he does. He actually said, uh, Mick, you're such a fan of team to apologies. So here's my question. Uh, if you're such a fan of this book, why do we keep overloading our platform teams with multiple complexity domains? And I think as a lot of us know, uh, as soon as you put more than one complexity domain on a platform team, things slow down, they don't speed up. You're overloading, you're, you're putting cognitive overload on your teams. So why have we created a pattern? He was asking of doing this over and over and over again, rather than actually properly architecting, uh, our platform teams and how much work that they can take on.
And I realized there was something really wrong because those signals were never making it up there. Those teams were overloaded at, at, at this level. And then we kept diagnosing further. And what was happening is the architecture, both between the platforms and some of our customer facing application, the coupling was growing. There were these initiatives I noticed of more and more meetings that were cross value stream and identifying cross value stream opportunities for collaboration and dependencies, these kinds of things. But those meetings were just, just growing their number and their importance. And then culture signals had actually changed. So we had code jams is just, were developers at the end of a, an iteration, just get the code, whatever they think would be, uh, most interesting or most novel. Uh, and they had, they actually actually disappeared. And then our, our community events, uh, in terms of our engineering communi communities had also disappeared.
So this was this to me, this, this, these findings were obviously bothersome. I was wondering how, how the heck did this happen on my watch? We've all my background is all development in engineering. Uh, but they were, they were, they, they were symptomatic of something. And the fact that the way the, the configuration of the organization designed suppressed certain signals and amplified others applied all the customer signals, but actually suppressed some of the signals of what our platform teams were feeling and the cognitive overload that they were feeling. And in, in supportive customer outcomes, we actually deprioritized things like code jams and the kinds of things that actually help you get better and better over time. So this single org hierarchy structure was just so compelling and so seductive, we thought, okay, this will, this will be simpler. It's more modular. It's it should have fewer meetings.
But what we saw in terms of its assessment was actually, it was actually causing these signals that were really important. Some of which should go to the very top of the organization, these very high organization, like when we should actually re-architect or when we should invest another set of platform teams, weren't making it up. And so the key lesson from this was by assessing it, we realized this was wrong for us at this point in time. And, you know, there's, and this is the key thing is not so much where we ended up, but the fact that we were able to assess that and understand where we were going, this is actually similar to, to what you might see if you you've been studying any of what, what, uh, how sh uh, Spotify has evolved beyond the Spotify model. They had a, a, a similar challenge.
There was no one from engineering who was sufficiently responsible to prior prioritize that kind of engineering work, where of course, all the customer work was always, was always taking precedent. And so, in terms of where we are today in this organizational design, we're already seeing this working the elevating of engineering. Uh, the fact that this is now training, mentoring, recruiting are first class function of the company. Uh, we've, we've seen tremendous results already, such as in the last three weeks, hiring three new 10 Xers, as well as elevating, uh, the career trajectories of our engineers today and reevaluating how we actually bring engineers along those career paths and making those career paths even more first class, as well as of course doing those things for other parts of, of our organization. Uh, we've also even adapted off this model when we initially did put this, I, I, my thinking was why don't we put support engineers right into the value streams realized that's not the right thing for us.
That's not gonna accelerate our flow, given the way that we provide our support to our customers today, but for another organization that might be the right thing. So again, the whole goal is, do not copy and paste this, just use this toolkit, use these concepts of structure and dynamics, and actually creating this, this feedback and assessment loop for creating the right organizational design for your organization, and then evolving it from there. So, and do keep in mind. The other lesson for me that was really important is that this product focus and this engineering focuses a pendulum, and you actually wanna set that pendulum to be specific for value stream for more platform value streams. You probably need more engineering focus for more external customer facing products for faster moving consumer products. You need much more product focus. So just be very deliberate about setting in the organizational design, the, the structure and the right kind of leadership for each of those roles.
So with that in conclusion, I think the key thing that we need to keep in mind as leaders, as team members is to design organizations and be aware of these pattern languages. And actually everyone in the organization should be aware of this. Everyone in a platform who should know when they're cognitive overload, that's too high, which is why these concepts are so important to assess this and to have a way of measuring it, which is really what the flow frameworks meant for that we, we think make things easier for our teams, or did we actually slow things down and introduce more bottlenecks and more burden and to continue improve this, to make sure you've got those signals happening at least a monthly or quarterly basis. So you can actually create this, uh, path for a qu at least a quarterly improvement of the structure of the organization by measuring those dynamics to learn more.
Uh, I've actually been so interested in this topic. My last three podcasts, uh, have all focused on it was Michelle Liu, manual patient Jordy Henderson. So you can check that out on project pro.org, the key books here, of course, team to apologies, but also working backwards at and ask your developer. I found to be tremendously helpful in terms of helping, helping me on this journey. And then in terms of additional help, I'm looking for, it'd be great to have others share their organizational design and what's worked. What didn't did you use two in the box three in the box? What approach did you take? And you can do that on the flow frame community@flowframe.org. And with that, thank you very much.
