Voices in DevOps – Episode 16: A Conversation with Nelson Petracek of TIBCO

Guest

As the global Chief Technology Officer (CTO) at TIBCO, Nelson Petracek is helping to shape the development of TIBCO's emerging technology platforms and products. With over 20 years of experience, Nelson works to deliver solutions for the next stage of digital business, drawing upon his deep knowledge of cloud, blockchain, low-code applications, microservices, and event processing. A strong technology evangelist, he works with customers to identify and define the appropriate use of various technologies and architectures, and advises on best practices, DevOps, and information delivery patterns. Nelson received his Bachelor of Commerce in Computational Science from the University of Saskatchewan.

Transcript

Jon Collins: Hello and welcome to this episode of Voices in DevOps, where I’m delighted to be speaking to Nelson Petracek. Have I pronounced your name right there, Nelson?

Nelson Petracek: Yes that’s pretty good. Petracek, yes, I’ve been called much worse so that’ll definitely work for me.

It seems to be the world of DevOps is blessed with people with difficult to pronounce names. Every time I open this thing with: I hope I got that right! More seriously, you’re CTO at TIBCO, a company of long standing and we’re here to talk about DevOps. TIBCO wouldn’t necessarily be known in DevOps, so why don’t you just tell us a little bit about yourself and how you got to this point, and TIBCO got to this point. Where are we coming from here?

Sure, absolutely. Happy to be here and happy to see where this conversation goes. From my standpoint, I started life as a developer, so it’s been interesting to watch over the years how the technologies that support development have evolved, but it’s also how the practices that support development have evolved as well. I think we’ll probably get into this in the course of the conversation around DevOps.

When you look at some of the work that we’ve been doing, both at TIBCO and even [in] my prior life and so on, it’s really evolved to the point where - and this has been going on for years - but the people want to do everything faster, they want to do everything with a higher degree of quality and they want to get business results out to the customers, again, better, sooner, faster and so on.

We’ve definitely seen, probably the last handful of years, a large uptick in that kind of focus. It used to be before that, you’d put a bunch of developers in a back room, they’d follow some kind of waterfall model and six months later, they would eventually produce something. Your choices of tooling were rather limited. I remember trying to pick amongst maybe three programming languages at the time, realistically, for building enterprise applications. Now that’s of course very, very different.

This need for speed and agility and all the supporting technologies around it and what that enables, I’ve really seen a big shift in that area, in terms of how organizations look at this, over the last handful of years. We’re not talking 20 years; maybe in the last 5-ish, I would say, we’ve seen a lot of renewed interest in having this type of capability.

TIBCO has seen that as well. TIBCO’s been around for over 20 years, and we’ve seen that evolution. Also, organizations have gone from, ‘I’ve got a bunch of IT guys in the back, they program some stuff and eventually I’ll get some business value out of it,’ to ‘Can we get new services, new capabilities, new business value every hour?’ That’s very, very different than what it was in the past.

There’s two things I want to pick up on there. The first is: I’m scanning your LinkedIn page as we speak; sorry, I’m stalking you here. One thing I noticed that really jumps to my attention is your education. You actually studied computational science. The reason I mention that is because I also studied computational science. This was before it was even computer science.

Yes, yes, absolutely. I mean –

Did you do all the same stuff I did like logic and stats and goodness knows what else?

Yes, absolutely. Your AND gates and exclusive OR gates and how you can wire all those things together, yeah, yeah, I went through that whole process as well, absolutely.

Kids of today, they don’t know six different ways to build a logic gate, do they?

No, probably not. (laughter)

The other two things I wanted to pick up on, and I’ll say one quick and then I’ll say one more slowly. One is that your background’s in complex event processing. That obviously begets IoT and all of that, which I’d really like to get into and the relationship between DevOps and that world.

The second thing is something you said about the backroom; you mentioned it twice. As a counterpoint to what you said, I remember watching a major large scale waterfall project with hundreds of developers on to it and what I really deeply wanted to do was take a really small number of them and put them in a backroom. Nothing was getting done in the big project and I just wanted to say, “Look, can I just have ten of your really smart people and take you away and then you will build something?” No one was building something; it was all too big. It was too cumbersome.

I know, and I’ve been on projects like that. I first started my career working for a small consulting firm. They had products and things like that as well. We started working with the police department and actually later, a fire department as well. That was very much one of the original issues. The team was just too big and then what they did was they took a group of us and threw us into a smaller room and we worked in that room for a while, effectively adding capabilities for these particular systems for these projects.

No, it was fun. You get taken into the backroom and shown what was confiscated that weekend from the police and undercover standpoint. We also lit a monitor on fire back on those days, when we were working on the fire project, so yeah, interesting times.

Oh boy!

Even then, it was around – it was entertaining. Even then, it was about shifting away from those huge waterfall models into these smaller agile teams that eventually, somehow magically, in the end had to bring all the pieces together and get them to work. That was some of the pre... before DevOps became cool.

I think it’s not necessarily that everyone’s striving for DevOps as this, ‘oh, got to better, new and improved, new and improved.’ It’s that the old methods really were horrible. Get me away from that world of hundreds of people struggling to even deliver one thing and being stuck in ‘me, too.’ .

Right, yeah, yeah, no that’s very true. All the tooling and that has evolved and the business of course wants us to be very agile. Again, quick time to market and meet customer demands quickly. Everybody expects information now. We’re so used to it on the consumer side, where we’re trying of course to mimic that on the enterprise side.

Wouldn’t that be nice! That’s exactly where I wanted to go. You’ve got your job; a CTO is a two-way title as far as I’m concerned. It’s both helping internally define architecture and strategy and vision and direction, from a technical perspective. Then it’s also liaising with customers and helping them deliver on some of this stuff. Is that roughly your role?

Yeah, yeah, correct. I would say that the way that we’ve structured it at TIBCO, the role is very much a field-facing role, even to the point where I have a dedicated team. We refer to it as ‘TIBCO lab.’ It’s a dedicated team that specifically looks at emerging technology and emerging development practices and helps customers understand where those might fit. That can be of course technologies related to DevOps, but all the other ops that are emerging now, whether that’s AI ops, which is really, kind of, an extension but different. Whether that’s model ops, which is, again, an extension but different.

All these other flavors of ops are now emerging, so a lot of the work we do with customers is helping them understand which ops are you looking at and how are you going to try and, not guarantee, but I guess help make sure, or at least being the best mechanism by which you can be successful with such practices. That’s a lot of what I do: work with engineering and then bridge engineering to the field and then spend a lot of time with customers, helping them to understand some of these concepts and technology areas.

Which is perfect; even better than I was hoping. Given the fact you’ve got that really strong customer focus – this is an utterly broad question so bear with me, we can focus it down in a minute. If you were to characterize what makes DevOps so hard in the enterprise – if we were talking in a bar – it’s nine o’clock in the morning for you so we’d best not get the beer out just yet!

Nothing that I’d admit to anyway! (laughter)

It’s just between us, no one will hear. If you were to characterize the kind of – the Pareto principle of DevOps, what’s the 20% of the problem that’s affecting 80% of the people out there, what would you say?

The first thing I’m going to say is what it’s not. It’s not the technology. Yes, you need to understand the supporting technology, to get trained on the technology, you need to figure out how to adopt it and so on. In many cases, I’ve seen the majority of the challenge is either based on organizational structure, which can also include culture, or just expectations. Everybody hears about DevOps and how much money it can save and how fast you can deploy software, you can get new features out in 2.5 minutes, everything like that.

