Software Lead Weekly Software Lead Weekly

How to Exhibit Leadership as an Individual Contributor
9 minutes read.

Organizations are not scalable by default, and counting on our managers alone to scale the company will only make the company more fragile. If you consider the ratio of managers to individual contributors, this post by Tom Bartel can help you shift some of the weight so everyone could assist. Make sure people get the appreciation (compensation and praise) they deserve for being a good coach or mentor to others, even more so if they're not a manager, as this is often overlooked.

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

Stage of Life vs. Math Skils
1 minutes read.

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

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

Support Driven Engineering (SDE)
7 minutes read.

"Sometimes all that’s needed is a more caring attitude in knowing how much work others have laid out before them." -- Share this post by Will Gallego with software engineers in your team, who ask themselves how they can move forward in the IC career ladder. Increasing your impact on your team and then on the entire organization starts with SDE mindset.

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

Software Sprawl, the Golden Path, and Scaling Teams With Agency
7 minutes read.

Charity Majors shares a good practice to align your team around "stable technology" while allowing individuals to bring new technology and use that. When you shift the cost and responsibility of the pipeline, system robustness (tests, monitoring, alerts etc.) and maintenance, you align the incentives. This will often lead to the right behaviors, where usage is a matter of utility and not hype.

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

The Most Obvious Question, or How to Increase Psychological Safety
4 minutes read.

This post by Matt Holford made me think a lot of about group dynamics in technical meetings. I think that what often helps to create a safe environment is asking questions around confidence level, understanding alternative cost, and data that could prove the opposite. For example, asking "if we are wrong, how will we know?" could generate a discussion around what to measure and how can we build confidence in the current path.

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

How to Be Big and Nimble as You Scale Your Company
2 minutes read.

The takeaway of optimizing our decision time and velocity (progress) is critical as the company grows. Upon a disagreement, strive to decide with the given context you have, stating the possible downsides and what we’ll do if it becomes relevant - making the decision less risky, and reversible if needed. It reduces philosophical debates as we can ask "How probable is that to happen? If it does, what will we do to mitigate?" and then we can focus on getting it done instead of being paralyzed.

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

How Many Reports Should a Manager Have?
5 minutes read.

I think this is a fascinating question, as we want to optimize for autonomy and impact while making sure we create meaningful management - a sustainable structure where X IC + 1 M> X+1 IC. I tend to believe that a manager should have at least 5 reports (and up 8 or so), as it creates enough room to build an independent team around a problem domain, formed with different expertise (puzzle vs. replacements), working to solve a solution from A to Z. Great read from Daniel Pupius that would make you think about your organizational structure.

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

How to 10x Your Own Productivity as a Manager Through Writing
6 minutes read.

"Relying on verbal communication alone causes unnecessary knowledge gaps for the whole team. Without written documentation, the conversations you have are inherently lossy—no one can remember everything that was said over the course of a 30-minute 1:1 or hour-long training." -- the best thing about written documentation is that it allows others to read it without the urge to reply on the spot. Next time you talk with someone else face to face, notice how much of your attention while listening goes into thinking about a response, instead of understanding their core ideas. When I write, I know that others will read and think about it for a few more minutes. Then, we can have a f2f discussion that goes deeper into the topic.

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

@Lethain: One challenge of infrastructure engineering is that we rarely talk about how to apply product management approaches to our work: problem selection, understanding our users, how tradeoffs impact different user cohorts, etc.

@Kpaxs: Write more: * To clarify your thinking. * To capture those synaptic bursts before your brain moves on. * For pleasure. * To pin down an idea using vocabulary. * For others. * To banish your demons. * To create blueprints, some of which may be later used.