Peter Nixey

A few days ago I received an email from Rob Bishop, the CEO and founder of Magic Pony. The email said that as a shareholder of Magic Pony Ltd. I would shortly be expected to sign a series of documents agreeing to their acquisition by Twitter Inc. Today it was announced that the company was acquired in a deal that TechCrunch’s reported from unconfirmed sources as being worth up to $150,000,000.

The reason I was a Magic Pony stockholder was that three years earlier I’d received an email from Matt Clifford and Alice Bentick asking me to meet for dinner. Alongside Chris Mairs and Chris Wade they invited me to become one of Entrepreneur First’s new, part-time partners. 

Away weekend with Magic Pony’s EF batch (many other great companies contained)

Magic Pony was one of the companies that came out of the EF batch I worked with. Rob and Zehan’s cutting edge work in computer vision and their success in recruiting an incredibly strong team of PhDs meant that today, only two years after the company’s inception, EF will reportedly make over a return of well over a hundred-fold on their initial investment. It is a massive credit to Rob and Zehan that they pulled off the technology and the exit and did both in less than two years since the company’s inception.

EF is similar to YCombinator in taking a small percentage of each business for their capital investment. However their investment model is strategically different and tactically evolved to cope with the limitations of the European market. YCombinator takes pre-formed teams of smart entrepreneurs with pre-existing business ideas and often pre-existing businesses. Matt and Alice at EF recognised though that such a constraint would fatally restrict the ability of Entrepreneur First to attract sufficient talent from the more sparsely-populated European technical scene.

They knew that seed investing would be a numbers game and to get scale they’d have to recruit talent directly and individually from universities and jobs. Their hypothesis was that it was possible to form teams before the founders had either an idea or a founding partnership. Magic Pony was a company formed by two very smart young men from exactly that hypothesis. Neither of them even knew each other before EF. Today their union was so significant that Twitter’s own founder, Jack Dorsey announced their acquisition.

Six years ago, Heroku became first of YCombinator’s $100,000,000+ acquisitions. There had been a few YC acquisitions prior to Heroku but it was the first really big one. Its sale to Salesforce signalled to investors that YCombinator was a very real investor producing very real companies. Heroku’s exit wasn’t an acquihire, there was something real happening here. Investing in YC companies was about more than simply fuelling the ecosystem. Investing in them meant real returns.

And YCombinator’s returns were about to get greater still. At the point Heroku exited, both Dropbox and AirBnB had already been funded by YC and were putting down roots that would come to be worth over $30Bn. Not only that but Patrick and John Collison, fresh out of their first, small YC exit with Auctomatic had only a few months earlier been accepted into YC with Stripe. There were already three Unicorns growing in the stable. 

Heroku’s acquisition rang the bell that woke Silicon Valley’s angels from their slumber and accelerated everything to light speed. Funding rounds went from taking months to weeks or even days. Prices went up and YCombinator’s ability to fund even more companies increased. As more companies went through YC, attracted by the brand and the advice, so more exits happened, yet better founders were attracted and yet more unicorns emerged. Sam Altman now estimates that YC funds a billion dollar company once per 80 companies. Or to put it another way, twice a year.

Magic Pony’s acquisition should be ringing the same bells for investors in Europe. Magic Pony will not be the last exit in this range for EF and I have little doubt that within a few years we will see the fund’s first billion dollar company emerge. I would expect a smart fund to index invest across the whole of the emergent EF portfolio in the same way that Sequoia and A16Z started index investing across YC. Prices are cheap right now and it is still a buyer’s market. 

There will be very big winners from these years. In time to come prices will increase and access will get harder. Companies will expect more from their investors. Right now they will demand only money. In years to come it will be harder for unknown Angels to even get access to the hot deals. Today is the opportunity to become in London what Chris Sacca and Ashton Kutcher became through those early years of YC and make a name as a brand-name Angel.

The companies coming out of EF now will be demanding real, valley-like valuations. And well they might. It takes capital to fuel such high growth. I know investors in London who thought that the Series A valuation of Magic Pony was too high. They stayed out and invested in companies they felt were cheaper. I find that a very strange strategy. Had they invested in Magic Pony’s series A, they would have made a 30x return. They could have invested at over twice the valuation and still made 10x. Staying out of it made them nothing. And had Magic Pony failed they wold have lost the same amount of money whatever the valuation was.

Seed investing in tech is different to seed investing in almost anything else. The returns and the timeframes are just so different. As a seed investor in high tech your job is to optimise for one thing and for one thing only which is being in the winning companies. I only fully internalised this when hearing Ron Conway speak. His point was that when you make 1,000x returns on your winners it only matters that you have 999 or fewer losers. When asked how he felt about frothy valuations he said he wasn’t too fussed. He observed that valuations go up and down with the heat of the market but don’t affect the logic of the investment itself. It never makes sense to stay out of a probable winner simply because the valuation higher than you prefer. Tech is not like property where investing over the market rate means you can never profit. Tech multiples are huge. Making 500x rather than 1,000x is neither here nor there. The only thing that matters is making sure you’re on the mega-ships when they dock.

After being approached by Coca Cola to start my new company, Copyin.com, I had to resign my role at EF. As an alum though I am incredibly proud of what Rob, Zehan and Entrepreneur First itself  have achieved and what they continue to achieve. EF is the single most important force of change in the technology scene in Europe today. I am confident that its presence will ultimately result in billions of pounds of value and thousands of jobs created. These are exciting times and there are fortunes to be made for early investors, entrepreneurs and employees alike. All of the people coming into EF companies right now stand powerfully positioned to become the technorati of years to come. Well done EF, well done Chris Mairs who I know put a huge amount of work into this deal and most of all well done Rob and Zehan and their team. An amazing result all round.

There’s a a really interesting discussion unfolding right now between Paul Graham and Tim O’Reilly on the Wealth Gap and whether or not economic inequality is really a bad thing per se.  

I used to believe that the argument against wealth inequality was unsubstantiated and largely fuelled by jealousy. I believed (and still do), that economic inequality is a natural consequence of increased economic leverage. If the most successful people are becoming more effective and the least successful remain consistently ineffectual then you get a divergence in wealth. If the baseline is zero and the top line goes up then the two of them diverge.

And it’s not just the rich who become richer. Over the last 50 years the whole world has become a much better place to live. Health, wealth and education are up across the board. That’s happened because our economies are more efficient and more effective. The people who run the businesses that drive those economies have benefitted proportionally. Is it really such an issue if a few people get rich so a lot of people can get wealthier?

I used to think not. Now I’m not so sure. Because what comes with a wealth gap is an empathy gap. And when people lack empathy they treat each other in ways they wouldn’t want to be treated themselves. Often those ways are bad and when you treat someone badly enough they dislike you. If you continue to treat them badly they hate you. And when people hate each other bad things happen.

In order to find out more I tried to read a book on the topic. I didn’t succeed because it annoyed me so much I had to stop reading it. Most of it was arguing that poverty was bad (obvious) and that wealth per se was bad (not true). Most of the arguments against disparity were that things would be better if the poorer had more cash. But, as Paul Graham points out, that is not the same thing as saying that inequality is bad. What it says is that poverty is bad. And that’s something that I don’t think anyone would argue with.

