Have you tried rebooting?

Sally, Doug, "Aristotle"

If you’re just starting with this series, I suggest reading from the beginning. It will make more sense.

So there I was, basically a kid, supervising older people, some of whom had been my co-worker peers until I was promoted. Recipe for awesomeness. I’m going to tell you about just a few folks from that team. This is the point where I started learning things about how to identify competence, and how to hire and retain those folks. I learned this by screwing it up quite a lot, but also by learning from the best and having help when I screwed up (see previous article). I had more lessons at first about how not to do it, and little by little, gained a few insights into managing Competence correctly. This article focuses a bit more on creating the environment than on recognizing Competence. In those early years it was more “welp, that wasn’t it” than “nailed it.”

I also want to give a caveat. Over the fourteen years I was in that job, I supervised a whole lot of folks. Not even just traditional IT staff. With only a couple of exceptions I was incredibly fortunate to work with and proud of each and every one of them. When I considered who could illustrate best what I want to say, three people came to the surface for me, and that means some others who worked as hard and have talents just as worthy aren’t coming out. This isn’t an “introduce you to all of the awesome people I’ve ever known” project (though I can guess that’s how it seems) it’s a set of articles conveying specific lessons I’ve learned and my conclusions on the topic of Competence. So here I have to make some hard choices about who can best illustrate those points.

Covering this span of time and incredible amount I learned about how to build a good working environment for Competence, I need more than one person to illustrate with, but I’ll limit it to just three right now. Sally, Doug, and “Aristotle” (not their real name).

Sally

Our first challenge as a fledgling IT department was to migrate from a mainframe-based development (fundraising) system written in-house (as all such things once were) to a more modern almost-a-CRM Oracle-based system that we would maintain ourselves, called “Team Approach.” It was written by some public television affiliates, though now, decades later, it’s owned by an actual software company. UNC-TV had the largest database of any nonprofit in the state, so that wasn’t an insignificant undertaking. Even today that sort of project would be considered a “heavy lift.” I had never done a migration of that kind before, but I knew a bit of what would be needed to make it happen. Major ingredient one: “someone who knows a lot more than I do.”

I poached a brilliant programmer named Sally from UNC. She had supported the mainframe application and written a fair bit of it. Sally could walk on water if water was made of enterprise software applications.

One way you can think of IT staff is in two buckets. You’ve surely met people who are experts at a thing, but also deeply attached to that thing. They are often “if you have a hammer every problem is a nail” kind of folks. People threatened by change. You may also have met people who can handle change and don’t get too attached. They can be just as expert, but don’t feel a need to be indispensable and are just as happy to do new things if the new things are better. People who get excited about doing things better.

There are all sorts of flavors of those two personalities. Some good, some less helpful. But in IT staff you always want the second bucket. Every time. And you have to watch out because a lot of folks hit a wall in an IT career and switch from the second to the first bucket. Suddenly your flexible, curious, “let’s do it!” person can become your “why do we have to change? this works fine” (when it doesn’t) person. I’ll touch on that in another article.

Sally was the second kind of person. In a big way. She had every reason to be attached to the mainframe system she helped build. She was entirely expert in it, and got respect and joy from supporting it. But instead of entrenching, trying to fail a project to keep the system that made her Queen of All Development (work in IT long enough and you will meet that person), instead, she dove in flawlessly to owning the conversion project.

Like all Competent people, she knew that if she could be expert in one thing, she could be expert in its replacement. She would be the best possible person to do the project even though it meant changing platforms entirely. No part of the new system would be like the old one. She was excited by the possibilities, and because she was expert in the old system and knew the development data and processes better than anyone, she could do not just the technical transition, she could also make sure the new system would be used well. She would exploit every feature and drive the developers to do more for us.

Sally took that project and ran with it. She also made it possible for a twenty-something ignoramus to be her supervisor, which could not have been either fun or particularly flattering to her. This is the sort of thing I talk about with the truly Competent. Sally knew what she loved to do, was brilliant at it, and didn’t care to leave her niche. I dare say that if she’d applied for the IT Director position, she could have gotten it. She had decades more experience, and had deep respect from all levels of the organization. But that wasn’t what she wanted, and she had the wisdom to know it. She had what she wanted. If working for someone younger than her own kids is what it would take, she was obviously willing.

One thing I did essentially correctly from the get-go was to leave Sally in charge of her work. I hired someone perfect for the job, and let her do it. I had never been a programmer, and didn’t try to teach her her business. My place was to provide resources or support when asked and stand back otherwise.

Many of the things I suggest about cultivating and retaining Competent people are no-brainer-sounding things that most employees prefer. Most people do not prefer to be micromanaged, they prefer to be trusted. Most people prefer a boss who will give them trust and autonomy, and show up when they need something. The trick is knowing just how much latitude you have when your employee is Competent. (spoiler: all of the latitude)

