As I read through some of the technical design docs / OKRs on the team, I've noticed some fellow engineers put out some really thoughtful comments (especially the more senior folks), however coming up with such feedback observations is not always super intuitive. As a new-hire junior, I'm looking to build up this skill of conducting an effective design / OKR review.
What do you usually look for / pinpoint when reviewing a design doc or OKR for a new project? How can I still provide good feedback despite not having the same level of exposure / experience?
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:
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.
Hope this helps!
When it comes to evolving your participation in discussions (both async with design docs and sync with meetings), the process is generally like this:
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
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.