Professional Development

#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.

2018-10-23 by Blogging is FUN! Professional Development SQLServerPedia Syndication 0

TIL from Atlanta #AzureDataFest

AZURE DATAFEST

I’ve been meaning to write this post since we wrapped up the event, but life, as usual, gets in the way.  Overall, I was very pleased with the whole event; things (for the most part) ran very smoothly.  However, in the spirit of continuous learning, here’s a few lessons (in no particular order) for anyone considering hosting an Azure DataFest in the future. 

Event Management

We used Sessionize and EventBrite to handle speaker submissions, schedule building, and attendee management.  Both tools worked great, but both are a little pricey (Sessionize charges $250 for the event, and EventBrite added a $3.54 fee to every ticket sold).  The benefit is that it was very easy to generate a professional looking schedule, review abstracts, and manage attendees (from fee collection to attendance rosters).  The one downside is that the tools don’t integrate (no way to easily export speakers into Eventbrite), and we really need a central website for people to hit rather than each individual tool.  I also had a small issue where some attendee badges didn’t print; that was probably user error.

Sponsor Expectations

  • I should have added company names to each attendee badge to make it easier for them to see what company attendees were from when talking.
  • I need to explain the email\contact information privacy policies better.  Some sponsors wanted to get more contacts to add to their mailing list.  May need to borrow a page from the SQLSaturday playbook and encourage raffles to get information directly from the attendees.
  • Microsoft SSP’s were on site, and that was a very valuable contribution.  Saw lots of hallway conversations with clients and Microsoft; that’s rare for SQLSaturdays.
  • Need to charge more for sponsorships in general; we had a flat rate of $500, which doesn’t go a long way toward building a community.  Also, I need to provide more structure over what’s included in a sponsorship; we had a couple of sponsors which had 5 or 6 team members show up.  Since food was included in their sponsorship, that literally ate up most of the profit from their sponsorship.
  • Need to find ways to encourage relationships between speakers and sponsors; speaker dinners or vendor parties?

Attendee Management

  • Generally, went well.  Food portions were about right, fee was right for a two day affair, and we had very few snacks and\or drinks left over.
  • Would love to go as paperless as possible; however, I think people like having SWAG bags.  Maybe provide them with an empty bag, and tell them SWAG is available at sponsor tables?
  • Stickers were a HIT!
  • Very different crowd than a SQLSaturday.  In fact, during opening session, only a few people had heard of SQLSaturday or AtlantaMDF.  Need to do a better job of evangelizing both of those, while recognizing that this is a crowd that may not want to give up their weekend.
  • Pretty sizable fall-off on Friday (the second day).  May need to do Monday-Tuesday to see if we do a better job of retaining folks.

Speaker Management

  • As noted above, Sessionize worked great for speaker management.  Abstracts were easy to receive and review, and building a schedule was a snap.
  • Need to be more up-front about the volunteer nature of this conference.  We had a few people that misunderstood, and submitted from abroad, and then inquired about travel reimbursement.  It was cleared up over a few emails, but I should have headed that conversation off earlier.
  • I had a speaker withdraw because we charged $50 to attend the two-day conference;  they felt that didn’t fit as a “community” event, since most community events should be free to the consumer (or offer an optional lunch, like SQLSaturday does).  I get the point, but in practical terms, that’s tough to do with a new event.  No event is free; just different people (sponsors) pick up the tab.  We’ll continue to work on this, but ADF may always have a small fee associated with it.
  • Most sessions had speakers sitting in the audience.  I haven’t seen that happen at SQLSaturday’s in a long time, so I’m hoping that people learned as much as they gave.

Logistics

  • Facility was great, but room capacity != seating arrangement.  I had to steal chairs from sponsors, and actually order more chairs on the first day to eliminate standing room only.
  • I loved having the plenary (everybody in one room) sessions at the start; really need to do one at the end, and then do a wrapup.
  • I could have saved some funds on table linens.  The caterer brought their own, and they weren’t really necessary for the check in tables.
  • We had a few technical glitches, so we need to make sure we keep the facility staff around next year.  They went to lunch and weren’t back in time for the afternoon session, so those were a little rough (maybe promise them free lunch next year?).

2018-09-17 by Conferences Professional Development SQLServerPedia Syndication 0

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).

 

 

2018-09-12 by Blogging is FUN! Professional Development SQLServerPedia Syndication The Social Web 0

The Definition of Service