The book was annoying and convinced me of nothing. However I had a lingering, unsubstantiated feeling there was a fundamental danger in the haves moving further from the have-nots. It was actually only only when I watched Neill Blomkamp’s Elysium (an allegorical story of the US/Mexican dichotomy played out in a futuristic, dystopian earth orbited by a utopian, man-made paradise) that I realised what it was and how I’d already seen it play out my own life. When the gap gets too large, empathy dies. And when empathy dies things get very bad.

As a career entrepreneur, most of my adult life has been spent with very low and extremely unpredictable income. I never wanted for anything during childhood but as an adult I’ve put everything I’ve ever had into my businesses and there have been many, many months when the stress of pennilessness rang like tinnitus in my ears. When buying bread and milk spikes your cortisol you’re in a bad place.

Essentials are the least stressful part though. What really hurts is the discretionary spending and what kills you is the forced discretionary spending. Unless you hermit yourself (as I did for three years during my twenties), it’s hard to get away from the social impetus for that spending. When you would walk a mile rather than take a $2 bus ride, buying a round of drinks cuts you like a sword. I wanted to punch a guy in the face when he asked me for a $20, double Talisker. He had a well paid job as an engineer with Nvidia. I had $20,000 on a credit card. How could he not realise the position I was in. How could he not realise that I’d literally spent ten hours walking across the hills of San Francisco to save the money his whisky cost me.

Imagine you ordered a drink and when the bill came it cost you $500. Imagine how sick that would make you feel, how it would ruin your evening. I had so little money at that point that that’s exactly how I felt. It ruined my night and I honestly hated him for it.

And yet eight years later I did basically exactly the same thing myself. I was back in San Francisco. This time I was there as an advisor to the Entrepreneur First cohort. These were all 20-something, first-time, unfunded entrepreneurs. I’d organised for us all to go out to dinner in the Mission. We weren’t at a particularly expensive place but when the bill came, every single one of the fifteen people there wanted to split it item by item. I found it intensely annoying to end the meal in such a tedious way and dismissed it suggesting that we just divide by the number of people.

But then I remembered that each of them was on a stipend of $1,600/month. They had to use that money to fund both both themselves and their companies. Meanwhile I was making $1,000/day contracting. So whether I was up or down on a $30 meal didn’t really matter to me. I didn’t have any empathy with their situation.

Not only that but I also ate and drank more. They were all budgeting, I wasn’t. So I wasn’t just being unsympathetic, in my carelessness I was also getting this crew of scrabbling start-uppers to subsidise my splashy lifestyle. Only, that didn’t occur to me because I didn’t feel the pain of expenditure the same way they did. I forgot the same pain that would have hurt me viscerally seven (or even two) years earlier. Yes, I was That Guy (though I subsequently paid over my share).

The powerful thing about empathy is it stops you from accidentally hurting people. You feel their pain as if it was your own. And that stops them from them hating you. And that’s good for everyone. That guy in the bar hurt me and made me hate him because he didn’t empathise with my situation. I made those young entrepreneurs stressed because I didn’t empathise with theirs. And both those things happened because we were economically removed from each other and lacked empathy.

Empathy doesn’t care about absolutes, it’s only the relative that matters. If you’re all rich or you’re all poor then it’s all cool. It’s only when you’re different that things get screwy. I have a very successful friend who’s CEO of a company that you will have probably heard of. By any normal standards he’s very well paid but many of his friends have sold their companies and made tens of millions. He’s now no longer able to keep up with them and finds himself resenting how much they will spend on a holiday or a meal that leaves him high and dry.

Boo hoo I hear you cry, poor him. It must be so hard living on a decent salary and not able to keep up with centi-millionaires. But unless you’re earning less than $3,650/year then boo hoo, poor you. Because you’re already earning more than 75% of the rest of the world. How does anyone in the UK or the US have any soap box to stand on when 20% of the world lives on less than $365/year? The UK government gives job-seekers $4,200/year in cash alone and that’s aside from housing and healthcare which is of course free. If you live in the UK you made it into the top 25% most wealthy people in the world even before you got out of bed. Well done you. 

But the fact that you’re richer than most of the world doesn’t matter because let’s be honest, what matters is how much you have relative to those around you. 

When you feel the pain of financial stress you feel the pain of financial stress. Is the suicide of the man evicted from his bedsit any less stressful than the suicide of the man who can’t pay his children’s private school fees or the teenager who can’t afford the right trainers? Stress and distress are stress and distress, who are any of us to judge their intensity.

Any of us feeling poor would probably immediately feel better if we were hanging out with the Syrian refugees currently camped out in Calais. We’d be grateful just to have a country to call our own. Small comfort to the financially suicidal in their hour of need though. Were they “rich and entitled” or “poor and needy” as they left this world? It all depends on your perspective.  

The reality is that as long as you’ve locked in the first two levels of Maslow’s hierarchy then it’s hard to say that you’re poor in absolute. But that’s not to say that you’re not poor relative to those around you and that’s not to say that that’s just as distressing.  Fairness and equality is deeply, deeply hardwired. In this incredible experiment it’s shown that even monkeys will demand equal pay for equal work. Hardly surprising then that inequality enrages humans. 

So while I always thought a wealth gap wasn’t a bad thing per se; now I’m not so sure. Maybe, like me at that dinner table, the larger the wealth gap, the less we notice when we take more than our fair share. And the less we notice ourselves doing things that make people hate us. Or hating people for things they never meant to hurt us. If the guy in that bar had been a student, I like to think he’d have never asked me for a $20 drink. If I’d been out to dinner with those entrepreneurs only two years previous I’d have been delighted to itemise the bill. 

I’ve never met a wealthy person that hates the poor but I’m shocked by the number of people I know who hate the wealthy. I never really understand why since none of them have obviously suffered at the hand of the “rich”. But then it doesn’t have to be something obvious to add up. Like the annoying housemate who eats all your ketchup, it just has to be occasional, careless or callous to eventually accumulate into a ball of righteous fury.

So to come back to Paul’s essay I think that his points are right, it’s not the wealth gap per se that’s bad. However I do think that the Empathy Gap is a bad thing. And the Empathy Gap is truly a problem with the distance between the two ends of the spectrum and independent of where either of them are. And for that reason I think a Wealth Gap is probably a bad thing too.

Most people don’t enjoy pain. If I held your hand over burning candle you’d haul at me to pull it away again. You wouldn’t even need to see or know that it was a candle to react to it. If I crept into your room and held it under your hand as you slept, you’d still instinctively yank your hand away. We are hard-wired to avoid pain.

But while annoying, pain is also useful. If I entirely removed your sense of pain you’d start to suffer some pretty bad wear and tear. Pain is nature’s way of telling us to get out of danger. It's good at keeping us from socially awkward situations like casually sawing off a finger while chatting to friends over a steak dinner.

Stress has a similar effect on us. It’s a stimulus that causes us to get work done and to get it down fast. We tend to exert it on ourselves and others to create a discomfort that gets things done. Stress is not nice but like pain, it’s a powerful motivator and when used carefully is a useful corrective influence.

Over the years I’ve noticed that experienced and inexperienced founders have very different ways in which they experience stress. Experienced founders feel stress from the things that are causing pain to their company. Inexperienced founders tend feel stress from the things that are causing pain to themselves. Experienced founders have nervous systems that are directly wired into their company's pain: the company is a voodoo doll for themselves. When the company is hurting, however non-obvious it may be to the rest of the world, the founder hurts too. Inexperienced founders tend to feel only their own pain which is all too often a trailing indicator for that of the company.

A classic place where you see these differences is in the initial product release.

