216ways.net

I'm leaving GameChanger.

I've had no shortage of great bosses, but my relationship with Kiril Savino stands out as uniquely productive and creative. He simply forced me into roles where I was uncomfortable and, to my surprise, I kept my head above water. My 3.5 years there changed how I think of myself and what I'm capable of. For that alone, I am endlessly thankful to Kiril, my long-time friend Teddy Sullivan, my executive colleagues, and everyone else at GameChanger.

I will especially miss our engineers and testers. It was a joy to lead them and I'm proud of what we've accomplished together. We've had our growing pains and we've emerged with a smart, versatile, enthusiastic crew. A hard-core introvert, I was skeptical that I'd ever adapt to people management. Yet the opportunity to learn what would get each engineer's eyes to light up was the biggest privilege of the job. Attrition plummeted, uptime steadily improved (no small feat with our extreme seasonal traffic surges), and several people flourished in new, unfamiliar roles. We also hired some great people who'll ensure that the team remains strong in the future.

The biggest lesson I learned in my time at GameChanger, though, had little to do with work. We all have experiences that remind us of how short life is. My family has had its share over the last 3.5 years. When the days and weeks began to feel intolerably long and when each victory brought a decreasing amount of joy, I recognized that I couldn't waste time in finding a new hill to climb. I spoke openly with Ted and Kiril over several months about where my thoughts were leading me. They listened patiently and were amazingly supportive.

I don't know what's next for me. That's kinda scary. My colleagues at GameChanger have made it impossible to contemplate doing Just Another Job. I know I won't do them or myself justice unless I'm working with amazing people on an important mission. I'm going to take some time to figure out what exactly that means, mixing in some relaxation and therapeutic hacking in the process.

Thanks to everyone at GameChanger for being great teammates. Thanks for challenging me and please keep challenging yourselves. Best of luck marching forward on your mission, and wish me luck at finding my own.

Republished from my old 4cupsr.us blog post on January 28, 2012.

"I'd like you to be my manager."

Coach Malcolm Lester was promoting me, but, to my 16-year-old self, it was a demotion. Coach Lester was asking me to become the scorekeeper for his lacrosse team. He recognized what was obvious to everyone, including me. I was good at math and I wasn't very good at lacrosse. The best way – the only way – for me to stay in the sport for any length of time was to hang up my cleats and to pick up a clipboard. I said no, but a year later, in my junior year of high school, I finally agreed.

I worked hard at it and I was pretty good. When one of our star players started showing his stats to college coaches, the head coach at Dartmouth tried to recruit me, the guy who took the stats. I won one of my school's athletic awards - it was the first time a non-player had won in the school's 80+ year history. Five years later, I was MIT's Manager of the Year. I developed perl scripts that moved our stats online. I also twice successfully disqualified a goal for the other team. Those two goals equalled the number that I scored as a player.

Sports matter. Seven years of scoreekeeping reinforced that fact to me. Sports stir passion in players, fans, parents, and communities. Sports inspire people, and they motivate people to spend hours a day – usually unpaid – to coach, to practice, to drive players around, or to stand, in freezing cold weather, with a clipboard to record stats.

This experience helps me understand GameChanger. GameChanger is a beautiful and fast-growing mobile scorekeeping app for amateur baseball and softball. But the company is about a lot more than keeping score. The GameChanger app generates detailed professional quality stats and it produces a live play-by-play of games. Parents, out-of-town relatives and fans subscribe to that play-by-play to follow games that they can't attend. The product's effect is transformative. I've talked to several users of the product already, and the overwhelming consensus is that it has improved how coaches coach. And by connecting far-flung fans to their players and teams, GameChanger is making the world a little smaller.

