How to effectively review design docs or OKRs as a junior-engineer?

As a junior engineer, a lot of your contributions to those documents are just going to be questions (usually along the lines of "why did we do <x>", "did we consider this alternative", "did we consider <y> alternative"). It takes years of nuanced experience to properly give feedback, so I wouldn't worry too much about providing good feedback. Focus on executing on your existing work/projects, take up increasing broader ownership, ask questions along the way: you'll gradually build up to foundations to provide more nuanced perspectives on those docs.

For design docs, what I usually look out (as a frontend engineer) for is:

• How cleanly is the doc broken down: is it clear that I can indepedently review pieces of the doc? Is it clear how the project is broken down into subdomains, milestones, etc to allow for clearer separation of concerns, parallelization of workstreams, more granular incremental rollouts?
• What schema changes are we making to APIs. Common questions I'd have is: how flexible are these changes for future products, are these changes backwards compatible, and if logic is shifted to be on the other end of the stack does that simplify the design.
• How granular is the business logic broken down. Generally, I use the design docs as a heavy reference for how I write code, so the less thinking I have to do to map the doc into code, the better.

For OKRs, it's more nuanced and vague: a lot of it comes from working backwards from what domain(s) the team owns and what problems the team is currently facing. Another part of it comes from experience on what OKRs did/didn't work previously for the team (or for previous teams engineers were on). I can give you my view to provide a starting reference for thinking about OKRs as a senior product/frontend engineer.

• A team should have between 1 and a handful of metrics they're driving to be bigger. Products generally drive users to behaviors that positively influence the business, so the team should know what causal chains they can/want to influence within the realm of the product.
• I'm not a big fan of having a flat goal as the top level goal OKRs (i.e. "10m new signups in 1 year", "+$50mil for revenue in 1 year"). Quantifiable goals are great for establishing a baseline to relatively tracking progress, but often times external factors can drive teams to be closer/further away from numerical targets (example: for 2 years, my team hit goals despite shipping very little at all). So I like structuring OKRs like "Our goal is to do <x>. We plan to do <x> through <y> projects, and we project <z> metrics to change" and pushing the team to focus on doing <x> as a goal. This way, the team is more focused on the goal rather than trying to think about hacking the last bit of value to hit <z> metrics.
• When thinking about projects or OKRs for the team, time should always be considered: more specifically, time to execute. Is the time to execute something the team is comfortable with? Are there clear bottlenecks in development present across every project? If there are clear bottlenecks, incorporate projects to tackle those bottlenecks in the OKR doc and call out how those projects will help the team in the future (depsite usually not generating any immediate ROI).

Hope this helps!

It's worth noting that the Senior promotion at LinkedIn does not depend heavily on your ability to review docs. Doing well in the Leadership category is about disambiguating requirements from a vague OKR by asking the right people who will give you good feedback on your design. Challenges usually come from operational overhead when dealing with multiple teams. And you will get a lot of recognition for aligning the correct stakeholders and being able to call out roadblocks early.

After a few reps of this, you will gradually become more comfortable and pick up on the common pitfalls in your domain. Over time, you'll learn who are the upstream and downstream and how your design may affect them. Make sure to ask questions to understand the direction of the team so that you're able to call out if an OKR or design is either redundant or shortsighted. There are rules of thumb that Jonathan mentioned which can be generalized, but becoming a good reviewer is a bit niche to your domain because it requires understanding upstream and downstream consumers well.

Take advantage of that invincibility you have from being junior. You can be fearless when asking questions and in my experience you'll often get an answer. And asking questions in a doc or even by PM is very valuable even for the person answering your question. I often notice flaws in my original design when answering questions from people on the team.

When it comes to evolving your participation in discussions (both async with design docs and sync with meetings), the process is generally like this:

1. Ask a lot of questions to get comfortable just saying anything and to learn super fast
2. Use the understanding gained from #1 to start analyzing patterns in how more senior engineers contribute
3. Leverage the insights gained from #1 and #2 to start actively participating, emulating the healthy patterns from #2

For #1, I recommend following the advice from this discussion: "I struggle to come up with things that add value to a meeting - What do I say?"

Make it your goal to ask at least 1 question per new design doc within your team from now on.

After you get comfortable asking questions and just being a person in the room, you can move on to these: [Taro Top 10] Communicating Effectively As An Engineer

I also highly recommend my system design series to learn how you can start leaving L5+ style feedback as just an L3: System Design Masterclass: Taro Playlists