Monday at LISA

When Matt Simmons recruited me to join the Blog Team for LISA10, I a young sysadmin who had recently outgrown the small department where I worked. I had scattershot experience and no real sense of connection to the community. That week in San Jose was a firehose of knowledge and networking. There was more content than I could possibly attend in a six-day span.

What I love about LISA is that as my career progresses, the content remains relevant. Sure, there are some repeats (and for good reason), but every year I find something new to fit where I am and where I want to be. This year, I'm a newly-minted manager lookig to make a positive impact on my team and my company. As we grow, we're focusing on maintaining and improving our culture, so the Culture track is particularly appealing to me.

Scott Cromar's "Survival Guide for the New Manager" training on Monday morning was a great way for me to start the week. Cromar wrote the book on moving from technical contributor to manager, and had a lot of useful insight to offer. He started out with a list of various new manager pitfalls an how to avoid them. Perhaps the most enlightening was the discussion of the Peter Principle. It's a topic I'm familiar with, both theoretically and by observation, but I had never considered the fact that it assumes people don't improve. People who are incompentent don't have to remain that way forever, and it's one of the main jobs of a manager to help people improve.

Scott described the characteristics of a good leadaer, and I was pleased to see that I could feel comfortable applying all of them to myself. He then outlined the 90-day plan for a new manager and how the goals and requirements might differ depending on the team. Teams already viewed as succeessful are much different than teams that are viewed as dysfunctional or teams that are brand new.

Just as there are different types of teams, there are different types of team members. "Key players" hold the team together and provide a credibility boost inside and outside the team. Despite the instinctual reaction to hold on to them tightly, it's often in the best interests of the team and the company to help them find new growth opportunities. On the other end of the spectrum, there are people who are toxic to the team and need to be given a swift departure.

While I thankfully don't have any team members that need to be jettisoned for the good of the company, the topic came up in chat as I was writing this post. Many of the things I learned in "Survival Guide for the New Manager" were germane to the discussion about how to alter the behavior patterns of employees who leave the team hanging. It's always nice to be able to apply new knowledge right away.

The other lesson that stood out from this training was to be aware of my boss's (and my own) "untouchables". Cromar used his example of not wanting to hear people come in and vent unless they prefaced it with a "Scott, I just need to vent to someone about this." This is what makes it clear to him that it's a healthy venting of frustration and not an unconstructive change to the team's attitude. I'm not sure sure what my untouchables are, but that's a matter I'll be giving a lot of consideration to.

In the afternoon, I indulged one of my other interests: being a rebel and actually liking systemd. systemd has certainly gained a broader (if sometimes reluctant) acceptance since it first debuted in 2011. As more Linux distributions, particularly enterprise-focused distributions, adopt it, it becomes more important for the modern sysadmin to understand it. Alison Chaiken's "systemd, the Next-Generation Linux System Manager" provided a great introduction.

I was pleasantly surprised at how much I already knew about systemd, despite not having done much with it apart from occasionally stopping and starting services. This isn't to say I learned nothing, I definitely learned about features I never knew about, particularly around the journal. The examples used during the training were great because they were simple, but focused on tasks sysadmins might have to do in the real world.