Category Archives: Business

Business Personal Political

On the idolatry of investors

It’s seems you can’t tune into any sort of political debate on the economy these days without a glut of commentators and politicians lining up to tell us how all our problems can, nay must, be solved by ‘attracting investors’. We must do everything we can, we’re told,  to catch the eye of these incredibly elusive and rare beasts, who are constantly on the move and always on the lookout for the juiciest pickings. They’re a different breed from us if you’re to believe the breathless accounts of expert observers; by all reports globally mobile, notoriously fickle and with the patience of a three year old after three tubes of blue Smarties. Miss your chance by making things hard for them – common faux pas by the poorly prepared include having labour laws and asking them to pay some tax – and they’ll breeze past your metaphorical begging bowl and on to more attractive opportunities. The only answer is to prostrate yourself at the feet of the investment cadre, regardless of whether you have to slash other things like health and education to do so, because if you don’t your destiny is destitution anyway. Or so the narrative goes, admittedly dressed in slightly more palatable phrasing. You’re not supposed to question this, it’s part of the doctrine of the Priesthood of Economics.

Now, having investors ready to fund business ventures is unquestionably a good thing. But if you think that this particular breed of gadfly investor – the straw man most often constructed by financial middle men and right-wing politicians in order to sell a particular philosophy – is the root of the majority of new businesses, then you’re very much mistaken.

Let’s talk fundamentals for a second. In order to launch a business, which I think is universally accepted as the engine of economic prosperity, you basically need 3 kinds of participant:

These 3 roles are pretty much fundamental, and investors are clearly present: but are just one third of the recipe. The inference by some of the narrative I often hear is that while investors are rare, precious and indispensable,  the people in the other two roles are not – if the money’s there, then we can surely rustle up people to do the other jobs, they’re almost two a penny. This is, of course, nonsense. People with good ideas, and people who can execute well on ideas to create a great functioning business, are at least as rare as the investors who would fund it, and in my opinion even more so.

My second point is that if you can do without any of the 3 roles, it’s actually the investor. It’s impossible to launch a new business without ideas, and without execution – nothing happens without these two things. But particularly in the technology space, it’s getting easier and cheaper to launch your own business thanks to cloud services, easy access to global distribution platforms, and the pace of change regularly giving great opportunities to newcomers, and often external investment just isn’t necessary in the early stages. Maybe you’ll scale using external money later, maybe you won’t – with a lot of successfully bootstrapped businesses, it often seems like they’re letting the investors on the bandwagon later not because they actually need the money, but because it’s literally being thrown at them and saying no gets boring after a while ;)

And those businesses who do launch with initial seed investment, do they get it from these nomadic global investors who only glanced their way because the economic environment was designed specifically to attract them? No. Almost exclusively they get this seed money from family, friends or business angels, people who invest because they see the potential of the idea or the people, and who are usually located in the same rough area already.

So what’s my point here? It’s that the political and economic narrative is regularly at odds with the reality that at least – at least – two thirds of the engine of economic prosperity in a community comes from its own internal resources. The kids who might grow up to have great ideas, or become really great at executing on those ideas. The kids that can build new businesses and create an engine of their own prosperity. Too many times we get caught up in a fashionable chase after the globally nomadic investor class, at times sacrificing the things that benefit the local populace in an attempt to pimp ourselves out in return for what often turns out to be frankly modest and, more damagingly, short-term returns whose conditions tend to worsen over time.  The actual effect on lasting prosperity within a community of courting fickle global investment is highly debatable – not only is the majority of seed funding for new business generated from local rather than global sources, but this funding also tends to be much ‘stickier’ – it doesn’t tend to evapourate at the first sign of difficulty, or in the face of slightly better terms available somewhere else.

Let’s think less about global fly-by-night investors, and more about the people with ideas, the people with creativity and powers of execution, and the at most the local angel investors who are here already and don’t need to be attracted with coy waves of a Geisha’s fan. The long-term returns are better anyway.

(With apologies to XKCD for my blatant imitation)

Business Internet Personal

On the Internet, everyone should know you’re a dog

One of the things I hear on occasion is the maxim ‘People buy from people’. Usually what people mean when they say this is that the only real way to sell things to people is to go meet them, shake their hands, wine and dine them, play golf with them, organise trade delegations to impress them, and so on. I’m sure that’s still the way it works in some industries, especially those which are large, slow-moving and headed mainly by the over-50s who are most comfortable negotiating over walnut boardroom tables. I hear sometimes what cuff-links or school tie you wear is somehow a relevant factor in the negotiation. Curious.

