If you’ve been reading this series for long, you may have noticed an important omission. I’ve spent all of these essays talking about attributes Competent people have. Things like sharing, persisting, team-building, that are “nice and all, but what does that have to do with competence?” Through all of this, where has the traditional sense of the term gone? If I was devoted to an appropriate story arc, this would be the last essay. But I’ve got a couple of folks to talk about, and I feel like writing about them now. They’re the textbook “competent” people.
I won’t bury the lede. In addition to all of these other important qualities, Competent people are also competent.
No one has much trouble spotting competence. Or so you might think. Hopefully we’d all agree it means something like “being really good at a thing.” Or a little beyond that, incorporating at least a bit of resilience. “They are very competent” we might say about someone who handles a big mess when others fail. People most notably show competence when things are falling apart. I also hear “competence” said about “just getting the thing done.” When something (usually unpleasant) is done and dusted, “competence” is the compliment.
I’ve been fortunate to work with any number of competent people over the years. The beauty of competent is that it’s within most of our grasp. “Our game to lose” is one way of putting it. Not being competent at something is fully our choice. Learn a thing thoroughly and you’ll probably become responsible for that thing. That everyone isn’t competent is a little baffling to me.
So I have a long list of little-c competent people to write about. But it’s not at all hard to choose. In each of these articles I’ve picked out someone who truly embodies the subject attribute. Even among my mental list of shining competent people, these two stand out as real stars. I think you’ll like them.
I worked first with Jeanne. When we worked for Susan, Jeanne and I were paired up because we had complementary skills. Jeanne isn’t an auditor or accountant, but she’s a wizard at knowing every penny and contract term of a purchase. She, as the kids probably no longer say, “has the receipts.” (Actual ones) It does not pay for a vendor to be squirrely with Jeanne around. They will not succeed. Jeanne is squirrel-proof.
I recall an example when a supplier of some sort of device was on a call and mentioned a price, something like “We can send those at $756.43 each.” Jeanne, without looking anything up or pausing even slightly, said “the agreement is for $756.23.” In a tone that made it sound as if they were trying to pull a fast one. They were off-balance for the rest of the negotiation (which went just as Jeanne intended).
Government contracting is a deep and difficult discipline. IT contracting particularly so. To be really good at it you need to know books of arcane rules. Years of experience only opens the potential for competence. Some people can go their whole careers doing this without becoming good at it. Jeanne has all of that ready and waiting. She’s the one you want on your side for any type of IT purchasing situation.
We had a project together in which a software company was auditing our organization. I handled most of the coordination, tracking down people and managing the audit logistics. Jeanne made sense of vast numbers of licenses. Dozens of packages purchased over decades in our large organization. Vastly different contract terms for the same product over time. Jeane matched what we had with the vendor documentation.
Don’t underestimate that complexity. On these lists, even the names of the software often didn’t match. What it was called when we bought it probably changed three times over the years. Features we bought got shifted into different forms of license and back out again, making it almost impossible to know what we were entitled to. People who bought the software were long gone. Even th way these things were bought varied across “any way they might possibly have been bought.” Purchase orders, purchasing cards, reimbursement, attached to hardware, directly, from resellers who might or might not still exist, from suppliers bought by this company after we got software from them. You name it and someone had probably bought it that way. And then, after buying something, many of them left. Jeanne’s ability to match patterns, and figure out a picture from a point or two of detail made this process a notch above “impossible.” She lined ‘em up and knocked them down. Identifying and quantifying.
That kind of work is exactly what anyone would call “competent.” Jeanne knows her stuff. It is not necessary to be “Jeanne-competent” in order to be Competent (thank goodness) but she’s a great model.
My second example today is Jen. If you hear the words “business analyst” and picture a rescue dog digging you out of an avalanche, or a person hanging on a rope from a helicopter and pulling you to safety when you’re drowning, only in an office sort of context…you may have worked with someone like Jen.
A minimally-capable “BA” will understand enough of how their area of the “business” works to be able to describe it to the technical people who then build what they say. A better BA can write requirements, having some sense of what’s possible technically-speaking. But the kind of business analyst Jen is, is a programmer herself. This kind of person knows not just the business, not just the technology, but also the people. She also knows the data better than anyone else.
I’ve had the privilege of working with Jen on a few different projects now. She’s the go-to if I need to understand what’s going on under the hood in her area of expertise (or, honestly, even adjacent areas also in her head). She will know, or will know how to find out what’s needed. I don’t recall a failure on that score several years into arcane off-the-cuff questions. In this large and critical business area, if Jen doesn’t know it, then both 1. No one does, and 2. It’s probably not worth knowing.
I don’t recall if it was the first project I worked on with her, but Jen and I were in a group tasked with defining request processes in a new system. We had almost nothing salvageable to work with from an old system. Just nonsense. We had tight deadlines and complex analysis to do. Long lists of requirements, some apparently conflicting. When we asked the “business functional people” we usually got not much helpful. I recall Jen saving our bacon several times just by knowing how the business worked, or needed to work. It’s as if Jen has some massive RACI chart in her head. “It can’t go to X because they can’t sign off, it has to go to Y and that has to be done before the Z for each department. And only this group of 25 people should make this request, not everyone.” The amount of detail in her mind is staggering.
One thing I most enjoy about working with competent people is the pleasure they take in a job well-done. It’s possible to have long conversations about arcane things with them. You can see and hear the energy when they can fit together cogs only they see. The level of “rubber meets road” in an organization is directly proportional to how many competent people are in the mix.
This is where people like Jeanne and Jen are powerhouses. They don’t respect oversimplification, because details almost always matter. But they can lift the work of understanding and managing that detail off of their colleagues and executives. Jeanne and Jen know that dragging others down into the depths of “how it all works” isn’t effective or useful. Instead, they just handle it, and present what the people around them need to know.
A side note if you’re reading to become a better manager: competent people make things look easy. Paradoxically, the harder something is, likely the more of it they’re handling in order to present only what people need to know. Don’t make the mistake of believing the work is easy. Managers should dig enough into the details to respect how deep it goes.
When you are interested, these fireballs are a joy to know. From just one such person you can get ALL of the information you need on a subject. They’ll help you figure out your projects. If you need a thirteen-page Visio diagram of a process flow (<-actual example, thank you Jeanne) they can probably make one. Need a report from a handful of tables in a massive ERP to show something you can only vaguely describe? (again, real. Thank’s Jen!) they’re the go-to.
I’m spending a lot of time talking about skills, attributes, and factors that make a person big-C competent. But those are the supporting cast. If we start at the very beginning (a very good place to start) the foundation is competence. Being good at something. And that’s a skill most of us could achieve if we put in the work. If you read this series and think “well, it’s nice to know these people exist, but I couldn’t be one of them,” just start with competence. Get good at something. Know when you’ve become the go-to. Then build from there.