John-Rhys, a fresh-faced young founder from Swansea is building a new SaaS CRM system. John-Rhys used to work at an agency. He loves building software but he’s sick of building software for clients that won’t invest fully in design and he wants this CRM to be gorgeous. He knows exactly what he thinks the market wants and plans to make sure they’re perfect before releasing them. It takes him eighteen months to get the first version and it’s pretty stressful making sure that everything’s as attractive as he’d like. Eventually though he puts up the registration form and convinces TechCrunch to do the cover story. Sadly the product fails eight months later because customers wouldn’t use it without email integration and they ran out of cash before they could complete that.

Hannah, the founder of an ad-tech company based in East London, has done a couple of startups before. She’s built plenty of product over the years and her experience has been that excellence is simply what comes from repeated rounds of customer testing. She can’t wait to get the first feedback from her customers because she’s not entirely sure which features they should double down on and which they should cut. She also knows that given they have only eighteen month of runway, they will need to start fundraising in twelve. To be ready for that she needs at least eight-months of customer engagement. The four months before their first release is a pretty stressful period because there’s a lot to do and she breathes a sigh of relief when the first customer support tickets start rolling in. Eight months later she has five paying clients on the platform and confidently begins her Series A fundraising.

Both founders were stressed but while Hannah’s stress prompted her to get the product out and into users’ hands, John-Rhys’ stress caused him to lose a massive eighteen months before launching. It also meant he invested too deeply in aesthetic design instead of testing the product with users and discovering how critical email integration was while they still had cash to build it.

Hannah’s stress came from things that were painful to her company, John-Rhys’ stress came from things that were painful to him. John-Rhys simply wasn’t attuned to what was hurting his company.

It’s not easy to feel the pain of a company. Company’s are not human-like creatures you can easily empathise with. You can’t even anthropomorphise a face on them so how on earth do you empathise with them?

One technique for feeling your company’s pain is having a good picture of what a healthy, well-adjusted company should look like. And that means planning. Plan for and visualise what success should look like. Look at where you need to be by your next funding round or milestone and work backwards to see where that puts you today. Find companies that are similar to yours and see what their trajectories were. What are the metrics, the hires and the partnerships that it will take you to get there. What’s the lead time to get those? The clearer you can visualise where you need to be, the more you can feel the discomfort of not being there. No plan survives first contact with the enemy but failing to plan is planning to fail. It’s only once you have some sort of a plan that you can feel the pain that comes from knowing you’re not sticking to it.

Startups are inherently stressful places. Founders tend to consciously and subconsciously generate stress in order to spur themselves onward. I think it’s hard to get away from that - it creates the discomfort that forces you to do a lot quickly. Make sure that the stress creates an impetus to do what’s  best for the company though and not merely from what is best for yourself. Wire yourself into the nervous system of your company. Use the stress to to pull your hand back out of the candle. Also you possibly shouldn’t let me into your room at night.

Everyone knows the importance of hiring well. Everyone knows that the people they hire will set the culture and the prospects of the company. Anyone who has ever worked in a company has seen that the characteristics of that company are the manifestation of the team that works there. The kindness, diligence, discipline and efficacy of the company all flow from the corresponding characteristics of the team that operates it. Great people beget great people. However many entrepreneurs fail to grasp the corollary to that. They fail to realise that their strengths are the strengths of their company. And so are their weaknesses. Their work ethic, their skill set, their interests and their values will be the same skill set, interest and values that will manifest throughout the company. What the founders are the company will become. It wasn’t until I was working to sell my first company that I really grasped the significance of this. I started to see that great engineers produced great engineering companies and that dreamers produced companies that never quite delivered on those dreams. And I also realised something very sobering. I realised that I didn't have the DNA to build the type of company I wanted. At that point in time, my characteristics didn't contain the characteristics of the company I wanted to build. I think that my younger self thought I might find such characteristics in the people I hired (actually a younger me thought that he already had those characteristics). However Joseph Smarr, an amazing engineer once said to me that “it easy to hire down but very hard to hire up”. And so I realised that while I might get lucky, I should assume that my best characteristics would also be my limiting characteristics. They were both the best and the worst in those that I should expect to be able to hire. At the time I was a saviour-driven entrepreneur. I believed in the saviour-feature, the saviour launch, the saviour investor, the saviour meeting. Many entrepreneurs think that way. Films teach us to believe that that's how it happens. They start off with enthusiasm and gusto, have a serious setback a third of the way through that causes us to sit back and re-evaluate. Then, following an eye-of-the-tiger training-montage we go on to snatch the final prize in a flood of glory, Hans Zimmer orchestrals and wingman soundbites. That's not how real life works though and I was still to learn how destructive such a saviour outlook actually was. I was still to develop the stamina and focus it takes to do the many small and boring things that will never feature in any montage but on which a company is built. I was still to become the entrepreneur that was capable of leading the company that I actually wanted to build. I was still to become someone that *I* would aspire to work with. I happened to be in Dropbox's office when they went to pitch for Techcrunch 50. It was a high-visibility conference and if it had been me up there pitching I would have been prepping for the two days before, practicing and changing it up hour by hour. If ever there was a saviour moment to savour it was pitching for the finale of a big conference. Drew and Arash, the Dropbox founders, did none of that. They spent the morning programming, they went to the pitch, fumbled it, took second place and then came straight back to the office to carry on working. Dropbox did nothing but work relentlessly, day-in, day-out on making the product perfect. Drew and Arash aren't splashy people, they're engineers and so they created an unsplashy company full of engineers. Their DNA replicated itself out and throughout their company. Virgin, by contrast is a very splashy and flashy company. It's sexy, adventurous and edgy just like Richard Branson. Zappos is a caring, community-driven company focussed on metrics, efficacy and culture building just like its founder, Tony Hsieh. These companies may be outliers and reflect extreme personalities but when you get close to most companies you see the strengths and values of the core team replicated out throughout the rest of the organisation.

It's important to remember this as you build your company. However it's critical to remember this when you conceive your company. It’s critical to ensure that what you expect to be special in your company is also what is special in you. Because if you create a company that's critically dependent on engineering and your founding team doesn't include engineers then you will have a very very hard time. Equally if you create a company like Jordan Belafort's Stratton Oakmont and your team doesn't include a ruthless, frothing-at-the-mouth-sales guy you probably aren't going to sell a lot of penny shares.

I am a founder advisor to a company called RotaGeek. RotaGeek schedules staff for companies like O2 i.e. it makes sure the right people are in the right retail outlets at the right time of day.

Jessica Livingstone recently wrote a very good article for the WSJ on Why Startups Need to Focus on Sales not Marketing. Her point was that early companies do much better by making their products work really well for a defined audience than by distracting themselves with high-scale but low-fit marketing.

Only a few days earlier I had been enthusiastically advocating exactly the opposite advice to the team at Entrepreneur First. I feel that startups should pay extremely close attention to marketing and do so as an ongoing discipline. I think that one of the biggest dangers to early stage startups is getting into a local market-minima and that marketing is an essential tool to help avoid that.

One of the team, Alex, wrote to me to ask whether the two points were at odds with each other and if not why I would stand by my original statement. I don’t and I do. Here is why.

It is very important to focus on making a product work really well for clearly identified customers. It’s painful and takes longer than you expect. But it also forces you to make software that is genuinely useful. As Jessica points out, marketing is painless and shields you from the cold reality (and insight) of rejection. A depth-first approach also tends to correlate with successful products. Or as Paul Buchheit says, “it's better to make a few people really happy than to make a lot of people semi-happy”. Worth noting that this isn’t the same thing as causation but for those of us who value building beautiful product, encouraging nonetheless.

