Blogging is FUN!

My one true #DevOps statement…

After my last post, Brent Ozar offered the following suggestion on kickstarting my thoughts on “People First”

” Come up with the one true sentence, and the inspiration flows out of that. Sometimes you hang the entire post on that one sentence, and sometimes the sentence just ends up slipped in somewhere almost as an aside. “

I mulled over it over the weekend (in between basketball games, date nights, and family technical support), and below is the best I could come up with. I think it’s a useful exercise, and I’m going to focus my energy today on expanding this thought:

The primary purpose of software development is to add value to humanity; however, most software development processes dehumanize the creators.

More to come. And, thanks, Brent! I owe you yet another beer.

Writing is hard…

I’ve recently started working on a book, and have rediscovered that if you don’t exercise on a regular basis, it sucks to start. I need to think of this blog as an opportunity to get my regular writing “steps in”, so that when the time comes to actually start running, I’m ready.

One of the challenges I’m having is articulating my thoughts on the concept of “people first” in DevOps. It’s the first element in Donovan Brown’s definition, and embedded in the first value of the agile manifesto, but yet, people don’t get it. I was recently involved in a Facebook conversation on the evolution of graph databases, and was saddened by the fact that many people who I know and respect still see an ongoing war between developers and DBA’s (and often make assumptions about the other camp).

I may be naive, but I’m trying to find the good in people, and trying to build value to customers. Different roles and skills are necessary, but allowing those roles to foster tribalism to the detriment of the goal is a futile pursuit.

More to come.

To be a #DevOps Leader…

…you have to do less work, and do more to improve work.

I know, it’s been said 1000 different ways already, but it sunk in this week as I struggled to put out the bazillionth little forest fire that had crept up after our last deployment.  It’s so easy to get back in the rhythm of doing whatever it takes to keep the system stable, even if it means sacrificing time with family, projects you want to make headway, general health and well-being… IT work is built on the backs of heroes.

But it isn’t sustainable.  I look back over the last month and wonder what the hell it is I accomplished.  My team is worn out; I’m worn out.  We managed to squeak in a major project, but we had to drop the ball on 100 other little things to get it done.  And, to rub salt in the wound, the new project added new work to the backlog, which just means that we may have won the battle, but it’s an expensive win.

My job as a leader is to make sure people know how much wins like that cost; not to discourage them from trying to make a win, but to make better strategic decisions so that we don’t sacrifice something important in order to get some other important thing done.

Monday’s coming, and I’m going to start over. Again.  And i”m going to keep starting over until things get better.

#DOES18 – Tuesday Takeaways

Thoughts from yesterday’s DevOps Enterprise Summit in Las Vegas

  1. Managing workflow is different than managing configuration changes or code.  It’s related, but you can have separate systems for individual team’s processes and procedures (i.e., Azure DevOps for developers, ServiceNow for ops), but you want to make work visible to all affected teams.
  2. Making work visible was a theme I heard over and over again; so much of the “throw it over the wall” mentality stems from the fact that ops does magic. 
  3. Processes are necessary, but they must be as light as possible or they won’t meet the need (they get in the way of rapid response).  People often adapt by ditching the process anyway.

#DOES18 – Monday Takeaways

This is a quick post; I meant to get this pulled together last night, but hey, I’m in Vegas.  There were things to do, so I’m hammering it out before the morning sessions start.  As always, this is a fantastic conference; it really shifts the focus away from specific technological solutions to understanding why technology is important to delivering business value.  In no specific order, here are my key takeaways from yesterday:

  1. I need to do a better job of articulating my vision, and asking my boss (and his boss) to do the same.  What’s the message we want to send to our employees?  To our clients?  To our competition?
  2. Minimum Viable Compliance – we are so process-heavy; how do we convince governance to help us do the right thing, but do it in such a way that it reduces the strain on the system?  Governance as a Service.
  3. Return to our roots- build a service catalog, and use it to describe architecture.  Every single component of the value stream (ideally) should be captured, and used like Lego blocks to define service delivery.
  4. Reliability Engineering needs to be visible.  Keep measurement and reporting simple; start with a rubric, and a pass/fail mentality.  Dedicate time to toil reduction as a team, not as individuals.

Lots more to come, but wanted to get these notes out the door.

Look Mom, I’m famous….

Well, moderately well-known 😛

I had the pleasure of being a guest on Andy Leonard and Frank LaVigne‘s podcast, Data Driven.  I was originally going to talk about #SQLFamily, Azure DataFest, and community life in general, but the topic quickly changed in light of the Azure outage on the day we recorded it (9/4/2018).  So we rambled on, joked a lot, threw in some 80’s pop culture references, and generally had a good time. Give it a listen on your favorite podcasting app.

