IT Leadership Best Practices: Why People Matter More Than Tools — SolarWinds TechPod 106

Stream on:

IT leadership isn’t about tools — it’s about people. In this episode of SolarWinds TechPod, hosts Chrystal Taylor and Sean Sebring sit down with Jon Collins, Field CTO & VP of Engagement at GigaOm, to explore the human side of technology leadership. From gurus to cowboys to misfits and mavericks, this conversation dives deep into why processes fail when people are ignored — and how leaders can build resilient, high-performing teams in an ever-changing IT landscape.

RELATED LINKS:

Chrystal Taylor

Host | Tech Evangelist

Chrystal Taylor is a dedicated technologist with nearly a decade of experience and has built her career by leveraging curiosity to solve problems, no matter… Read More
Sean Sebring

Host

Some people call him Mr. ITIL - actually, nobody calls him that - But everyone who works with Sean knows how crazy he is about… Read More

Episode Transcript

Chrystal Taylor:

Welcome to SolarWinds TechPod. I’m your host, Chrystal Taylor, and with me, as always, is my co-host, Sean Sebring. And today we’re joined by Jon Collins, field CTO and VP of engagement for GigaOm. And Jon is going to talk us through some people topics today. We’re going to cover leadership and some other things. But first, can you give us a little bit of a background on your career and what you’ve done over the years?

Jon Collins:

Oh, goodness. How long have you got? I’m that classic jack of all trades thing. So I was a programmer, then I was running systems, and then I became an IT director, and then I was consulting. But I tended to be the guy that, when they didn’t know how to solve a problem, they’d say, “Oh, Jon will work it out.” So I ended up doing a whole bunch of things, largely around development and operations and security, I’d say. Don’t ask me to fix a database, it won’t go well. But in those areas, a lot of it, and I think that’s where the people thing comes from, they’re all very people-oriented topics. So that’s really what’s rocked my world. And then I became an analyst, which is, great thing about, if I compare running an analyst to running a help desk, no one shouts at you, which is really nice. So yeah, I’ve got the scars and hopefully I’ll bring a bit of that to bear today.

Chrystal Taylor:

It’s interesting that you say that these are all people jobs, because I don’t think that most people would describe it that way. Even though I agree with you, we have to work with people on everything, but I don’t think most people think of a developer role as being a people job. You’re working with technology. So it’s interesting to me, and we talked beforehand in our preparations for the call, that you are passionate about empowering people. And I think that that mindset is already present when you’re talking about the roles as being people roles, when most people would describe them as just technical roles or working with technology rather than working with people.

Jon Collins:

Sure. And just to channel what we talked about before, because I’ve got it here. So wait, I’ve got a prop. Here we go. So in my first job, I worked for Philips Semiconductor, and we were writing CAD systems for ASICS. So it was largely teletext chips, or whatever, that went in TVs and so on. So it was very much at the firmware level, and everything just worked really well. And I had a good boss and his boss was a good guy. And we had processes and we had configuration management and we had testing, and you did things, and when they broke, you fixed them, and you got a ticket to do that. And I thought that was normal, straight out of college and university. And I read this book that I just pulled up, Peopleware, by Tom DeMarco and Timothy Lister, and thought it’s a work of fiction, where they’re just cynics and curmudgeons, and they just like to point out everything that could be broken about technology, and it’s all about people doing things wrong.

I then went to work for Alcatel in Paris and discovered everything in the book about what could go wrong with IT projects, software development, deployment, you name it, did. The book became my checklist for… I ticked things off, one page at a time. And this is back in the 90s. So since then, I’ve always had this passion for helping people do it right, because I’ve seen it done beautifully right. Thank you, Bob Baker and Hilton Kirk and Jon Bennett and the people I worked with there, and Elizabeth, and so on. And I’ve seen it work horribly wrong. And the difference is always, it’s nothing to do with the technology, it’s all about the people. So that’s really what fascinates me about adding the people elements to things.

Chrystal Taylor:

Well, I know that Sean also feels strongly about people and processes, and working together. You saying that you got a job right out of college, basically, with it all streamlined already, it’s interesting. I don’t think I’ve worked anywhere where everything is perfectly streamlined. So that’s actually, it seems like the unicorn out there of like, you don’t have problems with the processes or people trying to subvert things, or all of these things that happen in a normal role, where people are trying to work around things so that they get their job faster, or because they forgot something, or whatever. Because people inherently are flawed and we have issues sometimes, where we forget things or you missed a step, or something failed and you maybe weren’t as prepared as you could have been.

And in our pre-call, you brought up a term which always triggers me, which is best practices. And I want to dive into that a little bit because the way you talked about it afterwards is about the best practices for these people processes rather than what we, in IT, constantly have to deal with as best practices. So let’s dive in a little bit to that. What do you mean when you talk about best practices for working with people?

Jon Collins:

Yeah, really good question. And over the years, after that, I have worked in a lot of organizations where things are not done right, and it’s always been wonderful to be able to help in those situations. And it’s worth separating, teasing out the difference between the principles end of best practice, and then the detailed checklists and process steps end of best practice. And you could take a term, for example, like agile. There are highly principled areas of agile, where if you get those things right, things work better. And then you get methodologies like scaled agile, or whatever, that actually require you to do it all right in order for it to work. And so what tends to happen is, if you’ve got some really good agile consultants in an organization, they get everything working well. And then after that, it goes on a decay curve, where I call it the guru’s dilemma, that the experts go into an organization and think they fixed everything, and then they go away. And they always feel good about themselves because they know they’ve helped people.