I'm excited about helping GameChanger improve and expand. I am also excited because I've never been anywhere with higher expectations. GameChanger's baseball and softball apps are exploding in popularity and their fans are eager to see what's next. There's also a personal reason for the high expectations. I've known Ted Sullivan (GameChanger's CEO) and Andrew Huling (a fellow engineer) since 1989 when we were in 7th grade in Washington, DC. I know they expect a lot out of me, and I know that there are folks back home who do as well.

I get to work on something that excites me and with people I believe in. Can't wait to begin.

Republished from my old 4cups.rs blog post from September 15, 2012.

Two weeks ago, I got frustrated with the hundreds of bugs and feature requests in our database. So I deleted the whole thing. Then an odd thing happened: we started fixing bugs. We fixed almost 30 bugs last week, easily our best bug fix rate since I've been at GameChanger.

Joel Spolsky inspired me with his post on Software Inventory. I followed his advice almost to the letter:

At some point you realize that you’ve put too much work into the bug database and not quite enough work into the product.

• Suggestion: use a triage system to decide if a bug is even worth recording.
• Do not allow more than two weeks (in fix time) of bugs to get into the bug database. If you have more than that, stop and fix bugs until you feel like you’re fixing stupid bugs.
• Then close as “won’t fix” everything left in the bug database. Don’t worry, the severe bugs will come back.

In our release cycle, two weeks is an eternity. So we don't wait for two weeks of bugs to pile up. We wait until our bug column in Trello is roughly a screen-and-a-half tall.

Then we fix bugs! Our new bug column is too small to ignore. Some of the bugs that popped up were old bugs that customers had complained about for months. They had nowhere to hide in our tiny Trello column. So we fixed them.

The normal Huge Bug Database works in the opposite way. It requires a triage system (meeting), which requires agreement on a system of priority and severity (something to argue about). Then there needs to be some sort of scheme (meeting) for scheduling bug fixes along with feature work. And someone's got to make sure (emails) that the small percentage of Chosen Bugs are actually fixed before release goes out. That's a ton of meetings, arguments, emails, and management for little benefit.

Instead of documenting, categorizing, and scheduling bugs, we're fixing them and going back to writing features. Yay!

To build around generalists or around specialists is a core architectural decision for a team. I've worked on teams that have done both, and I now lean towards building around generalists when possible.

By a specialist function, I'm referring to something that one person or only a small number of people can handle. On past teams, we've had an Oracle specialist, a front-end specialist, and a test automation specialist.

These sorts of specialization leads to queues. That is, because there's a function that only a small number can serve, work requests queue up for those people.

Queues are really expensive. Read The Principles of Product Development Flow for a detailed discussion. The quick summary: when work sits in a queue, it isn't delivering any benefits to you. Reducing the time your work spends in a queue reduces your delay cost. That is, it earns you money by hastening the point at which you can realize benefits.

When a team is built around generalists, there are many people who are capable of handling any particular queue. You can use the same strategy that Whole Foods uses in many stores: all requests can go in one queue, served by multiple generalist checkstands. When that line gets big, you can get it under control by temporarily adding someone to checkout duty. This adjustment is possible because checkout duty isn't a specialist function. Generalists lead to shorter queues and fewer delay costs.

Credit: Matt Baume via Flickr

Specialist queues are different. They're something like the line at a pharmacy counter. Not every supermarket employee can work at the pharmacy. When that line gets big, it's harder to get it under control. Specialists can lead to longer queues and higher delay costs.

In product development, specialties tend to form somewhat naturally. This isn't necessarily bad, but it becomes a bad thing when queues consistently build and when delay costs pile up. I've seen a few examples that led to this pattern:

• Nobody on the team wants to learn a particular area. I've seen teams hire experts in areas that other team members shy away from. Some teams have an Oracle Guy or a Javascript Guy.
• The person who builds it owns it. When someone rolls out a new feature, that person can end up as the de facto specialist for that feature for years.
• Early adopters become specialists. When someone rolls out a new tool or programming language, they can become the team's sole repository of knowledge for that tool.
• Some people want to specialize. I've worked with people who want to carve out a niche that makes them special. This is hardly a bad ambition for someone to have, but it can lead to queues and delay costs.

As I said, I lean towards building around generalists even though all of these pressures to specialize exist. I've seen a few ways of handling these pressures:

• Outsource specialities when possible. Consultants and vendors are often better equipped to handle specialist functions. We're likely to replace our hand-rolled queueing system, understood by only a couple of people, with Amazon's SQS. Amazon employs enough specialists to keep delay costs under control. We don't have to hire or develop those specialists ourselves.
• Despecialize. Not every specialty needs to be a specialty. The best specialists are great at making their specialty accessible to others, both by teaching and by actively simplifying areas that require deep expertise. Jerry Hsu, our most experienced iOS developer, excels here. There used to be a set of problems that only Jerry could handle, and, during the busiest times of year, Jerry would be inundated with work. Now he's trained several other developers, and his workload has naturally redistributed itself across the team. He remains our most knowledgeable iOS developer, but he's used that knowledge to enable others.
• Challenge someone. Some developers revel in taking complex special-purpose work and making it accessible to a broader group of developers. We try to hire people with this mindset and to give them opportunities.
• Staff up. Sometimes, it's essential to your business to get good at a particular specialty. In that case, the only way to avoid delay costs to staff up — not by hiring one specialist but by building a team of specialists. At GameChanger, we've gained several iOS specialists through a combination of external hiring and internal development.

Conflicts and misalignments can happen. Sometimes people on the team will want to staff up a specialty when I think we should outsource or despecialize it. These situations are tricky, and I've learned that it's best to manage them by being both honest and compassionate. At times, it may be best to help someone find a job at another company that seeks to invest in their chosen specialty.

The decision to build around generalists has been a fundamental architectural decision for our team. It attracts certain kinds of people and it demands certain types of behaviors. I find that I need to evangelize the benefits of generalists and to advocate constantly for a generalist culture.

When faced with interpersonal issues at work, I'm leaning on the same techniques that are useful for designing for end users.

At its core, a design process basically has three steps:

1. Learn everything you can about your audience.
2. Generate possible solutions.
3. Pick a solution and iterate on it.

A common mistake is to skip to the 3rd step before tackling the first two. That is, we skip to feature requests. For example, "Hey! We need a PDF export of that report."

I've learned to always ask "why" when confronted with feature requests. Why is the audience trying to achieve? What's their context? What possible solutions exist?

In matters of people, though, I've started to discover that the same instinct is necessary. A few times, I've noticed that someone's work doesn't match what I expect. I figured it would be best to give feedback as bluntly as possible. "You aren't doing what I want. Do it better."

Having gone down that road a couple of times, I saw a pattern. I'd hurt the feelings of the person I gave feedback to. They'd react with anger and frustration. And I'd find myself backing up to step 1 and just calmly listening as my colleagues told me why they were upset.

And then I started to learn. My mental model of what they cared about was wrong in some significant way. As often happens with users, their mental model of themselves was wrong too. I couldn't just skip to step 3 and do what they asked for.

The same principle applies to me too. I'm not always clear about my own motivations. What I ask for doesn't always reflect what I really want.

When it comes to troubleshooting personal conflicts, I'm learning to seek clarity, both in what I ask for and in what others ask of me.

As some websites (including my employer's) are protesting in favor of net neutrality today, it's a good a time as any to say that I oppose strict regulatory enforcement of Net Neutrality.

I'm not outright opposed to regulation, but I'm not sure what problem demands regulation here. Net neutrality, the issue behind this protest, wasn't regulated in the USA from 2002-2010 and from the beginning of this year to now. Though there were clear abuses, they were corrected in the absence of the regulation that net neutrality proponents are asking for.

Our industry has benefited from a light regulatory touch. Strict net neutrality is a heavy form of regulation and we can't predict its long-term consequences. A regulation designed to handcuff companies like Time Warner Cable and Verizon — I hate them too — may be self-defeating. It may crush a company that doesn't even exist today. It may also prevent investments in network infrastructure, thereby harming the internet and internet businesses.

It's important to be humble about predicting the future. We're bad at it and we should only invite regulation — even of noxious companies — when we know that we need it.