I started a new job about a month ago, so I am right on schedule for my typical visit from the Imposter Syndrome fairy. It’s as regular as clockwork: suddenly immersed in a place where everyone in the building has infinitely more knowledge than I—everything from the business domain to work procedures to where to find the bloody conference rooms¹—so I have to fight the feelings that I’ve finally taken on too much until I start to get my feet beneath me on something that feels like solid ground.²

It’s simultaneously exhilarating and exhausting.

It was in the midst of this that I got a much needed ego boost in the form of a chance to directly compare how I’m doing against the best frame of reference I can think of: my own ideals.

During a discussion of how things were going at a friend’s work it was observed that a mutual friend—we’ll call him Steve—was struggling to keep his team motivated, on task, and engaged with solving typical work problems. It was clearly frustrating for Steve and having a terrible impact on his team’s productivity and morale. When I asked for specifics, the details shed much light on the problem.

Steve is attempting to streamline the processes by which his department performs work. Some of it is high level and conceptual, but much of it is very basic stuff: things like the layout of the office and the physical placement of the things that are needed to get the job done. Steve astutely observed that significant time was being lost to long trips for frequently used items, poor storage requiring lengthy searches for things that are retrieved often, and teammates getting in each others’ way on a regular basis. His goal became clear: restructure the physical workspace.

This was where things took a negative turn. Steve sat the team down, told them that the layout needed to change, and solicited their feedback as to the reorganization. Everywhere that he disagreed with their assessment, he took the time to explain why their idea would not work and why his concept needs to be followed. Once the plan was explained sufficiently, he turned it over to the team and helped them execute.

If you have experience leading teams, I suspect that you already see many of the same areas for improvement that I did. Rather than give advice, I shared my most recent experience with a similar issue.

After observing my teammates working for a while, it became obvious to me that their workflow had a number of areas that could stand to be improved, and I had distinct ideas as to how they could achieve that improvement. With that, I set up a meeting with the team.

During the meeting, I expressed the pain points that I had observed, and we discussed whether or not they agreed. On most of the major points we were all in agreement, although I was surprised to find that two areas that appeared to me as frustrating churn were actually perceived by my team as an almost luxurious break in what often became a monotonous task.

Interesting. We noted those areas that we agreed needed change and simply ignored those that weren’t perceived as pain.

Next, we discussed what a solution to the problems should look like—what traits it should have—in this case, it should solve the pain points, be simple enough to implement initially that we won’t feel bad about rolling back if we hate it, and that we can show fairly empirically the positive or negative effect it had. With the boundaries in mind, we started casting about for solutions.

For most of the remaining problems, the team quickly arrived at solutions that were either comparable to mine, or different but stood just as good a chance of succeeding in my opinion. For the remainder, we discussed some options with which I had some misgivings (which I expressed as a part of the dialog we were having). The team disagreed with my reservations, and decided to try their concept. We discussed how to implement and test all of the plans, and immediately put them to work.

Let’s examine the difference between these two methods for a moment:

1. Steve observed problems
2. Steve developed plans to solve the problems
3. Steve explained the plans to the team
4. The team executed Steve’s plans

Compare that to:

1. I observed problems
2. I described the problems as I understood them to the team
3. We discussed the merits of the problems
4. We discussed the requirements that define viable solutions
5. We developed plans to solve the problems
6. The team executed our plans

It should come as no surprise that Steve’s experience was not great; the team did a lackluster job of implementing plans they didn’t agree with to solve problems they didn’t agree they had. They complained regularly about the changes, and some griped publicly about how Steve doesn’t remember how to do their day-to-day—from their perspective, he’s out of touch and leading them poorly as a result.

All of this in response to Steve actively trying to improve the work lives of his team!

Comparatively, my teammates had a much more positive experience. Several of the ideas that we came up with did not pan out³, but the team quickly discussed the flaws and we were able to find a solution quickly. Their feeling of engagement was high and feedback was very positive. The term “empowered” was used to describe the situation more than once. Equally importantly, the team as a whole had an opportunity to learn a bit more about problem-solving in the process domain which will benefit all of us greatly in future decisions.

Finding the moral of the story involves looking at the purpose of Steve’s approach and mine. In both cases, the overt purpose is to solve the team’s problems and to make their jobs better and more productive…but the applied purpose—the purpose that was conveyed to the team—was very different. Steve’s applied purpose was to have the team solve problems he saw his way. My applied purpose was solicit from the team the best ways that I could help to solve their problems.

And that was the source of the ego-boost that I got from this narrative; it wasn’t “look how superior I am to Steve.” No, my pleasure was derived from recognizing that I had practiced servant-leadership without thinking about it. For a decade I have been struggling with setting aside my own ego and my own agenda in favor of trying to be an empathetic leader, and in a particularly challenging time I was able to do just that without backsliding when it mattered most.

And also, look how much better than Steve I am.

If you, like me, struggle with leading rather than managing, make this the template for your next problem solving meeting:

Try it, see what happens.

 

---

¹ Seriously, what is it with companies and conference rooms. They all choose cutesy names that make a ton of sense to people around when the names were chosen but do nothing to help folks find them. It would appear that as the number of rooms increases, so too does the distance between the names chosen and a meaningful attachment to the room itself. Oh, you called a perfectly medium-sized conference room “The Big House”? I see you, too, are a fan of prisons and people being lost in your building. (back)

² Recognizing a pattern is the first step to taking away its power; if Lex Luthor ever figured out that Clark Kent got the flu around Kryptonite all the time, Superman would be screwed. Likewise, your if you suffer from Impostor Syndrome at each new job, remind yourself that this is common (and believe me, it is) and that it will pass. Like a kidney stone. Painfully and with a little *plink* at the end. (back)

³ Some of the ideas that I thought had the greatest chance of succeeding were among those that failed gloriously. Humbling. Nothing like a tangible reminder that I’m very imperfect. Not that I’m imperfect, because I’m not!⁴ (back)

⁴ Lessons in humility have a notoriously short shelf-life for me. That’s just part of being awesome. (back)