And then they leave, and then the people, over time, start degenerating in their practices, but the guru never knows. So they’re just in this idealistic world where everything’s just fine and it’s always going to work. So the principles end of it… I was a DSDM consultant back in the late ’90s. So DSDM is dynamic systems development methodology, and it was one of the pre-agile, pre-Kent Beck, very pre-DevOps agile methodologies. It was post Barry Berman, the spiral methodology, and prototyping and all that. And it had, I think, 9 or 11 principles. And it had this great statement, which is, “All of them are right some of the time, and some of them are right all of the time.” And there’s another great book, which is Steve, I can’t remember his surname now, he wrote Code Complete, which is very famous guy called Steve, and therefore I don’t need to say his surname because everyone will know who that is. I think it begins with a C.

But things I learned from him, and then I tested in real life was, if you can go down to… I can remember helping one set of projects and fixing them, not trying to impose huge great methodologies on top, but just saying, what are the basic minimum necessary things that have to be true for this to be successful? And we got it down to five or six things that had to be true. Deadlines had to be met. If you set a deadline, you had to meet the deadline, for example, but they had to be correct. The project manager had to know everything, those kinds of things. So they’re not necessarily… And you could have put that in a Gantt chart or in a sprint or in a scrum or in a Kanban, whatever. Those are the principles that I’ve seen again and again, any level of, you name it, any project management tool you want to use. I’m trying to think of a few, Trello or anything like that, or Asana, we can all use those really badly.

And generally, again, they’ve got a bit of guru’s dilemma about them. They approach it with, “Well, all you have to do is use the tool and it’ll be fine. You’ll be fine.” But if you don’t get those principles right, of who’s in charge… I’ve seen Asana being used for micromanagement, I’ve seen Trello being used for just, throw everything at the wall and see what sticks, and no one knows whether they’re coming or going. So every single time it’s the principles that matter more than the detail, and the tools and so on, and you’ve got to get them right first.

Sean Sebring:

I appreciate what you said there. Working in sales for a software company, I feel like I’m often approached by prospects that basically say, “Sell me ITIL.” And that’s my best practice foundation skills, right? That’s my background. And so when I hear that, I have to grin and try and move past the fact that I can’t sell you ITIL. I can sell you a tool that supports it. But to your point… And thank you, Chrystal, for saying people in practices or processes. I love the adoption of the term practices instead of just processes, just because of the term itself, practice, means that it’s something you need to do regularly. You can’t just say, “Here is our process.” No, it has to be used in practice. So I appreciate that term more, and they’re often used synonymously, but to me, the idea of it as a practice is better.

But Jon, to your point, you can make changes, you can be a guru at a company and do all these things, but I suppose the culture is where it really needs to start, so that when you’re gone, the culture is there still, and that the successes can continue. So that way, again, when you’re gone, it’s part of their habits, it’s part of the ecosystem to continue “living and breathing that way.” It’s not just a here’s how a successful change should be done. It’s the practice of implementing, or continual learning is a big one for me. I think that should be absolutely one of the very first big culture things introduced, because without that, you’re not going to continue to grow. But anyway, very, very much appreciated, and thanks for the tee up there, Chrystal.

Chrystal Taylor:

Yeah, I think-

Jon Collins:

It’s interesting to… Oh, sorry, go on.

Chrystal Taylor:

I was just going to say, I think that I definitely agree with you, the tool doesn’t really matter. I mean, the capabilities are obviously great. But the previous company that I worked at, over the nine years that I worked there, we used five or six different time tracking tools, which, because we were a consultant, we had to track our time against our contracts for our customers, and it was, every single one of them, I would say, was implemented and used badly. We constantly tried to use them for things they were not intended to be used for, or people just didn’t follow through with the practice. So I completely agree with you. It’s not that the tools were bad, it’s just that we were using them in a way they were either not intended to or people were using them poorly, in general, or the implementation, in some cases, was so customized as to not even be recognizable as the original tool anymore with its original purpose.

And I think that in technology, we can get very caught up in, as you say, Sean, you go there looking for an answer, “I need to implement this thing with this tool.” And you think that that’s going to solve all your problems. And you mentioned, Jon, earlier, consultants coming in and they work with everything, and they’re like, “Feel really good. We’ve implemented it. It’s all working smoothly.” And then when they leave, it all goes downhill. And I think that all of that speaks to the people processes, what you mentioned, Sean, of having that culture set up right away. You’re talking about learning, but not just learning, I think having the culture to keep up those practices. And things start to crumble and fall apart as you have to onboard new employees, and then they don’t get the proper training and they start doing things one way. Or there’s a cowboy character that likes to do things their own way, because this way is more efficient, or something, right? There’s always something that comes in and takes it another direction, and you start to see that degeneration.

So how would you recommend people circumnavigate that? How do they get past that degeneration? Is there a way to combat that degeneration in an organization to make sure that your people are practicing the proper processes, and collaboration, and that kind of thing, to make it move forward?

Jon Collins:

The answer is, do that. I think it’s as straightforward as that. So we live our lives… I think that human beings have existed in their current form for about 200,000 years or something, and it’s only the last 11,000 years that we’ve really come out of ice ages and progressed as a civilization. And I’m sure some of the things that we do, that we now think are stupid, are survival skills. And one of them I include is denial. Just feeling optimistic that my way is the best way, and I’ll just get through it and cope with whatever happens. Probably that’s in all of us, just as a way of getting through life, and it goes right back to volcanoes and wolves and everything else. But it’s not so useful when you’re there trying to work with another 100 or 1,000 people and everyone’s trying to get something done, and everyone’s denying that anyone else’s way is going to be all right. So we’ve got to open up with a bit of honesty in terms of how we do things.

It’s interesting actually, you mentioned ITIL. ITIL, of course, was never tools. It started as a set of books of best practice. The original books never even mentioned a CMDB, for example. It’s all about, “Hey, let’s just sit around a table and get together and work out how things work well.” And so it required people to stop and think about what’s working. And I think that’s really important, in general. We can reinvent ITIL tomorrow, and that’s not necessarily a bad thing, because the moment it’s in a book or it’s stuck in a kind of… You go, “Yeah, but is COBIT better?” Or whatever. And you’re in a debate around what’s in a book as opposed to the right debate, which is about what’s working for us and how can we make sure that’s manifested tomorrow. So a lot of that stuff is leadership skills. A really big skill is prioritization, that I see inadequately. I think it’s the key to agility and it’s the key to operational strength, the ability to prioritize.

And we all meet people that can’t delegate, for example. Delegation isn’t necessarily the core problem, the problem is prioritization. Because if they could prioritize, they could stop and think for a bit and then they could remember that they’re not the only person there, and they could give some stuff to their team. So these are inherent human issues that we face. And so when I was doing the DSDM training, for example, I was working for SelectSoftware Tools, which was a UML software company, and we used to go out to customers, and they’d say, “Can we just have the methodology and forget the tool? Because the tool wasn’t so good.” It was really interesting, which made for some awkward, “No, you’ve got to have the tool. Sorry, mate, but we’ll help you with the methodology.” It was Visio with a backend database, if I may. So it wasn’t the most incredible tool in the world, but it did what it needed to do in terms of visualization. And the reason I mentioned that is, I spend a lot of time in organizations, helping them prioritize.

So you could have, let’s say, these days, “Well, we’ve got a lot of user stories. We’ve got hundreds of user stories, so we’ve done that really well, haven’t we?” It’s like, “Well, no, you haven’t because you haven’t gone down to the eight that really matter.” And similarly, if we move into the operations world, a lot of the challenge in operations is having time to think and having time to stop and set, what are the problems that you’re going to solve today? So you tend to either solve the easiest one or the hardest one. The scariest one is like, “Well, which fire is really burning now? We’ve got to solve that.” Or you just go, “Well, that one looks like something I can handle right now.” And neither of those are really good ways to set priorities. So a lot of this stuff is about getting ourselves into a good place, where we can actually respond to the stimuli that we are faced with in a way that’s going to deal with the best problems first, not the easiest or the hardest.

Sean Sebring:

It’s funny you say that. I relate to it quite well. I’ve done a few blogs or talks about bringing it back to ITIL. You’ve mentioned problem, and you also mentioned fire, which is an analogy I like to use, that a problem could be the spark causing the fire over and over and over again. So what do you want to address, the fire or the spark that keeps causing the fire? And so it’s that prioritization. And I don’t want to digress away from people too much, but I think that there’s a reason that these practices and processes exist, because you’ve mentioned a couple times now, we’re human and we are led astray by emotions, pride, ego, whatever you want to call it. Denial is, I think, an after symptom of the ego sometimes. And so these processes and practices can be there to keep us on track and give us a framework to avoid just tunneling down our human-driven passions, to say, “Oh, I need or want to do this.”

Instead, just trust a process. And it’s not to say that the process has to exist forever. Like you said, we could rewrite ITIL tomorrow, and maybe that’s not a bad thing. I think that agility to accept that things should change, we should be open-minded to it, those are all great. But again, that’s where, when we started the conversation at the beginning of the talk today, one thing that was just stuck in my head is the “trust the process.” That was a phrase I had heard in the beginning of my ITIL journey was “trust the process, trust the process.” And there’s an element of that that makes sense. As people, we need a structure, a framework to follow. And then it also ties back into what we were talking about with building a culture, a culture of growing, changing as an organization, instead of just kind of, I like the term Chrystal used, some cowboys out there, that we say, “Oh, there’s this cowboy. He does great work. We don’t really have a practice around what he does or a process around what he does. We just let him do it.”

That’s great, until it’s not. It’s also not scalable. It’s also not repeatable. So these practices and processes are necessary for the people, and as an organization, we need stuff like this in place. And one thing that I’m not as good at as a people leader, that I should be, is that delegation aspect and prioritizing. Because we talk about ego, sometimes I have a hard time letting go of stuff because I want to do it, or maybe even I want the glory of having done it. And so being able to prioritize and delegate and realize that it might be more successful, more scalable, and then still reflect well on me, the company, whoever, if I don’t just hoard the work myself.

Jon Collins:

