Managing the Flow of Value in Service Organizations

The flow of value is important in all organizations, but especially so in service organizations that are by the virtue of their business model more susceptible to disturbances in the flow. Why is this so?


Service organizations help their clients achieve business goals. Unlike their product-led peers, they don't rely on passive income streams based on subscription models. To maintain a steady income stream, service organizations need to continuously sell and deliver their services. Much like sharks that need to be in constant movement to keep the water flowing over their gills and prevent them from suffocating, service organizations must constantly sell and deliver their services to keep the cash flow healthy. And they need to do it most efficiently!


Managing a healthy flow of value in service organizations includes challenges not present at product organizations and stemming from the fact that service organizations don't work on their own but always for client organizations. Client organizations can stop ongoing initiatives, create completely new ones, and (depending on the collaboration level) significantly influence the technical solution and ways of working.


All these factors can significantly deteriorate the flow of value in service organizations which is why they need to closely monitor the flow and promptly remove impediments that get in the way. Work variability in service organizations is much higher than in their product-led peers with more predictable roadmaps.

IK

Ivan Krnić

Director of Engineering, CROZ

KM

Krešimir Musa

CTO, CROZ

Transcript

00:00:00

<silence>

00:00:13

Hello everyone. It's great to be back at dz. My name is Ivan kic and I'm director of engineering at Cross a professional services company. So we don't base our business model on products that we sell, but instead we work with our clients and help them deliver the best possible software solutions that would enable them to reach their business goals. Today I'll share our experience of managing flow and what good that brought us. There's been a lot of talks on the topic of flow and generally how organizations work, but I found that overwhelming majority of these experiences and case studies come from product companies. I believe that this world needs more experience sharing by service oriented companies, so service oriented companies can grow, but also to facilitate a better collaboration between client and service organizations for the benefit of the whole industry. 10 years ago, we were convinced that service organizations build their business by increasing the amount of work that they do.

00:01:14

If service organization wants to increase its revenue, it can only do that by increasing the headcount and taking over more work, and that's exactly what we did. We rapidly grew in numbers and jumped on every opportunity that came our way. This caused a massive overburden in the company for every opportunity. We conducted an introductory meeting and we did an analysis of what needs to be done. In order to provide a binding proposal, we had to figure out the architecture. We had to do some serious estimation. We had to draft the proposal and do all the administration.

00:01:49

All this work took precious time from our senior engineers who while drafting proposals didn't work on their already contracted projects for the existing customers. Since previous proposals introduced some commitments on the project duration and delivery dates, it was pretty clear that our teams were into long working hours and working weekends. This is a part of a blog post written on internal communication platform 10 years ago, and it's so telling. It says, here is the review of a week that has just passed. We started a week with a bench full of unutilized people and we ended it in a way that we had to forcefully take several people off of one project to cover another two projects, and that's great. Let the CPU work on 120% if possible. So this short paragraph tells so many things. First word unutilized implies something bad is happening in the organization.

00:02:42

Service organization makes money by working on projects, so if people are unutilized, they're not making money and this is a major problem. Next we were having project teams for each project. We were forming a new team specifically for that project, and once the project ended, the team was dismissed, so no sign at that point of long-lasting stable teams. Another observation, what kind of planning did we have if we had to change our plan so dramatically in the course of one week? Yet another observation. CPU Working in 120% is actually a desirable state where CPU actually refers to development department. So we have a classical resource oriented mindset here. People are resources and as such, they have to be fully utilized. All this resulted in well-known consequences. Our burden gave way to burnout. People losing motivation, exploring new technologies didn't get adequate priority, and at some point we ended up with a machine working like crazy in high revs, delivering features 100%, but also innovating 0%, which was said it's easy sometimes to find yourself in a vicious cycle not knowing that things can be different, and that's why I'll forever be grateful to this community for talking openly, sharing ideas and showing examples that things can work differently, that it is possible to change our race.

00:04:08

What we did since the dark medieval 2012 is influenced by so many ideas and people that is hard to mention them all, but I'll do my best to give all the credits. Burnout was something that we noticed early on, but burnout was a consequence, a symptom that we knew wasn't healthy, but we didn't understand the theory behind it and what the change. Our first realization of detrimental mechanism that was underway in our organization came in 2014 after our annual QED conference where Nicholas Moody gave a keynote talk called This is Lean named after his book. In this talk and in the book, Nicholas shared his learnings about lean mindsets, especially about the difference between resource and flow efficiency. I read the book soon after the conference and it became very obvious that the flow or better said the lack of it was the problem that we had and everything that we did from that point on was in the service of improving the flow.

