Just because you’re a manager doesn’t mean you stop being an SRE

Automate Everything: this is the tenet of SRE the world over. Any SRE worth their salt looks at their list of daily tasks and thinks about automating them away. Even if it takes an extra hour just to automate a thirty-minute task, once automated you don’t have to spend those thirty minutes on it ever again. As a “wise” manager once said to me: “If you ever want something automated, you give it to the laziest engineer on the team. They will automate that task after the second time doing it, because they don’t want to do it in the first place.”

As a manager of an SRE team, part of my role is to ensure that automation of our workload is something the entire team do. While this is generally an easy task, the old adage of ‘Lead by example’ applies here as well. But if I am “busy” doing all the manager work (quarterly reviews, reports, project managing, etc), it leaves very little time to do proper engineering work. How can I lead by example and automate boring tasks for my team?

By automating management tasks, of course.

Just because you stop being an engineer who does the fun stuff, does not mean you have to stop looking at your list of work and seeing what can be automated.

The only question was what to automate? It had to be something that benefited myself (obviously), a task that I needed done regularly but did not like doing manually. But it also had to be something that benefited the team and in the same way showed them that no task could not be automated.

The Problem

As luck would have it there were two options that presented themselves quickly after a minimal effort of searching: time-sheets and incidents. I ended up automating both, but for now I will focus on the time-sheet aspect.

Time-sheets have always had a paradoxical place in my heart, even back when I was starting out in the industry. As far as I could see they served a certain purpose in allowing people to track how much time they were spending on projects and tasks, which in turn could be data used by their manager to request more resources or push back on timelines that would not be met (insert sarcastic laugh here). The problem with time-sheets is when they are used purely to show that a company is doing time-sheets, when you are told to log no more than forty hours a week…but keep working more than forty hours a week. This is when most people start to dislike the end of week task of filling in their time-sheets. They no longer reflect reality and instead are just a fabrication. A box ticking exercise that becomes a pain to do each week.

Our company, like many others, brought in the requirement to fill in time-sheets using an online time tracking solution roughly two and a half years ago. It was immediately met with resistance from people across the organisation. The main reason given sounding very similar to the second point I made in the paragraph above. These time-sheets were seen as a task that had to be done but bore no real benefit and did not show how truly busy we were. For my team it was slightly worse because we were told from up on high that you had to fill them in. Now, I am sure all teams were told they ‘had to’ fill in their time-sheets, but for some reason it was only the SRE ones that ever seemed to get flagged when they were missing a few hours here or there. It was almost more beneficial to not fill in a single minute, as that way you did not appear on the report. My team, however, did not moan to me about it. They are adults after all. But they raised up concerns about the entire affair.

So, I automated the entire thing.

The Solution

All twenty people under me were told they did not have to fill in time-sheets or use the tracking software. It was an easy task from my perspective. All I had to do was use some API calls from our ticketing system which the team tracked their work in and input the information using the APIs of the time tracking solution. Moreover, the script checked against our holiday tracking solution to input time off and public holidays. A bit of Python here, a little Lambda there, and suddenly the SRE and NOC teams were having their time-sheets automatically filled in each Friday.

This was not an entirely free transaction for the team, after all if you are automating a task there is meant to be a benefit to the person who automates it. Sure, removing the grumblings about time-sheets is a benefit but I still am a manager and that means I need to know how much work certain projects are consuming each month and who is on them. In order to sell the idea of automating time-sheets to the team, the team had to agree to modify their workflow slightly.

Up until the introduction of the time-sheets, everyone on the team had tracked their work via tickets. The tickets showed how long a task would take, most of the time these estimates were spot on and a few times they had to be adjusted if something finished later or sooner than intended. While designing the automation part of the time-sheets I requested that each ticket now included a project code in the title of the task. A small price to pay for people to not have to fill in time-sheets and one everybody paid willingly.

The Results

Finance were happy as they didn’t have to chase SRE down for those missing three minutes that were not logged last month. My team were happy as they don’t have to do a task that they easily forget most weeks without a gentle reminder (at this stage most of them have even forgotten the name of the time tracking solution they are meant to log into). I’m happy because I don’t have to be ‘that manager’ who sends out emails and instant messages to the team about filling in their time-sheets. I’ve bigger, more important, things to be worrying about without being a pencil pusher.

What benefit did this bring me? A huge one, as it happened. By generating the time-sheets, I was able to see which projects were worked on each week and who worked on them. More importantly I could see which ones were taking more time than we’d estimated, allowing me to do proper resource management and feed back up the ladder that we had to adjust some timelines. It also let me go with cap-in-hand when looking for extra hires, backed up with sweet, sweet, metrics. Moreover we became the one team in the company to never be asked about their time-sheets again. There was the initial questions asked about whether or not the team really were working the additional hours captured, to which I said yes and explained how I wouldn’t be adjusting the time-sheets to not reflect reality as it was all automated.

It’s amazing what people will accept when once you explain a simple concept in confusing terms. Not that I was lying, exactly, but the time-sheets were the most accurate the company had ever gotten, I was not going to start pruning hours off the sheets just so we didn’t look like we were doing the additional work we really were doing.

Cost Savings

Of course this little pet project had hidden benefits for the company. Automating the time-sheets saved the company money. Most, if not all, of the team spent at least thirty minutes a week filling in their sheets. It did not matter if they did them daily or all on Friday before running out the door. Thirty minutes times twenty engineers, that is a lot of money spent by a company to show where the money is being spent by the company. If that is instantly reduced down to a few seconds with no additional overhead you are making savings that the company never even knew they needed to make.

Which goes to show that you can still automate stuff even when you’re managing a team. The real trick is to find things that matter for both manager and team, otherwise you’re just helping perpetuate the myth that managers don’t really do any work.

SRE Manager by day, parenting podcaster by night, author of a comedy-fantasy series called ‘Filthy Henry’ by twilight — Trust me, I always lie.