Ivan Krnić

[00:00:13.660] Hello everyone. It's great to be back at DOES. My name is Ivan Krnić, and I'm Director of Engineering at CROZ, a professional services company. We don't base our business model on products that we sell; instead, we work with our clients and help them deliver the best possible software solutions that enable them to reach their business goals.

[00:00:34.280] Today I'll share our experience of managing flow and what good that brought us. There have been a lot of talks on the topic of flow and generally how organizations work, but I found that the overwhelming majority of these experiences and case studies come from product companies. I believe this world needs more experience sharing by service-oriented companies so service-oriented companies can grow, and also to facilitate better collaboration between client and service organizations for the benefit of the whole industry.

[00:01:07.040] Ten years ago, we were convinced that service organizations build their business by increasing the amount of work that they do. If a service organization wants to increase its revenue, it can only do that by increasing 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 analysis of what needed to be done. To provide a binding proposal, we had to figure out the architecture, do serious estimation, draft the proposal, and do all the administration.

[00:01:49.100] All this work took precious time from our senior engineers, who, while drafting proposals, didn't work on their already contracted projects for existing customers. Since previous proposals introduced commitments on project duration and delivery dates, it was pretty clear our teams were in for long working hours and working weekends.

[00:02:10.930] This is part of a blog post written on our 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 the 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."

[00:02:35.740] This short paragraph tells so many things. The first word, "unutilized," implies something bad is happening in the organization. A 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 formed a new team specifically for that project, and once the project ended the team was dismissed. There was no sign at that point of long-lasting, stable teams.

[00:03:05.340] Another observation: what kind of planning did we have if we had to change our plans so dramatically in the course of one week? Yet another observation: CPU working at 120% was actually a desirable state, where CPU referred to the development department. We had a classical resource-oriented mindset: people are resources, and as such they have to be fully utilized.

[00:03:31.400] All this resulted in well-known consequences. Overburden gave way to burnout and people losing motivation. Exploring new technologies didn't get adequate priority. At some point, we ended up with a machine working like crazy in high revs, delivering features 100%, but also innovating 0%, which was sad.

[00:03:51.700] It's easy sometimes to find yourself in a vicious cycle, not knowing that things can be different. 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.

[00:04:20.541] Burnout was something we noticed early on, but burnout was a consequence, a symptom that we knew wasn't healthy. We didn't understand the theory behind it and what to change. Our first realization of the detrimental mechanism underway in our organization came in 2014 after our annual QED conference, where Niklas Modig gave a keynote talk called "This is Lean," named after his book. In this talk and in the book, Niklas shared his learnings about lean mindset, especially the difference between resource and flow efficiency. I read the book soon after the conference, and it became very obvious that flow, or better said the lack of it, was the problem we had. Everything we did from that point on was in the service of improving flow.

[00:05:11.600] Flow is important in all organizations, but especially so in service organizations. 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.

[00:05:33.320] 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 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, experience a lot more variability in their work pipeline, and therefore struggle more to standardize and improve work processes. This is a huge risk for flow.

[00:06:18.356] Service organizations should therefore invest extra effort in keeping the flow healthy. The opportunity pipeline shouldn't be empty, but it also shouldn't be completely full. The organization needs enough slack to help clients when they really need it and to sharpen its skills for the future to come. Balancing between those two states is an art that happens on several levels in the organization and requires constant fine-tuning.

[00:06:45.416] These levels are best described by Klaus Leopold as flight levels. He argues that work coordination happens at three levels in the organization. The lowest and most operational one is flight level one, which relates to coordination of work in a single team. The team uses some approach, typically Kanban or Scrum, to organize itself and coordinate activities. Although work inside the team is coordinated, the inflow of work to the team is not coordinated and arrives by push from many directions. The team usually has more on its plate than it can handle. Implementing flight level one gives the organization some improvements: work coordination and visibility improve team efficiency. However, since inflow is not coordinated, there is a risk that the team will be working on the wrong things. Since work comes from different directions, there will be many expedite requests and a lot of reprioritization.

