Software Lead Weekly

Firing People: How Can We Fix the Firing Process if We're Not Even Talking About It First?
21 minutes read.

Fascinating and personal read by Zach Holman, on his experience being fired of GitHub (was there for 5 years, employee #9). Zach has his own unique style of communication, which can be hard to read, and potentially to listen to, but it also feels that his heart and talent were always in the right place. Interesting story with plenty of insights on how we can keep being honest and fair about the way we approach this horrible situation. It takes a lot of courage to publicly talk about it, so while I don't agree with all of his insights, I do cheer and highly impressed by his willingness to share a truly painful experience.

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

The Office - DVD Screensaver Cube
2 minutes read.

My humble effort to help you start the weekend with a smile on your face. I wonder how much of it happens to me when I talk, after all "some days I'm just on fire!"

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

Software Has Bugs. This Is Normal.
4 minutes read.

"Throwing ever bigger teams at problems usually just makes the problems bigger still... Useless software can be entirely bug free, yet remain entirely useless. Useful software can be ridden with bugs, yet remain highly valuable. Or, the value of software depends far more upon the problem it solves than the quality by which it does so." -- great piece by DHH, making me think of bugs as sort of technical-debt that worth the same attention when it comes to prioritization, i.e. figuring impact, investment, users' frustration, current scale etc. You cannot throw endless engineers or QA to eradicate bugs. Such state of mind will probably only eradicate your business due to ridiculous (salaries) burn-rate. Set expectations accordingly and align your prioritization process to reduce internal frustration.

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

Entropy Crushers
7 minutes read.

Calling project managers Entropy Crushers might be a good marketing approach (a la Growth Hackers): "They are here to help with X because if we don’t solve X, we are screwed... A good project manager’s job is to decrease chaos by increasing clarity. I understand that chaos can be an essential ingredient in creative, but I guarantee you — I promise you — even with the best project manager on board, you still get to run around like a crazy person because the sky always unexpectedly falls. Chaos in a complex system is a guarantee." -- Michael Lopp (aka Rands) claims it's time for more Project Managers. While I understand, I'd like to further push the envelope. There is no need for Engineering Managers to do it either, or at least carry this burden alone. We need to scale this concept. There is a huge value in teaching senior engineers (who want to, of course) to improve their project planning skills and communication skills. They can do the trade-offs, offer alternatives, align people around them etc. The same happened in the "QA world", where much of the automated testing shifted to engineering. It just scales better, if you're willing to embrace it and mentor people to improve their planning skills & soft skills. Many companies fail to define & teach, thus falling back to "lets hire". In the long-term I believe it creates too much waste.

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

SelfConf: Empowering Group Learning for Software Engineers
3 minutes read.

This post is by yours truly. We share a lot of great read on a few internal Slack rooms, but I wanted to create something bigger than that. SelfConf is a frugal way to get your team within the same room, and get them to share talks they believe made a difference. It helps to create emotional bonding, where people can not only see a great talk together, but also hear why it was chosen and learn more about the person who offered it. We're planning to do another one in a couple of months, and people already started to send some great talks they'd like to recommend. Hope that this is something you can use in your company.

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

How Developers Stop Learning: Rise of the Expert Beginner
10 minutes read.

It's incredibly easy to get trapped in "Expert Beginner" state. It's our role as leaders to foster an environment where feedback and mentoring can help us unlearn old habits in order to learn new ones.

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

7 Tough Lessons I’ve Learned on Giving and Receiving Feedback at Our Startup
5 minutes read.

Great tips by Leo Widrich (COO at Buffer,) on how to give and receive feedback. From my experience, you should start with building trust first, and only then jump to providing feedback. People have to feel that you're on their side, and genuinely care about their progress, and their career. Without trust, even if you've got the best intentions, most feedback will simply be ignored.

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

Spend Time With A+ People in Other Industries
2 minutes read.

Hunter Walk with a great advice on expanding your horizons. While I don't have the google brand behind me, so far I've been able to reach out to other people thanks to this email which started as a small side-project and turned out to be something with much greater impact than I've ever expected. Find a way to meet and learn from others, this will probably be the shortest path to our own personal growth.

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

@sean_a_rose: The moment I am not terrible at my job is the moment I go find another job to be terrible at. It's no fun when there isn't room to learn.

@DocOnDev: If you're going to copy an organization's model, dig deep. What we first see is often not the model. How they got there is the model.