Hopefully this will inspire me to find time to write more.  We touched on a lot of ideas, but didn’t really dive very deeply into any of them.  I need to stop DOING, and WRITE IT DOWN (that’s a variant of the advice I give my team).

 

 

#DevOps – Lead by example, but set the right example.

Last weekend, I missed a data center migration.

It was a scheduling conflict; for Christmas last year, my wife had bought me tickets to High Water music festival (which was great, btw), and when they set the dates for the data center migration, I was worried. The tickets were expensive, and we had booked hotels, etc; I couldn’t change plans to work with the schedule, and there were too many teams involved in the migration for them to pick a different date. We’d done this migration once before (6 months ago), and I was confident in my team’s ability, but still… I was worried. You see, missing an after-hours deployment or a maintenance window of this size wasn’t usually considered to be an option before (by me). I’ve always been a firm believer in the management rule of: Don’t Ask Others to Do Something You Won’t Do.

So, every migration, every deployment, every maintenance window… I was there. Weekends, mornings, evenings… I was there. When our first major data center migration blew up a year ago, I was there for 26 hours. I THOUGHT I was sending the message that “I’m here for you… I’m leading the way… I’m being a team player.

That’s not the message I was sending.

What happened while I was away is that others stepped up and filled the void left in my absence. They didn’t do things exactly like I would have done, and they had to take on some additional responsibilities during the migration, so their timing wasn’t as efficient as if I had been there. But the work got done, and we survived without me. I could have looked at that and said “aha; I’m not really necessary; there’s some waste savings there!”. Instead, I realized that what I thought was a four-person job was really a three person job, and that meant that the fourth person could do what was more important than work; life.

You see, the message that I was sending by being at every activity outside of work was that I Expect Y’All to Give Up Your Free Time for Your Job, Just Like I Do. I didn’t mean it that way, but my employees picked up on it. I was there; they were there. Every time. And that’s no way to work.

What I realized this weekend is that Leading By Example also means Resting By Example. If the job really is a three person job, then four people don’t need to show up to do it (or else work will expand to make it a four person job; a variant of Parkinson’s law). And while I should still be willing to do the job, I need to be willing to do it when it’s my turn. I’m now scheduling rotations (I’m in one of those rotations as an engineer), and letting my team understand that it’s not just OK to not be at every maintenance window activity; it’s expected. A job is what you do to pay the bills and enjoy life. If I believe that for myself, then I need to set that example for my team as well.

“Presenting” at #SQLSATATL – #LeanCoffee #DevOps

My supplies for my workshop!

On Saturday, May 19, 2018 at SQL Saturday Atlanta, I won’t just be an organizer; I’m a presenter! My session, “All (Data) Things Considered: The Lean Coffee Workshop” is something I’m very excited to “present”. I use that term loosely, because the whole point of a lean coffee workshop is that it’s a structured, but agenda-less discussion. I participated in one of these at the DevOps Enterprise Summit in 2017, and it was a fun, and inspiring way to engage with other people who were facing very similar problems as I was.

The way it works is that there will be a brief introduction at the beginning of the session, but people are expected to form several small groups. A seed topic will be presented, but each small group will have a moderator (and thanks to my volunteers) who will make sure that their group stays on track. Every group will:

  1. Set up a personal Kanban board.
  2. Identify topics
  3. Vote & discuss.

That’s it. Easiest presentation I’ve ever done, but the goals are really deep. I want to encourage people to engage with each other; that’s one of the original goals of SQLSaturday, and I think traditional classroom settings don’t do enough of that (conversations are usually instructor -> audience, or audience -> instructor). This puts people around a table in a small, safe environment, and that leads to long term possibilities for relationships.

Second, I’m more interested in conversations about improving work, rather than just how to do work. I think coffee talks foster that because you’re not looking at a tool or a piece of code; you’re talking to a person, and hearing what they think. That sharing of perspective can spark new ideas, and new ways of looking at the forest, rather than individual trees.

Looking forward to seeing you there!

Goal – 52 blog posts a year

I’m sure nobody but me has noticed, but you may have seen an uptick of blogs on my site lately.  Most are short (like this one will be); many of them have little of interest to anybody but me.

It’s all part of a goal of mine to get out of a writing funk.  I’m trying to blog at least 52 time this year, even if it’s only a few lines.  I figure writing SOMETHING is better than sitting in a stupor, and letting my brain rot.  Creativity is mostly inspiration, but there’s also some discipline required.  So bear with me (if you want) as I struggle to find something interesting to write about.  Hey, at least it’s better than the alternative.

 

Friend of Red Gate 2018 – @redgate

I’m super excited to have been named a Friend of Red Gate again in 2018; I often wonder why they keep letting me back in because they do so many super awesome things with so many super awesome people.  However, I’m grateful as always.

They are an amazing company, and have always been very supportive of the SQL Server community.  Thanks so much for bringing me along on the ride, y’all.