Then when that doesn’t happen, then there’s this big, ‘whoa, what’s happening, it must be broken.’ They blame the technology. They blame this, blame that and so on, when they’re not even sure how to measure it. How do you know how successful you were, if you weren’t measuring it in the first place? Just because you weren’t getting these features out every 2.5 minutes – maybe that is successful. You don’t know. Some of the technology: absolutely, but a lot of it is just organizational structure, culture and expectations.

You mentioned measurement there. Is that part of that or is that a separate thing?

I think it’s related. I think in some cases, people forget that you don’t just bring new technology in. Even if you come up with the latest and greatest way of using it and so on, if you can’t measure how well that technology is helping you, what is the value you’re getting out of that technology? How well is the process working for you? If you don’t continuously measure and evaluate – you can’t just bring the technology in, come up with a process and say “Yes that works and I’m done.” It’s a continuous process.

It’s related to expectations. It’s related to the way the organization is structured. It’s related to the priorities that are placed in this particular area, and even just how people expect it to be within the organization. People forget about the measurement part and how that measurement has to feed back into the overall process. It’s a continuous process. You always want to be trying to make it better. Just doing it once and saying, “yeah that worked, I’m good, that’s the way I’m going to do it, I’m not going to spend any more time on it,” is actually the wrong approach.

Here’s an interesting one because I wouldn’t normally do this on a podcast because we try to avoid talking about products or vendor offerings or whatever, largely because most of the organizations I speak to are actually purveyors of, for want of a grouping, DevOps automation software. Therefore any time that you go into that kind of space, it’s the chicken and egg of solution looking for a problem. What do you think the problem is, Mr. Testing Guy? Oh, I think they’re all about test automation, the test automation company, etc.

If I’m right, as TIBCO is a purveyor of architectural solutions, integration solutions, analytics, everything that you do, but not – DevOps is a hindrance to you to deliver what you’re trying to do, but you’re not trying to deliver against DevOps, if that makes sense. The question I’m going to ask, if that does make sense, is how does it manifest itself to you?

Is it that organizations are just less well able to solve the problems they’re trying to solve? Do you have difficulties of communication? Are they having challenges scaling what they’re trying to do? How does it manifest in terms of consequences?

If I understand the question right –

It’s a waffle!

– in terms of how – go ahead. I can give you my interpretation.

I was waffling on. When you say, well that was a rubbish question, this is –

When you look at it – yeah, from a TIBCO standpoint, we don’t offer a DevOps package, if you will. Our goal is to always keep everything open, make sure that we can fit into or plug into the variety of different DevOps techniques that are out there. That’s just a philosophy of ours. Make the platform open, give you the right APIs and hooks to enable you to run a DevOps process, whatever that might mean for you - because it’s going to be different for different organizations of course - and keep it that way. We’re not trying to lock or keep people restricted into one way of doing it. Do it the way you need to do it, do it consistently across your organization, not just in one or two places; and that’s going to help you be successful. That’s the way we approach it.

Normally, what you find is you need to, again, balance the technology side, picking the right toolsets and picking the right toolset for the proper stage in the overall DevOps process. We find that applies both on the integration or interconnect side of our business, as well as on the analytic side of our business. Whether you’re looking to develop some microservices and deploy those quickly, rapidly, sooner, faster, better, all those kinds of buzzwords, or whether you’re trying to understand [things like]: ‘I’ve got this analytical model, how do I get the data for it? How do I do my data prep, data wrangling. How do I deploy my model? How do I test my model? How do I then monitor the model, as it’s running in an operational context in production? Then, again, how do I turn that into a consistent and feedback loop?’

We find those kinds of capabilities are required across all of our different sides of the business, again whether it’s connecting stuff, moving stuff, creating APIs, or whether it’s making stuff smarter; “stuff” being the technical term here in this particular context. That’s the idea. We do see that all over and so a lot of the work that we do is [around] how do we enable organizations to plug our capabilities into their process, to, again, create this end-to-end automation mechanism or automation part of a DevOps practice. How do I make that overall mechanism smoother, faster so I can roll out these capabilities as I need to?

I don’t know if that answers your question, but that’s a lot of what we see, again, across the span of the capabilities that we provide.

I thank you for framing things better than I did and I’m thinking, given that you are agnostic to the process, you could have waterfall – you wouldn’t care, you’re trying to provide certain things. You’re unbiased in terms of the challenges that DevOps causes both your customers and yourselves, and you’re there trying to provide analytics. If DevOps is getting in the way, how does it manifest itself? What are the challenges that – yes, sure, it’s organizational structure, it’s culture etc., etc. What does that mean? Does it mean it’s all running slow? Does it mean nothing ever happens? Does it mean delivery is suboptimal? Does it mean quality? What does it mean?

You answered half the question for me, but it’s usually it’s a lot of those items, absolutely. It’s usually the lack of speed. You’re not seeing the speed – or you’re only seeing the speed in a particular subset of the end-to-end process. Normally that’s either because the teams aren’t configured properly, so you’re treating each function within an overall DevOps process as a silo, or the development teams don’t have a DevOps person plugged into the team. You’ll normally see that there will be – and if you’re measuring things properly, which goes back to our original discussion around metrics and measurements, but if you’re measuring things properly, you’ll soon see that. Everything is fast, then all of a sudden, boom, at this point it becomes slow. The question is, well why is that?

I’ve heard the term, “water-scrum-fall” and things like this where part of the overall process is agile and part of the overall DevOps pipeline is automated and there is a team and there is integration between teams and so on, up to this point. Then from this point forward, it becomes waterfall, so you’ve introduced that bottleneck. You’ll see it then as a lack of speed, if you will.

You also see it in things like an overall lack of quality. You will have situations where if you want to deploy faster, faster, faster, faster but the quality is doing down, down, down, down. That can also manifest or be an indicator of a problem with your overall DevOps process.

Things like lack of training... I’ve seen very, very cool spiderwebs of DevOps tooling. This tool calls that tool and this other tool then calls this other tool and when the moon is full, it all works properly. Other than that, there’s the DevOps pipeline itself breaks because it’s all bundled together in these weird and wild ways. You can even take the technology and turn that into a spiderweb of complexity and as a result, your overall DevOps process will be impacted.

Security’s another big one. I’ll mention that as the final one. I could go on and on with some of these. Security is also a big one. You need to be able to make sure you’re baking security into every point within the DevOps process that you need to. Whether that’s doing vulnerability checks or looking for scans in the code to make sure you’re not doing anything evil or bad, like putting passwords into code or whatever. That also has to be a primary part of the overall process and not an add-on. Normally, what happens is you go through the whole process and then somebody at the very end goes, “What about security?” Then they tack on the pieces at the end, and that’s not going to be as efficient as if you’d thought about it at the beginning.

I’m nodding sagely as you’re saying all of that. It reminds me, we did some research earlier in the year and one of the main reasons – it was one of those questions where you could say ‘yes’ to whichever answers you like. It’s not the reason above all others, it’s just the reason that everyone cited more than all the other reasons, was the reason that people start doing DevOps in the first place is to increase quality, which struck me as pretty interesting. I just want to do better stuff.

Then the thing that was the biggest issue above all others was: it was more expensive than expected. All of those things that you’re saying can bundle together in: ‘We’re just not achieving as much as we thought we would at the price we’re having to pay. The value is not as high as it should be.’

Right. Yeah, I do see that. I see cases where people start off with a DevOps process and it'll increase our innovation, it will allow us to respond to customer demand faster. Will there be features to make the customers happier and so on? What happens is they say, “okay, yeah, that worked. We were innovative, now we need to cut the cost by 50%.” Whoa! How do you balance those expectations around, well do you want to be innovative and create all those new things sooner, faster, better, as I keep saying, or is it really for cost reduction, which I need to take a different approach [for]?