Of course when it comes to more modern businesses, particularly in the digital space, the idea that you have to meet people in person to sell them things is ludicrous – take tech companies like Atlassian for example, who exceeded $100m in sales revenue without ever having a single sales person on the payroll. When barriers to communication and trade come down, if you offer a great product or service, at a price that makes sense to people, and you find good ways to tell them about it (preferably with ways for them to try it and make their own minds up), they’ll frequently come to you and hand over the money without ever meeting you. If you do a good job, they’ll tell their friends about it too and do your marketing for you, in a more influential way than you ever could (3rd party recommendations are always trusted more).

So, the days of needing travelling salesman are long gone for many businesses. However, the maxim that ‘People buy from people’ is still actually true, it just isn’t addressed in quite the same way. Customers do still care about who they’re buying from, they just don’t feel the need to shake their hands any more. While the features of the product / service are forefront in a potential customers mind, they do still care who it is that’s producing it, and what their values are, even if only subconsciously. We enjoy buying things from people we like, and companies we can relate to, and are more likely to resent buying from companies who are much larger, faceless and treat us like an account number rather than a human being – ask people who buy from Oracle about that maybe ;)

It’s not even simply a touchy-feely issue – a company that shows it cares about its customers, and has a corporate image that suggests that it’s likely to understand a customers own challenges and goals, is more likely to give great after-sales support, and to listen to customers requests for improvements, and so on. Whether or not a customer feels that the supplier ‘gets them’ is an important indicator of what the future relationship will be like, and not just a nice warm feeling.

Of course, these are the same sorts factors that a travelling sales rep would address in the ‘old’ pre-digital businesses. Achieving this relationship in the digital domain might seem far-fetched to traditionalists, but actually as customer audiences become more and more digitally savvy it’s really not a stretch. Let’s not forget that anyone born after around 1990 probably can’t remember what it was like not to communicate online, and probably do most of their day to day communication this way. To them, the golf course is probably as alien as Twitter is to most 50-something executives around those walnut boardroom tables, but it’s these people who are increasingly your audience – if you’re not getting this yet, be aware that someone is actively moving your cheeseas we speak.

So what do you do? To truly connect with people online, you have to be:

  • Highly accessible in multiple channels (e.g. all the major social networking sites)
  • Responsive to all feedback, good and bad
  • Open and transparent
  • A real person – even if you’re inside a big organisation, people want to know who you are. You can’t connect if you’re Drone A from BigCorp
  • Collaborative – you’re not controlling the community even if it’s your product, you’re a part of it. Value people as peers and not just customers.
  • Honest. Seriously, the Internet will find out if you’re not.

Big companies have a real problem building these relationships well online, in my experience, because a large bureaucracy just isn’t designed to deliver it. Small, open, agile companies have filled the void and often kicking the older guys asses here, solidifying long-term relationships with numbers of people unheard of before in the traditional traveling sales models.

It’s a new world out there. Personal relationships still matter between suppliers and customers, but increasingly they’ll be in the digital space, and you can build them with vastly more people than you ever could before, if you do it right. People like Crowd can help you with that too.

(Image (c) Peter Steiner)

Business Development Productivity

What open source taught me about management

I was a manager of developers in an organisation for a few years, and during that period I learned a lot. But if I’m honest, I learned far more about being a manager from leading a large open source project for 10 years, because that taught me a lot about what makes developers tick. Of course, I’ve always been a developer myself too, but you often don’t think that clearly about your own motivations.

Open source developers are usually volunteers. They choose to spend their own time contributing to your project – maybe they do it as part of paid work or their own projects too, but even then it takes extra effort to contribute back in a meaningful way, since the quickest and hackiest option usually isn’t the one that will be accepted upstream. These guys are going out of their way to help, even though no-one is cutting them a check in return. Crazy? And not only that, they usually defer to project leaders or core team members, changing their contributions or beefing them up based on their suggestions even though they don’t have to. Curious?

‘Meritocracy’ is a word that’s bandied around a lot, but in open source it’s an accurate description; people only listen to your opinion, or accept your direction, because they want to, and trust you enough to respect your decisions. This is a two-way street; the leader essentially builds this trust not only through leading by example, but also by accepting feedback from others, even when it’s conflicting with their own current stance, with good grace and consideration.

