Software Lead Weekly Software Lead Weekly

Desperation-Induced Focus
4 minutes read.

"I have nothing against process. But I think startups generally implement them way too early and way too often. [...] In reality, process is not my problem. It’s what discussions around new processes often preview within a company. Lack of focus. Peacetime thinking. Complacency." -- Ravi Gupta (ex-COO of Instacart) with one of my favorite posts this year.

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

Product Managers Using Their 6000ドル Laptop to Open Jira
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.

Team Topologies for Data Engineering Teams
5 minutes read.

Pedro Gomes Mota presents helpful teams topologies to consider when structuring your Data Engineering teams. Everything comes with painful tradeoffs, so optimize for what would serve your business and your team the best. Start with the requirements and pains, then derive the optimizations factors and the model that fits.

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

Developer Satisfaction Surveys
8 minutes read.

You can gain a lot by collecting (qualitative and quantitive) feedback from your developers. Sally Lait shares a helpful set of questions and a process to maximize the team's learning.

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

The Talent Equation
3 minutes read.

Dror Poleg with an interesting formula: [The level of in-person interaction] multiplied by [the size of the talent pool] equals [The rate of innovation and financial success]. Maybe the right way to think about it is that the talent pool's size becomes more important as the company matures. While it's still pre Product Market Fit, the level of in-person interaction might be more important.

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

Why Are Software Development Task Estimations Regularly Off by a Factor of 2-3?
5 minutes read.

Michael Wolfe writes a terrific (funny and spot-on) explanation you can share with frustrated colleagues. The purpose of estimation is to do just that - estimate. Being more accurate in your estimation requires a lot of practice to figure out everything that can happen on the road (using Michael's analogy) and re-risk it first (sometimes easier in software than driving a car). And still - it's only an estimate, even if you become very good at it.

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

30 Rules for a Life Well Lived (Thread)
4 minutes read.

Nicolas Cole wrote an inspirational thread with many gems to consider when designing your life. This one is my favorite: "Play the long game. Slow and steady consistency is the most powerful driver of growth."

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

Code Ownership, Stewardship, or Free-for-All?
6 minutes read.

Ben Northrop covers the optimizations factors ("Drivers") you seek when figuring out your Code Ownership model. Then he covers a few models that you might use today (intentionally or not) and triggers a question I thought is interesting - what is the Code Ownership model your company aims for? Is it explicit? Was it by design or via inertia?

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

@AmberCadabra: Stop calling meetings so you can simply organize your own thoughts with witnesses.

@amasad: To build talent density in a startup you need to abstain from hiring good candidates to find the great ones. It takes a lot of discipline and a high pain tolerance to do the work yourself for a very long time. But it’s totally worth it and eventually you’ll hit a talent flywheel.