I spoke to Nick Hance recently, and we had a fascinating conversation about risk in software projects, maintaining quality over time, zeroing in on repeatable excellence, and finding your niche by focusing on value.
You can learn more about Nick at http://buildbettersoftware.com
Check out the 43-minute interview below. You can either watch the video, use the audio player to play the audio, or download the MP3 to listen on the go.
Or download the MP3 here for listening on the go.
Philip: Well, Nick welcome.
Nick: Oh, thank you Philip. Good to see you.
Philip: You too. Nick, can you tell me who you are and what you do and we’ll start with that?
Nick: Sure. Yeah, my name is Nick Hance. I run a software strategy firm in Quakertown, Pennsylvania. It’s a tiny little town between Philadelphia and New York City, about an hour north of Philly and two hours west of New York City.
Philip: That’s a great location, easily get to both places it sounds like.
Nick: Yeah, it’s pretty neat. We’re right in the middle and what’s neat is that it’s for where we’re at it’s somewhat on the rural side which to me I find is a pretty important thing. I like my quiet time so being able to get away from things is something I find a lot of value in having.
Philip: What kind of strategy work do you do?
Nick: We help to build software teams. We’ve been doing software consulting for almost 10 years and in that time we’ve worked with dozens of different teams to see what works, what doesn’t work, and we want to take what we’ve learned and deliver that in a way that will help new companies maximize the results they’re able to get from their team without spending years learning the right way to do things. We’ve got a product at buildbettersoftware.com that is designed to help companies really accelerate their capacity to accelerate their organization’s operational capacity in terms of software development in a very quick manner.
Philip: Software development has been around as a discipline for what, 30 years maybe longer?
Nick: Yeah, I think so. Since the 70’s I think.
Philip: Okay, so yeah coming up on 40-50 years. Just real briefly why the need for help with that, why have companies not just got it all figured out?
Nick: Well, I have this vision for the world in that we’re seeing more and more attention being paid to apps and software and we’re finally starting to see it have the big affect on the world that the dot com crash was so excited about. In that I see a giant rush for the world training more software developers to get more people to program and in that rush I see a lot of mistakes being made. I believe that in the next 50 years we’re going to see some of the world’s greatest software teams ever being built and it’s going to be a whole lot of ones that just don’t know what they’re doing or struggle to get things done in the right way. It’s one thing to be able to write code but to be effective and to get things done takes a lot of discipline and that discipline is not aligned with traditional values that a business has.
Philip: Oh, wow.
Nick: The reason is that software is really a creative exercise. If something has been solved before the tendency is to use and reuse what’s been already done and that means that all software projects are either using something that’s freely available or you’re doing brand new work and that’s not entirely true but at some point you’re doing brand new work for every project. That takes time to get right but there’s immense pressure on business owners and project managers to get things out the door quickly and that pressure tends to get pushed down to the developers themselves and when that happens developers are forced to cut corners and you end up seeing that in the end result of the product.
Without the discipline that you need to get things done in a way that is sustainable you’re going to find a lot of developers burning themselves out. You’re going to see demands that are just unreasonable and ultimately it’s the end user that suffers for that but the organizations that are able to understand this and to make the right choices and give the developers what they need are the ones who are going to see long term success. That’s one of the beliefs I really hold tight to myself is that to do software right you need to provide the environment that will allow the developers to succeed in a way that needs to be done.
Philip: Yeah, in a lot of cases software is the business. I think more and more they’re businesses. They’re not software companies but the software they put in front of users represents the company to their customers more than it did 10 or 20 years ago.
Nick: Yeah, software is just a machine. It’s just a machine based on logic then parts and gears and levers and it’s easy to forget that you’re building machines. To do it responsibly you have to be smart about it. You can’t leave extra levers and buttons and things in there. You have to clean things up and you have to do it with the discipline that this is a real machine and it has to be done in a way that is sustainable.
A lot of unsustainable practices out there and one of the things I really love to talk about is the fact that as a small business or as any business you’re operating with limited resources and you have to take risks. You have to. You can’t give into the engineers. You can’t always build a machine in the most elegant manner possible because in order for a business to succeed you need to get things out the door. There has to be some sort of meeting between the pressures that are placed upon project owners and project managers and the desires of the engineering team to engineer in a way that is more or less ideal and that’s one of the big struggles.
Philip: That’s why we’re here today is really is to talk about risk. We’re both small business owners so we deal with risk everyday. You in the context of building things and advising your clients on building things in a way that meets their tolerance for risk would you say?
Nick: It’s more about managing the short term versus long term outcome.
Philip: Okay, well let’s start with that or actually let’s back up. What’s your philosophy on risk? Let’s start with that and then dive into the details.
Nick: Okay, so when you’re building a software product first of all it needs to work but let’s step back because I think this applies to more business as a whole rather than just software. When a business develops a product it needs to develop the product in a way that the consumers of that product, or the customers, can use it and form expectations around it such that their expectations don’t change and they’re able to refer that product to others. It’s when companies have their expectations that they’ve established with their customers start to change that you’ll see companies start to fail.
Philip: Real quickly what’s a concrete example of that?
Nick: Apple does a very good job with their operating systems in that things are very consistent. They seem to work and it’s been a long strategy for them but it seems to have done a very good job in terms of building a very solid product. If you look at the difference between the latest releases of the Microsoft operating system and the Apple operating system the difference is very clear that the attention to detail and the polish while it takes a very long time to get right, in the end it’s really where the real winner is.
Philip: Yeah, I can’t remember the last time I’ve heard anybody say “it just works” about a Microsoft operating system.
Nick: Yeah, and I don’t want to start that debate.
Nick: It’s a feeling that you really can get a sense for just through casual use of both products.
Philip: Back to the product discussion. Customers need to have that expectation of long term stability or at least medium term stability?
Nick: Right, so a customer forms an idea of a product when they buy it and that idea is refined over the usage of the product. If you were to buy a car and the car runs well in the first week you’d think it’s a great car but if it stops running on the second week then it’s no longer a great car and your first weeks expectations are out the window. The fact that the product works at first is good but it needs to maintain that initial expectation over a period of time in order to gain the reputation and to gain the referrals that you’re going to get that a company needs to grow.
Philip: This is true of services too isn’t it?
Nick: It is and you’ll find that especially with the consulting agencies and I can speak with that just because I’ve run one for years and I’ve had interactions with others. A service agency usually gives a very good impression at first but that fades over time, sometimes rather quickly. Without some sort of quality measure or some sort of really strong habits in place that tends to happen just because, not so much the incentives, it happens because over time the desires of the customer and the desires of the service agency differ. You’ll see relationships that will start to fall apart because of that unless consistent attention is paid to keep the agency and the customer [alliance 00:10:30] close.
Philip: That’s very interesting. I’d love to hear more about that but please continue so we’re talking about risk and products.
Nick: Sure, so I think it probably is going to benefit us if we get a little bit more specific. The risks that I’m talking about is when you’re building a software product a company will expect to get it out the door quickly. See apps on phones. Every single day you see new ones and it’s easy to underestimate how difficult it is to solve new problems in software.
The problem is that when you’re reusing work that others have done there’s no cost to that so if you want to put a [balancing 00:11:18] widget on the bottom of your Mac OS X dock thing it’s very simple. It takes two lines of code but if you’re trying to solve a similar problem but it’s different enough that you need to solve it yourself, the engineering takes some time to get it right despite having established practices, duespite having solved it in a similar way. The creative work does take time to get right. For that reasons it’s very easy to have a project manager have unrealistic expectations for how long something will take to build.
Philip: Why does that happen? Why is it not just blazingly obvious that things take longer than you think and so forth?
Nick: It’s because progress is not linear in software. A lot of the times when you’re solving problems you can spend many hours solving, researching, or trying to debug something and the actual fix can sometimes turn out to be very very simple. There’s an interesting story I believe it was about Xerox that I’ll retell now, where there was a big installation back when they had the full room sized computers. One of Xerox’s customers had had a problem with the computer system and they sent an engineer out. The engineer came out. He switched out two switches and they sent a bill for $50,000. The company did not like this at all and they demanded to know an itemized list of why it cost $50,000. The story goes that Xerox had then sent back an itemized list and the cost of two switches was $2 and the cost to know which switches to replace was $49,998. It’s an interesting story. It really does take time and experience to learn those sort of things.
Philip: Right and that expertise is not evenly distributed throughout the organization. People who are setting timelines and doing management functions may not have the expertise or is that really the problem or is it a different problem?
Nick: Well, no. The problem is that a business needs to be able to estimate when things will be done and you see this when software delivery dates slip. It’s because it’s very very difficult to estimate the effort required to solve a software problem and that’s because again, the progress is not linear. It’s something that takes time. Most of the time it’s figuring out what work needs to be done. It would take as much time to do the estimate as it would take to do the work and that means that estimates are useless. That makes it extremely difficult to give the organization what it needs which is some estimates because estimates are tied to budgets because in business world time is money and that’s very very difficult to provide.
Philip: Yeah, that’s a huge risk. Not only do budgets need to be in place but other things need to line up around completion dates for software projects like marketing plans and stuff like that.
Nick: Yeah, and the other parts of the organization that depend on it and despite best efforts that’s not always possible. It’s a very difficult problem to solve and one that if it happens too often organizations will lose their tolerance for it. If you don’t keep your eyes on the bigger picture and you lose tolerance for the fact that things take awhile to build sometimes then you start to run into problems where people are making quick fixes and they’re doing things the quick way rather than the right way. That means you end up with very convoluted sort of programming that becomes very difficult to maintain.
Philip: Very fragile, right?
Nick: Yeah and I believe and I have no experience with this but that healthcare.gov that the US had such an issue with I believe was probably caused in large part because of this quick fix problem that you’ll see.
Philip: Well, they got a lot of heat for that. I think largely because the perception was come on it’s just a website with a database. What’s so hard about that?
Nick: Yeah but that’s the way you interface with it but that doesn’t say anything about the back end of it. You still see all of the apps and phones and things and tablets and all those different things but a lot of the programming behind that is server side. Anytime you need to log into a service. Anytime you need to interact with multiple users that all happens on a server somewhere and whether the interface is provided through a website or through a phone or a tablet it’s still is involving a lot of the same sort of techniques.
Philip: Back to our earlier point about the difficulty of estimating and sometimes the impossibility of estimating accurately, two questions come to mind. How do you live with that better and how do you estimate better and I know those are big questions?
Nick: Yeah, so that’s really just building a tolerance for risk and as much as it would be nice to have a quick answer for that I don’t know that there is one. The more time I spend developing software and the more experience that I and my team get with it, it doesn’t get any easier. In fact it sometimes gets harder because we’ve seen difficult problems. We’ve seen what can go wrong and that makes it even harder to estimate because you never know what could be lying around the corner.
It really comes down to best efforts. If you think of software development more as research and development where you don’t have solid expectations and less about product development then you can somewhat align your expectations better but it’s more about changing expectations at a high level than it is about changing the work that’s done there. [inaudible 00:18:18] you can make but you can’t change the fact that it is difficult to do.
Philip: Wow, that’s almost a different paradigm for conceiving of it when you think of it as R&D instead of let’s get this product out the door six months from now.
Nick: Yeah, exactly. Yeah, if you think of this in those terms then it’s a little bit easier to stomach however that doesn’t really help in terms of what the business needs to do to survive.
Philip: Yeah, if that product is linked to revenue and it often is or if it supports something that generates revenue, how do they move forward in light of that risk that they have to live with?
Nick: It really comes down to making smarter choices about the risks that you take. Any business owner has to take risks to survive and you take it with your business every single day. I find it especially difficult with the sales and marketing material that we’re doing because you don’t know what the return is going to be on that. At least with technology you can see results of your work so you can have something tangible to look at and you can do that with sales and marketing too but the technology works. You can press a button and it does something. Marketing it just lives out there and it’s insanely risk because you don’t know what works and what doesn’t and really it’s based on taking educated guesses and just trying to give the market what you think it needs.
Philip: The risks with marketing is not. I think actually this is true with product development, the risk is not just doing something and maybe doing the wrong thing. There’s a risk to not doing something as well, right?
Nick: Right. Yeah and if you can think further ahead I wish I had more concrete examples lined up of the risks of not doing marketing. That really comes down to a pretty pretty easy to see conclusion is that no one is going to know who you are. No one’s going to know what you’re capable of and the business is not going to grow beyond brick or metal.
Philip: Would you want to just live do a real high level dissection of your product and just talk about the risks and how you dealt with those in a somewhat general way.
Nick: Yeah, but let’s instead of being general let’s just expand and explore together.
Nick: Let’s just have a question and answer sort of thing about it and we’ll explore it in that manner. What is it specifically that you’d like to know more about?
Philip: Well, starting at the beginning. Your product is a service packaged up as a product right?
Nick: Correct. It’s a [inaudible 00:21:22] engagement of six weeks and it involves getting things done with your software team while giving them better ways to do it. We bring in it’s called framework because it’s designed to give you a very solid foundation upon which you can grow a business.
What happens is you’re either growing a software team or you have an existing software team that you think could do better and we get involved and we come in and we show them a technique that we’ve refined every year of this is how we write software. We go through this is where the ideas come in and then from ideas they turn into plans and then the plans for the ideas become tickets that the developers can take to work on and it’s a step by step process so you can see an idea from beginning to end. We have accountability through the entire process so once the work is actually part of the product you can then look back and see all the way back to the idea stage, all the discussion, everything that went through that so that you can then have that as reference later.
Philip: Oh, go ahead.
Nick: As you build out a product it’s very handy to have that sometimes because you’re going to want to be able to go back and see what decisions were made and to understand what motivations were behind any particular decision or any particular part of the machine. It takes it from being a black box of code that just does stuff to fully explained expectations of it should do this because we need the clients to experience this outcome and then you can start to make choices on is this outcome important anymore and if not then you can remove that code all together from the code base and then have a more refined product that’s done in a smarter manner. It’s a way of tying the business objectives to the actual delivery product in a way that will be maintainable and is teachable to other developers so that you can grow out the team and not be held hostage by your initial development team who may or may not move on in the future.
Philip: Wow, so let’s unpack that a little bit. I’m reminded of the old ideas are worthless. Implementation or execution is where it’s at. That’s what distinguishes the wannabes from people who are putting money in the bank.
Philip: It sounds like you’re really focusing on the execution, implementation, side of things.
Nick: Right and what it is it’s called framework because we really want to take away some of the guess work behind how to write software. Anyone can learn a programming language and there’s definitely varying levels of talent within that but without having expectations about how the product gets delivered and how to trace back to the actual expected outcomes on each different piece of the product that means at some point you’re dealing with just this mystery ball. You living in a magic world where this software does everything you want it to do and you have no explanation why it does what it does and then it doesn’t work over the long term.
Philip: How did you make the move from we’ll consult with you on strategy to this is the thing you can buy from us. Here’s what it looks like. Here’s the shape. Here’s how long it takes. Why did you decide to go that way instead of doing open ended consultations?
Nick: Well, there’s really two reasons behind it. The first was I wanted to be able to build product for the company. Something that we could deliver time and time again and get better at doing so that means you hear this all the time about how you need to pick a mission. You need to focus on that mission. You need to solve that as best as you can. What that really is saying isn’t that you have to pick a niche. People get too held up on the fact that they need to find a niche and that’s not. They need to do is to maximize the amount of value that you can deliver.
We looked back at our entire history, we’ve been in business since 2005, and we looked back at the entire history of all of our clients and who benefited most from us and did that change and how can we deliver that time and time again so that whoever works with us gets the very best from us and then we get out before that value proposition changes. If you think about education sort of thing. If you’re doing an educational course one of your customers have taken that course and they’ve gotten what they had gained from it they should stop paying you.
I believe the same is true and we talked about this earlier about how agencies are really great in the beginning and then something changes along the line and you may want to change organizations. It’s not as great as it was in the beginning so I wanted to design a package that would allow me to do that really great experience and get out before it stops. We could have this really great expectation and really great reviews and deliver that time and time again and then deliver process internally that would let us get better at that.
That’s how the product came to be but the actual product itself was based on our own experience where we looked back at the customer history we’ve had and we found one in particular that was almost a perfect fit and it went where it was about a six week engagement which is what we picked for the length of the product to start with and the client was just absolutely impressed with our attention to detail, the processes we have in place, and the fact that we’re building in quality right from the beginning but as is the case with trying to work with an agency it’s always cheaper to hire your own developers.
For the smaller businesses cost can become a concern and we wanted to get out before costs became a concern so that was one of the reasons why we wanted to do a fixed price on this so that you could budget for it. You could have expectations around it and you wouldn’t have this big scary open ended sort of thing where you’re now held hostage to this agency and you end up spending way more than you want to with them.
Philip: That’s really interesting.
Nick: Yeah,I believe that the power in the future is smart businesses are going to build their own software teams. This maybe true of your business but I think that programmers are going to be hired by nearly every business out there either directly or indirectly and we want to help build those programming teams and use all of our experience to do that and most importantly get out before it becomes too expensive and the numbers stop making sense.
Philip: When a business that has not had an internal programming team assembles one it’s almost like they’re entering a new market in that they don’t have, they maybe able to acquire the talent to do it right but they don’t have the institutional history with that right?
Philip: It sounds like you’re providing in a very short amount time an accelerated ramp up?
Philip: This is not just for startups because I started out thinking wow, this is great for startups who are coming together and gelling around a product idea but it sounds like it has broader applicability.
Nick: Yes, it does. It’s almost as valuable or more valuable for the business owners themselves than it is for the developers. The developers are great because they’re going to have to be able to communicate effectively with the business owners but it’s more of a course for business owners themselves to form expectations around what it takes to build software that works. That’s not an easy thing to do because developing software is unlike pretty much anything business owners were unaccustomed to dealing with have ever dealt with before. That’s the reason that you see so much churn with freelancers and agencies.
You’ve seen that we’ve worked with projects where we’re like the fourth or fifth agency to work on the thing and the reason is at that point no longer the fault of the developers of the previous agencies. It’s the fault of the business owners themselves and no one has the balls to tell them that because they’re the customer and the customer is always right except when they’re not and they need more education. It’s not an easy thing to go out and say that but it is a educational thing that needs to be given. There’s expectations that come with the programming team that are unlike any other operational experience.
Philip: You keep using creative and it seems to me it’s almost like hiring a team of artists and you’re a, I don’t know, a manufacturing outfit and you’ve never worked with artists before so you have to learn to speak their language to get the results you want.
Nick: Yeah. Sometimes working with developers can feel like herding cats. It can work but you have to make sure the rules are clear and if you have that base of standard operating procedures. This his how we do things, this is what the expectations are, developers are very very good at following rules. That’s what computers are. They’re just basically machines that follow rules and if you have no rules in place for your development team then they’re just do their own thing and it’s not going to lead to an outcome that you really want. What we do is we help organizations build out those rules and expectations so that their developers can follow those rules and then it turns into something that is predictable and sustainable and you end up getting a good result out of that.
Philip: Reflecting on this earlier conversation we had about risk and what’s your philosophy of risk. It seems to me it’s something you didn’t say explicitly is don’t ignore risk so you’ve seen in your agency experience or don’t pretend like it doesn’t exist or it’s just a fact of life. Design around it.
Nick: Yeah, one of the conversations we had internally just this morning was the fact that we’ve seen clients make decisions that oh, we’re just going to do a proof of concept on this. We’re going to push hard in this direction. We’re going to see if this works and then three weeks later that proof of concept is now live running code good to go and then it doesn’t work. It doesn’t work at all because if you build it with a different set of expectations than you brought it with you’re going to end up with a lot of headaches and those expectations bow upwards and outwards to the customers. Then you start getting yourself into trouble taking on a heck of a lot more risk than you’ve ever acknowledged.
You’re right Philip that you need to acknowledge the risk early and head on and be responsible about the fact that you know where you’re taking the risks and then you can do it smarter. It doesn’t mean you don’t take risks. You have to to survive as a small business but you have to be knowledgeable about where those risks are and what they entail.
Philip: It really seems like this product, the framework product, is the outcome of you understanding the risks of the type of business you’re in consulting, software consulting strategy work, and designing something that mitigates those risks, that designs around those risks. It’s a risk we’re going to get fired after about 10 or 12 weeks or whatever. Not fired but the client is going to start seeing less value and naturally decide to take more things in house so let’s design around that risk etcetera.
Nick: It’s very strange because I’ve seen that happen a number of times and it’s the time period is always different and it’s very strange because we don’t change anything about what we’re doing. The clients have changed.
I’ve been really trying to think about how and where that change comes and I don’t know if you’ve had experience working with vendors over a long period of time but they can deliver a consistently excellent experience but at some point either your needs change or your expectations change and that vendor is no longer appropriate even though they’re the same person they were at the beginning, the same company, they were at the beginning and they could be doing excellent work. The problem is not the vendor. The problem is that your needs have changed and we want to be responsible to that. We want to get out before those needs change and allow companies to flourish and make those changes on their own without being so closely involved. We want to give them the tools and capabilities so they can do it in house.
Philip: Yeah, you think that eventual degradation of a client vendor relationship has to do with, what do you think causes that? Is it because there’s the scope of work established and then that becomes the relationship fulfilling that scope of work rather than it being more of a partnership?
Nick: It’s by no means a guarantee that that happens. We’ve had engagements that have lasted upwards of five years.
Nick: We have clients that have been clients of ours since the very beginning but the fact is that people change and businesses change and it’s not always easy to see that from the relationships that you form and this goes beyond any software businesses. This goes to business in general in that the way to be the most responsibility customer and the most responsible business you can is to deliver the value that your clients need, that your customers want, and get out before their wants or desires change. That’s how you deliver a really excellent experience because if you leave them wanting just a little bit more then they go on to refer you and you build a really strong reputation because you’ve been responsible enough to get out when you realize that your value has been expended or when you realize that you’re no longer the right choice for them.
Philip: That’s a really powerful philosophy. I love that.
Nick: Oh, thank you.
Philip: That’s very cool. We’ve got a few more minutes. Let’s wrap up with what we can make actionable at least the people that I’m going to show this video to via my list they’re consultants like yourself. They’re running small maybe even medium sized software consultancies most likely or doing some sort of technical work. What would be your advice to them about risk?
Nick: Well, let me answer. Okay, you asked about risk. I was going to think about actionable. I think the most actionable thing you can do is to figure out how to deliver the maximum value and focus on delivering the most and how can someone get the best of you and do so in a way that you can package and deliver again and again. This really doesn’t answer your question at all. I don’t know [inaudible 00:37:40] is.
Philip: It’s okay.
Nick: I’m sorry but as far as actionable goes if I could give one piece of advice it would be stop trying to find a product. Stop trying to find a pain point. Focus more on how someone can get the very best of what you have to offer, find a way to deliver that, and get out before it runs beyond its due. It’s before you run too long.
Philip: Beyond its shelf life.
Nick: Exactly. Yeah, so if you can design a way that people can get the very best from you and then sell that again and again you can build a business behind that and it can be a product, it can be a service. It doesn’t matter but that’s how you build a business. At least that’s how I’m trying to build my business in a way that I think people will be ecstatic to do business with I’m going to love running. It just brings so many wonderful things into the world that it’s something that I know I have to do and I would encourage you and all of your readers to do the same thing.
Philip: I would interject there’s this great piece of philosophy packaged up as a manifesto called the Win Without Pitching Manifesto. I don’t know if you’ve read it.
Nick: No, what is it?
Philip: I can’t even think of the author’s name. I’ll have to insert something later to point listeners to that. Again it’s a manifesto and it’s really about becoming so excellent in a specific way that you don’t have to play the pitching game where you’re competing against other agencies with pitches. Your customers are coming to you because of your demonstrated expertise.
One of the little nuggets in there that I think is so great is the author acknowledges that consultants, technical people, creative people were naturally curious. Were naturally fascinated with things that are new and different and therefore it is very difficult, almost excruciatingly difficult, to do what you said which is pick one way, a defined single repeatable way, to deliver value and do that over and over again. That to a lot of people usually more on the smaller end of the scale with solo operators and freelancers. They are terrified of that because that sounds like wait, that’s the corporate job I left. I was doing the same thing again and again all day long and I don’t want to go back to that.
Nick: Yeah, however.
Philip: Yeah, you’ve gotten beyond that and that’s what the author of the Win Without Pitching Manifesto promises. He said I promise you if you do this it will be rewarding and you will enjoy it. I wanted to maybe wrap up with you talking about how has it been rewarding and how has that not come true for you? That doing the same thing over and over again, that same value proposition, how has that not been an awful corporate grind for you?
Nick: Because it’s about doing what you love. You hear how that’s terrible advice. Not everyone should do what they love.
Nick: In a way okay, maybe they’re right but if you can do something that you like to do and you can find the way that someone gets the very best from you then you can do that again and again. If it’s something that you enjoy doing then you’re creating more positive outcomes in the world than negative and that’s very rare so it’s prevented from becoming a corporate grind. You just have to I guess just keep raising the bar in terms of how can you make it even better.
If you settle and you stop trying to think about how to make things better, you stop trying to give the very best of you then it can become a crime and it’s just the same thing but if you instead try to think about how to make it as best as you possibly can and then make it even better than that then you can build processes so that you can get it to a good enough spot and then keep going and keep going. That means that every customer that you get is going to get the very best possible for every single customer now and into the future so it makes now the very best time to buy at all possible times.
Philip: That’s I think even a bigger thrill than chasing I guess you could call it the shiny object syndrome where you’re like oh, I want to try this new programming language and oh, I want to play with this new tool and that kind of thing.
Nick: Oh, don’t get me started on that. We could talk for another hour about that.
Philip: Yeah, well anyway. What a great spot to end. Nick, thank you.
Nick: Thank you Philip.
Philip: This was definitely the highlight of my week. Most interesting conversation I’ve had all week.
Nick: Thank you so much.
Philip: Great pleasure and look forward to talking to you again soon. Oh, I always forget to do this. Sorry. How can listeners find out more about you, your company, what you do?
Nick: Just go to buildbettersoftware.com.
Philip: Okay, simple enough. Nick Hance, thank you.
Nick: Thank you very much Phil.