They Know More Than I Do! (Managing an Expert Team When You Can’t Do Their Jobs)

This post began as a WordCamp US talk proposal. The core ideas are worth sharing, so I adapted it from a talk to an article. Enjoy!

Technical experts in a company know things, understand things thoroughly, in a way that someone, somewhere higher on the org chart, doesn’t. CEOs that have software engineering skills are rare. The Vice President of Engineering isn’t in the code every day, and no longer knows the minute details of the implementation. Even the principal engineer overseeing a junior’s work might not have all the details in their head.

But there’s a special frustration technical folks often have when their direct manager isn’t technical. Or doesn’t have all the right technical skills to do the IC’s job.

A few years ago, I took over a team of WordPress development experts. My job, as their manager, was to manage them.¹ I needed to get good results out of the team, evaluate their performance, hire people onto the team, guide development and testing. But I was not—and still am not—a WordPress expert.

As a leader, you’ll face situations where you are not an expert. You will not understand all the details. Perhaps, like I did, you’ll take a job because you have skills² that the company needs—but not in the team’s technical specialty. Or maybe, you’ll climb the corporate ladder high enough that you’ll oversee functions you have never worked in.

We have all seen the manager that tries to hide their ignorance of a subject. They pretend to know, give instructions, parrot catchphrases, bristle at the mere hint of correction, frantically ask ChatGPT for information about the topic, “take this offline”, slow-walk decisions—and they lose the respect of their team when they do.

I’m writing for managers of software developers. Other disciplines can adapt these practices. I want to write very specific, actionable guidance. Writing about managing software developers lets me do that. Writing generally will not.

What’s the Job of a Manager?

Before we get into the “what” and “how” of this article, let’s start with a big picture “why”.

The job of a manager is to produce results for the organization.

This means at least two things:

You need to know what results you (and your team) are responsible for.
You need to produce and deliver those results. (Note: using your team effectively (managing them) helps a lot in delivering results.³)

None of that stuff requires you to be an expert in anything you manage.

In fact, not being an expert can be a superpower—if you let it be.⁴

What Does Your Team Need?

If you’re going to get things done as a manager, using your team, it’s a good idea to give your team what they need.⁵

Your team needs:

Clear guidance
Context
Constraints and guardrails
A sounding board for their ideas / plans / designs
Support
Technical expertise (!!!)

How can you provide those things when you’re not the expert? Maybe not even an expert?⁶

In the next section, I’ll share eight specific recommendations for successfully managing a team as a non-expert. Those recommendations will include ways to provide all of the things on that list above, even though the headings won’t match one-to-one with that list.

By the way, providing your team’s needs and following these recommendations can help make them better developers, better teammates, and help them get better results, even if you are an expert.

Specific Recommendations

1. Admit When You Are Not the Expert

You’ll need to admit—to yourself, your team, your peers, your boss—that you’re not the expert. At least not compared to your team.

It’s a fact, and many of them already know. Or they’ll figure it out soon.

Proactively telling them makes it much more difficult for them to use your lack of expertise against you.

“I have a general idea of how this works, but don’t know the details well enough to give you an answer now.”
“I’m not an expert in _.”
“I’ll need to work with my team to get a useful estimate.”

If there are areas you are an expert in, it’s also okay to say so. At WP Engine, although I was decidedly not an expert in WordPress, I brought some deep expertise in CI/CD systems. I would tell my team I relied on them for knowledge of WordPress innards, but would give technical direction on CI/CD work. Admitting my non-expertise in WordPress made my team more receptive to my CI/CD expertise (which helped us to simplify some fragile, overcomplicated pipelines!).

2. Ask Questions

Here’s a hopefully-obvious statement: asking questions (and listening to the answers) is a good way to learn things. Learning things is a good way to build a base of knowledge and become more expert.

You’ll need to ask questions. Just ask. It’s okay. Really.

