Software Lead Weekly Software Lead Weekly

Technicality
12 minutes read.

This post is one of those gems you should read every few years as you can always learn something new from it. Michael Loop (aka Rands) explains why he was wrong, saying that new managers shouldn't be coding anymore. I would add a couple of more suggestion to his list: (a) write features or tools that would boost your teammates' velocity and (b) rewrite current capabilities by using a new technology or process (as a standalone proof of concepts) - picking up a new technology or process will help you to encourage innovation without forcing it. Great read!

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

Say Thanks for Bugs
2 minutes read.

Really important post by Johannes Hoff, on why you should personally reach out and thank your customers when they send you a bug report. We often forget that bugs are a great way to build relationship with our customers. Do you remember the last time you've reported a bug by sending an email or tweet to some SaaS company you're using? How did you feel when you got a personal reply from them? Bugs are actually a great way to have a discussion, to increase our audience and build a brand around amazing support and genuine care for our users and customers. Own it.

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

How Can Being Inefficient Make You More Productive?
3 minutes read.

Ori Brafman suggests a few ways you can apply to become more productive (and innovative) by accepting your inefficiency, instead of trying to eliminate it. I've shared a post before called "The Chokehold of Calendars" that I believe we can utilize to achieve just that - we should block time in our calendar, instead of letting someone else to grab it, for such innovation and productivity insights to emerge. Can you set a 15 minutes every day for reading? Maybe another 15 minutes for walking around the building with a co-worker and share a story or personal challenge you're facing?

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

Back in Time With the Cost of Change Curve
3 minutes read.

How come we're still using data from 40 years ago when we decide nowadays how to build our organization and which methodologies to apply? Uri Nativ (VP Eng at Klarna) raises a great point we should constantly question ourself - are we using obsolete assumptions to build our business? Share this post with your peers, and if you have an option to see Uri's talk about "QA without QA", I highly recommend it!

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

Implicit Expectations – The Silent Killer of First Time Managers
10 minutes read.

This (guest) post is by yours truly. It's a story of my first few months as a first time manager and what I've learned from that experience. If you happen to be a first-time manager, or maybe you know someone who is, I hope that my story could help you to avoid some of the mistakes I've made.

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

What Is the Engineering Interview Process Like at Stripe?
7 minutes read.

I really enjoyed reading Greg Brockman (Stripe's CTO) answer as it fueled the engineer in me to rise for the challenge. It made me feel "wow, it's really hard to pass their test, so if I'll make it, I'm going to work with some amazing people". Looking at Stripe's interview process, at least the way I see it, tells a lot about their company. For some, this process might feel "too much", but I'm pretty sure that for each candidate, the process is a bit different. What's definitive though, are there hiring standards. I can really relate to the attitude and passion in Greg's response.

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

Building Teams: Why I Hire People, Not Skills
3 minutes read.

I really encourage you to read David Cancel's post about his hiring strategy. While I can relate to hire for "culture fit", what I found myself most connected to is to hire for "Scrappiness and Drive". If you're interviewing someone for your team, do you have enough solid questions to check for it? If you need some questions around it, please reach out and let me know. It was one of the first things I would test for, when interviewing people for my team.

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

@antonvirtual: A QA engineer walks into a bar. Runs into a bar. Crawls into a bar. Dances into a bar. Tiptoes into a bar. Rams into a bar. Jumps into a bar

@dharmesh: It is easy to criticize but hard to create. Do the latter -- less competition.