DOES

#DOES20 Reflections

I usually try to write these Three Things I’ve Learned posts at the end of each day of a conference, but this is a little different. This is the first multi-day virtual training event I’ve been to, and because it’s virtual, there’s no travel. Which means my day begins on EDT, and the conference starts (and ends) on PDT. Makes for a very long day.

That being said, I love this conference: DevOps Enterprise Summit 2020 continues to push me to think abstractly about technological problems, and grounds me again in looking at cultural issues within my organization. These are the three things that have resonated with me (so far):

  1. I’ve got to do more to make the pain visible across the organization. Lots of folks have stressed the necessity of communication across teams, disciplines, and to the upper management, and that’s really sticking out to me. I think we’ve done a decent job of complaining, but we haven’t done the best job of proposing better ways of solving problems.
  2. I need to celebrate my team’s victories more. My team works hard, and there are moments when they feel forgotten in the grand scheme of things, particularly when other teams are holding them back. I need to make sure that they realize how much change they’ve promoted, and how far we’ve come as an organization.
  3. Set the Vision, but focus on the first step. A few years ago when I started us on this journey, I laid out a vision, and I need to revisit that. A lot has changed, including both targets we hit, and goals that are no longer on the roadmap. I need to make sure that I frame each step along the way in terms of the value it brings to the service we’re offering.

Virtual conferences are a different kind of fatigue; it’s been rough staying focused. I think I’m going to write another blog post to describe what’s worked for me, and what I’ll do differently in the future.

Back to learning; 3 more hours to go today 🙂

2020-10-14 by Uncategorized 0

#DOES2020 starts tomorrow

This is one of my favorite conferences, and obviously COVID-19 changes everything. It’ll be interesting to see how going online changes the tone of the conversation. One big benefit is that the cost is definitely lower while the quality of the content is expected to be the same; I miss traveling, though.

I know most folks have done a virtual conference this year and have already mastered the Zoom burnout, but I’m a little concerned about. I’m going to try and beat it by staying engaged with a co-worker who is also attended. I also plan on live-tweeting and or blogging as it comes.

Getting my learn on.

2020-10-12 by Uncategorized 0

Guest of @RedGate at #DOES20

Haven’t blogged in a bit, and I definitely need to get back to writing. However, just wanted to post a quick note that I’m super excited to be presenting a guest session with RedGate Software‘s Grant Fritchey at the DevOps Enterprise Summit. I’m very excited about this for multiple reasons:

  1. I love this conference; DOES is very inspirational, and there are lots of great speakers and content. It’s focused more on the technical goals than the actual tools, so it’s a good fit for where i am career wise.
  2. I love RedGate Software. Their company is simply an amazing producer of tools for the database community, and they’ve been very supportive of #sqlfamily and #sqlSaturdays for a long time. I’m stoked that they’re expanding their reach.
  3. Grant‘s ok. (Really, he’s a great guy and a lot of fun to talk to).

See y’all in virtual Vegas. Registration for the conference is half-price through August 31; it’s a great deal at $325.

2020-08-13 by Uncategorized 0

#DOES17 San Francisco – Things I Learned

Just spent the last few days at a technical conference that focused more on cultural change and workflow than bits and bytes, the DevOps Enterprise Summit. It was enlightening, and for the first time in a while, I’m leaving a professional conference energized and hoping to implement some of these ideas. The DevOps community reminds me a lot of the SQL Server community; passionate people who just want to help each other grow. There’s so much good content, and I think most of it will be available via YouTube later.

Armed with my handy dandy Rocketbook (I left my laptop in my hotel room each day purposefully), I scribbled notes fast and furiously. At the end of each day, I tried to capture three things that struck me as important, based on everything I’d heard. Here’s my list, broken apart by day:

Day 1 – Nov 13, 2017

  1. You are on the right path, do not fear. Change only happens when you take risks.
    I’m not sure why this struck as so important, but it was a feeling of general acceptance of ideas. I often struggle with being a leader because I think too much about the challenges ahead; that’s fear, pure and simple. The truth is that every challenge in technology has a solution; it may not be obvious, it may not be immediate, but it’s there. Fixate on the goals and successes, and don’t worry about the challenges.
  2. Value Stream Mapping is key to continuous improvement.
    This came out of the workshops, based on the Lean Coffee format; one of the discussion points that came up was the value of value stream mapping. I already liked the concept, but I tend to drift into thinking about the software components, whereas the discussion focused more on the people & process aspects of it. You can’t improve until you know where you are starting from.
  3. T-shapes are the best shapes.
    I had come across the term T-shaped professionals only a few days before flying out to San Francisco, and I was surprised to hear it mentioned in at least 4 sessions today. It aligns well with my vision for Service Reliability Engineering; people can (and should) be experts in a key area, but have some depth in additional necessary areas.

One of the amazing graphic facilitation artifacts done by Christopher Fuller of Griot’s Eye at the conference.

Day 2 – Nov 14, 2017

  1. Start with what you can do, but don’t be afraid to ask what other people are doing.
    This ties back into the first message from day 1 a bit, but it’s a little bit of a twist. Often when I see good ideas, I think “I can’t implement that”, and I may be right; I don’t have control of my infrastructure anymore, for example. However, just because I can’t do it, doesn’t mean that I shouldn’t tell people about something I’ve seen, and ask if it fits into their mental model of where we’re going.

  2. The SRE model works when you focus on people, not technology, and reliability (what you can measure and improve).

    Site Reliability Engineering talks were in short supply at this conference, but it permeated throughout. The fundamental truth of focusing on people, rather than technology still holds true with this model; technology breaks because of people. That’s not intended to be a statement of blame, but rather an understanding that technology does what it’s told to do; when things go awry, there’s an opportunity to understand what humane choices to make; is it a misunderstanding of purpose? Was there a missed signal of pending change? Was a change implemented riskily?

  3. Service Level Objectives (SLO’s) are crucial to monitoring.
    Operations folks are inundated with logs and other metrics; understanding what the expectations are for the business service is key to understanding what metrics to observe (and what to ignore). You cannot measure reliability effectively without some understanding of what up-time means.

Day 3 – Nov 15, 2017

  1. Foundation of journey is based on a three-legged stool: Service Level Objectives, Value Stream Mapping, and Technical Architecture Map.
    I know, the whole DevOps is a journey thing is a bit tired, but it’s an attempt to represent the fact that everybody’s experience with these principles yield different results, and paths. However, for my current work situation, we’re not going to get far without these three things. We need to understand what the Service is supposed to do, how the people interact with the technology, and how the components of the technology are supposed to work together.
  2. DevOps brings joy to technology; don’t quibble over details, but focus on bringing humanity into technical work.
    Gene Kim’s closing comments reminded me a lot of my #sqlfamily; everybody brings a different perspective on technology, and a different method of solving problems, but the people that impact me most are the folks that do so with joy. They have a passion about what they do, and their goal is to encourage others to move forward (rather than focusing on rigid solutions based on their own experiences).
  3. Patience – all change takes time, and the road is uncertain. Don’t expect overnight successes.

    Finally, my head is full of things to think about, and books to read. However, there is no magic pill for implementing change in my organization. It has to happen slow, and it has to be organized by every member of the team who wishes to contribute. It takes time to light a fire, but it is crucial to the success of any DevOps initiative.
2017-11-15 by Conferences Development DevOps Professional Development 0