What would happen if you asked your boss for another person to do your job with you? Would you be laughed at? Demoted? Fired? It turns out that developers have been working together to complete single tasks for decades, using a practice called “pair programming.” The basic idea is simple: Two developers sit in front of one computer. One programmer “drives,” typing out actual code, while the other observes and guides the driver, catching mistakes, and suggesting high-level strategies for completing the task.
Although it might sound counterintuitive and costly to employ two engineers to do one thing, its proponents swear that it actually saves money and time. Michael Kebbekus, a software engineering manager for collaboration software company Mindjet who spends 80% of his time pair programming, says the practice reduces costs and increases innovation by forcing developers to think through their decisions early:
When you work alone, you only have yourself to guide you, and every idea you come up with seems like a good one. When you pair program, you have the perspective of a colleague, and every idea is just a starting point for something better. Before you start typing, you verbalize a solution, and in explaining your thoughts out loud you discover aspects of a problem you didn't even consider, and better yet, your partner does, too. A quick conversation of refinements takes you through multiple iterations of an idea and past many pitfalls that would've lead to bug fixes and costly refactoring later on.
Kebbekus believes that these benefits can apply far beyond engineering to divisions like project management, marketing, and even legal. Thanks to the small, tight-knit nature of his team, he already leads a project manager who has started working in pair with engineers on the product roadmap.
For him, what was working well was being able to put a little bit of effort into a bunch of different ideas he was having for ways to take the product. We would work together in this really early, light phase of whiteboards and drawings so that before he wasted time making Photoshop mockups, he had already worked through problems like, "Oh wait, it would be silly to do a modal window because it would be hard to use." Even as nondesigners, we were able to raise questions when he explained features to us.
Although he acknowledges that it might not be beneficial to every division for every type of project, Kebbekus believes that everybody should at least try putting people together to work on high-value projects. His advice is to slowly start asking team members to work together on bigger, higher-cost projects and gradually formalize pairing people as they get used to the process.
Get people in a room together, because that will start the feedback loop of somebody lifting their head up and saying 'hey, what do you guys think about this stuff? I'm going in this direction.'
The earlier conversations are happening, you're actually getting a more valuable output or saving costs by not going on a path you don't need to go down.
This is an ongoing story, so we're adding to it as news rolls in. Read on to learn why we're tracking lessons in engineer thinking. Or skip below to read previous updates.
Software developers and designers are among the most productive workers in any office when things run smoothly, fixing problems and launching features at breakneck speed. But here's a dirty little secret: Developers are also the laziest people at your company, and that isn't a bad thing. Unlike most professions, where output is additive, a good engineer will actually eliminate lines of code from a product over time by finding easier ways to solve problems. Having the discipline to constantly throw out your own work in order to save time requires a specific kind of laziness unique to the technology and design fields.
Still, most companies divide their staff into "technology people" and "nontechnology people," ours included. This divide makes it harder to even know how to talk to engineers, never mind learn from the way they think. So what do your engineers have to teach you? Read on for lessons.
Everyone in technology is searching for talent. Know any good Rails engineers? Have a good front-end designer? Got any freelance contacts? When it comes to technology talent it's a seller's market, at least here in New York. So I wasn't too surprised to find this Facebook post from an entrepreneur friend of mine:
The full story: Jack Phelps, who is chief product officer at Brightbox, needed a Linux engineer for his NYC-based team, which makes cell phone charging kiosks. (Venue owners install them in public places so that patrons can get a quick charge.) He told me:
We had trouble diagnosing an issue with graphics driver support in Linux on some new hardware and didn't have the expertise in-house to figure it out. Googling for solutions, we stumbled on the blog of Magnus Deininger (ef.gy), a freelance hacker in Germany who does a lot of open source and embedded development and who had recently blogged about solving a similar issue. We asked him for advice, and he said he'd be happy to take a look, although he was getting married that weekend, so he wasn't quite sure if he'd get to it immediately. But sure enough, about a week later he was back with a quick solution for us. He didn't want to be paid because it wasn't too much work and he didn't want to complicate his tax situation with a few hundred dollars of random income. So instead we thought we might send him a gift. He didn't have a wedding registry, so we were out of luck there. We considered bitcoins but it seemed like kind of a lame present unless we managed to get ahold of one mined by Satoshi himself or something. We thought about a Beagle Board, a USB protocol analyzer that had saved our ass with another recent hardware question, but thought he might already have one. We were about to spring for some artisinal Brooklyn fare--Brooklyn Brine pickles or Kings County beef jerky--when one of our programmers had the idea of buying him a drone. The Parrot AR 2.0 quadcopters are pretty awesome for a hacker/hobbyist (I mean come on, you can control them with a smartphone's accelerometer and stream the POV footage back in real time). We're sending him some jerky too to go along with it.
And in case anyone was wondering:
PS: the drone is not autonomous, it doesn't hurt people.
A brilliant move that reminds me of one smart recruitment tactic I saw last summer at the social startup Sonar.me. Last summer, desperate for backend engineers, they posted this compensation package. The package included everything here if you accepted their (market rate!) engineering job:
- A Zero Gravity Experience (in other words, they’ll fly you to near-space and let you float around)
- A “Round The World” flight ticket
- 1 year supply of scotch (“For the long nights,” they say.)
- Hang Gliding trip
- Sky Diving trip
- Surfing lessons
- 1 Ticket to SXSW and any big data conference
- 1 year gym membership
- A night’s stay at the Waldorf Astoria
- New wardrobe from uniqlo
- Makerbot 3D Printer
- 64GB iPad 2
- High-def video projector
The actual cost of all this stuff is probably fairly competitive when compared to a cash bonus with equivalent attractiveness. The cost of assembling the package? A few weeks of intern time. I'll be surprised if more startups don't adopt this sort of approach to recruitment, especially as a way of self-selecting adventurous, creative talent.
Distribution is a feature, not a marketing plan. Over at Redpoint, Tomasz Tunguz wrote a great little article last week about what he called "startup judo," the way successful startups find something they can use as leverage against competitors that doesn't fight strength with strength. This secret sauce can be anything, but Tunguz mainly highlighted distribution.
Startups shouldn't rely on more manpower, bigger ad budgets or data access advantages in fields where there is a large incumbent. During its infancy, Google won with distribution. Most internet companies believed search wasn't valuable. Google thought differently. They offered to power all the major portals' search engines and eventually dethroned them. This was Google's secret.
If that description doesn't sound like distribution in the traditional sense, it's because it isn't. The key to Google's early success wasn't pursuing brute-force tactics like shipping more copies of software, gaining more users, or even being the only search engine in town. It was finding a way to insert their slightly better version of search into people's lives without pissing off other players. It's easy to forget that Google found early success by providing search services to other companies. Once they found that initial entrance point they were able to rapidly expand and crowd out the very companies who helped them get a leg up. Google is far from the only one to use this approach. Amazon used cheap Internet book sales as a way into the web services market. Yammer worked its way into thousands of offices by allowing any employee to start a network for free without asking permission of higher-ups. There are hundreds more examples from tiny startups to large tech companies building distribution into their product in order to get a foothold and then starting to expand.
Why are tech companies so successful at this strategy? Probably because they're often run by engineers. If you look closely at these examples, you'll see a combination of two common developer thought patterns we've discussed before: breaking off small chunks of complex problems and using lateral thinking to less obvious solutions but better solutions. Used together, the two techniques can make a company unstoppable.
Most traditional companies would see distribution as a problem to be solved after a product is finished. Once everything is built, you kick out the engineers and drag in the marketing gurus to convince people to start using it. The genius of successful tech companies is that they realize that the process doesn't have to be linear. You don't need to beat every competitor at everything, and you don't have to be finished with your product before you start to spread it. In fact, they tend to build distribution into their products as a feature from the beginning.
Facebook is perhaps the best example of this kind of logic at work. The original version of the site was almost embarrassingly simple and included just a tiny fraction of the features we use today. But it was enough to be slightly more useful than its competitors, and it was deliberately designed to be more interesting as you convinced more of your friends to join. Once it worked its way into people's lives, it had the foothold to expand into a communication tool, gaming platform and, most recently, an operating system layer for desktop and mobile web.
These examples offer a less intuitive recipe for success that any business can learn from: Think of distribution as a part of your product from the beginning, and don't try for world domination right away. Build the simplest and most useful version of your product first. Once you have a foot in the door, you might just be unstoppable.
Businesses have access to more data than ever before. This isn't necessarily a good thing. As Zynga Product Manager Kenton Kivestu writes:
There is a risk of PMs / orgs / companies over-utilizing a “data-driven” approach to the point where decision makers neglect pursuing step-function changing ideas because the “data doesn't support it.” A healthy use of this data requires a keen understanding of when to ignore it.
One way to avoid the temptation of precision is to throw it out the window entirely. Engineers have long used a trick called a "back of the envelope" calculation to examine their assumptions and avoid getting bogged down in time-consuming, precise analyses. The idea is to pose a question and answer it by making assumptions and estimating rather than trying to find the exact number. Usually, you'll either realize that you're asking the wrong question or arrive at a result that's close enough to the right answer to make an accurate decision without devoting valuable resources to finding the precise solution.
This type of question is also called a "Fermi problem," after physicist Enrico Fermi, who famously asked his students at the University of Chicago to estimate the number of piano tuners in the city. But you could just as easily apply it to a data-driven business or product decision. For more information on these types of calculations, take a look at this engineering class presentation recently posted to Hacker News. Tellingly, most of the commenters on the thread are busy arguing about whether you could actually use this approach to find the exact number of piano tuners in New York City. Somewhere else, a smart engineer has cancelled plans for his piano tuner social network without needing to worry about whether Yelp's listing of 15 is complete.
Technology is not always the best solution, because technology is not always the simplest solution. That's a truism you might not expect from a software maker, but believe me, developers are lazy, and sometimes hiring an intern or two is easier than engineering a brittle automated solution. Still, we see time and again executives making decisions based on what scales better--before they've even reached scale! Thinking that machinery is always more "efficient," entrepreneurs seem to prefer paying for technology over paying for people, even when it's clearly an overly complex solution. CD Baby founder Derek Sivers summarizes the dilemma perfectly:
When everyone else is trying to automate everything, using a little human intervention can be a competitive advantage. The problem is when business owners see wages as a cost instead of an opportunity. But people are the best cogs for version 0, because their workflow can change with a few simple directions. That lets you test and iterate quickly on the processes that power your business, validating the workflow you've set up without introducing tons of overhead. The result maximizes income, quality, loyalty, happiness, connection, and all those other wonderful things that come from real human attention.
Netflix and Amazon were both famously un-automated for years, employing human beings at folding tables to sort and send physical media. Here's Evan Baehr from Outbox, the Austin-based USPS-killer, talking about the value (and challenges) of constructing a human-powered software service--and then automating it once it congeals. From this FastCo.Labs launch story:
Last summer we met with Andy Rendich, the COO of Netflix. When Andy showed up at Netflix eight years ago, they were shipping 5,000 DVDs a day--these were DVDs in cardboard boxes and on folding tables they got at Sam's Club. Andy taught us how to do lean hardware development. And, like every other element of lean startup, we only automate or develop hardware for process bottlenecks. He showed up [at Netflix] and they had a 15-step process from intake to reshipment, all manual labor. He applied a rigorous evaluation process: How accurate is it when a human does this? What's the cost when a human does this? What's the expense of a hardware solution and what's the payback schedule? That meant a very high bar for automation. He has a nice anachronistic counsel: be slow to automate.
Breaking down complex problems into simpler parts is preferable to tackling a large schema of problems at once. There are no panaceas in software. Take media startup Upworthy as one example. By some measures, Upworthy is the fastest-growing media website of all time, but they didn't get to 10.4 million monthly unique visitors by publishing the most content or developing a complex social media strategy or constantly staying ahead of the news cycle.
But that's not some top-down strategy or hypothesis. Rather, the site has simply mastered a trick engineers have known about forever: Rather than trying to do everything at once, break down the functions of your company into smaller goals. Then put those tasks in some logical order, and focus on one at a time. For Upworthy, job numero uno is enticing surfers to visit a page on the site.
Instead of trying to build a whole viral machine at once, they simply bit off the first problem: writing enticing headlines. Once they perfected that process with an ingenious (and non-automated!) workflow, they were able to focus on the placement of their sharing buttons, and other new features for their massive audience. This reductive approach is much less magical than you may think, which you can infer from the quizzical way they introduce their slideshow on 10 ways to make viral content:
You are dumb at the internet. You don't know what will go viral. We don't either. But we are slighter less dumber. So here's a bunch of stuff we learned that will help you be less dumb too.
The path to the best solution isn't always linear. Engineers at Fog Creek software knew they needed to support both GitHub and Mercurial in their Kiln version control software. The obvious answer was to build an options page and a wizard for conversion between the two systems. Instead, Fog Creek simply made Kiln work with both simultaneously. The solution may seem obvious in retrospect, but it required a specific kind of lateral thinking that engineers are uniquely good at. Rather than getting bogged down in how to build dual support on top of their existing product, Fog Creek skipped right ahead to thinking about what the optimal solution would look like. The resulting product is far more "awesome" and useful than the usual approach would have been.
Do what's necessary, not what's glamorous. That's the lesson from this excellent profile of Twitter board member Jason Goldman:
Startups are run by people who do what's necessary at the time it's needed. A lot of time that's unglamorous work. A lot of times that's not heroic work. Is that heroic? Is that standing on a stage in a black turtleneck, in front of 20,000 people talking about the future of phones? No. But that's how companies are built.
If you come across any more good examples, drop me a line on Twitter.
[Two Captains: Everett Collection via Shutterstock]