From dysfunction to a soft landing: How Ajay found a way for his team to win. BGLS5E3

Becoming a Geek Leader

From dysfunction to a soft landing: How Ajay found a way for his team to win. BGLS5E3

Play Episode Pause Episode

Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 30 seconds

00:00 / 22:28

RSS Feed

Share

Link

In This Episode

• Fighting cofounders
• No documentation
• No repeatable processes and
• No tickets in the tracking systems for technical work?

Transcript

Tom Cooper 0:00

Fighting cofounders, no documentation, no repeatable processes, and no tickets in the tracking system for technical work?

Tom Cooper 0:14

Hey, it’s Tom Cooper, I want to welcome you to the next episode in the software horror stories podcast as an introduction to today’s true story, to protect those involved, I have tried to recreate events, locales and conversations from my memories of them. In order to maintain their anonymity, in some instances, I’ve changed the names of individuals and places and a few events were changed to add clarity and improve the message of the story. And now that we’ve got that behind us today, we’re telling the story of Ajay and how he led his team from struggle to stability. So let’s jump in. Ajay is the CIO of capital pros of venture backed technology company with many SaaS products. During his career, he’s had success as a technical lead and he’s moved up the ladder and today, Ajay is responsible to oversee the portfolio of companies and applications that leads to return on investment for capital pros. And not just portfolio they have internally managed applications where ownership has been transferred to his team for Operations and Support. And they have newly acquired tech which is run by the teams who originally built it. Capital pros expects Ajay to take on the applications developed by these companies they acquire. His job is to make sure the technical parts keep working that the application development continues as planned, and that he can support the profitability of these parts of the business. Things are busy but predictable for Ajay when he starts hearing rumors of trouble with one of the companies. Direct harmony is a newer acquisition for capital pros, Ajay was a part of the team doing the due diligence before capital pros bought direct harmony. In that process, he had been seeing signs of conflict between the founding partners, but His hope was that as they transitioned and gave the promise of providing additional financial support to the company, that maybe they’d be able to add more engineering capacity, and that would help them deliver and get past those differences. Prior to the acquisition, direct harmony had been in business for several years and had a promising growth curve. The technology and the opportunity for additional customer growth were factors and capital pros decision to buy them. In the months since the purchase, the team did release one big update to the application, but it didn’t have all of the promised features. And worse, there were significant quality problems in both the new features and in the parts of the application that weren’t even supposed to be changed. Now Natalia, the Head of Product Management and a co founder is reporting she’s more and more upset with Jack, the CTO and the other co founder. There is always tension in every development organization between product management and software engineering. Product always wants more features, higher performance and lower costs. Engineering wants to deliver all the product is asking for and at the same time is also fighting to do research and make scalability plans as well as paying off technical debt. Finding that balance between those interests, it’s always hard. But in this case, there may be more than just the normal amount of tension. For Ajay, he is busy. And the challenge for him is he’s got more problems than just direct harmony on his plate. That’s just one of many fire drills that keep cropping up for him. Jack had reported that the big blocker to his team hitting his deliverables was he didn’t have enough resources. If only capital pros could give him more staff everything would be just fine. based on that feedback, Ajay did push forward to find budget to fund more developers for Jack and he hoped that would get them back on track. The reality here was even adding more engineers didn’t work. Direct harmony was still shipping late with escaped bugs on every release. And while Ajay was looking for additional developers, one of the people he talked with mentioned me to him. They discussed how my team focused on working with leaders to help them improve software team performance, communication and resolving conflict. Ij knew he needed to do something but frankly, he wasn’t sure what could be done. At this point, he figured he needed to try something different. So he gave me a call. During our call, we talked about the challenges between Natalia and Jack. We discussed some of the tech stack and the process challenges, and we brainstorm ways for me to work with him and work with his team. We agreed the best case scenario would be to find some way to heal the rift between Natalia and Jack and build a sense of team while creating some predictability in those releases. That was a tall order. At the same time, Ajay knew he needed to show progress toward goals soon, or he was going to be in trouble with his higher ups. He had some runway left but the amount of runway ahead was starting to feel pretty short. Ajay realized the path to success was going to take more than simply adding more engineers. And after our conversation, he began to see a path forward. He decided to hire us to work with him and his team to see what we can do. We began the process of interviewing team members in preparation for what we call a calibrate workshop, where we could get all the team members on the same page about culture communications, conflict resolution Sure and the software lifecycle. Once we dug in, we learned that it was worse than Ajay thought. Not only was Jack not hitting his marks, but the conflict was escalating with Natalia, leading to a recent screaming match between them with the whole team on the call, it was getting ugly. And worse, Jack is the kind of guy who hates conflict, and he won’t even acknowledge the divide with Natalia. He’s essentially pretending everything’s okay when clearly it isn’t. Unless Ajay can find a path to make peace between these founders, there’s no way they can hit those deliverables that they promised conflict between Jack and Natalia. That’s a big blocker. And it’s not the only one. I love working with leaders and teams. And during my career, I watched too many of them fail, good projects, good people, good business problems, you combine those you should get success, right. But often, it doesn’t happen that way. I believe that because people matter, we must lead them well. And with all the resources we have these days, it shouldn’t be this hard to build great software quickly. But it is. However, with the right support leaders like Ajay can find great solutions. As I see it, there were three big obstacles in Ajay’s path. First is an unresolved conflict inside the leadership team. Second, is the fact there are no systems and processes in engineering other than we do whatever Jack tells us to do. And the third is the entire team simply does not communicate well. They don’t communicate well face to face or in any of the electronic systems. In fact, many of the development tasks are not even put into a ticketing system. Jack is the core of all software engineering and all software operations in the larger team. Well, they’re just living in the dark. And the team is getting bigger Ajay did approve that budget increase that allowed for Jack to bring in more developers, this time from an outsourced software development shop that had done other work for capital pros. And through the Calibrate workshop, we led the new larger team through exercises that helped them agree on how things are going to work going forward. Together, one of the things we did was we identified the roles and the people fulfilling the roles needed for successful implementation. As we went through that rolls chart, it turned out that Jack was performing almost every role related to anything technical, and that had changed. Jack is super smart. He’s well accomplished, but he’s not skilled at delegating, or trusting others or in following repeatable processes. The exercises we did together during the workshop helped shine a light on the problems caused by the bottleneck of check needing to make every single technical decision. We also identified cultural challenges, communication improvement opportunities, and together we defined ways that we could use the tools we had more effectively tracking goal setting and accountability. At the end of the Calibrate workshop, we had begun building a sense of community a sense of teamwork and collaboration that simply had not been there before. But that didn’t solve all of the problems. 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 too. Even the best team struggled to build a culture of collaboration and high performance without clear communication and right planning frameworks Broyhill 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 brighthillgroup.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 8:57