Some of that is down to just recognition, and then investment. I think that the best thing leaders can do is realize that they are looking at it, let’s say, pick a number at random, two years, let’s say. Let’s have a two-year plan. So the people that are in your team, or whatever, we’re not trying to make everything right today or even tomorrow or even next week. We’re trying to make everything right for the next two years, such that in two years time, we’re all really cooking on gas. So that means maybe giving a job to someone in the team that hasn’t done it before. Even though I’ve done it 15 times and I know how to solve this problem, but maybe the knowledge of how to solve the problem is the thing that I learned by being given it without being able to solve it.

So that’s all about investment, and it is about confidence and trust in your team. But I think that confidence and trust comes from actually building it and building those relationships, rather than just going, “Well, I trusted you and you didn’t do it,” kind of thing. It’s an investment thing. One thing I’ll throw in, in this age of AI is, we’re seeing, I’m calling it the augmentation gap. So essentially we’re finding that the more senior engineers and the more senior programmers and the more senior ops people, they know how to drive the AI in these systems because they know half what they’re looking for. And so they know how to get the answers to help diagnose a problem or remediate, or as you say, look for the spark rather than the fire. And a challenge that we’ve got is how we can get the less-skilled people in our teams up to a stage where they’ve got something augmentable, if you like.

So we need to build some muscle memory first, that we can then build out those muscles and make everyone stronger, which is the dilemma, because you might say, “Well, they don’t know it. The AI knows it, so we don’t need them anymore.” But no, we need the people that can go above the AI, and then drive it to get to solve the complex problems we’ve got in many organizations.

Chrystal Taylor:

Well, Jon, what would you say is your recommendation for getting the buy-in to have that versatility, to take the time to give things to more junior personnel so they can learn, so they can then be faster later? It’s the age-old question of investment now versus investment later, and where are we spending our time? But if we’re not investing in our junior people, then where are we going to be in five years and we don’t have any senior people left because they’ve moved up or moved on. But I think that with AI right now, because you brought it up, with AI right now, A, everyone is still very excited about the possibilities of offloading workloads, and things like that, that you’re talking about augmentation of maybe prompt skills, but also we’re going to be losing a lot of inherent knowledge by relying more on AI. And so in 10 years maybe, we’re going to be in a very different place, technical skill-wise, I think, than we are now.

Do you think that there’s some investment to be made in continuing to keep up skills that AI is going to be helping out with? Or what would you say is something we should be thinking about there?

Jon Collins:

Great question, Chrystal, which is always what someone says when they’ve got to really think, so thank you. There’s a reason why platform engineers and SREs came into existence, and that’s because the problem wasn’t ever in one thing, it was across things. And how things, both across the lifecycle and across the systems that we’re building, and complexity of the architectures that we’re building, we’re not going to have things get… Even if we apply AI to our code base and we can refactor, and so on and so forth, things are going to get more complex. There will be work to do. So the kinds of skills that we need are the kinds of skills we’re already moving towards in this very complex cloud-native world that we’ve already created, massively distributed, et cetera. AI isn’t going to suddenly simplify that. It’s going to make it bigger. So the problem space is going to get bigger. And the role of…

People are worried about losing their jobs through automation, and that’s fair, because a lot of people are losing their jobs through automation, and we see it on LinkedIn all the time. At the same time, there’s a place for two things. The first is people with AI skills, obviously, so bank that. But the second is people who can use AI as part of their jobs, to augment their role as a security engineer, their role as an operational person. And I genuinely don’t think any of that’s going to go away. I think it’s just going to get more and more necessary. So I think it’s worth investing in ourselves and taking responsibility a bit. I’m a bit older than you guys, I’ve seen this repeatedly. At various stages of people’s careers, they go, “Oh, I’ve been made redundant three times. I don’t know what to do.” I’ve seen that 10 years ago, 20 years ago. It happens. The people that I’ve seen succeed are the ones that go, “But it doesn’t matter. I’m already moving on to the next thing because I can see the next opportunity.” And there are huge new opportunities arising.

Chrystal Taylor:

Yeah. You mentioned agility earlier, and I think that that is the clear takeaway of that. We are adaptable in IT. That’s the nature of working in IT. And just because it’s changing faster than it was before, which I think is true every single year, it just continues to exponentially change, and because of that, we have to be adaptable. So instead of focusing on the negatives, being able to focus on being agile yourself, I think, is a great takeaway from that. But I wanted to bring up, you said earlier that, A, you brought up agility, but B, you were talking about you should be preparing to make the processes right for the next two years. So the other day when we were talking, you also said something which was, “We’re never done.” Can you expand on that a bit?

Jon Collins:

Yeah, some of this, it’s very dangerous to talk in terms of principles and practices, and so on, because you end up very much in the motherhood and apple pie world. But there’s a reason for that to exist, and the reason is that we get it wrong, unless we’re reminded to do it. So I can’t remember if we talked about this or not, but I’ll say what’s on top of mind at the moment. We have maturity models and we have this idea. Maturity models go back to the CMM. And by the way, if anyone’s watching this, look at the capability immaturity model, it’s hilarious. It goes from a bit dumb to insane. So we have these models that suggest you’re not brilliant right now, you’re immature, and you can get more mature, and then you can get really mature, and then you can end up in this optimal state.

A realization, having been around the block for a few decades is, no one ever gets to the optimal state. And for many years, I thought therefore maturity models are wrong. They’re stupid, because I’ve never seen in… Theoretically, we should all be there by now. But a more recent epiphany is, that was never the point, because it’s never done. We’re never done in terms of how we deal with change. Every time there’s a new change, it resets everything. We go back to the starting point and have to then rebuild our understanding, and then we really mature from that point. So when Cloud Native came along, even cloud computing came along, a whole new generation of developers and ops people and infrastructure engineers and database engineers found this whole new playground. And they started building things very fast. And there were a few huge winners in that world. And then everyone else tried it, and really struggled.

