Katie Sylor-Miller
Katie, as of the writing of her testimonial, worked in web performance at Etsy, and notes that performance is been recognized as business critical due to impacts on SEO, with subsequent impact on business performance.
She next discusses the “buckets” of more senior engineers. This is less detailed than some complex “archetype” systems that are discussed elsewhere. Her division is depth versus breadth, which she refers to as tech lead versus architect. I don’t think I’ve always been good at picking, which may have been limiting. I love knowing the heart and dark secrets of systems down to their deepest foundations. I also love enabling large projects and initiatives, and helping remove organizational barriers.
In terms of code, Katie notes she’s been writing SQL to perform data analysis, which I think is under acknowledged as an incredibly important skill in determining the next right step. I have struggled with data wrangling at Google, and would say I had the first significant breakthrough in data analysis two days ago. Finding usage of specific app versions, and how it relates to deprecating a legacy system, took a very long time. And the data dramatically disagrees between two sources. And a fairly core assumption (when feature was deprecated, usage in future versions would stop) was invalidated.
Katie next notes that she struggles to enunciate her impact. She does explain that she is very aware of reassessing priorities to make sure the right things are getting attention, but when it comes to a daily or weekly assessment of impact she doesn’t always know. I feel like many of the impactful things I do are “slow burn”. Inching culture closer to good, interjecting the right perspective early in a project, which may save a lot of time and avoid date slips, but aren’t easily measured. It sort of feels like hand-waving. In fact, I would say on a certain scale, it may be indistinguishable, which seems really hard for a manager to discern. I think actually quantifying time spent and intention/desired impact might be useful? Katie sort of echos some of this “small rocks into a big pond” seeming small, but having significant impact over time.
Her next anecdote is about ideating, providing a proof of concept, then allowing others to deliver on that (and acknowledging they did a better job than if she’d done it herself). I don’t think I’ve been as effective with this, but I think it was immaturity. I would think that I needed to take a prototype to production for it to “count”, and maybe at the time I did.
It came up earlier in the book, and Katie also mentioned that her discipline, Front-end, is often overlooked, viewed as simpler than others, and generally undervalued. I have definitely seen this attitude. I don’t think it’s universal, and often when an organization *knows* what the hardest problem is, they believe who is working on that has the hardest job and others are easier. In many big tech companies, the “norm” is believing that scalability of server-side components is going to be the live or die deliverable. Hence the belief that backend engineers and infrastructure folks are doing the “hard stuff”. In Prime Video, we didn’t have senior engineers dedicated to clients, but you needed senior engineer feedback to get promoted there. This often led to client engineers moving to backend systems to show their chops and get the recommendation they needed (and sometimes never returning to the client side). I do think we need to do better at establishing some mutual understanding and respect. Having named disciplines is a useful step. Showing equal skill but specialization, versus one big bucket, at least lets someone be compared to a role guideline that fits their skill set. Front end, ML, Data, and other engineering disciplines having explicit naming and titles can go far. If a “generalist” engineer is great at data design, modeling, transformation, quality, and designing effective data systems, but doesn’t commit and client or server code, how are they judged against a “standard” rubric? I appreciate progress, but hope we can continue pushing for fair recognition across expertise.
Like me, Katie is full-remote. It was nice to see this from her and a few others in the book. I definitely try to leverage 1:1s, but not as well as I think I once did. I have felt like deliverables trump relationship building now, but hope I can balance both. Another point Katie surfaced was relationships with managers, not only engineers, to be able to better partner and drive outcomes. Again, I feel like in other contexts I viewed myself as a peer to managers, and worked with them on technical challenges or sticky people performance issues with a really high level of trust. I think this is a TODO for me now, but feel like the trust isn’t strong enough yet.
Another activity I love is organizing larger scale events for engineers to collaborate, share, and generally get better together. Some of my favorite have been show and tells to push people to share technical wins that may not be “demo-able” to product friends, or broader audiences. Getting recognition from other engineers for technical achievements, even if the product impact is a work in progress, can be powerful. I also try to “push down” some of the visibility and organization effort… launching and effort, then passing ownership to someone that needs to be seen. If it’s a type of time-limited event like a book club, passing down complete ownership of that as a “program” to others means new sessions are created and executed without me having to touch it, with is some of my favorite impact opportunities. If you have to turn the crank, the machine stops when you’re gone. Katie also mentions using her Product Engineering Confab to give opportunities for visibility to others, that led to positive points in promotion cases. I have seen a lot of engineers that have the right scope and tech chops to move from entry to mid or mid to senior, but don’t have the leadership or broader impact on people. Using things like postmortem reviews, book club leadership, and other such activities can help fill some of these gaps.
I really identified with Katie calling out that a big part of staff+ leadership is not ignoring problems. I feel like I’ve had to do this more than I’m comfortable with in my recent roles when I was better about this at Amazon. I can harness a single-mindedness that can allow for tracking down and fixing things that may appear too complicated to others. She again references that this can be “hidden impact”, and surfacing it is key.
That last standout was something that was also mentioned by others: reputation and social/political capital. Getting to a staff+ role can’t happen if you’re unknown, have a poor reputation, or are difficult to work with. It’s not a “brilliant loner” role, and that can be difficult for people that have thrived being able to make the heavy lifts alone. I have tried to help “socialize” some of these folks, starting with communication and soft influence. One negative interaction can taint a relationship and be very hard to repair.
—
Ritu Vincent
Ritu describes her recent (as of her testimonial) boomerang to Dropbox as a Staff Engineer to pursue an opportunity to launch an incubator to drive innovation as Dropbox’s core business is being encroached upon by other companies. She also notes she was “getting itchy to code again” after managing for a few years. I definitely felt that draw after 3 years as a people manager. It is a strange dichotomy, though, because the biggest area I have struggled in is coding *enough*. I think that the drive was to have access to coding tasks, be able to write a PoC, and so on. Raw throughput on low impact, dissimilar tasks is definitely not very high. Maybe this is a problem I have and poor perspective, but when I am working on a small task I have trouble focusing on that, and instead look at scaling impact. Oh, this is hard to read… what would make it easier? Like, this API only takes seconds? Should there be adapters for other units? Or something that will use existing TimeUnits to build the second value? Is the API poor and can it be changed to take a duration value that is more easily created from other units? This is often pretty distracting, but I have felt like it’s good distraction, as long as it’s time-boxed. I try to surface ideas, back burner them, finish the task, and maybe come back later.
Ritu echoes some of the other engineers in her description of the main bifurcation in Staff+ behaviors at Dropbox: the tech lead that brings efforts together, and a specialist that is doing deep work.
Ritu discusses some organizational growth and culture issues which I also value. Interviewing, and improving the process, as well as diversity work. She mentions designing specialty interview loops, and as a Bar Raiser at Amazon, stumbling on a new, poorly-defined role or profile, and working on defining what needs to be assessed before guidelines were formalized, was very rewarding. Later in the testimonial Ritu discusses the amount of exposure that interviewing and moderating debriefs gives you to engineers and engineering leadership. This was another aspect I really liked, and made good friends with folks I met on interview loops, including recruiters, other engineers, managers, and so on.
In her approach to growing people, Ritu talks about coaching toward decisions rather than forcing a perspective, giving stretch opportunities, and helping people figure out the right path. I’ve worked with a lot of folk considering a role change, and helping to get them information about what life in a different role would be like, and coaching them through prep and internal interviews to make that change, was something I really enjoyed. Seeing people grow and achieve their goals was a lot more satisfying than doing things on my own.
The last few items that stood out to me feel closely linked. Ritu discusses being able to safely fail, and the importance of being able to try things you aren’t sure you’ll succeed at free of fear. She later mentions that a key to a close relationship with one’s manager is openness and honesty. I think that if there isn’t safety to fail, being honest with your manager can be a lot harder. I think I had created such a robust internal network at Amazon, and had such a strong track record, that I had created my own confidence and safety. I just haven’t gotten there yet in my jobs since. I have faith it’s possible, and need time in one place to build that.
—
Rick Boone
Rick works as a strategic advisor to a technical VP. The focus of this role is on the technology in use, the cultural strategy and special projects in order to extend the technical reach of the executive being supported, while giving them a feedback loop to increase the fidelity of their decisions. To be effective, Rick must stay very closely aligned with their VP to ensure any outward messaging is accurate, and appropriate and relevant context is gathered. This requires constant connection and a very high level of trust. I’ve had a few working relationships like this, but I’ve never really acted in this role. I think it could be a good fit for my style, but I might feel constrained not actually being the decision maker.
A significant part of this is gauging how engineers are feeling to help prioritize technical or cultural problems in order to minimize pain points to accelerate engineers’ progress. This is a passion for me, too, but one I’ve struggled to stay connected to in my last few roles.
One area that comes up throughout these stories is coding for connection, but not always for significant deliverables. Rick stays off the critical path when coding so nothing is blocked by low-focus coding commitment. This makes a lot more sense to me. I have felt pigeonholed to lower impact, but deadline-driven coding tasks, which feels like the opposite of what I think might fit best.
Rick mentions another bit that I am also passionate about, which is being visible to other minority engineers, and lifting those people up. My “minority” status is specifically neurological, and I still try to prioritize leveling the playing field and providing fair opportunities to excel to all sorts of less-representative folk in tech.
Rick goes on to discuss how much focus they put on visibility in moving culture. I have really tried to champion culture, trying to quickly correct negative cultural influences, and maintain (until they self-sustain) practices that measure and improve engineer experience.
The last point that stood out to me was Rick noting they’ve never been a “pure engineer” who is “in the core 24/7”. This spoke to me. If I was only relying only on coding (or design, to be fair, which I might be better at?) I think I would be… below average, at least in terms of output. I go slow, often to learn and identify improvements. If I wasn’t doing that, and didn’t think about engineer experience, and didn’t think about sustainability… I still wouldn’t be the fastest coder. What has (at least in past roles) made me “stand out” was all of the other stuff. Reconciling cross team conflict, identifying touch points to enumerate and fake early to unblock projects, unwind complexities of designs or projects, and so on. These are where I feel like I can make a difference where others may not. If I’m NOT doing those, I feel like I’m like… bottom half or worse of other engineers. I definitely can’t bang out bugs or features as quickly as peers who are intimately familiar with the area. Maybe if I was able to get that familiar I could get close, but don’t know if that’s the right investment for maximum impact. I am questioning if I actually have any idea how to have maximum impact anymore.
—
Nelson Elhage
At the time of writing, Nelson had recently left Stripe, where he worked prior to leveling was enacted, but he would have been classed into Staff once titles were introduced.
Like a number of others, Nelson describes different archetypes of Staff archetypes. Many of the prior engineers stuck to “specialist” vs. “lead”, but Nelson also describes an embedded engineer in a team that helps keep and drive its vision. He doesn’t say so explicitly, but this is likely a strategic team, or important small group of teams, that needs to mature due to criticality of their work and possibly fast growth. Having a Staff+ engineer shepherd this, help maintain focus, and aligning toward a vision can enable growth without dilution of focus or understanding. This is a big risk in my experience. A team has some new initiative or has become more critical, so they hire a lot of people. If there isn’t a central figure that is corralling this, and making sure that everyone is going the same direction, adding people can be expensive and counterproductive (I still believe in trickle hiring to reach a headcount goal, rather than flash hiring and outnumbering existing staff with new folk, making onboarding, mentorship, etc difficult).
A large project of Nelson’s was Sorbet, a type-checking system for Ruby. Nelson described a very important part of tooling work that can be missed: two-way advocacy. You need to be a good salesperson of the tools you’ve decided to build (based on data!), because no matter how amazing a tool is, if no one uses it because of confusion or high bar for entry, nothing has been achieved. The other direction is gathering actual needs and pain points from your target population, and advocating for building the right thing to serve their needs. For Nelson the potential users of the tool were the entire developer base, which meant driving significant alignment. Nelson described building the muscle to do this advocacy by establishing broad knowledge, and expanding that as the product and engineering organization grew. Synthesizing all of that, and being able to rapidly evolve your own understanding, is really critical in my experience. Your model of your systems and of your teams matters a lot when you need to sell changes, or align multiple teams on fundamental changes.
The last big focus in Nelson’s story is about relationships. He discusses the criticality of establishing trusting relationships broadly, and how huge an impact leveraging these relationships can be when assessing needs and introducing change. Further, when you have these connections it simplifies the glue work or “routing” as Nelson calls it, because instead of you needing to connect to each point of contact, then aligning them with one another, you already know the people and their working style, and can skip to alignment with existing context, which is powerful.
—
Whew. These are a lot denser than I expected. I truly approached the stories (in terms of my original plan for breaking up posts) based on page length. It did not go well. There are six stories left, which I’ll break into two more posts. Maybe this rescope will get them done a little faster. Fingers crossed. Enjoy!