Diana Pojar
Diana stands out amongst many of the others in the book because she is a Staff Data Engineer, while most of the others are Software Engineers. I am happy to see other disciplines expanding and including more senior roles. When I was at Amazon I saw a few roles start to show growth, such as the SDET role. I met the first SDET to get an L7 promotion to Principal SDET, and it was relieving to see that there was sufficient bootstrapping and acknowledged scope for growth into a role at this level. Similarly for Frontend Engineer, which was created to avoid some of the server-centric bias in evaluation and promotion review, acknowledging the complexities of frontend work, and that it significantly differs from a generalist profile. I am not sure if I’d met anyone that made it to L7 when I left, but I imagine someone had. I do think overspecification in roles can be limiting, and may reduce fungibility, but when over broad descriptions are used for different jobs, it can hurt clarity.
Diana again notes breadth versus depth, explaining she works on broad strategic initiatives that have notable business value, while a principal engineer she knows is dedicated to detecting and fixing performance problems. After reading this 8-9 times, and sort of rueing that I don’t know what I am, it occurs to me that this may not always be clear when someone is hired or moves to a team. Will I make this team successful if I bridge other nearby teams and enable faster delivery, or if I go deep in the code base and eliminate problematic areas or increase performance. I think that this isn’t described because many times no one knows. Ideally a Staff+ engineer can spend some time with the systems and team and determine priorities, but when priorities are dictated it can get a little square-peg/round-hole.
Diana recognizes a few times that she has privilege and power with this title others may not. I think that a big part of having this kind of influence is using it to lift up others. For me, this is especially true for people that work or behave in non-traditional ways. A quiet person may have amazing ideas, but don’t have confidence to share publicly. Can we make an even playing field for written suggestions? Can we help boost their confidence by copresenting with them? It’s not one-size-fits-all, but finding the way to help people perform to their best and be recognized is very rewarding.
Diana’s description of how she reached Staff was interesting to me, and echoed a previous story. She was put into a team with much more senior members and rose to the occasion, and seized the opportunity to grow. A significant impact she noted was moving traffic off a production database to the tune of millions of dollars. She notes that believing that you can do things you may not be comfortable with is a major part of advancing, and I think this is the case. Early in my career, I had gotten familiar enough with our systems that I didn’t think there were things I couldn’t fix. This wasn’t necessarily true, but it gave me the confidence to dig deeper, sometimes identifying bugs in our database system or our compiler’s runtime.
In relation to pursuing management, Diana has a very clear vision, which does not include managing people. Her main note is that manager’s shouldn’t code (regardless of what Elon Musk thinks, I tend to agree). I didn’t get this memo when I moved to management, and it led to frustration. I would take on “side projects” to try to streamline an implementation, or build a small stopgap solution to cover the time until my team could build it right. I can’t say these things had no value, but my ability to strategize and advocate for my team was certainly impaired by sinking time elsewhere. I got away with it because I had a really self-sufficient, smart, driven team… so I could lead with a light touch at certain times and things stayed on track. One of the misnomers I had about moving to management was that it would really increase my ability to grow and promote people. Diana notes that influence and growing people isn’t limited to managers, and I’d say in some ways it can make it more difficult. If I’m spending time trying to mentor someone toward promotion who isn’t on my team, this might be useful but not inline with my goals. Doing so as an IC, especially a more senior IC, is perfectly normal.
—
Dan Na
Dan is a Staff Engineer at Squarespace. Dan leads their internationalization platform, which builds and maintains internationalization primitives. I’ve never gotten too deep into the underpinnings of i13n, but do deeply appreciate it. Translation and localization are so different, knowing the currency someone is using doesn’t tell you the languages they know, and so on. I have wanted to try to capture more details about a user to give a better experience. For example, if they can read 3 languages, one fluently, then decisions can be made. Ideally all content is in their fluent language. If there is user generated content in another language, but on-the-fly translation isn’t available or of high enough quality, giving the option to view the content in one of their other understood languages may be better than presenting it untranslated.
Dan, like many others, notes that probing questions are some of his most valuable output, surpassing code. I feel similarly, and know that strategy, review, and oversight are going to yield more relevant outputs than the code I can write (mostly).
Dan adds an interesting note about ownership. We normally think of projects or systems when we talk about ownership, and Dan specifically mentions that Staff+ ought to be taking ownership of all things that contribute to engineering and block it. I love this, and think there’s so many cultural and procedural fixes that can speed up engineering as much as tools or other code-driven solutions. Dan mentions that his title does help him escalate and push through some issues that may not be impossible for others, but could be more difficult.
Dan mentions culture building through a pairing system, to let people across engineering get to know each other *before* their first work interaction, which could be under pressure or with disparate goals. I believe strongly that having connections first changes the tenor of such conversations and helps start from a place of partnership against a common foe versus coming in feeling at odds with the engineer on the other side of the table. He also started book clubs (one of my favorite activities!) with similar learn and connect thrust. Even better, other people maintain this. I got there at Amazon and this was great for a ton of people to get presentation experience, and more junior folk to show leadership in organization and execution.
Dan discussed coming in as an almost-staff, and having a project that did directly lead to promotion. This differs from a lot of others, but I think the reason is the same. It had very high impact and demonstrated working across teams and systems. A single project doesn’t have to do it, and often even when we think we have one that will we are wrong and feel like it was a waste.
I won’t enumerate the ideas Dan shared about shining a light on others, but will say this is something I like most. Even if I’m not doing all of the things I need to in order to obtain a high rating, a more junior engineer doesn’t know that, they see that someone in a very senior engineering role has publicly acknowledged them, gave them a peer bonus, lauded them in a large meaning, or given another form of recognition. The encouragement of junior engineers is possibly the most powerful boon granted as you progress up the engineering ladder. It is multiplicative (especially as you start teaching people to teach, or teaching people to train others to teach), and most of the people in these positions are capable of excelling, and need a nudge and a small dose of encouragement.
I won’t belabor the “being a manager helped me” points I’ve gone over many times already in these posts. The only new thing I wanted to emphasize is Dan’s callout to psychological safety. I feel that at many places, Google included, that used to feel safe have had morale badly bruised by layoffs, especially in light of growing profits. It may be true that companies over-invested during the pandemic, and public companies have to prioritize stockholder value. Even if profits remained high, when the broader climate worsens, a company’s stock loses value if they’re not seen to be “tightening their belts”. This isn’t a treatise on mid-late stage capitalism, only noting that I couldn’t run the companies any better. Regardless, I don’t think Meta and Google in particular will ever be the same after the last 18 months. Yes, Meta has grown a lot, and will be paying higher bonuses this year (performance year 2023, paid Spring 2024), and I think there will be an undercurrent of survivor’s guilt through this. Psychological safety, like trust, is very hard to establish, very easy to destroy, and immensely harder to reestablish after torn down.
—
Joy Ebertz
Joy, at the time of her story, was a Senior Staff Engineer at Split.io, which provides a software solution for turnkey feature ramp up, experimentation, and analysis. She noted that she was still defining the specifics of her role, which does seem harrowing and exciting. I think I’ve had some combination of incorrect expectations and bad timing. I think I was given a lot of leeway (no pun intended) on my first team at Google, and just sort of stumbled around. I found out what pain points existed, but didn’t have success moving the needle on them. There were efforts under way and it felt like I wasn’t in a position to “muscle in” on those and take them over. I may not have agreed with some minutiae but stopping something going in the right direction because they aren’t taking the route I would seemed bad.
Joy noted she feels most impactful when setting a vision, and more importantly, seeing it through. Getting the input from stakeholders, establishing the vision, selling it, and taking ownership of seeing it through. Ownership was a major focus in this section. A major change when growing into a senior role is taking ownership of any issue plaguing your engineering organization, technical or otherwise. See something, say something isn’t sufficient.
The next interesting point was focus for change, and never making changes for their own sake. It can feel important to “make your mark”. I used to comment SOMETHING on every CL review. Its obnoxious. I don’t have to say something just to be seen. Joy also notes that pushing back publicly helps others feel empowered. I definitely think that being the squeaky wheel when it’s safe for you does help others realize that there are avenues to raise concerns or push back.
After this Joy discussed something that felt very poignant. When writing or designing, seek more feedback than you think you need, and document all false starts or negative decisions, not just the positive ones (I didn’t choose X because, or I did consider Y, but it had this flaw), and laying out your thought process. A good design without any of this informs how one thing is built. Something with robust feedback and responses, rationale, justifications for paths not taken, and a lot of process not just an end point can teach others how to reason and design better.
The “shine a light” discussion in this section is very similar to Dan’s, and my takeaways are similar, so skipping that even if it’s super important.
In discussing promotion to staff, Joy is very clear that where you are (the current company) strongly affects your access to opportunity, that you have to be prepared when an opportunity does come, and how critical being known and visible is so the right audience sees your behavior and can speak to it being at the next level. Joy herself was promoted as an engineer, but very soon after moving back from a management role, which allowed for a lot of her management experience and leadership to factor in to her promotion. She notes clearly that meandering through management helped her get there. Beyond that, starting consideration and planning for promotion way before you’re ready can help plot a course to follow and ensuring your work is aligned, rather than doing what YOU think matters. The last bit here that I loved was spending more time ensuring what you’re good at becomes something you’re great at, and known for, rather than trying desperately to make things you’re bad at things you are OK at. I have spent a lot of time on the latter. It definitely never helped.
The final impactful point in her narrative was that you will have to work with people that don’t gel with your style, and you can either try to insulate from that, minimize it, and just get through it OR you can lean into it, learn from each other, and cover each other’s weaknesses to make something better than the sum of its parts. I have had this experience, and while initially difficult, it grew me quite a bit.
—
Almost done! One more post! Maybe I can wrap it up this week! Thanks for reading.