Because there’s no strict ‘hiring’ process as such (it’s more of an ‘onion skin’ sort of approach where developers are given increasingly more power as they soak into the community and contribute more), and geographical locations are irrelevant, you often end up with quite rag-tag band of people in an open source project, each with their own strengths and opinions, arguably a more diverse bunch than you’d find inside a single company. This mixture of experiences, ages, cultures and languages can be a challenge sometimes, but it also brings things to the table that could really only occur when you throw this sort of melting pot together. I learned a vast amount about dealing with people just by being exposed to that variety over the years.

But most of all, I learned that motivating smart, creative people can be done entirely for free – you just have to have the right attitude.

A lot of managers seem to believe that carrot and stick techniques coupled with metrics and monitoring are the best way to ensure employee productivity. You can encourage people with salary and benefits, make sure they work hard by applying metrics on time and task completion, have disciplinary proceedings when those goals aren’t met, and so on. You have none of those in open source, and yet great work gets done anyway – by some metrics, projects can be equivalent of millions of dollars of investment. Why does this work?

Well, as it happens, what pushes the buttons of creative people like developers most of all is the work itself, and the experience of doing it. Sure, we all need money; we need to live somewhere, eat, buy expensive shiny gadgets and so on, but actually, the good developers would be (and indeed are) writing software regardless of whether someone paid them to do it. For most good developers, what really matters once they’re comfortable with their financial situation is:

  1. To work on projects they care about
  2. To learn new and interesting things
  3. To have creative control/influence over their work
  4. To be treated like adults and not micromanaged
  5. To be recognised for their work

Open source projects put a big tick in all of these boxes, and that’s why they can be so successful despite there often being no money involved. As a manager, if you concentrate on these 5 things, you’ll increase your chances of attracting good developers – the salary and benefits have to be reasonable too of course, but those 5 will tip the balance.

Of course, rather than ramble on like this I could have just pointed to Maslow’s Hierarchy of Needs; all managers are familiar with that and use it to guide their management style, right? Right?

Business Personal Productivity

You probably underestimate yourself

For the purposes of this post, I’m going to assume that the reader is a relatively normal person, and not a raging egomaniac, or a nihilistic sociopath – investment bankers, you might want to stop reading now ;) .

Still with me? OK. So, I don’t know precisely what you do for a living; given my usual readership you’re quite likely to be a software developer, but I believe this applies pretty universally. I’m willing to bet that you probably assume that other people in your industry are way better than you are. That you look at the big company names, and big celebrities in your industry, and are a bit intimidated by their position, their expertise, and their track record. You might have the impression that because of the resources and experience these people / companies have, and perhaps the infinitely more ‘suitable’ location they live in, there’s no chance you could ever compete with them.

If so, I’m pleased to be able to tell you: you’re wrong.

Here’s a personal story. I grew up on a tiny island that in my early youth was based largely on horticulture, and then later morphed into a financial services centre. Neither of these professions interested me in the slightest. Software companies just don’t come from here, unless they service the local finance industry, or so the wisdom goes. The assumption regularly made by people both within the island and outside it, is that the only way to obtain real expertise is to bring it in from outside, because what expertise could you possibly expect to find in a small population in the back-end of nowhere anyway?

In this environment, a few of us grew up and found we wanted to be software developers, but we generally assumed we weren’t that good, at least in the grand scheme of things. Maybe we could impress each other, but surely that wouldn’t wash outside the island. Some of us tried to address that by working twice as hard, and learning as much as we could, from anywhere that we could, assuming all the time that we were basically regional hillbillies struggling to catch up with the far more sophisticated outside world. Maybe if we worked really hard, we might just be good enough to get an entry-level position or something, and then learn all the really smart stuff that everyone in the rest of the world must be doing that we had no idea about.

As time went on, through one means or another we started to interact more with the outside world. There were joint projects with global teams, the Internet opened things up and open source projects were joined and even started, and some even worked with/for these big-named companies in fabled places like Silicon Valley. And guess what we found, much to our surprise?

