Software Lead Weekly

Expiring vs. Long-Term Knowledge
3 minutes read.

What a powerful framing to think about your information diet. Yes, you should read what you love until you love to read. Then choose (enough) quality over quantity: "Expiring knowledge catches more attention than it should, for two reasons. One, there’s a lot of it, eager to buzz our short attention spans. Two, we chase it down, anxious to squeeze out insight before it loses relevance. Long-term knowledge is harder to notice because it’s buried in books rather than blasted in headlines. But its benefit is huge. It’s not just that long-term knowledge rarely expires, letting you accumulate it over time. It’s that compounds over time." -- This is why I love Jeff Bezos's mindset on looking at things that won't change in the next ten years when considering ideas and investing areas.

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

That Feeling When You Get Your First Paying Customer for a New App You've Built
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.

Slack - Deliberately Leaving Time for Unplanned Work
3 minutes read.

I've covered before the idea of having enough time captured for unplanned work. This is the idea behind planning for "Slack" (not the app). This conjecture is important to align and agree on with your customers, peers, and the leadership team: "For planning and coordination, higher confidence is often worth more than trying to maximize throughput." -- It's worth understanding how much you want to invest in unplanned work by getting closer to your customers, investing in productivity tools, and solving small bugs that cause friction (context switches, annoyance, or anything else)

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

Love This Memo From Steve Jobs
2 minutes read.

Headcount is a vanity metric. Dunbar's number should teach us about the downsides of being bigger (in people) than our company's stage and needs. Managers are important at a certain stage. Having enough time for "Maker Mode" (also for managers) is critical, and top leadership must support and promote it. Nothing is good or bad by itself. It's understanding the tradeoffs and the pains or requirements (needs) and making the right decisions based on what we try to optimize for.

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

Why You Should Run Your Platform Team Like a Product Team
5 minutes read.

"The platform team’s main goal is to help developers safely ship software as quickly as possible while meeting the needs of organizational stakeholders. The organization stakeholders are often looking for secure-by-default infrastructure workflows, compliance guardrails, reduction of tickets and inefficiencies and the reduction of costs through the elimination of infrastructure sprawl among other requirements. Many of these areas are blind spots for development teams but are critical to the “safety” element of shipping software." -- I've seen the power of having a Customer Advisory Board (CAB) for Platform teams as a great way to influence the roadmap and help "Build in Public" so Product Teams can understand and rely on Platform Teams when they build their roadmaps.

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

Becoming a More Self-Directing Staff+ Individual Contributor
6 minutes read.

I'd recommend Omer van Kloeten's post for any Staff+ engineer considering stepping up in the IC journey to read. Inertia is comfortable yet dangerous in a leadership position. The section about "Introspection" is so easy to ignore and keep implicit. This is an area where having someone external to the team (maybe someone from HR/People org) mentor the team and ensure each individual has their document written and shared with relevant members can have a significant impact. An interesting topic to add to such document will be: "Which type of questions I want the team to consult with me even if it's not within my declared responsibilities? What do I plan to do to create an environment and trust with them to enable that?"

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

MVP: The Most Valuable Programmer
7 minutes read.

"Most Valuable Programmer isn't a concrete concept. Rather, it's a goal that you strive towards. Also, it's not about being the most valuable among your peers. Instead, it's about becoming the best version of yourself." -- I love this post by Arend van Beelen. This lesson took me a few years to understand, and working in different roles helped me understand that there are many ways to provide value: "Consider this: If you're an engineer you get hired to solve problems. Code may be your weapon of choice, but you don't get paid to deliver code. You get paid to solve problems."

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

An Interview Process That Works for Me
9 minutes read.

Colin Breck shares in detail the interview process they're using. Hopefully, it will inspire you to (a) write down your process and (b) consider changes needed to attract the right talent, improve the candidate experience, and your close rate.

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

@mwseibel: It takes time for a startup to find product market fit. In my experience, 1-4 years. Twitch took 5+ years to find it. And it's much easier to do this with a small team, low burn, and extreme focus.

@Jack_Raines: Over-optimizing every aspect of your life to reach some quantifiable result is a unique form of self-loathing. Bullish on fun stuff for fun stuff's sake.