Ask questions of your team, both in group and individual settings. The answers they give will help you build your knowledge, of course, and your intuition around the subject. It will help your team get better at articulating what they know, which will help them in future interactions across the company. If you don’t understand something in their answer, or need them to change the level of detail, say so. This will also give you a better feel for the expertise of your team and personalities.

When asking questions of your team, it can help to (separately) ask the same question of multiple individuals. The difference in answers can be illuminating. You might discover over time that Bert is terser with his answers and will focus on exactly the question that’s asked, where Ernie might give a longer answer with more background information. Or you might discover that Oscar will make up answers to hide when he doesn’t know something, but Kermit is transparent about what he doesn’t know.

Ask questions of your boss, your peers, stakeholders, and anyone else that might have useful information. These won’t be technical questions, but they can help you build up business context, understand the “why” behind requests, get a feel for the relationship landscape of the company, and gain new perspectives on situations.

Ask big picture questions to uncover context to share with your team.
Ask about implementation plans (at worst, you’re a rubber duck, but more likely you can bring new ideas—and you’ll learn how your team thinks).
Ask about details of the work to drive accountability, self-improvement, catch rhythms of work, and to map out expertise.

When there is something you don’t know, ask someone about it. Even if you’re just asking who you should ask.⁷

3. Share What You Know

As a manager, you need to share what you know with your team, even if it isn’t much.

As a manager, you also represent your team, and need to share what your team knows with the rest of the organization.

Try sharing things like…

Context around tasks or projects – most often with your team (“this task is to help with…”), but context is also useful to share with others (“this was requested by the support team, because…, and if it doesn’t get done, …”)
Constraints and guardrails for tasks (and how you know) – again, most often with your team. If you’re lucky, the team will be able to ask you good questions, learn from the guardrail, or question it.
Priorities your team has been given – guides your team’s work, of course, and gives context outside your team.
Company information and context.
The purpose of a project, task, or constraint.
The reason your team exists.

(If you don’t know these things, one good way to find out is by asking questions!)

4. Be Clear About What Needs To Be Done

Your job, Mr. or Ms. Manager, is to produce results for the organization. It is much easier to get the results you want if you are clear about what you expect.

When you assign tasks, projects, or set priorities or quality standards, be clear about what you expect. And no, it’s not quite as simple as assigning Jira ticket PROJ-123 to Terri. Well, unless your organization is far, far better at specifying tickets than most.⁸

Your job is not always to dig into the details of a planned implementation and offer your opinion about how to do it better. That can be part of your job, but if you’re not an expert in the programming language, framework, platform, etc., your opinion is likely to be uninformed and wrong.

Your job is to make sure your team is clear about the task to be done. Yes, including the “what if…” questions. You don’t need to have the answer now, but you do need to respond helpfully to the questions.⁹ Once the team is clear about the task to be done, you can assign them to invent the approach, shape the details, and implement it.

You’re not entirely done when the team is clear about the task to be done and off building it. You should ask about the details, not in a micromanaging or correcting way, but with genuine curiosity and desire to help. Your questions and conversation will help you gauge (1) your team’s understanding of what you told them and (2) anywhere you need to help drive clarity.

For example, if you just asked them to change the text on the “Login” button, and they’re talking about new libraries and rewriting the credential store, there’s a good chance your team didn’t understand what you told them.

On the other hand, if you just asked them to change the text on the “Login” button, and they ask if the text needs to change in other languages, you might need to seek out more information and clarity. And you also learned something—your site (app/program) has text in multiple languages!

A few specific things that might create useful clarity for your team:

The purpose, goals, and context for the work. At the very least, this can help a team avoid XY problems.
Deadlines, and the reasons for those deadlines.
Things that are out of scope for a ticket.
Things that your team should stop doing entirely (“we’re NOT putting cover sheets on TPS reports anymore”).

5. Don’t Make Assumptions

Don’t make assumptions—or if you do, state them and ask for correction.

You need to see things as they are, not according to a set of suppositions that live in your head.

Now, you’ll naturally fill in blanks with guesses and assumptions,¹⁰ but that doesn’t mean you need to keep invalidated assumptions around. Ask questions. Or state “I’m assuming here that __, is that right?”

