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.
Director of Engineering, CROZ
Hello, everyone. It's great to be back at. Does my name is I K 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 in 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.
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 grow 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.
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 communications 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.
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 <inaudible> yet another observation CPU working and 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 gateway 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 ways. What we did since the dark medieval 2012 is influenced by so many ideas and people that it's 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 Q E D conference, where Nicholas Munich 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 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 new ones because of this narrow focus on products and full control over roadmap, product organizations, experience less variability, which 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 come balancing between those two states is an art that happens on several levels in the organization and requires constant fine tuning.
These levels are best described by CLA 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 command 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, work coordination in the team and improve 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 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, 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 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. So focusing on the single projects will certainly help those projects and successfully, but in the grad scheme of things, it can actually harm the organization. If you are not carefully balancing all those of formation 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.
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 if everything 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 need, 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 scrum like approach while others opted for Cameron 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.
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 ensure we needed a mechanism for choosing which projects ares 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-strategic 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 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 interest 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 of local market and growth in terms of technology, cloud native technologies had the advantage of 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 nonstrategic 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, 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 clients. 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.
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 than through delivery. And finally it is 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 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. 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.
10 years ago, we were contractors doing what we were told. Although many times we knew there was a better way to generate away 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 Kegan 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. 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 wonder 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 Kissler 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 worked, 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. Going back to the beginning of my story, 10 years ago, we believed that service organizations grow their business solely by increasing their head counts 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, any 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. 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, we actually stay the same. The second value is flow over head count because sure, adding extra head count 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 head count 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 head count. Third value is missionaries. Our 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. 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 our client organizations as well.
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 group by 17%. And this tells us that the capacity wasn't freed up at the expense of business goals, I'd like to ask my colleague MI MUA, who is CTO at cross to share his view on benefits caused by improving the flow.
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 V I P missed deadlines, high contact switching, burnouts, lack of select time for improvement and a 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 workflows and grow leadership on all those levels. A leadership there is flow over and actively manages it. This is not easy, but when you succeed, the results are staggering. In our case, better flow management released in enough capacity for new strategic directions. And that further resulted in over 200% increase in the number of new initiatives on strategic markets
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 a concrete experience or if you are just starting, I would love to talk, thank you all for being here today, and I'm looking forward to future conversations.
Unlimited users from organization
Gene Kim's Shared Services Playlist
Breaking Traditional IT Paradigms to...
Ralph Loura, HP Enterprise Group; Olivier Jacques, HP Enterprise Group; Rafael Garcia, HP Enterprise Group