Software Lead Weekly Software Lead Weekly

How to Structure Teams for Building Better Software Products
7 minutes read.

Matt Lane offers interesting insights into how to structure your teams to increase their effectiveness. While it feels there are many existing models out there to leverage, every organization has its unique constraints and goals. Every structure is bad in many ways (it's unavoidable), so I find it useful to start with "what are we trying to optimize for?" and experiment with the tradeoffs. Talk with others about it and get their perspective. Understand what you'll need to compensate for.

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

The #NobelPrize Committee Couldn't Reach Paul Milgrom to Share the News That He Won, So His Fellow Winner and Neighbor Robert Wilson Knocked on His Door in the Middle of the Night.
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.

Why Silicon Valley Has So Many Bad Managers
7 minutes read.

Nobody learns in school how to serve our team and act as good leaders. We pick it up at work, but we can often experience the wrong set of behaviors to learn from. If you look at management as a long-term compounded return, where there is a good chance the people you now lead will want to follow you to future companies, you'll treat them well. Your company has to do well to keep them around, so you'll always balance between short-term and long-term. You'll balance between the company's needs and the team and individual's needs. People will follow you if they know you care about them and create a successful setup for them to shine.

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

I'm Often Complimented by CEOs on How I Run Meetings, and Some Have Asked for Tips. So Here's My # 1 Rule: Before Participants Share Their Opinions, Ask Them to Write Them Down. (Thread)
3 minutes read.

"The far bigger time-waster, I've learned, is free-form sharing. You inevitably get rat-holed because of someone's proclivity to blab or because one opinion generates endless debate." -- Meetings can be such a wasteful medium, yet done right, it's one of the best ways to create alignment and collect feedback. Andy Raskin provides ideas you can try out on your next meeting.

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

Product Thinking vs. Project Thinking
7 minutes read.

Kyle Evans with an excellent reminder that by default, our mind is optimizing for delivery of projects (features). Products also have unique traits that projects don't encapsulate well: SLA, measurement of success, observability, roadmap, clear long-term ownership, and more: "While project thinking focuses on coming up with solutions up-front and then delivering against a schedule, product thinking keeps the focus on the outcome. That involves some level of comfort with uncertainty and learning, which can be pretty hard. But if we want to get to the right outcome, and not just an on-time output, it is really the only way to work."

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

Choosing the Management Track
6 minutes read.

I'd share this post by Dan Na with software engineers who consider shifting into the managerial path. Our teams deserve great leaders who want to act as managers for the right reasons: "Management is a privileged position to provide that environment for others. And when it’s working - the team is healthy and collaborative, ICs are growing via stretch projects, and you play a role in the development of autonomy/mastery/purpose of a teammate - there is no better feeling in the world."

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

The Tacit Knowledge Series
16 minutes read.

I found myself reading for 30 minutes of different topics and posts from Cedric. I love his series on Tacit Knowledge: "Tacit knowledge is knowledge that cannot be captured through words alone. Think about riding a bicycle. Riding a bicycle is impossible to teach through descriptions." -- reminds me of Naval Ravikant's notion of knowledge: "You will need to rent your time to get started. This is only acceptable when you are learning and saving. Preferably in a business where society does not yet know how to train people and apprenticeship is the only model."

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

Good Decision-Making Depends on an ‘Archer’s Mindset’
4 minutes read.

Annie Duke's approach to decision-making is helpful as most of our decisions when building software or a team are not falsifiable. It's not math. Often, we'll need to collect information, explain our reasoning, and use our intuition before deciding. Having a method will help us increase the probability of hitting the target, and maybe sometimes hitting the bull’s-eye: "The beauty of approaching each decision by first examining what you know is that little bit of knowledge can go a long way toward improving your aim. The more you know, the better equipped you are to counter uncertainty in your decision-making."

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

@GergelyOrosz: Arguments you should avoid using- that are logical fallacies "Because it’s always been done this way." "Because we tried it before, and it didn’t work." "Because company X uses this." "Because {important person} said so." Reason on tradeoffs, constraints, opportunities instead.

@SamuelHulick: you aren't onboarding users to your product; you're onboarding users to an outcome