The range of ability was exactly the same in these places as it was in our tiny ‘backwards’  island. Sure, there were more people, leading to more companies and more positions, but the ability scale was occupied in broadly the same proportions. The people we thought were great developers just in the context of our island were still great developers on the world stage, even in centres of excellence. Projects we worked on ended up being highly respected by people far outside these shores. We competed, and were surprised to win sometimes. And yet we came from the middle of nowhere, in tech industry terms.

We made the classic mistake of assuming that we were worse than the competition, just because we weren’t based in these larger, more famous places. That assumption had some positive effects – making us work harder for it – but also some negative effects too, such as making us rule out a lot of options unnecessarily. In fact the playing field was a lot more level than we thought it was.

There are other examples too. I spotted a quote from Dame Mary Perkins of local company Specsavers in our local paper a few days ago, when she talked about their experience of setting up in Melbourne. She said that they’d thought there would be 4 million people’s worth of skills and qualifications, but in fact the people were no better than the people they found back home in Guernsey. Scale really doesn’t matter very much.

And again, in a recent interview Bradley Wiggins, current favourite of the Tour de France, he illustrated his surprise at his position: “kids from Kilburn are expected to be postmen, milkmen or work in Ladbrokes”.

So, you almost certainly underestimate yourself, and you probably overestimate other people / companies too. Often the hardest thing about doing something outside the norm (for your environment) is believing that it’s possible in the first place. Get over that, and pretty much anything is achievable if you put your mind to it.

Business Personal

Playing both the long and short games

I’m an avid believer in the value of ‘playing the long game’ – that is, the concept that it’s worth foregoing short-term benefits, or indeed enduring short-term pain, in pursuit of a more significant long-term gain. This kind of thinking is a basic requirement of anyone who has chosen to run their own business at some point, because it’s always easier and more immediately financially beneficial to take a ‘safe’ job offer rather than to leap into the unknown, a place of short-term cash flow issues and uncertain future gains. I certainly turned down some attractive looking job offers while building a business because I believed long term it wasn’t the right option, and I’m sure most people in that position do too.

At the same time, I’ve also blogged before about how I think making 5-year plans is futile and ultimately limiting. So here, I’m advocating only short-term planning – aren’t these two positions contradictory? Well, actually no, and I’ll try to explain why not…

When you play the long game, you’re making a set of high-level, strategic goals for yourself. These should be completely devoid of any specifics of how you intend to achieve them, but they will be the yardstick against which you will measure your more detailed, short-term decisions. So while I think it’s silly to make specific plans for a period as long as 5 years, for example wanting to get a specific job or be making a specific product in 5 years time, I think you should be making high-level statements of intent. For example: “I want complete freedom to work on projects of my own choosing”, or “I want to be able to take off on a round the world trip with my family whenever I want”. These might sound like fanciful pie-in-the-sky things, and probably some people around you might say you’re crazy for considering them. That’s because the world is full of short-term thinkers who unconsciously extrapolate from what is possible to achieve in the short term into artificially restrictive, often rather dull (and far too specific and rigid) long term plans. You really don’t have to be constrained by this thinking. Don’t extrapolate from the short-term, interpolate from the long-term ;)

When you have a long-term but very high-level goal in your mind like that, making decisions on short-term things often becomes a lot easier. For example, a while back I started taking a Masters degree in my spare time. It was kind of interesting and I passed a few modules, but then I realised that while I appreciated the learning, in the context of what I wanted to do long term – to work on my own products and not just look for jobs – additional formal qualifications were actually pretty worthless. No-one cares what your qualifications are when they buy your product, they only care how good the product is. Even when you’re a freelancer, which I used as a conduit, clients are far more interested in your portfolio and track record than the letters after your name. I was spending a lot of time conforming to a pre-set syllabus which didn’t adapt to my interests and the demands of the projects I wanted to work on; sure there’s some overlap, but I found I could learn just as much or more on my own anyway. So, I dropped that part way through and I’ve never regretted doing so; not surprising really because it wasn’t aligned with my long-term, high-level goals. If I’d wanted to stay a regular employee long-term then it might have still been useful (although even then, less so as you get older, but sometimes good for getting past dumb HR pre-filters), but that wasn’t my goal.

So in summary, my approach is to play the short and the long game at the same time, staying flexible and open to opportunities (by not planning the long term in detail) while still making all my short-term decisions in the wider context of very high-level long term goals. Sometimes those short-term decisions lead in a direction which might seem unintuitive to others (and might give you second thoughts) unless taken in the context of those wider principles. If those long term goals really do speak to you personally, they will be worth pursuing even if the route takes a few twists along the way. In fact, those twists can be fun too, if you’re willing to roll with them.

