TEC37 E01: Breeding Unicorn Employees

Please view transcript below:

Rob Boyd:

Today on TEC37, developer skills and network engineers. Incredible new career opportunities or something you can ignore? We have the experts.

Rob Boyd:

Hello and welcome to this latest installment of the WWT Tech 37 video podcast series. Which is not a new series, just a new host. My name is Rob Boyd, and each 37 minute episode will focus on a topic in the fields of technology, education, collaboration. It's all the IT you can eat in 37 minutes.

Rob Boyd:

Yes, that's fast. But brevity of course has never been a word associated with me, but this is in our name. So I'm going to adhere to our time limits, unless I just think our topic is getting way too interesting and we may stretch it.

Rob Boyd:

But anyway. For anyone who is not familiar with WWT, they are a powerhouse global, global, global. That's supposed to be dramatic. Global systems integrator, delivering solutions from idea to outcome to organizations across the world, since 1990. This is truly one of the most well-equipped, intelligent, and friendly group of geeks that I have ever worked with.

Rob Boyd:

In fact, we have two WWT experts with us. Tyler Hatton and Todd Erickson, and from RedTalks.Live, Nathan Pearce. Welcome gentlemen. Thank you so much for joining us.

Tyler Hatton:

[crosstalk 00:01:26]

Rob Boyd:

I'm doing well. I appreciate you asking. So all three of you are here because you have extensive experience with dev ops, with helping both individuals and companies navigate what has really become a movement or a change.

Rob Boyd:

And so what I wanted to do with the little bit less than 37 minutes that we have in front of us at this point in time is see if we can walk through what needs to be known, what needs to be shared. And I was kind of breaking this up into three areas, if you will.

Rob Boyd:

First of all what's the problem that dev ops is purporting to solve here. Right? Why has it come about, why has it evolved the way it has. And what's the urgency? What's going on here.

Rob Boyd:

Let's take that into skills that we should be focused on, both as individuals, whether our background is primarily network engineering is where a lot of people that we interface are. But there's also developers who are understanding the networking side of things a lot better and understanding the part that they play collectively in an organization.

Rob Boyd:

And then of course what kind of resources can be offered? What kind of next steps would you guys recommend. Does that all sound pretty good to you guys?

Tyler Hatton:

[crosstalk 00:02:27]

Rob Boyd:

Don't say yes, because there [crosstalk 00:02:28]. Okay, cool. Well, Tyler, we're going to start with you. Let's just do it this way. But I want everybody else to weigh in. Tyler, how would you describe the problem being solved? What is it that's gone wrong and perhaps in many organizations today, what do we need to be working on?

Tyler Hatton:

Yeah. That's a really good question. I think that's very important fundamentally when you talk about dev ops. And I think ultimately when you talk about dev ops and really what it's about, it's effectively a series of practices, principles, and tooling to enhance and improve an organization's ability to deliver services to customers.

Tyler Hatton:

And improve the ability to basically accelerate continuous improvement of those services and applications. And I think when you look at the goals of dev ops around continuous improvement and acceleration of delivering services, really the problem is trying to address within organizations if is you look at most organizations today, I used to work in one of those, they're very siloed in nature.

Tyler Hatton:

You have many of these different teams within an organization who fundamentally kind of have their own countries or silos or groupings, and they don't really work well together. And what dev ops tries to do is encourage collaboration across those different teams. Encourage a culture of sharing, in order to somewhat break down those silos and increase the ability of delivering services to their customers.

Todd Erickson:

Right. Right. I think if you think historically about things, we built those silos because we were working with one server room and we wanted to segment responsibilities. And now that basically things have become more virtual and we have all of these products that basically, in cloud environments or on prem, that really are software based and they have a lot of different focuses. They have networking and apps and automation that you have to deal with.

Todd Erickson:

Having groups work together in that collaboration becomes way more important than it has in the past.

Rob Boyd:

Well, I'm curious. Nathan, I want you to jump in here. How would you define these silos? Can we get more specific about what silos we're talking about that need better communication?

Nathan Pearce:

Yeah. I think there's a few drivers behind this segmentation. In some organizations it was probably just generating fiefdoms of control. But in others it was about eliminating risk areas.

Nathan Pearce:

So anything that overlapped. A failure in segment A could cause a failure even greater in segment B, so let's keep them really isolated and really separated. And that was due to a lack of the right kind of tooling and integration and workflows.