However in the product-focussed, early-stage (pre YC) teams that I see, the real risk is not that they waste time or money on marketing. The real risk is that they end up optimising for the few users who are most easily accessible to them. Instead of exploring the wider market, these teams relentlessly iterate their product for a small number of friends, family and customers who don’t necessarily even want their product. They just happen to be accessible users.

The real risk for a product team isn't failing to make good product, it’s failing to find a market that wants it http://t.co/4fdvhuNP9f

— Peter Nixey (@peternixey) June 9, 2014

Marketing is traditionally a tool to help companies scale sales. It allows them to reach out to a lot of people and either sell them directly or soften the ground for a purchase later on.

That scalable outreach is super important to startups too; not as a sales tool but as an exploration tool. Marketing is a way for startups to quickly gauge demand for their product across one or more marketplaces. It's a way for startups to explore the territory and find their beach heads. In more mature companies, marketers complement the sales team. In early startups they should be cartographers, and complement the product team. Before you can make something work perfectly for an individual customer you need to find the individual customer to perfect it for.

Marketing in early startups is super important. Not for growth but for exploration. Marketing is a startup’s sonar http://t.co/B1K2FbogiI

— Peter Nixey (@peternixey) June 10, 2014

"Startup marketing" does not mean thousands of dollars spent on adwords budgets or expensive trade show stands either. Startups are inherently interesting and should get involved in the communities they're designed to service. If you're a developer and your community is Hacker News then you have it easy. Companies like Stripe and statuspage.io absolutely nailed their HN marketing. If your target market is Mums then get stuck into Mumsnet, if it's teaching then get stuck into the teaching community. Some of these communities are in forums, some are on Twitter some are probably just physical. Any which way though your primary marketing is simply Getting Involved. It won't get you all the way but the relative ROI is huge.

One of the companies I advise, Rotageek, provides excellent scheduling software for organising staff schedules. The team spent years honing the product and making it right for the NHS here in the UK. One of the founders, Chris, worked in emergency medicine and saw the pain and cost of manually organising staff. Being an entrepreneurial sort, he teamed up with a friend to create a piece of software to address that. He knew the problem intimately and worked hand in glove with the NHS, evolving the product and optimising it for their needs until one day he realised they just weren't going to pay for it. They would happily string him along and may eventually, possibly have bought but that point would have been long after the company finally ran out of runway.

However the moment that Rotageek switched from optimising the product for the NHS to casting their net out wider, they started to find companies who really were hungry for the software and more than willing to pay. The team is now scaling for a huge rollout and all because they started marketing the product widely enough to find people who really wanted it. Even now they still only have a relatively small market sampling. While retailers are extremely receptive to Rotageek, they may not end up being the best market for the company either. Without reaching out to new markets and without casting their nets wider, the company will never discover that.

One of the hardest and also the most useful things I’ve ever done was door-to-door book sales in West Virginia. I did it with a friend as a summer job at University. We learned a huge amount about selling and how to sell. The sales scripts and the sales school were both brilliantly designed but despite all the technique, the scripts and the schooling, one simple lesson was hammered home again and again: “The quickest way to convert a disinterested customer into an interested one is knock on five new doors”. The point was that finding the people who really want to buy from you is more lucrative than obsessing over those who don't. To find that customer, the one that's really hungry for you, you need to first of all knock on a lot of doors.

Most teams focus on Product Search & optimising product. Just as important is Market Search & finding optimal market http://t.co/B1K2FbogiI

— Peter Nixey (@peternixey) June 9, 2014

.

You should absolutely go deep and optimise for your target market be careful not to optimise prematurely. There is someone for everyone on the internet. You can find people who are willing to eat you and even people who are willing to be eaten. When you find those customers who really want to you (hopefully not for dinner) then follow Jessica’s advice: go deep and deliver exactly what they want. Until then though, remember Annie Lennox’s advice and that “everybody’s looking for something”... “Hold your head up, keep your head up, movin' on”.

As with my previous post this is taken from an email I sent round to our team today

I've spoken about this with all of you individually now but I'd like to get it down and into Copyin too.

Up until recently we've been using "2-week plans" to give us each a longer horizon on the work we're doing. Those have been combined with weekly "Plans, Progress and Problems" reports to give us a way to plot and chart our progress.

As an early startup, we operate on such a tactical, day-to-day basis that the two week plans were originally a useful way to help orient ourselves with where we each wanted to go in the "longer" term. However once we introduced weekly PPPs they started to feel redundant. The two week plan was turning into just twice a PPP and not adding any value to us.

The PPPs do an excellent job of making sure we're moving forward they don't really do a lot to check that we're going in the right direction. Which is where Objectives, Goals and Strategies come in.

Objectives goals and strategies are a way of determining the exact value-add that we want to commit to (objective), how we plan to deliver the value add (strategy) and whether we succeeded in doing so (goal).

Objectives

The qualitative outcome we want to achieve e.g.

make sure that people stay active on Brojure

increase the number of people being exposed to Brojure

make the editor easier to use

Goals

These are the hard numbers that determine whether we have actually met our objectives. They're a way of making our objectives achievable and failable.

(examples of goals that relate to the above objectives)

increase the proportion of new users who create a 3rd Brojure from 1% to 20%

increase traffic to the site from 500 uniques a week to 5,000 uniques per week

reduce the time it takes to create a Brojure (with known content) from 15 minutes to 5 minutes

NOTE - these should be achievable (not ridiculous) and also failable (you should be able to tell whether you actually achieved them. e.g. "make editor better" is not failable)

Strategies

These are the ways in which we are going to delivery our goals.

Note that the strategies are the ways in which we achieve our goals. They are not the goal itself. Failing to recognise this distinction is why many people and companies remain busy without really achieving anything. They assume that the work is the goal. Working is not the goal, it is merely a means to achieving the goal.

Let's look at possible strategies for achieving the goals we set above:

Possible strategies for increasing # users who create 3rd Brojure from 1% to 20%

after each Brojure send them an email with a trick they can use for a new Brojure and a prompt to start the next one

pick a vertical and funnel users through 3 particular uses of Brojure for them e.g. for a restauranteur encourage them to produce: 1 Brojure for their menu, 1 Brojure for Private Events, 1 Brojure for the restaurant's history (sounds like a crappy strategy to me but it is at least an example of one!)

add a "to do list" in the editor encouraging users to "complete their to-dos" one of which is making 3 Brojures

allow people to copy Brojures and tweak them for someone new

Possible strategies for increasing traffic to site

guest blog on other people's publications

buy google adwords (needs further constraints to ensure that the strategy is economically viable)

make identifiable improvements to SEO

get guerrilla and go into communities to spread the word

Possible strategies for decreasing time it takes to make Brojures

fix image upload bug

allow people to copy an existing Brojure to create a new Brojure

pre-load Brojures with content

allow people to save content snippets that can be injected into new Brojures

add more Javascript interaction to the editor to literally increase editing speed

What Objectives, Goals and Strategies actually do for us

The idea is that each month we will decide on our actual objectives. This is one of the most important parts of the process. It's very easy to just churn through work without moving forward and so before we decide what we're going to do we first decide what we want to achieve. Product is one place that can benefit hugely from this part of the process. It's incredibly easy to queue up lots of features without any of them actually impacting us and end up with a set of features for the sake of features.

