A link collection of books recommended by engineering leaders from a question I posted on twitter. There are a number of new books for me on that list as well, but interesting to see what people are reading and what they learned from it.

I found this article a good contrast to one that a recent article I published called “Reasons to step into a leadership role (and the reasons not to).” As I would expect from Charity Majors’ (@mipsytipsy), this article does not hold back and makes for a fun read.

Marc Brooker (@MarcJBrooker) explains a common failure mode he observes with engineers in reading research papers. They immediately go for “What’s wrong,” or “What’s not working.” Although this is in the context of reading research papers, I see this consistently in engineers in general conversation. This limits their leadership potential, which is why I’m including it in this section. If you know you fall into this trap, watch yourself carefull, or ask for people to call you out on it. T

I watched this short presentation recently from Agile Coach, Nancy Evbuomwan (@nancy_evbuomwan), and I really liked the way she explores the role of leadership in an agile environment. I also like the focus on practice, a strong reminder that everyone can build leadership skills.

A long but solid read from Paulo Merson that highlights a nice acronym to guide microservice design. The “IDEALS” of Microservice design include interface segregation, deployability , event-driven, availability over consistency, loose-coupling, and single responsibility.

This article reported by Monica Chin (@mcsquared96) is an amazing story of abusing AI systems. It’s also one I expect to see more and more as AI continues to expand its influence into everyday systems and one we should all be cautious of as people building them.

Medi Madelen Gwosdz explores a really interesting question in this article. In this, she looks at a brief history of OOP, what it brings and ponders some of the potentials answers to this. I’ve found that OOP, used well, certainly encourages high cohesion and low coupling, both which contribute to better designed systems.

I love the perspective that Ross Pettit (@rjpettit) brings to technology, always strongly rooted in pragmatic commercial and business contexts. As technology leaders, this perspective is one of the least exercised and one to read if you’re working in a long-lived organisation with older systems thinking about “legacy moderization”.

I think it was earlier this year, Basecamp published their product dev approach, calling it “Shape Up.” I remember seeing claims like, “We do development without agile” (Editor: But it certainly fits with the agile spirit“. In this article, Nolan Phillips (@ncphi) shares how his team at TinaCMS went implementing this product development approach.

One reason I find people’s focus on titles annoying is that they rarely make a lot of sense in many different settings. You see this a lot in start up land where a Director or VP may simple be a “Team Lead” in a different place. Vinod Kumaar R (@vinodkumaar) explores why title inflation is bad for everyone.

A key to leadership is ensuring team members pull in the same direction. This is sometimes really hard to do with technical decisions when engineers dig their heels in for a particular solution. In this article, Mario Fernandez (@sirech) shares a simple approach on how to align developers with a Dev Huddle.

Aaron Randall (@AaronJRandall) and Amy Phillips (@amyjph), hosts of the Human+Tech 🎙podcast (listen to it!) share some great advice about what to consider when building a team, but also offer 3 great questions to test if you need to build a team (a mistake I have seen at too many companies).