‘How do I overcome legacy?’ is the other part that people often forget. I’m going to establish a DevOps process so what’s the core part of that process? Well it’s my mainframe. Well, do you know how that’s going to work then as a result? Some of those things also come into play as well. People forget that some of these older technologies were never originally designed to operate in that fashion and so that’s going to increase the cost, until you sort that out. Whether it’s through additional APIs or interfaces or whatever, as an example.

Those kinds of things people forget about. They just think you can take these tools, plug them in, somehow automate the process, write some scripts and you’re done, forgetting that you’ve got all the legacy that you’ve brought with you over the last 10, 20, 30-plus years. You need to build accounts for that. Then also be able to resolve that, before you’re going to see a lot of the benefits, potentially, from a DevOps pipeline.

Yeah, definitely the costs may or may not be what you expect them to be, and even – again, it goes back to measurement. How do you know what those were, and how do you allocate the cost to the appropriate part? I definitely agree.

I think back in the day – it’s interesting actually, it’s like – I don’t want to just cite Gartner here because I think it’s the trick of every analyst house, so I’ll include us in this as well that we’re great at making predictions but we never, never go back and say whether or not those predictions came true.

We all tend to have that – I’ve done that.

Moving swiftly on from that one and undermining my entire industry. As a very quick aside before we get on to how do you then speak to your customers about improving these things, I wonder whether within that better, faster, discussion that we have – as humans, we have an intrinsic assumption that if it’s faster, it must be cheaper. We don’t need to mention it upfront, but then we get disappointed afterwards and go, “...actually it didn’t quite pan out, did it?” You go, why not? Well, it was more expensive. But we never talked about it being more – being cheaper. Yeah, but it should have been cheaper shouldn’t it? I wonder if that’s going on.

Yeah, yeah, I think you would see some of that. Again, people have a certain expectation set going into these types of technology areas. They hear their peers are doing it or other companies have done it. They hear things on the internet. They read this blog. That sometimes paints almost like a false set of expectations that people try and match. They feel they can achieve that in a six-week timespan. In some cases, you can. It really depends on, again, your organization and what area you’ve picked to apply this particular practice towards.

It can happen but people do – again, based on hype maybe or what they’ve ready or what their peers are doing and have achieved and so on, but forgetting how that applies to their organization. Not every organization is the same, so how does that apply to your organization? What are you trying to achieve? What are the metrics that are important to you and what is the business trying to achieve? Those are the kinds of things you also need to look at. Not just that it was able to check this code out and compile it and push it out into a container and take that to the cloud faster. Yes that’s part of it – but that’s not the only part.

How many deliveries a day? Well, yeah, but does it matter if the deliveries are any good? By the way, I’m reminded, the other thing I wanted to pick up on that you said earlier, which I think is really important, so I want to mention it for the record. You characterized it and I hadn’t heard the term before: “water-scrum-fall,” which I love.

Where I’ve spent a lot of time concentrating on and talking to people about is the notion of bottlenecks where you’ve got an agile process and it’s all mostly agile and yet, I don’t know, testing is causing a buildup of slowness within the system . That’s the principle... behind value-stream management, where you’re looking for those bottlenecks and then addressing them in terms of efficiency. Then also, the other part of value-stream management is the masterclass in turning it into business value.

What you were saying, and if I may, I’m reminded back to my computational science days where one thing you could do is think about electrons moving forward through the wire in order to deliver whatever rare condition they were capable of. The other thing is to think of the holes moving backwards. When I was thinking about bottlenecks, the water-scrum-fall thing is: what if everything’s a bottleneck and only pockets of it are the fast-moving bits, which actually thinking about it, is more likely to be a scenario in many organizations? ‘Yeah, we’re really good at this stuff there, there and there, and the rest of it, most of it, is not very good.’ Do you see that?

Yeah, yeah, you do see that. Your example around testing is probably the one that I see the most. People understand how to set up agile development teams, but then everything tends to funnel into the testing team. If you set up, I don’t know, pick a number: 5, 10, 15 agile development teams and they’re all funneling into the same testing team, well your testing team only has so much bandwidth.