Business Personal

Scale isn’t everything

If you limit your reading material to articles on TechCrunch and similar sites, you’d get the impression that to succeed in business requires that you plan to scale to a massive level. The received wisdom is that if you’re not targeting a user base of several million, and are not raising capital in Silicon Valley commensurate with that aim, then you’re not doing it right.

This is nonsense, of course. It simply reflects one end of the spectrum of business ventures – that which is high-risk and high-reward. There are many groups with a vested interest in this extreme being perceived to be the only valid approach – not only the media companies which hype them to generate news (big wins and big failures are news, the middle ground isn’t), but also the venture capital machine requires a steady stream of people willing to roll these high-stakes dice, because the unfortunate reality is that most of them will fail. The fact is that at the high-stakes end, you have to keep feeding the wood chipper in order to keep generating the minority of successes that fund the rest – it just sucks for you if you’re one of the majority who flame out. Failure can still be a good experience of course, and in the US past failures do not carry the stigma that they seem to in Europe, but still, being back at the start a few years on with probably a burn-out or two is not the outcome you were shooting for.

And at its worst, this can have a serious negative effect on would-be entrepreneurs – those people who are not in their early 20′s with no commitments, and who do have something to lose (houses, families etc). The perception that the only startup business worth doing is one where you move to Silicon Valley, pitch to VCs and then sleep under your desk for a few years can appear so daunting and high-risk that someone with anything to lose is likely go white and run back to the ‘safe’ world of employment (the actual safety of which is vastly overestimated of course, but that’s for another time). And yet in reality there are countless ways those over 30 can start their own business without risking destroying their lives, particularly if they’re creators themselves – programmers, artists, engineers, writers and so on, by profession or by hobby – whether part-time or full-time, and the Internet has made many ventures largely location-independent in practice. Sure, if you want to start the next VC-funded über-growth company you probably need to move to Silicon Valley, but seriously, that’s not the only kind of business that makes sense.

Here’s a truth that you rarely hear in the rarefied world of tech business journalism – a successful business is one that makes more than it spends, and ideally increases that margin over time. That’s it. If you can do something that you enjoy doing, and you can make more money than it costs you to do it, you’ve won. Don’t listen to people who imply that success comes in some kind of first-class and second-class offering; that you have to be on the cover of Wired and have millions of users every day to be successful. If that’s how your business model works, great. But if it isn’t, if you make money by giving a tiny niche audience something they like and they reward you for it with enough money to pay your bills, that’s awesome - don’t for a second let anyone make you feel that it’s not. Don’t get into willy-waving competitions with the ‘go big or die trying’ crowd, it’s pointless and just legitimises what is often a poorly disguised frat boy competition.

Running your own business and seeing it work is a fantastic feeling, and I think anything which encourages more people to dip their toe in that water, at a risk level that they’re comfortable with, is a good thing. The bar that TechCrunch et al set is the precise opposite of that – it’s a kind of elitism, really, designed to keep out all but those who think in that particular way.

I’ll just finish by referring you to 37 Signal’s Bootstrapped, Profitable and Proud page, which is a collection of companies who took a different, bootstrapped route and have done extremely well. Not that I think the $1m revenue benchmark on this page should be considered a threshold for success either; the only success factors I believe make any difference are being happy, and being profitable. If you can nail those two, it’s party time – whether you get to ring the NASDAQ starting bell or not just isn’t as important, IMHO. :)

Business Open Source Productivity

Oh no, not a ‘Best of’ collection?

Well, yes – and my apologies if you’ve already seen these.  In celebration of the new blog and before I’ve polished any new entries for it – I often write & refine my posts over several sessions, I find the content is better that way – I thought I’d flag up three posts from this blog that I’m particularly satisfied with, and that I think resonated well with people.

  1. Work 2.0 – the interruptible programmer
  2. How to make decisions
  3. My evolving view of open source licenses

Hope you enjoy!

Business Personal

On being acquired

A lot of you will already know, but SourceTree, a Mac client for Git and Mercurial I created over the last 18 months, has just been acquired by Atlassian. There’s a press release, articles on TechCrunch and VentureBeat, and an official FAQ on the SourceTree site. But this is my personal blog, and I’ve had a few requests for a personal angle on this, so here you go.