Nathan Pearce:

But with the right visibility they could protect that isolation. That they could make it all work fine. So now we're kind of past that age, driven by the need to just respond quicker to market demands, to customer demands, to business, that that just doesn't work anymore.

Nathan Pearce:

So the tooling needed to be made and it's happened. It started, it's come along brilliantly. I want to add to what Tyler was saying earlier about the drive behind this.

Nathan Pearce:

A former colleague of mine did a brilliant job of explaining it in a single sentence. He said, "Dev ops is all about reducing operational friction." And that kind of like blew my mind. I was like nailed it. That's literally what we're all trying to do here.

Nathan Pearce:

And then you described it brilliantly. There's obviously a lot more detail that needs to be added to that. But I quite like the way you explained it all.

Rob Boyd:

Well, let me take a shot at this. One thing that I think, and I just tried to repurpose what everything is coming here so we can build on top of this, is I think there was examples. And Nathan, you and I talked a little bit about this offline.

Rob Boyd:

But historically if we look at the manufacturing revolution of the 1980s and such, with Toyota and movements that were designed around efficiency of processes and things like this, if we take ... not that we're doing manufacturing in the traditional sense by any means. But I would say that every company is an IT company. So this broadly applies to everybody.

Rob Boyd:

If you even take a bank, a bank is simply an IT company with a banking license. Right? I mean so could you find a capital project that doesn't have some type of impact on IT? And I think you would be hard-pressed not to find some level of necessity there.

Rob Boyd:

So if we think that everybody is potentially interested and how do we get better at delivering the value that we're supposed to to customers in this, which is the bits, what are the value added things that a given company's going to be doing for their customers? Then removing friction, which I love. That idea of saying well what is the friction maybe, what are some examples of that friction that's keeping it from going.

Rob Boyd:

Could you describe? I'm going to go back to you, Nathan, for one second here. And then I want you guys to jump in. But describe what is an example of that friction? What is happening? We're talking about I think let's just be clear, two. Dev ops is a portmanteau of two words. Development and operations.

Rob Boyd:

And operations we generally thing of that's where IT sits. Are the goals for IT different from the goals for developers? Is that maybe where some of the challenge stems?

Nathan Pearce:

I think clarity in those goals and how to achieve them, a lack of that clarity has definitely been a big part of the problem. So I mean one of the common examples used to explain that reduction in operational friction is that the environment and the libraries and the versioning of systems and tooling and modules used by development is not the same as when it gets thrown out of production and people can't even understand how to keep that [inaudible 00:07:58] in a nice workflow.

Nathan Pearce:

That's a very common use case there. Like I'm running version X of an NPM and you, [inaudible 00:08:06]. Or maybe a vulnerability in one that isn't in the other. And just chaos because there isn't that common, not just goal but almost templatization of a process.

Nathan Pearce:

We're reproducible ops. I quite like that term. It's about creating something reproducible across both those teams, so that we don't have any surprises. So then if something goes wrong, I can just repave straight over the top of it and know I will always get back to that right state that I was at before.

Nathan Pearce:

so that reproducible and going back to your bit of what is the problem, I think it's us. It's people. Elon Musk, love him or hate him, said it brilliantly. That the moment you put people in the production line the production line drops to people speed.

Nathan Pearce:

Well I would go further than that and say well also to people created problems. We make mistakes far more than machines do. We're the ones that tell the machines to make the mistake.

Nathan Pearce:

So a lot of it is it's not about getting rid of people. It's about people having a very different focus and approach. A systems thinking about how everything works.

Rob Boyd:

Yeah, guys. What do you think? Tyler. Let me pick on you again. So from a definition of dev ops, would you say that dev ops is ... certainly dev ops is certainly not a tool someone's going to go out and buy. Right? How would you characterize, when we're talking about becoming more dev ops oriented in an organization, I think we're talking about the problems now.

Rob Boyd:

Talking about reducing that friction and becoming more repeatable and consistently automated to the extend that we can really compete quickly. And if we say dev ops is a way to get there, do you feel like we're arriving at a definition people can live with in this conversation yet?

Tyler Hatton:

Yeah. I think to a certain extent, and I think Nathan's point around systems thinking and just the ability to think at a really a macro level within an organization, across multiple different teams, I think that is fundamental at a cultural level within an organization.

