POSTED: 14 Sep 2021
TAGGED: #conference #career

Leaddev and StaffPlus event

I recently virtually attended the leaddev virtual conference, on the track StaffPlus, where the theme was all about the individual contributor paths in organisations, and around the question "what's my job?". Also, "what has worked until now will not work for the next steps".

Before dumping my notes on almost all the talks, I would say that it was a very interesting event. Lots of valuable info and actionable actions for people who want to climb the corporate ladder without going down the management path.

And without further ado, massive note dump (for future self and perhaps a few colleagues) !

Role and Influence: The IC trajectory beyond Staff

From Yonathan Zunger from the 140chr blue bird company.

The ladder

How nature of work & influence change as you climb the corporate ladder.

Jr/Sr engineer: execute a task with/without supervision.
Staff: go from description of the task to execution.
Senior Staff: Go from well defined problem area to the tasks.
Principal: understand an area and manage it.
Distinguished+: find the problems and fix them. more fuzzy there around job title across corps.
Junior grades: The how
Senior grades: The what

As you go higher, meaning of IC gets fuzzier. People are more&more part of the system, team, stakeholders, users&co. Systems stops being only machinery. So it becomes more about identifying problems and working with others to solve them.

Staff vs Senior staff: lead a dependant team, part of a bigger one vs independant team, which has its own customer, and more autonomy (and questions). Principal: construct teams and understand business aspects. Distinguished: drive strategy. Nothing is out of scope.

The four disciplines

for any job:

core tech skill
product management: what needs to be done and why.
project management: what needs to happens, and making it happens. herd cats.
ppl management: finding the right ppl and turning them into a team + career management.

Think of the combo between core tech skill + one of the three other => powerful combination, and very useful.

None of that has anything to do with the business card. The role title is merely a hint about where you spend the most time. Most ppl excel at 1 or 2, are okay to 1 or 2, and try to avoid 1 or 2 of them.

Every team needs all four types of leadership. So usually need more than one leader (unless you bootstrap something on your own) to help complement.

The fifth discipline

Being the adult supervision. With experience comes good sense. The "hooold up a second" in discussions.

What makes good adult supervision?

experience matters. You've seen this before.
engineers are split about product engineering (how thing should work) and safety engineering (how things might fail). Experience makes you more conscious of the latter.

How do you learn that?

Mostly at big companies, where risk matters. For startups, it's almost always better to ignore risk since there's nothing to lose. At big companies, it's different.
Maintain systems over time
From diversity of experience
From understanding more about ppl. It's one of the core skill you build during career. Mastery of technique is achievable, mastery of human isn't.

What is senior IC? Flavours of technical leadership.

Panel, check the link at the top of the page for the details.

Senior & beyond, what qualities?

Asking why. Get more context to solve the real problem.
Empower others. Teaching arch skills, guiding principles so ppl can make great decision on their own. Coach & mentor. Build engineering culture. Onboarding. Force multiplier.
Difference between senior eng to beyond: frame every problem in term of "solving a business need" and go beyond the tech. Ppl are part of the system.
Taking a wider perspective, and how to solve things longer term. Removing yourself from the actual solution, maybe it's about bringing other teams.

Staff eng role is a mixture of things. How to deal with the ambiguity?

Ambiguity can be a way to express creativity.
Ambiguity isn't necessarily a constant of the role, and would be nice to have corp to reduce that. Perhaps it's more variance in the role.
What can I do vs what I should do? The first "can do" can be solved by the org, the second is part of the role.

How do you approach leadership without authority?

Ask a lot of questions. Ppl have different context, and go from that understanding.
Not many direct reports, but influence many engineers. Long term writing + presentations and create alignment behind a shared vision.
Spend lots of time, when disagreement, into incentives. What are the incentives in places, and get leadership through manipulating/changing these incentives. Figure out the real incentives through 1-1 chats with ppl doing the work, can get honest reviews because you're not the one doing the perf review.
Similar to incentives, understand who cares about what, and adapt communication & format depending on that.
Sponsorship, having a very senior ppl to lend privilege & authority to bootstrap can be helpful.
Tension between local vs global opti. Suprinsingly effective tactic is to go for a local opti, without going for the global approach first. Can create fragmentations, that can be reduced, maybe not reduced to one true approach, but a few manageable ones. Careful since org move slowly, and fragmentation can go out of control. This advice (and every other) is highly contextual, especially on the size of the corp.

