Why some engineers get trusted with high-impact work

It’s fun and rewarding to work on critical tasks. But there’s only so much important work to go around. Worse still, the chances to work on these projects are unevenly distributed, because often this work is done by hand-picked teams. I’ve been on a fair few of those. What gets an engineer put on that list?

Circles of trust

As you acquire more recognition among managers at your company, you rise up through a series of concentric circles.¹

At the center is being the go-to engineer on your own team. You start here by just being straightforwardly good at your job. At this point, your manager will (explicitly or implicitly) be steering important work your way.

Next up is being the go-to engineer in your org. At this point, your manager’s peers are asking your manager to task you with key pieces of work. You’ll probably be on the shortlist to lead any cross-team projects that touch your team, or at least you’ll be tactically placed on cross-team projects that must succeed. Your org’s leader (typically a director or VP) knows your name, and will occasionally reach out to you directly.

Finally, you’re one of the inner circle of engineers at your company. All the engineering-facing directors and VPs know your name, and you’re routinely pulled onto cross-org ad-hoc teams to execute on key bets. You’re considered a key resource, so you’re typically not allowed to sit on an individual project for very long - the company will shuffle you over to whatever it considers most important at any given time.

These concentric circles are circles of trust: first trusted by your own manager, then by your manager’s peers and direct bosses, and finally by the real movers-and-shakers in your company, all the way up to the CEO. Unless you’re already snowboarding buddies with your VP, you must pass through those levels in order. Your boss’s boss is only willing to consider trusting you because your boss does, and so on.

How do you move up through the circles? In my experience, by being invited each step of the way. Unlike in your own team, you can’t go up and ask to be put on a particular piece of work. Instead, you’ll get some contact with senior managers by working on important projects, which (if you do a good job) encourages those managers to tap you for more important projects, which gets you contact with more senior managers, and so on. You have very little direct control over any of it - all you can do is put yourself out there and try to be the kind of engineer that leadership wants to put on other projects.

So the question “how do I get the good opportunities” really boils down to this: what does it take to be the kind of engineer the company can trust?

Why trust is so hard

Very few engineers really appreciate just how delicate the relationship is between themselves and very senior managers.² As you talk to people higher in the management chain, they have less and less technical context, and no direct power to affect the product. But they have a lot of institutional power to ask engineers to do things, and a lot of responsibility: it’s inconvenient to you if a product you work on doesn’t succeed, but it will cost your leadership team real money in lost bonuses (and maybe get them fired). So they’re heavily invested in success, but almost entirely dependent on their engineers to actually do the work that needs doing, and to tell them what can be done in the time available.

That’s why the engineer-leadership relationship is strange and delicate to maintain. These are very powerful people at the company, who can mobilize hundreds or thousands of people to achieve their goals, but they need your help to do anything directly. It’s an awkward position for them to be in. Even Caesar felt helpless when in the dentist’s chair. If you can be genuinely helpful in these circumstances, you will reap the benefits of having Caesar as an ally. But of course, if you betray his trust, you may get your head cut off.

One reason large tech companies have many layers of managers is to avoid having to rely on this tricky relationship. VPs are supposed to be able to talk to their manager direct reports, who talk to their manager direct reports, who get estimates and plans out of their engineers. Everything thus gets safely triple-handled on the way up and down the chain. In practice, very senior leadership people often chafe at this indirection, and quietly rely on a few very senior engineers as a sounding board or a sanity check. Sometimes this is even formalized in the org chart (for instance, as a ‘floating’ staff engineer reporting directly to the VP or CEO)².

Maintaining the trust

How can you keep the trust of very senior managers? First, be discreet. If your boss’s boss’s boss comes to you with a quiet question, and you immediately start saying in Slack things like “as I talked about with Big Boss the other day”, you have demonstrated that you can’t keep your mouth shut. Being trusted by senior leadership often means being trusted with confidential information (about company plans, for instance). Avoid giving the impression that you might not know to keep that private.

Second, talk at their level. You and your CTO share almost completely different contexts: different working spheres, different problems, different tools. When they come to you and ask how well a particular feature works (for instance), that question may as well be in a foreign language if you don’t have their specific context. If you immediately launch into a reply about SLOs or the quality of the code, you are going to bore them and provide no value. They are almost certainly coming to you because they have a specific agenda or they heard some claim that they want to double-check. You need to draw out some sense of what that agenda or claim is before you commit to a response.

Finally, you must get the technical questions right. If you tell them that something works a certain way and it doesn’t, or that it’s impossible to do X and it turns out to be possible, the trust will be gone. Very senior managers are distant enough from the work that they can’t double-check you on details, but because of that they’ll be paying close attention to the things they can check you on, like the customer-facing results of a project.

What happens if you do break the trust? Unlike Caesar, your friendly neighbourhood executive is not going to literally cut your head off if you mess up the interaction. But you will silently and immediately be dropped from that circle of trust. They will never ask you a direct question again, never loop you into early planning discussions about secret projects, and they won’t mention your name in private discussions about who should lead what project. This is not the end of the world, or even the end of your ability to be promoted at the company. But it is the end of your close relationship with that particular executive.

Keep it in your management chain

A word of warning. It is great to be trusted by managers at your company. But you must try to keep it inside your management chain. I have seen engineers fall into the trap of becoming the go-to person for managers or product people from different orgs, at the expense of their actual job. There is no shortage of predatory managers outside your org who would love to have more engineer time “for free” (i.e., they don’t have to bargain for it with people who they’re actually accountable to) ³. One “quick favor” can be a sensible idea. Two or three is a mistake.

It can be pleasant to feel helpful, and for many engineers the opportunity to solve someone’s problem is tempting enough. But it’s a really bad idea to get involved like this. These people will be very persuasive - it’s their job! - but they won’t be there during your next promo discussion, and they’ll walk away from you the second it’s in their interest to do so. Save your energy for the work your org actually pays you to do.

How do you push back against these requests? Directly involve your actual management chain. Say something like “hey, I’d love to help you, let me run that request by my manager so she knows what I’m doing”. Your manager will probably bite their head off for poaching her engineers.

Summary

• The foundation of trust is being good at your job. Be good at your job!
• You get noticed by working on important projects, which gets you noticed by more senior folks, and so on
• The more senior a manager you’re trying to build trust with, the more delicate the relationship will be
• It’s a different set of skills than building trust with your direct manager
• Direct trust relationships are very useful but violate the “normal” chain of command, so must be kept relatively discreet
• Do not alienate your own direct manager
• Do not invest in these relationships outside your own management chain! Maybe it’s possible, but I’ve never seen it work