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.
Sometimes you just happen to be in the right place at the right time. I crashed Frank & Andy’s podcast, and had a lot of fun talking about Big Tech and layoffs and empathy and beards…. Click on the image below to get the podcast audio, or click here for the video stream on LinkedIn.
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:
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.
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).
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
19 years, 3 months.
My last day at Jack Henry and Associates will be February 4, 2022. I am extremely grateful for the opportunities I’ve had. Jack Henry has been very supportive of working from home for the last 14 years, and they’ve fostered me as a learning-center manager. The work-life balance and benefits were extremely tough to beat over the last 19 years. I’ve built and supported some really cool things in the managed security services space. I’ve grown up here.
Here’s a selfie (now) next to a photo of me from 2002 (when I joined JHA).
I’m a dinosaur by IT career standards; honestly, I didn’t think I’d write this blog post anytime soon. However, COVID-19 has changed the way we work, and more companies are creating remote leadership positions.
On February 7th, 2022, I’ll start a new position at Salesforce, working as a Senior Manager of Systems Engineering, supporting the CI/CD infrastructure for Tableau. I’m ecstatic about the opportunity, but I will greatly miss all of my colleagues from JHA (Gladiator), particularly my direct reports.
I still plan on blogging intermittently, and I’ll be active and involved in the community (in fact Salesforce actively encourages volunteerism), so I’m not going anywhere. But yet, I’m moving up, and am looking forward to figuring out the next few challenges in my career.
Let’s build something awesome.
I’ve been struggling recently with feelings of burnout. I’m sure many of you are as well. The world is a scary place right now, and it’s been tough to find purpose and meaning in a my job (which was often the refuge for a scary world).
I don’t have any real advice. I don’t really know what to do, but I’m not giving up hope. The only piece of advice that has ever worked for me is to talk about the issues, and try to get one thing accomplished each day. So today? I’m writing a short blog, which is something I haven’t done for a while. After that, I’m canceling most of my meetings, and going to write some code.
Today is going to be a good day.
…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.
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.
As many of you know, I’ve been slowly changing focus from database administration to DevOps, management, and service operations. Over the last few years, I’ve been heavily involved with migrating our datacenter to a private cloud infrastructure, and focusing on methods to improve the overall reliability and scalability of my company’s service deliverables. I’ve been a bit of an evangelist for organizational changes, and it’s finally official.
On October 1, my job title and responsibilities will officially change from Manager of Database Administration to Senior Manager, System and Network Administration. I think that title’s a bit funny, because I won’t be managing system or networks; our infrastructure is managed by another team, and my team is responsible for applying principles of Site Reliability Engineering to operating our complex business services. Unofficially, we’re calling ourselves Service Reliability Engineering in order to remind ourselves (and others) of our foci:
The title change itself is a minor issue, but it’s an important distinction to me. It represents a significant shift in my career path. Although I’ve been acting as the IT Operations manager for the last two years, it’s always felt a little odd because I was still known as the DBA manager. With the move to the cloud, most of our administration (like backups, DR, and maintenance) are handled by another group, and we’re responsible for making sure that the applications (all 84 of them) perform appropriately. We’re not coders, but we need to be able to identify coding issues. We’re not network or sys admins, but we need to know how systems work, and be able to propose solutions to scalability issues. We’re not DBA’s, but we need to be able to express data requirements to the new DBA team. In short, we’re an integration point for a loosely coupled set of applications.
I plan to blog more on Service Reliability Engineering in the future, but for now, I’m excited about what’s happening.
Very excited to be presenting an Ignite talk at #DevOpsDays #Nashville (October 17-18, 2017): Tactical Advice For Strategic Change In A Brownfield
It’s only a 5 minute presentation (20 slides; slides change every 15 seconds), but I’m stoked about it. It’s going to be my first DevOps talk that has absolutely nothing to do with SQL Server; finally starting to go in a new direction, and focus on Culture, Lean, and Sharing. It’s a great little conference, and I’m grateful to go back for my second year (this time as a speaker).
Now, I just got to develop the slide deck J
I used to present a session called Managing a Technical Team: Lessons Learned (Alexa: Remind me to update and submit this session again); the point of it was to reflect on some of the lessons I learned early in my career transitioning from a database developer into a management position. I was trying to give a view from the trenches, mostly to help other folks get a perspective on what it’s like to fumble through a career change. Management, like development, is a process of learning and continuous improvement; the difference is that other people have some expectation that you know what you’re doing (and often, you don’t). Inevitably, I’d get asked some version of this question:
I used to have a quasi-canned answer, something along the lines of “at some point you must choose your path; management is about people, not technology”. I still kind of believe that, but recent experiences in my own career path have caused me to reconsider giving an answer. Instead, I’ve started asking the questions:
The truth is, I don’t know what’s best for you, but I trust that you do (that satisfies my libertarian soul). Everybody’s got different experiences, different beliefs, different goals, and different circumstances. When you bundle those things together, it makes for a very complex decision tree; even a simple question about how you want to conduct your day-to-day affairs becomes overwhelming for someone sitting on the outside to answer. That being said, I still want to help, so I thought that I would share some of my decision factors using the four buckets above.
Here’s some of experiences that have gotten me to this point:
These are some of the core beliefs I have about management and technology; these will be tough to change.
Goals are tough for me, because I believe they should be a mixture of both long-term and immediate. As such, they change more often than you would think (at least for me).
Everybody’s got different external factors that influence their decisions; managers are no different. For me, the following things are true:
For me, it means that I don’t want to be a single-technology manager; I want to figure out how to make technology work for business, even if it’s a technology that I’m unfamiliar with. The logistics of scale means that I can’t be the single source of authority when it comes to implementing technical solutions. I scale out by relying on my team to be the experts, and I want to keep building teams that can handle lots of different problems.
More to come later.