Relentlessly give the user what they want

I love my Peloton. Mostly it exists as a fancy piece of abstract art in my office, but I occasionally use it for workouts. When I overcome my lazy butt inertia, my experience is that the Peloton almost always wants to do an update.

Instead of giving me what I want (to work out), I have to wait several minutes for the software to update itself. The engineer in me appreciates their rapid release cycles, but they are just frustrating users and they probably don’t even realize it.

When I’m driving in my car and I have a flash of inspiration, I love that I can instruct Siri to “make a note” and she helpfully transcribes it for me. Then she cringingly repeats the whole thing back to me, including reading the first few words twice (presumably because they were input as the “subject” of the note).

All I wanted was for her to take a note, but a PM at Apple was (understandably) concerned that the transcription engine was so bad that the content should be verified. For a text message going to someone else this makes perfect sense, but I don’t need 100% accuracy when it’s just a note to myself. Waiting while she slowly and robotically repeats my words is just annoying and only serves to remind me how bad she is at transcribing.

There are several examples of these little annoyances in daily life. Unexamined user experience quirks like this build up minor stress and annoyance throughout the day.

If software designers would simply ask this one question relentlessly, all software would be seamless:

“Does the user want this?”

Everything the user experiences in the course of using your software should pass through this filter. Does the user, who just sat down to exercise, want to wait several minutes watching a progress bar? If not, then accomplish your engineering need another way!

Less user-focused engineers advocate for their own needs: “But we need to update so everyone is on the same experience!” Then design your platform to support overnight or post-workout updates. Like technical debt, minor user experience oversights like this build over time into a frustrated user.

If your company has user-facing software, use this question as a tool to refactor and refine your user experience. Be relentless about delivering a user experience where user needs are met at all times.


You hire what you measure

At a recent conference, I spoke with an engineer who confided in me that the well-known tech company he works for is having an “innovation crisis”, where everyone is brilliant and works hard, but progress towards launching new features seems slow and uninspired.

So I asked him: what’s your hiring process? He answered with the mantra we’ve all heard before: “we hire the best and brightest engineers from the top schools – we have PhD’s and polymaths… We should be innovating like crazy!”

When did we get it in our heads that to create a successful product we needed only engineers that fit this traditional mold?

The beating heart of your startup begins and ends with the people you hire, and I believe that true innovation starts with your engineering team. After all, feature specs for a fast-growing startup are an ever-moving target: wouldn’t you prefer an engineer who can think on her feet, filling in the inevitable uncertainties that arise with her own good sense?

I’d argue that most startups still working things out don’t need engineers with strictly deep technical chops. I’d suggest that many of us would be better off if we started hiring more like IDEO:

Candidates [of IDEO] bring in examples of work they’ve done, things that they are passionate about. They have to get excited when they’re talking about what they’ve made and what they want to make. It’s easy to evaluate them when you get them in a room with a bunch of people who feel the same way.

Beth Strong, Director of Recruiting at IDEO

When was the last time you interviewed an engineer and asked them to talk you through a previous project from a product perspective? How would they go about things differently knowing what they know today?

I look for engineers who know when to cut corners, who choose launching over perfection, who think three steps ahead of the product vision and anticipate change with flexible code.

The next time you think of running a candidate through a tired whiteboard problem like “rotate a matrix 90 degrees”, be critical of yourself: does this inform you of their ability to be an effective member of your product team?

Instead, how about sitting them down with a relevant and open-ended project, and see how they set about accomplishing the task? Do they organize their time effectively and focus on the right things? Is their code structured well? This form of technical interview is more interesting and engaging to the candidate – and by talking with them later about what they produced, you’ll get a significantly better signal on their real world abilities.

If you start hiring this way, your startup will undoubtably be more innovative.


Welcome to the interview; please sit down and choose a color

A superstar engineer with a bad attitude can place more drag on your engineering org than they put in, which is why I like to focus my interviews on attitude and culture. Naturally, the candidate is on their best behavior, so how do you break down these barriers and see what they’re really like?

Let’s play a board game!

A lot of us at Sincerely enjoy playing board games. If you visit us during lunch, you’ll often catch us playing Chess, Blokus, Settlers, Carcassonne, or Acquire; lately we’ve come to enjoy playing a turn a day of the Game of Thrones board game (it’s a 6-7 hour game!). Through these sessions, I’ve come to realize how much game playing styles mirror how people interact with their coworkers away from the game table. One day when we had an engineering candidate on site, I got to wondering if we should invite them to the table.

How much can you learn?

