If you’ve been following Will Larson (@lethain) since his book on engineering management, you might have heard about his new project interviewing “Staff+” roles. The result is a book that explores the IC/Technical Leader track or those technical leaders who don’t manage people. Congratulations on the launch 🎉

People working in tech often have more choice about their next role or job in comparison to other industries. Leah Farmer (@leahlialeigha) shares a great article about making the most of this privilege by considering more than simply the job title and salary.

You might consider this post from Adam C. Conrad as a set of book recommendations, but he adds a lot of valuable context about which book might offer the most value depending on what stage you’re at, drawing on US-centric terms like freshmen and sophomore, etc to group them.

Daniel Watts (@dan_badge) offers advice to technical leaders responsible for software architecture. I’ve seen these 7 behaviours and have fallen for a couple of them myself in the past (learned the hard way) so use this list to avoid these traps.

You may be familiar with the ThoughtWorks Tech Radar, with a focus on techniques, tools, platforms, languages and frameworks. This latest report from ThoughtWorks (disclaimer, I’m an alum) looks at tech trends but with a broader perspective. Although targeted at executives, all technical leaders should take interest in trends, their impact on the work we do, and also the lives we have.

I feel we’ve been talking a lot about team cognitive load, thanks to Team Topologies but I like how David Whitney (@david_whitney) also approaches the idea of good code by considering individual cognitive load, and common approaches on how to reduce it. 👏

This article from Mozilla engineer Gian-Carlo Pascutto (@gcpascutto) offers great insight into all the details that go on “under the hood” to make something like Firefox continue working as its foundations constantly shift. If your product relies on low-level hardware, the article shows which areas to focus on in preparing for a migration to Apple’s M1 chips.

Giving tough feedback can be really hard. You may have avoided doing it because you were scared. These simple steps from Said Ketchman (@introvertedeng) should help you get more comfortable.

Most people only focus on the initial cost of building software, or the time taken for developers to build the system. A lot of people underestimate the carrying cost, which is why I like this concept from Eduardo Ferro Aldama (@eferro), as a way of trying to consider the overall lifetime cost of a feature.

Leaders require great communication skills. Company norms sometimes nudge habits in the wrong direction. This is a great post from Josh Bernoff (@jbernoff) to improve how you and your team communicate. Show good examples and nudge company norms in a better direction.

A lot of developers complain about not writing enough code. Little do they realise a majority of their time isn’t about writing, but about reading and building strong mental models about the system they are about to change. This article from Tudor Girba (@girba) explains why.