Learning from Giants #38
Square's A/B experimentation template, A gentle introduction to Conflict-Free Replicated Data Types, and Executive onboarding tips and best practices.
👋 Hi, this is Mathias with your weekly drop of the 1% best, most actionable, and timeless resources to grow as an engineering or product leader. Handpicked from the best authors and companies.
Did a friend send this to you? Subscribe to get these weekly drops directly in your inbox. Read the archive for even more great content. Also: I share these articles daily on LinkedIn.
An A/B experimentation template
Looking to optimize your A/B testing process? Check out Square's internal template.
"I’ve found it to be incredibly useful...It poses important questions for both stakeholders and data scientists to ensure that key details are thought through prior to setting up a test and launching it."
One of the most useful sections of the template is the Overview section, which helps translate the hypothesis into a business problem and agrees on the launch criteria ahead of time to avoid potential conflicts between data scientists and stakeholders.
The Learnings section encourages staying curious by noting interesting follow-up analyses or A/B tests to run after the experiment has finished, helping to get to the "why" of user behavior and inspire future improvements.
📗 Kasia Rachuta's Square's Experimentation Template shares the genericized version of the A/B testing template that you'll be able to modify for your own use cases. Don't reinvent the wheel - use that template in your team and optimize the impact of your A/B testing!
CRDTs: solving multi-user collaboration and synchronization with data structures
As apps get more collaborative every day, most software engineers will face that problem one day or another: resolving conflict between multiple users modifying a shared state.
What if I told you you could get away with zero conflicts, and as a bonus, all end up with the same final state?
That's what the very well-named Conflict-Free Replicated Data Types (CRDTs) do.
"A CRDT is a data type that can be:
"Copied to multiple machines"
"Be modified independently by those machines without any coordination and for any length of time"
"All divergent copies of that state can be merged back together in any order and by any machine. Once all machines have seen all divergent copies, they're guaranteed to have all converged to the same final state."
Implementing such a data structure, one could be tempted to use timestamps as a deterministic ordering attribute. But when looking closer, time has many flaws, starting with the fact that there is little guarantee that time is exactly the same across devices.
CRDTs instead focus on causality.
"Given we shouldn't trust system time and can't trust it where we're going (distributed, possibly peer to peer, and unknown connectivity) we need to free our mind from the common conception of time. [...] What we really care about is what events could have caused what other events."
📗 Matthew Wonlaw's Gentle Introduction to CRDTs is a very well-structured, illustrated, and written article introducing CRDTs from the problems they solve. It takes the reader through a first simple example and then explains CRDT's notion of time as a DAG (directed acyclic graph). If this introduction leaves you wanting more, I'll also post the link to one of the best CRDT academic papers.
Executive onboarding tips & best practices
"Most executive onboarding is not that successful. Parachuting in as a new executive in an already running team can be very tricky, and organ rejection is common"
"But when this is done well, onboarding can be a springboard for a multiplicative relationship."
Executive onboarding is a shared responsibility of the onboarder and the onboardee. Whichever side you're on, here are some principles that will help:
"Principle #1: No one knows who you are... and they are going to be skeptical." Your new team isn't the person who hired you. And there could be many reasons why they don't love you (yet).
"Principle #2: You have more to learn than you think. And no, you can't learn it later." Onboarding is a grace period. But when it ends, you better not look ignorant.
"Principle #3: What the leader thinks is broken isn't what everyone else thinks is broken." Make sure you consider both.
The recommendation: define that onboarding period clearly; it can be eight weeks; build your learning plan for that period, and stick to it. Don't reinvent the team's strategy or processes during that time. Focus on intentional, methodical learning.
After that period, switch seats and take control!
📗 Shishir Mehrotra's Executive Onboarding Tips & Best Practices is a dense guide to onboarding critical team members. After the principles and essential tips, it gives tools to design your N-weeks learning plans and Coda templates to fill as you go. A must-have for when you'll need it!