“Staff Engineer” Read Through, Part 2
“Stay Aligned with Authority” through “Present to Executives”, Pages 70-99
Here we go! Part 2, base 0! Onward!
—
Stay aligned with authority
Your relationship to your manager in a technical leadership role is different than working at previous levels. They are no longer giving obvious and clear direction, and you are making decisions that affect the output of you and the rest of your team. If you make those decisions without vetting them with your manager, or if things go much differently than expected and your manager finds out later and is surprised, this is often a failure condition that can erode trust. A transparent, peer partnership with your manager, where you know what they expect of you, and you keep them apprised of decisions and progress, is a key to productivity and mutual trust.
To lead, you have to follow
Identifying the most critical work is rarely an effort you can successfully execute on your own. Gathering input and insights to guide your efforts, and supporting work that is on-going, requires close partnerships. To have impact, you need both a clear understanding and ability to notice gaps AND the ability and fortitude to actually affect change. When someone else is owning a specific effort, and they are trustworthy and driven to solve the problem at hand, they should be given staunch support. The author notes that if you cannot leave the work to such a person and provide them feedback and support, this may be a problem with your ability to influence and provide effective feedback.
When you ARE providing feedback, prioritizing making this feedback non-blocking. For me, this is often questions on design docs that matter, but can be answered later. Surfacing a question early helps to keep it in mind as progress is made, versus bringing it up when answering it or changing course could be much more expensive. I also prefer to give detailed code review feedback, but ensure it is marked as “resolved” or “non-blocking”, saving blocking comments for true risks. When something is to provide extra information or probe for details, this shouldn’t need to halt progress.
Learn to never be wrong
This section forced some pretty hard self-reflection. I do think I’m better about it now, but “they’ll continue debating until their perspective wins the day or time runs out”. 😬 Yikes. This was definitely me. My talking was and sometimes still is driven by insecurity or anxiety. I want desperately to be understood, and, ultimately, useful. The following bit asserts that this method of “influence” or “persuasion” is “characterized by the resignation of their peers”, instead of enthusiastic partnership. One piece of feedback I received was that while I was frequently right, I was not talking to people in a way that they could hear. It was too brusque or out of alignment with their feelings or current stage of consideration. Being correct is useless if you can’t communicate and be heard and understood.
Fortunately the next bit of the text was more reassuring, as it addresses driving consensus and resolution in the face of contentious, conflicting views *is* something I am good at. While my ability to navigate this may have come from a place of fear and discomfort with conflict, it has become invaluable. Frequently blocking issues are human, not technical, and being able to be a bridge between disagreeing parties can be critical to moving a project forward.
When reconciling these points of view, and even your own, I (and the book, but not directly) try to stick to a quote I’ve heard: “Do you want to be right, or do you want to be in relationship”. Often this is applied to familial or romantic relationships, but I think it applies to working relationships, too. If your only goal is to convince a group your view is right, you will often alienate others and damage your working relationship. You also sacrifice the opportunity to learn, because you are not trying to listen and understand, but explain and convince.
Another key aspect of effectively shaping plans and driving consensus is asking the right questions at the right time. Asking questions is a superpower. The right questions can at once convince others that you are in alignment, understand, and are working toward the best outcome. “This design won’t work because of X” does not sound constructive or helpful, and might betray a misunderstanding you have. “I have seen things like X before and I didn’t always have a good way to address that. Do you have that handled, or do we need to address that before we get to milestone Y?” turns this into a conversation, and shows interest in a positive result, not shutting someone down.
The last bit of this section is about jerks. First and foremost, don’t be a jerk. If you’re not sure whether or not you’re a jerk, maybe you are. It’s hard to know if you’re a jerk, and it gets even harder as you move up. In the book this is approached from the “a jerk may not be a jerk to you if you’re high up”, but doesn’t address as clearly “you may not have anyone tell you that you’re the jerk because people may be afraid to give you that feedback and incur your wrath”. Personally I have tried to seek feedback anonymously. I have setup burner email addresses and shared the passwords so folk could log in to them and mail me feedback. There are google forms that you can setup without capturing identifying data, too. Regardless, people who have written you off may have no interest in helping you via feedback, but asking early and often may help you catch your worst tendencies before they are out of control.
As I mentioned earlier, I loved being technically correct, and didn’t realize that it was as or more important to maintain relationships. At the time I was definitely a jerk, and it took time before I got that feedback and truly internalized it. In terms of dealing with jerks, the book lays out some strategies, like involving more senior people they won’t be a jerk in front of, or investing time with them to ensure they feel heard in private and don’t derail conversations. The follow up is private conversations documented, then escalating. I haven’t had to explicitly escalate interactions with jerks often. There were times their managers asked me explicitly to help coach them. I was the sole dissenter on someone’s promotion and ultimately it was blocked because they were a jerk. This was a very acute case where someone was technically brilliant but very difficult to work with. Setting an example of this being a promotable path without explicit correction didn’t feel good. Another case was mostly setting a different example and showing results without being harsh in feedback and consensus building.
Create space for others
What I hope to do most is very aligned with this section. I want to elevate others, set positive things in motion, and step away. I don’t want to be the gear critical to the machine making positive progress. I want to tweak the machine so it runs without me there. When I am and do contribute it should be additive, not intrinsic to success.
Some notes here I definitely agree with is promoting participation. Some people DO NOT want to speak in meetings. Demanding they do so may not be helpful. Knowing what matters to them in advance and acknowledging them and the viewpoint in the discussion can help. Leaving room outside the meeting to contribute also helps. I take good notes because I can transcribe near-real time, mostly bred from doing almost-transcripts of interviews for years. If you have good notes, it’s an easy “in” to allow for follow-ups and feedback after the meeting. If people ARE comfortable speaking but are shy or don’t want to butt in, giving them the floor explicitly can be powerful.
In terms of right-sizing feedback, this section makes some excellent callouts. One is about where/if you deliver non-critical feedback. The next, which tied into my last behavior, was to not center yourself in providing feedback and forcing decisions to match your preference to show value. For me, I always thought that saying smart things or giving valuable, pointed feedback publicly was how I could be valuable and make sure people knew it. It took a lot of time and growth to be able to take lots of notes, bring up one or two really important things to discuss publicly, then provide other feedback offline and ensure it was not blocking. Sometimes other feedback was valuable, but this avoided sucking up all the air in a room.
When new work arrives, and ownership is being decided, I have definitely tried to avoid being “first” on a project. If others can lead and it will be better for their growth, and it is not a risk (or that risk can be mitigated by consulting), that is far preferred. Being a good second is a very different skills than being a lead on a project. Being able to avoid the most egregious of issues without enforcing every preference you have takes a lot of discipline. The author suggests this kind of sponsorship (“Person X and the team would benefit if they led effort Y.”) a few times a month, while ensuring you still do some things yourself. I have not found this balance well at my last few jobs. I am working on it. I tend to rat hole on a deep problem, or remove myself and consult and point at important things. Blending this is rough. This is mostly because I don’t have experience in this role. I was a mid-level engineer that needed to show dedicated takes ownership, then a people manager who needed to keep my hands out of the execution work. Being a staff IC is not either of those jobs and I’m still trying to learn to do it well.
The last piece I liked a lot in this section was to volunteer to take notes. I’ve gotten away from it, but good notes really elevate positive meeting outcomes. Being a note taker may also take you a little more time, so you’re less likely to butt in if it’s not necessary. Being the note taker every time can be hard, but suggesting someone should, and volunteering a time or two, can help jump start the practice. My time interviewing at Amazon really honed my transcription skills, so I can live transcribe, and then go back and summarize/boil out what’s important later.
Build a network of peers
This is one of the primary factors that have led to the success I’ve found. Knowing people who know people, making connections, getting diverse feedback, being known broadly… all of this has added up to tremendous value. When reconciling various viewpoints, having some history with all parties makes this much easier. I have mostly focused internally at previous jobs, but have started to branch out, largely via LinkedIn, to network with people throughout the industry. I have always tried to maintain positive relationships with recruiters, and haven’t “applied” for any job since the first one I got after college. One was a referral by a friend, one was being recruited, two were connecting via existing recruiter contacts.
If you can pick one “extra” to invest in, I would advise this. If someone gives an interesting talk, reach out with some additional questions and see if they’d like to meet. If someone from a partner team impressed you in a meeting, you can have coffee with them. Being easy to work with, and well-known, is tremendously helpful.
Present to executives
When I first started having interactions with executives, I was very resistant to the “standard” document format. It was… blah, seemed so boring, so staid… it sucked the creativity out. Turns out, this is not the place (document format) to get creative. Executives see dozens of documents. They need the content, and need it served in a fixed format so they can find what they need quickly, provide feedback, and make decisions. It isn’t vanity to enforce a format, it is avoiding unnecessary searching and distractions from unfamiliar layout.
Writing this document, even if you don’t end up presenting to the executive you targeted, is its own reward. It is a lot of work, and can serve to crystallize your thinking, giving you structure, raising questions you hadn’t considered, and enunciating your thinking concisely. While you’re undertaking the writing, remember why you are approaching an executive in the first place. Is this a plan that doesn’t need their approval? If not, why are you asking them? Are you seeking input on a tricky area that no one else can provide? Let this guide you, so you can ensure that there are clear calls to action in the document.
Once you have a draft of your document, and after each major revision, get feedback. Ideally it can be from people that have presented to executives before, and people with diverse viewpoints, and with no context. This will help you identify where you are wasting time with too much detail, or confusing the reader with too little.
When you DO present, focus on the best outcome, not what you thought was best when you showed up. If you knew it all, you wouldn’t need help. Be sure to accept feedback and even criticism with grace, and take it as a gift. Follow up when you’ve incorporated suggested changes or view points to let the feedback provider know you took it seriously, and that you actually did what they were asking.
——
This is the end of part 2 of the read-along. I think the book provides a lot of very dense information here that may require some re-reading, your own note-taking, and reflection. This definitely isn’t a fiction novel to read through quick to advance the story.