AMA: How Can Our Small Team Embrace DevOps?

Bryan writes:

How can a small, mainly click-next-admin team/culture best get started on the journey toward Infrastructure-as-code, build-test-deploy / Release Pipeline? I see many blogs and books about more mainstream DevOps, but our shop is more like the one referred to in the Microsoft / Chef Release Pipeline whitepaper, where we only create and maintain our own infrastructure operations management files and scripts, mainly for internal corporate facing apps and systems. We don’t need to worry about any customer facing or other style of high visibility web pages or mobile apps, but I think we could definitely improve our efficacy of managing the on-premises environments we have, with a lean, properly trained, empowered staff. We have mainstream skills across VMware, Windows, NetApp, SQL, Exchange and Citrix technologies; all of which also play nice in a PowerShell-centric world. We have a few people with foundational PowerShell skills, but have not yet reached a tipping point where we really use it the way I think we could / should. Instead, we feel stuck in the rut of jumping through RDP to fix our Production ‘snowflakes’, instead of working out automated fixes in a ‘lab’, then using a DevSecOps style pipepine to get the fix to production.

Have a question of your own? Please ask.

DevOps is DevOps; the benefits potentially apply to anyone producing any code, for any reason, whether it’s customer-facing or not. So I agree with you – you can definitely achieve a lot.
You might not love this answer, Bryan, but it’s, “you just gotta do it.” The next time you need to just quickly fix something via RDP, don’t. Do it the way that you know is right. Yeah, it’ll take longer that time, but you’ll only have to make that investment once for that task. From then on, it’ll be easier and faster, and you’ll start to see a return. Over time, this’ll accrete to the point where not running a script to do something will feel odd.
When I worked for Bell Atlantic Network Integration, back in the day, I had a small team of four admins, a 3-person help desk, and a 4-person desktop support team. We supported a couple of thousand users spread across a dozen or so sites. The help desk and desktop team brought me problems all the time, but I almost never fixed them (unless it was a fire drill, of course). Instead, I wrote a script, gave it to them, and let them fix it. Sure, this was a lot of VBScript and KiXtart back then, but same thing applies.
You just have to make a cultural shift. We aren’t going to do it this way, anymore. We’re going to change. I mean, I know it’s super-easy to write that and very hard to make it stick, but that’s really the only thing you have to do. Decide to change. And then stick with the decision.
Start small. Pick one task, work on that, and then pick up another task. Start logging your tasks in a ticket system or something; you’ll want to know how much time these things take to do manually, how much time it takes to write the script, and how much time you save. Take your salary. Multiply it by 1.4. Divide that by 2,000. That’s your fully-loaded hourly rate. Multiply that by the amount of time you save per year by automating a task, and that’s how much money you save. Multiply your hourly rate by how long it took to write the script, and that’s how much money you spent. So long as the savings is bigger than the spending, you’re #winning. Doing that math can be a big help in making the cultural shift, because it represents a business outcome, whereas, “we’re just going to write scripts instead of manually facing problems” is a little abstract from a business perspective.
Good luck! Let me know how it goes!

You might also like

Add comment

E-mail is already registered on the site. Please use the Login form or enter another.

You entered an incorrect username or password

Sorry, you must be logged in to post a comment.


by Newest
by Best by Newest by Oldest

I appreciate the concept of training yourself to look at tasks in terms of business outcomes. Great point.


why take out the 2 weeks?
it's common to have longer or shorter vacation time. and it If I don't take vacation I loose it. so the company still pays the same for 2080 hours of work.


It's just a planning number. Don't overthink it; you're never going to get a precise number, you're after a round one. 2,000 is designed to be a median for a large number of situations, not David's Own Personal Number ;). Some companies, for example, do pay for unused vacation time.


Hi Don, when you calculate the fully-loaded hourly rate, I think I know why you chose those numbers, but I wanted to confirm. My assumption is you're adding 40% overhead beyond base salary to account for employee benefits. Then, 2000 represents the number of hours worked in a year, assuming a 40-hour work week, and two weeks of time off. Is that correct?