Check out a free preview of the full Enterprise DevOps & Cloud Infrastructure course

The "Three Ws" Lesson is part of the full, Enterprise DevOps & Cloud Infrastructure course featured in this preview video. Here's what you'd learn in this lesson:

Erik reviews the Three W's of strategy. What problems are we trying to solve? Who are we solving it for? Why are we solving this problem?


Transcript from the "Three Ws" Lesson

>> We're gonna start off by following the three W's of strategy. Now this is something that we do explain in the DevOps course, but we're not gonna go too deep into it. But we just wanna make sure that we're all on the same page here, okay? So what problem are we trying to solve is our first W.

That is most importantly the biggest question you have to answer. If you cannot answer what problem you are trying to solve, you probably either don't have a problem, or you don't know what the problem is. So this is a very, very important part of working in DevOps. And sometimes, you'll have circumstances where stuff is on fire.

Nobody wants to be asked what problem are you trying to solve while things are on fire. But the reality of it is, you still have to, and that's why it's really important. Also with when things are on fire, you still have to ask, well, who are we solving this for, right?

Part of this position or this practice is about making sure that you're doing what's best for the company and the company's infrastructure. It's not about what a particular developer may want, or an opinion of a specific person, it's about looking at the overall company and saying, okay, is this valuable?

And is this going to be solved for the person we expect it to be solved for? And then again, the last one is, why are we solving this problem? So what are our problems, right? What are our problems if we're a brand new company? What would those look like?

Well, we'd ask our first W, right? Brand new company, I just hired a whole bunch of people, what problems are we trying to solve? Can anyone think of any problems? What would be first, maybe a couple of things that you would think about? Brand new company just had hires, nothing's been created yet, what would be something that you might be concerned with first?

>> Storage.
>> Storage, yeah.
>> Authentication.
>> Authentication, yeah.
>> Who owns what?
>> Who owns what, permissions are back stuff like that. Yeah, anyone else?
>> Cost.
>> Cost, yeah, all of these things, right? And we're not even talking technicals, we're really not talking technicals yet.

But you can't, and this is something a lot of engineers do, even I have tried to take a step back from, which is, don't just fly down the problem, right? Don't just be like, we can technically solve it this way. You have to take a step back and say like, okay, what are we solving exactly here?

And so yeah, you guys nailed a lot of this on the head. For starters, for me, and I think that some people might even argue this, but I think it's true, accessing control and permissions is gonna be the first thing you're worried about, why? Because it's your intellectual property, right?

You wanna make sure, and companies fail at this constantly. Companies constantly fail at not putting good policies in place, not putting good permissions in place. And that's why you get data breaches, that's why you get a bunch of other like broken stuff or things. If you don't have good edges that people can basically work around, it makes it very difficult for you to operate as a company.

So access control and permissions is huge. It's a huge part of it. If you are a software company then you'll probably need to consider software life cycles, all right? So, how are we gonna develop software? What tools are we gonna use? How often are we gonna release that software?

Who's gonna be doing what, right? Things like that. And then you've got supporting infrastructure. So, not only are we talking about access control and permissions, now we are talking about how are we gonna develop our software. Now it's like okay, well, now we know what we want to build, what are we gonna build it on top of?

[LAUGH] You know what I mean? So infrastructure becomes a big part of it. And then finally, and I do think that this is important, and unfortunately it is not something that is taken seriously more, which is developer experience, DX. To quickly talk about DX, and I do talk about it more in the course.

For a DevOps perspective, developer experience is crucial to the company. If developers aren't enjoying themselves, you're not gonna get good product. Why would you? They're probably barely putting in the effort they want to, or they're hating the technology they're working around. And so it really does become part of a problem to make sure that developers are actually enjoying what they're building and what they're working on.

So, now that we know what problems we're trying to solve, right? Who are we solving these problems for, right? So the first is gonna be hands down developers, through and through. If you're a software company, your problems are gonna be for developers, right? Those are your end users.

Now the developers end users are the people who go to the website, but your end users are developers. You're also got end users for quality assurance. So you're gonna be working with QA, you're gonna be helping them, supporting them with the things that they need, right? So they're also part of the people that you'll be helping.

IT, right? Yes, you'll also be working with IT. I know some companies that purposely separate DevOps and IT and don't have them work together. That's not a good idea. At Hippo, where I work, IT and DevOps work intrinsically together, so that we can integrate together. And so we have a circumstance where we have SSO, OneLogin, all this stuff.

And we went to IT and said, okay, well, what do you need so you can set up your authentication and everything? And then we'll build the automation to provision the users where we need. And so we enabled it to be able to create users, manage them, do whatever they need to, and then just gets automated.

So that's a problem we don't even think about. So having IT as a part of the people that you're trying to solve problems for is very important. And then others. This can be any other organizational unit, whatever, there might be other parts of your company that may need DevOps infrastructure help, things like that.

But I think the biggest point here is that outside of finance [LAUGH] and maybe some other parts of the company, you touch a lot of the parts of the company. Your job in doing this role is to come kinda make everyone happier, tor try to at least the best that you can.

So, these are important people. If these people aren't on the list for the people that you're trying to solve problems for, then you might not be solving a problem valuable, yeah?
>> If your company had significant compliance requirements, would that be an instance where DevOps actually does talk with finance?

>> Yes, absolutely, yeah. DevOps would be in charge of the compliance from the infrastructure perspective. So, they would need to coordinate with finance for an understanding when are we doing changes, when do we need to take things into effect, right? All that stuff. And we do that at Hippo as well, where I work, yeah.

We don't talk to legal very often, but I mean, even when it comes down to like, we need to update our TOS, or we need to do things like that, some of those things we personally take care of just because of the importance and the severity. We're an insurance company, so if we get our TOS wrong, that's kind of bad?

[LAUGH] And yeah, yeah, it can be that. I think the overall thing to take away here is, you should wanna help. Even if it seems like it might not be something that is directly related to you, you are a figurehead for the company in some ways, and a lot of people will look to you for that help.

And then finally, now that we know who, well, why are we solving these specific problems, right? And so, this one's actually very easy. I tried to separate it really into two things, which is one, you have organization needs, and then you have organization unit needs, right? And if you've ever heard of this or if you've ever created an SSL certificate before you've heard of OUs and organizations, basically.

It follows the same common pattern of you have a global level of infrastructure, you have a lot of things that you need to maintain, and these resources are reused by other parts of the company, right? But then you also have specific resources for specific parts of the company, and so you kinda have to have like a layer here, and then you have a layer that you build on top of it, right?

So the organization layer comes first, the internal stuff, and the organizational units, basically, are built on top of that. There can be more to this too, but I think to try and think of this as plainly as possible is probably a good idea.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now