We jumped back into the story right after the Calibrate workshop, that one of the first places we made some traction was with a team member named Siva Siva, it was a relatively new hire who actually reported directly to Ajay Siva had been taking work direction from Jack but he was having trouble learning the system because basically the entire technical back end was undocumented. During the workshop, Jack agreed that Siva could start documenting the work that Jack was too busy to do and this did allow Siva to start to gain some critical understanding of how the software actually worked. And then there was Julian Julian had been a scrum master in her previous role in direct harmony thought that it would like to be more scrum like, but it seemed to get stuck actually implementing agile ceremonies when things got busy. In principle, we agreed this was necessary. But when it came right down to it, the team was skeptical they would actually follow through after the workshop was over. We did agree with the team’s concerns and after the workshop we shared what we learned with Ajay based on his previous work with Jack Ajay was skin tickled the team was ready to handle things on their own. And they then he asked us to work directly with Jack Gillian and Siva to help them turn those good intentions into new good habits. And as we began to hold them accountable to follow through on their commitments that they had made in the workshop, we were able to free up Ajay to work on some other tasks. But it was also clear that team members were going to need more help from Ajay in order to change the culture and change the practices within the team. Ajay decided he wanted to work with SIVA and Jillian to mentor them and to provide them some support on the journey. By having Jillian and Siva report to him directly, he now had that channel to hear directly from them on how things were going. And over the next few months, the team began to see some wins. Sivas work documenting system design and operations allowed Julian to schedule meetings to share information across developers and product management. This allowed everyone to see and agree about how the system works, as well as how they want it to work. This change just starting to document how the system was built, allowed the team to discuss impediments and potential strategies to solve problems, they began to work together in ways they hadn’t. And it gave the team a shared experience in working together to slay the dragon. Jillian’s organizing and planning allowed product management to get better insights into what work was actually happening as opposed to what they thought might have been happening, they began to understand when they might get results from engineering. It also helped the engineers really collaborate working together rather than as independent contributors. Through this process, also, Jack was freed up from some of the more mundane operational work so he could start to look at solving the tough challenges ahead. And things like scaling and operations. So things are good, right? What when it comes to the day to day Software Development, Operations and deployment, things were running much more smoothly, that was good. And during our coaching engagement, our team met regularly with Ajay to help keep him up to date on our view of Team progress, to be a sounding board for him, and to support him in his leadership of the team in the business. There had been persistent code quality problems, and the team was asking for additional resources to extend the QA team and to extend testing. And during one of our update calls, we met with Ajay to ask him about additional resources for QA. Unfortunately, Ajay told us that that was just not going to happen. It can be quite challenging for organizations to make change in the way that they do things. As co founders and a startup Jack and Natalia had big dreams and big plans and a wide ranging big roadmap of things that they hoped to accomplish. Many of those things had come to fruition, but the reality was that many hadn’t. Not only that, but many of the things that they had promised to come by a certain date just weren’t being delivered. Things were more complicated than perhaps they originally thought and they were struggling to work together to try to find a way to get to that resolution. And in spite of the time and the effort and the money that capital pros had put into direct harmony. The Roadmap wasn’t coming together. In fact, their roadmap had been impacted by something I call hopium. Usage. Hope becomes a common addiction for small development teams and for product management teams and when things don’t go as we dreamed our problems turn out to be more complex. Life is hard. That can lead to increased hopium use. Many times, roadmaps are optimistic that’s a reality for everybody but direct Harmony’s was more than merely unrealistic. More and more unexpected problems cropped up. And when that happened, the deliverables and due dates promised became more and more dependent on hopium. Maybe all the stars will align, maybe it’ll all work out, maybe we can come up with a great solution. But things didn’t come together. And worse than that, direct harmony sales forecasts had been dependent on delivery of those new features that prospective new clients considered essential before buying and that existing clients needed to see in order to choose to renew their licenses. And even though engineering and product teams were making progress on those needed items, direct harmony was consistently not hitting the publish schedule for new features. And their sales numbers were way off to. Jay had based his support for funding additional team members based on direct harmony, turning their hopium into working features in production fast enough to offset that new investment just wasn’t happening. And after the acquisition, Natalia and Jack were kept on their commitment was supposed to be based on earnouts that they would get when they shipped features and when they hit those sales numbers. While the improvements in the team’s performance were encouraging that slipping schedule and Miss His quarterly numbers, they were a great disappointment to the investors. Ajay just couldn’t justify the increased spend when the software and the financial results weren’t happening. Complicating this whole problem Natalia had come to Ajay to say she just couldn’t keep working at this pace. She left. She’d been working beyond her peak capacity for so long. I think she just ran out of gas. Nobody can sprint for an entire marathon and she was worn out. The impact on the team, though, was tough because she had brought a lot of energy and vision to the product line and losing her. That was a blow. Andrea was worried about Jack to these changes in process and combined with the pressures of the schedule had begun to push jack back to following some of his old habits, which weren’t good ones. As we continue to work with Ajay, he concluded his best path forward was to move as much daily work as possible to the capital pros operations team. See this documentation and his work with Jack equipped him to be able to be the catalyst for success in that process. Over the next few months, our team worked with the transition team on this so that we could reduce workload on the engineering team. Siva became the lead who really understood the application and who could coordinate with the operations team to successfully keep that application running well. As far as daily software development operations were concerned, Ajay worked to equip Jillian to be in charge of planning and execution and leading the day to day teamwork. We also stayed engaged to work with Jillian to develop ways she could work with team members and leaders to help them all implement the kinds of change they needed to implement. Her work was very helpful, and she built momentum, as the team adopted positive habits and consistent execution. And building that momentum and seeing those successes that helped to make Julian’s job easier. Unfortunately, Jack felt the increased pressure of Natalia his departure, and he too decided to move on this. This was tough for Jillian. But by the time that happened, she was in a better place to be able to manage it. Over that whole process we worked with Ajay as he directed Siva and Jillian through the process, and they were able to create a soft landing for the team in the midst of all these big changes. As a leader in a software team, you know, you want to help your team perform at the highest level. And you know that with the tools we have, it’s never been easier to write software than it is today. But it’s still hard. I’m Tom Cooper, and for the last decade, I’ve focused on coaching and training software leaders and their teams to help them make the small but important improvements to help them perform as one team and to achieve their potential. How much better would your results be? If your team communicated clearly managed conflict well delegated work that stayed delegated, and then created and executed on great work plants. It shouldn’t have to be this hard to write great software. And the good news is it doesn’t have to be, are you ready to take the next step, head on over to brighthillgroup.com So you can learn more.

