One of the challenging things about being a staff+ engineer is that people trust you. They trust you a lot, and there might be less pushback on ideas than there should be.

This makes sense. To become a staff+ engineer, you usually need to be really good at this intersection of skills¹:

• Writing good code
• Software architecture and system design
• Communicating clearly and persuasively

When you communicate out an idea, you are eminently trustable. Usually you're right, and you have the bona fides to back that up. And you're also persuasive and somewhat naturally convince people that your idea is right.

This is a challenge. As a staff+ engineer, you are still human, so you will still *gasp* be wrong sometimes. But when you're wrong, you're less likely to get pushback. As a staff+ engineer, you have to be more careful with your ideas, and actively seek out checks on your own ideas. Pushback won't come as naturally and immediately as it did earlier in your career.

Here are a few of the things that I do to validate my ideas and elicit checks on them. Some are the same as when I was a senior software engineer, while others are unique to the leadership role of staff+ engineering.

Ask questions first

One habit I had to break in transitioning into leadership was excitedly spouting off about my ideas right away. When you're not the most senior IC in the room, there's not a lot of danger in that. It can grease the wheels of design discussions and get things going.

But when you're the technical leader in the room, things are a little trickier. If you toss out an idea, it anchors the space of ideas near what you suggested.

Instead, I try to start by asking other people questions to get their wheels turning. Here are a few questions I like to toss out early in design discussions:

• Is this the right problem for us to solve? What's the real fundamental problem?
• What constraints do we have here?
• What would the simplest, silliest solution be? Wrong answers only, please!
• If we could wave a magic wand and have a solution, what would that be?

This reminds me, time to go ask my product management peers how they elicit ideas from people. That's one of their core skills, so time to learn more from them!

After you've gotten input from a lot of people, and their ideas come out, it's a lot safer to float your own ideas. You still have to be careful to not dominate the discussion and assert your ideas as correct, though.

Ask for feedback, and accept it with grace

You have to just get out there and ask for feedback. A lot. Have a design doc? Spam that out to some peers and remind them to dig in, and be explicit with what sort of feedback you want. Have code to review? Get your reviewers lined up, and make it easy for them to review the code so you get good feedback.

In the times when people do provide critical feedback on your work, you need to say "thank you" and accept the feedback gracefully. It's hard not to get defensive sometimes. This is something you worked hard on, and someone found flaws in it! It's necessary, though. Positive reinforcement will help you get more feedback over time. If you are defensive, that will just decrease the amount of feedback you get.

And remember to be open to being wrong, and assume good intent. Try to by default interpret critiques as legitimate found problems in your code/design/whatever. Find a way to take the feedback and use it to improve your work. If the feedback is correct, then you have a clear path to using it. If the feedback isn't correct, understand what led to that feedback, and make it so that the underlying system is clearer. Not only will it strengthen your work, it will also encourage people to give feedback more since their feedback led to an improvement.

Don't be wrong (be your own reviewer)

It's cheeky, but it's also important. You got here by being right a lot! And as a staff+ engineer, you do have more pressure to not be wrong, because you're expected to be highly skilled and competent.

Lean into that and be your own reviewer before you get someone else involved. After you write a design doc or finish implementing a feature, let it sit for some time then come back to it. Look at it with a critical eye, and try to imagine what a skeptical peer in your position would think. If you got this review in your inbox, would you be happy with it or would you request changes?

Now go make those changes so that when you do submit your doc/code for review, you're not as wrong.

What do you do?

This is a narrow view of how I approach a narrow part of being a staff engineer. I'm really curious what other people have found effective, and what they do that's not on here!