[00:07:50.056] The next level of work coordination is flight level two. This level coordinates multiple teams to get the work done. There is a central and prioritized backlog for teams, which means fewer expedite requests and reprioritizations. Flight level two manages work on the value stream level. It optimizes interaction between teams to deliver value efficiently, ensuring that the right thing gets done across teams, but also at the right time and in the right order. Flight level two ensures the project or product increment gets done.

[00:08:27.616] But an 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. Focusing on single projects helps those projects end successfully, but in the grand scheme of things it can harm the organization if we are not carefully balancing all those factors.

[00:09:06.696] That's where 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 business goals.

[00:09:36.476] So how did we implement flight levels at CROZ? The first one we implemented was flight level one. We unconsciously started there because teams are where the rubber meets the road. Teams are where the feedback loop is shortest, and if anything goes wrong, you'll notice the sparks there first. We never mandated one specific methodology for all teams, but we did set up enabling constraints: we need a well-maintained backlog, good coordination in the team on who is doing what, planning ahead and respecting commitments. We also want to grow our skills, and we don't want to burn out doing all this. In essence, the work needs to flow.

[00:10:22.656] Some teams opted for a Scrum-like approach, while others opted for a Kanban-like approach. Any approach was fine as long as the team was in control of what it was delivering. We immediately saw benefits: better organization, fewer escalations, and teams were happier because they weren't jumping from one fire to another.

[00:10:45.176] The next level we implemented was flight level three. We saw the need for flight level three when we realized how much time and energy we had been wasting on drafting proposals and implementing projects that were, in essence, not strategic for our company. We needed to manage what was entering our funnel. We needed a mechanism for choosing which projects are strategic for our company so we could focus our energy on those projects, which also meant skipping non-strategic ones.

[00:11:17.396] We formed a group of people called the portfolio board. Their task was to evaluate all opportunities and stop those that are not strategic. The group gathers weekly every Monday morning for 30 minutes, goes through all new opportunities created in the CRM system, and approves them or rejects them. Approved opportunities are strategic ones that we choose to invest our capacity in. In the beginning it was a weird conversation: how do you choose what the company will work on? We all had some intrinsic understanding of such work, but we didn't have explicitly formulated rules. Soon after several sessions, some core criteria started to emerge. In terms of market, international market and growth had advantage over local market and growth. In terms of technology, cloud-native technologies had advantage over traditional ones, and so on.

[00:12:11.648] In terms of benefits, last year we rejected 16% of all the opportunities that came our way. Those were all non-strategic opportunities. Very soon people started noticing this new mindset. You could feel the energy among people and see 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:36.148] After improving work on the team level and focusing our efforts on what is truly important, we noticed a strange dysfunction. There were situations where we committed to a project and then, after some time, noticed the work hadn't even started. Opposite situations also happened: we would start working on a new project although official confirmation hadn't yet arrived from the client. It was obvious we had coordination issues in the delivery process and were missing that coordination layer, flight level two.

[00:13:08.668] The solution: we formed another group of people called the delivery board. Their task was to facilitate 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. Some people are part of both boards and provide additional context for coordination.

[00:13:36.188] A typical delivery board session uses one large GitLab board to track all the work. The board is not complicated: it tracks an opportunity from creation through sales phase, through delivery, and finally to close. The board is visible to everyone. When the sales phase is done, meaning we got the job, the work item goes into the staffing column. Teams look at this column and pull new work items according to their capacity load and current skill set. Each work item is tagged with several tags indicating size, client, the team that pulled the work item, and so on. We also have a special tag called Supervision. We tag work items we consider risky and want to keep an eye on to prevent possible problems. We filter the board by the Supervision tag and have a conversation around those work items.

[00:14:35.648] In terms of benefits, we noticed improvement in how work gets pulled to teams. No longer did work fall through the cracks, and the flow was much better. There was significantly less drama on projects because we knew where to focus our attention, and we had much better visibility and situational awareness.

