Coming up next Jul 16, 2016

On jobs that click, and leaving them

When I started as a PM at Microsoft in mid-May seven years ago, I thought to myself, "well, I guess I'll give this a shot for a year, and if I don't like it, I have a 'Plan B' to go work abroad through AIESEC." And if I did like it, I figured I'd put in a couple of years before figuring out my next steps.

Well, it turned out that I did like it, and a "couple of years" rapidly became the better part of a decade. Why? Because I was lucky enough to find a job that clicked for me. And yet, after all this time, and even though both my family and some of my friends think I'm a bit crazy, yesterday was my last day at Microsoft.


Talking at work Aug 4, 2015

Want a team to communicate well? Talk to groups at least 80% of the time

The rise of Slack and similar chat services is, in many ways, changing the way teams communicate at work. Day-to-day conversations are increasingly moving from the stagnant, high-overhead world of email to light-weight chat. I find this evolution incredibly exciting, and I think many companies and teams are benefiting tremendously from these changes. But most teams? Well, they never knew how to communicate in the first place. And Slack can't magically fix the fundamental flaws that make bad teams remain bad teams.

Poor communication

How do you know a team is bad at communicating?

My experience is that if you've ever been on a team that has healthy communications and you suddenly find yourself on a bad one, it'll be painfully and overwhelmingly apparent. But I suspect quite a few people haven't had that good fortune, and believe a team with stunted communication channels is actually the norm.

Here are some pretty safe indicators that you're on a team that doesn't know how to communicate:


The soccer ball and the solar system Jun 8, 2015

Two ways to think about reworking a complex software architecture

A few weeks ago I hit my six-year anniversary at Microsoft. In that time, I've worked with several teams building web services inside the company, and I've built a network of decent size at many of our peer companies. I've learned a lot about software engineering, both from my own experience and that of my peers. In all this time, perhaps the biggest thing I've understood is this: pretty much every engineer who works on a software project of any complexity hates their codebase.

Talented engineers faced with market pressures make tough choices that almost miraculously result in shipped software. It's well understood that those choices add up at a micro level as technical debt, and most great companies have figured out mechanisms for improving individual components over time. But it's harder to account for—and correct—choices that add up at a macro level.

Architectural debt is the sum of those macro-level choices. It affects every piece of your code base, and is usually the result of decisions that were made years ago. Importantly, those decisions may well have been the right ones at the time, both from a "getting to market" perspective and from a "right technical choice for this moment in time" perspective.

However, because it affects so much of your codebase, it's dramatically harder to revisit architectural debt, and the decisions that made sense once upon a time evolve into an albatross around the neck of the people who have to deal with them now. This is the source of the codebase hatred that pervades among engineering departments at companies; they are weighed down by two major factors:

  1. The architectural debt has started affecting every aspect of their day-to-day work: everything takes a long time, functionality is fragile, ownership and accountability is hazy, etc.
  2. The codebase is so large that making any real impact on the problem seems like an insurmountable challenge.


The API is the product Apr 12, 2015

Companies have figured out how to make great APIs and make money

Back in the early days of Web 2.0 exuberance, all the hot new online services (Flickr, Delicious, and even Twitter) built largely open APIs and encouraged developers and customers to build mashups: fun but fleeting ways to juxtapose data from multiple sources on a single webpage. These companies seemed to believe that enabling people to create new and unexplored tools on top of their data would produce magical, unexpected innovation that would make the entire platform richer and ultimately accrue benefits to them. For a time, nearly every consumer startup seemed to launch with an API ready to go, even if their company didn't yet have enough usage to make developing on that API worth people's while.

Unfortunately, as the early mashup excitement waned, these companies figured out they had to earn money and exert more control over their platform. Watching Twitter stumble drunkenly through that process has been particularly entertaining, but the gradual falling into disrepair of many other companies' APIs may ultimately be worse for the web community as apps break and the features of the product diverge from the features of the API.

In recent years, though, a different approach to APIs has emerged. Companies like Twilio and Stripe are rehabilitating the idea of an API from the legacy of failed late-2000s startups and going "all in": the APIs these companies provide are not just important, but the core product that each of them sells.

These companies have figured out two fundamental things about APIs:

  1. The best APIs aren't for your product but for a problem.
  2. You must put as much effort into the user experience of developers who want to use your API as you do in all the other elements of your product.


Wedding planning the 21st century way Mar 29, 2015

According to TheKnot, a popular wedding planning website, the average cost of an American wedding in 2014 hit the mind-boggling number of $31,213 (though their numbers include the cost of the engagement ring). Any event with a budget to the tune of 30 grand inevitably becomes a complicated planning endeavor, with hundreds of tasks and projects, all of which add up to piles of cash leaving your wallet.

One of the big expenses that figures into that sum is a wedding planner, which isn't surprising: for many people, their wedding is the most complicated project management exercise they'll ever be involved in. I, on the other hand, consider project management one of my professional competencies. As my fiancee and I work to plan our wedding, I've found that we've been able to apply many of the tools I already knew and loved, and those tools have allowed us to reduce our stress levels, minimize our own amount of work, and save a good bit of cash.

While we looked at the fancy "official" wedding tools (like TheKnot itself), all of them seemed to have some fatal flaws. They make assumptions about what you want to do with your wedding and subtly encourage you to do more than you might care about (and therefore spend more money). But the biggest issue with common wedding planning tools is this: they assume one person (generally the bride) is handling all the wedding planning, and offer minimal opportunities for collaboration. Frankly this is just antiquated nonsense in 2015, so we rolled our own. Here's how.


Tragedy of the common timeline Mar 13, 2015

Meerkat isn't good for Twitter's mainstream users. Why are we surprised it got blocked?

If you keep up with the tech industry's latest social fads, you might have seen a new app blow up this week: Meerkat. The iOS-only video streaming app enables users to trivially kick off a live broadcast of whatever they may be doing, and share it with their Twitter followers.

On Friday evening, only a short while after the app began to draw hundreds of influential users, Twitter pulled the plug on Meerkat's access to their users' social graphs, preventing the app from drawing on people's existing networks of Twitter followers. Given that this comes as Twitter works to rebuild developer trust, it's a controversial move, especially in light of the announcement that Twitter has purchased a Meerkat competitor.

Is Meerkat doomed?

Given that Meerkat can still freely and automatically post to Twitter otherwise, it seems that Twitter has taken this stance primarily for competitive reasons, and I'm not entirely comfortable with Twitter becoming protective of the parts of my social graph that happen to be in its system today. While an outright block is probably too harsh a measure, I think Meerkat runs the risk of running afoul of Twitter and undermining its own growth for another reason entirely: the app is a prime polluter of Twitter timelines.