Werd I/O

The other day I got an email from someone asking about being a founding CTO of a tech startup. I replied with some brief advice, but it got me thinking: I've been doing this for a decade now, and was creating projects on the Internet for a full decade before that. A hallmark of the teams I've been lucky enough to work with has been the ability to punch far above our weight: online magazines edited by 15 year olds that ended up being distributed by the established press; the number one linked-to site on Blogdex (remember that?); a social platform used by the most prominent universities in the world, as well as national governments and Fortune 500 companies; and a video platform used by some of the world's largest broadcasters. These are solid achievements for groups and companies that, for the most part, contained fewer than 10 people.

The web is rife with articles giving universal advice based on subjective experience. For whatever reason, there's a tendency for technical people to think, "this worked for me, so why aren't you doing things the same way?" I don't think that's usually truthful or productive, so take this post with a pinch of salt. These are my opinions, not a manual.

Nonetheless, if you're just starting out, with few resources, what advice can I offer? Here are a few things I hold to be true.

Enjoy yourself.

Few things are as exhilarating as creating your own thing from scratch - making something from nothing - and releasing it into the world. People will notice if you're loving the experience. Don't lose your joy.

Focus on people.

For "people", read: your end-users, your customers (if they're different), your coworkers.

Your satisfaction must come from pushing code to the user and building something that creates value, rather than the act of programming itself. If you don't like people, and you don't want to interact with people, don't found a startup. If you're starting a business, you need to be relentlessly social (in the human sense), communicate well, and love getting feedback. Otherwise, do something else.

This is a refrain I'll repeat many times below: communication, communication, communication. You need to communicate clearly, and you need to listen, both to your customers and your team.

This is, of course, in addition to having great technical skills. These things together will allow you to build great software.

Understand your responsibilities.

As a co-founder, you are jointly responsible for the direction of the company, and creating an awesome, valuable product.

As the technical lead, you have a lot of responsibilities and pressures on your shoulders. You need to make sure your product or service is technically as good as it can be. You need to ensure that the technical side of the operation is able to meet business objectives. You need to be a software architect, and an infrastructure architect, and a technical designer, and a lead developer. As you grow, you need to be a product manager, ensuring that everyone in the engineering team understands the business goals (and hits them), and ensuring that everyone in the business team understands the technical challenges (and has a sense of the technical realities of your projects).

Ultimately, the technical buck stops with you. If the technology doesn't work, it's your fault. That's fine, but it's therefore doubly important that you are candid with everyone in the team about technical challenges that you might face, and the requirements for success.

Pick the right cofounder.

Before you begin working on a startup, it's also important that you check if your business co-founder or co-founders are able to bring something to the table to the same degree. If you're doing all of this and picking up a disproportionate degree of the business side, you will find yourself quickly burning out, serving nobody. Be a cog, not the engine.

One particular danger is that people see you as someone who can make their ideas a reality; that you will, essentially, build what they tell you to. (In one particularly toxic situation I was referred to as "the back-room guy".) This is an employee relationship, not a co-founder one. The company needs to be a true collaboration between founders, and everyone must have the skills and focus to participate more or less equally.

An oft-quoted metric for finding technical cofounders is if they have a past record of building things under their own steam, and an understanding of the intersection between business and technology decisions. Well, guess what? That applies to non-technical co-founders, too. Do they have a past record of starting their own ventures? (They don't have to be businesses, but their own projects, and so on.) Do they have an understanding of the intersection between business and technology, and the kinds of trade-offs you have to make? They do? Great.

Build small pieces, loosely joined.

Don't fall into the trap of building elaborate frameworks or overly elegant technical solutions. Your role as a startup founder is to test and change rapidly. By building too much of a framework around your code, you lose the ability to react to customer feedback. The ideal is that you can learn as much as possible from your users, and then shift your code to take these things into account.

Nonetheless: always, always, always make sure code is commented and well-documented, no matter how little time you have to spend. Comments are part of the code, not an afterthought, and the people who tell you that decent programmers should just be able to read the source are flat-out wrong.

That you should use decent source control, issue management software, etc, is obvious. When you're starting out, a paid GitHub account should work fine. (I've used Beanstalk, Assembla, and a bunch of other things, and GitHub is more stable, is easier to use, and has the best ecosystem.)

Be proud of your system's code, but be proud of how small, nimble and well-documented it is. Don't be afraid to plug in existing, well-tested frameworks and libraries, as long as they're well suited to your goals.

Don't be trapped into caring what the cool kids think about programming languages. The only material way your choice of programming language will affect your software (within certain bounds, of course) is in the choice of people you are able to hire.

Remember design.

User experience, interaction and interface design will probably come under your remit to begin with. They are the first impression that your product makes. Don't make the mistake of thinking of them as an afterthought (or, as more than one developer has expressed to me in the past, "pretty pictures"). Design is equally as important as architecture. You need to make sure every one of your engineers - as well as the business team! - is thinking in terms of the impression the product you're all making is having on its users, rather than a list of features and capabilities. If you can, bring a professional in to help you with design. It'll make a disproportionate amount of difference (see my note about the team, below).

Expect to scale.

If you're building technology, build it with an understanding of how it'll work when it has 10,000x the usage it does now. A few years ago, there were a lot of articles warning about premature scaling, which is a danger: you can easily sink all of your time and resources into building infrastructure that scales beautifully, when your focus needs to be on shipping as early and as often as you can. Nonetheless, not paying enough attention to scalability is dangerous. The old programming maxim - never assume you're going to be able to come back to anything - certainly holds true in a startup. Ask yourself what'll happen when you exceed the capacity of one server, or five, or fifty. When scaling becomes a business need, you'll need to do it very quickly. You'll have to do work in each case, but if you've thought about it and prepared while you were building, you'll be much more agile.

Again: small pieces, loosely joined, with queues and late binding. You'll thank me later.

Don't skimp on tech, but don't waste money, either.

I've written before about my long, slow journey to Mac. I just think they're better computers: more reliable, faster, and, crucially, more compatible with the software you're probably running on your servers. They're not more compatible than Linux laptops, of course, but there you'll still run into a world of hardware incompatibilities and time-wasting fiddling that you really can't afford. Leave the tinkering to your spare time. The last thing you want to be doing is fiddling with drivers or mucking about with wifi settings when you should be working on your product or your next pitch.

Think about what you actually need. My first Mac was a 2011 Macbook Pro that I upgraded to 16GB of RAM; theoretically it's blazing fast. In fact, though, the computer I use the most is my Macbook Air, which is less than half the cost, and theoretically vastly underpowered. It just works, and the battery is impressive enough to last a coast-to-coast flight. These things matter.

On the other hand, don't buy a peripheral, or something like an iPod Touch, unless you absolutely need it to test or run your software. You don't need to be awash in computers and technology. Just buy the things that affect your business directly, at least to start with. Most of us are gadget-heads to some degree; resist the temptation to buy cool stuff because it's cool.

Strong milestones are good - but it's okay to change the plan.

A set of strong milestones, with associated tickets, allows anyone in the team to get a good sense of the roadmap. I like arranging tickets onto a kanban board, so you can see what people are working on right now, as well as the backlog. Standups are great for this, too, as long as you follow the rules and do it standing up, for a short period. Don't be tempted to devolve into a long meeting; that's not going to get you anywhere.

Sometimes, you'll find that you need to change the plan completely, perhaps to take advantage of a sales opportunity, or because you've realized you need to take a change in direction. Early on, that's both okay and sometimes necessary. You need to be okay with not sticking to the plan, and you need to reassure your team that this isn't a terrible thing. As ever, good communication is key, and it's a good idea to go into the "why"s.

Your team is everything.

When I was working on Elgg, we knew we needed a designer to help build better interactions and interfaces, and create the brand identity for the company. When we found the person we wanted, we paid him more than our own salaries; we had equity, after all, and adding him to the team would create a huge amount of value for the company.

Do your best to hire well, and never hire someone because they're cheap. Sometimes they won't know their own value and it'll work out, and sometimes you'll find someone who is genuinely under-skilled. Either way, by paying them far below market rate, you're screwing them, and that's a lousy footing to start off a relationship on. It's certainly true that you'll have to pay less than many companies, but you can offset that with the freedom that a startup can offer. (Equity and the promise of value later on isn't enough; at this stage, most potential engineers are wise enough to know that share options are a lottery ticket.) If you're creating a corporate, hierarchical environment with all the resource constraints of a startup, and not offering anything tangible in return as people, you're creating a poor working environment. Freedom, trust, and a creative environment are all motivators. It doesn't have to all be about money, although money really does help; salary should be one of the first things you bring up when you can. Employees who are worrying about making ends meet are needlessly distracted.

It's okay to let go of someone if they're underperforming. You should do it early, both for your and their sakes. Sometimes, it's just not a good fit. Nobody likes working somewhere where they're doing badly, and there's no need to be nasty about it; if it isn't working, it isn't working. It's better to end an unproductive relationship quickly than let it limp on. This is, for me, a very hard thing to do. Nonetheless, it's sometimes necessary.

Be nice, by the way. Steve Jobs was famous for yelling at people, and he wasn't alone. It's completely unnecessary, and creates a poor environment. You and your team are allies, and if something's going wrong, remember where the buck stops?

By the same token, your team has to know that if you're asking them to do something, it's for a reason. While you should always be open to the idea that you could be wrong, and interested in listening to opinions from your whole team, everyone does need to know that you have the final say, and that they need to be adhering to the milestones you've set down. (If those milestones are realistic, of course; you need to be receptive to the idea that they might not be.)

Hire well. Get people excited. Be a steward of their well-being, and give them the space to build amazing things. Don't dictate tasks; your team are your collaborators. Talk them through what needs to be done, and why. Smart people question things, so give them reasons.

One last thing: part of communicating clearly is making sure people feel like they can approach you to talk about anything. Your workplace has to be a safe place. If someone is being harassed, or feels put upon for any reason, or they have any concerns at all, they need to be able to talk to you about it without fear of reprisals. Similarly, they need to feel comfortable. If someone's making sexist jokes, or otherwise making anyone feel uncomfortable, it's down to you to stop it.

Everyone should do support.

By which I mean, everyone in the company. It's important to understand the problems your customers are experiencing, and this is a great way for everyone to get a good handle on that. But it's also important for everyone in the company to understand how the product works - something that non-technical members of the team might have less of an understanding of, as they're not in its guts day in and day out. By ensuring that everyone takes support phone calls (if you take calls) and emails, you ensure good product & customer knowledge throughout the team.

It all comes down to empathy.

Good communication is empathic. You need to be able to understand your customers, your team, and your co-founders, and react when you sense that any of them are unhappy. Tech startups may have technology running through their veins, but more than anything else, they still have people at their core. A little love goes a long way.

Good luck!

1. Elgg

I've written before about how Elgg got its name. I had just recently graduated, and due to an unwise predisposition for flippant humor, I didn't have a single serious email address to my name. I needed one in order to apply for jobs. My full last name is Werdmüller von Elgg, and a brief search revealed that elgg.net was available. I used ben@elgg.net as my email address for years, without any web presence - so when I wrote a prototype social networking platform for education, it made sense to put it there.

Nobody was very comfortable with the name. Alternatives that were suggested over the years included Learning Landscaper, but none of them stuck. Past a certain point, the project was well-known enough that changing its name would have been silly; and anyway, it was a short, easily-memorized domain name.

Imagine, though, if we'd decided to call it Learning Landscaper. While that fit our original idea, Elgg morphed quickly from a social eportfolio engine for capturing informal learning into a multi-purpose engine that anyone could harness in order to create a social networking site. Had we picked a more domain-specific name, we would have limited our scope automatically, and possibly even unconsciously. Had we picked a more rational name (Engine, for example), we would have possibly isolated Elgg's large non-English-speaking userbase, and cut out a huge number of opportunities to talk about it. I lost count of the number of times someone asked us "what does Elgg stand for?" - it was unusual, and people were curious about it.

In fact, my only real regret is that I no longer have use of my ben@elgg.net address.

2. Latakoo

A latakoo is a kind of African lark: a bird that flies high and fast. For a service that allows people to send media footage quicky from and to anywhere in the world, that makes some thematic sense. But there's a good chance you might have never heard of a latakoo before.

When we were brainstorming names, a close contender was Cloud Compressor. The "cloud" was a big innovation back then, and latakoo achieves the bulk of its speed improvements through data compression. On face value, it makes sense. But not only is it a lifeless set of words, like Learning Landscaper, it thematically contrains what the company does.

Today, compression is just one part of the Latakoo service. It's still core to what we do, but we use it hand-in-hand with advanced routing, access permissions, and both service and datacenter integrations. We take media footage via any Internet connection, and deliver it anywhere, in the format it needs to be, securely. That's in no way covered by Cloud Compressor.

Our customers use us as a verb: "latakoo it". That's both a wonderful endorsement of our service and something that would only be possible with the right kind of name. What do you think YouSendIt were after when they changed their name to Hightail? Try to construct an elegant sentence involving sending something with YouSendIt. Now, switch it out to Hightail. "Hightail it". The kind of word you choose matters, because the sentences people use to describe you affect the way they think about you.

3. Idno

Lately, I've been spending some time with Idno, which I started in order to explore what a social publishing engine might look like on today's web.

It's another weird name, whose origins lie in the very unlively term ID node. I lopped off the de, because I wanted the word to phonetically end in a vowel. The idea was to create something that was at once friendly (I think ending in a vowel makes it feel like a nickname), reminiscent of terms like "ID", "id", "know" and "number", and weird. (It's also sometimes used as an acronym for in desperate need of, and a shortened form of I don't know; neither are bad connotations.) My idea is that people would remember idno in a way that they might not remember a more normal name.

We'll see what happens. I've been talking about perhaps changing its name while I can, but part of me likes having a name that's a little unexpected. Maybe that's because I have a bit of a weird name, too, but I genuinely think that standing out and being a bit skew-whiff to everyone else is a positive trait. There are situations where choosing a very conservative name is appropriate - for example, when your customers are, themselves, very conservative - but typically in technology you want to be seen as innovative.

And the way you are perceived starts with what you choose to call yourself.

Rereading the Guardian article about Elgg, I'd forgotten this detail, which is true:

The idea was conceived in late 2003, when Ben Werdmuller and Tosh were working at Edinburgh University developing e-learning and e-portfolio systems. Werdmuller (an avid blogger) persuaded Tosh (who had just started a PhD in e-portfolios) to start a blog of his own to support his studies. Within a week, Tosh had received comments on his blog from people pointing him to relevant resources and others bloggers had begun to link to him.

Dave and I shared an office at the University of Edinburgh. He was skeptical about blogging at that point, so what I told him was this: start a blog, post every day, and leave a meaningful comment on someone else's blog every day.

I wasn't sure that it would work, but thought that it probably would. Sure enough, within a week or two, he was part of the global elearning community, and was participating in conversations with its thought leaders. It was through this medium that we put out the initial white papers (completely unofficially) that provided the basis for Elgg, which went viral in the elearning community.

Could that happen today? I'm not sure.

The turning point for my first startup came one rainy Friday afternoon, in February 2007.

As TechCrunch reported:

A new open source cross-site social networking service called Explode launched today and looks like a very appealing alternative to the now Yahoo! owned MyBlogLog. Built by UK open-source social network provider Curverider (whose primary product, Elgg, is similar to PeopleAggregator), Explode offers an embeddable widget that links out to users’ respective profile pages on any social network but allows commenting and befriending in one aggregated location. I found Explode via Steve O’Hear’s The Social Web, one of my new favorite blogs.

Steve O'Hear had written:

Although comparisons with Yahoo's MyBlogLog are inevitable, Explode isn't primarily intended as a way to turn an existing blog into a social network, nor as a way to monitor traffic. Instead, think of it as a loosely joined network that works on top of existing social networking sites and blogs, to allow a user of one site to 'befriend' and communicate with a user from another.

Curverider co-founder, Ben Werdmuller, says that Explode is very much a 'work in progress', and that they are already working on an API, and also have plans to add support for OpenID.

Dave Tosh and I had been working on Elgg for three or four years at that point, and had obtained a two-person office above a bookstore in Summertown, an affluent area in North Oxford, awash with coffee shops and restaurants. Our startup was fully bootstrapped; not a single penny of investment had been put in, except for our own work, and the non-monetary support of the people around us.

As Februaries in England can sometimes be, it was a cold, overcast day, with nothing to recommend it. Because we were bootstrapping, we had been working hard, as always, and we were exhausted. Also because we were bootstrapping, our waistlines had seen the effects of long hours in front of the computer sustained only by relatively cheap food, so we'd decided to buy ourselves gym memberships and try to go regularly. (I think we managed eight or nine times.)

As we worked out, we decided that, screw it, we weren't going to work on Elgg for the rest of the day. There was nothing to be gained, we were feeling kind of burned out, and surely there had to be something more fun we could do.

Elgg was a full-blown social networking engine, and although we later completely rewrote it, it was still a pretty powerful piece of software used by companies and institutions all over the world. And I had a simple idea.

When we got back, I got to work widgetizing all of Elgg's functionality: writing templates that would take pieces of its output - the friends list, for example - and embed it in JavaScript such that it could be made to display on any website. This was back when people still had websites where people could embed HTML and JavaScript, and the effect would be that any website could be part of a larger social network. That wasn't a small idea: it captured questions people were already having about siloed sites, and would later be tackled by projects like Google Friend Connect. (Of course, the IndieWeb movement is answering those questions today.)

Dave created a template for the site so people could sign up and get their widgets. At the last minute, we created a logo. I made it in about 5 minutes in MS Paint, which seemed appropriate for a hacky site, and we both agreed that a ridiculously bad logo was probably good: it captured the scrappy ethos of the whole afternoon project.

After four hours of work in total, we made it live, and pinged some people we knew, like Marshall Kirkpatrick, who at the time was a TechCrunch writer (now the CEO of the excellent Little Bird), and Steve O'Hear, who had previously written about us in the Guardian. For us, it was a bit of a lighthearted thing we'd put together at the end of the week, and we didn't really expect anyone to cover it. To his credit, Dave proactively got in touch with everyone anyway.

Boom. Steve wrote about us, and then Marshall wrote the story on TechCrunch. This was more coverage than the tech press had ever given us.

The fact that we had executed quickly on our idea, which in turn had developed out of having worked on social networking platforms for years, mattered. The fact that we didn't try and make it perfect, or spend ages putting it through careful design cycles or product feedback loops, was unimportant. We had a working first version, and we put it in front of people, who thought it was compelling. This directly led to many more customers for Curverider, as well as our first investors, who got in touch because they had seen the coverage.

Those four hours of work - and the quick decision to muck about, be creative, and follow our whims for an afternoon - literally changed the fate of our company, and both of our careers.

If you can get shit done, you can get shit done.

If you're in technology, there is nowhere else in the world to be. Period. The critical mass of talent, investment and employment opportunity mean that - if you're the kind of person who already has the skills and circumstance to be able to make something out of nothing - you can thrive here like nowhere else in the world.

For years, working on Elgg, potential investors would tell us, "move to San Francisco". Our advisors told us that. Some of our customers told us that. And we didn't listen, because we believed that we should be able to create the same kind of opportunity elsewhere.

You can create opportunity elsewhere, but San Francisco is a special kind of place. Need to talk to the person who created product or technology X and get their advice? You can have a coffee with them, almost guaranteed. Need to learn about a product, or get investment feedback, or find top-tier developers? This is the place to be. In other words, if you're here to make money, be surrounded in technology and other smart people, and create something quickly, you're golden.

It's not for everyone, and probably not forever, but it has its place, and I'm not unaware that being here is a privilege all on its own.

The fact that it's beautiful, the weather is pretty good, you're less than an hour away from incredible national parks and world-beating wine country, and it's highly connected with the rest of the world doesn't hurt either.

But more: there's a buzz in the streets, the restaurants all serve amazing food, there's music from every bar doorway and little snippets of culture and history around every corner. I work on the edge of Chinatown, and walk to get coffee past Francis Ford Coppola's restaurant on the edge of North Beach. The echoes of beat poets still hang in the air. Every house is an individual, and the stores are idiosyncratic and independent.

These things are what made San Francisco appealing in the first place, and it's these things that I'm worried will be lost.

For me, one of the most interesting aspects of #xoxofest was the humility on show from people like Evan Williams, Maciej Cheglowski and Cabel Sasser - people who, in my mind at least, have "made it", and should be happy, successful and singing on hillsides with butterflies. Instead, each of their presentations was introspective and personal in different ways.

Frank Chimero captures one facet of it well in this amazing post:

After several talks, an unstated theme began to emerge, providing fuel for many of the stories and ideas expressed throughout the two days. It was often hinted upon, but only directly stated in Christina Xu’s talk. It came out as bright and searing as magnified daylight: “Independence is lonely.”

Independence is lonely.

When I moved to the San Francisco Bay Area, I did so for personal reasons. My mother has (had?) idiopathic pulmonary fibrosis, an incurable disease of the lungs that causes progressive scarring until you can't breathe anymore. I wanted to be close to both my parents to support them, and to spend more time with them. It was a good decision: I was there when she had to be bumped up to two refrigerator-sized oxygen concentrators in parallel in order to be able to breathe, I was there when she had her double lung transplant, and she's lying on my sofabed right now, in readiness for yet another session at the hospital.

So I have no regrets, even with everything else aside. However, you've probably noted that the San Francisco Bay is not the worst place in the world to be if you're making software. Legends have been made here. The people here have have made the world change over and over again - even before the computer revolution - and will do so many more times. I want to be in that mix. Call it egotism, but I believe I can help the world change, too.

But I was lonely.

Now, it's true that I wasn't fully independent, or alone. I work for latakoo, an enterprise video management startup based out of Austin, Texas. I'd been working with them first as an unpaid advisor, and then transitioned to lead their technology team. However, they were all in Texas, and I was all the way over here. Flights and Google Hangouts are useful, but they're not quite the same as having a ready-made community to plug into.

I've always liked to have my own projects, but the last big self-owned project I'd helped to start - something called Elgg - had not ended well. It still continues to be widely used, and I'm still very proud of the work we did, but the startup we'd founded with it succumbed to a series of bizarre interpersonal issues that I still don't fully understand. It's a shame, because we had been successfully bootstrapping, and had succeeded in a way that I think most web startups wouldn't be capable of, from a standing start with zero knowledge.

Those interpersonal issues were killer. There were, through the course of Elgg's evolution, a number of what felt like attempts to subjugate me in importance in the company, and in the project. I was threatening, I think, which is bizarre; if you've ever met me, you'll know that I go out of my way to be un-threatening. (And I was responsible for building the project, which is still in use in two national governments, Fortune 500 companies, etc etc.) In the end, though, it was a disagreement over a fundamental business direction that made me leave; I realized that it could never be profitable under its current heading, and I realized I didn't have quite enough clout to change this on my own. The company faded away less than a year later, and Yammer, a company that took exactly the direction I wanted to head in, was sold to Microsoft for a billion dollars.

So it goes. I left in 2009, just as the web was becoming more mobile; it was something you accessed from everywhere, rather than on your desktop or laptop. So I started to build something called Outmap, which would let anyone create, curate and crowdsource sets of geographically-tied data, and then share and access them from wherever they were. My two big use cases were (for the free version) crowdsourcing lists of free wifi access points using Twitter, which was a big issue at the time, and (for the pro version) being able to take biological species counts using a smartphone.

But then there was a kerfuffle with some people, because they felt that perhaps I shouldn't have been creating any social software at all after Elgg. All software is social, of course, and it was really an attempt to bully me into doing some things I didn't want to do, having already been bullied into doing some things that I also didn't want to do. They had a lot more money and power than me, though, which meant that I wound up shelving the project.

All of which brings me to San Francisco in 2011, feeling utterly burned-out about my own projects, and feeling shy about connecting with people in the industry because I was no longer doing the thing I was vaguely known for. I was forced to be a talker rather than a doer; something I strongly dislike. I had left my girlfriend behind in Edinburgh, I was dealing with a dying parent, I was in the midst of my startup's scrabbling-around phase (trying to find the right product-market fit), I was personally losing money every month because of the phase we were in, and I didn't know anybody at all. Without realizing it, I lost faith in my ability to create things on my own terms. Reader, I was miserable. For a year.

This is where community becomes important. Finally, in an act of desperation, I put out a message saying that I was having trouble meeting people (although, yes, that was mostly because of my own barriers). Tantek Çelik responded, inviting me to a microformats dinner in the Westfield Dome, where I had some great conversation with him, Kevin Marks and Ariel Waldman, and we collaboratively ended up submitting a pull request to Elgg, to get its profiles to support appropriate microformat markup.

A month or two afterwards, I went to XOXO and found a community of independent makers and doers who were creating things on their own terms using the power of the Internet and were improving their lives in the process. In a quiet corner one evening, I cried. And then I made a resolution: I would give myself time, every day, to build my own things again. In November, as part of NaNoWriMo, I wrote a novel.

That Elgg pull request was eventually rejected, and it was as a direct result of this that I found myself writing the first code for Bonita and then idno, and then eventually presenting my platform at IndieWebCamp. It was a lot more than a simple social platform that embodied some technical principles; for me, this journey has been more symbolic. It's been about taking my life, claiming some ownership, and rearranging it to be what I wish it to be.

(An important note: I have no ill will towards the current Elgg team at all, which is, in my opinion, doing a great job.)

I wrote the database and object code for idno while I was spending my evenings in my mother's recovery apartment, while she was getting slowly better after her invasive surgery. A couple of commits were from the ward after she was readmitted. I wrote the interfaces when I had moved back to my own apartment, and was still waking up every night with flashbacks from the day of the operation. I presented the first version - chickens! - when I was finally beginning to breathe again on my own terms, and was wondering what the rest of my life would look like. And now, I'm getting ready to release.

For me, the #indieweb movement has been about software, sure, but it's more importantly been about meeting amazing people and once again being a part of a human movement. I have found my community in San Francisco, and I am no longer lonely.

They say that to have real satisfaction in your career, you should feel like you're making progress on meaningful work. More and more, I feel that way about my life. And it's helping me with my work on latakoo, my interpersonal relationships, and the way I feel about the world.

The power of XOXO isn't in the things that people are making on their own terms, although the things they're making are incredible. It's in the sharing of those things, and in the motivation to create, and in the community.

For both the #indiewebcamp and #xoxofest communities, I can say this: I'm proud to be there.

It was an honor to present Idno to the W3C Workshop on Social Standards: The Future of Business in San Francisco last week.

My position paper, The Indieweb as a Minimally Viable Platform, was previously posted on this site. It speaks for itself: the decentralized social networking technologies evolving as part of the #indieweb, I believe, are perfect for exploring and testing new social workflows and interactions without significant resource expenditure. In enterprise situations, this is key: too often, technology stacks are dictated by committee, and user experience becomes subservient to a growing list of untested needs. Silicon Valley startups know that you need to validate your ideas before you invest too heavily; it's time that enterprise caught up to this approach.

Conversely, larger organizations do have a different set of needs, and it's important to incorporate those into software designed to serve them. Security is often paramount (as it should be), and most large organizations won't consider running software on third-party clouds, or that "phones home" with aggregate statistics about their data. As it happens, those are some of the values that the #indieweb shares. It's also Elgg's largest market, and it's clear that there's still a need for a simple to use, off-the-shelf, fully self-hosted platform that enterprises can use to facilitate social communication internally. Idno's intent as a replacement for Elgg that works with modern web standards continues to be vindicated.

Some comment was made about how the #indieweb presenters at the event had to overcome their fear of the enterprise to get there. That's very far from the case. I've been working on easy-to-use enterprise software for almost ten years, and I continue to be passionate about bringing the ease of use and fluid social interactivity of the rest of the web to that market. I believe that the #indieweb community's work is very applicable, intend to help get it there, and know that I'm not the only one.

Thanks to Harry Halpin, Mark Weitzel and the Programme Committee for inviting me. I learned a lot, and had fun meeting everyone.

Also posted on IndieNews

In 2004, I quit my job and spent six months working on Elgg full time, burning through my savings. My living room became my office, and I quickly learned I had to find a way to stay motivated and un-distracted.

I'd worked from home once before, of course, when I was doing my degree. As a student, my brain was scattered; I never figured out how to block out the world around me and concentrate on what I had to do. Partially that was because I was still figuring myself out as a person; partially that was because the Edinburgh University environment itself was sub-optimal for me. It often seemed like nobody was concentrating on the work they had to do.

For the first month or two, I'd sit and stare at my computer, make myself some food, listen to music, go for a walk - anything but actually get started on work. It'd sometimes be 3pm before I put down a single line of code or even write an email.

For the nine years since then, I've mostly had to be self-motivating. I've learned a series of very simple techniques that keep me working, let me achieve my tasks, and allow me to stay relatively sane while spending lots of time by myself. Some of them probably work just for me; some of them might be more universally helpful. Everybody's different. Nonetheless, here they are.

Don't be macho. Burning the midnight oil on a project makes you sound like you're super hard working, and it can be pretty satisfying while you're doing it. But not taking care of sleep, exercise, nutrition and your social life will very quickly impact your performance. You'll probably find that your work from 3am isn't quite as awesome as you thought it was at the time - and you'll struggle to concentrate for at least the next couple of days. Keep relatively regular hours, and take care of the rest of your life. Take regular vacations, too; downtime is good for your creativity. (The one semi-macho thing that works really well for me: sprinkling my day with regular exercise. I always walk 10,000 steps a day, and if I start my day with 100 decline crunches and some push-ups, I feel much better than when I don't. It's not hard to work yourself up to that point, either; trust me, I'm hardly what you'd call athletic.)

Drink water. Sounds dumb, right? But drinking water improves concentration. For one thing, you're keeping your brain hydrated. But coffee - or worse, sweet drinks like cordials and sodas - will set your off on a spike-and-crash pattern that gets in the way of steady thought. Bonus: drinking plenty of water through the day will also help you sleep, which also helps with concentration. It's the little things. And for the same reason:

Don't eat junk. I mean, duh. I've found that eating lighter food during the day, with plenty of vegetables and protein, results in much better work. (If possible, cook for yourself.) Actually, my biggest problem is not eating enough: it's easy to under-consume calories when you're eating things like salad. You need to give yourself enough fuel. Meanwhile, while I think they're delicious, meals with a lot of meat or carbs tend to send me to sleep. Not useful.

Find music you love. Now that we've taken care of your body, let's talk about removing all those distractions. For me, that means plugging in some ear buds (or immersive headphones; the point is to block out exterior noise) and sticking on a playlist. Usually, I'm into artists like Ani DiFranco, Hamell on Trial and Eels, but when I'm working, those don't work for me at all. Instead, I've found - and again, this is purely subjective - that the best concentration food for me is stoner music. Groups like Nightmares on Wax, Mr Scruff, Lemon Jelly: perfect. There's something about the slow beats that block out the rest of the world and promote concentration in just the right way. I consider my Spotify subscription to be one of my most important productivity tools. I've built a coding playlist, which I often use to seed a radio station. I guess one reason why stoner music works for me is that a continuous sense of calm is helpful. (It's worth saying that I don't actually get stoned, and don't recommend it.)

Don't be interrupted. Turn IM, IRC, your phone, off off off, unless you absolutely have to be contactable. If you share your home with others, let them know that when you're working you shouldn't be interrupted unless it's really important. That can be really hard to understand, and I've seen (other peoples') entire relationships disintegrate because of it. It might seem like a small thing to people who aren't in the zone, but it can take 30+ minutes to regain your concentration after you've been interrupted. (I find that even seeing people around me doing non-worky things is disruptive.)

Sit up / stand up. Working from the sofa doesn't work. Don't try it. And get up and walk around for at least 5 minutes out of every hour.

Accept that you're human. If you're bashing your head against a problem or a piece of work that doesn't seem to be budging, there's nothing to be gained by continuously, fruitlessly hammering away at it. Go for a walk; have a glass of water; focus on something that isn't your screen. When you come back to it, you'll have a much better chance of getting something done. Furthermore, everyone has bad days, and they don't make any of us feel good; if you're really getting nothing done, it's okay to go get some fresh air instead (if you can).

Find your motivation. Finally, figure out what makes you excited to work. For me, that's getting feedback, so I'll often release my work early - sometimes a little too early. Knowing that there are people - a manager, a client, users - looking forward to seeing the work I'm doing is spectacularly motivating. Other people are motivated simply by creating something beautiful, or finding an elegant solution to a problem. Again, everyone is different. It's important to understand your own goals and desires. It may help to figure out how to mark your own progress, beforehand, so you can maintain a sense of momentum.

This is probably the most important thing for me. It's not enough to have a job; I've got to be working on something that has meaning for me, in a situation where it's possible to make an impact. If I believe that the project I'm working on isn't important, or there's no way to succeed, it's all over for me. Nobody likes working on a treadmill.

All the usual advice about working with great teams comes into play here: if you're working with other people, make sure they're great people. One bad apple can poison a team, and I've certainly seen situations where one guy's poor attitude ruined an entire startup. Working at home is still working - in addition to the above, all the usual workplace tips apply.

Finally, regarding keeping your brain running, this article from the New Scientist is pretty good. I don't think I like the idea of smart drugs, but there are some solid tips here.

Written with the help of Georgie St Clair, Jonny Miller, SamarKaushal, Jaqueline Png, Danae, Joachim, Julien Genestoux, Paul Birch, Domenico Perri, Jamie Bullock, Annalyn Aguilar, Ahmed El Gabri, Kristian Kruse, Linda Mork, Zoe M. Gillenwater, Gordo, Mike Sirrah, 不能淋雨的眉毛, Niall Thompson, olga_zagorzelska, Antonella Iselli, Jack Smith, ntlk, Aisha Rawji, Lowfill Tarmak, sanjaypoyzer, Thomas Kjemperud, Chloe Nicholls, Paul Sturrock, Stef Lewandowski, Johnathan Leppert, damnitnicole, Robin Lynch, Emarcroft, fee plumley, Jeri Dansky, and Erin Jo Richey

The photo was taken in 2007, when I was working on Elgg.