Two years ago I started setting personal OKRs (Objectives and Key Results). I wrote about the 2017 results here and decided to carry the practice forward into 2018. I wanted to recap how things have gone and how I’m thinking about this experiment going into 2019.
I am aware that this is a bit of a ridiculous exercise. My answer to “do you have any New Year’s Resolutions in 2018?” was “well it’s like 13 metrics-driven resolutions spread across three main themes”. Most people probably wouldn’t find value in this kind of system, and I think it would be fair to criticize me for taking this approach to achieve goals like “happiness”. I probably overdid it this year by trying to do too much. I felt stressed out about making progress on these goals and that led me to be very protective about my free time. I was probably a worse husband, father, son, and friend this year. At the same time, it’s hard to say that I wasn’t aware that this was the deal I was making. I wanted to push myself to do more, and to have more to show for it. I’m proud of what I was able to achieve in 2018, but there was a cost too.
I enjoyed publishing some thoughts on my reading list from 2017 at the end of last year, and wanted to continue the tradition in 2018. I think my blend moved more toward nonfiction this year, which I’ll blame on getting a ton of good recommendations through work. Stripe is an amazing place to build an impossibly large reading list.
I didn’t quite hit my goal of 20 books this year, but feel good about the material I did get through this year. If I had to pick, I think Men, Machines, and Modern Times, Democratizing Innovation, The Score Takes Care of Itself, and Sculpting in Time were my favorites of the year. I’ve left some notes on these books (and more!) in ascending order of completion below:
The teams I manage at work pride themselves on moving quickly. We release features, adjust UI, and run experiments at a rate where it is difficult to follow everything which is going on. I see one of my responsibilities as a manager to keep up this pace of execution, but in a way which holds a high bar for quality and allows for feedback from stakeholders who aren’t following every design discussion or code review.
We had a problem of the sort where an engineer would make some kind of change and then later on get asked “why did you turn this on?”, “why didn’t you tell X?“, “did you consider A, B, C?”. This was adding uncertainty to the development process - engineers would be uneasy about rolling changes and felt pressure to get buy-in from every stakeholder before shipping even small modifications to the software.
I wanted my team to feel safe following a product development process where they wouldn’t get second guessed or called out if they did things the agreed-upon way. Using my favorite productivity tool prototyping platform (Google Apps), I created a form which would handle collecting the details of planned changes, format things nicely, and notify all appropriate stakeholders. We have an agreement with the team now that engineers are “covered” making changes as long as they fill out the form as soon as possible during the development process. If an engineer uses the form, ships a change, and then someone has a problem with how the feature was shipped or communicated, then I intervene and walk the stakeholder through our tracking process. This has been a great step toward making engineers feel more empowered to ship changes, giving stakeholders a concise summary of upcoming changes, and has the side effect of creating a clear log of everything our teams are contributing.
I’ve gotten some interest in this internally from other teams, and I think it’s a generally useful tool for any team of software engineers. I’m going to walk through how it works and was built, with the hopes that you may find something like this useful in your development process.
As is pretty common at SF tech companies, lots of people at Stripe have laptop stickers with various company logos (including our own) on them. So there have been at least a few cases where I’ve sat in a meeting, maybe slightly distracted, facing a laptop with the word STRIPE on it, and let my mind wander. And where it tends to go is to the observation that there’s lots of other words inside of STRIPE. STRIP is a word, TRIPE is a word, TRIP is a word, and RIPE is a word. There are valid words all up in this thing! And then I tend to think two very specific questions:
I’ve thought these questions far too often. And so in the interest of self-discovery, growth, and hopefully moving on to other useless things to think about, I decided to find some answers.
I’ve had a game idea bouncing around in the back of my head for a few years now. In fact, many of my goals in the past few years (i.e. watching more art films, learning to paint, and publishing a small game) have been in service of expanding my repertoire to be able to work on this larger meta project.
The game itself is structured as a puzzle-based adventure game, where solving puzzle challenges in effect unlock skills which can be used to advance the story. The puzzles themselves are supposed to be abstractions of programming challenges, but presented in a way so that non-programmers could complete them. I wanted to explore the space of manipulating a stream of data, rather than some kind of Turing complete programming environment like Shenzen I/O (which does that really, really well).