I said in a previous post that in my experience, the best opportunities often come along when you’re not looking for them, and that was certainly the case here. I wasn’t even thinking about looking for acquisition opportunities for SourceTree – sure, the idea had crossed my mind as something I might want to consider eventually, but it certainly wasn’t an active line of thought this early in the product lifecycle. SourceTree had grown to become a viable business for me, and I was very much enjoying the process of just creating a software product that I used every day myself too.

So, when the Atlassian opportunity came up, I wasn’t at all prepared for it, and I had to make some decisions. I was enjoying being master of my own destiny, and was managing just fine – so my initial knee-jerk reaction was to be very cautious. However, the more I thought about it, and the more I learned about Atlassian, the more I realised what a huge opportunity I’d be turning down, both personally and for SourceTree, if I said no.

Any acquisition kicks off with a financial offer (don’t expect details, they won’t be forthcoming ;) ), but that’s far from the whole story. In my case I didn’t have any pressing need to sell, and I’ve learned from experience that being happy about what you do is extremely important. I also have a strong attachment to the products I create – that’s why I stayed with Ogre for 10 years and it was/is still a wrench to leave – and that’s the case with SourceTree too; not to mention that I’m a daily user of it myself. So if I was going to sell, it had to be to the right company who would look after it just as well, or better, than I did.

Luckily for me, I discovered that Atlassian was about as perfect a fit for SourceTree as I could have asked for. Atlassian lives and breathes developer tools – that’s their entire product focus, which in itself is a good start. They’re investing heavily in DVCS tools – hence the 2010 Bitbucket acquisition and its recent enhancement to handle Git as well as Mercurial (which of course SourceTree does too) – again spot-on on the compatibility chart. I learned, particularly when I visited their HQ in Sydney, that everyone at Atlassian really ‘gets’ developers (well, most of them are developers after all), and care a lot about giving them good products. Development tools permeate the entire company – the CEO is a regular user of SourceTree, and people in marketing understand when you talk about version control. Even though they’re quite a big company now, it retains a startup feel. Then there’s their corporate values, which are very much in evidence when you talk to people there – things like “no bullshit” and “don’t f**k the customer”. And it’s not just on the wall, it’s really how people in the company make decisions. These are the kind of people I can relate to, and definitely the kind of people who can add a lot to the future of SourceTree.

Another thing I found reassuring is that at no time was there any question that Atlassian would want to railroad developers into their own tools at the expense of others. Clearly Atlassian already owns Bitbucket, and SourceTree supports Bitbucket, GitHub and Kiln already. It was made abundantly clear to me that no-one at Atlassian took the view that restricting developer choice to favour Atlassian tools was a good idea. Their ideology is to make developer’s lives better by giving them choice, and of course they’re going to want to offer good Atlassian options in there, but if a developer wants to use an alternative, no-one is going to stop them.  The view I got from everyone was that giving developers a positive experience that reflects well on Atlassian, including giving them their own choice of integration, is far more valuable than artificially chaining them in. Obviously, I concur.

My final reason was that while I really, really enjoyed creating and supporting SourceTree myself, the workload is quite high, and was increasing. It’s not a continuous death-march, but the availability requirements are very high – since I was developer, webmaster, sales, customer support and everything else all rolled into one, taking a day off was basically impossible. Making sure the website was still up, and making sure customers got a quick response to support calls, was a 24/7 responsibility. After a while, that gets tiring, even just checking on things all the time means you never have ‘proper’ downtime. A big advantage of joining Atlassian is that I get some extra backup. That’s good for my health & mental wellbeing, and I’m sure that will be good for SourceTree too long-term. I really didn’t want to start resenting SourceTree for preventing me having a proper holiday occasionally ;)

So based on all these factors, I decided that the future for both myself and SourceTree would be better within Atlassian than continuing alone. I learned a lot along the way to this acquisition – dotting all the i’s and crossing all the t’s turned out to be more time consuming and stressful than I expected, so I wouldn’t say it’s a process for the faint hearted, but if you’re as lucky as I was to be approached by the right company, it can lead to a really great outcome.