any tricks for that?

Straight up asking ppl: "what do you care about most?", "what keeps you up at night?"
Try to make things as data driven as possible, to remove all form of ambiguity.
Is the conversation/person I'm talking to emotional or rational?

How to be a force multiplier?

Without ivory tower, create golden paths. Create templates and bases to allow ppl to build upon. Can also help with standardisation. Enable ppl to focus on business value with best practices.
Teach ppl to fish becomes your primary job, even if it's slower. Switch away from being a fixer to being a teacher. There can be a tension between short/long term impact, especially during prod incident for example. Focus on fixing custom impact first, and then you can take a slower approach for the longer term fix.

How to balance solving technical vs social problems (and do you care about balancing)?

Depends heavily on the rest of the corp structure. Can push a lot to competent eng manager.
Focus on building the right thing. This is rarely a purely technical question. Who should build what, gather and spread the context.
It's a spectrum, and it can swing from one side to the other. If it's fully social problem, it's usually a gap in leadership, can step in but need to escalate. Can escalate & help understanding the issue, and then it's not my problem anymore.

Bonus question: why long-form writing isn't more popular?

Cultural problem: not valued enough. Need to write things to scale yourself. Need to help the org to have a written form for contexts.
Two parts: the act of writing help organising your thoughts. The second bit is about rapidly and asynchronously getting alignment.
Need to also record decisions that did NOT happened.

Luminary interview with Diane Tang (google fellow)

What is a google fellow?

VP equilavent of IC
Which problems needs to be tackled? Usually spanned multiple org (within google). Who should be working on the problem. What are the best approaches. Work across org boundaries about solving the tech problems.
Definitely a leadership role, carries an aura.

How much do you spend hands on/write code?

Haven't written code in a few years. Work more at the archi level.
Gets a lot more in-depth on the data science analysis itself.
Real challenge is about how to correctly frame the question & the goals.

Difference between manager and IC?

Currently manage ~250ppl, but consider herself more like an IC.
Coach & mentor, set standard. Doesn't always set a superstrong vision. Depends a lot on the teams.
In team where she's more an IC, get more involved with vision, standard&co
Spend less than third of time in the teams that reports to her. It's a lot more about influencing other teams.

Influence without authority

Tech expertise confers some form of authority.
Understanding that her goal is neutral, and has google's interest first. Less political, or org bias.
Creating the space & conversation creates the influence, give the very big picture around interface and how things will work together.

How do you learn these skills?

A lot is about practice & being in these situations.
Asking questions is an underrated skill, and is one of the most important.
Active listening. Synthesise info on the fly and summarise+recap, that also shift the conversation. This can also be done async, in written doc&co

What are other important skills?

Being really blunt and honest. Call things like it is, and be vulnerable (no idea how to do X), tends to create trust. Clear about what the situation is, and ennounce it clearly and concisely.
Being able to blend and navigate different level of details and granularity of details.

What's next (18y at google)?

No idea. Who I get to work with? What's the problem?

Live long and prosper as a senior IC (staff engineer at squarespace)

By Alice Li from squarespace.

Talk very product focused (I found it a bit meh).

Having to make tech decision and advocating for them.
Not exactly managers, but responsability as force multiplier.
Senior IC: horizontal influence vs manager track with vertical influence (n+k levels). IC+ are cross functionalities usually.
3 types of levels: company, developers and users. Ideally, can ensure all 3 categories have their needs met.
- company: moar money
- developers: DX
- users: UX
Note: Halo effects not taken into account enough in business decisions.
Should focus on users, since ultimately they are the main driver for corps.
How to determine areas where there's the most impact to get? Go back to the end user experience.