When you have marginal employees, the sort who really need supervision and mentoring and support from a manager, that’s one kind of effort. When you have Competent people, that’s a different sort of effort entirely. But it’s like any situation with MVP employees, these are the “80% of the work” people in 80/20. These are the ones who have options. These are the ones you have to get management right with. But unlike star athletes, Competent people are forgiving, and will “manage up” to improve you because it’s just something they do to improve the environment around them. They will create the environment they need for the whole team to succeed if it’s at all possible.

Sally managed up. Her wealth of experience informed my work. She was never unclear about what was needed, and didn’t hesitate to ask her young boss to step in if there was something I could usefully do. Or to ask me not to (which was always harder for me) if my help was not helpful.

But if you mess up enough, even the most forgiving and capable Competent people will walk out the door. They can be lost by management error. Which is what eventually happened with Sally.

The Development conversion went well. Sally got new systems, new processes, new ways of thinking gelled. We had the Development systems in place and running smoothly. We’d hired another excellent programmer who could handle those things. And the organization was in the thick of major industry change. I had projects entirely different that I needed brilliance to accomplish.

So I “repurposed” Sally. But Sally liked the kind of work she had been doing. She didn’t hide the ball, she explained that. I (wishfully) thought she “needed a challenge” with these new things because I’d seen how she rose to the challenge of that other big project and she seemed a little bored. But if Sally had needed that kind of challenge she would have asked for it. So ultimately, after plenty of opportunities to see my error, and undo it…she took a job with the company that made Team Approach rather than keep hacking away at a pile of unfamiliar, and to her not that interesting work.

The critical error there is something a manager can commit with any employee. “Not listening.” But it’s the stupidest error in the world with a Competent employee. With them you really don’t need to guess, they know themselves and their work far better than their managers ever could. Just listen. In that situation, we did need other projects done, but with hindsight, the best thing I could have done was ask my brilliant staff how we could accomplish them, instead of just deciding.

Sounds simple, “listen.” Harder than it sounds.

Doug

I mentioned earlier that what works managing most people are often things that also work with Competent people. Most people do not like to be micromanaged.

I did ok hiring programmers but I had much more trouble hiring and retaining a good UNIX admin. The market was challenging, but that wasn’t the issue. Because I was a UNIX admin, I couldn’t stop micromanaging. The first couple of folks I hired in that job were not stellar, but I didn’t have the skills to help them. All I could do was hover.

When you’re good at something, and you care about it, handing it over to someone who is only “ok,” even if they’re good enough to do the job is basically impossible.

In other words, I was “little-c” competent at that kind of systems administration. When I hired people with less skill I couldn’t let them do it. But nor could I help them do it better. I think the way I acted can be a differentiator between “competent” and “Big-C Competent.” If you are very good or expert at a skill, consider how easy it is for you to delegate work requiring that skill. It’s hard. Unless you have training, experience, and skills as a mentor, you’re probably going to be stuck being good at that thing, and never let go of it.

This crops up all the time. Someone changes jobs or gets new responsibilities, but their old job or old responsibilities stick to them. They add burdens. That’s how competent people work. They’re good at things, they’re known to be good at things, even when new people are hired to do the work, people like how the competent person did it and just keep going to them. Or, more likely, they just don’t stop. There can be a lot of “if I want something done right...”

It’s also an element of the “Peter Principle.” When someone rises to the point where they were outstanding at their job and then get promoted one more level and become bad, the “bad” is often lack of key management skills, including mentoring. So the shiny new manager will try to do their old familiar job rather than their hard new job. That’s what I did with my sysadmins. I wasn’t Competent. I wasn’t even competent at management. I didn’t have particularly good mentoring or teaching skills, but I was comfortable and good at operating critical UNIX systems, so I did their job instead of mine. I micromanaged. And I drove off the first couple of admins I hired.

It took hiring a UNIX admin who was much better than I ever was to make me leave it alone and do my own new job. There was not one thing I could teach this guy about that work. Enter Doug. Doug is a renaissance IT guy. He has a collection of “history of computing” artifacts (including a particularly impressive collection of operational DEC computers). He came through a telecom background as well. Computing prehistory. But he’s the definition of a bucket-two IT person. Always entirely aware of the up-and-coming. Poised to apply something new to solve an intractable problem. Could tell you the entire technical lineage of that new thing. Loves the old things. But relegates the old things to a museum and keeps them operating out of love, not in production doing work.

Really, if almost anything needed a big brain with a lot of technical knowledge applied to it, Doug was our Department go-to. As a sysadmin he was (and presumably still is) peerless.

Like Sally, Doug needed space, resources, and big goals. Everything else he handled himself. Sometimes to the point of handling the work of co-workers. But unlike me at the time, Doug had mentoring skill, and if someone wanted to learn, he wanted to teach them.

One thing I learned working with Doug about providing the right environment for Competence is the need to make sure they’re seen. Not typically in a show-offy way, but (again, like most people) Competent people want the reward of their work being seen for what it is. Doug liked to talk about his work. That was his skilled way of obtaining what he needed. In this case, he needed for the people reported to to understand what his work entailed, and how cool it was when he figured things out.

