On the stage at Prodacity, Mik Freedman from Tanzu Labs shares his insights on the culture of continuous improvement in software development. Drawing from his 20 years of experience in software and service industries, Mik delves into how creating exceptional customer experiences in software parallels hospitality services. He emphasizes the importance of building software that evolves and adapts continuously, highlighting lessons from the development of the B17 Flying Fortress and its impact on modern software practices.

Mik Freedman (00:20):

As Bryon mentioned, I work at a place called Tanzu Labs, which was formally called Pivotal Labs, a consulting organization. I wanted to talk a little bit about how I got onto this stage and what I've done in my career. Just to give you a bit of context of why I might be able to talk about these things.

(00:37):

I've been in software 20 years and before that I was in hospitality - service industry. Most of the 20 years of software I've been a consultant. And so really, thematically, working in service has been what I've done and what I do. And part of that work, or a mainstay of that work, is creating great experiences for customers or clients. And the hospitality work really informed the way that I operate inside the software industry as well. And I'm excited to, as I get further in my career, to really draw that similarity or comparison to the services industry.

(01:20):

There's a great book by the front of house manager or the original front of house manager of 11 Madison Park called, something I can't remember...but...it is Unreasonable Hospitality. Thanks Siobhán. And I highly recommend everyone pick that book up because it really talks about this idea of experiential difference in great service, and it's applicable to managers and teams in any industry. So I highly recommend picking that book up because I think it really speaks to this idea of people remember how you make them feel. We've heard so many great talks this morning on building great platforms for government, how to get continuous authority to operate Rob closed things out with a big slide, or multi-slide build, on empathy. And it can't, can't be overstated that that's one of the most important aspects of what we do when we work with people who we need to bring along for a journey. Listening, being there, empathetic and understanding that the way that person is experiencing what you are doing or the change you'd like to affect is just as important as the work itself.

(02:34):

So, that's me. You can find me on LinkedIn, but you'll have to find me with my mom's version of my name, which is Michael. You have to say it like a Australian as you type it in, it'll be fine. I work, as we all mentioned, as me and Bryon both mentioned, I work at Tanzu Labs and I think one of the things for those of you who don't know about this organization, it's a consulting firm. And the unique value prop to me is the fact that we work with people to solve problems. I think a lot of folks, in government especially, experience the vendor providing a thing, a widget, a product, or a service, or providing advice on how one might do the implementation, but rarely working with a team integrated to solve a problem. And so we take this approach of pairing in, or creating a balanced team. We've heard balanced team a lot this morning - to solve a problem. And doing that together, with people, is what makes the Pivotal Labs experience I think so special. And we ship that working software, that we build together, into production.

(03:56):

So what is great software development in my mind, right? So over those years of service, I don't know anything unequivocally. I don't have 36,000 pieces of research to reflect on over 10 years. I just know what I've seen work for me and for my customers. And I would say that we do a lot of talking about methodologies, and systems of approaching problem-solving, and these things go in and out of fashion, and people get really caught up on names, practices, tools, techniques, approaches. And what we're really trying to do is codify or capture what makes that lightning in a bottle work that one time on that one team that was really great. But I think at the end of the day, if you were to reduce it all down, all these different tools and techniques, I would say that instilling, nurturing, and growing a culture of continuous improvement is great software development - small incremental change, Kaizen, is the way that you affect large change inside an organization or a team, and that leads to the high performing teams that I think we're all striving for in our agencies or in industry.

(05:16):

But, this is not a new problem. I think in the software industry, we often lead ourselves...we often think that we're solving some new paradigm or paradigmatic problem, right? It's a new industry, it's never been done before. Infinitely malleable, I hear a lot. These are the reasons why we can't apply the same things we learned in the past, but I don't think that's true. In fact, I think there are many great examples of small, highly focused teams, high-performing teams, with strong collaboration. If you remember the two by two, we saw before on team types that have been tasked to solve real problems either in industry or for the government. And I think we can learn a lot from them. And so today, I'd like to talk a little bit about the same way that the General [Groen] spoke about the Lancers, but from a counterpoint position to talk a little bit about the B17 Flying Fortress from World War II.

(06:12):