And it’s easy for someone like me to go, “Yeah, that’s because you got the principles wrong.” But actually it’s important for me to recognize that those principles have to be learned for that new world, and they will have to be relearned for the next new world. So I think from the point of view, so at GigaOm, we have an AI maturity model for organizations, it’s a very useful tool, but it’s not a be-all and end–all. It’s a place where you can understand where you are and where you can get to next. And then next year you look at it again and you understand where you are, and you find that you’ve succeeded on a whole bunch of level 2 things.

For the purposes of this, let’s say the maturity model goes from level 1 to level 4, you’re still on level 2 for certain things, you got to level 3 or 4 for other things. So let’s work on the level 2 stuff, and it’ll change. It’ll shift around. Sometimes it’ll be the operational stuff. Because everything happens, like you improve one set of things and you forget the other set of things. And then you realize you’ve forgotten the other set of things, and they have to be brought back up to scratch, and round we go. So it’s always be learning, always be checking, always be accepting that perfection is neither true out there or true in here. And that’s fine. Therefore, it’s easier to go, “Yeah, I understand where I am and I understand what I can do next.”

Sean Sebring:

The only thing you didn’t say was always be closing. I’m sales, so that’s very relevant to me. I’m just kidding. Doesn’t really fit there. No, great points. I really appreciate that, Jon. Yeah, to bring Chrystal and I’s gaming life in there, there’s always another expansion. You think you hit level max, just wait. There’s a new expansion, a whole new set of levels, all new sets of progression to go through. Yeah, you’re never done. I like that.

Jon Collins:

And I think the gaming model is a great one because essentially when you get to level 5, you think, “God, level 1 was so easy.” And you go back to the original starting point, and you go, “Oh, I can work through all of these very quickly.” But level 10 is a real challenge. And then you get to level 10, you go back to level 5 because you happen to be running through that area, or whatever. And each time you’re building new things, you’re building out new things, but you forget what you’ve learned along the way, or what skills that you’ve built, or whatever. They just become an inherent part of what you’re doing. So just that constant re-skilling. As you say, there’s always a new expansion pack, there’s always new skills to learn, and just be never afraid of that. Just recognize that that’s as true in life when you become a parent, when you buy a house, when you learn a new sport, when you start getting older and you find out there’s things that don’t work as well as they used to, you have to learn to deal with that.

Learning in a world of change is a constant, and it just happens faster in tech, but it’s good for the brain, right? So we’re all benefiting from that.

Chrystal Taylor:

Yeah. I think because you guys brought it up, and now I’m thinking about it because I’m playing a Metroidvania style game right now. I think that that’s the optimal example for this, because you come across things, even in the early game, that you can’t tackle or you can’t address because you don’t have the skills. So when you go get the skill later, you can go back to the early game and unlock the new things that are there, that you couldn’t get to before. And I think it’s a great… You’re constantly going back and forth, and we, in technology, should also be doing that. You constantly have to revisit the skills that you’ve already gained. Because one of the things I think that we’re in danger of doing, the longer that we’re tenured into our careers, the longer we’ve been doing something, is that you can get into a trap of missing a lot of the earlier stuff.

You start, instead at your troubleshooting, you start here at level 5 instead of at level 1. And the answer could have been as easy as at level 1, you’re not even thinking about it anymore. And I think that that’s true in technology a lot. And especially with these processes, we’ve mentioned a lot of different methodologies and practices and processes, and it’s like, well, what’s going to work for you? What’s not going to work for you? I think is all a variety of different things, depending on what your position is, what work you’re doing. There’s too many questions there. But you are going to have to keep revisiting those skills. We are talking about AI and how you, which I completely agree with your stance there, of, we can’t just lie down and not do those things anymore. We’re still going to need to do things. You’re still going to need those skills. They’re not going to go away. You just have to learn how to work with the AI rather than against it, because it’s not going away.

But I also agree with your stance on perfection. I actually said this recently on TechPod, I think, I don’t believe in the word, perfect. I don’t believe that perfection exists. I think it’s a myth that we tell ourselves so that we have something to work towards. And that’s just as true in our businesses as it is in our everyday lives, of, you need some attainable goal to work towards, and whatever you think is perfection. I don’t believe it exists. I think that we always have to continue to be learning and acquiring new skills and changing our opinions, and all of those things. And you brought up the human experience, basically, over the history of humanity, right? And how far we’ve come, how far you’ve come in your lifetime. My son is right now learning, he’s 15, he’s learning coding. And how far he’s come in the last two years even is insane. And just thinking about technology, asking different questions about the technology that he’s working with, asking different questions about how things work.

And we do the same things. It’s easier for us to see in someone else, especially when they’re a kid, I think, where you can get impatient with an adult, you’re less likely to get impatient with a child. And so you get this mentality when you watch a kid learn how to use technology you already know how to use, that you forget all of those little first steps, those little things, the mind-blowing things that are happening, where like, “That’s how that works?” And I think that we should try and carry that forward as we move through our careers, of trying to retain that. Sean and I have talked about this too, that childlike sense of wonder, almost, as we’re continuing to adapt to the way that things are coming.

