BGLS5E1 – Software Horror Story #1 – Everyone Needs a Reservation

In This Episode

• Executive alignment
• Realistic (not optimistic) estimates
• Transparency of promises made

Transcript

Tom Cooper 0:00
When it comes to planning our roadmap these days, we just pick the client, we want to disappoint the least. No one system for setting priorities has ever lasted more than one quarter. When we work with you, we need you to bring on more team members without slowing anything down.

Tom Cooper 0:21
Welcome back to the becoming a geek leader podcast.

My name is Tom Cooper, and I’m your host. This is the first episode of season five. And in this season, we’re going to tackle something a little different. For the past few years, I’ve been focusing my coaching and training work on helping software teams improve their performance. In one day, my friend Bobby Dewrell and I were talking swapping some stories. We realized there are a lot of teams out there who are struggling with the same kinds of problems.

I think it was Bobby suggested that we start telling these stories, and that’s the genesis of this season.

So because of Bobby’s input, today, I’m starting a new series on this podcast.

I’m calling these software horror stories, stories about teams and projects that simply could not go right. As I’ve worked with clients and collaborate with other experts like you, we’ve all seen these challenges.

In many cases, we’ve found solutions. And in some cases, we certainly didn’t. In each episode, I’ll introduce a situation and I’ll talk about what did or did happen, or could have happened to make things better.

During the season, we may even be able to hear from some of my friends who’ve lived through some of the same kinds of stories.

So why tell these stories, I mean, is it just to give you a cold shiver down your spine? Well, I’m hoping you’ll enjoy knowing you’re not the only one suffering through this.

Hopefully that you’ll be able to have some takeaways from these stories that will help you with your projects and your teams. Now, for many of you, this may be your first episode of a podcast from becoming a geek leader.

I want to introduce myself to you. Once upon a time there was a young boy who fell in love with technology. When he was 12, he bought his first computer with money he earned on his paper out.

He started learning tech and writing code when almost nobody even had a computer at home. And as a young professional every day, he worked on tech projects. Day after day, he watched project team struggle and projects fail. How could this be? These teams had smart people, they had good tools, they’re working on solvable business problems, these things should just work. He continued to wrestle with this problem until finally one day he discovered the core issue is that teams didn’t deal with the people part of the equation. They were great at the technical stuff, but they often failed at leading people through the process to get them to success. And he began to learn these things. And as he did his career took off. He moved up the ladder in large companies and in small companies. Eventually he was the VP of Products for a software as a service firm. But he wondered why didn’t anyone ever teach me this stuff. And so he decided to quit his job and do just that. For the last 10 years, he’s been working with software leaders and teams to help with people stuff like communication, delegation, resolving conflict and planning. And what he found was that these skills were critical to helping move forward the projects that people were just desperate to get done. So let’s get started with today’s software horror story.

Tom Cooper 3:24
I’m calling today’s story. Everyone needs a reservation to get in.

So this client, let’s call them entry, Inc. came to us in an unusual way. They already had a tool in production that they’d written to book reservations, users could go online or with an app, they could make a reservation for a particular facility.

And then they can make a payment.

Simple enough, right?

But, truth be told, it was not going well, the leaders of the company were pretty mad. They said engineering is way too slow. We think the CTO is failing us. And they told the CTO to go find some help to solve the problem, or they would solve the CTO problem. And so he hired us to help solve the problem. Interestingly, right after the contract was so signed by the CEO, he quit. The new CTO came on board, he realized that he had to work with us, even though he hadn’t picked us. That’s not a good place to start, is it? We sat down with engineering, and it was true, they did have problems. They were far behind, and they couldn’t give us a plausible plan for how they were going to catch up. Well, so that meant the company leaders were right, weren’t they? Not so fast. As we looked at the engineering process and the software team, overall, they were doing good work. They were using good tools. And generally they were following the kinds of processes that should have led them to good production of new software. But the customers and the internal stakeholders they weren’t happy. They said code quality is no good. Existing customers are getting mad because they’re not getting the features that they were promised new customers are coming on board. If that would have features work, and then the features would break it management said it took too long for new clients to come on board.

That just wasn’t working well.

