BGLS5E4 – Living the dream

In This Episode

Frank 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 help
• Why adding a project manager didn’t solve it
• Key mistakes to avoid

Transcript

Tom Cooper 0:00

Oliver said, I can do the work or I can document the work, pick one.

Tom Cooper 0:10 Hello, and welcome to another in our software Horror Story series. I’m Tom Cooper and today I’m telling the story I call live in the dream. As we enter act one of today’s three act play, we meet Frank. Frank was a big guy with big ideas. He was a visionary who dreamt of building a high impact product that would change the way the world thought about charitable giving, and could potentially make him wealthy in the process. And Frank had been dreaming of a big launch for a long time. And over the years, he managed to raise some money, and each time he raised money, he would make some incremental progress toward his overall plan. And each fundraiser raising round, he managed to take steps to get closer to making that a reality. And by the time we met Frank, Frank was on about iteration three of his dream. At this point, he had contracted with a team to build it for real. But he was frustrated because he wasn’t seeing the progress that he hoped for. And he asked us to come alongside the team and figure out what was working and what wasn’t working. Now, the first step was to understand what was real. And what was vaporware. And one tool we use for that is a product we call our foundation assessment. In the foundation assessment, we look at elements of how the business is actually connected to the software, what processes and methods are in place as they’re producing the software, and how the technical resources are managed. And our goal is to come up with a comprehensive risk analysis that helps prioritize which of these 15 key areas need the most attention to improve those outcomes. And we’ve seen that teams can sometimes miss out on even seeing important risks, and then they can fall into a trap that can raise costs and potentially threaten their project success that had happened here. We began our foundation assessment with Frank Frank, Lieutenant David and the technical team. And what did we learn? Well, one thing is Frank had the vision but the technical stuff. Well, Frank relied on others to make his vision a reality. And he didn’t really know what it took technically, to build a tool that could credibly be deployed and run and operated in a financial technology world. Now that should have been our first clue. And I have to say this story got more exciting from there. Now, we began to work primarily with David and Frank had hired David to be his right hand man, somebody who could handle the details. While Frank focused on the vision and the fundraising. David was a smart guy, and he had some experience in software development, but not a lot of experience in bringing a new product to market. David was doing the best he knew how but there were some limits on what David could make happen based on his experience and the tools that were available to him. And if you remember that Frank was bootstrapping his dream, he had raised some money, but it was angel investors really, he looked for ways to cut costs regularly. And one of those ways that he cut costs was he persuaded a friend who had some technical folks to donate some of their time in exchange for some equity in his in his venture. And that’s where we meet Oliver. Oliver is the tech lead. He’s responsible for implementation of Frank’s big idea that Oliver has support, because he’s got a group of offshore developers that are half a day’s worth of time zones away. And Oliver’s job is to come up with a scalable technical design and then guide that team to build the software. I have to say at this point that Oliver is no slouch than in an interview situation, it is clear that he really does know his technical stuff. He can think well, and his ideas that are really technically smart. There’s nobody better to see the talent oversee the technical stuff, right? Well, did I mention that Oliver was only available part time for this project? Yeah, that was an issue. Oliver worked for Frank’s friend and Oliver his day job was overseeing the operations for Frank’s friend’s company. Any operational challenges that came up meant that Oliver was missing an action until the crisis was over. And since Frank was paying his buddy and a combination of equity and a small amount of money, revenue generating work for Oliver, well, that went to the front of the line, and everything for Frank and David went to the back of the line. And Oliver, like a lot of deeply technical folks is mostly concerned with whether he understands the design and the implementation, and not nearly so much focused on documentation or even communicating with others about design or how things actually get built. As we dug into the realities of the project, we discovered that when Frank had worked on version one, and then later on version two of his dream, he had been using a locally installed version of a ticketing system when the money was starting to run out. To his credit, Frank did create backups of the data. And he did pass those on to Oliver for Oliver to use, so he would have a frame of reference for what technical work had gone before. Unfortunately, for Frank and for Oliver. It had been so long since they had done the previous iterations that the version of the ticketing tool Frank had used before was now so old, it would not run on a modern operating system. The ticketing systems application code was so old that it was no longer available from the vendor either. So Oliver was tasked with finding a way to make it work. His solution, which was creative was to stand up a virtual machine, running the old operating system and restore the application code and the data to that VM. It was a good plan because it allowed Oliver to see the tickets and the status of previous work in progress. But it was an island of data, Oliver didn’t want to put that VM on the public network due to operating system security issues, because the OS was unsupported. And his offshore developers didn’t have access to that system either. And they couldn’t use it. So Oliver didn’t want to make his daily operations dependent on an unsupported locally installed copy of the ticketing software, which that was the right decision. So Oliver stood up a cloud instance of a new version of the ticketing system for his offshore developers to use. And he did make some initial attempt to import tickets in history to the cloud version, but decided that mountain was too high to climb. So he ended up treating is the old way and the new way and use the old ticketing instance as a reference for himself. Nobody else had access to that. Now, as long as we’re talking about ticketing, I’ll note that Oliver followed a pattern I’ve seen many highly skilled engineers embrace, he didn’t create or update tickets related to work he was doing. I call it a pattern, but I think it’s really an anti pattern. When your most senior people don’t document planned work status, a work in progress or completed work, their work queue and their work, progress is a black box. This problem is made much worse when people get busy. All too often stressed and frustrated, senior engineers will say something like I can do the work, or I can document the work pick one. And because the senior engineers, the only one now who can do the work, we tolerate that lack of documentation from them. I can’t stop myself from pointing out how deadly This is to long term project success. I remember, in college, I worked with a guy who was so smart, he basically breathed algorithms in and out, he would write concise code that almost always would compile without errors. It was efficient. It met all the technical requirements. And it demonstrated his utter fluency in the language as he wrote, It was impressive. I remember I was in awe of John, and on the surface seems great, doesn’t it? It’s great to have efficient and accurate code. But we have to ask ourselves, what problem are we solving? are we solving the problem of can John write that code? Or can John make changes to that code? Actually, no. It’s true, that code doesn’t rust. But it’s also true that the details of your business problems always change. So the problem we’re solving is not can John write that code for us. But the problem we’re really trying to solve is can we build a system that makes business requirements today, and can be modified in the future by a competent, mid level engineer, because we can’t afford to pay John to constantly be maintaining the system. For what we pay a developer like John, we really need him to work on figuring out the hard stuff, not making minor changes to the small parts of an existing system. So that leads us to this point, brilliant technical developers and architects write simple code that elegantly solves the hard stuff. They read it in such a way that young engineers and mid level engineers can understand what they wrote and can make changes to it over time. This is a profoundly valuable thing. That’s all too rare in our software development. engineers who are smart, but don’t do that they’re short sighted. Because if you’re the only one who can modify the code, you’ll be doing that job forever.

Tom Cooper 8:40

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 14:09

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 15:06

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 19:45

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 29:07

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.