00:05:11

Flow is important in all organizations, but especially so in service organizations. While teams in product organizations share the common context of the product that the organization is building, it is perfectly normal for large service organizations to have many unrelated projects for different clients that are not connected in any way and all started at the same time as opposed to product organizations which control all of their processes and decisions. Service organizations work with their clients and it's usually those clients that call the shots. In the end, client organizations can stop ongoing initiatives or they can create completely nuance. Because of this narrow focus on products and full control over roadmap, product organizations experience less variability, which leads to better results in improving work processes and making good technical practices. Repeatable service organizations, on the other hand, work on many more projects, so they experience a lot more variability in their work pipeline and therefore they struggle more to standardize and improve work processes and this is a huge risk for flow Service organizations should therefore invest extra effort in keeping the flow healthy opportunity pipeline shouldn't be empty, but it also shouldn't be completely full. Providing the organization enough slack to help their clients when they really need it and to sharpen its skills for future to balancing between those two states is an art that happens on several levels in the organization and requires constant fine tuning.

00:06:45

These levels are best described by Klaus Leopold as flight levels. He argues that the work coordination happens at three levels in the organization. The lowest and the most operational one is the flight level one, and it relates to the coordination of work in a single team. This means that the team is using some approach to organize themselves and coordinate their activities. Typically it's ban or scrum, although the work inside the team is coordinated, the inflow of work to the team is not coordinated and arrives. We have pushed principle from many directions. This means that the team usually has more on its plate than it can handle, and by implementing the flight level, one organization will experience some improvements where coordination in the team and improved visibility will improve team efficiency. However, since the inflow of work is not coordinated, there is a risk that the team will be working on the wrong things and also since the work is coming from different directions, there will be many expedite requests and a lot of reprioritization.

00:07:49

Next level of work coordination is the flight level two. This level deals with coordinating multiple teams to get the work done. There is a central and prioritized backlog for teams, which means less, uh, less expedite requests and Reprioritization flight level two manages the work on the value stream level. It optimizes the interaction between teams to deliver the value in the most efficient way by ensuring that not only the right thing gets done across teams, but also at the right time and in the right order. Flight level two will ensure that the project and product inter increment gets done, but organization is more than just one project. This is particularly true for service organizations that implement many projects for many customers. Success of a service organization rarely depends on a single project. It is the result of a complex interplay of business goals, strategy, consulting skills, client organizations, partnerships, technical capabilities, hiring, retention and so on.

00:08:53

So focusing on the single projects will certainly help those projects end successfully, but in the great scheme of things, it can actually harm the organization if we are not carefully balancing all those aforementioned factors. That's where the flight level three jumps in. Flight level three optimizes the portfolio of projects by taking into account multiple projects at multiple customers in order to support organizational strategy in achieving business goals. Typically this comes down to making informed decisions on which projects to commit to and allocating people and resources on those projects to maximize the chances of achieving the business goals.

00:09:36

So how did we implement flight levels at Cross? The first one we have implemented was the flight level one. We have unconsciously started there because teams are where the rubber meets the road Teams are where the feedback loop is the shortest and the ING goes wrong. You'll notice the spars there. First, we have never mandated one specific methodology for all teams, but we did set up some enabling constraints. For example, we needed, we need to have a well maintained backlog. We need to have a good coordination in the team on who is doing what. We need to plan ahead and respect commitments, but we also want to grow our skills and we don't want to burn out doing all of this. In essence, the work needs to flow. Some teams opted for a scrum like approach while others opted for camel like approach. Any approach was fine as long as the team was in control of what it was delivering. We immediately saw the benefits here in terms of better organization, fewer escalations and teams were happier because they weren't jumping from one fire to the other.

00:10:44

The next level that we have implemented was flight level three. We saw the need for flight level three when we realized how much we have been wasting our time and energy on drafting proposals and implementing projects that were in essence not strategical for our company. We needed to somehow manage what's centering our funnel. In short, we needed a mechanism for choosing which projects are strategical for our company so we could focus our energy on those projects, which in turn meant that we would need to skip all those non iCal ones. So we formed a group of people called the portfolio board, and their task was to evaluate all opportunities and stop those that are not strategic. The group gathers weekly every Monday morning for 30 minutes and it goes through all new opportunities that are created in the CRM system and approves them or rejects them.