People had this perception that the software was full of bugs, whatever that means.

When we dug in with engineering, and they said, every time they turned around product management and operations would bring them a different list of priorities.

Sometimes on a Monday, they’d say, drop everything and work on x. And Tuesday, they’d here Forget about X, we need to work on why they even told us, we can’t even schedule an entire sprint, because things are constantly changing, and pay off technical debt.

Who’s got time for that? We asked to look at the backlog. Man, was there a backlog.

But when we dug into the backlog, what we discovered was most of what was being called requirements.

They weren’t requirements at all, they were almost statements of ambition, make it easier to add new users.

And not only that, but there wasn’t a plan, even verify that the code that got written matched what the requirements were.

We sat down with product management, and they told us, our mission is to be a product company that that were in charge of deciding the SAS features that are needed, and that they were really frustrated because senior leadership kept demanding that they force in customizations, and that were specific to individual clients. And these facility owners would say, No, we have to have this feature or that feature.

And the senior leaders would say make it happen. Leaders would come to product management, they would literally say this is what has to get done. In fact, they tried to set up multiple times they tried to set up a system to to schedule or plan or think through product prioritizations. And product management eventually told us no one system for setting priorities has ever lasted more than a single quarter. They also said, sales, close the account, and then start talking to engineering. And they said we can’t create a predictable roadmap because we’re constantly having change. In fact, and I put this in the cold open when it comes to planning these days, we just pick the client, we want to disappoint the least. Now, at the core, the problem that our client felt they had was capacity that if they could just add additional engineers, they’d be able to catch up. And in fact, they asked us to come up with a plan where they could bring on new team members and train them and get them submitting working code. But there was a catch. They couldn’t afford to slow down development because they were already too far behind. So they wanted to double their capacity, but they didn’t want to have any impact on short term productivity. Man, I was going back over my notes as I was preparing this episode. And all these were ongoing challenges in this organization and so many other things that we just don’t have time to get into in this particular episode.

Now, if you hang on for just another couple of minutes, we’ll be digging into what we think would really have made a difference for this client. But first, there is no greater business investment than investing in your team. You’ve got an exceptional team, but you’re still struggling to unlock consistent, outstanding performance. You know, it shouldn’t be this hard to deliver value to your business. And we do to even the best teams struggled to build a culture of collaboration and high performance without clear communication and right planning frameworks. brightfield group, we deliver leadership coaching that empowers you and your software team toward peak performance. Our personalized coaching solutions help you build trust and increase efficiency across your development efforts. Head on over to bright Hill group.com To schedule a call today. So you and your team can break free from this rut of untapped potential and start delivering the high business value you know you’re capable of.

Tom Cooper 9:03
So let’s talk about how do you go forward in this kind of situation. And realistically the things that we’ve talked about so far in this episode have been a lot more about sort of the evidence of a problem than the core problem itself. I think about this when when you have the wrong strategy, there’s nothing you can do tactically, that’s going to make a difference. The reality is when it came to productivity engineering was thrashing. There were too many page faults, too many high priority items that were pushing back current work to the backlog and so it really doesn’t matter how many more engineers you add. If you keep overloading the work in progress, you’re going to have problems even if we were able to straighten out the inefficient curves in the engineering cycle to make a straight line path even if we could have improved software quality overnight. It entry Inc still would have been stuck they that wasn’t that the problem was related dirt directly to engineering or QA, it had much more to do with what they needed to do differently as an organization. There were three core areas that we think were fundamentally a challenge. One was executive alignment. at the executive level, they just were not on the same page about priorities and commitments. I love this concept that the first job of a leader is to define reality. The reality is this organization was pretty dysfunctional in the way that they were operating. And the company was growing fast. And they, they were trying to figure out how to scale the business as much as they could. But the key leaders in the senior part of the organization, they weren’t on the same page about what promises had been made to customer, much less what promises could even be kept. The measurements that were really driving the senior leaders had to do with closing sales and grabbing up the most facilities, they could, because they felt that strategically, doing a land grab was critical that they could get as many facilities as possible that that would be a big win for them. And different executives kept changing the priorities based on missed commitments, who’s yelling the loudest? Man, if you are setting your priorities by who’s yelling the loudest, that is not going to be a good day. And they didn’t. Also they didn’t have good information on which to make plans.

