Software factories vs software universities

April 29, 2013 | Leave a comment

I’ve worked in startups for almost my entire career – sometimes my own, sometimes companies started by other people. I’m good at what I do, and I love it: I get to create tools that empower people to do things they previously couldn’t, or that were substantial obstacles. Usually that involves some kind of democratization; a righting of an inequality of access. I love creating these platforms, I love watching people use them, and I love evolving them in partnership with the people who use them.

I’ve become more aware that some of my friends in technology startups aren’t having the same experience. We all love technology, but while I find working on it liberating, they find it soul-destroying. They complain about disconnects with management, and that their opinions aren’t listened to. (It makes me feel lucky to work in the environment I do.)

I’m contacted by a lot of recruiters and IT consultants (spoiler: I don’t think I’ve ever used any of them), and over time I’ve become aware that the way in which they talk about technologists is another side of the same coin. They complain about – or often solutions that address – the same disconnects, but from a management perspective.

It’s a mistake to create a them-and-us divide, and it’s impossible to say “this is what developers need; this is what management needs”. Nonetheless, a little empathy goes a long way, and with very little thought about the requirements of the different positions, it’s easy to see why these disconnects occur, and mitigate them.

Great developers are experts in discrete logic. They sit and write logical expressions that represent a desired experience, and don’t just have to think about how that logic resolves, but also about every single thing that could possibly go wrong. It’s not a million miles away from being a lawyer, and computer programs aren’t a million miles away from contracts. Both need to be logically watertight even given contextual circumstances that the author hasn’t thought of; both need to be usable; making a complicated program/contract simple to understand and use is not a simple challenge. Both professions have a reputation for being difficult to get along with.

Finally and most importantly, writing both software and contracts is a creative act. If you want a high quality product, you don’t just do it by numbers. Great developers and great lawyers are artists who are constantly learning and building on their skills. (The distinction blurs even further with user experience developers, whose job is, in part, to translate discrete logic into an emotional response.) They are not simply back-room technicians, and their ideal workplace is something akin to a well-paid university, where they can learn, create and innovate in a nurturing environment.

Startup founders and managers are, in my experience, significantly more financially motivated than developers. (You need to pay everyone competitively, but founders want to sell, whereas developers are often happy finding new, interesting ways to make something work.) This is important. While, depending on their background, they may not have the same grounding in logic as a developer, this isn’t to diminish them: they’ve probably got lots of other skills that the developer might not have, not least an ability to market and sell, and hopefully, a strong sense of vision. (Indeed, if your founders don’t possess these properties, you’re probably in trouble.) Nonetheless, often their ideal workplace is more like a factory, where a decision is made and everybody falls in line.

It’s silly, in a way, because everyone should be – and should feel like they are – all working on the products and services they’re trying to create together. The problems lie in how these two perspectives collide. Inexperienced managers, particularly in smaller startups, micromanage. They want to know every little thing, and want approval on every decision, which in turn means that developers will need to explain the logical underpinning behind their decisions. Worse, they may have to explain why a proposed solution won’t work. Unless these situations are handled delicately, the former has a high chance of making the developer feel undervalued, while the latter may make the manager feel like his or her authority is being undermined.

This is one of the reasons that so much startup literature focuses on hiring correctly. It’s not that some people are wrong and shouldn’t be hired; it’s that you, as a manager, need to feel like you trust them to make the right decision. A hands-off approach (combined with both clear communication and discussion about goals) for a creative, skilled knowledge worker will empower them to make stronger decisions, and make better software. Your main jobs as a manager are hiring correctly and maintaining infrastructure and an environment where your employees can be productive.

Meanwhile, on the other side of the spectrum, a professional developer needs to understand that everyone is a part of the business, and keeping the company afloat is something everyone needs to be concerned with. It’s important to bear those management motivations in mind – they have a fiscal responsibility to the company and its employees – and not think of business considerations as somebody else’s problem.

Given the right environment, that shouldn’t be a problem. If a developer feels like they are trusted to be creative, and to make the right decisions to create software of a very high standard; if their skills are a correct fit for the job that needs to be done; and the environment is such that they can ask questions and provide feedback without fear, and comfortably get work done; if you promote a culture of empathy and try to make sure everybody is valued; then you’re already a long way down the road of reducing that friction and making sure that people love to make great software with you.

It’s a tall order. But nobody said running a startup would be easy.

Punching above your weight

March 1, 2013 | Leave a comment

I wrote about doing great work at a small startup like latakoo over on Quora:

This, for me, is the essence of a small startup. From that hunger to build something that solves a problem for people, to the fact that everyone is doing a little bit of everything – whatever needs to be done, whether it’s taking a new corporate client through the administration process, or emptying the dishwasher.

You can read the whole post over here.

I really like the Quora blog system. So much so that I’ve restarted my old blog, The Internet is People, over there (although this will remain my primary blog).

Recipes for startup failure