The delegation equation

By Leslie Chapman from Comcast.

Loves to write code initially. But need to let go and delegate to climb the corp ladder.
Cross team collaboration, publications, process improvements, architectures.
Give other ppl the time & space to shine & "prove their worth".
Cannot simply shove new features to other team members and then tear them appart during code review. Doesn't work because they don't have the wealth of experience and knowledge about the codebase & the context.
Tech grooming: brain dump about how to do things, caveats and stuff. How to teach more senior to teach and improve other ppl.
Then swamped in meetings + excel + github api scripts. Can also delegate these things. View that as opportunity to give more context and exposure to the team. Although need to onboard.
Problem: imposter syndromes kicks in, am I fully repleacable? The value you bring is being a mentor, teacher, bridge builder and delegator.

Luminary interview with Lea Kissner

Head of privacy engineer at Twitter.

Solve zoom privacy issue

Make everybody to take a deep breath. Ppl getting stressed makes more mistake and worst decision. Need to give ppl heads up for preparation.
Superpower: being calm
Always looking for: "what actually makes a difference?". "that's on fire" vs "how to be in a place where it won't be on fire". Where do I want to be in 3, or 5 years, in incident retro. Avoid repeating work.
Access control, good for privacy & security, but also to trace prod dependencies and keep outages at bay. Tie the security aspect to "system runs correctly" aspect.

How to find the right ppl in the org?

(fairly weird approach): swap the entire world into you head (careful, brings inconsistency).
"What is it you worry about". ppl knows where are the burried bodies in the systems. And keep track of them.
Think of threat modelling in a very human centric approach. It's much harder though, because humans change (rapidly sometimes).

How do you get buy-in for proposals?

Talking to human is a job skill. Being able to talk math & english is super valuable for eg.
Great product is respectful product. Here are the things standing in your way, and I can help you remove that.
Translate things into language that ppl speak. Give ppl the tools to compare things from different domains: tech issues and business risk.
Framing risks as "here's what the headline will be"
"This is important", this is something I can help at. Even if it's not code.

Tricks for promotion:

Don't under-represent what you did.
Be the worst jerk you be, and oversell yourself. Send that copy to someone who know your work and you trust, to help about the other copy for promotion. Helps not under-representing yourself.

Setting up a cross-team project for success

Panel

Set the stage, share an example of a project

At dropbox, db + storage system (500PB of data). Migrating from MySQL to edge store (in-house distributed db). Wanted to finish a project and get it over the line. Get buy-in and excitement from 73 eng over 15 teams. Key success: get two other principal eng on board.
Hyperplane (at aws): distributed/embedded system which powers some stuff like nat gateway and load balancer. Starting small, then worked with tens of teams to integrate the hardware. Biggest challenge: everybody has their own priorities. Lots of status meeting & 1-1.
Infra migration project. 14 to 15 ppl involved with many teams. Prioritization really fleshed out before the beginning of the project.
At Financial Times, reamiganing the content platform. Had fingers in every parts of the business. Span several partner companies over 5 years.

What structure & cadences used to keep projects on track?

Instead of having regular meetings, have parties. Celebrate the metrics to track progress. Also tied to engineering KR.
kick-off + close-off meeting are important. Kick-off solidifies who are to be involved, what are the goals and so on. Flexible status update for lead engineer to choose how they want to communicate that => creates empowerement. Make the work more visible for everyone helps reduce the need of meetings and statuses update.

Let's talk stakeholders. Example of communications with them.

Send quick 1-line emails to stakeholders for metrics between milestones. Working really hard upfront can get some help to manage the project (get additional headcount). Can also be done after project started.
Connect contributors with customer asap, to get feedback and help them build the right thing. Try to eliminate bureaucracy around the feedback loop. When ppl know the right person to ask, they will do the right thing. Can use the kickoff meeting to make introductions and connections between ppl.
Breaking down the project into milestones is helpful for management and yearly/long term planning.

