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).
One of my favorite undergraduate courses was an optional elective on the topic of ciphers, starting with handwritten approaches and eventually moving on into mechanical and then digital cryptography. A few classes in the handwritten section started with the professor writing ciphertext on the board and inviting us to spend some time attempting to break it without knowledge of what the cipher actually was.
A while back I pledged to write a paper on a topic unrelated to my academic major for my Estonian fraternity. I never actually got around to doing this, but at the time of the pledge I had the ciphers course fresh in my head and thought it would more research would be interesting. So in the interest of actually making some progress on this, I thought writing a bit about handwritten ciphers here may be a good way to motivate myself. To ease into it, I’m starting with the most basic cipher I know of: the Caesar Cipher.
I tried something new in 2017, which was to make a set of personal OKRs to fulfill throughout the year. OKRs (Objectives and Key Results) are typically used as a planning framework by companies (both Google and Twitter implement them) but I had never tried to structure personal goals in this way. I’m not sure it’s a general approach I’d recommend for anyone else, but I like the idea of taking a set of abstract goals and trying deconstruct them into measureable tasks.
I respect the effects of small adjustments to habits compounded over time. New Year resolutions have been effective ways for me to implement such changes. In 2014 I started making one-second-per-day videos (and have done so in 2014, 2015, and 2016 so far!). In 2015 I started regular Rosetta Stone lessons to learn Mandarin. In 2016 I tracked my weight and food every day with the intent of losing 30 lbs by the time my daughter was born. In 2017 I wanted to be healthier, happier, grow intellectually, and create things. I’m writing this as a postmortem on the process, and an accounting for how I think it went.