Then stuff starts to funnel into almost a sequential pipeline fashion and then – and I’m not saying the testing team is bad, I’m just saying they’re overworked. They’re not set up to mimic what the agile development teams are doing, and the testing part is not as automated as it could be, as part of the development process. That’s a very common occurrence. Some people say, “Yes, but I need that because I need the control and I need this check in place for regulatory reasons.”

In some cases, there are valid reasons as to why you potentially set things up that way. In many cases, people just don’t carry that whole thought process end to end. I don’t know if it’s an oversight or it’s just people realize that the ‘dev’ part is not just development, it’s actually end to end. It includes testing. It includes security. It includes all the operations, all these things, and you need to construct your teams to match that. That’s where I think water-scrum-fall comes into play, where everything is agile. Boom, you get to testing and now it’s waterfall and everything has to flow through almost like a single-threaded stream.

That’s the biggest criticism I have about the term DevOps by the way, is the fact that actually it should be DevTestDeploySecAI and its value biz thing.

It would not roll off the tongue nearly as coolly as DevOps does, though.

The other thing, I want to just put this out there. I want to say for the record, we love test engineers. I used to share an office with test engineers and we think our problem in life is that sometimes things go wrong. The life of a test engineer is thinks are going wrong all the time, deliberately.

No, it’s a science, magic science in itself for sure.

All of that in mind, you’re talking to your organizations. You’re talking to your customers. You’re talking at all levels from front line to very, very senior and you have the opportunity to say “This is how to make a difference here.” This is what to do. How do you approach these conversations and what do you tell people?

It’s important, of course, to understand where they’re starting from, or the organization is starting from. Where are they at? What is their current structure? How do they support the overall development process? What does it look like today? It’s important to understand that, initially. You need to understand where you’re coming from. Then it’s important to get the key stakeholders into a room and just discuss the opportunity. You don’t need to call it DevOps day one, all those kinds of things. This is just more [about]: what is the business trying to achieve? Normally, they’ve obviously got their goals and the capabilities that you’re trying to bring forward for their current fiscal year planning, things like that.

You need representatives from the business. What are you trying to achieve? How are you trying to achieve it? What are the timeframes by which you’re trying to achieve it? Then you need, obviously, representatives from different aspects of IT. It’s not just the developers. It’s not just the testing team, it’s also operations, security and so on, as we’ve talked about. You almost need to have some sort of workshop and get everyone on a common understanding of the realistic capabilities versus the hype, first of all; an understanding of what is happening today because not everybody in the organization tends to understand that. Code gets thrown over there and magic stuff happens and I get a result. It’s never fast enough for me, but I don’t understand why. Those kinds of things you need to try and resolve and get a common set of understandings of any core basis of what you can build upon.

They need to understand, okay, well how am I going to fill that gap? I want to be way up here, I’m currently down here, so what are the steps I need in order to bridge that gap? Then I always say, “Start with something small and pilot it. There’s plenty of opensource technologies out there; let’s pick the ones that are best going to fit into your environment.”

If they turn out to not be the right ones or one of them is not the right one or whatever, that’ll come out as part of the pilot, then it’s not the end of the world. There’s choices out there, we can pick a new one and go from there. Take a small team, a mix of different people, pilot a small project and measure the results. Then see what went well.

Also, and more importantly in some cases, see what did not go well. There’s no blame. You’re just looking to make sure that people understand: okay, this is a learning experience; here’s what went well, here’s what didn’t, here’s what we need to change. Let’s go ahead, tweak that part; let’s try it again. Eventually from there, they can maybe become the experts, if you will. Then you can farm those experts out to different teams and now start to seed those other teams with that experience and that knowledge gained and you can grow it from there.

