The Three Hardest Words: “I Made This”

dish“I made this”, is what we say by implication when we publish, send, launch, perform or unveil work that is entirely our own. Three wonderful, difficult and daunting words.

We are the only ones who can choose when — or whether — to say them, whether to hit “publish”… whether to take the risk.

Solo entrepreneurs, writers, bloggers, artists, performers, artisans all know the feeling. But even in a team at a small startup, we may feel this to some degree because we may singlehandedly represent some entire aspect of a company, a product or a service.

Our work represents us. Once we unveil it, it is out there and usually can’t be retracted. There is no-one else to stand behind it, to share the blame or the praise. No large corporation to take the flack. No anonymity. It’s like publishing a condensed version of ourselves; a snapshot of what we are currently capable of, warts and all, for the world to see.

It takes nerve to accept feedback – good, bad and indifferent – and still stand by our work, to discuss potential improvements to it, or the inevitable choices we could have made. There is no perfect launch and nothing is ever truly “ready”.

The crucial thing is realising we did our best at the time, that no-one is 100% correct, and still being glad that we put it out there. It takes guts to realise we will inevitably want to retract, delete, smash it to pieces, or to endlessly correct it based on feedback — or the perceived feedback of indifference — but to keep it out there anyway, in its original form.

So far, I’ve done this with two software products I developed alone, this blog, photographs and other articles. I have friends who have done it with startups, artwork, experimental new food products, books and performance art. I’m proud to count myself among them because I think people who have done this are amazing.

I’m convinced that we learn more by putting our work in front of an audience than we possibly ever could by thinking and agonising about it in private, by tweaking it and waiting until we feel like it is somehow worthy or “ready”. Those lessons feed back into our next attempts, but only if we make our first attempts.

If you’re in doubt, it’s probably ready. So take the leap, and say “I made this”.

Why Time as a Solopreneur Might Make You a Better Team Player

forwardTeamwork: Good. Lone work: Bad.

Or at least that’s how the stereotype drummed into us through education and our careers seems to go. We learn to focus our CVs and resumés on our team contributions, and to downplay the things we achieved entirely alone.

But what if the things we achieved on our own somehow made us more effective the next time we joined a team? What if a balance of both experiences made for better team players?

It’s my experience that teamwork between people who have never known an occasional lone accomplishment can suffer from a few blind spots: Such team members may have an inaccurate view of their contribution and how to tune it, having only ever seen their work as part of a larger deliverable. There’s a danger of feeling like a full four-wheel contributor, whilst actually running on three wheels and being unaware how much your contribution leans on the work of others. People who have never known personal wins can see a team project as their only chance to demonstrate their abilities, and may be over-invested in personal outcomes rather than team outcomes, safe in the knowledge that they can shine elsewhere or next time.

So what do I mean by lone accomplishments? Lone accomplishments could be a product (software, hardware, anything), a piece of art, training materials, blog posts, or a book. Anything you actually launch, publish or deliver to an audience, for which the entire deliverable depends on you, and for which you have no backup or other input to assist. Anything for which there is no scapegoat once you deliver it; it is yours, good and bad.

I’ve done this twice, with software products of my own. They were far from a commercial success, but the lessons learned were worth more than the time I spent and the salary I forfeited in those months. Since then, I’ve gone back to teamwork in startups, and really appreciated the perspective that my lone achievements have given me.

So what do lone accomplishers bring to a team? How can lone work strengthen and define you?

  • People with lone projects under their belt tend to have a more accurate view of their own strengths and weaknesses, and an appreciation for the roles others perform in a company.. because they’ve probably filled them at some point, albeit probably rather clumsily. Most former solopreneurs will have noticed how they couldn’t possibly fill all those roles alone… and will appreciate that it is only possible to cover them well in a team where a variety of skillsets are present.
    For me, as a software engineer, I now have a great appreciation of the other roles involved in startup life: Marketing, PR, design, QA, Ops, etc. Prior to undertaking my own projects, I probably had a dismissive or inaccurate view of those roles.
  • People with lone projects under their belt already have personal “wins” in the bag, so they don’t feel the need to act as if the next team project is their own pet project or chance to shine. This makes conversations more about a team win, rather than a personal win, less religious, more exploratory, and more practical.
  • People with lone projects under their belt tend to appreciate the difficulties of building something entirely alone, and therefore the need for others. The mature lesson from this is a willingness to delegate… and truly delegate, giving people a long leash and adjusting it appropriately. Knowing I can’t do it alone, but might be able to achieve it with others, makes me value the contribution of others and the need to delegate effectively.