So I just want to give you some facts to set the scene on this aircraft and the aircraft industry based in Southern California in the thirties. In 1934, the US Army Air Command put out essentially an RFP for a new multi-engine bomber. And that was only 31 years after the first powered flight in Ohio, so not very long. You could say - I definitely draw a parallel there to the sort of nascent quality of both the software industry and the aircraft industry at that time. And the RFP was really quite simple. It was a multi-engine bomber. The bomber had to carry a useful bomb load. I don't know what that means. 10,000 feet in the air, 200 miles an hour for 10 hours. Those were the requirements that the Army set forth so that vendors could compete in a design competition.

(07:04):

Fun fact, I don't know how fun this is, but we'll go for it...fun fact, the original B17 couldn't fly in the first design competition because the pilot had incorrectly not disengaged a landing, a ground control safety device, leading to the crash of the aircraft and the death of some people on board. And that incident was actually the birth of the modern checklist. So from there, that's where you count that form forward because people started realizing the systems were too complex for the pilots to keep all in their heads. So that was kind of cool, I thought. So yeah. So we had this really simple design competition and the B17 was the one that eventually won out despite crashing in the design competition plane.

(07:53):

I wanted to talk about the outcomes that were achieved over the course of the war related to this aircraft and also the aircraft industry as a whole. Between...these dates mostly fall between 1940 and 1943/1944 is when these stats were from. But in the beginning of the war, the aircraft industry was producing 3,000 odd planes a year, and by the end of the war that was up to 43,000. The really cool thing is it wasn't just about putting more people to work, it was about increasing personal productivity. So you can see here this stat of airframe pounds per worker increased threefold over that same timeframe. So I think they were doing like 127 pounds per worker or something by the end of the war, which is really cool. That's for the aircraft industry as a whole.

(08:44):

For the B17, specifically, the cost in the Lockheed manufacturing plant...so Lockheed was producing the B17 for Boeing by the end of the war...reduced from $268,000 to $136,000. So a significant cost reduction if we say that material and logistics helped the Allies win World War II, this is a really great example of that.

(09:10):

Tanzu Labs, Pivotal Labs currently is working with a state agency, for a large state in these United States, and honestly, we're posting sort of similar, or I think to be similar, types of really exciting productivity and cost savings statistics. I think for MVP to production, we heard someone earlier today talk a little bit about measuring time to production in years, right? This agency is no stranger of that concept and we're able to work with them to get these MVPs out in 14 weeks. Production deployments are up one to three per week, utilizing, I'm sure, the techniques that Nathen was talking to us about from DORA, are a significant cost saving reported to the agency.

(09:56):

And I think this fourth point is the most important one. 30 people have worked with us in this pairing model to continue that work at the agency. So we're bringing in... who here has read Jen Pahlka's book, couple of people, two people, alright? We're bringing in this idea of policy as implemented through software, and saying this agency now needs people on its staff that can produce the software because the software needs to grow and continue to respond to changes in policy, and changes for that agency, that state agency. So 30 people are on the full-time staff outside of the vendor system, doing that work for the state government, which is really exciting.

(10:44):

The commonality that I draw between the B17 example and the state agency is this culture of continuous improvement. This belief that things can continue to get better and ultimately, really the thing we're really tracking are the outcomes. Can we deliver the outcomes? The software is incidental. Building custom software is a lot of fun. It's really great when you've got a blank piece of paper, but you need to know that you're solving a real problem. And I think in both cases we can see that the management structure around the teams that were doing the work allowed for the continued evolving of both the production system and the product itself. Many, many versions of the B17 were produced during the war and, also, the production of those versions was improved dramatically.

(11:39):

H"ow did these organizations, how do these organizations do this? And I think the real key thing here is an acknowledgement, and this sounds trite to say products are never finished," but it is really something that is worth repeating often and early because it's easy to think about the B17 as being a plane that was designed once and then built increasingly quickly over the course of the war. But in reality, that plane had to continually improve. The production system, of which the plane was only a part, was complex, and received feedback, and incrementally improved. The systems that were designed for the state agency and also for the aircraft were welcoming of change - open to change. And that's a really hard thing to get right, and we're going to get into that in a little minute. And I think the third point here is especially important for those of you who may have had some success - limited success - with a smaller team utilizing new modern approaches and techniques and are struggling with the concept of how to scale that out to an organization. Leaders and teams can integrate the learnings from those early successes.