This is where your ignorance can be a superpower. Because you don’t know all the details, you have the ability to question your assumptions, and the assumptions of the folks you interact with. You won’t assume, for example, that a deployment really does need someone manually sshing to the server.¹¹ You can dig into what is assumed to be The Way, looking for better ways. Because of your perspective, you’ll be able to build an accurate picture of the world—a picture that nobody else has. That can be a true superpower.

With your team, one particularly useful variety of question is to question technical details of implementations you’re not yet able to fully understand. If you bring general technical knowledge and engineering intuition, your questions can help you accelerate learning and be useful to the people doing the work. That usefulness might come in the form of accountability, spurring learning or self-improvement, or at the very least, feeling like their manager finally understands what they’re dealing with.

A somewhat rarely-used technique in software that’s incredibly useful in identifying, validating, and correcting assumptions is the Gemba walk. In manufacturing, that’s where managers visit the shop floor to see the work being done and identify potential improvements. In software, that could involve joining a pairing session, a design session, doing a deployment yourself—taking yourself to the hands-on engineering work.

Seeing the work being done, or doing it yourself, can lead to the realization that things can be done better. People have a remarkable capacity to get used to things. Observing the work being done (or doing it yourself) can suddenly spark awareness that a process is clunky or poorly documented.

6. Pull Expertise to the Work

If you’re not an expert, your presence doesn’t bring expertise.¹²

However, you can still cause more expertise to gather around the work. Before I get into this, I’m going to caution you: this does not mean that you go get tidbits of knowledge and bring them back to your team. Don’t think Gatekeeper or Knowledge Bringer, but instead think Facilitator or Shepherd.

Work will go faster if the needed expertise is close at hand. Think of a well-organized workbench where every tool is at hand. Now compare that to a perfectly clean workspace, where all the tools are locked in cabinets scattered around the building. You’re trying to create that “well-organized workbench” feeling.

Outside of the team, this looks like stating your own assumptions (as assumptions, and asking for correction, like we already talked about), asking your team for input and opinions ahead of meetings outside of your team, and bringing members of your team to meetings when it’d be beneficial and appropriate. It also means building relationships with experts (technical and non-) outside of your team to give yourself a better chance of quick access to their knowledge later on.

Within your team, consider…

Facilitating technical discussions between team members – this keeps expertise or ideas from staying locked in someone’s head. It gets the team used to having detailed, practical technical discussions. That reduces the friction to future technical discussions, so when Tim has a question, he’s more likely to ask Cindy. It also helps everyone on the team know who knows what, so Tim knows that Cindy is the person to ask.
When someone on your team is stuck, use that as the start to a technical discussion. Pull Cindy into the discussion. If you need more people, go get them! (This is especially important if you are following the work and trying to keep priorities moving.)
Encouraging working in public – this is a special case of the above. If Tim has a question and asks Cindy in a public Slack channel, it’s easier for Cindy to tag Joe and pull more expertise into the discussion. Or if Tim demonstrates in-progress work publicly, it’s much easier to attract feedback, commentary, and excitement than if Tim had opted for furtive, private demos. (Give affirming feedback to those that make a habit of working in public. Give corrective feedback to those who insist on working privately, e.g., through DMs.)
Mapping out where pools of expertise exist – knowing where expertise exists means you can bring help in connecting a need to the right knowledge.

Mapping Expertise – a Sidebar

A quick sidebar on mapping pools of expertise: you should do that, at least informally, even if you are a technical expert. It’s a valuable tool in understanding current and future gaps on the team. Let’s say you run a team of four.

Doug knows all the nuances of your documentation tool
Kusuma is the Python expert
Justin is the only one on the team who knows how to set up a fresh test environment
Kris is always right about Webpack

Of course, your real map would have a lot more skills and nuances listed for each person.

Using that map will help you figure out what skills the team has and what skills the team needs. Or what cross-training needs to occur.