Doug liked to share the solving of difficult problems. He may have had a dim hope that we would even learn things. I’d worked with others who had the same tendencies, but it was a lightbulb for me working with Doug. Before I understood that, I couldn’t figure out why all of the talking. I’m certain there were times when Doug worked long hours, pulled out every stop in his big brain, and solved a critical problem, only to have me looking at my watch when he tried to tell me about it. Why would I need to worry about a problem that had already been solved? *sigh*

A manager should never be “well isn’t that your job? what do you want, a medal?” with any employee. But when a Competent one comes to tell you something, I’ll go back to the last lesson, LISTEN. If that’s hard, picture someone less able to solve challenges doing that job. Picture the mess this would be instead of the triumph of a problem solved. Because that’s what you’ll have if you don’t appreciate those Competent folks. You’ll have not them. I was so fortunate to have Doug when I was too inexperienced to realize that. Again, Competent folk give managers more leeway than others do when we screw up.

Aristotle

I wasn’t able to get a hold of the next person I’d like to talk about to be sure this is ok, so for now let’s call them Aristotle. If I hear from them, I’ll edit to put the real name in.

Once I got some practice, really understood to look for people motivated by mission, and started thinking about ways to find competent people who might be missed by other employers, I was fortunate to find rock-stars in the then-worsening recession. I was also lucky enough to get people who worked brilliantly as a team. Aristotle was a critical teambuilder. So let me tell you what I mean by that, and why it matters so much.

I often called my team rockstars, but in an article about competence, I need to call them what they really were. They were the folks you might not notice off on the side making everything happen. They knew their own business, and kept learning it as their business evolved. You could rely on them under any circumstances. They shared their work appropriately, asking for and giving help. They supported each other by picking up slack. They found opportunities to do more and do well. That was true of almost every member of the team. But that sort of thing doesn’t just happen. Too often managers take (or are just given, as I was) credit for a cohesive and successful team.

So think about this again. I was in my 20’s with no management experience, in a demanding environment, with sea change occurring in the industry. I had amazing support from above (see previous article) and I had amazing employees. With that background, it should be obvious I didn’t build that team culture. Think about excellent teams you know, and look at them more closely. Often the best you can say is that the manager doesn’t impede the good team culture. It’s rare that the manager actually contributes to it. Honestly, in decades of watching and learning, I’d honestly say that when a team has a bad culture it’s uniformly the fault of a manager, but when it’s good, it’s mostly a combination of other factors.

I think Aristotle was a giant “other factor” in my team. They brought an element that will seem obvious when I say it, but which flew under the radar right up close.

Aristotle’s form of Competence involved what I’m going to describe as “being there.” Aristotle always set a kind of example that made those of us around them work to be better people. They introduced me to “The Four Agreements,” mostly by living them. In the time I worked with them, Aristotle had some hard things happen outside of work, enough to affect anyone. But they brought their best self to work every day. Work was work.

With Sally and Doug I spoke of technical skills first, and I don’t want to minimize Aristotle’s. This was an excellent administrator, and could fill in where we had gaps, always willing to learn something new quickly. A “utility player.” But it’s their contribution to the team that makes me write about Aristotle here.

Aristotle is an example of how Competent people may quietly be doing more than anyone notices. In many ways they created the culture of our group. Always the first to volunteer for something. When we’d get paged in the middle of the night, the first on site to handle the problem. When those of us with big “personalities” would be ready to go off the rails, Aristotle would be the calm voice of reason, always setting the bar high for professionalism. Aristotle always knew what was going on with everyone, and could see the other side when we’d be angry or frustrated. I have no evidence for this, but I’d bet dollars to donuts that when I screwed up from vast inexperience, that Aristotle was one of a couple who would smooth things over (I know you were there too Mike.)

The lesson I learned from Aristotle was twofold. One, “listen” (running theme here) because a Competent person will make you better if you’re able to emulate them or just take their advice. The second is that superlative people like Aristotle can be incredibly difficult to “manage” in a traditional sense because they will exert themselves to never be “a bother.”

If you’re a busy manager, it can be far too easy to focus on the squeaky wheels, the big personalities, and just assume everything is fine with these quiet stars who keep it all running without complaint. I think he took pride in not showing strain. It’s a challenging nuance, but paying too much attention to someone who takes pride in not needing it can be almost as bad as paying too little. I recommend avoiding either mistake by listening. Listening to not miss quiet indications and listening to know when you’re being too much.

I still have no idea what I must have missed all of those years, how I could have been a better manager to Aristotle. I think they showed more leadership than I did.

Lessons

Three different Competent employees, three wildly different personalities, styles, and areas of expertise, but one answer. Listening to every employee is good practice. Listening to your Competent ones will always be the right answer.

These Competent folks who can handle their own business are such a blessing to have in any organization, which is why I’m writing about how to support them, and help them make the environment they need to do their best work. I don’t have all of the answers, only a few, and this “listen” one is key. Trust what they tell you. It doesn’t pay to second-guess them. Take them at their word. Hear what they say. They are saving you so much grief, it’s worth any amount of listening. Whether it’s listening because being heard makes them happy, or because they are telling you how you are screwing up managing them, or because their needs will be so quiet that you might miss them, the answer is the same.