You’re also going to need to support, of course, the management. You need to potentially change things like org structures and the way the teams are managed and mixed and so on and so forth. You’ve got to go back to the beginning. Where are you starting from? Where are you going? Get that buy-in. That’s a mixture of different groups, not just IT; and start small, incrementally build. Don’t expect magic overnight.

That’s an excellent five-stage plan and I think it’s a wonderful place to be. If you are talking, let’s say, is it the CEO, or just within IT, what do you do when the person, the very person, who needs to get in with this game doesn’t get it? Literally realize that key stakeholder is not part of the solution, they’re part of the problem.

You need to understand – try to understand as to why [that is], of course. That’s going to be the first obvious answer to that question, I guess. Having an understanding of what their background is, what their thoughts are, what their objections are, are of course important to understand. You’re not just going to say, “Oh well, they hate DevOps so we’re just not going to understand or talk to that person. That’s not going to work.

In some cases, it’s very much a “show me” [situation]. Maybe they’ve been burnt in the past by some of these practices. Maybe whatever the latest, coolest term three, four years ago, which had the same set of promises as what they’re hearing about DevOps, those didn’t really work out. The individual’s been burnt by that in the past and so they’re very wary and skeptical about the latest and greatest set of buzzwords.

In many cases, it’s more of a, almost like a skunkworks type innovation-y sort of project where you can demonstrate here’s where we were before with this small project, here’s what we can do now and here’s the benefits. I instrumented everything, so here’s the metrics, if they’re a numbers guy. Those are the kinds of things that I find can be helpful. Show it. Hopefully, at least you can get the buy-in enough to the point where you can demonstrate it and show it.

In some cases, it’s got to be driven by the business, and the only way you’re going to achieve what the business is asking for is if you apply a lot of DevOps techniques that we talked about, around automation and, again, the end-to-end approach and so on. It’s going to be a mixture. In some cases, it’s just, I don’t know if ‘pressure’ is the right word, but there are a set of business objectives that have to be met, and you need to show that individual that this type of practice, this technique first of all doesn’t require me to completely rebuild everything I’ve ever done.

It’s very pluggable into my existing environment. I don’t have to stop all other development while I’m doing this. I can incrementally add these capabilities and get incremental value. By showing the results of this small project that was done, here’s the actual value. Here’s the numbers. We measured it. It went from three months on the prior project to even three weeks; a huge benefit there. Those are the kinds of things I find can be effective.

That’s fair. I think that’s a great moment to wrap up but before we do, I just want to capture what you’re saying there. Within what you’re saying, there’s a very important element which is, I can’t remember your exact words, but ‘don’t leave them behind.’ If you haven’t got a senior stakeholder that wants to do this, or if you have got a senior stakeholder that doesn’t want to do this, you can’t just say, “Oh well, we’ll get on anyway.” You’ve got to – one way or another, you’ve got to get that group on board.

Right.

The whole job is selling to them. As you say, it’s show, don’t tell. There’s almost an earning the right to scale in there, from the top down. Don’t just get as far as you can and then go, “Now we need to get the head of security in.”

Right, yeah, no, definitely. It’s a lot easier to get all the different stakeholders engaged earlier rather than pull one guy in at the end and go, “Oh yeah, we forgot, we’ve got to talk to you.” That’s not going to go over so well because chances are, you’re going to have to go all the way back to the beginning and redo a lot of the stuff that you just did. It’s a lot easier to – it may seem more difficult initially. Normally, you just want to say, “Oh yeah, no, we’re just going to go ahead and do this because otherwise we’re going to be slowed down.” You have a greater chance of being slowed down at the end than you do if you’d actually waited and brought that person on board at the beginning.

Bingo! That’s fantastic. I’m going to wrap up there. I think that’s a great last word. I’m just going to say, thank you very much, Nelson, for that fantastic insight. Thank you to our listeners for listening and contributing and setting the direction of this podcast. Most of all, thank you to you, Nelson. It’s been a pleasure.

Thank you. I enjoyed the conversation.