#ThankfulThursday

I’ve been a lousy blogger lately, and I apologize for that. I wish I could promise to do better, but life keeps moving, and things have been quite busy. However, I believe this topic is important, so I’ve decided to take a moment to share this post.

Yesterday, I had the opportunity to participate in a couple of panels at the Redgate Summit in Atlanta. It was a great experience, mainly because I got to spend time with friends in the SQL community.The Redgate product suites have continued to evolve and grow and continue to impress me.

During dinner that night, I sat next to my good friend Tim Radney. Our conversation turned to Brian Moran, another friend who passed away a few years ago. As we reminisced, we realized how influential Brian and others in the community had been in our professional growth.

It struck us that we don’t express gratitude often enough for our professional communities. So, Tim suggested we do something about it. His idea? Let’s start a blog series, similar to the T-SQL Tuesday series. But I thought, why not keep it even simpler?  Thus, we’re committing to #ThankfulThursday as a hashtag on LinkedIn.

Feel free to join us! Let’s lift each other up and celebrate those who’ve shaped our journeys.

Too busy to blog lately…

…and I can tell that it’s starting to affect my ability to actually craft meaningful content in other ways. My emails suck. I’ve tried writing an abstract for a presentation that’s due next week, and I’m getting nowhere.

I need a fresh start. So here it goes. The only way to get stronger is to exercise. If I want to be a better writer, I need to write. Even if I’m feeling particularly uninspired; I just need to get thoughts out on paper and go from here.

So what am I working on today? For now, I’m taking a couple of on-line courses on logs and APM’s. It’s not particularly thrilling, but I need to get my head wrapped around an application that we’re using at work, so let me start there.

Headed back to Chicago

Internal conference this week at Grainger, and I’m presenting two lightning talks. Excited to see my team again, but traveling is hard (especially without the family).

Two separate Kanban talks: an overview and one focused on two different styles of boards (time versus project based).

#DASH2023: Three Things I Learned

Recently attended the 2023 DataDog DASH conference, and it was a lot of fun. This was the first in-person multi-day conference for me in a while (I did crash the PowerBI SQLSaturday Atlanta conference back in February, but attended no sessions and mostly just went to see friends). I had a blast; the conference space was amazing, and the content was thought-provoking. Here’s my key takeaways.:

Take your team to conferences.

I’ve been a manager for over 10 years now, and I’ve struggled to convince upper management to send multiple key individuals to conferences. Thankfully, my director at Grainger is a big believer in education, and not only did he encourage me to send a team, but he also wanted to come as well. It was awesome to have feedback on topics both upstream and downstream. I had team members with a variety of experiences (junior, mid, and senior), and they raised some insightful questions. We split up often, so I still managed to make some new networking contacts but it was good to come back together and discuss new ideas.

Your fires are no worse than anybody else’s fires.

Sometimes being on the production side of the development pipeline you get the feeling that the world is burning and there’s absolutely nothing you can do to save it. While we were at the conference, my slack channels were screaming about several ongoing issues that my team was having to deal with. At times, it’s overwhelming.

But talking to folks at the conference from companies in all types of verticals from health care to automotive to financial to manufacturing, we’re all dealing with the same issues. Changing enterprise systems is hard, and modern development methods often accelerate faster than production systems can respond. Additionally, systems that have been in place for years have often grown connections to other systems in unexpected ways; things break, and they break fast. Observability systems offer hope, but we shouldn’t feel like we’re the only ones struggling with implementing that vision.

AI, AI, AI,AI, AI, AI

Artificial Intelligence and Large Language Models are here. DataDog offers some compelling use cases to accelerate MTTx (Mean Time to Detect, Acknowledge, Respond, Repair, Resolve), but it will take some time to get the plumbing set up for it to provide value. Additionally, users have to be trained on how to do their jobs with a co-pilot. They have to trust the system, and know when to dive deeper than the initial responses. They have to know how to phrase questions in such a way to help the assistant understand them, and they have to understand what the assistant is suggesting. That’s going to take time.

Practical #kanban – map your flow to your work

