Software Lead Weekly Software Lead Weekly

Someone Is Coming to Eat You
5 minutes read.

Great read by Michael Lopp, reminding us all that this game never ends, winning is an endless effort and our challenge as leaders is to build an environment that celebrates the journey (and appreciate the effort): "The reward for winning is the perception that you’ve won... You’ve forgotten that someone is coming to eat you and if you wait until you can see them coming, you’re too late. Just ask Nokia or RIM."

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

SQL Injection Attacks Against Speed Cameras
1 minutes read.

My humble effort to help you start the weekend with a smile on your face.

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

Purpose and Perspective Through What, Why, and How
5 minutes read.

Brent Baisley's frameowrk presented in the section of "Scaling up What, Why, and How" can be a powerful tools for sales, marketing, product managers and engineers to align everyone in the company around shared vision and tactics.

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

Why Deadlines Need to Drop Dead
6 minutes read.

Highly debatble topic, with a lot of easy ways to oversimplify reality to fit both agendas ("deadlines are critical" versus "deadlines are worthless"). I agree with Eric Elliott that deadlines should be customer-driven, making the entire team of product, marketing and sales better understand what can be done for a given date, and adjust their requirements as we release small iterations out there, and adjusting it to the market. So don't force a deadline, but do set an expectation for release plan by engineering, as they push forward, even if it's in certain range rather than specific date. The danger with going to far with "engineers should have no deadlines", is that it's easy to take a step further and get them to say "there is no point in planning then" which is a dangerous symptom of a blind execution team. Strong communication and trust is organizational unfair advantage in the market.

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

5 Ways to Hone Your Production Incident Postmortems
5 minutes read.

Paul Bellora with great tips on how to track incidents when they happen, and how to run some retrospective to get the most value, in terms of orgnaizational learning, out of those events. Paul's first couple of points are often overlooked and incredibly useful. Talk about it with your teammates, it will save you a lot of pain and reduce misalignment on how to manage incidents in real-time.

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

6 Tips for New Engineering Managers
4 minutes read.

Chris Paul with great tips I kind of wished I had when only starting as an Engineering Manager. I'd add to "Write down your decision making process" the fact that having a clear list of decision, can be utilized for doing "managerial decision review" later on: sharing a dilemma with your manager, letting them ask questions and how they'd approach it, and finally telling what you did. Sharing your dilemmas with others can teach you a lot just by listening to others explainning how they'd approach it. Also, if you can look at 50 decisions you've made you could also detct interesting patterns (and anti-patterns!) in it.

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

Screen Engineers Better With a Debugging Roleplay
3 minutes read.

Brilliant approach by Pete Karl on using text-based role playing games for phone screening. This is such a great way both to see the depth of knowledege one has while listening to how they analyze problems and try to break them into smaller validation points. Think of how such scenarios would be like in your company, so it would fit different positions.

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

The One Method I’ve Used to Eliminate Bad Tech Hires
5 minutes read.

Interesting approach to hiring when it comes to giving a project assigment for a candidate. The biggest takeaway and something I fully agree with is: " DON’T use a real problem because of tribe knowledge needed to fix." -- I know that some companies prefer to give candidates bugs or challenges to solve that are in the same domain (or even product). When context is a requirement, the project assignment will probably fail to test the right things.

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

@sandyarmstrong: What is everybody so upset about? New Macbook will ship with an ESC dongle for all vim users

@dhh: My most potent secret to productivity, satisfaction, and wellbeing: I sleep nine hours or more every night.