In This EpisodeFrank was an idea guy with a big dream. What happened when he depended on Oliver to help him get to launch?How good Product Management could helpWhy adding a project manager didn't solve itKey mistakes to avoidTranscriptTom Cooper Oliver said, I can do the work or I can document the work, pick one. Tom Cooper  Tom Cooper This idea of writing elegant code that is simple was a level of thinking that was higher than Oliver was willing to apply to this problem space. And it was a huge limiting factor for Frank and for his code based. One last comment about John from college, I really liked him. And we were working on a team project he he helped me overcome a major limit in my thinking about how to write in machine language. John was super smart, and I’m really glad we work together. He helped me get better my math classes because he raised the bar in class, let me assure you. And I also remember that one of my work study jobs as I was trying to work my way through college was in as a computer lab at Proctor. Yes. This was in the dark ages when even computer science students couldn’t afford to own their own computers. You young uns need to be super grateful for Moore’s law. But one night I was in the lab. I saw John he was stressed he was tearing his hair out. I’ve never seen him struggle that much of her work and certainly not like this. After a while I went over to John and said, What are you working on? I’m sure that I thought it was some complicated graphical rendering algorithm or something. Yeah, back in my day, we didn’t have GPUs. We had to learn how to do 3d transforms using math. But I digress. So John, what are you working on? And this brilliant young man, the one who intends updated me with his computer language fluency said, Tom, it’s this English paper, it’s killing me. I had to laugh. John was so at ease with math and computers that it never occurred to me that everything wasn’t simple for him. That was a big life lesson for me. So let’s go back to Oliver. If given the situation Oliver was in, I really don’t blame him for the choices he was making. Ultimately, he had a lot of things going on and he was being measured on is it done? Rather than? Is it done in a sustainable way? Or even? Are we asking you to do the right things here? His bosses were only asking him this terrible question they would ask how much longer or is it done yet. And of course, given those pressures, Oliver is going to shape his work into small tasks, he can get done, so that he can report progress back on things being done, and his bosses will get off his back. So in addition to the operational support work, which was all of his day job, in his work for Frank Oliver had two categories of work, work that he had to do himself and work that he needed to oversee, that would be done by other people. In this case, Oliver needed to define work to be done by the offshore team and then incorporate their work into his work as a part of getting stuff done. Now, we’ve been talking so far about the work that Oliver was doing, personally, I want to shift gears for a minute and talk about the work he was supposed to be overseeing on the offshore team. On the plus side, the work they were supposed to be doing was documented, it was in a ticketing system, and progress was being logged, at least at some level in the tickets. But just because work is being tracked in a ticketing system, that doesn’t mean the work is being done efficiently, or the work is being done well. Someone has to have the job of organizing the work, assigning the work, checking the work, to make sure that it does what it’s supposed to do, and that it’s written in a way that can be maintained and then releasing and deploying the code. And Oliver clearly did not have time to do that. As time went on, Frank got more and more frustrated with what the what he saw as the lack of progress. And he complained to his friend about it. And so Frank’s friend brought in a project manager to address this problem. Now, Judy was a competent project manager with a track record of getting stuff done. Unfortunately, Judy didn’t have experience running software projects. And she tended to work in a waterfall methodology rather than an agile approach. This is linked to the problems we could talk about in terms of product management. But for now, I just want to talk about project leadership. Now, to her credit, Judy did her best to try to document the work schedule, the work and ship work. She knew her limits, and she didn’t try to get in the weeds of the software development details. And that was smart. But it also meant that she didn’t fully understand what blockers existed or the potential implications of the problems that developers were describing in those meetings. What she did bring was a sense of consistent process and reporting of progress. And that was very valuable, I think it’s easy to overlook the importance of seeing what’s going on and recognizing where things could be getting off track. Now, the offshore partner, provided a team of a BA, eight mid and low level developers and two development leads. The challenge we ran into here is that it wasn’t clear where duties responsibilities stopped and where the development teams responsibilities started. And that lack of role definition meant that stories can be assigned to a developer where the story wasn’t developer ready stories that had unclear requirements or that could not be tested. Now, the addition of the BA to the team helped somewhat, but the BA was hampered by product management challenges as well. And because of this fuzziness in responsibility, it became harder and harder to really understand how much progress was being made toward a shippable product. At this point in our story, I think it’s time for a break. Tom Cooper As a leader in a software team, you know, you want to help your team performing 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 an 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 brightfield group.com So you can learn more Tom Cooper Welcome back. So we were talking about who was on Oliver’s team. And one of the challenges was role definitions. Now, for those of you who were paying very close attention, when I outlined the roles for the team, you might have noticed that one of the role definition problems was a role that wasn’t present at all. On this team, there were no QA team members, none. And the fact that there were no QA resources meant that the project team defended on developers to deliver what the business people intended when they asked for the features. I gotta tell you, this is not a winning strategy. QA teams, when they work, well do all sorts of things with their goal being to break the software. Unfortunately, developers write code and they assume that users will follow the happy path. And when that code breaks developers often respond with Why would anybody do that. And that reminds me the joke about a QA engineer walking into a bar, he orders a beer. He orders zero beers, he orders 99,999,999 beers, he orders a lizard, he orders minus one beers, he orders a bit of our first real customer walks in and ask where the bathroom is the bar burst into flames killing everybody. developers don’t think like QA engineers. And the fact that Oliver was overseeing a team without QA meant that a lot of bugs are going to slip through the tests of the developers. So Judy was pushing the team to be accountable to move things forward and show progress, that progress on individual tickets can be super valuable. But that’s only one part of the puzzle. One of the things I reinforced for teams is we need to be focused on getting 100% of something done. If we almost finished a bunch of stuff, we have nothing we can ship. And it’s critical that whatever we are shipping delivers value on its own. Which leads me to the topic of Product Management. The purpose of product management is to understand the path to value, prioritize desired features, and work with engineering to make sure that what they deliver is 100% of something that delivers value to the customer. Far too many ships of developers have been wrecked on the rocks of shipping a lot of stuff that didn’t add up to value for customer. As we worked with Frank Oliver and David, we realized Another potential problem. We had a huge backlog of features, but there was no comprehensive high level plan for launch. We didn’t know how many more Sprint’s before we could ship 100% of something, and certainly anything more than a proof of concept. And this reminds me of the idea of a launch countdown in the American space program. The flight director would go down a checklist of all the departments that needed to sign off, go for launch, and then got confirmation in order to blast off. In this situation. We didn’t even have a list of departments much less than evaluation of whether the components were ready for launch. See, Frank, David and Frank did outline the major milestones but not in detail. And it’s a far cry from a developer’s assurance that code works on the happy path to the place where we have a robust, supportable application in production. The other challenge Frank was dealing with was that he was really married to his friends investment in the project. Frank’s team didn’t control any of the systems that held their intellectual property. And as Frank began to lose confidence in his friends team to deliver what was needed, Frank was in trouble. If his friend decided to hold the code hostage, Frank would be powerless to do anything about it. And it’s right about now that we turn the corner from act one of today’s play. In Act One, we worked to find a way to make the team healthy and productive. And as we worked with Frank, and David and Judy and Oliver, Frank began to see that that mission was not one that could be successfully completed. So now we turn to act two, how do we safely help move the software project from Oliver’s leadership to another team. I’m a big believer in distributed teams. I’ve seen a ton of successes with nearshore and offshore development. But it’s critical that decisions about your product and the control the tools that hold your intellectual property, those things must remain in your hands and not in the offshore developers hands. And next episode, we’ll talk about some of that. But after we worked with David Oliver and the rest of the team for several work several weeks, Frank asked us to shift our mission from help this team turned around to help me figure out a way to get this to another team without killing the project in the process. But then, on its own brought a whole new wave of challenges. The good news is that Frank and his friend had a good relationship and they came to an agreement that Oliver would help us get to an orderly shutdown, and that Oliver would provide documentation. Tom Cooper I’ll note here that Oliver was relieved because this was a side project for him anyway, and he definitely wasn’t used to leading teams collaborating or communicating with others to build bigger projects and he could build on his own. However, there is a long distance between I agree that you need documentation and actually writing the documentation. So we entered phase two that orderly shutdown with Oliver walk while we figure out a path to restart development with a new team. Now this phase two involves two major areas of work. First, we had to gain agreement on a project plan where Oliver and the rest of the team could provide everything needed to move the project elsewhere. Now, that’s a delicate dance because we needed to convince Oliver to do things for us that he never believed were needed in the first place. Oliver wanted out and he knew that pleasing us was his best hope of not having to deal with us any longer. But at the same time, he had a full time day job, so he was often distracted from the things that we cared about. And like many other senior engineers, Oliver seemed allergic to writing documentation. Now, the second area of work was related to the fact that Frank and David had never really created a measurable launch plan this product, they had a concept of what success would look like, but the devils in the details, and they needed help coming up with the details. So while we worked on one side of the team by creating a done list, for them to satisfy us that we could build the product independent of them, we also worked with the other side of the team, helping them dance with the devil, if you will, of all those pesky details, deciding what was an absolute must have for launch, what was nice to have and what needed to remain a fantasy, at least for the first few releases. Now, while we were doing these things, we also worked with an outsourcer. To help Frank find a reliable software development team in Eastern Europe. I’ll take a moment here to talk about finding developers. It’s true that as my friend Andy Hilliard says smart people are everywhere. Following that principle means that using the right outsourcing strategy can allow you to build a highly skilled team of smart people who don’t live in your city, or even in your country. Now, one way I’ve seen that go badly for clients is they’ll Google offshore C sharp developers, which gives you a jillion results. It also gives you a mismatch of individuals and real software development companies. And of course, the individuals and real software companies have different rates per hour. And so many are tempted by low price believing that because smart people are everywhere, the only relevant differences price per hour. That is not the case. And the path that I’ve seen most consistently lead to great results is to find a company who focuses on actually writing software for clients and not a roll your own committee of developers who offer their services at the lowest hourly rate. I don’t have time in this episode to talk about all the differences between these two options. But suffice to say the lowest dollar per hour is not always the best value. And while the outsourcer worked to connect frank with a great team who was ready to hit the ground running to tackle that engineering work, we worked on helping Oliver and Frank find their way through the end of phase two orderly shutdown, with an island phase three starting up again with a new team. So we worked on defining the set of things we needed to know. And some of those were things that Oliver would just know off the top of his head. Others were things that Oliver had discovered and subsequently forgotten. And a third category included items that he didn’t know and he was gonna have to figure out. We were looking for product requirements, architecture, design documents, current work processes, processes for handling documentation, deployment, a list of tools in active use to support the development, the runtime stack, and third party libraries, I think we had a list of about 150 items that we needed Oliver to work with, to help us get captured. And once we had a starter list, which of course grew as we learned more, we worked consistently with Oliver and with God to get to the place where we had documents that we found acceptable. We also had to work on a migration path where we could export data from Oliver system and put it in a system under Frank’s control. And that included source code management work, ticketing and workflow system design documentation, mock ups and product roadmapping data has a ton of stuff. In parallel with that we had regular meetings with David to review what was working, what was broken, and what was missing. And we also challenge David to make some tough choices to figure out what really was in that minimum viable product? And what could wait. And because you have to make tough decisions. It’s a painful experience. Of course, we want everything. We can’t have a lot, but we can’t have everything all at once. And did I mention that the path to launch doesn’t just include the engineering components? Even if engineering can deliver perfect code, which literally never happens? Product Management still has a good deal of work to do before handing the application off to customers. For example, what are they going to do for user documentation for training the sales team for determining operating parameters like where the system will be hosted? And who gets to call when things aren’t working? How are they going to get paid for software? How will customers report problems and ask for help? How are you going to manage user identity and password resets for heaven’s sakes? And often these things are completely overlooked until engineers say oh, the code is ready. And then the client begins to think about these things. But these are all in the space of product management to figure out as much work as we needed to do with Oliver in his team, we had a similar amount of work with Frank and David. One of the pain points was making sure the system was documented in a way that’s understandable to a moderately skilled senior engineer. This project had gone through multiple iterations with very little documentation. And to Oliver’s credit, he had reviewed the system, the code, the old tickets, and the intent behind the system to get a sense of the way it worked. But Oliver started with essentially no documentation, and he was more interested in doing the work than documenting the work. So he built more and more, and he became the expert on how the system worked. Some people might feel that this is an intentional manipulation on the part of the engineer like, oh, I can be secure in my job if you don’t know how anything works. I really doubt this is the case for most engineers, what often happens is that writing documentation, well, it’s boring, and it gets put off in favor of the fun and interesting work. And I really think that’s what happened here. So our conundrum was we needed Oliver to choose to not do the interesting stuff, but to choose to do the boring stuff. Now in our favor, was that Oliver was tired of this side gig and he was happy to get rid of it. Unfortunately, all of his day job was demanding, and he had to squeeze this work in on a project that was getting shut down. And it was not his priority. In our project review meetings, Judy would ask Oliver, which of these things can you get done this week? And Oliver would say I’ll do the high level architecture doc and the application workflows, diagrams. But the next week would come by and he would report Well, the architecture documents done but I didn’t get to the workflows. And that brings us to one of the hardest software problems teams ever deal with the definition of Done. When is a document done? How would you know, when it comes to documentation, the standard we pushed for was understandable to a moderately skilled senior engineer. So why that standard? Let’s break that down. Understandable? Well, that makes sense. What’s the point of documentation that’s not understandable to a senior engineer? Okay. So we’re not asking for documentation for someone with no experience at all, because that can make your documentation 10 times as big. But what about the moderately skilled part? I think this is actually a critical element. This is important because every senior engineer who’s being pressed for this, first of all believes that he or she is highly skilled, and many times that’s actually true. But while they have high skill in technical areas, they often are not highly skilled in written communication. And they tend to be terse believing that anybody who gets it will need a lot will not need a lot of details, because as they see it, these things are obvious. We push for moderately skilled, because we want to tell the author who’s documenting that they have to dumb it down from their level, to a level understandable to a smart person, but maybe not quite as smart as they are. So when Oliver reported the documents were done, we would review them. And often we would discover that what he thought was clear, was actually lacking contextual details that were relevant to that next guy. And that person was going to need that information. Which meant that Oliver had it on his done list, but we kept pushing things back from done to needing revision. And since this was work he didn’t like and he was fitting in time to work on it anyway, you might imagine his attitude toward those project review meetings. Well, it was not great. They started out with his gently expressed frustration, which increased to annoyance. And overtime, these conversations became more and more aggressive. It’s understandable why it happened. But it led to some tense meetings before we finally got to a minimum viable set of documentation. And frankly, that part of the engagement was not one of the more fun parts. It actually took us a couple of months to get to an orderly shutdown in this case. And now we’ll turn brief attention to act three of today’s play successful startup with a new engineering team. While we continued working on that orderly shutdown with Oliver Frank had contracted with an offshore development company so we could begin phase three. How we begin things often impacts how the overall effort is gonna go. Engineers depend on accurate information and leading a team well requires a good plan with clear expectations about roles and about measurements. Tom Cooper Because of the work we had done with Frank and Oliver, we were able to help David onboard that new engineering team. One of the first things we did with this team is something we call a calibrate workshop. In a calibrate workshop, we invest time at the beginning to establish the tools, the meetings, the measurements, the communications, and the cultural impacts that can drive changes in the way that we work and cause miscommunication. These processes build trust quickly, and they establish a sense of one cohesive team. In just a few days, we get everyone on the same page about how the project is going to run and gain agreements about what we’re going to do when things inevitably don’t go perfectly. And after the Calibrate workshop, we worked with David and the engineers to help them come up to speed on the software they were taking over. We also coached and mentored David and the team. We held them accountable to establish work patterns that would allow the new team to stand up a very should have the app in their lab and begin that critical new development work. With the right parameters in place, and a structure that supported them, well, that team did an amazing job. They were laser focused. And it was just a few weeks after the contract was signed, when the new team was assembled, they built a new development environment, they had a copy of the old code operating, and they were even able to push out improvements to the code in just a few weeks. In this new model, Frank’s team had control the technical details, the control the knowledge, base and control of the intellectual property. They control the development and test environments on server images that they owned and controlled. And these, these environments were readily available to the development team. And that startup of that engineering team was one of the fastest and most smooth experiences I’ve ever seen. I like to say that it’s never been easier to write software than it is today. But it’s still hard. There are so many moving parts. Software is great, but it’s not simple, even with so many advanced tools at our fingertips. So let me take a minute and talk about what we learned in this engagement. We certainly saw the value of documentation, ticketing, and clarity about the criteria that was being used to measure success. And I think there were two major factors that led up to Frank needing to change development teams. The first, Frank didn’t have a ton of clarity about what the market needed and what the market would accept, he could have saved himself effort and money. If he systematically embraced principles from the lean startup with a focus on invalidating assumptions and rapidly learning in that way, he would have avoided paying for engineering work that potential customers just didn’t care about. And the second is, he was really focused on trying to do it cheaply, he looked at costs rather than the idea of investment. And because he was spending on the expensive stuff of paying engineers to work on unproven concepts, he was blowing through his investors money fast, without a clear path of return. If he had been prototyping and doing the critical market research, he could have failed faster and would have learned more with less spending. Often people dramatically underestimate the cost of engineering. Some markets require services that are a lot more robust, and his target market of financial services. That’s definitely one of them. What does that mean? It means it’s a long path from well, it works if everything goes right to it’s really hard to break when it’s attacked for a bunch of different angles. Frank thought he had a production ready solution, when what he had really built was a complex proof of concept. And finally, I want to come back to something I touched on earlier in this episode, one critical mistake that I see teams make is in the area of engineering, Team creation or team selection, that time and again, I see leaders confuse cost with value. Just because a resource is less cost per hour, that doesn’t mean they’re going to deliver higher value. If your team members on average cost half as much, but it takes them twice as long, you spend the same, but it takes you longer to get to your destination. And that time to get across the finish line. That’s opportunity cost. So going cheap, may actually cost you more money in the long run. And let’s talk about this. Do you want to spend your time recruiting, developing and shepherding the engineering talent? Because whether you hire independent contractors or bring on people as employees, that’s exactly what you’re signing up to do. These days, it’s often a far better value to hire a software development company, which has the expertise in those areas, and can bring an entire tech team online just for you. Yeah, that can be more expensive on a per hour basis than hiring independent experts. But it can lead to significantly better overall performance. And aren’t you really more focused on how many features you can ship that customers will be happy to pay for than just getting the lowest dollar per hour? Maybe your investment ought to be dollars per customer valued feature, rather than dollars per hour. And that wraps up today’s software horror story. We encourage you to tune in next time we’re going to talk about a team CTO who said to me, I feel like I have a firehose of money that I’m constantly pointing at new problems. That one was quite the carnival ride. See you next time.  The post BGLS5E4 – Living the dream appeared first on BrightHill Group .