Tom Cooper 18:07

So I want to take just a minute and talk about what lessons we can take away from the story. It would be great to be able to tell a story where the hero stands on a pedestal in a celebration where they’re awarded medals by the princess and they’re hailed as heroes. But could we really call that a horror story? And isn’t this the software horror stories series on the podcast? The fact is, we live in a messy world. We all want our projects, our careers and our income to move up on a chart up into the right. But what often happens is that things some of which are in our control and some which are not in our control often change our plans, and our path to ultimate success might be forward or sideways or even backwards. The world changes quickly. And we need robust skills and the ability to keep our focus on how our personal goals relate to business goals and market factors. Jay was really earning his pay. He had to navigate a challenging course working with a team that wasn’t ideal success criteria change midstream, and he had to find a path that helped the team to win because that’s what leaders do. Leaders find a way for the team to win even when situations are complex and challenging. Doesn’t that sound familiar to you? How many times have you found yourself running toward the goal line only to find that it had moved while you were running? This project had people challenges, low trust, weak processes, and an overwhelming workload for many of the team members. Ajay was able to navigate those challenges and he found an acceptable landing spot for the project and the team and his higher ups. It wasn’t a grand slam home run. But Ajay and his bosses were content with the outcome of the project. Together they found a path to stabilize the platform to lower expenses. And in the process they were able to build more team connection and trust and increase per person output overall I was thinking about this experience. And I thought of some questions that might be useful for you as you’re trying to navigate a season with a difficult project. First, who are the leaders on your team? Sometimes helping those leaders to learn how to stop alienating team members can be the most productive thing for your team. Jack often was making difficulties for his team members and helping him learn to stop doing that was very valuable. I like to say when you’re in a hole, stop digging. Next question, what does success look like? If all this stuff was working? How would you know? What evidence would you have to let you know that that worked? In this case, Ajay realized stability and cost containment were the highest value that he could deliver. And so he had to turn his attention to focus on that, because for him in this situation, that’s what success looked like. Thirdly, who needs to grow to help you get to that level of success? Looking at your team members who’s got the potential to stretch enough to become a change maker? Who has an interest in growth? And what can you do to equip them? Next, how realistic is your forecast? Whether it’s for sales or for feature delivery? Is it based on real data? Or is it impacted by hopium use? Getting to reality is a powerful step in defining metrics to be accountable, showing real performance compared to projections. That’s a great way to get off of opium addiction. Now, I would love to step into your messy world and help you find a path to success. Head on over to Bright Hill Group to set up a time to talk about you and the things that are happening with your projects. Even if you’re not sure that you’re ready to have us help you right now. Go ahead and set up a call because I love hearing your stories. And that’s today’s Software Horror Story.