Why is lone work a rarity? Aside from the widespread celebration of teamwork, we probably shy away from lone work because we know it will truly define or break us; there is no middle ground, and so we fear it. Through it, we will either discover, once and for all, that we can lean into a challenge on our own, or that we don’t (yet) have what it takes. Unlike teamwork, there is no scapegoat, no fallback, no-one else to blame. This is a hard reality to face.

But I’m convinced that every day we put off an attempt at lone work, is a day we never really understand what we are capable of; both alone, and in terms of our contribution to a team.

I’m convinced that, particularly in industries that involve building something (software, hardware, arts), we should exercise our lone capabilities on a regular basis, and at least once a year. It’s an ongoing eye opener on who we are, what we’re capable of, and therefore what we each bring to a team.

Far from being a red flag when hiring, lone work — when properly learned from — could be the thing that truly makes a strong team player.

Distil Complexity, Nail Theory, Build Software… Just Not All at Once

questionmark

Trying to pat your head whilst rubbing your stomach is the standard way to demonstrate that we, as humans, find it difficult to perform certain activities concurrently.

The software project equivalent is attempting to overlap activities that teams find it difficult to handle in combination. It’s just a reality that some things are hard enough on their own, and so we hamper our efforts if we attempt to combine them.

It’s been my experience that projects where there is at least an attempt to separate, as much as possible, the following activities are those that experience fewer hiccups. It may still be necessary to iterate through these activities regularly, and they are not waterfall-style one-offs, but being aware of the complexity of doing more than one of them at once can help to simplify things for teams and to ensure one flows into the other:

  • Distilling Domain Complexity – Every software product is built to deliver a solution in a unique problem domain. Often, there is much to clarify in this domain, and much complexity to unravel and distil. This can be something of a voyage of discovery, particularly if it takes a while to extract that knowledge from a domain expert and to figure out which aspects of it the project will require. As building products for a market can be like chasing a moving target, it is highly likely that this domain-related activity will be revisited many times during a project;
  • Nailing Academic Theory – Beyond well-worn Software Architecture and Computer Science principles, a project may rely upon deeper academic theory, such as Artificial Intelligence, Machine Learning, Big Data… or non-tech project-specific areas such as psychology, natural language, etc. Each of these alone are huge fields, full of theory. The problem is, you can’t build software with theory, and so we need to pin down practical forms of that theory that will be implemented in software. This may involve prototyping, comparative analysis of different approaches, and finally a choice between palatable options.
    There is a tendency to linger over these decisions, and an attractiveness in remaining in that land of possibilities. However, software engineering requires knowns, not possibilities, and the sooner theory is nailed down — for this project or iteration anyway, as we can always make different decisions next time — the better.
  • Building Software – Software engineering is concerned with building stable, scalable, understandable software to meet a need. There is sufficient difficulty in doing that in isolation, without overlapping with the previous activities. For large chunks of time, teams need to focus on building software, unencumbered by academic theory or domain ambiguities. It is almost an unwritten assumption on some projects that most of the difficulty lies in the previous two activities (problem domain and academic theory), and that building the resulting software solution will be comparatively easy or, at least, will be more of a known activity. However, the complexities and practicalities of building software require that teams focus on the activity where possible.

Although we may revisit each of these activities many times during a project, identifying and managing the boundaries between them helps to isolate them from one another. One great way to do that is by creating and maintaining great team documentation: Domain knowledge and concrete decisions based upon academic theory are perfect examples where documentation can form a neat output from one activity (albeit perhaps occasionally updated), to be consumed by another. Documentation needn’t be heavy and cumbersome and writing just enough, but before it is needed, should be encouraged.

I wonder, how many times that we’ve seen projects go awry could we identify examples of these activities bleeding into one another too much? And, where projects have gone comparatively smoothly, I’d be interested in hearing whether it was because these activities were understood to be complex in combination.

I guess it’s all part of improving the task of building complex software, with a human team.