Tyler Hatton:

And to go back to these frictions that may exist between potentially development or operations, or even the different teams within operations, operations isn't just one group. There's a networking team oftentimes, a middleware team, a security team. Those groups also have to work together and there's friction there.

Tyler Hatton:

And from a culture standpoint, what we're trying to do, and I think as an industry from a dev ops perspective, is just to get those people to collaborate more and work together more. And create some really flow and reduction of friction between those different teams.

Tyler Hatton:

And really to think about each team's care about, somewhat empathize at a very high level, and get some perspective from a security perspective. What do they care about? What are the things that are important to them from a developer's perspective?

Tyler Hatton:

Thinking about that from that perspective I think is really important when you just think about the adjustment in culture that we're seeing within the industry today.

Rob Boyd:

Yeah. Todd, I feel like one way in which we may look at this is one hand the urgency for any company, if we agree with my premise that everybody is an IT company because of the fact that IT is structurally part of everything we're doing these days no matter what your industry, and if we say that then that means that the ability for IT and everything that touches it to operate with less friction so that we can compete, so we can respond to market conditions faster, there's the urgency.

Rob Boyd:

And if feels like what I was thinking of earlier was this notion that it feels like development is all about being creative and turning out stuff fast and user interfaces and being able to do things that aren't necessarily shared with IT. Who says in IT we've been raised, because this is my background from a networking perspective, we've been raised that we value stability and consistency among all else.

Rob Boyd:

And so it's a little bit against the mindset of the networking nerd, from my perspective anyway, that we would want to go out and try things. Because that threatens the stability. And so that's where I feel like the goals start to maybe differ.

Rob Boyd:

And so I wonder if you can segue us into the type of skills that are needed in this dev ops environment that we should be looking at here.

Todd Erickson:

Well, okay. Actually I want to disagree a little bit with your point. From a developer standpoint.

Rob Boyd:

Okay, okay.

Todd Erickson:

A lot of people come at this of developers really just want to push things forward and try something new and move the ball, regardless of stability. And to be completely honest, that's entirely wrong because for the most part we don't want to work the weekend. And if things go down, we do.

Todd Erickson:

So actually I think yes, developers do want to push things forward. But they want to do it in a stable way. And that's where you have testing and trying to do that automated. Right? Try to basically bring as much of that into the development process and the build process.

Todd Erickson:

I think that's actually also part of dev ops. I think dev ops sees that the organization wants to move forward. Right? The reason why the developers want to move forward is the organization wants to move forward.

Todd Erickson:

As I think Nathan pointed out really well, hey, we have to meet these business goals. Right? But they also don't want things to go down. And that's where the old IT mindset is absolutely right. And the dev ops goals is to try to bring those two together. Right?

Todd Erickson:

So how do we basically move things faster but also keep the stability. And that's where basically a lot of automation and things come in. Which goes back to our skills, right? So you need to basically change your mindset about how you're going to approach a problem.

Todd Erickson:

And you need to try to basically learn these automation skills and things that are basically going to make it so that we can constantly test and we can feel good about what we just pushed up. The project that we just pushed up that is going to work and be stable and accomplish the goals.

Todd Erickson:

And how can we do that every day? Or every hour. Or every minute.

Rob Boyd:

I appreciate you calling me out on that. And I'm hoping Nathan, you're going to be on me out here. I do want to switch to some skills, because he mentioned a couple of things in there.

Rob Boyd:

And I don't mean to ... I do love a little bit of conflict because I think that makes for a more interesting conversation. I wasn't going to talk about developers smelling funny, the fact that they don't bathe as often, or whatever it may be. I'm just kidding, I'm not bringing any of that stuff up.

Rob Boyd:

But Nathan, what are you hearing in this in terms of what's important? Because it is a balance and it is about working better together for the shared goal of faster, better, let's get home in the evenings, let's stay home on the weekends and not get late night calls. Right?

Nathan Pearce:

Yeah. Yeah. Actually I loved what you were just saying there, Todd. What I immediately thought of was the whole five nine's ear. Which I think allowed for 30 minutes of downtime a year.

Nathan Pearce:

Basically that was a knee jerk overreaction to some people having some bad outages and the whole industry just went crazy to this model where you were doing your deployment once a year. And you were permitted to have just a 30 minute outage for the year.

Nathan Pearce:

Which meant everybody said we're not touching anything. We're going to do crazy extensive amounts of testing and then once that's in production, if you needed to change a logo, we'll get to that next year in the next window.

Nathan Pearce:

And it just went way too far. Way too rigid. And what we're having to do is just break that muscle memory. We're having to get people to relearn that actually that doesn't help anyone and you can have continuous deployment safely. And this all goes back to I think it was 2008 conference when Paul Hammond and the other guy who I-

Rob Boyd:

[inaudible 00:15:55]

Nathan Pearce:

Yes, [inaudible 00:15:58]. They got up and said we're going to do 10 deploys a day and everyone was like they're crazy. And now everybody's trying to do what they're doing. It's getting away from that crazy five nine's kind of mentality where nothing could change.

Rob Boyd:

Well let me ask you that, Nathan, then. Because take us into that, because I don't want to lose track of that thread in terms of if you're looking at doing something at the time, 10 deploys a day which for many operations is probably still crazy talk, how does someone begin getting to something where 10 deploys a day is considered a normal day? And you're not talking about staying late that day either I assume.

Nathan Pearce:

The confidence in [inaudible 00:16:31] comes down from that reproducible theme I mentioned earlier. So everything I do boots out of a GitHub repository. And I do things that way, all my code does it, my infrastructure comes out of repositories.

Nathan Pearce:

Because as a developer, I'm encouraged to have a curious mind and experiment. That's how I innovate. However, that is only compatible when I can just wipe out the crazy path I went down that generated something that should never have been born onto the internet, and I can just repave straight out of my repositories.

Nathan Pearce:

I can roll back that last code change, that commit, and everything is back to how it was before. Now, the way we architected infrastructure back in the five nines era, it took weeks to reconfigure, reset everything. Even months in some circumstances.

Nathan Pearce:

So constant deployment can be done extremely safely if you adopt the right mindset. Love that you used the term mindset there earlier, Rob. Todd. Sorry. Not Rob.

Nathan Pearce:

That mindset done [crosstalk 00:17:32].

Rob Boyd:

Pretty sure I must've said that somewhere. But just go ahead. Keep going. Sorry.

Nathan Pearce:

It's too similar for my mind, Rob and Todd. I do [inaudible 00:17:38].

Nathan Pearce:

That mindset of that continuous integration, like every time I make a commit, my test automatically runs and it's kicked off and I'm not involved in that. I'm involved in the response. If it comes back bad I'm like oh, I have to do some more work on that I guess.

Nathan Pearce:

And that safety of the redeploy, the reproducible operations is key. Because I have no fear that when I roll something out, it's good. And I can roll it back. And I've done it from ... this was my own system, not someone else's.

Nathan Pearce:

I have actually been out in a sports bar watching a football game and rolled back a commit I did because someone told me I broke something. And I did it from my phone using the GitHub client. I just killed that last commit.

Nathan Pearce:

That level of safety and confidence in my tooling is why I sleep great at night. And that's what this frictionless operating model is all about.

Rob Boyd:

I'm curious. So all of you guys, you all work with customers at different levels. You all have some pretty deep backgrounds that I purposely didn't have us go into here, just because I feel like it would take up all of our time just to discuss why it is.

Rob Boyd:

But I'm curious from a customer perspective, what is the reality out there? If you think through all the broad base of customers, you're probably working with people most often that are looking to make a change. But what percentage of ... are there very many companies out there that already get it and that they're doing these things? Or is everybody on some sort of continuum and others might be late to the party? Where does that fit? Whoever wants to jump in that.

Tyler Hatton:

I can start with that. I think, at least from my perspective, I think there's a wide recognition that this change needs to happen. And the different organizations, at least I've talked to. And that's getting pretty close to universal today.

Tyler Hatton:

There's very few organizations that are pushing off, at a very high level, dev ops principles, repeatable principles, and saying that doesn't work for us. I think it's almost universal. Everybody [inaudible 00:19:32] within that organization realizes this is the future and we need to figure out some way to get there.

Tyler Hatton:

Now, around developing those repeatable processes, tools adoption, change in the overall culture of the organization, I would say many of the organizations I've talked to are still early on in that process. They're still trying to figure it out, they're still trying to figure out how do they break down the existing silos that they have within their organization, how do they create those repeatable processes that reduce the overall risk within their organization.

Tyler Hatton:

That is still, from at least adoption standpoint, for many of the enterprises today is still very early on. There's a ton of documentation out there on how other organizations have done it. But again, a lot of people are just still trying to figure it out.

Rob Boyd:

Well and Todd, there's no one way to do dev ops right? Because dev ops is certainly a mindset and it's working towards a set of goals that are just about continual improvement it feels like. Which is what reminds me going back to the manufacturing days.

Rob Boyd:

Do you agree that a lot of people are still very early days on figuring this out? Because I think the only people that really have figured it out, in my experience, are the companies built from scratch perhaps and that were able to start doing things without any preexisting infrastructure.

Todd Erickson:

Right. I agree with that. I think -

Rob Boyd:

You're going to disagree with me too. I can hear it coming. Go on.

Todd Erickson:

No, no, no. I agree that basically organizations are all in transition. I would say that nobody actually has it truly figured out, because since it's a continual mindset and a continual change.

Todd Erickson:

I was actually talking to people from GitHub the other day and they were talking about all of the changes they were making to make things more improved and faster and add more testing. Trying to make their processes-

Rob Boyd:

They're trying to get better.

Todd Erickson:

Better, exactly. Exactly. Constant. And the thing is, it's an organization that you think oh yeah. GitHub, they're actually pushing this. They have this figured out.

Todd Erickson:

Well, guess what? They're still moving forward and they still have things that they need to figure out and they need to get better.

Rob Boyd:

GitHub, yeah, okay.

Todd Erickson:

Yeah, exactly. So yes, we should always be moving forward. Yes, there's a lot of organizations that are just starting this process. But this is a process that never really ends. It's about basically always making yourself better.

Todd Erickson:

And as Nathan pointed out, this is a competitive advantage. Right? So if you can get better at this, it's a good way to basically be better than your competitor. Right?

Nathan Pearce:

Todd, I think you nailed it there actually. From technology's perspective, you're never done. You're there when your mindset has achieved that space where you're thinking I'm going to constantly improve. And continuously improve everything I've done.

Nathan Pearce:

That's when you've adopted it. That's when you've made it. When nothing's the same and everything's constantly evolving to serve that purpose of frictionless deployment in a safe, reproducible manner. Definitely.

Nathan Pearce:

People think oh, if I buy this tool or I need to implement this scripting language, then I've got dev. No. You haven't. Dev ops is not tools. It's the collaborative culture that is dev ops. And that's really the goal here.

Rob Boyd:

But let's say that I am a networking person, for the sake of speaking to our audience here. Let's say someone in the audience is looking at this and going what skills do I need to be working on. Because there's a reasonable fear that goes, you know the software's eating the world, it's all developers. And the role feels like it might be diminishing for someone who's got purely connectivity skills.

Rob Boyd:

I don't know if you agree with that or not, or whatever. What kind of advice would you give? What kind of skills should someone be working on if they've come up from a networking background?

Rob Boyd:

Then I'm going to flip it around and ask you about developers and what they need to be understanding better as well. But let's start with the networking side. Let's see, Tyler, you've got the most interesting grin. Let's go with you.

Tyler Hatton:

Thank you. I think that probably, at least from my own perspective, the most important skill to have, and I might get eye-rolls and this may be too vague, but I think it's really just a willingness to work outside your comfort zone.

Tyler Hatton:

If you are the networking guy or the storage guy, the compute guy, the middleware guy, whatever that is, just to have a willingness to look at a problem from a different perspective I think is an incredibly important skill to have. And to have some level of empathy and humility with it.

Tyler Hatton:

I think coming from an operations organization, historically the problem that I have seen is we were seen as an organization that said no. No to our developers because we wanted to maintain uptime, similar to what Todd referenced earlier. That was what was important to us, was uptime. We didn't want to get alerts in the middle of the night and phone calls from angry stakeholders.

Tyler Hatton:

So from our perspective, that's what was important to us. But really I think outside of that, I think that's kind of important, is to think about from your customers, your stakeholders, their perspectives, what's again important to them. What are their care abouts. Have some empathy there.

Tyler Hatton:

And then outside of that, even go outside of your comfort zone and try to learn more about what they're doing within their own teams and try to grow from there. I think just to have that as just a fundamental skillset is incredibly important.

Rob Boyd:

Todd, do you agree with what he's saying there? He purposely evaded the idea of specific skills, but he's referring to ... and that's okay because he's referring to this notion of the mindset and the fact that I would say ideally we want every employee to be more open-minded, willing to change, able to communicate and collaborate.

Rob Boyd:

Obviously that implies a different management scenario in an organization that understands that the channels have to be set up for that level of communication. So given that, if we're exposing the skills to not just the person but to the organization, what might you add to that?

Todd Erickson:

Yeah. I mean I think number one, as the engineer, you need to stop calling yourself a network engineer or an applications developer. You need to start calling yourself an IT person. And somebody who's trying to ... maybe not even an IT person. Maybe even just somebody who's trying to help out with projects. Right? How could I move these projects forward.

Todd Erickson:

I think from an organization standpoint, you need to realize that a lot of these projects are really calling for people who have a lot of different skills. I was an applications developer for a long time before I started doing a lot more dev ops and everything else.

Todd Erickson:

In that, I didn't really get exposed a lot to networking. But I found that I need to know a ton of networking. Like it is super important for me. Not only that, but also I need to know a lot about storage and a lot about kernels and the OS.

Todd Erickson:

And that's not something that basically if I just kept myself being called an application developer, and if my managers just called me an application developer and never let me get outside of my box, I would've never had the experience to be able to do those things.

Rob Boyd:

Okay.

Todd Erickson:

So I think that cross training and being comfortable with moving people around as a manager is very very important. And I think as the person themselves being excited about doing that and being excited about learning all of these different technologies. You don't have to be an expert in absolutely everything.

Todd Erickson:

But you need to have some understanding of it. And it also helps you develop that empathy, as Tyler was talking about. When the security guy comes to you and says what are you doing, this is going to be really scary for us, you have to understand why he's saying that.

Rob Boyd:

Patience with the security team is never easy.

Todd Erickson:

It's a skill to learn. Yes.

Rob Boyd:

Sometimes not as bad as the storage team, but it's like they touch everything and they've got that trump card because they're security. And we have to get sign off on everything, or at least we should be getting sign off on them, that projects are going to be where they're supposed to be.

Rob Boyd:

But that's all part of the process. I cut you off, Todd. I didn't mean to.

Todd Erickson:

That's all right.

Rob Boyd:

But yeah, no, I think you're expanding on more of the same. Nathan, I don't know if we can get more practical here with regards to in your experience. Because you've seen this from a couple of different fences, or sides of the fence so to speak.

Rob Boyd:

Both as a consultant working for a manufacturer and working with a lot of different customers. What do you think ... where do you think they're hitting the mark and where do you think maybe we still need to understand this better?

Nathan Pearce:

Yeah. I really like what Todd was saying there. And I just wanted to show I could get your name right as well, Todd. Apologies earlier.

Nathan Pearce:

Getting people to work together and understanding a little bit of the teams around you really is super important. You can't live in your own little world in your silo anymore. We used to have ... this was common in the five nines era where you have a meeting and meet all the team architects and they'd not invite one and it would always be straightaway that's the disruptive team. They're not in this meeting to tell me how the system runs here.

Nathan Pearce:

And that type of thinking just does not work anymore. And yes there's lots of tools to learn. But I would strongly encourage people that those tools, those scripting languages, etc., to look at that as just 50%. Because over time they will change.

Nathan Pearce:

You will learn a new scripting language will come along. And that will change. But this philosophy, this mindset of I must not understand the impact of what I do on that team and what do they need to get from me as part of this pipeline of this reproducible operations that's going to support them being effective and reach their goals.

Nathan Pearce:

And only when we have that common approach are we going to be able to realize this dream of safely being in continuous improvement. And for example, like security. Like getting them less focused on everything having to be a manual policy that I'm typing down and understanding working with them to teach them that what if I'm presenting this metadata from the app at the time of building it and you build your policy programmatically around my metadata and you could have 80% of your policy tuning done if you join us in this pattern, this templatization of surfaces and apps.

Nathan Pearce:

So so much can be achieved by breaking down these barriers. But so much of it is culture. In an organization you need the 50% of the skills and the frameworks and tooling and the scripting. But then you need to get buy-in. And that comes from possibly buy-in higher up in the business to convince these people you got to come to these meetings. This is critical for our success.

Nathan Pearce:

You can't have one silo out there doing its own thing. You can leave no ops behind, which was my closing comment at Dev Ops Enterprise Summit 2017. Leave no ops behind. Otherwise you're going to fail.

Rob Boyd:

So it's interesting. I feel like I live in a certain bubble where I get to work with smart people who are always interested in learning more, like you guys. Because now we're in the same bubble, at least here for the moment.

Rob Boyd:

But consistently what I see is I meet people like yourselves that are always hungry for new information. And I get the feeling that you guys seek out, as an individual. If you weren't already working for WWT or working for yourself and doing what you're doing, let's assume that you were looking for another job or you were dissatisfied for some reason. I would assume that you're looking for the type of organization that would support you, whether you're a network engineer, a developer, or somewhere in between, in this manner.

Rob Boyd:

Would you say that's an attractive pursuit? And that also is going to become ... because you need the right people and then you need the right organizational support to be able to pull these things off most successfully. Obviously it's to all these different degrees.

Rob Boyd:

But I assume you guys want to work for companies that allow you to experiment, to learn, to challenge yourself, to expand. Is that fair? Anybody?

Todd Erickson:

Absolutely. I mean that's one of the first questions I usually ask in an interview, is ... if I'm interviewing with somebody. What are the possibilities for me to learn in this organization? Do you have a training budget? Do you have a dev ops practice? And are we all part of it? Right?

Todd Erickson:

And I think from the other side, the other perspective, when you're interviewing other people, asking and trying to figure out are they looking at other projects. What are they doing outside of just work that they're interested in? And they're trying to look at.

Todd Erickson:

And trying to find those things. I think that's ... when you can find an organization that basically wants to support you and wants you to grow, and when you find an individual who wants to grow, you have a great marriage. Right? And those are the type of things that you just can't teach.

Rob Boyd:

Yeah.

Nathan Pearce:

Hopefully I don't embarrass Tyler with this one.

Rob Boyd:

No, please.

Nathan Pearce:

WWT has a very cool story around this. Where didn't you have, when you were in WWT's IT, like a day a month or whatever, I can't remember the frequency, you can tell the story better. Where you get to experiment and I believe you won an award and were up on stage receiving that award for that work.

Rob Boyd:

Oh, let's go down that road, Tyler. Please expand.

Tyler Hatton:

No. No thanks for throwing that my way. Yeah. So I think if you look at one of the things that an organization could adopt, it's something very similar to what we do internally within Worldwide. And I think Todd's pretty familiar with this.

Tyler Hatton:

Which is what we call innovation days. And what innovation days are really about was to give every engineer within our IT organization a day, one day a month, I think it was the final Friday of every month, and they could basically use that time to experiment on basically whatever they wanted to.

Tyler Hatton:

If there was something that they were interested-

Nathan Pearce:

Right.

Tyler Hatton:

Yes, on live system. So it really ... fundamentally what it was about is you look at everything we do in IT today, there's always room for improvement. I think Todd mentioned that.

Tyler Hatton:

So what's something that you really feel like we could improve upon? And you could spend that day working on that process. And a lot of the things that I did were automation. How do we take our load balancing workflow and streamline that process of building out what's called an F5 VIP.

Tyler Hatton:

And I think the coolest part about that wasn't necessarily that phase of experimentation. It was what we did afterwards. So at the end of every single Friday, you were given the opportunity to present on what you built. In front of everybody who was interested. So a whole bunch of people in IT.

Tyler Hatton:

And you could share and evangelize hey, I built this and this is really important to me and this is why I built this. And I think that really goes a long way, especially in IT organizations where you're often put in the corner. You might be working in the basement. You don't really get a lot of exposure.

Tyler Hatton:

And I think just to give somebody in IT the ability to present on something that's very important to them, and how they're trying to address it, kind of reinforces that ability of learning new things. And building out continuous improvement within an organization.

Rob Boyd:

Well thank you. And so, Nathan, I'm glad you put him on the spot there because that is a good story. It highlights WWT in terms of having what sounds like a strong culture for doing these very things, practicing what they preach.

Rob Boyd:

But I would be remiss, we've only got about four minutes left, and I don't want to miss the fact that this isn't about WWT as its own internal IT organization and how it runs, as interesting as that may be. You guys, Todd and Tyler, you guys both represent WWT directly. You've also worked with Nathan for years in various capacities.

Rob Boyd:

But let's start Todd. What type of things does WWT offer to potentially help someone who's maybe sitting here going I don't know what to do next. I don't know what I should be learning. I either do or don't work for an organization like this, but either way I want to raise my value. At this moment in time, how could they take action on that right now?

Todd Erickson:

Right. So we have what we call the WWT platform, which is WWT.com. And that has articles and information that basically we have discerned from our various partners and various customers that we've worked with, that basically talk about experiences and ways of basically looking at these problems. And working with them and making things better.

Todd Erickson:

We also have labs on that platform.

Rob Boyd:

So hands-on.

Todd Erickson:

Which basically ... hands-on labs, exactly. So you can actually sign up for an account and instantiate those labs. And play around with some of the technologies that we see interesting and are kind of evangelizing.

Todd Erickson:

And we also have for organizations who are looking for a place to really play around with things and try out new, maybe even very large scale, testing and training. We have our own training classes that we provide in, plus we also have this idea of a proof of concept where you can engage us and we have a very very large data center that has a lot of beta gear and other things from our customers.

Todd Erickson:

And we can basically run a POC, a proof of concept, at a large scale, to help you out. So those are the things that Worldwide provides.

Rob Boyd:

Yeah. You guys do ... I'd mentioned in the open you guys are extremely well equipped. You work with a ton of different vendors and therefore you're not necessarily always ... you're in the perfect position to never have to say oh this is the only way we know how to tell you how to do it.

Rob Boyd:

You're here to partner with the customer, it feels like. And I love your focus on education. And thank God now too you guys had already been investing for quite a while in terms of making all that physical infrastructure virtually accessible. So that people could learn and take advantage of that stuff, despite the fact that we may all be stuck at home right now for periods of time.

Rob Boyd:

I want to wrap things up. Those are great places to go. Nathan, let me just ask you where can people find you? Where you hanging out on the web these days?

Nathan Pearce:

You can find me on my website, RedTalks.live. RED being ranting engineers and dev ops. That's the kind of themes. So it's RedTalks.live. You can subscribe to my newsletter. I have awesome people from WWT on sometimes, covering these types of themes.

Rob Boyd:

Yeah, I recommend that actually because he is also a host. You do a very good job and this is your lane. This is where you play in. And obviously there's a lot of smart people as we're seeing here from WWT that often play with you in that lane. So thank you, Nathan. I appreciate you taking time to join us today for this one.

Rob Boyd:

Tyler, I'm going to ask you. So I assume you and Todd, you're at WWT. I got your bios off of the platform. I'm signed up on the platform to be able to interact with you guys more effectively, as well as dive into the stuff that you guys are writing and stuff that you're demoing. Is that the best place to find yourself, Tyler?

Tyler Hatton:

Yeah, absolutely. You can look up my name on WWT.com. And what's really cool about that, and to what Todd talked about earlier, is I've created a lot of videos, blog posts, and on demand labs around many of the topics we talked about today. And those are freely accessible.

Tyler Hatton:

So if you look up my name on WWT.com, you or course can read a bio about me.

Rob Boyd:

Yeah. Todd O. Hatton, H-A-T-T-O-N. We'll put it on screen as well. Excellent, yeah.

Tyler Hatton:

Perfect.

Rob Boyd:

Thank you for all the work you're doing there. So your head gets bigger when you start getting picked and go hey I like your load balancer.

Rob Boyd:

And I love the focus you guys always put on let's not do the same manual things more than once. If it's going to be something we have to repeat within the next year, then that's way too often.

Rob Boyd:

Todd, I assume you're on the platform as well? I've seen you there.

Todd Erickson:

Yeah. Pretty much that's exactly ... what Tyler said is exactly what you should be doing for me too.

Rob Boyd:

Excellent. Perfect. Well you guys are awesome to work with. I appreciate your time. I hope you guys are happy with the way we covered this topic. I think we're roughly within the 37 minute time frame. Excellent.

Rob Boyd:

Well, guys, to those of you watching out here, you can also go to the same platform to find more information about everything we're doing in this series. We continue to put out more information. We'll also provide a place there, if not obvious yet it will be there soon, in terms of how to reach out to us and ask questions or follow up with us and make sure that we got something right, correct us. And we'll get on and address that and answer your questions.

Rob Boyd:

Anyway. Thank you so much for joining us. For TEC37 at WWT. My name is Rob Boyd. We'll see you next time.