We’ve played games where @hua was losing so badly that he was effectively out of the game. Yet, he’d still show up every day to play a round, in good spirits and doing what he could to influence the game. Likewise, he has the unparalleled ability to make lemonade from lemons, and I’ve never seen him in bad spirits. Even in stressful situations, Hua has a smile on his face.

Some time ago, a talented engineer joined our team who’d have so much potential if not for a stubborn attitude. Code reviews were always a one-sided chore, as we’d always get so much push back. Low and behold a pattern emerged when others played games with him: he’d get so angry at others for attacking him that they’d just stop doing so. And so went the code reviews – they became thinner and fewer, and his code more isolated. Would an interview game have exposed this attitude and spared us the bad hire, I wonder?

The ideal interview game

The ideal game involves strategy (over chance), plenty of interaction, and an opportunity for alliances. Game of Thrones would be ideal if not for it’s 6 hour play time; the ideal game lasts no more than an hour. I’ve played dozens of great strategy board games, but three stand out in my mind as best for an interview:

Carcassonne: Plenty of interaction, strategy, and some alliance possibilities. Easy to learn for new players, and quick to play.

Blokus: Fun & easy to learn with clear strategy. No opportunity for alliances, but plenty of interaction.

Settlers: Plenty of interaction, fewer alliance possibilities, some strategy difficulties for new players. A tad bit on the long side, but some engineers will already know how to play.

What to look for

In general, you’ll learn a lot about a person and their future interactions with your team just by playing a game with them. Just as they say there is a lot of truth in a joke, I believe that people often let their guard down when playing a game, and expose more of who they are. There are few interactions to pay particular attention to:

How are they at winning and losing?

There’s nothing wrong with savoring a win, but players who gloat over successes tend to be the engineers who have trouble interacting with and leading teammates later on. Being a sore loser can stem from jealousy issues, which hints at poor teamwork skills. The player that faces a battle or a game with grace despite the outcome will most likely be a good teammate.

How do they manage their alliances?

If the game involves making and breaking alliances, it can be telling to observe how a player manages those relationships. Do they take advantage of opportunities and break alliances at appropriate times? Players who maintain permament alliances even if it means losing a game are telling you that they’re loyal but may lack self-initiative. Players who “take one for the team” by preventing a particularly strong player from winning a round are showing you they are team players. Players who make a habit of breaking alliances too early may have difficulty with impulse control and bigger picture thinking.

How effectively do they learn?

How quickly does the candidate learn the rules to the game, and do they enjoy the process? How quickly do they pick up strategies on their own? How do they deal with uncertainty if a rule or strategy isn’t explained to them? These can indicate how quickly they’ll pick up new technologies and stay ahead of the curve.

It’s all in good fun!

By the time the candidate has walked through your door, they’ve probably already gone through several days of technical interviews. Imagine their surprise when you break that monotony by asking them to play a game with the team? If nothing else, you’ve all just bonded over a good game and made your company stand out in their mind as one that values culture.

I’m looking forward to implementing and refining our own interview game process at Sincerely and would love to hear your thoughts and feedback. The next time you have a candidate in for an interview, consider making it a group interview over a friendly board game and tell me how it goes.

PS: We’re hiring!


The mathematics of team productivity

When it comes to growing the productivity of a software engineering team, I believe there are four basic types of engineers: Adders, Subtracters, Multipliers, and Dividers. I find this framework helpful during hiring as well as determining when to let someone go.

Adders are your standard, talented engineers. They learn and grow over time, striving to improve themselves and their code. They add to your team’s productivity by being team players and strivers of excellence.

Subtracters are your below average performers. They complete what is assigned to them, and perhaps even do good work from time to time, but they subtract from the overall productivity of the team. Subtracters write code that must be refactored later, don’t stay current, and generally aren’t passionate about software development. Subtracters can become adders given time and a culture of code reviews or pairing, but you must already have enough adders and multipliers on your team for this to work.

Multipliers are your superstar engineers. They are not only talented, but they level up the whole team. They’re your evangelists of good practices and the ones that the rest of your engineers look to when they have a challenging problem. This is the engineer who stays up late working on a tricky bug, participates in hackathons, and is the first person you go to for the low down on the latest hot technology. They literally multiply the productivity of your entire team through their leadership and upward momentum.

Dividers are those engineers that rot the productivity of your team. They take several forms, but usually as some sort of attitude or behavioral problem. Perhaps they have a toxic attitude, are a crusher of new ideas, or are otherwise disruptive to the rest of your team. They usually get hired because they’re incredibly talented, but they take a group of adders and multipliers and divide their productivity. These are the folks you want to avoid hiring at all costs, but are sometimes the hardest to fetter out during the typical engineering interview. This is why I place the most weight on attitude and culture metrics when hiring engineers, but it’s still a challenge.

