Software Lead Weekly

Ten Principles for Growth as an Engineer
4 minutes read.

Dan Heller with a post every Engineering Manager should read before entering the 1:1 with a their teammates. I tried picking the parts I like most. It's impossible, it's all so good. This post is now part of my "must-read" list for new employees so that they could increase their impact and leverage in the organization.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

“I'm Just Going to Fix This Lil' Bug in the Legacy Codebase Real Quick...”
1 minutes read.

My humble effort to help you start the weekend with a smile on your face.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

Product vs. Feature Teams
8 minutes read.

Marty Cagan with a post I think all software companies should read and measure their organization against (outcome > output): “The purpose of a product team in this sense is to solve problems in ways our customers love, yet work for our business. […] Much more often than not, the teams are not empowered at all. In contrast, they are there to serve the business. [...] In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility. The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us.” -- I also highly recommend reading the follow-up article (link at the end of the article), as it covers relevant FAQ people brought up.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

Small Wins
3 minutes read.

"Every so often, I begin to forget to celebrate the small wins. The satisfaction of incremental progress becomes no longer good enough, as though something was only worth celebrating and sharing if it was life-changing. [...] Celebrate your progress, no matter how small. Don't rob yourself of the collective joy of each of those wins. Enjoy the ride." -- I really needed these words by David Hemphill. Optimize for happy, and sustainable impact will follow.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

Most Roadmaps Are Setting Up Their Product Teams to Fail. That's Because, Even Today, Most Roadmaps Still Follow the Dreaded *Timeline Roadmap* Format 😱 (Thread)
3 minutes read.

Janna Bastow with a framework I see being more common today, used by new startups (and a lot of Indie Hackers). The goal is to change the language and visual people use: from the output (features) to the outcome (KPIs), a clear understanding of what to measure, etc. The thread is interesting to follow as there are many subtilities involved, for example - how much to focus on future planning ("lean" or not, KPI-driven or not) vs. focus on this quarter only.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

Developers Are System Changers
2 minutes read.

Jessica Joy Kerr with framing I found helpful. There is a strong set of tools (#nocode) that allows non-developers to connect systems and automate their work. If you look at it inside software organizations, you can see it happening by increasing responsibilities (DevOps, SecOps, DevSecOps, etc.) with relevant tools that encapsulate some of the complexity.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

What a Senior Staff Software Engineer Actually Does
6 minutes read.

I think it would be interesting to think of Joy Ebertz's responsibilities and time investment as a context to ask yourself what is right for you. You might want to change some responsibilities, add new ones, or change the time investment. Just don't let inertia lead your path. Take control over your growth and your impact on others.

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

False Assumption 1: “Safety Is Increased by Increasing the Reliability of the Individual System Components. If Components Do Not Fail, Then Accidents Will Not Occur.” Nope. In Complex Systems, Accidents Often Result From Interaction Among Perfectly Functioning Components (Thread)
3 minutes read.

Managers should read this thread carefully, with re-read of the 10 fallacies of accident causation. The process (we call it BetterNext at work) should optimize for continuous improvement and learning, never to find the root cause (there isn't one really) or a person that could have done better (it's a system failure of humans and machines).

Read it later via Pocket or Instapaper.
Share it via Twitter or email.

@MrAlanCooper: Satisfying a large group of users is a by-product of satisfying one user. Satisfying nobody is a by-product of trying to satisfy a large group of users.

@dvassallo: If you have a goal to reach/do/achieve X by age Y, you’re self-inflicting stress & anxiety onto yourself for nothing.