Weekly Digest 3 - move quickly and safely
Another Weekly Digest, #3 this time. As usual, you’ll find a few jobs for you to peek at, product of the week and my biggest learning from this week.
Program Manager, Transportation @ Amazon - click here
- Team size: large | Location: ✈️ Remote
Project Manager @ Pixel Cabin - click here
- Team size: small | Location: ✈️ Remote
Backend Engineer @ Flickr - click here
- Team size: medium | Location: ✈️ Remote
Platform Engineer @ VividSeats - click here
- Team size: medium | Location: ✈️ Remote
Move Quickly and Safely 🚈
2 years ago I came across an amazing talk by Zach Holman who was employee #4 at Github and he went over the philosophy of moving fast and breaking all the things. The whole thought was born from Mark Zuckerburg in Facebook’s early days but as the company grew Facebook moved away from the push to break things in the codebase all willy nilly. Instead, Mark started pushing the saying “move fast and fix things” which makes much more sense and had a lot more focus on retaining users, learning from mistakes and delivering continuously.
In the talk, Zack focused on the phrase moving quickly and safely because obviously teams can’t move fast and break things ALL the time. It may work for a small startup with a tiny customer base but as the startup grows the thought of shipping broken features isn’t viable or smart for the business. So, having the mindset of moving quickly, iterating, constantly delivering all the while safely shipping your features and fixes is a WAY better philosophy to work by.
There was a lot more to this talk and here a few quick useful learnings I pulled:
Teams should engage in more communication
- Without communication and respect, a lot of things can tend to fall through the cracks. Focusing on trust and
communication from both executives, managers, and teams is crucial for a great dynamic.
Engineers should be responsible for their own code
- Zack mentions how QA teams shouldn’t be responsible for engineers code, they didn’t write. Instead, engineers are the authors of their own code and they should be accountable for it to work when merged to production. I completely agree here. Too many times I see engineers who “believe their code works” and don’t go the extra step of testing it before sending it for review and that’s insanity. You own your code, test it.
Ship lists for product launches
- In the talk “ship lists” are mentioned but so is Apple’s new product launch checklist. Essentially, these are to-do lists that give a clear look to existing employees as well as new ones a run-through of the layers a product or feature must meet before reaching the public. I used to have this in my previous role and it truly helped a whole ton. No longer did I have to try and remember what happened the last launch and ensure that this launch met all the criteria before it was pushed out. I was able to refer to a short list of items or sign-offs that MUST happen before this was launched and it saved large chunks of time for all parties involved.
Empathy for internal teams | “everyone should do support”
- It’s easy to reach out to an engineer or a CX team and tell them to do something or to fix X. It’s easy because we’re not that team. It’s easy because we sometimes don’t have the full picture of what it takes for an engineer to context switch, investigate, find a solution, implement it and push it to production. This is because we haven’t built empathy for that team member. Zack mentions how “everyone should do support” and that’s HUGE. Being in the shoes of another team member for a few hours or even a day really has shown me what it takes to problem solve an issue. If you’re not sure what a team does on a day-to-day basis, block your calendar out and shadow them. Knowledge is understanding and that ties to empathy for that person and their role.
Visibility means teaching
- I’d say this one ties with building empathy. The more you see the more you’re able to understand and that’s invaluable. Zack gave an example of using an Ops bot that pushes and tags @channel in Slack when a feature is down. The key here is that it tags “everyone” so all folks part of that channel (most likely the whole engineering team) will see the notification. Whoever is on call will tend to it and will keep all comms within that channel. Why? Because visibility is power. That new engineer that just came onboard needs to see how the issue is handled and solved simply because the next time it happens, what if that new engineer is on call? He’ll know what steps to take to at least get started because of visibility.
If you want to check out the whole talk, which I 100% recommend, the video is here.
Book of the Week 📚
How Music Works by David Byrne
Taking a break from self-help books or career related books, here’s a book about music. That’s it. It touches on the history, future, and challenges of creating music that we listen to today.
Buy it here
Product of the Week ☕
Physical product time! The Amazon Fire Stick has been my favorite product since I got it late last year. I can watch all the shows I want at any time with a decent UI allowing me to navigate through all shows and movies simply.
If you’re a tv show or movie buff, I can’t recommend it enough. Check it out here
Share this post if it was helpful or you! If you’d like this in a weekly newsletter form, shout me on Twitter and let me know :) If there’s enough interest I’ll get a mailing list running.