Kaizen, Innovation and the Entrepreneurial Life

10251565_830162623679537_14497031_nKaizen is a Japanese word meaning “good change”, but it has also been the basis of an approach to “continual improvement” that has been applied in many industries and as a way to drive personal change.

The idea is that incredibly small changes, made continually and consistently, tend to beat radical plans, proposals and initiatives because they work with, rather than against, human nature. Small changes bypass the brain’s tendency to fear and resist change. They also set us up to actually like the change and to want to accelerate it naturally.

It struck me recently that many of the words applied to startups and entrepreneurial pursuits are the polar opposites of Kaizen: They tend to imply “disruption” and sweeping changes carried through by radical innovations, actions and energy. But does this expectation of brave change on a huge level put our entrepreneurial dreams at odds with human nature? Are we hampering our own efforts by working against, rather than with, our brains?

What if, instead of trying to find one radical way to “disrupt” an industry, we tried to notice small things that are true about that industry, make small changes to improve those things, and to use that momentum to gradually see the bigger possibilities? What if we tried to notice small ways in which we could improve someone’s life with a product or service, and build on that? What if we tried to innovate by making a small but meaningful change to an existing product or technology and see that as the basis for a bigger change?

And when it comes down to ourselves, as entrepreneurs… What if, rather than trying to affect the various changes in character, lifestyle and approach required to become entrepreneurial overnight — as if a butterfly-like metamorphosis in human behaviour is even possible — we tried to make small changes to our thinking, attitudes and behaviour to become more entrepreneurial over time? Kaizen techniques for personal change highlight the benefits of ludicrously small changes at first, to beat resistance. Those changes tend to snowball into genuine change driven by the subtle rewiring of our brains caused by adopting the smaller changes. There is certainly less chance of us reverting to our old behaviours if we affect change gradually, and it tends to be longer-lasting.

Of-course, all this talk of small changes goes against the grain of an entrepreneurial world where we value disruption and innovation. But what if, rather than distracting us, making these small changes increased the chances that we’d actually spot the bigger and more radical possibilities? It’s certainly easier to see what’s possible when you’re moving in the right direction, rather than standing still waiting for inspiration to strike.

In our quest for disruption, bigger and better, maybe we could do with realising that small and continuous change could be the most effective way there, albeit perhaps rather a counterintuitive one.

(Image: (c) 2014, Ian Cackett)

Beyond the Geek Apprenticeship

forwardWhen you’ve immersed yourself deeply enough in programming to write a ray tracer in 68000 assembly language in your teens, it’s safe to say you probably aren’t going to become an accountant. So whilst I know some folks struggle to find theirs, my own career path was always rather obvious.

Since graduating from uni a not-insignificant number of years ago (!), I’ve been lucky enough to have worked for some truly inspiring folks at some amazing companies and on some very cool problems. I’ve had a chance to help build software for many different industries and sectors. I think that gives you a really valuable perspective on what we, as software engineers, can actually offer.

More importantly, it also gives you a great sense of what’s possible with this universal toolkit called “software”. For that’s all it is; a toolkit, and nothing more. As I’ve said before, it’s what we do with that toolkit that counts.

I’m mostly interested now in exploring what’s possible with technology, and what we can build with it to benefit each other. I think there’s a certain obligation to look up from what we’re building occasionally and to ask how it helps us. If the answer isn’t obvious, it probably doesn’t. Self-serving industries, with little benefit for those outside of them, no-longer interest me.

I realised that the earlier part of my career was probably naturally something of a travelling tech apprenticeship: You work in various corporate scenarios, learning, building and applying what you’ve discovered.

Beyond any apprenticeship, the bigger question always comes: What will you do with this now?

Unlike my initial career choice, the answers aren’t as obvious… but, if I’m open to finding and exploring them, they’re probably going to be at least as interesting.

Looking at New Product Ideas the Wrong Way

idea-comfort-zoneThe moment you’ve had a new idea for a product, something dangerous happens… You start viewing the world from the perspective of that idea; validating the idea against the world, the people in it, and the opportunities / benefits it might present to them.

Sounds right doesn’t it? Intuitively, yes. But it’s the wrong way round!

