Digital transformation, bleeding edge, and legacy tribal knowledge with Nick Lumsden of Online Tech

Ledge: Nick, great to have you! Thanks for taking the time.

Nick: Thanks, Ledge. I really appreciate being invited to the show.

Ledge: Awesome! Why don’t you give a two- to a three-minute introduction of yourself so the audience can get to know you and your example, and then we’ll dive into a little Q&A.

Nick: Absolutely! I am head of operation and product strategy for Online Tech which is a global provider of secure, compliant hybrid in multi-cloud solutions specifically focused on service providers, channel partners, and enterprise organizations.

My background is all in Stage 2 rapid growth organizations. I’ve always been in the technology space. I’ve always been focused on health care and security. I love the service provider space. It’s a fascinating time to be here. There are so much happening in the technology space where organizations are transforming and trying to find their way from thinking like it’s 2008 to thinking like it’s 2018 and what that means.

Frankly, things have not slowed down; they’ve only sped up. And as organizations are trying to adapt to this new world where the speed of need is instantaneous ─ there’s no longer this world of quarterly releases; it’s now a world where the speed of change and IT organizations technology organizations are trying to figure out how to make it instantaneous to respond to their business needs.

And that’s my passion. That’s why I’m here.

Ledge: So there’s a huge space between 2008 and sort of the bleeding edge, let’s say, ML, MI blockchain software development. Choose your poison there.

I wonder what’s exciting about that space between legacy and bleeding edge and making that transition? I think a lot of our freelance audience will probably appreciate and say, “I’d like to work in those major transition points. I would like to help bring a company from sort of years ago into really exciting stuff.”

What does that look like from the service provider perspective?

Nick: I can tell you looking at the businesses out there and the opportunity for these businesses to transform, the buzzword out there is “digital transformation.” That’s what we’re talking about ─ going from legacy to cloud makeup.

Not all workloads should fit into one bucket. We talk about public cloud. We talk AWS or Azure. There are workloads that should be going there and we need to plan to get them there. But if you take all of your workloads and you put them there, you’re going to run into some problems.

What the conversation is about is where an organization is today and the plan to get them there. Technologically, we can all go figure that out but, honestly, the biggest hang-up to these transformation is around culture and the people.

How do you go from 2008 and think of workload. We’ve named them. We know their idiosyncrasies. When a certain server starts to act up a certain way, you know exactly how to take care of it. To a world of today where we treat our workload as cattle that if one of them dies, we just create a new one. And that is a huge cultural shift for technologists inside of these organizations that need to move a whole lot faster.

Ledge: You’re making me laugh because I can completely resonate with that. I actually remember the server names at one of my jobs back then. I can rattle off for you when each of the servers had a problem exactly what we would do because Glenlivit just burped and they’re all named after scotches.

That’s fascinating. How do you see it all fit into the CI/CD software development, software engineering flow, automated testing, all this stuff?

I talked to an interesting guy the other day who is kind of at the forefront of bringing Agile to mainframe environments which I thought was something you don’t hear about a whole lot.

You think legacy systems, sometimes, at best, you’ve got a Unix Terminal; at worst, you’ve got sort of this monochrome screen; and legacy ops don’t really get a whole of sexy points these days.

How do you bring those people along for the ride and help them get along with the 26-year-old engineers who want to build, build, build?

Nick: It’s not easy. I can tell you that. First, of course, you have to understand the business and what’s driving it. What are they attempting to do? And then, it’s understanding what workload to have.

I can use the example from the past organization I’ve worked at. We were developing a number of product lines. I think from the first product line to the tenth product line was probably about a five-year span. And just the way you build those over those five years change. The one that was older and that was legacy was built in a different architecture and a different philosophy than the one you built more recently.

First, it’s understanding those and then understanding the people who manage those, who work inside those business units. They each culturally are going to have some differences in the way they think.

And the biggest part of the transformation is helping organizations get past the mentality of “We’re going to build, deploy and we’re going to maintain this workload over time and help them see ‘build, deploy, and destroy.”

That’s a huge cultural shift but once you get there and can start to then take apart that workload, now you can think in terms of CI/CD. But that’s a massive change from a world that we were in.

And so, that journey, I would say, technologically, is not that hard. We’re engineers. We can figure it out. We’ve got a ton of smart people over there who can figure this out.

It’s how you get on board those who have the legacy knowledge to help bring them on that cultural journey to the transformation.

Ledge: What’s interesting is that we often talk about “Hey, let’s advance the dinosaurs.” And I like how you said that the tribal knowledge and the people with the legacy knowledge have a tremendous amount to offer.

I wonder, what about the young new engineers, what do they need to look for when they’re working with these legacy folks who have been there?

It’s easy to go, “Uh, people who have been there for thirty years; they’re stuck in their ways. They write COBOL or whatever it is.”

What should the new kids on the block try to learn from that group of people before they retire?