November 20, 2012 | 4 comments

Technical co-founderPaul Graham’s essay, How to Get Startup Ideas, is long but very much worth reading. Normally I’d pull a quote, but it’s a valuable piece from start to finish, and it’s hard to know what to choose. Go read it, then come back.

He makes clear that, more than anything else, if you want to be a tech entrepreneur you need to live in the future and build what’s missing. That’s an important idea, which we can break into parts:

  • Have a great idea
  • Build it.

Sounds simple, right? But that second bullet is the hard bit. It’s not anywhere near enough to come up with a great idea, although you can’t have a great startup without one. (Paul has some valuable thoughts on this, including turning off your “sexy” filter and allowing yourself to see problems whose solutions are going to be a pain in the ass for you, but valuable for your customers.) You also have to build it.

This is a complicated field, on which a lot has been written. But I think there are a couple of things that will never allow you to build a successful software-based startup.

If you’re not a geek, don’t outsource the product.

Forget what you may have heard about IT projects. Building a technology company isn’t as simple as coming up with the idea, sending a plan to an outsourcing company and then reselling the result. Not only will your technology be frozen in time, with the outsourcing company effectively holding all of your value (you’ll need to hire them again to make improvements, and it’s important to realize that software products are never actually done), and not only does it send a clear signal that you don’t really care about your product, but it’s also a certainty that no outsourcing company cares as much about your startup as you do. An outsourced software product will always be inferior to one produced in-house by a dedicated team.

There are no shortcuts. Your startup must know how to code. And you, as a startup founder, must learn enough about the technology to be able to make informed decisions. Don’t hand it off – and if you possibly can, learn to code yourself. It’ll be worth it, and as long as you can think logically, it isn’t as hard as you think.

(One quick special note: if you instinctively recoil from the idea of learning how code works, or DNS, or servers, or any of the fundamentals to running a technology company, don’t get involved in tech startups. Those things are the building blocks of your product.)

If you are a geek, don’t make the mistake of thinking it’s all about the code.

This is the mirror image of the above mistake. Building the product is important, as I’ve just laid out. But a startup isn’t a webpage, a service or an app: it’s a company. The temptation, particularly as a single founder or a small team of developers, is to spend all your time working on awesome code that works well. But, equally importantly, you need to nail down the fundamental framework of the business you’re creating.

How do you work? How is your company incorporated? How will you sell your product and market yourself to your potential customers? How will you find those customers? How can you grow? You can’t code the answers to these questions, and if you’ve never started a company before, you’ll find that they’re far harder than building software (because these are new challenges). You’ll need to be empathic, unless you’re building software for a million people who are just like you. (Hint: there aren’t a million people who are just like you.)

As far as the product goes: get something working, fast, and then iterate on it, while you work on the tough stuff. You’re a coder, so you probably don’t read manuals, but get used to not knowing stuff and having to test it in the real world. That’s how companies work. There’s no such thing as sitting in a dark room and – ta da! – coming up with a world-beating company that’ll make you millions. Any story that says otherwise is a lie (because the company in question will have worked out that it’s a great way to sell people their product).

(The geeks get a special note, too: design is marketing. It’s how people perceive your product. If you’re a back-end coder, not only will you need to learn the spreadsheet side of your startup, but you’ll need to learn how to make a clean design, too. You can’t outsource this, but luckily, projects like Bootstrap and Glyphicons help. Get a real in-house designer as soon as you can.)

Your business is the product, and your product is the business.

You can’t do just one. Starting a technology company is an amazing experience – but if you’re a spreadsheet person, you’re going to have to get used to looking at the technicals. And if you’re a technical person, you’re going to have to get used to looking at the spreadsheets. That’s just how it works.

Startups and growth

September 22, 2012 | Leave a comment

Y Combinator founder Paul Graham’s essays are invaluable if you want to be a part of the startup ecosystem. His latest, Startup = Growth, is required reading, and defines, once and for all, the difference between a “startup” and a “new business”:

A startup is a company designed to grow fast. Being newly founded does not in itself make a company a startup. Nor is it necessary for a startup to work on technology, or take venture funding, or have some sort of “exit.” The only essential thing is growth. Everything else we associate with startups follows from growth.

[...] Starting a startup is thus very much like deciding to be research scientist: you’re not committing to solve any specific problem; you don’t know for sure which problems are soluble; but you’re committing to try to discover something no one knew before. A startup founder is in effect an economic research scientist. Most don’t discover anything that remarkable, but some discover relativity.

You should read the whole essay over here.

What’s important to remember is that this is one model – you don’t have to go the Y Combinator / venture capital route if you don’t want to. If there’s one thing I learned at XOXO, it’s that a lot of people are earning a living in a lot of ways: there’s many routes to covering your costs, living a sustainable life and doing what you love. Patrick McKenzie and Amy Hoy are worth paying attention to here – as is virtually every successful technology project on Kickstarter.

Next Page »