Once we've done that we then get honest with ourselves and ask what will tell us whether we achieved that outcome. We set our goals.

Finally we look at the strategies we're going to use for achieving those goals. How will we execute?

OGSs will be set at the start of each month

The Objectives will become something that will require solid teamwork from us. If we take an objective like "increase Brojure completion rate" then it may require Dash to create an email strategy, Peter to implement changes in the editor and Tomas to design them. Similarly "Increase the number of people engaging" may mean Ollie has to do do more phone calls but that Dash needs to create a new sign-up email type and that Tomas needs to tweak the landing page design.

This is nice in that it begets collaboration which is fun. However it could also go badly wrong. If we choose goals badly they will be dependent on multiple people and we could fail on all OGSs simply because a critical member of the chain was not able to give their support to all of the strategies they were required for. If Dash is on the hook to do an email component for every other person's strategy then he could end up over-committed. If he's overcommitted then he won't succeed and everyone fails. Whose fault was this though? Who can correct it when it becomes clear that it's starting to happen? Not Dash's because he was over-committed, not everyone else's because it was Dash who failed to deliver. This is NOT a situation we want to find ourself in (or put Dash in).

If people can't independently deliver their goals then they get demotivated & tasks sink to the lowest common blocker http://t.co/CM9l5aSzoD

— Peter Nixey (@peternixey) June 5, 2014

Goals should hold individual people (or teams but at our scale it will mostly be people) responsible for delivering and should afford them the autonomy and resources to do so.

Objectives will be set company wide, goals will be individual

For this reason we will decide on company wide objectives but each goal will relate to a particular individual. We will choose goals such that individuals can execute on them, can take credit for them and can can be held responsible for them.

There is one exception to this in that Tomas and I have discussed this and because his design work is currently so strongly coupled with my dev work we will work as a unit on product. I'll go on the hook for both of us :)

Any questions, concerns, objections just hit me up or reply to this email.

This is taken from an email that I sent out to our team earlier today.

Some jobs in life come to you - answering phones, answering emails, responding to requests. They turn up and you process them. As long as you spend the day processing them then you’ve done your work. These tasks keep us in place, they stop our businesses unravelling, they maintain our status quo. If we already have a company, a revenue stream and a business model then that is exactly what we want. If we do not then it is exactly what we do not want.

In a big company, your job is to maintain the status quo. If all eBay does for the next decade is continue to be the top online marketplace and make 9% profit off all transactions they will have succeeded. Most of that work is reactive - keep competitors at bay, acquire them when they get too feisty, make sure systems don’t go down: as a friend from eBay once told me: “the main thing people care about here is making sure we don't fuck it all up”.

However if, over the next 10 years, all our little startup does is to keep 100 users on the system with one super-user and and ten more somewhat engaged, then we will have failed spectacularly. We don’t yet have the luxury of having anything to fuck up. We dream of the day when our fuck-ups have consequences. Our fuck-ups go sadly unnoticed.

Big companies fear change because it usually means something’s gone wrong. Startups are entirely the opposite. If startups are not changing then they are dying. Everything we do is about changing numbers not maintaining them, everything is about building product, growing users, building momentum, increasing engagement. None of those things are about maintaining the status quo, none of them are about not screwing up; all of them are about gaining new ground.

We do not fail in unsuccessful attempts to take new ground, we fail in not making those attempts in the first place.

Reactive tasks are about maintaining your current position, they are about not losing ground, they are low risk. You know they’re feasible because you already hold that position, you know what the ground feels like under your feet. You know that you can probably complete that task without failing. Pro-active tasks are quite the opposite. They require taking new ground and taking ground that you're not sure can even be taken.

"in a startup, absolutely nothing happens unless you make it happen" - @pmarca http://t.co/v2TbP8yoX2

— Peter Nixey (@peternixey) May 15, 2014

Being proactive and making this happen is hard and comes hand in hand with failure. It means going out on a limb, doing jobs that risk not having any worthy outcome, doing things that may just fail to work altogether. It also requires being wrong and ideally being wrong 50% of the time.

Most of what a startup does is exploration and testing. Our goal is to find a repeatable scalable business model, our job is the search for that. We are literally discovering what works and what we can successfully repeat. We are figuring out what product our users want, who wants it most and how we can reach them. Once we have tested that then we can repeat it but first we must test it.

Information theory tells us that the optimal testing strategy yields positive outcomes 50% of the time. If on average you're right more than that then you waited too late to test, less than that and you tested too early. The goal of testing is not to prove that you are right it is to see *if* you are right.

But optimising to be right 50% of the time means optimising to be wrong 50% of the time and that is 100% more of the time than most people can handle.

It's easy to respond to an email, you cannot fail. It's there, it's asking you to respond to it, you already know there's an audience waiting to read it you can’t go wrong. It’s far harder to risk the rejection that comes with cold calling a customer who may not want to hear from you. Far harder to report the 0% clickthrough rate from your latest, experimental email campaign or that the blog post you spent a day writing only ended up with 10 visits.

But these are the jobs that actually move us forward. These are the jobs which, while infused with risk, are also laced with sparkly rewards. These are the crazy email campaigns that may yield a 50% clickthrough rate, the blog post that happens to resonate and generates 60,000 visitors. These are the alpha-team tasks that parachute you into new ground and from which all of the reactive tasks subsequently unfold.

These jobs are proactive not reactive. It is the outcome of these jobs that form the anecdotes we tell people at parties, they are what go into our investor decks, they are what we feed the press in interviews. These are the forays that build our company.

So - as you put jobs into your daily to-do list, ask yourself: "is this proactive or reactive"? If it's the former and it’s “tangible, fail-able and do-able" then it's probably an excellent task. If it’s not then perhaps it really does need to happen but also ask yourself whether there is another way that you to spend that time that really moves the company forward. Because maintaining the status quo means maintaining a non-existent business. We are about change.

I love this early interview with Mark Zuckerberg. I remember seeing it when it came out in 2005 and being impressed, even then, with how humble and pragmatic the vision for the service was.

The company is early enough that it's still college-only and called The Facebook. It's so small that you can see Dustin Moskovitz doing a kegstand in the background without any PRs diving in to tackle him out of the shot.

The thing I really love about the video though is Mark's total focus on product (The Facebook) and service, and his utterly pragmatic view for how it can potentially evolve.

When asked, "Where are you taking Facebook?" he gives the following answer:

"There doesn't necessarily have to be something more, a lot of people are focussed on taking over the world, doing the biggest thing, getting the most users.

I think that part of making a difference and doing something cool is focussing intensely. There's a level of service that we could provide when we were just at Harvard that we can't provide for all of the colleges and there's a level of service we can provide as a college network that we couldn't provide if we went to other types of things.

So I really want to see everyone focus on college and create a really cool college directory product that's very relevant for students and has a lot of information that people care about when they're in college. I don't know what that is and it's not everything that's on The Facebook now".

"There doesn't necessarily have to be more, I want to focus on college & create a directory prod. that’s relevant for students" Zuck 2005(!)

— Peter Nixey (@peternixey) May 6, 2014

A more powerful and succinct endorsement for PG's advice that founders should make something people want, do things that don't scale and offer surprisingly good customer service would probably be hard to come by.

Disclaimer: This is a very long piece, much longer than I would normally write on any subject. I have edited it back but on sending it to friends to read they agreed that there was no one bit that should be cut. I hope that you feel the same.