(12:54):

So...never finished. Let's get a bit, let's double-click. No one says "double-click" anymore. Do they? Really? Have you noticed that things go in and out of fashion in corporate speak? Planes weren't finished. They were complex production systems. One of the things that were, one of the really cool things that were introduced to the production system was bringing women into the workforce during the war, which led to several ergonomic improvements to the manufacturing process, which increased productivity for everyone. So the diversity of the workforce lent itself to actually driving better outcomes for the warfighter, and for all the mechanic crews, and so on deployed in the field.

(13:37):

I think in software we often pay lip service to this idea of software is living, but we don't always see the structural changes that are necessary to be made to have that actually happen. Funding models will fund the development of software or procurement of software more often than not, and rarely fund the maintenance of that software in the same way. In fact, the idea of maintenance itself is kind of selling the whole process short. We think about the B17, again, it's that living production system that had to exist during the entire course of the war that we need to do when we build software for citizens or for Warfighters or whomever our constituent population is.

(14:23):

In my time at Pivotal Labs, Tanzu Labs, and elsewhere, less successful customers, customers who haven't always achieved the greatest success, often believe that software can be finished and they measure that completion often on the wrong metrics - not outcomes, but units delivered, widgets delivered, whatever it is. There are some failures to understand how to measure a system that is living and growing. And I think the other thing people - that some customers tend to not do really well here, is forge an emotional connection between the development teams, the app teams, and the problem being solved.

(15:08):

So, we talk a lot in industry and especially at this conference about user-centered design, about integrating feedback from the field, but then we sometimes stop short of including the actual engineers in that process. The cross-functional balanced teams that folks have talked about in earlier talks, still often sometimes end up with silos inside that team. And what I've seen to be really successful is getting engineers in the room with users, hearing from that Department of Education student about the struggles that they had enrolling in selective high school changes the way that people approach and how they're motivated to deliver that software. Welcoming of change. Building that system that can integrate internal and external feedback is super important. It

(16:09):

In 1942 alone, the aircraft industry accepted 13,000 recommendations from the factory floor, and a third of those recommendations were acted upon and led to the improvement of the production of aircraft. The user experience discipline itself traces its origin back to the B17. Yet another user-experience design error was leading to pilot error during landing - selecting flaps, selecting the landing gear...the toggles looked the same and they were next to each other. Fatigued pilots coming back from the war would accidentally turn or flick up the landing gear and land on the belly of the aircraft, instead of selecting flaps. And instead of blaming it on pilots, they eventually just redesigned the console. And so that story is like the apocryphal story of working with good ergonomic and user design.

(17:10):

Good software teams do this by integrating feedback from a wider variety of sources on a more frequent cadence. When I think about the tools and techniques that we often talk about at Pivotal Labs and elsewhere, they fall into this category, for me, of internal feedback. Why paired programming? Am I an XP zealot? Well, maybe, but I don't really care if you do XP. I don't care about pairing. What I care about is fast, quick feedback, being integrated in the system and adjusting the course of the software being produced. Paired programming is the ultimate implementation of fast feedback for engineers and for other people who practice a discipline. And I think cross-functional teams or balanced teams fit into that same category.

(17:53):

We talk about the real value prop of a cross-functional team is shortcut decision making, I have my product manager sitting cheek-by-jowl with the engineer, they're doing the thing, the trade-off conversation, which is at the heart of every great software team, much more quickly if they're co-located, virtually or otherwise, than they would have been doing it over email. So creating those internal virtuous feedback loops is super important. And this is for me, was the interesting, I think at least for me, it was interesting, this idea that the external feedback that comes into the system, which is just as important, serves a different function. So I've got internal feedback often fixing the production, the efficacy of the production line of the widget. The widget in this case happens to be software. And then we have the external feedback dictating the improvements in the actual product itself, which I think is handy.

(18:56):

Leaders and teams integrate learning. What do you really need to get this done? In both cases, aircraft industry in the 1930s, our state agency in the current year, we had workers who care, mission-aligned workers, emotionally connected to a real problem. But more importantly, I think, or maybe not more importantly, but complementary, we had leaders who listen, open-minded management that were able to integrate learnings, reevaluate principles and value systems of the organization, to make that change more permanent, more durable. Thanks for that word, Paul. Durable. I like it.