I’m still fully committed to developing SourceTree, like I was before, but now it has a more robust support structure around it. Taking things to the next level, both in terms of user base and features, is so much more practical now within Atlassian. I’m very confident that they’re the right company to take SourceTree forward – our thinking is very similar, I respect their values a great deal, and the people are great. My decision was a lot easier than it might have otherwise been because of this!

Business Development Tech

Why ‘software engineering’ is a misnomer

These days I’m a free agent, and I’m lucky enough to be able to choose what projects I work on, but in a past life, I was what I suppose is properly referred to as an ‘enterprise software developer’. Yes, I once functioned in an environment where terms like ‘mission-critical’, ‘project life-cycle’, ‘stakeholders’ and ‘change management’ came up quite a lot. I’m grateful for the experience I gained over 12 years of doing that, but I’m also very glad to be free of it now.

One term which was bandied around a lot in this environment was ‘software engineering‘. The implication of this term, and the expectation of many people using it, is that designing and creating software is very much like physical engineering disciplines, such as erecting a bridge or building a block of flats. When a software project starts to go off the rails, and fingers are starting to be pointed, a common question is why large physical engineering projects can come in on time an budget, when most software projects beyond a certain size don’t? Surely if the people who create software claim to be ‘engineers’, they should be able to adhere to the same standards of other engineering professions?

At face value it sounds like a fair argument, and I’ll be the first one to admit that software engineers are very often not as rigorous as others bearing the title. But there’s a good reason – the belief that software projects are akin to building bridges is completely misplaced, and it is a belief which too often leads people to think that software projects should be run using techniques such as fixed prices, up-front design, and waterfall life-cycles. This is despite decades of case studies indicating that such techniques rarely work, and are more often a collective delusion adopted because the reality – that you’re never going to be able to predict a large software project accurately up-front – is too terrifying to be contemplated. The term ‘software engineering’, while indicating some of the responsibilities of such a person, is an incomplete definition of what building software actually entails, and just reinforces these misconceptions.

So, why is making software so different to building a bridge?

  1. Software is intangible.
    You can see and touch a bridge, it has a physical presence you can measure and its purpose is absolutely obvious to any observer, as are its success and failure conditions (getting people across a gap without falling down). Even though there are parts of the bridge the user will never see, their purpose can be easily unambiguously defined – carrying utility cables/pipes, providing maintenance access, etc. Software is intangible, and even the part that is seen by those defining its purpose is often hard to evaluate until it can be seen and used directly, never mind the internal working processes. Evaluating and defining software ahead of time is like trying to describe a dream seen through a keyhole – incomplete and everyone has a slightly different impression, and regardless of how much you try to write it down, you can’t capture or communicate its essence completely to others, or guarantee that they interpreted it the same way.
    People are just naturally very bad at defining and evaluating intangible things. There’s no point pretending they can with 300-page requirements documents, you’re just wasting everyone’s time – accept that people won’t know what they like until they can play with it – iterate!
  2. Interaction complexity
    There’s only a small number of ways to use a bridge, and they’re each quite straight forward. Yes, there’s much complexity to the structure of the bridge itself, but that really doesn’t matter to a person driving or walking across it – that doesn’t need input or feedback from people except for whether they like the look of it.
    Software is basically defined by complex interaction, which is often context- and data-sensitive. The number of variations mean that even if every one is bug free (yeah, right), there’s the question of whether it’s solving the correct problem, which is a function of people and their interpretation / opinion. While building projects can be complex, those complexities are most often a function of the engineering challenge, whilst most complexity in a software project is a function of the involvement of people, which are far more difficult to pin down.
  3. Change is a constant factor
    Change happens everywhere of course – maybe the bridge builder discovers that the ground isn’t as firm as they thought, or suddenly someone wants to make an extra deck available for trains. Big disruption, and an effect on time and budget – all understandable. The problem when it comes to software is that the perception of change is very different. If suddenly you have to sink massive extra foundations or double the amount of steel you need to use, people understand the magnitude of that intuitively and accept the effect on the schedule. Changes in a software project tend to be perceived as ‘just a little tweak’ by those requesting it, which tends to mean tolerance for schedule impact is lower, and indeed the potential for interaction between changes in unexpected ways is often overlooked. Now, I’m not for a second advocating that change should not be allowed, but often the mechanisms that have been established for managing a project – up-front estimation, fixed feature sets and so on – prevent the efficient integration of change, or at least obscure its impact to a point where things become critical. It’s important to appreciate that change is more common and expected in software projects, by nature of the issues raised in the previous points, and therefore setting your expectations based on a discipline where change is less common is not a smart move.
  4. Lack of hard limits
    Building  a bridge involves respecting some hard, unchallengeable limits. As a wise man once said “You canna change the laws of physics, Cap’n!”. When you’re building software, however, there are very rarely any unbreakable limits, and even the soft limits that there are tend to be invalidated very regularly as new technology comes on stream. No-one can realistically stand up and say ‘this is impossible’ when faced with a request, because almost nothing is impossible. Hard limits in physical projects make all stakeholders ‘get real’ – you can’t use more land than you have, you can’t build a skyscraper out of paper, there are non-negotiable rules for safe load-bearing and so on. Barring some really crazy and ground-breaking structures (which BTW, rarely come in on time & budget), these limits ground everyone involved in the project to realistic expectations. In a software project, reining in those feature requests, or those ideas that the implementors have for a new tech they could use, is much more abstract affair, and everything is up for debate.