Since they didn’t have good information, they were flying blind.

Making decisions, when you don’t have good information, that is not a recipe for success, they just continued to make promises that the organization just had no way of keeping.

That is so devastating to morale, if you’re going to come to work every day, and you’re going to get hit in the head, you’re gonna fail, you’re going to be tripped, you’re going to be caught off guard to cut off the knees. That’s what was happening, because you could work really hard to try to get something done, only to find out that that was de prioritized. Or even that it was pushed so far back in the schedule, it might as well have been canceled. So that’s area one, executive alignment, the second area had to do with realistic estimates. Now engineering did have some skin in the game. But one of the things that was critically needed was to put effort into looking at what they were calling their backlog. And what was happening was engineering wasn’t getting good requirements. And these requirements, were not developer ready. They weren’t ready for developers to pick them up and start working on it. And so what was happening was development would get and requirements that would say, make it easier to onboard people. But what does that even mean? And and how would they figure out the complexity or approach that was needed, they were not able, based on the information that was in the tickets to create estimates, they couldn’t even create t shirt sizes for features. And if you want to make a plan about it, when you’re going to deliver it, you have to understand how complex is this? How hard is it going to be to build this and it doesn’t have to be an hours, but at least was some idea of the concept.

This meant that engineering was not going to be able to follow through because they had no idea when they picked up work, whether that work was going to be one hour, or 100 hours.

Finally, the third area that I think is critical in this situation is transparency of promises.

And support had made one set of commitments to customers.

Onboarding, the professional services aren’t they made another set of promises, a

sales had A third, and then

product management and then

engineering,

all these different commitments that were being made to each other, and to customer were floating around out there.

This was like a time bomb because every time somebody would turn around, there was an unmet need, or a promise that wasn’t being kept.

That is so frustrating, and, and frustrating for customer and frustrating to sales and everybody was mad.

That’s not a good way to be able to have a positive future for the organization.

Recognizing that these organizational groups inside the organization, they needed to begin collaborating, no one had a view of the priorities outside their group.

There was no process in place to help gain that visibility and to to really push forward for cooperation across the teams.

That’s one of the things that I think was foundationally a problem that when there was not communication across teams, it led to everybody kind of pointing fingers at each other.

Now until everybody could agree on on what was needed, and which I items on that list of what was needed were the highest priority.

They were going to continue this churn. And this, this is just going to leave them to so much thrashing and frustration and pain.

Now, of course, there were improvements in the engineering process, we could have made that starting with engineering saying, No, we do not accept that as a requirement because it’s not development ready.

Being able to define what would product management consider acceptable quality. And because none of that was defined, it was just going around in circles.

When you’re going in circles, figuring out how to go faster, turns out not to be all that helpful.

Now, what’s interesting to me is that the majority of the issues that this organization was facing, they were not related directly to technology.

One thing I’ve learned about planning and about business process, if you’re going to change the way that those things work, it takes time, it takes reminders, and it takes encouragement, there is no silver bullet, to getting people to change behavior.

The reality is, we often know what to do, but we do not do it.

Ouch, that hurts.

It’s true.

We know what things we need to do to get better to grow to stretch, but we just don’t do it.

That was the case for this organization. And we came back to leaders with a recommendation we said, here’s some changes we think that you should make.

If you’re going to be successful in making those changes, we recommend you have some external accountability to follow those new processes.

We felt confident that they could be making and keeping promises to each other and to customers quickly and they could begin to build momentum.

Interestingly, in this case, when we delivered our recommendations, they said, Well, you’re not offering the kind of help we’re looking for.

And they sent us on their way.

I do hope that they got some of those things sorted out, we wish them the best and we did go on our way.

Tom Cooper 17:01
So that’s today’s software horror story. Everyone needs a reservation. I hope you found it helpful. But I want to ask you for just a second.

How is your team doing with planning with priorities with communication? Are you investing in your team?

Head on over to bright Hill group.com To learn more about how to improve your results as a Software leader