blog link

A massive amount of my time is spent doing written work, research, and talking to people. I’ll have regular meetings with the teams and managers that build APIs. I’ll spend time breaking a long-term strategy into little chunks, doing research, and writing a proposal on that. Then I’ll have to market that proposal around the company. Less on writing code lately, but in other phases I’ll build demos or tooling to support the wider work. That coding work is still really enjoyable.

What a staff+ engineer’s work looks like? Keavy is a pretty typical case.

Coding? Sometimes, and it’s more like a enjoyable thing rather than high-return investment. I totally agree with the enjoying part, especially when you haven’t implement sth for a while.

Breaking strategy into smaller chunks? Always, When an engineer becomes staff+, how to scale the impact becomes one of the most important things (Assume they already have the required tech skill-sets). Breaking big things into smaller stuffs that others could understand and follow is a typical strategy. How tremendous the “big thing” is varies, depending on the level/company/org, of course.

Communication is another big portion: meetings, notes, proposals, retro, etc… So many day-to-day work depends on a solid communication skill. I’ve learned the importance of the communication from several leads, however I got a over-fitting problem here: Communication itself is not valuable, it’s more like a power tool to move things happen. Image you have a big hammer and you know how to use, but it doesn’t mean you could build a wall with it.

I present what I think is the best case for us, and people can disagree with that. And, you know, they often do. I’m steering and influencing more than saying, “I’ve got the authority to just tell you what to do.” I’ve never seen that style work well.

Another key thing about staff+ engineer. Becoming a staff+ engineer doesn’t mean they are always right. It’s more like a trust they could influence/steer people and move things forward, by driving the discussion/planning. Thus the answer to the question becomes more clear: “Are staff+ engineer more brilliant?” Probably, but that’s not the key thing. Of course, always proposing right things could build trust, but it’s not sth required.

The thing that springs to mind is to find your peers or support network. Just like management, it gets lonely the higher up you go and it’s important to find peers that will still challenge you and you can brainstorm ideas with. It doesn’t even matter if they’re in your similar area of work or even are in different companies.

this is really true. That’s why partner/peers are important: I have similar experience. If in a regular meeting, you found whatever you said/proposed, others just agrees with you, it’s a red flag that there isn’t enough partners in the meeting. Also it’s bad in long-term: No one could be always right in long-term.

Tags:

Updated: