Peter Meulbroek was recently hired as WebKite’s CTO.
I joined WebKite approximately one month ago; a period of time that is transitional for both myself and for the company. For me, it gets me back working locally in Pittsburgh after several years of working remotely for NYC companies. Much as I enjoy the City, I won’t miss the weekly trip on the 5:40 am flight into LaGuardia. I’m joining during the transition from Pikimal to WebKite as the external face of the company. At Pikimal, the goal was to help users make fact-driven decisions around products, services, and activities that are important to them. With the advent of WebKite, that goal is expanding to include a partnership with businesses and individuals who are passionate about a category, and who are in the position to curate that category’s data. We see that as the next step in the evolution of the company, and are excited to expand our vision to include these experts.
Coming aboard WebKite has been a great experience so far. My goal when I join a company is to free the technical elephant in the room, cleaning up the room post-elephant, then figure out how to move to a bigger room. The good news at WebKite is that some of the obvious technical challenges that plague many similar companies at this stage just aren’t present here; there’s no big technical elephant. For most companies, the pressure to “just write some d*mn code” is overwhelming; the business need is obvious, and the big customer is demanding or the big competitor is breathing down your neck. Internally, the marketing team is stir crazy waiting on something they can talk about, the CFO is worried about cash burn, and the CEO is…impatient… This usually results in buggy code that is both poorly conceived and ill-tested. After a couple years of this, the typical startup tends to spend more time fixing the sins of the past than actually developing new features. Code reviews? “We’d like to do that”. Unit tests? “We ran out of time”.
Not so at WebKite. The team does reviews on all significant code changes. Though the tech team is purist enough point out that they don’t “really” do test driven development, there are more unit tests here than at any of my previous gigs. Many formalists might disagree, but I don’t care as much when tests are written, I think it is more important that the tests in place so that a patch in a month doesn’t break a feature written today. Bravo, WebKite tech!
If it were perfect, I might not be needed; happily, there’s plenty of opportunity for me to contribute. We do suffer from an all-too-common affliction at a startup: the focus on the current cycle to the exclusion of any longer time period. We’re missing team-wide coordination and introspection about what product goals to achieve, and thoughtfulness about what path to take to get there. We think we want to go from A to C. What we don’t think about is that we need to go to B, and evaluate if C is still the goal. Even further, the path to B is probably A.1, A.2, etc. We need to be thoughtful before we start on how the product evolves, and how we learn from the marketplace at each step. After A.2, we may well throw out A.3, and also decide that C is not a useful goal. To address this, we’ll need to grow more introspective, but also learn to listen more to what customers and users tell us. To do so, over the next few months, as we continue working the kinks out of WebKite, we’ll drive development with our new user testing framework, listening to what users prefer. We’ll also roll out features fast and very iteratively, because we need to be responsive to our users, and to our new partners. These will be heady times, and I’m very excited to be a part of it.