Leadership: People & Process

It's About the People, Stupid

It’s easy to lose sight of the people element.

Recently I attended a training led by Bill Joy who reminded us again how important it is to coach the person not the problem. This is a common trap that is remarkably difficult to avoid even after years of practice, particularly if your career path as been from being an engineering individual contributor, you're basically predisposed to try to solve problems when they are presented since that is, for intents and purposes, your job. It's who you are!

Instead of focusing on the problem, it's much more important to focus on the person. What's going on with them? Often organic conversation, some questions based on the person in front of you, will clarify the real issue and help lead to the right solution. Generally the person in front of you is a valuable and capable human being who could figure it out, they just need something from you as their manager.

There are a variety of things that folks need from you that they can't handle on their own, of course. Sometimes it's as simple as permission, other times it's just a reasonableness check or even some economical rubber ducking. Sometimes they've been dealing with external (to the team) factors that require mitigation assistance.

Speaking of external issues, one of the more common problem categories that arise frequently are around challenges to focus. Challenges to focus are often external. It could be stakeholders looking for updates, a program manager trying to get the 'real timeline' on a project, or a support question that someone is just hoping an engineer can simply answer (and why not, they built it, right?).

The Value of Process

External challenges to focus typically happen because of a lack of formalized process for your external stakeholders.

If you don't have an intake process and people who aren't your engineers to manage that flow, you're doing it wrong. Whether it's support questions in Slack or folks in the business who believe their ask is so incredibly important (and probably technical) that it must go immediately to an engineer.

It may not feel like it, but one of the best things you can do for your people is to develop a formal process. This will cut down on distraction, context switching, and general shenanigans involved when people are tapped on the shoulder repeatedly throughout the day by inconsiderate folks (who are admittedly just trying to do their jobs as well) who think whatever they are doing is actually the most important thing to the business right now.

I'm reminded of a blog post by Randall Munroe of XKCD fame from about ten years ago (wow) - Distraction Affliction Correction Extension. In this article Randall writes about introducing process to help reduce his distractions.

Recent Process Updates Helped My Team - YMMV

Here are some process things that we've done over just the last year that have helped immensely with managing external distractions:

• Stood up a Service Desk workflow
• Built dedicated support channels
• Created Office Hours

The sort of distractions we needed to reduce were around support and feature requests as well as status updates. Both of these things were coming to the team through a variety of communication channels practically all of the time. It was leading to a sense of burnout and a feel of getting nothing done.

The first step was to try to characterize just how bad things had gotten. We built an 'Unplanned Interruptions' placeholder into our sprints and stuck a bunch of points on it. Every time one of these requests came in, the team had to document it with a new ticket and siphon points from the placeholder to the new ticket. The results were pretty clear after only a few sprints. The team was often spending nearly double their velocity trying to manage these request.

Implementation of new process wasn't easy, it took a lot of effort and upwards of a year to roll out. Some of the effort was training both within the team and without, some of the effort was around documentation, and some of the effort went to a deep focus on our retros. The results are that my engineers feel like they have more control over their time. They don't complain about constant interruptions (as much), and because of the process we can actually see how much less of their time is being eaten up because we have the data to back it all up.

What's the point of this post?

That's a fantastic question. This post does feel like it's done a bit of meandering.

I started this post because I wanted to talk a little about how to focus on the needs of the people who do the hard work of making things happen. As a leader of people it's critical that you realize how important the people are as it's 100% of the role is people.

That focus on the person and not the problem is what reminded me of the collaboration with the team that resulted in new process to make everyone's life feel better.

Was it only the process? Of course not, I also hired some folks, and we've done a variety of other things to help make our lives better.
Ultimately, though, we did something and that's often a defining difference between success and complaining. We could have carried on, lamenting the issues. Instead of building a new intake process, the move could have simply been to say, "Suck it up, everyone is underwater, it's hard all around. This is life."

I much prefer having done something to make the people's lives easier, however.