Hi! I'm Matt. Nice to meet you!
I like to open things up and see how they work. Software has been a convenient way to vent this obsession because, unless you do something terribly tragic, you can't physically break anything.
Today, I'm a director of engineering and the site lead at Dropbox NYC. Since founding the office in March of 2014, we've grown to over 75 engineers owning a variety of high-impact products and infrastructure. I work with an incredible group of people building the cultural and technical foundation for Dropbox's first engineering presence outside of headquarters, and it's been an amazing experience.
Previously, I built Hoot and a few other things with my partner Christina. Hoot was the first mobile app for both of us, and, as with any new technology, the victories were as glorious as the impasses were frustrating. Before that, I was at Hunch (later eBay via acquisition) and Meebo. I am constantly reminded of my gratitude for the mentorship I've received. Much of what I know has come from patient, talented coworkers.
At Stanford, I studied computer science and left with undergraduate and master's degrees. I did my best to exhaust the course catalogue's supply of systems courses, though I may have left a few behind.
As an individual contributor, most of my work has been in infrastructure and machine learning, architecting and building large-scale systems to make sense of lots of data. I spoke on these topics at PyCon 2011 and PyCon 2012. I've also explored the depths of Android development – there are some interesting fish at the bottom of that sea.
Enjoy your stay! If you'd like to subscribe to future updates, join the mailing list.
Managing without domain expertise
At the risk of stating the obvious, being an engineering manager (EM) and an individual contributor (IC) are different jobs. An IC is responsible for developing high-quality software that serves customers’ needs. An EM is responsible for ensuring that the company’s resources are leveraged effectively to achieve its goals. Manager...
Productive escalation
Developing complex software at scale almost always requires coordination across potentially many teams and functions. People are people, and every now and again, such coordination results in disagreement or conflict. For example, an engineer might disagree with the user experience proposed by a designer. Or, a team responsible for a...
Ownership and quality
There’s a natural tension between quickness and quality in early-stage product development. The faster you build a product, the sooner you can get feedback and iterate towards what users want. If you move too quickly at first, you risk the maintainability of the code and can end up spending all...