As #staffeng, it's often too easy (and comfortable!) to fall into an endless cycle of working groups, design docs, architecture diagrams. IMO, this is dangerous and ineffective, as we steer away from the reality of our systems. Nothing beats getting our hands dirty.

I just stumbled on a great article about this, where diving into systems through debugging creates understanding, learn about inefficiencies, and a closer relationship with eng teams.

Read on: https://architectelevator.com/transformation/debugging-architect/

#debugging teams and orgs is a key skill a #staffeng / #staffplus levels. While it's more often associated with #engmanagement , IC tech leads should develop their skills in this area. It can help identifying systemic issues early on, and collaborate with EMs to resolve them.

More wisdom from The Staff Engineer's Path: when writing design docs,

"Wrong is better than vague."

If you are specific, a reviewer will immediately know if what you wrote is wrong, whereas if you are vague they wont be able to tell. It's also easier for people to review specifics rather than high-level ideas. This also is good to keep in mind when you are not sure yourself about which direction to take -- just pick one and your team will tell you if it's good or not.

#staffeng

The more I reflect on it, the more I think the reason I'm miserable is I'm being used as the "Right Hand" #StaffEng archetype, which is literally the only one of the 4 that I very much don't enjoy: https://staffeng.com/guides/staff-archetypes

I gravitate strongly towards being a Solver or Architect, and also enjoy being a Tech Lead when the situation calls for it. But being the Right Hand — especially to an executive — is just not a job I find joy in, and I miss the freedom of finding and driving my own initiatives

I can recommend the recent
Quality Bits Podcast for #QualityCoach, #StaffEng, and principal testers.

- how do you build skills in others
- how much hand on should you be as #StaffLevel #Tester

--
Bandwidth to Grow: Supporting Growth and Change with Maaret Pyhäjärvi @maaretp
https://www.buzzsprout.com/2037134/11705424

Upcoming projects: procuring getdx.com for our engineering org, embedding with dev teams to teach and help build SLOs, moving towards federated GraphQL by writing RFCs and disambiguating the path forward, finish our migration to GitHub actions, and exploring Crossplane. What about you? #staffeng #platform #infrastructure

other important #StaffEng tasks completed today include: picking a color scheme for some periscope reports

sometimes people wonder what staff engineers do. well, I feel like I staff engineered this afternoon:

I was vaguely aware that a recent change by Team A was putting some load on Team B's ElasticSearch cluster, and then today I overheard someone from Team A asking *Team C* about how to scale up ES.

So now someone's going to prepare a brief backgrounder, then the involved teams are going to meet, understand, and come up with a plan together in which scaling up is just one option!

#StaffEng

A test process is getting costlier to maintain: flakiness in tests, difficulty in recording mocks. Small changes can lead to hours of extra work

The whole point of testing is to save time by catching bugs early. At what point do difficult tests make the tests not worth it?

#staffeng

Rolled out a huge fundamental change to a complicated system yesterday, and surprisingly few things broke! I feel like I'm waiting for the other shoe to drop, but so far, it seems...okay?

#staffeng

Another nugget of wisdom from The Staff Engineer's Path: Don't get too attached to ideas just because you came up with them. Your idea may not be the best one. I fall into this trap often. #staffeng

https://www.oreilly.com/library/view/the-staff-engineers/9781098118723/

A year into life as a #staffeng and I find myself struggling with running planning/whiteboarding meetings. Feels like I’m either too forceful in directing the conversation (shuts down contributions), or too open ended (which lets things go off the rails a bit). Anyone have any tips for facilitating group discussions/planning?

@iarna Yep, I went through that exact phase at reddit before I started defining my own projects. It also took a while before I realized "oh yeah, this is actually okay and somewhat expected"

#staffeng

Senior engineers often ask me what projects they should do to get to the next level, and I always say "that's for you to figure out and execute on!".

This book points out that as you move up the engineering ladder your work becomes less defined and more self-directed.

#staffeng