(19:40):

These two things are what's needed to drive those systems that are open to change, and to continue to nurture this idea that software or good outcomes are never finished.

(20:00):

This slide is real long. It's a lot of stuff...of things that I've seen that I think are pitfalls, things that trip people up, but I wanted to really bring it down and focus in on one thing. Does anyone here have teams who build software for a living? Has anyone had some limited amount of success with applying new techniques and approaches in a small team? And then you've successfully rolled it out to the entire organization and everything's great?

(20:34):

Not as many people. Jason said "yes." Alright. It can be really hard to take what you've learned from an initial success, or series of MVP successes, and integrate that learning into the system of the entire organization. And I think the thing that...the reasons for that include the fact that initial successes are often not grounded in reality, and leadership doesn't internalize what made those wins possible, and we failed to expand upon our stakeholder group in a meaningful way. The system, if we don't change this, and then Rob covered this great in the continuous ATO talk. I apologize for coughing into the microphone. Rob covered this really well when he talked about bringing in the compliance, the technical assessors, and all these different people, but I can't overstate this enough. The system will punish innovation, and people will get their hand slapped, or get burned out, or get reprimanded, for trying to change things.

(21:45):

Nathen's talk this morning mentioned someone who said, "I'm here to see you fail," right? I don't know. It's wild. Why are those people, individual people, acting the way that they do? Is it because they are malicious? Or is it because the system is designed in a way that's delivering the wrong outcome? So I think bringing in groups of stakeholders who you may not consider to be critical to your application, and bringing them along for the journey instead of telling them we're changing things is really, really important. HR, Finance, Audit and Compliance, Regulatory Assessors, whomever that may be, are all empowered to stop you in your tracks. If you can't change incentives, you can't change the way that people are paid, you can't change the way that projects are funded, it's going to be challenging to recreate the bubble that you created for that MVP where you suspended the disbelief, and roll that out onto teams and teams of teams.

(22:57):

As I mentioned earlier, I just really think that getting wrapped up on which methodology or which version of SAFe you want to implement is not the best way to have this conversation. If we would've come out strong and said, "it's only this way" or "it's only that way," I think it wouldn't be doing good software development service because I've seen it, and I'm sure you all have seen it, in pockets despite whatever methodology is currently deployed. Great teams of people can operate well inside a waterfall environment. Not so great teams of people will still operate poorly in a highly agile and collaborative environment. Getting people together and speeding up those feedback loops will highlight or improve whatever's going on. But whatever it is, you'll know about it. My wife was also a consultant once, and she worked with a customer who, by the end of the engagement, the time that we were working together, he said to her, "Ariel, now I know what it means to develop software. I've been doing this with you." And she said, "what do you think?" He said, "I hate it." "What do you mean you hate it?"

(24:08):

Well, he hates it because now he understood what it actually takes to get software into production, and he much preferred throwing it over the wall to someone and saying, you deal with it. So there are ways...there are ways and means to get this to happen, but ultimately the thing we're trying to do here is create a team of people who are dedicated to improving the delivery and behavior of software that solves a real problem. Meaningful connections between workers and the people that they're trying to help will go a long way to ameliorating any stress you might have around the system. And then acting, rather than, what was the great quote? Like acting - and then that drives the way that you think, instead of thinking? I really liked that, mangled it, but check the slides out from earlier. It's worthwhile.

(25:03):

So today, what...I think we've heard a lot about continuous improvement from many different talkers, speakers, excuse me, what can you do today?

(25:12):

If I could do only one thing on a team to get them on this path, it will be the last thing there - retrospective. So it feels played out and it feels hackneyed maybe to say, retrospective is important. I don't really care about any other tool, or technique, or process to develop good software. If you have this one, you can go and rediscover all the other things again.

(25:38):

So to that, with your team this week, if you have a team or if you're on a team, I am guilty of forgetting to do this on my own team, and I think it's worthwhile to think about revisiting this concept, coming at it with an open mind, listening to people, integrate learnings and make small incremental changes.

(26:03):

What do you guys want to do for a minute? Do want to talk about other stuff? Anyway, thanks very much for listening to me talk. My name's Mik. Have a great rest of your conference.

‍