Technology’s not going to stop changing, guys. It’s not going to stop. It’s going to keep happening. And so we have to go with it. And you mentioned a bunch of leadership skills throughout all this that are helpful with navigating the changes and the things that you have to go through, your organization has to go through. So do you have any recommendations for anybody out there who’s looking to expand their leadership skills, or expand their people skills, how they work with people? Do you have any recommendations?

Jon Collins:

Yes. And I absolutely hear you on perfection. Perfect is the enemy of good, and all that. I am a big fan of excellence, however. So be the best you, you can be, is a very important thing, because that’s about being honest with yourself, about who you are, what you bring, et cetera. You don’t have to be the best someone else, you just have to be the best you. And that’s incumbent on all of us. And from a leadership perspective, I think it’s important to set that expectation around trust, around building up a team of people who can, at any level, who can deliver on a goal. And it’s up to the leader to actually assess what that goal should be, and then shape people need. It’s one of my theories, by the way, that we all miss living in villages, and therefore we create villages around us, and teams and parts of the organization are actually those villages. And if you’re put in charge of a bit of that, it’s incumbent on you to manage that situation and to set expectations, and so on.

I think if you go down the path, as a leader, of trying to get people to just deliver on metrics or whatever, you’re going down a data-oriented path. And people game that, and so you’re not necessarily getting the results you want. And then you find, to your surprise, that you’re not being successful even though all the targets were hit, which is a really weird place to be. And the alternative is to actually sit down with your teams and to have a conversation about what these expectations are. It’s not always a nice job to do. You have to tell people what’s acceptable and what isn’t, and what your expectations are. So it’s not about operating as one of the boys or one of the girls. People expect leadership from leaders, and you’re there to provide that. So then all the tools…

It’s interesting. All the human traits that we’ve talked about, a lot of what we do tend to be influenced by our susceptibility and our very humanity. And we’ve got to rise above that and actually get things right first. And this is where I’m very keen on the principles and expectations. Get those right first. And then what do you know? You go back to the very first job I had and the tools get used properly, because people define what they’re going to do before they do it. They set quality gates. They have code reviews, they have scrums, they have operational meetings, they solve problems together. They work collaboratively. You can’t just get Slack or whatever the latest thing is, or a chat interface, and expect people to work better together.

Those things are part of the team dynamics, so put that first. Literally, that would be my big tip to leaders. It’s, put your team first and then allow the tools to either automate the boring bits so they can get on with the harder bits, or augment what they do. Whether it’s good old-fashioned… Even a spreadsheet is good at that point, or tools like you guys produce on the observability front or the monitoring, pulling all that complex data together, then adding the AI elements to it. All of that is in support of the people doing the job, ultimately. And that’s the role of the leader, is also to be in support of the people doing the job.

Sean Sebring:

So I want to see if I can ask you one that’s also difficult, maybe more, maybe not. Maybe it’s me, maybe it’s Maybelline. But what I was going to ask is about the culture piece, because I find, as a people leader, that culture is, especially being in a much more regionally-based place, I’ve got members on my team from all over, culture seems, to me, to be one of the harder things to help spread or create consistency in, especially because cultures could be different, depending on where you’re from. So two things. One is, is there a specific trait a leader should possess in a… that’s pretty universal? Is there a universal trait from a leader to help create some consistency? That’s part one.

And then the second thing is, in general, when addressing culture change, knowing that your team is incredibly diverse… They can all be from the same place and very diverse, right? Someone’s a pessimist, someone’s too passive, someone’s too soft, right? Maybe they all want to be aspiring leaders, but they’re also different, which is why I asked that first question about a universal trait for a leader, potentially. So to restate again, a universal trait for a leader, do you have a thought? Is there one? Is there not? And then the second one is, when it comes to addressing culture within your team, what tips, tricks, or recommendations do you have around that?

Jon Collins:

So the universal trait, I’d say, is the same for leadership as for sales, because we all want it, is listening. And it’s fascinating, as an analyst, a lot of our job is helping remind people that all they have to do is listen to their customers. It’s crazy that that should be a role, but it’s important nonetheless. I’ll map that into the culture question, and I’ll say, “You can’t create culture, but you can destroy it.” And what I mean by that is, your culture already exists in terms of the diversity of your people, in terms of their likes and dislikes, in terms of the way that they interact when you’re not in the room. Maybe it’s a sporty culture, maybe there’s a musical element to it. Everyone loves talking about cooking. And you find that the culture is already happening in front of your eyes. And what you can do with that is- take the pieces of the culture that are important to your organization, and grow them and nurture them like you would a garden. Just go, “Yeah, let’s have some more of this bit.”

And just as a garden, when you water certain plants, they become the garden. So if you look at the culture within your organization, or the cultural elements, and then you nurture certain ones that are going to be more helpful to you, be it a data orientation, let’s say, everyone seems to love working with data. Let’s make data a big thing. Let’s have a data stand-up once a week. What are we seeing guys? And as we know, a toxic culture often comes from the top. That’s when I say it can be destroyed. You can get toxicity within the culture, you can get bullying, you can get issues inbetween people. It’s like the school playground. That’s a culture very much that largely often is down to people creating the culture for themselves because the leadership isn’t strong enough. And that’s a big statement. But often when there’s a really tight team, it’s because there’s a good team leader. And when people are kicking off, it’s because there isn’t a team leader that’s in the room, if you like. So being in the room is hugely important.