How do you avoid hiring dividers? I’d love to hear your thoughts on Hacker News.

If you found this interesting, you should follow me on Twitter.

Thanks to my friend Aamir who first told me about this helpful framework.


An inside look at the app that powers Sesame

Though Sincerely has been shipping physical goods to our users’ homes since day one, last week’s Sesame Gifts launch marks the first time we’ve done fulfillment in-house. So how does a startup go from shipping apps to shipping boxes? By building an app, of course!

From the start, we knew we wanted a Sesame gift to be more than just a brown box in the mail – that receiving one would be an experience in itself. We also knew that we’d want the same freedom to quickly iterate on new fulfillment and packaging ideas that we’d become accustomed to in software development. So we decided to do it ourselves and transform our beautiful office in downtown San Francisco into a state-of-the-art fulfilment warehouse, like this one:

Amazon's warehouse is like a huge Walmart that caters to pro shoppers

Ok, we’re not quite there yet! Tasked with setting up a fulfillment center in less than 8 weeks, our team created an internal iOS app that helps ensure orders get out the door accurately and efficiently. I’m quite proud of what we’ve accomplished and wanted to give you an inside look at what happens when you place that Sesame order for your mom that you’ve been meaning to send this week:

Introducing Rocket: the app that helps our team ship beautiful Sesame gifts.

The objectives of Rocket are simple: provide a list of orders that need to go out, print shipping labels for those orders, enforce accuracy throughout the process, and track everything. And of course, avoid any bobcats from ending up in our boxes.

And who says internal apps can’t have a little fun first? Maybe it was because we started specing Rocket the week of the successful SpaceX launch, but first time users of the app are greeted by an animation of a rocket ship with smoke trailing taking off with Elton John’s “Rocket Man” playing in the background. If you think it’s a bit much, I’ll agree with you only when I stop smiling every time I hear a new user open the app.

A user is given two possible activities: Packing or Shipping. Because we have a limited number of gift sets and a relatively complex packing process, we chose to keep these two processes decoupled for operational efficiency. Gift boxes are packed from inventory and placed in a staging area; when orders come in, packed boxes are pulled from staging, sealed with a personal card from the sender, and shipped.

Packing a box

A user who selects Packing will see a list of gift sets sorted by priority (sorted by available box vs pending orders). Choosing a box type shows a list of items to grab from inventory. The user enters how many boxes they want to pack and clicks Print, which prints a unique QR code inventory control label for each box. The packer affixes the QR code labels to the packed boxes, places them in the staging area, and moves onto the next box.

Rocket talks to our server via an API, which lets us keep track of things like how many boxes have been packed and are ready for fulfillment, as well as who packed each one and when.

List of Rocket Orders

If the user chooses Shipping, they see a list of pending orders as they come in, sorted by priority. Selecting an order from the top of the list, they see a screen that tells them what box type to grab from staging, and asks them to scan the QR code on the box with the camera.

Scanning the Box

This step is important, because it essentially “checks in” the box to the order: the QR code ties the box to a specific id in our database, so we know that the scanned box matches what was ordered (in case it was accidentally placed on the wrong shelf), and we know who packed the box and when. So if Joe Customer writes me a week later telling me that someone took a bite out of one of the chocolate truffles in his Ultimate Unwind box, I’ll know that Jane Packer has a sweet tooth.

Shipping Station

Provided everything matches, the shipping label and the personalized greeting card are immediately printed at their shipping station. All the shipper needs to do is insert the card inside the box, seal it, and place the shipping label on the outside. An email is then dispatched to the customer, informing them that their order is on the way, along with their UPS tracking number.

You may be wondering how we print labels and PDF greeting cards from the phone when the shipper clicks print. Actually, Rocket hits the server API, which then sends a request to the local CUPS server at the shipping station to print the label and card. But that’s all gravy – the important bit is that our packers and shippers don’t have to worry about marking orders as shipped, reconciling inventory, matching greeting cards with orders, or printing labels on their own – it all just works with timing synchronized to their workflow.

Launching Sesame and developing Rocket was a fun technical and operational challenge for the team here. It was a great mix of app building, api hacking, and interfacing with the real world. We’ve only just begun using Rocket, but it’s already helping us keep up with the rapid growth of our new product. As we expand our operations, we expect Rocket to be a hidden ingredient of our special sauce.

Continue the discussion on Hacker News