jtr has a project where he occasionally interviews people to collect the history of SRE at Google. As you might imagine, most of it is very Goog-specific -- how they did onboarding in 2005 (less well), what the shuttles were like in Mountain View in 2006 (weird) -- but he ended on a couple of general questions about advice for engineers. I don't claim any special wisdom, but here's what I said, lightly edited. Consider it my version of the sunscreen song :-)
Any guidance for more junior engineers?
- Admit when you don't know something. Not knowing things is amazing: you get to learn.
- Do things that are a bit harder than you think you can do. All of this is learnable. Ask for projects that are hard. Own the projects. Finish things.
- Write one-pagers for ideas you have. Generate artifacts of your work. Be brave and CC mailing lists; don't just mail individuals.
- Some great advice Kate gave me more than a decade ago: keep a log of what you do. It's nice to look back and see a little trail of achievements behind you, and it helps you keep track of where you're spending time. Turn the log into snippets. (Snippets are weekly summaries of your work. I love them.) Turn snippets into your self assessment at performance review time.
- Don't become a manager unless you want to be a manager. I've often heard people at Google say "I'm going to stop being an engineer and become a manager because I’m not Jeff Dean". But you don't have to be. First off, maybe compare yourself to someone who's a little closer to your level? Second, nobody seems to be saying "I can't be a manager because I'm not Sundar Pichai", and I don't know why engineering feels different. And third, if you become a manager, you're going to need to spend a bunch of time learning to be a manager. It's not free. If you choose to, you can put the same time into learning whatever tech skills you feel you're missing.
- It takes time to learn, but it takes more time to not know things. Block out make time for learning, take your laptop to a conference room and learn the thing. Online courses solidify your understanding and they're a huge confidence boost (and they're often really fun). Spending time on learning can be hard because it doesn't feel like you achieved something with your time, and tweaking the configuration or whatever feels more immediately rewarding, but learning will make you do better work. Prioritise it.
- Don't solve problems with software that should be solved with talking. (Unless you're having trouble being promoted because you're somewhere that only rewards code. In that case, do what you have to do, but get out of there as soon as you can.) Software is easier than people, but solutions that involve getting humans talking to each other are more likely to solve the real underlying problem.
Any guidance for more senior engineers?
- Also admit that you don't know things! Set the culture of learning and discovery and humility and make it safe for more junior people to show weakness.
- Forget what it says on your OKRs: your first responsibility is turning junior engineers into senior engineers. You get to be a 10X engineer by making everyone around you more effective. Find opportunities to make people grow: this means giving away your Legos, which can be scary, but when great people you trust are getting the stuff done, you get to look at a broader picture. Give people work to do that's harder than you think they can do, support them through it, and be reassuring if they screw up. Tell them the story of the time you screwed up. (If you're a senior engineer and you claim you've never screwed up, I don't believe you.)
- Point out the good as well as the bad. Explicitly say LGTM on design docs; don't just point out the nits and move on. Send peer bonuses. Call out good work in meetings. The approval of senior engineers is a confidence booster and secure people do better work. See above re: 10x.
- Notice who around you is underleveled and figure out why and fix it. Notice who is good but scared, or has been undermined and now has no belief in their technical abilities. Fix that too.
- Read Lara Hogan's post about sponsorship. Read her other posts about technical leadership, for example "manager energy drain". She's talking about management, but all of this applies to senior engineers and tech leads. And watch this talk by Corey Quinn. (It's only 27m long and very funny. It's a great use of your time, I promise.)