When I started my new gig a little over a month ago, one of the first problems I wanted to tackle was the flow of work. My team does a lot, and some of the work is very structured and repetitive, whereas other work is much more fluid. It’s really two teams with different foci; they run different sync meetings, and had different work intake processes but they were sharing a board.

The board was a typical software-development style kanban board; board columns included things like:

  • Ready – User stories pulled out of backlog based on business priorities
  • In Progress – work that was ongoing
  • On Hold – work that was waiting for other team input
  • Validate – Work that needed sign-off from someone
  • Closed – recently “done” items

For a fluid SRE team where the project work can be ambiguous, a flow like this is OK (with some caveats that I’ll explain below); In Progress is a “squishy” state for work; you don’t know what the steps are, or how long it’s going to take at a glance. However, SRE work can be “squishy”; you don’t know if you’re going to be writing a script to automate a technical process or helping coordinate a large scale project to implement SLO’s for a new service. Having a card sitting In Progress is just a visual reminder of a task list.

For structured, repeatable work, though, this style of board has limitations; if the steps of being In Progress are known, then you can highlight obstacles in your process by teasing them out. The regulated work team doesn’t know how often projects come in, but when they do, they followed a series of steps for every project (no matter how much data was involved. There was also a lot of regular back-and-forth between this team and client teams early in the process; using the old board, cards were constantly moving back and forth between In Progress and On Hold. It made WIP limits on the board very difficult to track.

We spun up a new board to better represent the flow, focusing on replacing the concept of In Progress with more specific states tailored to the flow. We also identified the primary constraint(s) for each state, be it Client, Team Member, or Systems:

  • Ready: Projects (not single stories) pulled from the backlog in terms of priority (Client)
  • Requirements: A discussion phase with clients to finalize the expectations (Client\Team Member)
  • Prep: Project scripts are developed; data is gathered. (Team Member)
  • Produce: Actual work is in-flight (Systems)
  • Analysis: Write-up from project (Team Member)
  • Validate – Work that needed sign-off from someone (Client)
  • Closed – recently “done” items

Note that WIP can now be defined for multiple states (Prep, Produce, and Analysis); each of these states are governed by a limited number of resources; team members can only have 1 project in the Analysis state at a time, for example. Note also that the cards represent the entire project, not just a task inside a project. It’s an assembly line mentality, and allows us to quickly see where constraints are acting as a bottleneck.

With the regulated workflow removed from the original board, it let us focus on some rules for the fluid SRE work (the caveats referenced above). One of the basic decisions needed for a kanban flow is what does a card represent? For assembly lines, a unit of work could be the whole project, but for fluid software development efforts, it gets really soft.

We decided to go with a timebox method; a unit of work should take no more than a day of focused work. A card could be really small or reasonably large, but if you think a project will take more than a day, then split the work out. This has psychological advantages; it’s far better to see things getting marked as “done” than to just watch a card sit in the In Progress column for weeks.

Another rule we implemented was transferring ownership of the card in the Validate phases back to the original requester. We then started a clock; if a card sat in the Validate phase for more than 7 days, we flipped the ownership back to the team member, and closed the card.

So far, the team seems to be working well with the two new improvements; after 30 days, we should have enough data to see where we can continue to improve the flow.

For the ones who get it done…

Excited to announce that I’m starting a new position as the Senior Manager of Site Reliability Engineering for Grainger. It’s a fantastic opportunity; Grainger is nearly 100 years old, and yet their technology stack is very progressive.

I’m excited to contribute and yet still learn new things every day.

Trello Power-Ups and Automation

As I posted last time, I’ve been using Trello as a Kanban board to help with my job search. The default functionality for Trello is effective, but there are some free components you can add to minimize the time managing the workflow (so you can focus on the work itself). In Trello, these are broken up into two broad classes:

  • Power-Ups: add-ins that have been developed either by Atlassian or contributors, and
  • Automation: native functionality to Trello that are triggered by actions or dates.

Power-Ups

Adding a Power-Up to an existing board is easy; just push the menu button near the top right of the board and click on the add power-ups button. As you can see in the screenshot, I have two power-ups that I use in my job search board.

Card Age Badge – this puts a colored icon on each card that shows how old that card is. This allows me to track individual job submissions or leads and follow-up on older cards. At this point, I’m mostly using it to indicate when a job has “ghosted” me, and I no longer consider them active applications.

List Limits – an important component of kanban is WIP, and Trello does not capture that by default. This Power-Up lets you set a limit per column (and tracks the number of work items in each column). I use it as Reverse WIP measurement; I want to keep at least 15 applications in progress. List Limits will color the background of a column when you exceed the limit, so for my Applied column I set a limit of 15, and as long as the background is colored, I can focus on other things.

Automation

To access automation, click the Automation menu item next to the Power-Ups button. Because my needs are simple, I only use the Rules feature for my setup. Trello’s implementation of rules is very nice in that it creates natural language statements to show what is to be done and when. I have the following rules:

when a comment is posted to a card by me, move the card to the top of the list

when the red "Rejected" label is added to a card by me, move the card to the top of list "Dead Lead"

when the dark black "Ghost" label is added to a card by me, move the card to the top of list "Dead Lead"
The interface is very easy to set up; each rule is simply a trigger (something that happens) and an action (something that gets done). The three rules above do two things; they allow me to move a card to the top of the stack by simply adding a comment to the card (this helps me to remember to follow up on it), and to move a card to the Dead Lead list when I either get rejected or I think the posting has ghosted me (no response after 14 days).

Board Final* View

Here’s what my board looks like today; as always, there’s room for improvement, but this allows me to focus on the job of finding a job while minimizing the overhead of managing the job search.

Good luck out there! And as always, if you want to see what kinds of roles I’m interested in, check out my LinkedIn profile! Stuart Ainsworth | LinkedIn

Using Trello to Manage My Job Search #kanban #opentowork

As I’m working through the process of dealing with my layoff from Salesforce, the biggest focus is on managing the process of applying for a job. I’m casting a wide net, and I figured I should approach this process like I would approach any project; break the work down into reasonable chunks, define a state for the workflow, and work the backlog. In essence, kanban.

I’m using Trello to manage this process. Trello is a very flexible list tracking tool that can be used as a lightweight kanban tool right away (although I plan on describing additional Power-Ups and Automation in another post).

For my job search, I visualized the workflow as 5 basics steps; this may change over time, but a week in, here’s where I am:

  • Prospects: those leads graciously submitted by others (and please keep them coming)
  • Applied: Jobs that I’ve actively applied for. More on this card later.
  • Screen: I’ve heard back from a recruiter, and a conversation is pending (or occurred).
  • Tech Screen\Follow up: Usually the second or third contact.
  • Dead Lead: Investigation didn’t pan out, not a good fit, or I was rejected.

I work the board. In the afternoons or evenings while watching TV, I do my job searches and save prospective opportunities in an email, or bookmark, or whatever. Evey morning, I start pulling those opportunities, double-checking them to see if they’re still interesting, and then go through the mechanics of applying (and BTW, some job sites are PAINFUL to use when applying).

The job opportunity card is simple right now; I don’t want to overcomplicate this, and the goal is to provide minimal information to track what I’ve applied for and provide context when scheduling follow-up calls. I use the following notations:

  • Card Title: Company name followed by Job Title. If I apply to more than 1 position with the company, I create a new card. A card represents a single job.
  • Description: a link to the job posting. If I have any other relevant information (like a reference, etc), I’ll add that to the description as well.
  • Comments: brief notes describing what I did when
  • Labels: Right now I’m using labels to manage Dead Leads, and have it restricted to three:
    • Not a fit: something that I think is not for me; I may revisit later
    • Job filled: the search engines are outdated; the job may not be available by the time I apply
    • Rejected: the company didn’t like me 🙂

So far, it’s been helpful. I’ve only screwed up once in the last week and applied to the same job twice, but that was my fault (I didn’t check the list).

Good luck out there! If you’re hiring, or have a job lead for me, please feel free to reach out to me at Twitter: @codegumbo or on LinkedIn: Stuart Ainsworth