I recently transferred to another team within my company, and this was the email I sent out at the beginning of my last day with my previous team. It doesn’t require much context, and lots of people have told me that I should share it, so here it is:
So today is my last day with the recommendations team. It’s been a fun year and a half with all of you, and I want to thank you for that. We’ve gotten a lot accomplished during my time here, and I hope everyone continues to move the team forward after I’m gone. I also hope that I’ve helped to instill some good values into our people and processes, and that you continue to iterate on our design, code review, testing, and quality practices.
Earlier this week I said that things would get a little philosophical, so I’d like to leave you all with a few final thoughts:
Always put the customer first: When dealing primarily in backend system development, it’s really easy to forget about the ultimate goal: to find innovative ways to delight our customers. We talk in terms of “the business” and “the ask” and “the client,” and often forget about the people keeping the lights on. When we’re building recommendations features, think about performance and quality first, as those are the two things under our control that directly affect our customers.
Be present: It’s easy to just “go through the motions” or fade-out during meetings, but what we discuss is actually quite important. The whole team could benefit from everyone being a bit more passionate about what we build, and what we discuss. It’s easy to forget that we’re a part of a world-class entertainment system, used by tens of millions of people…
Focus on experimentation and evidence: This team arguably builds one of the most easily relatable pieces of X1. We have the luxury of being able to quantitatively access the thoughts of millions of active users, but we generally don’t use it when making decisions (either engineering, or otherwise). When we do try to experiment, it’s a burden due to both tooling and process. Getting everyone comfortable with constant experimentation will be hugely advantageous for building the best product. Avoid the bike-shed at all costs!
Feel empowered to fail: Feeling empowered to succeed is obvious, but everyone should also feel empowered to fail. Failure is always an option, and shouldn’t be feared. It’s important to remember that while success creates proof, failure creates knowledge. Being scared of a new idea or a new system failing should never hold us back from moving forward, especially if the risks we’re taking are in the best interest of the system and our customers.
Don’t create red tape: We regularly talk about red tape, usually under the context of having too much of it to accomplish a particular goal. What we don’t talk about is that we’re often guilty of implicitly creating it. When we feel the need to discuss a problem with our entire org chart, that creates an artificial need for approval. Having confidence in the decisions of your immediate team, and keeping those decisions local can significantly reduce this artificial red tape.
Sometimes it’s ok to be too broken to fix: There are times when you instrument/monitor/refactor, and there are times when you re-write. The complexity and new-code-risk in our current system is prohibitive to our progress. I really hope that someone picks up the ball on CIRCUS and moves that forward.
Design-build-learn-design-build-learn: Recently we’ve started to put together PoC work, design meetings, whiteboard sessions, etc. before actually implementing something. While it’s always easier to just “code the unit,” I’ve always found it more beneficial in the long run to spend a little more time thinking about the system as a whole. Coding is 90% thinking 10% typing, right? Or it’s typing a different version of the same thing 10 times… ;-)
Read what you write: Writing functional code is only half the battle. Does it make sense when you read it? Will it make sense when you read it in a month? Will it make sense when someone else reads it a year from now?
Automate everything: We’ve made great progress with automation over the last year or so, but there’s still a lot to do. Automation isn’t just about making life easier, it’s about building knowledge into the system. I think people often overlook the fact that every time we automate a manual process, we’re increasing the knowledge our toolset possesses.
Alright, enough of that. I’m not going far, so please keep in touch. Thanks again for everything and best of luck with future projects!
I think it’s really important to stick to these principals, and more importantly, to speak up early and often if you’re a part of a team that doesn’t.