Staying aligned with authority.

April 2, 2020. Filed under management 110staff-plus 8

It’s a common misconception that authority makes you powerful. Many folks aspiring towards more senior roles assume they’ll finally get to do things their way. They believe that the title inherently creates flexibility and autonomy. They believe that the friction holding them back will burst into a whirl of butterflies that scatter into the wind. The reality is a bit more nuanced.

Getting in the room.

March 28, 2020. Filed under management 110staff-plus 8

One of the most common frustrations I’ve heard from engineers is that they’re not in the room where important decisions are being made. They don’t understand the company decisions, and have important context that seems to be missing or ignored. Staff-plus engineers frequently cite access to “the room” as a major benefit of their level, and titles do increase the likelihood that you’ll be involved in decisions that impact you.

Learn to never be wrong.

March 21, 2020. Filed under staff-plus 8

Most folks have worked with someone who thinks they’re never wrong. In each discussion, they lean in, broaden their shoulders and breach their way into the role of the decider. They’ll continue debating until their perspective wins the day or time runs out. They are often right, but right in a way that sucks the oxygen out of the room. As their tenure at a company increases, they may fancy that they’ve become very persuasive, but frequently it’s a form of persuasion characterized by the resignation of their peers.

How do folks reach Staff Engineer?

March 19, 2020. Filed under staff-eng 4

At most technology companies, you'll reach Senior Software Engineer, the so-called career level, in five to eight years. At that point your path branches, and you have the opportunity to pursue engineering management or continue down the path of technical excellence to become a Staff Engineer.

Hotspotting developer productivity.

March 17, 2020. Filed under architecture 28productivity 1

Late last year I had coffee with Keith Adams, and we ended up chatting a bunch about migrations in the context of making it easier to extend an unruly codebase. The discussion went in a bunch of directions, including chatting a bit about Building Evolutionary Architecture. One idea that Keith mentioned in that discussion has particularly stuck with me: most changes happen in the same handful of files, and those files are the most effective place to invest into quality improvement.