Software Lead Weekly Software Lead Weekly

Why It’s Difficult to Build Teams in High Growth Organisations
5 minutes read.

Jason Yip shares his observations for scaling software teams during hyper growth (and what not to do). I liked his insight on group structure alignment with the stability of the group's strategy: "Structure should be stable where strategy is stable; structure should be flexible where strategy is volatile. For example, if a broader department-level product strategy is stable while more local tactics are volatile, you should want the structure and shared identity of the department to be stronger and more stable than team-level structures and identities."

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

Me, When I Got My First Dollar Out of a Weekend Project
1 minutes read.

My humble effort to help you start the weekend with a smile on your face, even in this difficult time.

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

Product Management in Infrastructure Engineering
5 minutes read.

"Most infrastructure teams have a lot of experience in Foundation, but have much less in Innovation, so I won’t belabor managing through scarcity, and will instead dive into how to manage in times of surplus engineering capacity." -- Will Larson covers how to approach roadmap planning and vision when it comes to internal infrastructure teams. It is never easy to get this right, as you often find yourself considering building a generic PaaS (although it's not your core business) versus stitching together a solution based on a few well-known tools.

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

Shifting Modes: Creating a Program to Support Sustained Resilience
9 minutes read.

"Incidents cannot be prevented because incidents are the inevitable result of success." -- Share this post with your team and talk about your current approach to failures. This one is extremely important to look for when reading the summary of the event and what the team learned from it and plans to do differently (including action items): "The organization doesn’t truly benefit until those lessons are scaled far and wide. For the write-ups to be useful, they have to teach the reader something new and help draw out the complexities of the incident."

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

The Return of the Office
5 minutes read.

I still don't have a strong opinion on where things will go, and how many companies will want to shift back to working from the office. It looks kind of obvious that forcing everyone to work from the office every day will block your ability to hire talent. It feels we need to utilize our time in the office to socialize and promote initiatives that require a lot of intense collaboration. Will we become better at time management, or at least more aware of how we invest our time given the setup we're in? Time will tell.

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

An Incomplete List of Skills Senior Engineers Need, Beyond Coding
3 minutes read.

How do you feel about the topics covered by Camille Fournier? What would you like to work on and improve? Is there someone who can guide you on it? A handy list to look at and pick areas you'd like to work on to help you improve your impact.

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

Good Execution vs. Bad Execution (Thread)
4 minutes read.

So many wonderful examples by Julie Zhuo of measuring execution quality. These two are spot on "Bad execution: All decisions are rigorously considered and debated. Good execution: Expensive, hard-to-reverse decisions are rigorously debated. Cheap, easily-reversible decisions are made quickly. (Most decisions are the latter.)" and "Bad execution: The team, lost in Groundhog Day, continues to debate last month's decision because they don't agree with it. Good execution: Once a decision is made, everyone moves in lock step on implementation. Only substantial new information reopens the case."

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

Testing in the Twenties
8 minutes read.

As distributed systems and "big data" became more common, we see the spread of appreciation for tests, monitoring, and alerts. Tim Bray's post can serve as a great ground to discuss with your team. What is your preference? Why is that? What did you change your mind about in the past 5 or 10 years?

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

@david_perell: The Law of Work: Communicating an idea requires a finite amount of work. The more work the writer does to clarify their ideas, the less the reader has to work to understand them.

@rakyll: Operations is not a part of the job. It is the job. You don’t have a product if you can’t operate it.