00:11:36

Approved opportunities are the strategic ones that we choose to invest our capacity. In the beginning it was a weird conversation, how do we choose what the company will work on? We all had some interesting understanding of such work, but we didn't have explicitly formulated rules. But soon after several sessions, some core criteria started to emerge. For example, in terms of market, international market and growth had advantage over local market and growth in terms of technology. Cloud native technologies had the advantage over traditional ones and so on. In terms of benefits that we observed last year, we have rejected 16% of all the opportunities that came our way. Those were all non-strategic opportunities, and very soon people started noticing this new mindset. You could feel the energy among people and see the shifts in the conversation. Team leads would ask, is this really something that we should be working on? And many times they were right, we shouldn't.

00:12:35

After we have improved the work on a team level and after we focused our efforts on what is truly important, we noticed a strange dysfunction. There were situations in which we have committed to a project and then after some time we noticed that the work hasn't even started. Opposite situations also happened. We noticed that we would start working on a new project, although officially confirmation hasn't yet arrived from the client, it was obvious that we had coordination issues in the delivery process and that we are missing that coordination layer. The flight level two, the solution we have formed another group of people called the delivery board and their task was to facilitate the coordination with and between teams, so no work falls through the cracks from initial opportunity to final delivery. The delivery board also gets together weekly every Monday for 30 minutes after the portfolio board, and some people are part of both boards and they provide additional context for coordination.

00:13:36

So how does a typical delivery board session look like? We use one large GitLab board to track all the work. The board is not complicated. It tracks an opportunity from creation through sales phase, then through delivery, and finally it's closed. The board is visible to everyone and when the sales phase is done, meaning we got the job work item goes into staffing, column teams look at this column and they pull new work items according to their capacity load and current skillset. Each work item is tagged with several tags indicating the size, the client, the team that has pulled the work item and so on. We also have a special tag called supervision, uh, and we tag work items that we consider risky and we want to keep our eye on them to prevent any possible problems, so we just filter the board by the supervision tag and then we have a conversation around those work items.

00:14:35

In terms of benefits, we noticed the improvement in how work gets pulled to the teams. No longer did the work fall through the cracks and the flow was much better. There were significantly less dramas on the project because we knew where to focus our attention and we had much better visibility and situational awareness. These three levels are not isolated. There is a continuous feedback between levels. Strategic guidelines are shared from flight level three to flight level two and one all the way to the teams. The feedback goes in the opposite direction as well. Teams share their insights from the field and many times they recognize unhealthy environments and sketchy technologies that we should stay away from. This input is valuable to portfolio board in adjusting our criteria for evaluating opportunities. New opportunities falling into this category won't get through, so it is like a self calibrating mechanism.

00:15:33

10 years ago, we were contractors doing what we were told, although many times we knew there was a better way to generate the value. Understanding that delivering value to the customers is not about typing the code faster, but about understanding the needs and getting to those needs helped us move from what Marty Kagan calls mercenaries to missionaries. We are now actively participating in the process of designing the product or service together with our clients. Participating from the beginning in this design process helps us from a technical point of view in designing a better system architecture, but also from organizational point of view in planning the activities. The latter part is especially important because it directly influences the flow. Now that we are actively participating in the design and implementation process, we can have sufficiently elaborated, prioritized and transparent backlog by doing this for every project and every customer that we work with, we got a clear picture of our complete portfolio and suddenly we didn't feel like kept in the dark by our clients, but of course it takes two to tango.

00:16:43

So how come that our clients change their relationship with us and let us participate in their design and planning process? One reason certainly is that we want their trust, but the other more important reason is the message that the whole community is emitting. Past years, and I learned it best by talking to Courtney Kisler about how good relationships between client and consulting companies should look like. Courtney formulated three key principles from client organization point of view trust is the most important here. We are not coercing our clients to let us in the design and planning process for our own benefit. Instead, we are bringing to the table our experience from previous similar engagements, so what worked well, but also what didn't work well and which mistakes we absolutely shouldn't repeat, and I can tell firsthand that whenever we had such relationship with the client organization, the amount of friction in the delivery was close to zero and the flow of value as well as the client satisfaction was high.

00:17:43

Going back to the beginning of my story 10 years ago, we believed that service organizations grow their business solely by increasing their headcount and the amount of work that they do. This is not wrong, but it's more nuanced. It's popular to express good practices in the form of a manifesto. So I try to do the same to express the values that service organizations should live by just like Courtney did for client organizations. You'll notice here that I stole the structure of one very popular manifesto in hope that this one will gain the same popularity. So the first value is strategic work over just more work. As I said, it is more nuanced. Service organization can definitely grow by taking on more work and work, but it's much better to take on strategic work. Sometimes you don't need to take more work. You just need to eliminate existing non-strategic work and replace it With strategic work.

00:18:38

It's like going to the gym to get stronger. You don't need to gain extra weight. You need to replace the fat weight with muscles weight, and even if that means that your total weight would actually stay the same, the second value is flow over headcount because sure, adding extra headcount could be a way for a service organization to do more work. Although I'd be careful here since Fred Brooks taught us differently, but even if increasing the headcount leads to more work being done, it is still better for an organization to do more work by improving the flow instead of increasing the headcount. Third value is missionaries or mercenaries because service organizations are here to help client organizations achieve their business goals through consulting or outsourcing part of work. Either way, service organizations should be in the game deeply engaged, understanding the real needs and pains of client organizations and actively looking for ways to help only through such behavior will client organizations feel the trust drop their guard, let them come closer and plan together, which is, as we saw earlier, an important factor in improving the flow.

00:19:50

The last value is community over the zero sum approach. I feel like there is much more competition among service organizations than among product organizations because product organizations use tangible things like their product features to differentiate themselves. While service organizations use intangible things like skills, knowledge, and experience, and these are much easier to fake than concrete product features that you either have or you don't have. Consequentially, all service organizations are allegedly fantastic and all of them can allegedly pull off any project perfectly. This inability to differentiate drives service organizations to hide every advantage, close themselves and not share their experience. The moment we start treating our industry as a zero sum game is the moment in which we all lose not only service organizations but their client organizations as well.

00:20:49

When you look at these values, you will notice three different perspectives. The first perspective addresses the organization itself. The second perspective guides the organization's relationship with its clients, and the third perspective guides organization's relationship with the ecosystem in which it operates. Our experience shows that for a service organization to grow sustainably, it needs to take into account all of these three perspectives. Leaving out any one of these perspectives can still yield short-term good results, but the service organization won't succeed in the long run. It's been quite a ride for us so far and we want to draw more and better insights from all the process data that we are gathering. There are already some telling numbers, for example, overtime still happen, but their amount is consistently dropping year over year. Just last year we had a drop of 32% compared to the previous one. The amount of time invested in learning has increased by 12%, and this tells us that by managing the flow, we have freed up some of our capacity. The number of new initiatives on strategic markets has increased by 224%. This is amazing, and this tells us that we have succeeded in focusing on our strategy, which again means that flight level three is doing its job well and we are looking forward to the results of these initiatives. At the same time, our service revenue grew by 17%, and this tells us that the capacity wasn't freed up at the expense of business goals.

00:22:26

I'd like to ask my colleague, KH Musa, who is CTO at Cross to share his view on benefits caused by improving the flow Reha.

00:22:34

Thank you, Ivan. As a service organization, we are susceptible to high work variability. Historically, this work variability has caused us a lot of problems in terms of increased VIP missed deadlines, high context switching, burnouts, lack of select time for improvement, and the decrease in applying foundational technical practices by better controlling what is entering our production funnel, we have eliminated the work not aligned with our strategy and redirected that capacity to our strategic projects, improving our delivery process and building our capabilities. Managing flow is not something that can be done centrally. It's necessary to recognize all organizational levels on which the work flows and grow leadership on all those levels. A leadership that is flow Uber and actively manages it, this is not easy, but when you succeed, the results are staggering. In our case, better flow management released enough capacity for new strategic directions, and that further resulted in over 200% increase in the number of new initiatives on strategic markets.

00:23:45

In terms of help that I need, I would really like to get help and talk more about your experience in gathering value stream metrics and drawing insights. If you have concrete experience or if you're just starting, I would love to talk. Thank you all for being here today and I'm looking forward to future conversations.