How to develop and express opinions as a Senior Engineer?

Love this question.

I actually had similar feedback which got me rejected as a Senior when interviewing. After working on fixing it, the offers started coming in. I had a LinkedIn post that explained it in a bit more detail: https://www.linkedin.com/posts/jordancutler1_techcareergrowth-softwareengineering-learning-activity-7042993957881950208-pDqx?utm_source=share&utm_medium=member_desktop

Overall though, I get you. I had a mindset of making a decision based on everyone else's thoughts first. We are taught to be open-minded and to listen. This is correct, but in some cases we can take it too far.

The way to fix it in my experience has been...

1. Form a technical opinion based on weighing pros & cons before hearing everyone else's thoughts
2. After hearing everyone else's thoughts, you can combine your original ideas and their ideas with what might be the best approach.
3. Over time, reflect and understand where you generally fall in your opinion space. Where can you improve? What assumptions were incorrect? What can you learn from how your initial opinion changed from the ending opinion? By reflecting on these, you'll start to get a better understanding of yourself, your ideas, and be able to build stronger cases for technical decisions.

Hope this helps!

The framework I usually operate on is "strong opinions, weakly held":

• As a senior engineer, you need to break discussion stalemates to move the project forward.
• Often times, people don't exactly disagree in discussions (so they're fine with most/any reasonable outcome, but don't really want to say it) or they don't even know where the discussion should begin.
• So that's where "strong opinions" come in: you need to be ready to put your opinion down to serve as the starting point. Although you need to put something strongly down, you should be explicit about what specific details that helped you formulate your decision as you vocalize your opinion. This is so the broader group can understand how you arrived at your line of thought and see where they should/shouldn't be building on. Once you've done that, you should end with asking people what their thoughts are.
• This is where "weakly held" comes on: you need to pull input from other participants and keep the discussion going until the group has arrived at a consensus. It doesn't matter if the final outcome is completely different from your opinion, someone else's opinion, or something completely new that was thought of mid-meeting: you are simply a conductor to drive people into agreeing on something reasonable.

Jordan and Jonathan's answers are both great.

I do want to put "strong opinions" in context. Strong opinions are vital in helping organizations make decisions. Correct ones steer the organization toward success, and well, incorrect strong opinions are often disastrous. So being cautious about having strong opinions isn't bad thing.

In a way, opinions are generally predictions about what would happen if a particular action was taken/decision was made. That's why, like Jonathan said, it's important to:

1. Logically think through why you arrived at that opinion/prediction
2. Be open to alternative predictions that could also be correct

To develop stronger opinions and make more powerful predictions, I would start with having opinions about your own work and your own ownership area first, before attempting to vocalize opinions about other people's work. This is especially true if you are afraid to be wrong.

So maybe right now you are taking a lot of opinions from others about what you should be doing in your space - but maybe you don't need to. Try planning for your own work. By doing so, you'll inevitably have to know what your opinion about what the biggest problems are, what you should be doing about it. You will even have to explain this to others, like your manager, and your act of presenting your thought process will demonstrate that you have at least some opinions.

Further, this will allow you to figure out whether your opinions are correct and gain the needed confidence. Repeat this and eventually you will have opinions about myriads of things, and you would also have done the work to back those opinions up.

Ultimately, if you find that your own opinions about your own work isn't correct, it won't be a big deal (the impact should be limited), and you can always strengthen your own understanding to make better predictions later.

Hope this helps!

Is there any advice on how to develop these skills?

Honestly, my advice here is just do it. More specifically: Embrace your lack of knowledge, be bold, and aggressively put yourself out there asking questions and learning. Be completely unafraid of "looking dumb".

I have worked with several incredible Staff Engineers. I was fortunate enough to see many of them in action when they were new to a team. None of them waited around for very long before they jumped right in trying to add value.

Here's a story I like to tell when it comes to the difference between senior and staff. It's about a Staff Engineer I worked with on Portal:

• They came from Apple with a deep iOS background, working on many flagship Apple products like the Apple Watch.
• Portal ran a fork of AOSP underneath, so it was sort of the complete opposite of this engineer's mobile background. We had a deep Android ecosystem, while this engineer was super accustomed to iOS.
• Within days, this engineer just started tearing into the code, putting out experimental commit after experiment commit and asking tons of questions. As expected, their initial commits were super terrible, literally some of the worst Android code I have ever seen in my life.
• However, they were extremely receptive of feedback and had this self-deprecation and charisma about them that made you want to help them more. You could tell that this person wanted to get stuff done fast, do it properly, and add value to the team. They kept improving and improving at light speed.
• Within just 1 month, you couldn't even tell that this person was a new Android engineer. Within 2 months, they were coming up with and leading new initiatives to revamp the entire Portal platform, doing the whole Staff Engineer "creating scope" thing. It was spectacular.

To dive deeper into the tactics this engineer used to learn so fast, check these out:

• "How do you overcome the fear of asking stupid questions / bothering people when you need help?"
• "I struggle to come up with things that add value to a meeting - What do I say?"
• "What’s the most effective way to switch domains in tech?"
• [Masterclass] How To Learn Quickly In Tech

Promotion is about behavior change, and this is especially true when you're pushing for Staff. Learn how to be nimble and extremely adaptable to any new crazy situation that comes your way. Once you master that, you'll unlock the Staff Engineer level and more. However, it all starts with a leap of faith.