If there’s one thing that software developers care about, it’s becoming even better software developers. Where do you start though? Should you accumulate the bells and whistles: deepen your knowledge of Node and no-sequel? Should you rote-learn the answers to the profession’s gateway questions and be able to produce bubble sort or link shortener algorithms on demand? Or are there perhaps more fundamental roots that you can put down?

I believe that your seniority and value as a programmer is measured not in what you know, it’s measured in what you put out. The two are related but definitely not the same. Your value is in how you move your project forward and how you empower your team to do the same. In fifteen years of programming I’ve never had to implement a bubble sort or a link shortener. However I have had to spend thousands and thousands of hours writing and refactoring account management tools, editing suites, caching logic, mailing interfaces, test suites, deployment scripts, javascript layers, analytics architecture and documentation. These were the things that mattered, the completion of these were what moved us forward.

Those humble components are the bricks and mortar of projects and take hundreds or thousands of hours of hard work to assemble. And even though they combine to form complex systems, they themselves should not be complicated. You should aim for simplicity and over the years I have learned that simplicity is far more easily attained by time spent working and refactoring than hours of pure thought and “brilliance”.

Simplicity and excellence are most reliably attained by starting with something, anything, that gets the job done and reworking back from that point. We know this is true of companies and the concept of the MVP is burned deep into our consciousness. So too with software. Start with something ugly but functional and then apply and reapply yourself to that ugly and misshapen solution and refactor it back into its simplest form. Simplicity comes far more reliably from work than from brilliance. It comes more predictably from code written, than from thought expended. It comes from effort.

"Your value as a developer is measured not in the height of your peaks, but the area under your line" http://t.co/6JMyGvGuzl

— Peter Nixey (@peternixey) April 22, 2014

It is all too easy for smart lazy people to flash spikes of brilliance and wow their contemporaries but companies are not built on those people and product does not sit well on spikes. Companies are built on people and teams who day in, day out, commit good code that enables others do the same. Great product is built by work horses, not dressage horses.

Years after Joel coined the term “Rockstar Programmer”, it lives on along with the misapprehension that companies need such geeky micro-celebrities in order to do anything. While those characters do exist there aren’t many of them. When you do find them they’re often erratically brilliant - astonishing at the things that interest them but hopeless at working consistently or smoothly with their team.

Not only is their output erratic but their superiority is aspirational and infectious. Their arrogance bleeds toxically into the rest of the team. It signals loud and clear that if you’re smart enough you choose when you work and what you work on. You become a “Developer in Residence”. And you not only soak up a salary but you distort the values of those who work around you.

So the reality is that in all likelihood you and your team will depend, should depend not on those who think they are “Rockstars” or “Ninjas” but on reliable people who work in reliable ways.

Great developers are not people who can produce bubble sorts or link shorteners on demand. They are the people who when you harness them up to a project, never stop moving and inspire everyone around them to do the same. Fuck Rockstars. Hire workhorses. Here’s some ways to become one:

Name your functions and variables well (write Ronseal Code)

Such an incredibly simple place to start and yet I think it is one of THE most important skills in programming. Function naming is the manifestation of problem definition which is frankly the hardest part of programming.

Names are the boundary conditions on your code. Names are what you should be solving for.

If you name correctly and then solve for that boundary conditions that that name creates you will almost inevitably be left with highly functional code.

Consider the function:

It tells someone almost nothing abo

ut what it’s going to do or how it’s been implemented in the code. However:

tells someone exactly what’s going to happen. It’s also a good indicator as to what’s not going to happen. It tells you both what you can expect the method to do but also how far you can overload that method.

A developer might happily refactor “process_text” to not only convert text to HTML but to auto-embed videos. However that may be resolutely not what was expected in some of the places that function was used. Change it and you’ve created bugs. A good clear name is a commitment to not just what a function does but also what it won’t do.

Function names create contracts between functions and the code that calls them. Good naming defines good architecture http://t.co/6JMyGvGuzl

— Peter Nixey (@peternixey) April 22, 2014

A good function promises what it will deliver and then delivers it. Good function and variable naming makes code more readable and tightens the thousands of contracts which criss-cross your codebase. Sloppy naming means sloppy contracts, bugs, and even sloppier contracts built on top of them.

It’s not just functions that you can leverage to describe your code. Your variable names should also be strong. Sometimes it can even be worth creating a variable simply in order document the logic itself.

Consider the line:

It’s pretty hard to figure out what the hell is happening there and even once you have done so, it’s not 100% clear what the original author was trying to achieve with it. The variable names are horrible and tell you nothing.

The “and not” statement is always confusing to read (please never write “and not” clauses which end with a noun) and if your job was to refactor this code you’d have to do some acrobatics to guess exactly what the original intent was.

However, if we change the variables names into something more meaningful then things immediately start to become clearer:

We can go further still and forcibly document the intent of each part of the if statement by separating and naming the components:

It takes some courage to write a line like “user_is_recently_created” because it’s such fuzzy logic but we all do it at times and owning up to that helps inform the reader about the assumptions you’ve made.

Notice also how much stronger this approach is than using comments. If you change the logic there is immediate pressure on you to change the variable names. Not so with comments. I agree with DHH, comments are dangerous and tend to rot - much better to write self-documenting code.

The better code describes itself, the more likely someone will implement it the way it was intended and the better their code will be. Remember, there are only two hard problems in computer science: cache invalidation, naming, and off-by-one errors.

"If you want to be a great developer, make sure you write Ronseal Code that does exactly what it says on the tin" http://t.co/6JMyGvGuzl

— Peter Nixey (@peternixey) April 22, 2014

Go deep before you go wide - learn your chosen stack inside out

Very few programming problems are genuinely new. Very few companies are doing technical work that hasn’t already been done by 50 teams before them. Very few problems attract Stack Overflow eyeballs that haven’t already seen them somewhere else before.

For that exact reason, the majority of the things you are trying to do have already been solved by the very stack you’re already using. I once refactored 60 lines of someone else’s Rails code to a one line using the delightfully simple and powerful methods that Rails ships with.

"Most programmers waste huge amounts of time by lazily re-creating implementations of pre-existing functionality." http://t.co/6JMyGvGuzl

— Peter Nixey (@peternixey) April 22, 2014

Not only do they waste time but they create verbosity and errors. Their code requires new documentation to describe it, new tests to monitor it and it makes the page noisier and harder to read. Like any new code, it’s also buggy. War-tested (and actually-tested) stack code is very seldom buggy.

If you are a Ruby developer take time to learn Ruby, especially the incredible range of array methods. If you are a Node developer take time to understand the architecture, the methods and the mindset of Node, if you are an Angular developer go right up to the rock-face and understand the logic behind of the incredible architecture the core team is forging there right now. Ask before you invent. You are walking in the shadows of giants. Take time to find their tracks and then marvel at how beautifully they have been built. Because if you don’t, you simply punt the problem downstream and someone will just have to figure out why the hell you chose the sub-standard path you did.

Learn to detect the smell of bad code

Something I’ve noticed in programmers who are good but who have plateaued is that they simply don’t realise that their code could be better. That is one of the worst things that can happen to your personal development. You need to know what has to improve before you can figure out how to improve it. Learn both what good code looks like and what bad code looks like. It is said that grand chessmasters spend proportionally much more time studying previous other good chess player's games than the average players. I’m quite certain that the same is true for top developers.

An important part of your improvement arsenal is your ability to detect bad code - even when it’s only slightly bad or perhaps “a bit smelly”. Smelly code is code which, while you can’t quite articulate why, just doesn’t feel right.