As I’ve blogged previously (The S in #SRE), I’m in the process of transitioning my team from database and system administration to a team focused on service reliability. As I’m continuing to evangelize DevOps and Service Reliability Engineering within my business unit, I’ve realized that I need to have a good strong definition of what exactly a service is. I figure if I’m going to work through this, might as well do it in my blog so I can find it later.

A Service:

  1. Is an abstraction of value. Services are containers for delivering value to a customer, either internal or external.
  2. Has a consistent definition. It’s comprised of people, products, and processes, and while the relationship between those elements can change, but the inputs and outputs of a service are relatively consistent.
  3. Requires a backup strategy. Disaster Recovery Plans and Business Impact Analysis are foundational tools for the management of quality associated with a service. While a DRP may contain multiple recovery strategies, a Service should be able to be recovered entirely.
  4. Should be continuously improvable. This means that a service is only fixed at a point-in-time; components should be versioned so that management processes (including recovery) are synchronized with the delivery of value at a given time.

More to come.

2018-05-25 by Professional Development SQLServerPedia Syndication 0

“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!

2018-04-18 by Blogging is FUN! Conferences Professional Development 0

One Weird Trick to Build a #DevOps Culture

I know it’s clickbait, but I really did want to reinforce the simplicity of this post. I think building a DevOps culture can sometimes be daunting for most folks from traditional IT backgrounds because, well, people aren’t systems. You see, both developers and system engineers are comfortable with technology; it’s usually predictable, and it’s relatively easy to manipulate.

People (and processes) are messy. The social aspect of a sociotechnical environment is full of friction: different backgrounds, different perspectives, differences of opinion. It all creates a challenge for solving business problems quickly because it takes energy to build and maintain a relationship. However, once those relationships are established, the benefits multiply. When you are challenged by a peer you trust to defend an idea, it makes the idea better. The old adage of “iron sharpens iron” is true; smart people make smart people smarter.

But how do you build trust? The first step is easy.

Be thankful.

That’s it; acknowledge when people take a risk, and thank them for stepping of their comfort zone. Be thankful when they offer an opinion that’s different than yours, even if you don’t take the advice. Specifically acknowledge their contributions that make your job easier, and let them know why. It takes some time (and occasionally some effort), but it establishes a pattern of trust. This is particularly important when you’re in a leadership position, and they are not; the best ideas come from people who feel like they can contribute on a regular basis, especially to people in power.

Take the extra time to say “Thank You”, and establish a foundation of trust.

2018-03-28 by Professional Development 0

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.

2018-02-12 by Blogging is FUN! Professional Development SQLServerPedia Syndication 0

Finally hanging up the shingle (part time)…

Let me get this out of the way first; I haven’t quit my day job. I’m VERY blessed to work at a great company that lets me work from home, balance work & life responsibilities, and has great pay and benefits.

However, I’ve had side gigs for the last 15 years or so; at first it was to make extra money, and then after my divorce and child support payments kicked in, the side hustle became crucial to my financial survival. Once I satisfied those obligations, the side gig is not really necessary, but man, it’s nice to have to spring for the extra vacation here or there. As such, I finally decided to make it real, and have now established myself as an LLC in the state of Georgia.

I feel so grown up.

The real irony of this is that shortly after I filed the paperwork, I was notified by my longest running bread-and-butter side gig that they had been bought out, and my services would be phased out by November. I went ahead and filed for the LLC anyway, but it just strikes me as funny that now that I’ve finally got a “real” business, I don’t have any clients.

I’ll just keep on keepin’ on, but there is a small sense of satisfaction knowing that there’s now a CODEGUMBO, LLC. Anybody need a SQL slinger for hire? Project Manager?

2018-01-28 by Blogging is FUN! Professional Development SQLServerPedia Syndication 1

The S in #SRE

As I’ve blogged previously, my responsibilities at work have shifted to focus more on the application of Site Reliability Engineering principles to the delivery of our business services to our customers. Unofficially, we’re calling my team Service Reliability Engineering for a few reasons. I thought I’d take some time to explain what the differences are, and why I think the name matters. I realize I’m just one lonely guy in the wilderness, and I’m going up against Google, but I think one word in the title is wrong. Before I explain why, let me explain what I do like about the title.

Engineering defines consistency of methods.

I realize that engineering is an interesting terms these days, with lots of different definitions; you can even be sued if you call yourself an engineer inappropriately in the wrong jurisdiction. However, the term itself is widely used in technology careers to describe the systematic design and operation of complex systems. Most modern applications are actually comprised of several smaller applications, all in varying states of underlying complexity. Furthermore, the delivery of an application to an end user (particularly web applications) can span the entire spectrum from infrastructure to platform to software. Additionally, applications can vary in terms of scalability, configuration, and location. Engineering addresses complexity, not just complication through systematic processes; engineers experiment, learn, and integrate consistent practices into their daily processes.

Reliability refers to purpose.

When your job title identifies reliability as a name, it means that you have a specific goal in mind, and that goal is not limited to a technology. Reliability engineers work with networking equipment, operating systems, applications, middleware, and/or database systems. They may specialize in a area (e.g., database reliability engineering is now a thing), but a robust team is comprised of necessary skill sets required to meet service level objectives across the entire technology stack. Reliability as a goal must first be defined, and then measured, and SRE responsibilities are responsible for measuring and addressing reliability across the entire spectrum, from infrastructure to platform to software. However, reliability measurement must also account for not only technological issues, but also the processes and people responsible for developing and operating the system. There’s a reason that a just culture is an integral part of the SRE experience (and the DevOps movement at large); people are responsible for how well technology performs, both in terms of defining expectations and day-to-day delivery of service. It only makes sense to look beyond technology when examining reliability, and that leads to where I disagree with the standard SRE nomenclature.

“Site” implies a technical focus; “Service” implies a business function.

The word “Site” in the IT domain typically refers to either a physical location (data center site) or an application (web site); however, the heart of the definition is sociotechnical, not strictly technology. From an undated (seriously, Google?) interview with Ben Traynor, the founder of the SRE movement: “… we have a bunch of rules of engagement, and principles for how SRE teams interact with their environment — not only the production environment, but also the development teams, the testing teams, the users, and so on.” While the previous paragraph of that interview specifically focuses on the type of work that’s being done by Google’s SRE team, these rules of engagement show that SRE’s should be concerned with the entire value stream of service delivery including not only operations, but development, testing, and ultimately the end user experience.  In, other words. SRE’s are concerned with the reliability of the whole service, not just the technical parts.

2017-12-01 by DevOps Professional Development SQLServerPedia Syndication 2

#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