All these things put together mean that if you think you can use the same kinds of techniques to run a software project as you would use for a building project, you’re kidding yourself. They’re so very different in fundamental ways, it’s like trying to catch a shark with a shrimping net (because it’s just a fish, right?).

So please, stop with these delusions:

  1. that estimating the cost of any non-trivial software project (that isn’t just a carbon copy of something else) is any more sophisticated than mildly informed guesswork.
  2. that it’s reasonable to think that a fixed-price can be realistic for any software project longer than a couple of weeks
  3. that ‘change control’ is the about exceptions, rather than the norm

Of course, agile approaches attack these particular delusions rather well. But try to get those adopted in very large organisations where the ‘software is like a bridge’ mentality still thrives :)

Business Development

Sales work – who knew?

The SourceTree 1.2 launch sale is now over, and I thought I’d post some indicative results. I went for a fairly large discount of 40% over a full week, and some people I know commented to me along the lines of ‘what about all that money you’ll be losing on each sale?’.

I decided on a large discount because SourceTree 1.2 was a major update that I was actually quite proud of, so I wanted to get it in front of as many people as I could. I was also aware that there might be people who tried SourceTree before, but who decided it wasn’t for them, and I wanted to encourage these people to try it again, since I’d made pretty big strides in this version on the overall appearance of the app and the smoothness of the workflow, in addition to all the normal new features. The way to do this of course is to make it worth their while to do so, by offering a discount that really grabs their attention. A 20% discount probably wasn’t going to do that effectively, but 40%? That’s almost half price! It’s this sort of gut reaction I was looking to promote.

The other thing I was acutely aware of is that you have to be careful not to have too many sales. If you go on sale too often, people are going to start assuming that there’s a sale coming almost any time of year, so will avoid buying unless there’s a sale on. In my opinion, sales need to be infrequent, but big and attention-grabbing when they do happen.

So actually my goal for the sale wasn’t necessarily to make more money than usual, but to get more eyeballs on the new version, and more active users, which I hoped would then translate to more awareness and more sales further down the line, because satisfied customers are the best marketing resources you can ever have. Solid reasoning, but as it turned out, things went much better than I could have hoped, so in the end I actually achieved both at once. :)

So for those people who were wondering whether having a sale is worth it, my results are on the right, in fashionable infographic form ;)

As I said above, what I was really looking for was to reach more people, and I certainly did that – with a 793% increase in units sold in the sale week, that’s about 2 months’ worth of new users in one week. And as you can see, in value terms it also ended up a considerable net positive even with the 40% discount – now of course I’m expecting sales to be more sluggish immediately following since the sale will have caused people to bring forward their purchase, but I’m pretty confident it’ll remain positive even with that compensating effect.

So why am I writing about this? Am I doing it to strut around flashing my ‘wad’ at people? No, and if I’d included the actual $ values you wouldn’t think that anyway – they’re fantastic news to me but they’re in the ‘I can keep doing this sort of thing for a living!’ range rather than the ‘I can buy a Ferrari tomorrow!’ range :) I’m writing it to hopefully provide a data point to other developers who, like me, are still learning about selling their wares online, and are wondering about what kind of affect a sale might have. I don’t know whether it will be exactly the same for you, and there are no doubt a number of variables involved, but this was my experience, and I’ve been very happy with it. Maybe it will help someone else pondering a similar decision…