How do you build relationship with other teams?

and get buy-in and prioritization?

Everyone has a story to tell, start from that + empathy. Usually informal 1-1 with many ppl way before it reaches the OKR phase or any work has started.
Approach everybody with the mindset of "we're on the same team". Avoid framing of conflict or winning. Initial connection is important, and helps a lot afteward.
Listen a lot more than you talk. More effective than convincing.
Find opportunities to connect with ppl. "Hey, I like what you said at the postmortem can we chat a bit…"

How to manage interdependences between teams?

Give ppl/teams as many carrots as possible to ease the transition/delivery.
Make sure every team knows the Why, the general What, and then let them organise by themselves.
Get to know more the roadmaps and long term objectives for the other teams and see how your project can fit in.
Company level, high vis projects are hard to move/change.
Biggest problem: other team can't get the time to help, becomes bottleneck. At that point, you need to get them help to ease their burden so they can help you.
Think about dependencies very early on to avoid something abrupt arriving at the 11th hour.

Share one big idea/concept helping you to get into staff+ roles.

"how to start a movement" by derek sivers. Inspiring talk.
author: ari-weinzweig book anachist around project???? a list
Team topologies

Technical strategy power chords

By Patrick Shields at Stripe

Power chords are simple shape, but very powerful, can write a lot of interesting stuff with that.
They unlock the power of music for beginners.
How to create clarity and confidence for tech strategy. Work on epic, or multi-year goal. Framework and little bits of advices to help.

Pick one (and only one) goal

For example, specific and focused on one outcome.
- lower error rates during deploy to less than 1%
- run db migrations
- increase event processor throughput to n events per second
Do not combine multiple goals together. They may contradict themselves, or create unecessary burdens.
The approach is multifaceted but the outcome is not. Some approaches are impossible but inform the final goal.
Can add some non-obvious constraints that needs to be communicated bc profound impact on the project.

List the facts that would change your mind

No need to name any outlandish black swan.
For example:
- tight deadlines and SLA
- timeliness guarantees and delay sensitivity
- some form of capacity cap
Solve only the hard prolbmes you absolutely need to:
- You can change the problem slightly to make things easier. For example, degrade a bit and keep the user XP ok instead of increasing reliability.

Work backward

Need the end state, but also the steps that lead to that from the starting point.
Specify the near-term states.
Don't overspecify the end state.

Start small

Big strategy is hard and time consumming.
Can apply these techniques and practice on smaller scale projects & epics.

To kill it with fire or not

by Laura Nolan from Slack.

X is painful to run/operate, full of tech debt… Many many reasons.
Case study: Sisyphus deprecation. deprecation failed to gain momentum. Lots of custom python plugin that cannot be migrated automatically. Many external dependencies outside of the control of the owning team.
What helps: proper staffing from the onset.
Modernisation in place: not a lot of work for end users, can be opt-in and turned down.

As getting more senior: how to make difficult choices.

Ask a question, gather relevant facts and perspectives, articulate your principles, consider how problems may be mitigated, make the decision.

Asking the question is the easiest steps

Then, gather relevant facts. That takes more efforts.

what are the motivations to change
alternative systems?
team capacity <- very important. It's difficult to keep the old thing up and running while creating the new solution.
capacity of the whole org to be treated the same as the team's capacity. Especially when migration requires work from other teams.
impact on users.
risk of migration.

Articulate your principles, your values

For example:

team workload should be sustainable
system should not be toilsome
users should not be impacted
an org should limit tech churn and risk
Some principles may conflicts, or points at conflicting goals. Need prioritization

Consider mitigations

prototyping or proof of concepts
additional staffing
tooling to automate migration process or toil of existing system
careful planning of migrations to reduce risks.

Make the decision

Write it down, clearly document the rationale (and all the points above).
Can revisit when the facts or the principles change

Finally: don't understimate how long migrations and turndowns take, and how costly they are.

Navigating the manager <> senior IC relationship