Back in October I had the pleasure of appearing on the Tech Pro Unicorn podcast - the first time that I appears as a guest. The host, Michael Grace, and I covered a number of topics - such as build vs buy, low-code/ no-code and generally tried to put the world to rights'. And with Michael's kind permission, I am re-playing the interview in in full.
Or listen at:
Published: Wed, 22 Dec 2021 16:53:49 GMT
Transcript
Hello, and welcome back to the Better ROI from software development podcast.
Back in October, I had the pleasure of appearing on the Tech Pro Unicorn podcast - the first time that I've appeared as a guest. The host, Michael Grace, and myself covered a number of topics and, with Michael's permission, I am replaying the interview in full.
In the episode, we touched on a number of topics such as build versus buy, low-code/ no-code and generally try to put the world to write. I wanted to replay this episode as there were a number of topics I wish to take a deeper dive into over the coming weeks - all of which are presented in this interview.
I'm already planning episodes on Build versus Buy, low-code/ no-code and Robotic Process Automation (or RPA).
The interview is longer than my normal episodes and does contain stronger language than I would normally have used, but I didn't want to alter it from its original format. If this doesn't feel like the sort of thing you'd want to listen to or maybe you've listened to it already, then feel free to jump forward to the next episode for the return to business as usual. Ok, onto the Tech Pro Unicorn podcast.
Announcer: Welcome to the Tech Pro Unicorn podcast brought to you by RPI Consultants, a podcast about the magic of digital transformation through technology. Each week, we'll cover topics related to ERP, RPA, business transformation, leadership, health care and unicorns.
Michael: And welcome back to another episode of Tech Pro Unicorn, I am Michael Grace, I am your host.
Michael: And today I am joined with a fellow IT-eir, someone who's in the I.T. field, a developer - so very in the very technical weeds, whereas I'm more in the technical field but as a vision kind of person - Mark gets to actually make the magic happen.
Michael: So I'm joined by Mark Taylor. Mark Taylor is from Red Folder. That's his company in development, and I'd like to ask Mark to maybe embellish a little bit more and tell us a little bit about yourself.
Mark: Well, thank you, Michael. Yeah, I've been working in software development for over 30 years now and I've had the privilege of doing a lot of different things over the years. As you could well understand, obviously, software development over the last 30 years has changed quite a bit, but during that time, I've had opportunities to work in both leadership architecture in terms of solution design. More recently into things like DevOps and all the time working in some level of development. And I like to take those that skillset and apply that to my clients when I work with them.
Mark: I'm also the host of the Better ROI from Software Development podcast. We've managed to get to 103 episodes with just over 21 hours of people having to listen to me. So I apologise in advance.
Michael: That's awesome. That's awesome. It's always very cool to me to have other podcasters on on as guests, and I always ask them, right, I mean, we put content out there and we hope people listen right and we're trying to make the world a better place. We're trying to share experiences and share knowledge, and hopefully it's meaningful and help somebody have a better project or a better outcome or in your case, get better, better ROI from from the money that they're spending on all this IT componentry.
Michael: I had one person tell me that IT spend was, on average, 10% of a company's budget - so pretty significant spend going on, a lot of project work, a lot of DevOps and a lot of investment in both the hardware and the software side.
Michael: But from your perspective, there's always the debate: "off the shelf" or should "I custom develop the app?" Could you talk about that paradigm and kind of like, where does it make sense to do some custom development versus just just taking what's given by the vendor and making that your own?
Mark: Of course, I suppose traditionally we've always seen the rules as being build what differentiates and buy the rest. That seems to be the mantra we've worked with.
Mark: Personally, I probably see it as a bit more of a spectrum, and I don't think it's as black and white - it has that the levels of grey in there. So depending on a variety of factors, will drive you as an organisation, depending on what your makeup is in terms of the people you have, the attitude and the appetite to risk, past experiences. There's various things that could affect where, on that scale, you choose to go with a specific piece of work.
Mark: That might be something really large. It may be something very small. So if you're working with a product that you've bought and you want to expand it, you may be looking at what effectively is like "glue code", something that is gluing two pieces together and that could be relatively trivial. Whereas if you're maybe wanting to make a whole e-commerce platform off the side of something, that could be massive. So there's a there's a number of factors.
Mark: I put my hands up: I have a bias.
Mark: I've come from a developer background. And I think it's something that people commonly miss, that there's a lot of factors that you can logically use to decide which of those two routes you go or even a mixture, and we can go through some of those in a bit, but I think a lot of the time it will come down to the people in that organisation who owns the chequebook - they may have their own personal bias, they may have past experiences. And I think it's it is an important factor to remember.
Mark: There's obviously going to be certain things that you would never want to build unless you're Microsoft. You're not going to want to build a word processor - you're going to buy that every single time. And the other end of the scale, if you've got something that's so unique to your industry, maybe it is groundbreaking, maybe it's something entirely new, maybe it is part of innovation and research and development - then you're unlikely to be able to go down and buy that off the shelf from the Best Buy's. It's something that's going to be have to be tailored to exactly what you need to to to match what you want.
Michael: I love it. I love you use that word "glue code". I've never heard that term used, but so, so much of what we do, right when we're trying to get to systems, maybe to work together or or communicate better, you know, I jokingly say we use the word integration interface, interoperability - it's all the same shit. It's really just code to kind of bring data together. And I really like "glue code". That just makes mentally it makes a lot of sense to me what how you describe that.
Mark: Working in that style of having interfaces into systems, it helps us to have a level of options around when we choose to, whether we buy or build. Because if you've got various components that make up a platform, you may buy this bit over here, you may build that bit there and you effectively assemble them together.
Mark: If you have the interfaces right, what you're doing is you're allowing yourself options. That later on, you may have built this part yourselves, and you might have been a quick and dirty piece of activity just to get something in, but you then decide actually over time you need to scale that move to this bought product. And as long as you've got those interfaces right, the clear lines of separation. Think about like a bulkhead within a ship, the ability that you can close off that section and replace it with something else. Then you've got a lot of agility. You've got a lot of ability to change things up as your business advances, as you understand more about what you're trying to do - because parts of software development is a learning process. Very rarely do you know exactly what you want to do on day one. And part of it is going through that evolution of understanding exactly what you need and what's going to work best for your business, and that changes over time as well. So if you've got those ability to interface in, then you've got the ability to swap stuff out as you change. I was listening to another podcast earlier today, and they were talking about when making choices make a two way door choice so that the door can open both ways - so you can reverse the decision - rather than it being a one way door and effectively taking yourself down a position where you run out of options.
Michael: I think a lot of what you're talking about, I describe as like architecture, and I think in your introduction, you kind of stated that you've had kind of that role, right? So many times we go to, I think, the developers or development community and we're like, "We just want this, just go do this" and we don't expect them to think right. We expect them to just be able to go, "OK, let me go code that?"
Michael: And the problem with that is, you know, there's no thought, there's no architecture around what are you really trying to do? I think the magic happens with the developers when you bring them in and let them understand what you're trying to do so that they can understand the picture right? And then they can, so many times we get told what we're doing an acquisition, we just want to bring this data in. Just just go code that how we how we incorporate all this. And we're like "but what about if you divest of that business, right?" That's you're in and you're out. Like, shouldn't we think about in so many times that vision from from a top is so myopic it doesn't allow for the developers to build a robust enough solution to really be truly meaningful to the organisation.
Mark: Oh, I completely agree 100%. Software developers, by their nature, are problem solvers. That's what they do. You give them a problem, they work the best to solve it. If, however, you've narrowed that scope down to say, actually, I don't want you to think about the problem, I just want you to go and do X, then you've instantly lost, depending on the developer, a large, large proportion of their value.
Mark: And I think developers themselves have at times done themselves a disservice by not wanting to engage with the business. Almost having that stereotype of not being approachable, not wanting to talk to people, putting their headphones on, and "I'm just here to turn caffeine into code. That's all I do. I don't want to talk to you. I'm not interested."
Mark: And I think they've done themselves a disservice during that because I've seen so many good developers. When they're engaging with a problem fully and they can have these conversations, they can question, they can go "why are we doing it?" Go through that cycle of the five whys digging deeper as to why we're being asked to do X, Y or Z. They may well be that you come back to the same conclusion, but more often than not, because they've got a greater understanding of it, if nothing else, they do the job better because they're buying into it. They've understood the purpose of it.
Michael: I love it. You know, and I think I'm such a fan of kind of the the agile methodology that that's emerging as a trend, right? Because it involves the developers and the users very iteratively along along the process.
Michael: And one of your kind of mantras is projects can be bad for ROI. Maybe you can talk a little bit about that because I love where we're talking about being interactive with developers. And, you know, I just love what you just said about how it's just a stereotype around like developers as order takers. And it's it's just every time I've had a chance to break through that barrier. I've just been amazed at the potential that's unleashed.
Mark: Yeah. Unfortunately, no one can see me nodding. And yes, exactly, exactly. It's moving away from that order taking process. And to be honest, IT as an industry has as almost based itself around being that order, that order taking and putting in place PMO, project management and working to what I talk about as a spreadsheet project management - knocking tasks off a list rather than necessarily looking at the outcomes.
Mark: And part that is through the maturity of software development and IT. How long have we been doing software development - now we're talking realistically from the 70s. It's no age as an industry and we obviously are looking keenly to borrow stuff from other disciplines. So you'll take things like agile, lean principles that come in from manufacturing, for example, are coming through as people look at how to do things differently over time. And we talk about agile as being a better way of engaging the customer. Now that's nothing new, it's just we haven't been doing that in IT since day one. We started day one working on the principle of what we can do is we can plan this all out to the nth degree, and we can get it defined right the way down, where we build out these big Gantt charts with all the dependencies, all of the the interactions.
Mark: And there's two reasons we did that originally. One was because it was so much cheaper to spend the time writing documents and getting everybody to approve documents and sign off on those documents - and we could spend twenty four months just getting the documents right. It's so much cheaper to do it on paper than it was to experiment and try it.
Mark: However, advancements in technologies, we've moved on so much more that things where we wouldn't have dreamed of doing it maybe 20, 30 years ago are now commonplace. If we want to try and spin up a series of servers, we can go to AWS, we can go to Microsoft Azure, we can spin these things up.
Mark: And unfortunately, a lot of projects for me, and I'll talk about why, I suppose the quintessential project type for me in a second, project types don't really seem to follow on. And I know that's a bit unfair for some people, maybe fully into the likes of Prince2, which does embrace a lot of the same philosophies as agile, but unfortunately a lot of the implementations I find aren't that good. A lot of people misunderstanding how it's used.
Mark: They are working very much on that Gantt chart structure. They sit down and they will spend siloed efforts of time by skill set. They will have Business Analysts go and do their piece, write a document that then gets passed into an architecture team to review and write their document. That document gets passed down to the developer and so on and so forth. Each handoff is having a document in place - and I explain this once to the Head of a PMO and went - you do realise you're getting your business analysts to document all those requirements, the business never reads them, the developers never read them. The developers will basically what they think they need to do, and then they will see what the business say.
Mark: And this was just completely mind blown. And unfortunately, best will in the world, a document, a written document - which is always useful, I'm not going to dispute written documents and they still have value - but they're open to interpretation. So you get a written document that's going down the chain and it's being rewritten for individual's languages, so by the time it's reached from the original requester all the way to the developer, it's probably gone through two or three different languages in terms of how people describe things.
Mark: So if, for example, you then get the business owner is asked to sign off on a piece of documentation the developer's written, he's reading it with his own bias. They're reading what they want to read into it - and some of it, they're not going to understand, but they don't want to sit there and go "I don't understand this". So it gets signed off, and it's only when it comes out the other end of it, do we then have problems.
Mark: But we then do all the crazy things and then round it. We do things like estimations to try and build our Gantt Chart. Estimations, which let's be honest, estimations are always guesses. As such, they will always be wrong. The question is, is just how far wrong. But people take them as commitments, which you'll then get people having to work long hours into the weekends, at night, trying to hit an arbitrary deadline so that they can tick a box to say "Yes, that's done."
Mark: In the same respects, we also get things like overfocus on getting a specific project piece done. So a project by definition is trying to get a specific thing done by a specific time. So if it looks like we're going to miss that, what drops off? We're not allowed to move the time and we're not allowed to miss what we're trying to do. So we drop things like quality, for example. Quality suffers because if we can get it through the project, it's no longer the project team's problem. Its supports problem.
Mark: But you also get things like short term thinking, which is probably one of the biggest concerns I have. Because you've got that myopic focus on a specific thing in a specific period of time, we don't think about the longer term lifespan of that product, and I use the word product on purpose because I'm much prefer the idea of it being considered a product. It has a lifespan, you have the creation, you have the maintenance and you have the destruction phase, which could be in six weeks time or six years time, you don't know. As such, you need to think about what you're building and how you build it - to think about the longer return on investment.
Mark: So when you're getting tight on your project time scale and you're going "Oh, this took longer than we thought it was", well we're drop things, we're drop levels of quality, we'll drop things that would help us in the longer term of ROI.
Mark: Are you familiar with unit tests in software?
Michael: Absolutely. Yep, we do them all the time.
Mark: Yeah, so for anyone who isn't, unit tests are a way of us being able to automatically verify sections of our code. We write that - it's more code, that test code. So think about testing components of a car. You would test the seatbelt assembly separately from the car. And we can do that in an automated way. Now there's an investment in time in actually creating those tests. And it does take time to create them. Now, that gives us better levels of quality, not just when we write it initially, but over time, because those tests can continue to run next week, six months time, 12 months times, six years time, and we can continue to make sure that what we built continues to meet those tests and we haven't inadvertently created a regression bug - we haven't accidentally broken the thing that calculates our profit margins and accidentally selling everything for below cost. You've got those safety nets built in.
Mark: But the problem is when your focus is on hitting a specific thing by a specific date, those sort of things fall by the wayside because it's extra work. It's being seen as gold plating. It's being seen as excessive to what you need to do. And this is where I suppose really it's where with that focus on the task in terms of "yes, we're ticking a box to say you've done this block on a Gantt chart" versus the outcomes as an organisation and what benefit is to your customer is where I much prefer that thinking of looking at it as a product and ongoing improvements - and changes to that product rather than thinking in a project mindset.
Michael: I love it. You just dropped a lot of knowledge right there. Again, you couldn't see Mark nodding at certain pieces and you couldn't see me at one point I even started clapping. You know, it's the coverage there of items, I've seen great programmers and great developers, and I've seen developers that have opportunities for improvement - perhaps we'll just leave it there - but the ones that are really good are the ones where I can just go stand shoulder to shoulder with them and go "Hey, here's kind of what we're trying to do". And they're like "Oh, OK". We're like collaborating collegiately, throwing spaghetti at the wall, going, "Yeah, OK, can we tweak this? Yeah, OK, great". And it's just evolving.
Mark: And I think you made a comment that, you know, agile as is often kind of misunderstood. I've been part and partly to people that are hell bent that they're going to implement agile, whether the situation is appropriate for it or not. And they just don't get it right. And I believe the true intent of agile is to bring all the parties together in a collaborative short sprint, you know, with the intent of of kind of short circuiting some of that unit testing and having it more more readily fail faster, right? Like figure out, don't don't just wait. I mean, I've seen developers go away and you're like, "What are they doing? What are they doing?" - And then they deliver a piece of code and you're like, "That's not what we need". You know how you're in unit test and you don't have anything and you're like, "Well, shit"
Mark: We've all had the projects that have come back 12 months later to find that really wasn't what we had in mind. I mean, it's going back to that, that agile mindset. If you if you don't mind, have you come across the agile manifesto before?
Michael: Yes. Ok. Yes.
Mark: So 2001, a bunch of thought leaders sat down and wanted to describe how they wanted a number of processes that were floating around at the time, a lot of efforts to try and make software development better, and they they wrote down the Agile Manifesto down in 2001. And if you allow me, I'll just read it a second because I think it's a good piece of work for how short it is.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Mark: Now, that's been an underpinning for the last 20 odd years for for agile movement and the various other software approaches that have come in after it, and you're right, there's a lot of people don't understand the core principles behind it. They misread it and they go, "Well, you're talking working software over comprehensive documentation. Excellent. No documentation. We're not writing anything down anymore."
Mark: No, that's not what the intention is. Documentation is useful, but it's having it in the right place. It's having it at the right time. Working software is more valuable than a document describing how you want the software to work. But having documents, for example, to describe why certain decisions were made, so that in six months time when a new team have to pick it up for whatever reason, they can understand why certain decisions were made.
Mark: And it's interesting that agile, unfortunately, as a term like any technological term, has had an amount of spin on it, and it becomes corrupted. And, we're not going too far down that rabbit hole because I'll get upset - but it's it's one of those things that has been corrupted and I've I've seen and I've heard people go, "Oh, we tried our agile, we've done a stand up every every morning and it hasn't made any difference"
Mark: You're taking one part of it. I talked earlier on about not blaming Prince2, for example, for project management being poor if it's badly implemented - and it's exactly the same if you take certain pieces out of any framework and don't implement them correctly. Doesn't matter what you do, you're still going to make a mess.
Mark: So no, I think as a having those fundamental things at heart, the ability to have those individual interactions, the closer the developer can be talking to the people that are going to use the software, the more engaged they will be. I think you talked a couple of weeks back with Patty Murray, and she brought up drive by Daniel Pink - And you know, it's very much that idea of being motivated by those intrinsic motivators. Especially the purpose one, in this case, of understanding what it is that why we're doing something rather than just being given a piece of paper and said, "Go, build that".
Michael: Right. I think gone are the days of there used to be the analogy of "your developers", well, they're not people, you know, they're they're they're kind of behind the door and we just slide pizza under the door and magic comes out that door.
Mark: And there's still a few of them about
Michael: I think your best developers are people like this, right? That can that can have these these conversations that have that desire to understand and the knowledge and they want to produce. I think everybody wants to do good, or at least we should approach it that way with every interaction. And developers want to give you great. They want to give you what you need and want, and they might even have ideas that blow your mind. That might be better than what you thought, right?
Michael: Because you might not know that the software, the tool, the capability that the product can do so much more than even you thought of. And when they enlighten you and empower you with that together, right in that partnership, it can go farther than perhaps it was in that order taking scenario when you just here's a piece of pizza, give me some code.
Michael: I had a great interaction with a developer who was on one of my teams and he said "And you have the worst job in the world and I have the best job in the world". I said "Wow, OK, how did I get the worst job in the world?" And he said "You know, your job is customer facing and you have to go all over our company across the country and you have to talk to all our customers. I can't stand that, you know, I'm back here and I just get work to do. I have the best job and I can just sit here and do my work".
Michael: And I said "I'll challenge you that you have the worst job in the world because that's horrible. You have no idea of the challenges the organisation is facing and you're not sitting side by side trying to solution problems with with our customers. To me, that that that's the worst job. You're just sitting here being an order taker, you know?"
Mark: That's the magic, isn't it? It's the magic you can see what you're doing is having, I'm going to say, in effect - it's nice if it's a positive effect - but it's having an effect. You can see that what you've done is, I'm over grand-desising a little bit by saying, changing people's lives, but it's improving things. It's making things better. And even if it's not improving things, you learn from not improving. So if you've done something and you find it didn't help, let's do something else. Let's find out what else does.
Mark: And it's such a great thing to be able to, you know, regardless of who it is, you know, whether it's the CEO or someone on the on the warehouse floor, Iif you're able to improve their day even by the smallest amount - that's a win.
Mark: And I think, you know, there's a level of pride, and I think a lot of developers feel that. And I think, as I say as an industry, I think historically we've divorced ourselves from that and it has been a little bit of a stereotype of the software developer sat in the back room working in the middle of the night. Nobody sees them, you know, God forbid, if they come out for for caffeine, you know, - and thank God, it's changing.
Michael: Yeah.
Mark: I don't think, I don't think it's quite that way anymore. Don't get me wrong, there's always going to be different personality types. There's always going to be people that are more introvert and need help to be part of that conversation. So they need to feel that that's an engagement where if they are dealing with people that are using the software, they need to have that level of trust, which obviously needs to work both ways. And this is where you get great things from - where teams work together very closely, where the software developer is working with the person that's using. You build that relationship, you build that level of trust, you build that rapport so you can have a conversation and you can go "I was thinking, what do you think about doing this?"
Mark: And sometimes it's the quietest person in the room that will have the best ideas. But building that level of trust where they feel they can bring it forward.
Michael: I love it. I love it. Some of the best relationships I've had. I had the pleasure of leading it my last position, a fairly large app dev team. And they were they were my favourite people to hang out with. I mean, that team was always thinking and they were funny and they had, you know, but you'd sit in a meeting with them and they just sit there quietly, right? That, you know, don't misinterpret that. Those those folks are important. There's so much movement right in the industry.
Michael: You mentioned something else that I really picked up on about the misinterpretation of it terms, right? And then you said, don't get me started on that because it'll get me fired up. So, so part of my world is in in the artificial intelligence space, right, which is also misinterpreted highly and used far too liberally for anything almost. The really isn't artificial intelligence yet. We're working on it, but we call so many things artificial intelligence or AI, and I think it's become just this brand for a variety of random software all getting renamed.
Mark: If you haven't got a machine learning model, on the block-chain, using quantum, then you're really not playing the game properly.
Michael: I love it. Yeah, yeah, we all should be there.
Michael: There's this huge movement in that space, whether it be robotic process automation or there's a variety of tools out there now. Everybody has a tool that's all this low-code, no-code kind of applications. And they, you know, you don't need to learn any programming languages now. You can just use low-code, no-code tools, and you can develop the same thing. What what are your thoughts on that? I mean, to to to me, it's kind of interesting and people really are excited about it because I think people have a fascination with development. But low-code, no-code, I think, is a bit deceiving, at least to me. And I'd love to hear your thoughts.
Mark: Ok, I suppose, first off, anything that allows, I'm going to use a fairly umbrella term of business user, to be closer to technology for me is great. Anything that allows someone that understands a domain they're working on that can bring ideas to the table, breaking down barriers to be able to turn that into technology. That's great. That's a win. Anything we can do with that. I'm all for that.
Mark: What I do worry sometimes with things like low-code and no-code is that it's being branded as it's "not software development". And in doing so, we forget the lessons that we're learning from software development. I talked earlier about it's a fairly immature industry. It's very young, it's learning all the time. And for me, no-code and low-code is still programming. You might do it from a visual editor, you might drag and drop, you may do very limited text, but it's still providing instructions to a computer to do something.
Mark: And as such, I really like to be able to see the same disciplines that we find in, oh sorry, hope to find in a professional software development team being applied to those same characteristics. So having the ability to have source control so that we have versions of changes, making sure that it's testable, making sure that we can deploy it and version it, making sure that we've got an ability to secure it properly.
Mark: And I'm sure every I.T. professional in the world has been approached by someone in finance going "Jeff's gone on holiday, but we don't understand what his Excel macros do".
Mark: The whole business runs off this spreadsheet that has Excel macros that, to be honest, could have launched the space programme. Nobody else understands it. And yet you as IT are expected to - "Well, you do computers don't you? Can you not understand what it's doing?"
Mark: Short answer is no.
Mark: And that's what we need to avoid. Don't get me wrong, Jeff was great. He wrote wonderful, wonderful systems while he was there. Work a charm. The business ran off it. The minute he went on holiday, we struggle as an organisation.
Mark: So it's applying those same disciplines of being able to make sure that we can repeat the code, we can understand what changes have been made, when by whom we can reverse those changes out and revert back to a known good form. We can test them. We can understand why certain things work the way they work.
Mark: As long as those are applied to to low-code, no-code, I'm happy with it because it does bring more people into development. And I think there's an argument to say as time moves on, very few of us will not have some element that involves providing instructions to some form of computer to do something - whether that's a robot, a robotic automation, whether that's workflow management.
Mark: We find even now very simple things that even if we do automatic responses in our in our email programmes, if we go into outlook and set rules, those are instructions to the computer to do something. It's a layer of abstraction. It's making it easier for you to understand it. But in the same respect, when I develop stuff day in, day out, I'm not working directly with the bits and bytes, with the electronic signals in the hardware of the computer. I'm working in an English-sized language that tells computer what to do. I'm working on probably two or three layers abstracted from the hardware. All no-code, low-code is doing is working another layer of abstraction above. So it's trying to get those same principles in if we can get them.
Michael: I love it.
Mark: It also acts as a gateway drug to get them into proper programming.
Michael: Yeah, yeah. I love what you say because it draws the business user closer and I'm excited about that as well.
Michael: I think our vendors that are just trying to sell licences sometimes to some of the software don't do us any favours, right? And they they oversimplify how easy it is.
Michael: "Oh, you as an accounts payable clerk, can code software". Yes. No, sort of. And they make it seem so dumbed down that the business can do it without IT. Right. So anytime we go into a customer, I always tell them, like, where is IT? And they're like, Oh, well, the vendor sold us this and said, we don't need IT. I'm like, well, if we're doing this without IT, I'm out, right? Find yourself somebody else and call me when you need me to come back in and clean this all up because it's going to be a disaster.
Michael: So, we did a test at my last company. I worked at Dignity Health, which is a really large health care provider out in the western United States. And we took some of this low-code, no-code software. And it was really interesting because the vendor was like, you don't need any experience, none. And I was like, wow, I want to test this, right? So I put two of my IT developers on it. Let's go learn it and you're going to go develop. And I took two people from the business that were super users, right? I told the business, Give me your best and brightest, your smartest people - took two of them - so we had four people.
Michael: They went through the same training. They went and they had the same assignment to do the exact same thing. I had one IT person finish it faster than than the vendor had seen it. I had another one right behind him finish it - and went off and did the coding, had error handling and all that good stuff that you'd expect from from a developer.
Michael: And then one of the people from the business side didn't complete it. They couldn't get through the concepts and the training. We had somebody get through it, she wrote it, it functionally worked. But there was no error handling. There was no documentation. You know, the IT guys finished it and then documented the configuration and everything and said "Here we go. I'm done".
Michael: So so I think, you know, some of these vendors just kind of do a disservice with this low-code, no-code and they sell it as you just don't need it. And that stems from a root problem that you kind of alluded to that people see it as expensive and a project management laden, and they're going to slow us down, and it just doesn't have to be that way. I think there's a new world of IT that that changes that paradigm.
Mark: Oh, I fully agree. And this is where the concept of Shadow-IT comes from. Where, Yes, the business, rather than going through, especially if it's any size, going through some project management office, creating some sort of initiation document, raising various paperwork, going for various meetings, doing this, doing that, jumping through hoops, trying to get the priority, trying to grease the wheels. They can just take the credit card, sign up for something and their team are using it by the end of the afternoon, which is great. It means that they can get on and do things.
Mark: And all of us just, you said it earlier on, all of us come to work wanting to do our best work. We want to do the best we can. And, I honestly don't blame business owners and business leaders from doing that sometimes because they want to do the best job they can. It does obviously cause a problem later on, potentially where you have to bring that back into some form of governance piece, for example. Or it wouldn't be the first time that that system dies on its feet after sort of like the entire business is running on it and it expects to fix it - going back to our Excel spreadsheet - and they've never seen it before.
Mark: They have no idea what it is, and yet the CIO or the CTO is suddenly on the block. For "Why is this broken?", "What is it?", "I didn't know we were using Salesforce over here. No one's told me that it even exists".
Mark: So yeah, it's again, I suppose it all comes back down to that breaking down barriers, having a closer relationship across the entire business. I mean, we shouldn't really be talking about IT and the business, which we traditionally do and we still do. We are all the business and having people going back to what I was saying before about products, trying to have the team, the entire team, whether you are marketing, sales, an IT developer, someone else, whoever you are being part of that holistic piece around some delivery and value stream that you're delivering out to a customer or whether that be an internal customer, external customer. People all wrapped around that piece, so you're all working together looking at how you can build stuff rather than it being the more traditional siloed approach of marketing over here, sales is over here and everything is done as order taking.
Michael: It has to all be done together, right? I get a lot of executives that are like, you know, "Michael, that that sounds great, but that's just a lot of people. That's a lot of work." And I'm like, That's what you get paid for. You get paid to do hard shit, right? Like managing these large projects, developing these, these new products. It's hard work and it's coordination and it's people skills and it's tech skills and you need a village, right, to deliver true greatness.
Michael: And I loved your analogy about "Oh, we didn't know we were using Salesforce". I sat on a customer advisory board for a company called Netscope, and they're all about managing your exposure in the cloud and your cloud presence. We installed a sniffer and people would be like "Here's our application portfolio. We have these eighty three apps" and we'd be like, "Well, did you know that these apps are being used in the cloud?", "No, they're not.", "No, really, they are. They're coming out of your domain and your users are actively putting your company information into these apps so you're not managing and have no idea about".
Mark: It's my entire customer base is on Dropbox.
Michael: Yeah, you're right. Right. And people are astonished, right? And it's it's from an IT perspective. I challenge my I.T. leaders that that listen, do better, right? Get closer to your business and partner with them. And and that's the best way, right, that that collaboration is the best way to disarm them if you're sitting with them and having these discussions. They're not going to go do all that stuff. They're going to stay very, very close to you. They're going to they're going to come to you first. You're going to have a great relationship. It's when it says we're too busy. I don't have time. You don't have enough money and you stiff arm the business. You know, they're not going to go "Oh, OK, thank you. I'll just sit here and wait until you have time for me". They're resourceful people, too. They're going to go out and get their stuff some other ways. And you're just not going to know about it until it's too late. Until they bring that spreadsheet to you and "go fix it" and then you can't. And that's kind of I mean, I know we like to blame the business a lot, but that's kind of your fault. You created that scenario that creates that.
Mark: I fully agree, have you ever read the book "War, Peace and IT" by Mark Schwartz?
Michael: No, but I think I will.
Mark: Yeah, it's actually a companion piece to it - he's written two books - which are almost the same story. "War, Peace and IT" is effectively a book to the non-technical executive. So CEO, COO, CFO in terms of how to deal with it. And it talks about a lot about moving away from all the requirement driven stuff that, a lot of stuff we've talked about in here, actually.
Mark: But he's also got, I want to get the right books, he's done a few, but I think it's "A Seat at the Table", which is the same subject, but written for the CIO or the CTO. So that technological in terms of, with you going to be at that level in the board, then, these are things you need to be thinking about. Rather than acting as an order taker, you need to be coming forward and having those conversations. So I'd certainly recommend "War, Peace and IT" to non-technical execs. And if I'm honest, I've not read the other one because I've read that one. And it's a brilliant book. But as I say, the companion one is written, which was written before it, was actually for the technical leaders.
Michael: I love it. You know, the world of IT is evolving and changing, and I think we're all trying to do our part to to help guide people through it, whether it be from a consultative nature or from a developer perspective. And IT leaders such as such as Mark brings to the table. So we've covered a bunch of really cool topics. We hit on agile. We hit on development. We hit on low-code, no-code. We hit on off the shelf and custom developed solutions. All topics, you know that if I opened my email over here on the other screen, I'm sure somebody is asking something about one of those on a pretty, pretty daily basis. So if folks want to get a hold of you and get some help, either either with development projects or maybe even, you know, we get a lot of questions where folks want to "How do I how do I raise the bar in my app dev group or team that I have?", "How do I how do I better lead or better help that group develop?" - Mark is out at his own site at www.red-folder.com. I assume Mark, that's a great way that they can get a hold of you and and get your information and contacts and such.
Mark: Yeah, of course. By all means, there's also the podcast or directly on LinkedIn. I can provide you with the links, if you've got show notes somewhere,
Michael: I will put that, I will put the link to Mark's podcast down below as well.
Michael: So "glue code". that's what I'm taking away from this. That's a cool word that you're going to. Everyone's going to hear me and they're going to be like "What is glue code?" I'm like, "You've got to go find Mark Taylor - all about glue code".
Mark: Awesome.
Michael: Well, Mark, I want to thank you for taking the time. It's it's been great having you, and I appreciate your insights on just such a critical topic. Again, on average, companies are spending 10% of their overall budgets and such on IT. It's important we get it right, and I appreciate folks like you in the industry giving your your intellectual knowledge to try to make this a better experience in more productive and so folks get better ROI out of their investment.
Speaker4: It's been an absolute pleasure. Thank you for having me.
Michael: Awesome. Thanks, Mark.
Announcer: Thanks for joining us this week on the Tech Pro Unicorn podcast. Make sure to visit our website at www.techprounicorn.com, where you can subscribe to the show and catch our latest blog articles while you're at it. If you found value in this show, we'd appreciate a rating on iTunes. Be sure to tune in next week for our next episode. Remember, unicorns represent the magic of digital transformation that occurs when business process is enabled with technology.
Hi, Mark, here again, I hope you enjoyed listening to that episode. I'm going to use it as a backdrop for a number of topics I'm going to do over the coming weeks.
In the coming weeks, I expect to do episodes on build versus buy, low-code, no-code and robotic process automation (RPA). I really want to expand on these topics. There was many more notes I'd taken that really didn't have time for us to cover properly in the original interview.
So I look forward to speaking to you again next week.