Nick: Boy, how do you sum up thirty years of someone’s experience and bottle that up and put it into a young engineer?

I would first say that none of those things that that young engineer would need from that thirty-year-old veteran are necessarily technological in nature. As engineers, we always go to the technological.

But the ability to troubleshoot a problem is something that just takes experience. You just need time over target to do it. And I guarantee you that that guy who has thirty years of experience, by intuition, when something goes wrong, knows probably where to go and what to eliminate in a problem domain.

I have seen over and over that young engineers just don’t know where to go. And, sometimes, they just start shooting from the hip.

And so, when we talk about tribal knowledge, it’s a vast array of experience that helps in some of those things that are not really technical in nature; they’re how we work when we look at a problem; how we understand navigating an organization; or how we understand getting a project pushed through.

And if you’re a young engineer and you have an idea to advance your organization towards cloud data, you should be looking to partner with that guy who has all that experience and find a way that that becomes a benefit to him such that you can leverage in value his experience to help you get that project over the finish line.

And, at the end of the day, you’re going to take a bunch of stress and fear off of that person’s plate because, again, a 30-year-veteran has probably a huge workload sitting on their shoulders and they would love for you to take some of that off their plate through automation, through rethinking how an application is deployed.

Go partner with them.

Ledge: I think you’re right. That really applies to any discipline area. It’s not just engineering. Organizational knowledge would sort of apply to the same paradigm.

What could you tell the people now who are building relatively scaled sort of high-growth SaaS companies right now about what you see in the field and how to avoid being the disastrous sort of legacy dinosaur where people say, “Oh, that thing was written in 2018 and they haven’t upgraded it?”? What are the lessons to avoid getting there in a resource-constrained environment?

We all know where technical debt comes from. It’s hard to prioritize. It’s hard to fund. But what do you see are the enduring lessons that we can avoid the next generation whining about what we did and being stuck with it?

Nick: The first one is don’t overbuild because that’s how you get technical debt. We go and try to overbuild the solution up front. And stick to the lean concepts that are at the core of DevOps and at the core of Agile. Think in terms of MVP. Think in terms of what you really need to go deliver because the more that you build, the bigger it gets, the more technical debt you accumulate and then, of course, the more technical debt you have to pay off.

And I would say to the leaders who are out there to make sure that there is some function within your team to actually be looking at broken windows and fixing them. You do need to pay off some of that technical debt.

I would also say to bring in people from outside to help challenge your way of thinking. If you’re in Stage 2, you’re in rapid growth, and you’re building your organization to scale, you need people to contradict you. You need people to challenge your way of thinking, and that is how you’re going to survive becoming a legacy while you’re building and scaling your organization.

Ledge: Let me ask you this sort of my final question I ask everybody. We’re in the business of evaluating and vetting senior engineers and we take that really seriously. And so, we’re always looking for the best of breed.

What are your heuristics for knowing that I am talking to and I’m about to hire an A-plus senior engineer? Do have a framework or a way of thinking about that measuring that’s really been successful?

Nick: I do. And I will tell you that technology and being able to solve problems in the industry are not as important to us. What technology do you use today versus what am I hiring you to go use tomorrow? That matters less to me.

What really matters to me is that you have a couple of factors. First, let’s just cover the basic. You’re intelligent. You’ve got a great personality. You’ve got character. You’ve got integrity to be on my team.

But the most important factor is this idea of having a really strong internal locus of control. That’s what I look for in my engineers.

Do they have what it takes internally to see the world as something they can change versus an external locus of control?

An external locus of control is someone who doesn’t have control over the way things happen to them.

The example I like to give is if you have a person who shows up late for work and you say, “Hey, why were you late for work?” the person with an external locus of control ─ we call them ELOC ─ is going to say, “Oh my gosh, it was raining and there was so much traffic. I just couldn’t make it to work on time.”

Whereas the ILOC ─ the internal locus of control ─ is going to say, “You know what, I didn’t look at the weather last night so I didn’t get up early enough to make it to work on time.”

And that is the sort of person that you want inside of the organization because they own it; they personally own it whether it’s theirs or not. And the most successful people I have ever have worked for me, whether they had the technical knowledge or not, have those four factors. They’re ILOC. They’re intelligent. They’ve got a personality to work with a team. They’ve got the character to take charge.

Ledge: Love that! That’s a great framework ─ very successful. Thank you so much. Nick, it’s great having you on. Thank you for sharing your expertise.

Any closing comments about you and your work? I want to make sure that people can check you, guys, out.

Nick: Absolutely, Ledge! Thank you for having me. Come check us out over at onlinetech.com. Our goal is to help our clients in their business transformation. It’s all about win-win. We want to make the world a better place. We want to take customers on the journey to digital transformation and make sure that they get there and that they’re hugely successful at it.

Ledge: Nick, thanks so much. It’s really great to have you on.