What we need to do after having a new product idea is to keep validating it from the perspective of the outside world: Keep finding scenarios into which the idea might fit, and assess it in terms of its true benefits. Keep starting from the point of view of different sets of people in the world, or different potential use cases… and look at the idea from that viewpoint. Not the other way around.

The idea must not become the lens through which we see the world. If it does, we’re blinding ourselves to the reality and we risk building something that is of little use or limited appeal.

It’s counter-intuitive because, once we’ve had the idea, it is naturally our obsession. If the idea is something we feel we could build as a product, we can get blinded to the fact that there are a billion things we could build as products… but a much smaller number of things that would truly benefit the world, and perhaps even manage to be commercial products.

I think it’s a subtle but powerful switch in perspective.

 

The Subtleties of Validating Ideas

I guess those of us following a “lean” approach to developing software product ideas talk a great deal about how we “validate”  them.

The usual wisdom is that you expose your idea — landing page or, better still, your MVP — to the world, preferably in its leanest  form possible, perform some sort of marketing activity to draw attention to it (advertising, social media, word-of-mouth), and then measure what the interest is, usually in terms of sign ups and usage versus number of eyeballs. This is intended to give you a very rough idea of the size of the market, and perhaps an informal sense of how much it might take (and cost) to “acquire” each user.

In general terms, I believe this is spot-on. But there is a great deal of idea-specific subtlety that I think you have to gauge each time you do this. I don’t think anyone can distil or teach it and I guess this is where much of the benefit of trying and rejecting ideas comes from. There really is no substitute for actually doing it.

With some (possibly almost all) ideas, validation probably requires that you go out there and somewhat coerce  a few people into becoming users of the product. This is what Paul Graham refers to in “Doing Things That Don’t Scale“. It feels unnatural for techies like me, but it’s probably an essential part of the process. There simply is no way to validate the idea itself, until an MVP is built based upon it, and even then passive validation (“It’s here, anyone interested?”) usually isn’t enough to pull anyone out of their busy lives for long enough to take a real look at what you’re offering.

Potential users just don’t often have a gut sense of whether your product is attractive to them, until they’re sat in-front of it, using it… at which point, the lightbulb above their head will either light, or it won’t. Longer-term, they might help to spread the news. But initially, you may have to wire up the light bulb yourself.

Very few products leap straight off the landing page and on to the “sign up” page. And those that do are possibly the result of a process of maturing from a much more manual marketing approach, and no-doubt took many, many iterations to get to the point where they appear to market themselves effortlessly.

I think it’s a balance though between how lean  an offering you initially run with, and how hard  you push it at people. It really is a question of learning to judge when you’ve exposed or pushed the idea way too little, versus bullying people and trying to magic up a market where none exists. Judging this is quite an art form.

Remembering To Dream Big, Again

S025-bwFrom the age when I could first put the pieces together, I built impractical things in Lego, and sometimes in Meccano. I used to dream of having enough Lego to build a castle, or a Meccano crane as tall as the house. There were no limits to my dreams, other than the size of my Lego set.

When I got into Computing I realised that, in a virtual world, there was no limit to what I could build to improve, serve and augment the real world outside. It was the ultimate toolkit. That’s how I found my passion, and my career. I count myself as immensely lucky.

Sometimes though, I wonder if I am honouring those early dreams, or whether I let them fade along the way. Have a Zone 1-3 travel card, a monthly pay slip and someone else’s dreams made me forget that being alive necessitates an element of impracticality, of thinking big… no, bigger!  Of planning things that might initially seem beyond me, then stretching to reach them. Not everything worth pursuing can be neatly described in a career plan, a yearly goal or an appraisal.

It doesn’t matter how many hundreds of thousands of lines of great Java code I’ve written, if I’ve not yet written the thing that reignites those early dreams.

I feel privileged to know some immensely passionate and brave people — entrepreneurs, artists and professionals —  some of whom are pursuing their dreams and making them real seven days a week, not just in “spare” moments snatched from a busy work schedule. I think it’s no coincidence that I’ve stayed in touch with these people. Like them, I also pursued my own projects full-time for a 2-year period recently, got a real taste of what’s possible when I focus, and realised how tantalisingly few steps there are between a software engineer like me and viable, commercial ideas.

I have, in Computing, the ultimate Meccano kit, the biggest box of Lego. It’s no wonder I regularly think, “Am I dreaming big enough?”