Going back to the example above, did warning sirens start going off when you read the line about Justin? If he’s the only one who knows how to set up a fresh test environment, that creates a potential crunch if he’s sick, or on vacation, or quits.

7. Be Excellent to Your Team

If you rely on your team’s expertise (designs, timelines, estimates, hands-on work), you can’t undercut their trust and support. If you do, you’ll end up in trouble. In the pursuit of results, choose to be excellent to your team.¹³

Get to know your team. Specifically, have regularly-scheduled, structured, weekly 1:1s, in which you give them time to talk about the things that are important to them.¹⁴ Give them feedback so they know how they’re doing. Most of the feedback should be affirming, unless they’re terrible at their jobs.

Solicit input from them about how you and your behavior are affecting the team. You don’t have to act on all of their input, but do consider it.

Behave as a leader. Protect your team (while holding them accountable for work, of course). If you make a mistake, apologize for it. If you decide your team is going to NOT do something, you need to take the heat for that decision, instead of letting one of your direct reports catch flak for it.

Whatever your preferred phrasing, treat your team the way you would want to be treated in their shoes.¹⁵

8. Have a Trusted #2 — and Tell Them!

Your #2 is your right-hand person, the person on your team who steps in for you when something unexpected comes up—and they’re probably much more of an expert than you are in the work. Typically, this would be the person with a “tech lead” or “senior” title, but it doesn’t have to be.¹⁶

I’ve been fortunate to have had some truly excellent #2s when I’ve been managing teams.

A good #2 will help you

Test and correct your assumptions
Avoid making mistakes before you make them
See things as they are
Look better than you are (not cheating, but it is true!)

Let’s dig into that last “see things as they are” item. At the very least, your #2 will bring expertise and facts that you, as a non-expert, don’t have. But you can’t expect them to have all the context you have. Your relationship with your #2 needs to be a two-way dialogue. Bring honest, interrogating questions to your discussions, along with the other skills that got you the job. Together, the two of you can work through issues and see what’s there.

For someone to be your trusted #2, you’ll need to trust their recommendations. There are two incorrect things you might think that means. First, that you need to implement all of their recommendations. It’s perfectly fine to hear them out and choose a different path because you weigh the decision factors differently. Second, that you’ll trust your #2’s recommendations more than you’ll trust your own or those of someone else on the team. Even your #2 might not know everything, and good ideas can come from anywhere.

On that note, don’t expect your #2 to do all the work of formulating plans for you. You need to bring your own thoughts, ideas, and plans. But if you have a #2 you can really trust, you can (and should!) give them the freedom to tell you the unvarnished truth about your ideas. (“Yes, it’s good, but have you considered…” or “You know that John will never go for this because…” or “On paper it all makes sense, but remember how I was telling you about the hacky workaround in the JKL module? Well, unless we fix so it’s not just chewing gum and bad dreams…” or “I really prefer Jan’s approach because…”)

You need to tell your #2 that they are, in fact, your #2. Sure, they’re smart and can probably figure it out. When you tell them, you communicate that you trust them and that they fill a key role on your team. That will encourage them to be more up-front and honest—they can’t rely on someone else to think critically or tell you something difficult.

Wrapping Up

Once upon a time, I was working at my desk in the office. A new member of my team was having a conversation with his onboarding buddy not far from my door. The newcomer must have asked something about me, because I heard the buddy’s answer. “He doesn’t make a big deal of it, but Matt can do all our frickin’ jobs.”

In that role, I was a manager and a technical expert. My organization included software and quality engineers. We started with high-level problems and did the work to turn them into deployed solutions, partnering with other teams or field crews as needed. I had written industry standards, had my name on patents, knew the systems.

But even though I could have stepped in and done the job of any one of those folks, I didn’t. I did /my/ job. My job wasn’t to be an IC. It was to get great results out of my teams.

And years later, when I took over that team of WordPress experts, I was glad I’d learned how to manage work without having to have my hands all over it.

My team at WP Engine (where I wasn’t an expert) needed exactly the same things my teams at Herzog (where I was) did.