It may be that you’ve used 60 lines of code for something which feels fundamentally simpler, it might be something which feels like it should be handled by the language but has been manually implemented instead, it might just be code that is as complicated as hell to read. These are your code smells.

It’s not an easy thing to do but over the years you should learn what bad code smells like and also what beautiful code looks like. You should develop an aesthetic appreciation for code. Physicists and mathematicians understand this. They feel very uneasy about an ugly theory based on its ugliness. Simplicity is beautiful and simplicity is what we want.

The truth is that the truth is sometimes ugly but you should always strive for beauty and when ugly is the only way, know how to present it well. If you can’t create beautiful code, at least create Shrek code but before you do either you need to develop your sense of smell. If you don’t know what good code looks like and know what bad code smells like then why would you ever improve it?

Write code to be read

I once heard Joel Spolsky say that Stack Exchange optimises not for the person asking questions but for the person reading the answers. Why? Because there are far more of them than the single person who asks the question - utility is maximised by optimising for readers, not questioners.

I think you can view code in a similar way. It will be written just once by you and you alone. However it will be read and edited many many times, by many others. Your code has two functions: the first is its immediate job. The second is to get out of the way of everyone who comes after you and it should therefore always be optimised for readability and resilience.

"Write your code through the eyes of someone who is coming at it fresh in a year’s time." http://t.co/6JMyGvGuzl

— Peter Nixey (@peternixey) April 22, 2014

What assumptions have you made, what do your methods actually return, what on earth does that quadruple nested if / else / and not / unless, statement actually select for? Sometimes you’ll need more than just good variable naming and you should ring fence it with tests but do what it takes (and only just what it takes) to make it durable. Great code is code that does its job and that continues to do its job even when git blame returns a who’s who of your company payroll.

Write every line to be read through the eyes of a disinterested and time-pressured team mate needing to extend it in a year’s time. Remember that that disinterested and pressured team mate may be you.

Weigh features on their lifetime cost, not their implementation cost

New developers want to explore and to play. They love the latest shiniest things and whether they’re no-sequel databases or high concurrency mobile servers and they want to unwrap all the toys as fast as possible, run out of the room to play with them and leave the mess for the next dev to clear up.

Dogs aren’t just for Christmas and features aren’t just for the next release http://t.co/6JMyGvGuzl

— Peter Nixey (@peternixey) April 22, 2014

Features and architecture choices have maintenance costs that affect everything you ever build on top of them. Abstractions leak and the deeper you bury badly insulated abstractions the more things will get stained or poisoned when they leak through.

Experimental architecture and shiny features should be embarked on very carefully and only for very good reasons. Build the features you need before the features you want and be VERY careful about architecture. Save toys for side projects. Every component you invent, every piece of bleeding edge, fast changing software you incorporate will bleed and break directly into your project. If you don’t want to spend the latter stages of the project doing nothing but mopping up blood then don’t use it in the first place.

Or, as a friend once tweeted

Just use Postgres. Stop being a hipster, and just use Postgres.

— Tony Million (@tonymillion) December 29, 2013

Understand the liability AND the leverage of Technical Debt

Technical debt is the code you write which, while sub-optimal, gets you to where you need to go. It’s the errors which, while annoying, are still sub-critical. It’s the complexity of a single-app architecture when you know that the future lies in service-orientation, it’s the twenty-minute cron job which could be refactored to twenty seconds.

The cost of these these not only adds up but it compounds. Einstein once said that “there is no force so powerful in the universe as compound interest”. Equally there is no force more destructive in a large software project as compounding technical debt. Most of us have seen (or built) these projects. Codebases where even the smallest change takes months of time. Codebases where people have lost the will to write good code and hope only to get in and get back out without bringing the site down.

Technical debt is an awful burden on a project.

Except when it’s not.

Like all debt, when used correctly, technical debt can give you tremendous leverage http://t.co/6JMyGvGuzl

— Peter Nixey (@peternixey) April 22, 2014

Not only that but technical debt is the best type of debt in the world because you don’t always have to pay it back. When you build out a feature that turns out to be wrong, when you build out a product which turns out not to work, you will drop it and move on. You will also drop every optimisation, every test and every refactoring you ever you wrote for that feature. So if you don’t absolutely need them; don’t write them. This is the time to maximise your leverage, leave gaps, ignore errors, test only what you need to test.

In the early stages of a product or a feature, the likelihood is that what you are building is wrong. You are in an exploratory phase. You will pivot both on product and on technical implementation. This is the time to borrow heavily on technical debt. This is not the time to fix those sporadic errors or to do massive refactorings. This is the time to run through with guns blazing and keep firing till you burst out the other side.

When that happens though; when you’re sure that you’re in the right place and out the other side then it’s time to tidy up and to strengthen your position. Get things in good enough shape to keep on rolling, repay enough of the debt to get you on to the next stage.

Technical debt is like so many other things in a startup, a game of leapfrog. Your initial code is scouting code. It should move you forward fast, illuminate the problem and the solution and give you just enough space to build camp. The longer you stay, the more of the system that camp has to support the bigger and stronger you build it. If you’re only ever staying for a week though, don’t burn time laying down infrastructure to support a decade.

Check and re-check your code. Your problems are yours to fix

Engineers who “throw code over the fence” are awful engineers. You should make sure your code works. It’s not the testers’ job and it’s not your team-mates’ job. It’s your job. Lazily written code slows you down, increases cycle times, releases bugs and pisses everyone off.

If you constantly commit code that breaks things then you are a constant tax on the rest of your team http://t.co/6JMyGvGuzl

— Peter Nixey (@peternixey) April 22, 2014

Don’t kid yourself that you’re anything less than a burden and get it fixed.

Do actual work for at least (only) four hours every day

For all the talk about self optimisation, focus and life hacking that goes on amongst developers, the simple truth is that you don’t need to do that much work to be effective. What really matters is that you do it consistently. Do proper work for at least four solid hours each day, every day and you will be one the best contributing members of your team.

However, doing four hours of work every day is harder than it seems.

Proper work is work that includes no email, no Hacker News, no meetings, no dicking around. It means staying focussed for at least 45 minutes at a time. Four hours of work a day means that one day lost in meetings or on long lunches and foosball breaks means you have do eight hours the next one. Believe you me, eight hours of solid work is almost impossible. Four hours a day on average also means you should be aiming for five or six in order to prep for the day when you only get two.

However it also means you can be a huge contributor to your team while still having a fully rounded life. It means that you don’t need to post that self-indulgent “I’m burning out, please help me” post on HN. It means that simply by being consistent you can be valued and respected.

Software teams don’t slow down because people work four pure hours a day rather than seven (which is insanely hard to do consistently by the way). They slow down because people spend weeks with no direction, or because the louder and emptier vessels dedicate their paid time to discussing Google v. Facebook’s acquisition strategies over endless extended coffee breaks.

Just work. Doesn’t matter how incremental or banal your progress seems...

Do four pure hours of work each day, every day and you’ll be one of the best people on your team http://t.co/6JMyGvGuzl

— Peter Nixey (@peternixey) April 22, 2014

Write up the things you’ve done and share them with the team

However you document things, whether it’s through a mailing list like Copyin, a wiki or even just inline documentation in the code, you should take the time to explain your architectural approach and learnings to the rest of the team.