But equally, the leader can be the bully, can be the person who is creating that toxicity or pitting one person against another, or whatever. And that’s really, really good ways of destroying any hope of creating a beautiful garden where everyone’s bringing their own skills. I’m a huge fan of diversity, in all of its glory, not to check any boxes, but to recognize that we’re in the IP game, we’re in the intellectual property game, we need multiple different brains all processing different elements of the problem space so we can come up with new and unique solutions. And if we have them all, if everyone looks like me and everyone sounds like me and everyone thinks like me, we’ll end up with a whole bunch of… That’s not parallel processing. I might as well just do it myself at that point. But if I want to leverage all of my team, I don’t want to have seven people like me or a hundred people like me, because I might as well just have me, from that point of view.

So it’s really important to embrace that diversity and bring, be it neurodiversity, be it gender diversity, whatever, and certainly cultural and social diversity into the folds, and benefit from that, and see that as a strength.

Sean Sebring:

Was it a hard enough question or was it too easy?

Jon Collins:

It was a lovely question. Thank you. I think there are ways to do this. A team can be a family or a team can be a serfdom. And I’m just a big fan of the family approach, where people might bicker, you’re not all going to get on all the time, but you’ve all got each other’s backs, and that’s very much embracing the humanity of it.

Sean Sebring:

That’s good stuff, Jon. I appreciate that.

Chrystal Taylor:

It’s interesting you say that though, because there are a lot of people out there that think that when teams refer to themselves as a family, that that’s actually a red flag.

Jon Collins:

Yeah. It’s a bit like when you’re… I don’t know, I can’t speak for you guys, but when someone says, “Oh, my mom’s my best friend,” and you’re like, “Ooh.” But it’s-

Chrystal Taylor:

Wait, hold on. What does that say about a person? Because I spend a whole lot of time with my mom.

Jon Collins:

No, that’s fine. That’s fine. But also, I hope you’ve got a great friendship group.

Chrystal Taylor:

I do.

Jon Collins:

There you go. Team dynamics, you should leave your home life at the door, in the office anyway, but obviously then the office has emotions, and so on and so forth. I don’t think it’s about creating an environment where nothing gets done, because families don’t tend to work towards shared goals. It’s about breaking down the barriers of formality such that you have trust and friendship and professionalism all in the mix at the same time. There’s a great example, I’ll go back to the book, Peopleware, and I’m just remembering this. And here we go. I’ve got it upside down now. So there’s an example in here about the person in the office that never seemed to do anything. And I think in the book, she was a she, and essentially, so they fired her, and then nothing really worked as well as it had before, and they ended up not delivering so well, et cetera.

And there are people in the organization that work with other people and get other people to do things really well. And they could be at a senior level, they could be at a lower level, but they’re hugely important to the dynamics of the organization, to actually just make sure other people are achieving things. It could be a bit of mentoring, it could be a bit of communication, et cetera, et cetera. And we have a tendency, when we put together terms of reference and roles and responsibilities, and so on, of over-defining roles. And actually, and this goes back to what I was saying about culture, I’m a huge believer that excellence and delivery and productivity come from understanding what everyone brings, and making the most of that. So you open your tool chest, you see what tools you have, and those are the tools with which you can carve or create or whatever.

And nothing really matters. As I say, we’re in the intellectual property game, creativity is a hugely important element to what we do. Even in operations, creative problem-solving, there was always that person, wasn’t there? In every organization, there is that person that can solve any problem, and they get called on for just about everything. But that’s because they’re creative, that’s not because they’re necessarily technically smarter, that’s because they’re thinking outside the box. So we’ve got to embrace those characters in our organization, not by going, “Oh, well…” As you said earlier, Sean, there’s that one, but by embracing the notion in itself, and seeing what everyone can do. We’re all misfits and mavericks. At the end of the day, we’re just pretending not to be.

Chrystal Taylor:

I love that. I did want to ask as a follow-up question, do you think that building or fostering culture is more challenging, or I guess different, if you have a remote team or a widely distributed team than if you were all, say, working in the same office?

Jon Collins:

That’s a really good… Because GigaOm’s completely remote, so we’ve been working through this as well, and I think we were all struggling through that, or we were certainly struggling during COVID. GigaOm went completely remote before COVID, so it was like, “Oh, COVID. Oh, well, another day.” Nothing really changed. Meeting people face-to-face is hugely important of who we all are. I think it’s fundamental and critical. However, there are surrogates to that, and it’s important to embrace those surrogates and not shut them down, like the Slack channel for Legos, or whatever. They’re not with us anymore, but for example, I don’t want to speak ill of the dead, but in some organizations, let me genericize it, some people might say, “That’s just time-wasting. It’s not productive for people to be spending all that time on the chat channel,” or whatever. And that could be right if one person is literally spending their entire day on the chat channel. Maybe, yeah, let’s have a look at what they were supposed to be delivering that day. “Oh, yeah, but I was busy talking to so-and-so.” Maybe that wasn’t hitting their objectives.