[00:14:56.368] These three levels are not isolated. There is continuous feedback between levels. Strategic guidelines are shared from flight level three to flight level two and one, all the way to the teams. Feedback goes in the opposite direction as well. Teams share 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 the portfolio board in adjusting criteria for evaluating opportunities. New opportunities falling into this category won't get through. It is like a self-calibrating mechanism.

[00:15:33.228] Ten years ago, we were contractors doing what we were told, although many times we knew there was a better way to generate value. Understanding that delivering value to customers is not about typing code faster, but about understanding needs and getting to those needs, helped us move from what Marty Cagan 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, and also from an organizational point of view in planning activities. The latter part is especially important because it directly influences flow. Now that we are actively participating in design and implementation, we can have a sufficiently elaborated, prioritized, and transparent backlog. By doing this for every project and every customer we work with, we got a clear picture of our complete portfolio, and suddenly we didn't feel kept in the dark by our clients.

[00:16:41.528] But of course, it takes two to tango. How did our clients change their relationship with us and let us participate in their design and planning process? One reason certainly is that we won their trust, but the other, more important reason is the message the whole community has been emitting over past years. I learned it best by talking to Courtney Kissler about how good relationships between client and consulting companies should look. Courtney formulated three key principles from the client organization point of view. Trust is the most important here. We are not coercing clients to let us into the design and planning process for our own benefit. Instead, we bring to the table our experience from previous similar engagements: what worked well, what didn't work well, and which mistakes we absolutely shouldn't repeat. Whenever we had such a relationship with the client organization, the amount of friction in delivery was close to zero, and the flow of value as well as client satisfaction was high.

[00:17:43.568] Going back to the beginning of my story: 10 years ago we believed service organizations grow their business solely by increasing headcount and the amount of work 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 tried to do the same to express the values that service organizations should live by, just like Courtney did for client organizations. You'll notice I stole the structure of one very popular manifesto in hope that this one will gain the same popularity.

[00:18:18.648] The first value is strategic work over just more work. A 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 need to eliminate existing non-strategic work and replace it with strategic work.

[00:18:50.708] The second value is flow over headcount. 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. Even if increasing headcount leads to more work being done, it is still better for an organization to do more work by improving flow instead of increasing headcount.

[00:19:15.248] The third value is missionaries over 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 trust, drop their guard, let them come closer, and plan together, which is an important factor in improving flow.

[00:19:50.768] The last value is community over the zero-sum approach. I feel there is much more competition among service organizations than among product organizations, because product organizations use tangible things like product features to differentiate themselves, while service organizations use intangible things like skills, knowledge, and experience. These are much easier to fake than concrete product features that you either have or don't have. Consequently, all service organizations are allegedly fantastic, and all can allegedly pull off any project perfectly. This inability to differentiate drives service organizations to hide every advantage, close themselves, and not share 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.748] When you look at these values, you will notice three different perspectives. The first addresses the organization itself. The second guides the organization's relationship with clients. The third guides the 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 three perspectives. Leaving out any one can still yield short-term good results, but the service organization won't succeed in the long run.

[00:21:24.888] It's been quite a ride for us so far, and we want to draw more and better insights from all the process data we are gathering. There are already some telling numbers. Overtime still happens, but its 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%, which tells us that by managing flow we have freed up some capacity. The number of new initiatives on strategic markets has increased by 224%, which tells us we succeeded in focusing on our strategy, and that flight level three is doing its job well. At the same time, our service revenue grew by 17%, which tells us the capacity wasn't freed up at the expense of business goals.

[00:22:26.148] I'd like to ask my colleague, Krešimir Musa, who is CTO at CROZ, to share his view on benefits caused by improving the flow. Krešo?

Krešimir Musa

[00:22:35.108] 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 WIP, missed deadlines, high context switching, burnouts, lack of slack time for improvements, 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.

[00:23:13.638] 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: leadership that is flow-aware 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.608] 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 are just starting, I would love to talk. Thank you all for being here today, and I'm looking forward to future conversations.