Have a tough time getting a fresh install of Postgres or ImageMagik to work? If you found it hard, the rest of your team will probably also find it hard so take a moment to throw down a few paragraphs telling them what you did and saving them your hassles.

One of the worst parts of programming is losing whole days to battling bugs or installation issues. If you take the time to document and distribute the way you found through that you could buy five times your wasted time back by forearming your colleagues.

Understand and appreciate the exquisite balance between too much testing and too little

Testing is a powerful tool. It allows you to set a baseline for the reliability of your releases and makes you less fearful to make them. The less fearful you are to release, the more you do so and the faster you improve.

However it’s also an overhead. Tests take time to write, time to run and even more time to maintain.

Think of testing like armour. The more of it you wear the harder it is to hurt you but the harder it is to fight too http://t.co/6JMyGvGuzl

— Peter Nixey (@peternixey) April 22, 2014

You become too heavy to move, too encumbered to flex your limbs, immobile. Too little of it and the first skid across a concrete floor is going to cut you open and leave you bleeding.

There is no intuitive answer to what the right amount of testing is. Some projects require more testing than others and testing is a whole new piece of expertise you need to learn in and of itself.

Take the time to understand what really needs tests and how to write good tests. Take the time to see when tests add value and what the least you need from them really is. Don’t be afraid to test but don’t be afraid not to test either. The right point is a balance; take time to explore where the equilibrium lies.

Make your team better

This is different to the other points in that it’s not something you can action so much as an indicator of whether your other actions are working.

Does your presence make your team better or worse? Does the quality of your code, your documentation and your technical skills help and improve those around you? Do you inspire and encourage your team-mates to become better developers? Or are you the one that causes the bugs, argues during stand-ups and who wastes hours of time discussing irrelevant architectural nuances because it helps cover the fact that you’ve done no actual work?

You should make your team better. There should always be at least one or two ways in which you make those people around you better and through which you help strengthen them. However, be aware that being “smart” alone is probably the least valuable and arguably most destructive dimension you can choose. In fact, if your chosen dimension doesn’t actually make you tired it’s probably not a valid one.

It’s not who you are on the inside that defines you

There is one, humbly brilliant line in Batman Begins which has always stayed with me. At some point in the film where he’s fooling around and acting up as a billionaire playboy, Christian Bale implores Katie Holmes to believe that he’s still a great guy on the inside. She answers simply: “it’s not who you are underneath, it’s what you do that defines you”.

Your contribution as a developer is defined not by the abstraction of how smart you are or how much you know. It’s not defined by the acronyms on your resume, the companies you’ve worked at or which college you went to. They hint at what you’re capable of but who you are is defined by what you do and how that changes the project and the people around you.

If you want to be good, apply yourself.

We’ve been beating about the bush here for years, Amazon but let's be honest, it's time for you to have a key. At first it was lunchtime dates at mine. We’d both be excited and both be there early. It was forward of me to invite you over so soon but what the hell, I was in the honeymoon haze! Then of course my job got more demanding and it was harder to sync our timings. So you very thoughtfully tried finding a spot in between us to meet, somewhere where you could make it easily and which I didn’t have any problem collecting from.

The problem was though it wasn’t always easy to get your gear home from those lockers and so even they didn’t work out that great. There was just too much stuff that I wanted to avoid hulking home and the locker just didn’t really help. Then finally we go to the late night booty calls. They weren’t ever really going to last. They were convenient, sure but hardly civilised. Now it’s got a bit weird with you telling me you’re going to send stuff to me by drone. I mean it’s a sweet gesture and everything and it’ll be cool to get stuff quickly but it feels a bit unnecessary. I know you love gadgets but there’s honestly an easier way.

During today’s keynote, Tim Cook mentioned, almost in passing, that you could log into the iTunes store using the fingerprint sensor.

This statement may turn out to have way more significance than its low-key delivery would suggest. It took me a moment to realise it but the fingerprint sensor is almost certainly not about securing your device. The fingerprint sensor is about securing your account. The fingerprint sensor is about payments, initially to Apple and then maybe subsequently elsewhere. The fingerprint sensor may be Apple’s mobile answer to Amazon’s web-bound One-Click.

For every app, music and in-app purchase made through an iOS device there is at least one other that wasn’t made because someone couldn’t be bothered to type in their password, got it wrong or just didn’t know it. Amazon once measured a discernible difference in checkout rates from page loading increases of only 1/100th of a second. Apple has to request a password. That password has to secure the phone against chargebacks due to theft, purchases made by small children or just a trouble-making friend pinching your phone and playing with it. The only answer to those chargebacks today is to demand users to continually re-enter their passwords.

Perhaps even more problematic for Apple is the proportion of their customer base who don’t even know their passwords. A significant proportion of iOS users won’t be able to tell you their password and may not even have a credit card associated with it. Apple must have swathes of older, tech-challenged or simply disinterested customers who never buy any video, music or apps. Those customers are lost revenue for the iTunes store in the short term and are far more vulnerable to churning over to Android in the long term.

Because it’s not the just the revenue from apps that passwords cost Apple. Apps are what make the platform useful, apps are what tie you to your OS and many of the best ones need to be purchased. If you don’t buy apps the platform is significantly less useful to you, you’re far less loyal and you’re far more likely to be swayed by Android. Apps are Apple’s platform lock-in.

I’m guessing that this new scanner won’t just be a piece of hardware Apple ships and forgets about. I’m guessing that Apple will integrate their efforts around the fingerprint and will encourage you to setup your fingerprint and enter your credit card in the Apple store when you buy a new device. I would. They will do everything they can to encourage you to associate your fingerprint with your credit card and free you to one-scan purchase. I’m also guessing that despite its more homebound nature we’ll see that fingerprint sensor very quickly on the iPad too. The iPad is a perfect shopping tool and one-scan shopping would make that even more true.

The fingerprint sensor is way too much technology just to make it easier for you to get past your lock screen. As Tim Cook said, many people don’t even setup a PIN. I think the fingerprint sensor promises to be a far more strategic tool than simply a souped-up login. What the fingerprint sensor may actually deliver is the biggest improvement in frictionless payments since the Amazon account.

Apple has to make big bets to move the dial now and payments is one of those that many people have spoken about. Many people were waiting for Apple to announce NFC and jump into the payments space but I think they may be even cleverer than that. Payments would be a huge new revenue stream for them but easy authentication and chargeback avoidance must have been a large barrier to offering that. If the fingerprint recognition works a well as advertised, that barrier may just have fallen away.

These are the slides from the talk Taavet Hinkrikus and I gave yesterday at the O2 for Campus week and Wayra.

The talk is about how to build good quality product quickly in highly uncertain situations. It's about building product in a pre-product-market-fit startup and I like to think that there's something for everyone (over the age of 29) in there.

If you, like me, lament the fact that Craig David and XKCD sex scenes have have never before met in a presentation about product then you're going to LOVE slides #90-99 (also I hope you at least remember Craig David unlike most of the blank-faced audience I was talking to).

If you're wondering what the relevance of the Ariel Atom and a kitted-up Peugeot 206 (#106-110) is it's this. One looks like a piece of scaffolding that fell on a go-cart but goes like s**t of a shovel while the other looks, well... crap but it's owner clearly spend a lot of time on "design" while paying no attention to the fact that there's not a lot of point in it as a car. This is a metaphor.

Enjoy, debate and if you chose to upvote this at Hacker News, well then let me tip my hat to you as you're a gent sir (or mademoiselle). Gracias.

Comments on Hacker News >