Clear guidance
Context
Constraints and guardrails
A sounding board for their ideas / plans / designs
Support
Technical expertise

Even when you are an expert, there will be details you don’t know, or that you forget.

It doesn’t hurt to be a technical expert. In fact, it’s quite a help! But technical expertise is not mandatory to manage someone, even a very expert someone.

If it were, managers could never be brought in from outside the company—or even the team! If it were, CEOs would need to be engineers and salespeople and accountants and truck drivers and ditch-diggers, and every time a new technology was invented, the CEO would need to take a break to skill up.

You job, as a manager, is to produce results for the organization.

Expert or not, you’ll do better at producing results if you:

Admit When You Are Not The Expert and
Ask Questions, then
Share What You Know. With your team especially,
Be Clear About What Needs To Be Done.
Don’t Make Assumptions and
Pull Expertise To The Work.
Be Excellent To Your Team,
Have a Trusted #2 — And Tell Them!

The real secret of managing an expert team when you can’t do their jobs is to give up the illusion that you have to be superpowered and all-knowing. Instead, you can be the manager, supporting and directing your team, making sure you deliver results through your team.

You can do this!

Want to get better at managing, whether or not you’re an expert? I offer coaching that can help you become the manager you want to be. Book an intro session, and we’ll dig in.

Additional Thoughts

Hiring for areas you’re not expert in is a whole separate topic. You can get pretty far by applying the guidance above. I may write an article on it, but no promises.
For more on this subject, read Turn the Ship Around by David Marquet. He takes a different, but compatible, approach to it.

Deep, I know. [↩]
In my case, the company wanted to change the way the entire department worked, so I was hired to lead the transformation, improve productivity and team health, fix broken relationships. My general technical background was a plus. [↩]
I’m a good programmer, but I can’t sling enough code to outpace a whole team. [↩]
That’s not an excuse to avoid expertise you should have, mind you! [↩]
If you’re going to go places in your car, it’s a good idea to give it what it needs: fuel, properly inflated tires, oil changes, wiper blade replacements, etc. If you bluster about how it’s the car’s job to get me where I’m going and don’t take care of your car, you deserve the failure you’ll get. Application to a team is left as an exercise for the interested reader. [↩]
If you’re not a technical expert in the area a team is working on, it helps if you’re at least a veteran of the company so you can provide company context. If you want to play on extra hard mode, try being new to the company and not being an expert in what the team does. [↩]
As companies get bigger, it’s common to not know who is responsible for a task, system, process, etc. Take your best guess at who is closest to having the answer, and ask. It’s completely reasonable to ask “I’m trying to figure out X. You might not know. If you don’t, could you point me to someone who might?” It might take a few steps, but when you get through that side quest, you’ll have learned more than just the answer to your original question. Plus you can give yourself an achievement badge for this side quest! [↩]
“A card is a placeholder for a conversation”, after all. [↩]
Responding helpfully is very situation-dependent. It might be best for you to track down an answer all by your lonesome. It might be best to bring someone from your team with to ask the follow-up questions they’ll have. It can also be best to give the team a suggestion about who to talk to, and have them go find the answer. There is not a hard-and-fast rule. [↩]
You know what they say about making assumptions, right? The Umptions are nice people, so don’t! [↩]
True story. [↩]
Whoa. I’m sure you’re amazed. You can pause until you’ve recovered enough to keep reading. [↩]
Be excellent to each other…and party on, dudes! [↩]
You also get time for your agenda. Let them go first, though. [↩]
Some formulations to consider: do to others as you would have them do to you; treat others as you would like to be treated; do not wrong or hate your neighbor; treat your inferiors as you would be treated by your superiors; an’ it will harm none, do as you will; first, do no harm; be excellent to each other… [↩]
It’s possible the most senior person by title is focused or wired in ways that make them unsuited to be your #2. Maybe they’re a high-level IC because of deep expertise in an important subsystem, but have little interest in anything else. Your #2 is someone you trust to “be you” when you’re not around. [↩]