It’s one of the things I used to say when I was doing the consultancy side of things and everyone was in an office, “Let’s all go out and have a football game. Let’s go out and play a game of soccer, or let’s play table tennis.” And this was pre-startup, pre-pizza teams and so on. It’s amazing how people go, “Oh, you’re okay. I didn’t realize. I’d never…” So you can use that. It’s not so much creating culture, it’s allowing culture to happen. It’s getting out of the way. It’s even, stopping preventing culture from happening is really, really important. We put barriers up to culture and we should be allowing it to happen. And if we don’t like the culture we’ve created, that’s our problem, not the problem of the culture, because we can nurture, as I’ve already said.

Sean Sebring:

Yeah. Meeting people in person, big deal. I agree. I can’t tell you how many times people are like, “Oh, you’re so much shorter than I thought you were.” And it’s just a necessary thing. We got to get it out of the way. So it is what it is. Now I’m less intimidating. I’m just a wee lad. I’m just kidding. But yeah, I know that’s just a human element. It does help quite a bit. And to your point, there’s plenty of other ways to nurture culture, from a remote aspect. But yeah, it’s so great to finally get a chance to meet some folks, go do an activity together, bond in different ways that aren’t just work tasks.

Chrystal Taylor:

I agree completely. I just like to hear what other people think about that. Because I’ve been working remote for about 15 years, so I certainly have opinions about there being able to be a solid work culture. I think that when you have a remote, or really widely distributed team, it just takes more effort to give places for that culture to grow, because humans naturally will do that when they’re in person. And when you’re remote, you can ignore notifications or the chats that are going on, or whatever. You can more easily ignore those things or not participate in them. And I would say also that if you are a remote person and you’re not feeling like you’re part of the culture, but those places do exist, you have to participate. And if you don’t participate, then you’re part of the culture toxicity. So you don’t necessarily have to be in -person for there to be good culture. There’s plenty of remote-first, or completely remote companies out there now that are thriving.

So I appreciate your thoughts on that, Jon. I think that especially with some of more old school leaders and executives, they can still get stuck in the mentality that they may have had before, which, if I can’t see you, you’re not working. Or like you say, those spaces are a waste of time, or whatever, but they will foster those things in an in-office environment, where it’s like, “Oh, go ahead, have this party. Here’s some budget for a happy hour,” or whatever. They’re happy to provide the in-person cultural aspects and less happy to provide, the usually don’t-cost-you-anything, remote cultural aspects, which I find interesting. It’s just like the dichotomy of the pre-COVID and post-COVID world that we live in.

And I think we were always headed this way, realistically, to a more distributed workplace, because technology has evolved to allow us to do that, and there is no reason not to do that. So realistically, I think COVID just sped things along, of, more people were going to be remote because they had to be. And we, as people, need to just be more accepting of the fact that it’s not going to go back to the way it was before, but there are plenty of ways to nurture and foster a culture even amongst a fully remote or fully distributed workforce. All right. Well, Jon, is there anything else that you would like to share today?

Jon Collins:

Yeah, there’s one thing in particular I want to share, which is, sometimes these kinds of conversations sound very matter of fact. It’s like, “Oh, yeah, well, there’s things you can do,” et cetera, et cetera. The trick, I think, is to recognize that this is all really hard. None of this stuff is easy, and we love our denial, and we would wish that human interaction is easier than it is. It isn’t. It needs to be worked at. In a marriage, you need to work at relationships, with your kids, you need to work at it, et cetera, et cetera. This is stuff that you need to put your back into. And hard sometimes means really hard. It’s not just, “Oh, I found that a bit hard,” it’s, “Oh yeah, I’m broken by this.” And so I take my hats off to anyone out there that’s dealing with difficult relationships, got problems in their team, got problems with their manager, whatever it happens to be, but that doesn’t take away the fact that therefore it needs to be focused on and addressed in some way.

And I was reminded, on the remote working thing, for example, I’m someone who can… I made this huge mistake when I became a manager. When I first became a manager and then I became a director, and I got an office, and it was like Terry Gilliam’s, Brazil, you got your certain meterage, your office, and I thought, “Oh, this is great.” And I went in and I shut the door and I sat down, and I thought it’s the best thing ever. And shutting that door was the stupidest thing I ever did, because I completely lost track of what my team was doing. And lesson learned. Yeah, only in hindsight two years later did I find out that no one did anything that I told them. It didn’t even take two years, it was like weeks later. I was like, “Oh God, I’ve got to fix this.” Because I went away on holiday and nothing got done. And so there’s that.

And also, on remote working, I can easily stop communicating because I’m getting stuff done, and don’t bother me right now, and switch off the notifications, as you say. So we all have things to work on for ourselves. It’s not easy. It is the right route to put people first, to build trust and respect, and optimize those things for productivity rather than putting productivity first and then trying to optimize the team. Because ultimately, if all the tools are equal, if all the processes are equal, if all the practices are equal, back to the words we were using, it’s the people that will make or break anything. So that’s why they have to be seen as the biggest priority.

Sean Sebring:

Beautiful closing, Jon. Wonderful. Love it.

Chrystal Taylor:

Awesome. Put people first, that’s the key. Listen and put people first. That’s my biggest takeaways from all of this. So thank you, Jon, so much for joining us today and sharing your insight and your experience with us.

Jon Collins:

No problem, I loved it.

Chrystal Taylor:

Awesome. I’m your host, Chrystal Taylor, and with me, as always, is Sean Sebring. And if you haven’t already, subscribe and join us next time on TechPod. Thanks for tuning in.