A New UsabilityHub: Coming Soon

It's been a long time since we've posted an update, and for that we're sorry. We're not dead, we've just been busy elsewhere. Matt and I (Alan) have been working full time on a bug tracking app for web designers and digital agencies called BugHerd. BugHerd is a visual bug tracker for websites, like sticky notes for HTML. Things have been going awesome at BugHerd, and whilst we always had the intention of coming back to UsabilityHub and Five Second Test, it was becoming more and more clear that we were just never going to be able to.

So a while back we made a decision to get some help.

We'd like to introduce you to Nick and Tristan (You may have already used their app - the time tracking and invoicing app, Paydirt). They've been working hard rebuilding UsabilityHub from the ground up. They've made a lot of improvements already, but there are a lot more changes and features coming soon. We'll be launching the new version into beta in the coming weeks. If you're interested in trying it out shoot an email to support@usabilityhub.com and we'll get you set up as soon as it's ready to go. As a treat, here's a look at the new dashboard currently in development (full design not implemented yet...this is just a sneak peek):


Once the new app is ready to roll, we will be shutting down the old app. This means two things:

1. Where possible your tests will be migrated to the new system. If for some reason we're unable to migrate all of your tests, we'll give you plenty of opportunity to get the data you need before we move to the new version. We don't expect there to be any problems, but because it's an entirely new system some tests may not make the journey.

2. As everything is new (including the database), you'll be asked to reset your password. It will be a simple matter of using the "reset password" functionality to choose a new password. If you can't remember what email address you used to sign up, just shoot us an email to support@usabilityhub.com and we'll help you out.

I hope you're as excited about this huge new release as we are. Once again, I'd like to apologise for the silence of the past little while... it's not that we don't love you, it's just we bit off more than we could chew :)

Thanks for all your support and enthusiasm over the past few years, and here's looking forward to the next few!

Cheers,

Alan and Matt - UsabilityHub co-founders


Why Being an Aussie Startup Sucks.

This is a repost of an article I wrote in May of 2010. It was originally taken down at the request of our bank in order to be approved for an account.  Ironically, the reason we relented was because there was no other bank in Australia that provided the USD merchant account we need. The fact it was demanded that we take down the post only serves to highlight the point the post was making in the first place. This still makes me laugh.

Having had another 12 months experience in running startups, with two incubators and three trips to the US under my belt, a follow up post may be in order. In the meantime, by request, here is the original post.

------

You've all heard about how if you want to run a successful startup, you've gotta be in the US. Well, we're quickly finding out how true that is. But first a disclaimer...I'm not a banking expert. I'm new to the whole Internet Merchant realm, and this is a tale of my experience trying to get our business selling online. I know there are far easier options than using a customised solution, but looking to the future, this is something we wanted to achieve, and we're simply astounded at how something so seemingly trivial could be so damned difficult. If at the end of this you have a solution to our problems, by all means drop us an email at support@fivesecondtest.com. I'd love to hear from you!

It's not that our business is any different than a US based business. Our websites and applications would all be exactly the same if we were in Silicon Valley. We'd likely go about our business activities the same as we do here, we'd probably have the same amount of traffic, and make the same number of sales. The one big difference, is that by being in the US, we'd be in the US already! Sounds obvious, but that's where the Internet "happens". The majority of our customers are in the US, our hosting is in the US, our suppliers are in the US, our sales are made in US dollars and most importantly when you talk Internet, people don't look at you like you're trying to launch a mission to Mars.  Remove yourself from that ecosystem, and all of a sudden you find yourself asking questions which people don't understand, and trying to find information that no one has. Worst of all, you find yourself with a big fat lack of choice.

For the past 6 months one of our little applications, Fivesecondtest.com, has been trudging along earning us a nice bit of cash on the side of our usual consultancy work. It's not our main revenue source by any stretch, but that is something we're in the process of changing. As many readers will know, all our payments are currently handled by PayPal. PayPal, for all its faults, provides a cheap, flexible and easy to setup payment system. Whilst it is certainly doing its job admirably, as we move to the next phase of our little hobby, PayPal is no longer fitting the bill..... and this is when our problems started.

Our next product, Navflow.com. is designed to run as part of a subscription. When hunting around the web for ways to achieve this goal, we found a plethora of providers, gateways, carts and apps to meet our needs. So much choice!! Where to start!? Well for us, we'd be reading a heap about a little app called Chargify, and decided to check it out. I'm all for supporting those that are trying to do something different. Even if it is in Beta, we were keen to get on-board. 15 minutes after signing up, we had Chargify set up and plugged into our app. With a little tinkering, we quickly had a full test bed running that allowed us to subscribe, unsubscribe and switch plans. This is how the web is supposed to work! Fantastic!

So now the pain of learning happens.

Chargify is still in Beta, and whilst it is a remarkably polished app, it's not "feature complete" yet. For the most part this doesn't affect us, but the one thing that did catch us by surprise was their support for payment gateways. First of all, we thought Chargify WERE a payment gateway. This is an example of how we were more than a little naive about the world of credit cards and internet payments. We'd been spoiled by the one-stop-shop that is PayPal.

As it turns out, Chargify (as of writing) only support one gateway that supports Australian businesses, PaymentExpress. Well that certainly made our choice easier! So we went to Payment Express and found that to use their services we needed a Merchant Account. Ok, no problem, we had a business account already, it surely couldn't be too hard to get a Merchant account setup alongside that? Could it? We spoke to our bank only to find that they can set us up a Merchant account, but that we could only sell in AUD. Not only that, but prices have to be QUOTED in AUD. This is hardly appropriate given that around 1% of our customers are actually Australian. After much research and gnashing of teeth, it turns out that <REDACTED> are the only Australian bank (supported by Payment Express at least) that support multiple currencies....and that comes with a hefty up front fee as well as additional fees for every currency you want to support. OUCH!

So if we want to use Chargify, we MUST use Payment Express and we MUST use <REDACTED>. A quick look at transaction fees for all of the above quickly showed how big of a slice of our monthly subscription fees we'd lose. We'd make it all back again, but it's still a big punch in the face when compared to the relatively cheap PayPal solution.

This is where being Australian sucks.

If we were in the US, we'd have a choice of half a dozen payment gateways with Chargify alone, and we'd have a near endless supply of banks and merchant account suppliers queuing up to take their slice of our takings. But in the Internet backwater that is Australia, we have the choice of ONE bank that will do what we need to do, and they seem intent on taking a hefty slice of every dollar they can (they are a bank after all).

So the logical progression of thought here is that if we ditch Chargify, we can ditch PaymentExpress which means we can ditch <REDACTED>. Of course, we still want to sell in USD, so that means getting an international acquirer. We spoke to several other companies such as WorldPay, GlobalCollect, Chase PaymentTech and several others. Whilst the aforementioned providers could at least provide us Aussies with merchant accounts, the vast majority of "online" providers weren't set up to support Australian businesses. GlobalCollect and Chase, whilst helpful were quietly sniggering at our annual turnover, and politely showed us the door. WorldPay, our last remaining option told us that it would take up to TWO MONTHS to set up an account with them. WOW. In 2010, it takes that long to set up a payment gateway and merchant account?

So, we're back to square one. As an Aussie startup we have the choice of precisely one provider of Internet Merchant accounts, and they're EXPENSIVE. There are some fantastic cart providers (like Chargify) out there doing some amazing things. For the most part, they're not only simple to use, but also have excellent support and are crazy cheap to implement! The frustrating thing about all this is that the closer you get to a bank in the whole process, the slower the responses become, the worse the implementations get and all the while they charge you more and more for the privilege. 

Even when we thought there was a glimmer of hope, with Chargify announcing support for PayPal Pro, our hopes were quickly dashed. If you're in the US, PayPal Pro is an all-in-one account that let's you do everything you could possibly want, and for a very reasonable fee ($30/month). Connect that to Chargify, and you have an awesome subscription system that is not only flexible but is very cheap to set up and run. Of course, that's if you're in the US. In Australia, we're stuck with PayPal Payflow Pro, which is not only significantly more expensive ($150/month), but still requires an bloody Internet Merchant account from your bank!! Back to square one....again!

So it seems that whether because of banking regulation, or lack of competition, we're stuck with a cumbersome, expensive, inflexible, slow-to-setup payment system for one reason and one reason alone.... We want to do business globally, but we're based in Australia.

At least we have better beaches I guess.

Why the world needs a new bug tracker.

If you haven’t checked out our demo or had a play, BugHerd is a kick-ass new bug tracker that makes reporting website issues a breeze for designers and clients. Matt and I started developing it one day after trying other tools and finding them to be too cumbersome for our needs.

As the founders of UsabilityHub – the home of several popular UX tools including FiveSecondTest – we were solely focused on building great user experiences and found that bug tracking tools designed for engineers got in the way of us achieving that. If it takes more time to log a bug than it does to fix it then you simply won't log it. That means the bug gets forgotten and it never gets fixed. So to solve our little conundrum, we built a bug tracker that we would actually use. It takes 5 seconds to ask someone to change a button color instead of the several minutes it takes to fill out a monstrous form.

Our UX sites have over 11,000 members, split evenly between designers, front-end developers and UX experts. Surely these folks shared our pain! We ran a survey to find out and the results were startling. These were the top 5 responses to the question: "What solution do you currently use to obtain client feedback and manage issues?"

1.       Email (20%)
2.       Pen/paper (18%)
3.       Phone (7%)
4.       Google Docs (6%)
5.       Excel (4%)

Do the math, and you'll see that over 55% of respondents have no formal method for sourcing and tracking client feedback. Now, I'm the first to admit that our survey is by no means exhaustive, but it certainly makes one thing obvious: these users can't find a bug tracking solution that works for them. So here we are in the age where there is an app for everything, yet 55% of designers aren't using any kind of purpose built tool to manage their work! 

Imagine the workflow for any one of those top 5 methods. There’s double handling, no round-trip communication, no automation, no backup, no process, no feedback mechanism - nothing. It's almost an entirely manual process. I guess it shouldn’t be a surprise that 74% of respondents said their clients didn't like their choice of solution. Ouch!

Think that’s the bad news? Well it gets worse.

We were also curious about how these people manage their own issues internally between team members. So we asked, "What solution do you currently use to manage bugs and issues between team members?". Once again, the answers were surprising:

1.       Pen/paper (23%)
2.       Email (14%)
3.       Basecamp (13%)
4.       Google Docs (11%)
5.       Redmine (10%)

Well at least there are some actual management tools in this list! Almost 50% of these designers weren’t using any formal means of tracking bugs and issues internally. Conversely, a similar survey we ran on Hacker News found that the vast majority of developers use the most well-known bug trackers (Redmine, Jira, Bugzilla, etc). In fact, only 12% of Hacker News respondents said they use something other than a bug tracker to track their bugs. 

What this says to us is that there is clearly a mismatch in the market. There are a thousand and one bug tracking tools for engineers, but there are none for non-engineers. Developers use bug trackers, therefore bug trackers are designed for developers. It shouldn’t come as a surprise that when you survey designers and their clients, they'll tell you they don't use anything at all. Whilst your bug tracker may be great for your engineering team, it sucks for everybody else. 

We're currently talking to a company who is interested in using BugHerd internally. Their web team is made up of 75 people, 6 of whom are engineers. Yes, SIX!! They represent 8% of the team yet they're the ones dictating which bug tracking tool to use. Imagine trying to get the 12 designers, 10 content writers, 15 managers and 32 other non-engineers to use something like Bugzilla to log their issues! It's no wonder they ultimately fall back to email to log and track issues. It's also clear why they want to use BugHerd.

What is honestly surprising is that no one has thought to build a tool for the designers, marketers, writers and stakeholders. BugHerd is the first bug tracker that was designed with those users in mind whilst still being powerful enough for your dev team to get their jobs done. At the end of the day, bug tracking isn't just about engineering problems and solutions, it's about keeping customers happy. Who do you think knows more about these problems - the engineering team or the people who deal with the customers?

And that is why we'd like to introduce you to BugHerd: The world's fastest bug tracker for web designers and their clients.

If you haven't already seen it, check out the BugHerd demo now.

Facebook is the Death Star, and we're all building it.

Do you ever wonder what happened to all the innocent construction workers on the Death Star (v2.0) when it is destroyed? If you've watched Kevin Smith's Clerks, you certainly would have. If you haven't seen it, Google "Clerks Star Wars" and watch a short clip from it. For those that can't be bothered, the discussion between a customer and a store clerk revolves around the destruction of the second Death Star in Return of the Jedi. Given that it was still under construction at the time, it is almost certain that many thousands of workers would've been killed in the blast. The customer feels that it's terrible that so many people were killed just doing their jobs (roofer, plumbers, electricians etc) that weren't, strictly speaking, part of the "Empire". The clerk argues that the independent contractor has a moral obligation to know who they're working for before they take on the job. If you're building a Death Star, it's really your duty to know what it is you're helping to build. If you get killed in the process, well... you knew the risk when you took on the job.

What does this have to do with you? Well, Facebook is the Death Star, and you're helping build it.

Ok, so you're not part of the Empire, but you're contributing to the construction nonetheless. You're the plumber or the electrician, the guy that forgot to put in safety rails, the girl that builds the strangely located trash compactors in prison blocks and then ensures they have large tentacled creatures in them, or maybe you're just the one responsible for naming Mr. Coffee and Mr. Radar. The point is, you don't need to work for the Empire to be complicit in its success.

Tim Berners-Lee, in his Scientific American article, wrote, "If we, the Web's users, allow these and other trends to proceed unchecked, the Web could be broken into fragmented islands. We could lose the freedom to connect with whichever Web sites we want." One of the trends he speaks of are the walled gardens of information; silos of user data owned by the likes of Facebook and LinkedIn. He argues, "Each site is a silo, walled off from the others. Yes, your site’s pages are on the Web, but your data are not."

He quite clearly sees the onus on us, as web users, to prevent this from happening. But I think it actually goes further than that. Data portability is certainly an issue, but friend data is at best transient and for any individual can become outdated in a year or two. Sure those awesome photos of your mate dressed as the Death Star may be stuck permanently in Facebook's database, but in a year or two, you're not going to care. Even the network of friends you build today is quite possibly a lot different than the one you'll create in 2 or 3 years time. This data is usually not critical and is, more importantly, replaceable. People left MySpace for Facebook and built new networks, and they can certainly leave Facebook for Diaspora or whatever comes up next. No, the real problem is Facebook becoming a defacto standard for your online identity. 

Many applications now provide the ability to log on to their system using Facebook Connect. In many cases, this is now the exclusive means of registering. Signing up to just about anything is becoming a simple matter of clicking the "Facebook Connect" button. For many of us, it's almost too tempting to take the quick route rather than signing up a whole new account with a new password. What we're not doing, however, is giving thought to what we're really doing. By joining something like Digg with that one click, we're permanently tying our Digg identity to our Facebook identity. Without thinking, we've made an implicit decision that our Facebook account will be active longer than our Digg account. From this point on, we can't delete our Facebook account without losing access to Digg as well. By doing this, we've all decided to make Facebook our permanent record, our online authentication protocol and our secure means of access to dozens of websites and applications.

Most of us sign up to a social network with little thought to the security behind it. Afterall, do I really care if someone knows what I did last summer? But if your Facebook account becomes your online passport, how secure is it? If your Facebook account is compromised how many sites does that hacker now have access to? How many sites can a hacker sign up to and assume your identity in the process? How many sites have your Credit Card stored securely for easy checkout? The hacker now has access to it all. The more ubiquitous Facebook becomes in your life, the more likely it is to be compromised and the more destructive it will be when it happens. What was originally a means to connect with friends, has become your single online identity. But you don't need a hacker installing malware on your PC. This an identity that is persistently logged in on your home laptop, your iPad, your iPhone and your work PC. Have you ever lost your phone or even just left your computer logged on at work? Someone now has access to everything you do online. Worse than that they even have a handy list of every website you're signed up to with Facebook Connect.  

Returning for a moment to the Star Wars analogy; remember when Jar Jar Binks voted to dissolve the Galactic Senate (thus handing control to Senator Palpatine) and you were screaming at your TV because everyone in the damned movie must have to be a complete and utter moron to not see it happening? Well...you just put Jar Jar Binks in charge of your online identity. Nice work dumbass.

These are all personal issues, things that affect the end user. I'm not proposing people go out deleting their Facebook accounts. Facebook connect is actually really handy. But what about the big picture? What happens when everybody on the Internet uses Facebook as their online identity? What happens when sites start offering Facebook Connect as the only means to sign up? Without realising it, you've made Facebook the sole authentication system for logging on to just about anything on the Internet. A closed-network owned by a private company now has a complete record of every site every person on the web visits. Think about that for a second. Remember that kid from that Social Network movie you saw the other day? He's holding all the keys to everything...literally.

The danger in Facebook isn't in that you can't take your friends elsewhere, the danger in Facebook is having it become a defacto standard means of authentication on the Web. Every time somebody hands the keys to their Blippy account over to Facebook, that is one more person who is now "stuck" with Facebook. You can decide to leave your social network behind, but if you use Facebook Connect, leaving Facebook also means leaving behind every account on any one of a hundred different websites. The barrier to entry is insignificant, yet the barrier to exit is so insurmountable that it's scary. It doesn't matter what the Diaspora project do. The social network is all but irrelevant now, it's the online authentication hook that is what will ensure Facebook survives any new up and comer. 

Of course, there are ways to stop this happening. As developers, we're the ones building the Death Star. Every time we add Facebook Connect, we're adding another piece of armour to make Facebook stronger, more powerful. Our users want Facebook Connect, and that is fine, but we have an obligation to give them a way out too. Some sites, like Groupon, give users the ability to disconnect their account from Facebook. You just add a password, and you can then just login manually. The problem is if I delete my Facebook account before I do this, I can't log in to Groupon to flick the switch! This is something akin to uninstalling Adobe Photoshop only to realise that you had to deactivate it first. Problem is now you can't deactivate it without it being installed, and you can't install it without deactivating it. Catch 22.

The real problem is having Facebook as a permanent centralised authentication system in the first place. It's one thing to "get started" with Facebook Connect, but an application should always provide another means of accessing the application without Facebook (even for those who connected with Connect in the first place). If Facebook becomes inaccessible, or we want to stop supporting Facebook, or even if Facebook stops supporting us, we need to have a solution ready to allow users to continue using our application without that reliance on Facebook Connect.

The goal here is to prevent Facebook "lock in" and I believe, the humble "forgot password" is the place to start. I'm putting forward the suggestion that applications that implement Facebook Connect should add a "login without Facebook" next to their "login with Facebook" link. This would work something like a "forgot password" function for Facebook users who no longer want to connect using Facebook. This would transparently modify their accounts to allow manual login and simultaneously perform a "forgot password" retrieval. The user gets an email with a link to create a password, and from then on they can use that to login instead of Facebook. Groupon is actually one site out there that is already subtly doing just this using their existing "forgot password" function, but it certainly isn't obvious. As time goes on, users are going to become more and aware of how much they're relying on Facebook for authentication, and eventually they're going to want out. It's up to us as developers to give them by providing that "out".

Of course, Facebook may have already worked this out. Now they want you to use Facebook for your email as well...can you see where I'm going with this?

We're building the Death Star, make no mistake. And every time a user signs up using Facebook Connect another Ewok dies. Do you want that on your conscience? We have an obligation to ensure that there are as many exposed shield generators and poorly positioned ventilations shafts as possible. Only by creating weaknesses in the Death Star as we assist in its construction can we ensure that some whiney kid in an X-Wing can destroy it when the world finally realises what we've built. As developers, it's our responsibility to make sure we don't contribute to the yet to be coined "Facebook lock-in". We must provide our users not only a means to use our applications without Facebook, but also a means to use our application should they have already stopped using Facebook. By perpetuating the need for Facebook logins in our applications, we perpetuate the security risk that Facebook Connect presents to our already over-connected users.

Why you absolutely MUST write an API when you write your next app

I'm a bit of hacker. I've worked with serious software engineers, and I'm definitely not one of those, although I can be when it's required. They're the types that spend more time writing and talking about what they're going to code than they do actually coding it. The word engineer suits these types perfectly. A piece of software to them is constructed from piece by piece of pre-defined, pre-designed and pre-fabricated code. There is more art than science to what I do. I liken what I do to gardening more than building a bridge. To me, software is more of an organic thing and I start software the way I start in the garden. I pick up a shovel and start digging. Over time as plants grow (or die), the yard changes and you change with it. I'm not building bank software or landing planes. I'm building to an ever changing target, evolving my software to suit a need that is never well defined, never fully known. It's whatever I feel like making it.

The big disclaimer here is that sometimes I need to be an engineer. If I'm working for a client on a fixed price project, then obviously everything needs to be engineered to a certain goal. So I can work that way, I just prefer not to. My client work is structured and defined, my pet projects are the result of an ever evolving process of discovery and learning. Of course, that isn't to say you can forget about security, performance or reliability...but it means these things are just one part of an iterative process, not a project in themselves.

For the most part, not being constrained by things like "best practices" is a wonderful freedom. I think of something, and I start coding it. When I'm done, I might go back and tweak or even throw away the prototype and start again (kind of like how we're onto our second Japanese Maple, after the first one died). It's wonderful when you know nobody will ever look at your code, or discover your hacks, it allows you to solve problems now without worrying too much about later. It's like an author taking short cuts with facts, names and places instead of wasting time researching. It just gets in the way of writing the story. But there is a big problem with this type of development. What you gain in agility, you lose in portability. By coding for yourself, you're forgetting about everyone else. 

If you build a successful product, there is a fair chance that at some point you're going to need to get someone else involved. It may be as an employee joining your coding team, or showing a potential investor what you've been working on or it may be by releasing an API for others to integrate with your system. For the first time you're suddenly faced with that embarrassing feeling of your parents dropping in to visit...and it's the morning after a really really big party. It's at this point you suddenly regret all the shortcuts, the laziness, the hacks and the sambuca...oh Lord the sambuca!

That's where writing a public API from day 1 comes in.

You don't have to have your whole house neat, just the bits your parents are going to be seeing. Writing a public API as you develop your system forces you to keep a certain level of decency without constraining your ability to be agile elsewhere. By using your own API you also force yourself to follow the same rules that you expect others to follow when interfacing with your code. It prevents you taking shortcuts that you rightly wouldn't let anyone else take.

If you're an agile or "lean" developer, the one thing you never think about is what this app is going to need to do in the future. You're only ever worried about what it needs to do today. This means your code can evolve into a horrible flying spaghetti monster (if you believe in such things). What makes sense today, may not seem like such a good idea tomorrow. By having a well defined core API you have at least one part of your system (hopefully the important bit) that is well documented, well considered and well written. It's something akin to maintaining a tidy formal lounge whilst the rest of your house is being subjected to an ill-considered conga line.

When it eventually comes time to make your API public, it's already tested and known to work. You know what problems your users are likely to encounter, because you've already encountered them yourself. Best of all, you're not trying to shoehorn a heap of public points of access where they were never intended. Writing an API as you go means you solve a lot of problems before they ever happen...and all without having to think about it too much. The API is as flexible as you want it to be until the day you make it public.

As you grow your application, your API grows with it. The more reliable it becomes, the more likely you will turn to it rather than hacking in a new piece of code elsewhere. When new developers come on board they have something they can immediately recognise and understand. We're all terrible at documenting our code, but with a published API you all of a sudden are advertising what you're application does...you want it to be well documented. Your users won't stand for anything less. 

All of this is the main reason most developers recommend working on open source projects. Open source means everything you do is available for anyone to see. Hacks and cheats are found and highlighted by others, and hopefully you'll learn a better way in the process. You lose this benefit of peer review when you're working on your own private projects. Writing to your own API is the next best thing. Hacks look a whole lot worse when you have to document them for someone else.

Minor UsabilityHub Update 22-Nov

UPDATE: This update has been postponed until tomorrow due to a minor, but time consuming to fix, issue.

We're releasing a small update today. Most of the changes are behind the scenes in preparation of some future developments. There are, however, some other changes as a result of these future changes. There are two main things to be aware of:

1. Test creation process. We've now made it easier to create a test and leave it sitting in a preview mode. This allows users to set up a test, and have it approved by others, or be able to work on several tests over a period of time before publishing them. We've also done this to support our upcoming API. In effect this has only involved splitting step 1 and step 2 of the test creation process and putting a publish button in the middle. 

2. Random test selection Our random test selection function was not only slow, but wasn't properly supporting international languages. Basically if you can understand a language other than English (the default) you would always be served an English test before we'd check if there were any tests in other languages waiting for results. We now treat all languages equally, so we will just serve you the next test that you've said you understand. This should mean our international users get results a fair bit quicker. It also means if you speak a language other than english, we'll be asking for your help to do those other tests more often than before. This does mean that English users may be presented with non-English tests if the test owner hasn't specifically forced the test to only include users of that language.

As always, if you have any issues with the update, drop us an email at support@usabilityhub.com

Thanks for your support!

Why indecision is worse than a bad decision

Indecision is the worst trait you can find in a startup founder. Actually, it's the worst trait you can find in anyone tasked with leading or shaping the direction of any company or project. Indecision, is simply delaying the making of a decision. Sounds reasonably obvious when you say it out load, but what isn't obvious is the implications of delaying a decision. Delaying a decision is effectively delaying work. Being indecisive is therefore no better than procrastination. Both are a barrier to getting things done. It doesn't matter whether you're running a startup, or just deciding on what to eat for lunch, indecision just makes things worse. Right now you may be stuck deciding what to eat, but in an hour's time your lunch break is over and you're bloody starving. Better to suck it up now and just have the damned noodles.

People are indecisive out of fear of making a bad decision. The logic goes that by delaying the decision, I can gather more information and then have a more informed opinion later. The information they're waiting for is really just something to either make them feel more secure in what they've already decided, or something to sway them away from something they don't want to decide. Either way, more information is unlikely to help. If you're in a position where you need to make a call now; make the call now. Looking at the menu for another ten minutes isn't going to make the noodles taste any better.

The absolute worst case is the person who delays a decision until it gets to a point that it simply becomes someone else's decision. If you meet someone like this, run the other way...especially if they're leading a team you're in. I've found myself in a position a couple of times where I've relied on someone above me in a company to make tough decisions.  In many cases the person just went on holiday, or avoided me for a week just to avoid the inevitable discussion, decision and implications. In the end, the hard tasks just fall to someone else often ill equipped to deal them. This lack of confidence in one's ability to make difficult decisions makes for poor leaders and, consequently, poor teams.

There are many reasonable sounding excuses for delays in decision making. Gathering information is one such reason and is often necessitous when making a decision. The danger in gathering too much information is when the information is being gathered simply to confirm a well known hypothesis. If it looks like someone in your team isn't pulling their weight, there is little point gathering evidence to confirm the fact. If they're not up to scratch, show them the door. The opposite case is the search for information to avoid a difficult, but necessary, choice. The reality is that if you look hard enough you can find information to confirm just about anything you like. Giving someone the opportunity to do so just gives them a chance to put weight behind a decision that everyone knows is wrong.

Another reason for indecision is when there doesn't appear to be a good option. Sometimes you're faced with a situation where you have two choices, and they're both bad. The natural inclination of most people is to simply delay making a decision in the hope that a better option comes along. Of course it's possible, but if a better option doesn't surface, you've likely left yourself with the same two choices you started with...except now you're a month poorer as well. Sometimes you just have to play the cards you're dealt.

Some time ago I watched a great video on youtube about indecision and inaction over global warming. The premise of the video is that we can act or not act, and global warming could be true or not true. There are therefore 4 possible outcomes, the best case being we act on global warming and it turns out to be true, and the worst case is that we don't act and it also turns out to be true. The interesting part about the video in this context, is arriving at how to decide if you should act.. 

Imagine we're provided with a situation where we may or may not have a major problem in our software; we'll use the infamous Y2K bug as an example. If we spend a heap of money investigating if our software is affected and it IS then we're all thrilled that we avoided disaster. Good decision! If it turns out that we weren't affected...well at least we know! That's still pretty good....even if it did cost us a truck load of time and money.

Now, let's imagine we didn't do anything. NYE rocks around and we're out partying the night away. Barry, our sysadmin calls us at midnight with the news. If everything is ok we all high-five each other and get on with the partying. If, on the other hand, all of our software is now dead, banks are going belly up, planes are crashing, toasters are exploding...well...we'd probably be in a really bad place. Here's a handy little chart with the possible outcomes from a situation like this.

In essence, when you have an unknown outcome it's always better to act than it is to not act. If you don't act and things go bad, they can go really bad. So what's this got to do with indecision? Well, indecision is the same as not acting. By not making a decision, you're in effect choosing the "don't act" column. By not acting, you're rolling the dice and hoping for the best, you're giving up any say in the matter, you're relinquishing control to some external power, you're crossing your fingers and toes. This isn't the way to deal with global warming, and it isn't the right way to run your business. If you have control, use it.

Difficult situations don't disappear. They just get worse. If you've got a bad employee causing problems, delaying the hard decision to give him the boot just increases the chances of him affecting those around him. If your website is losing you money, delaying the decision to pull the pin will just cost you even more. Decide early, and act swiftly.

So what's the worst that can happen if you make the wrong decision? The fact that you decided to do it means that it was the right decision at the time with the information you had. So it only became a bad decision when unknowns surfaced, or when something changed. When that happens, you simply make a new decision. That may be that you alter what you were doing slightly, or it may be that you scrap it in favour of a new path. Either way, by making a decision you forced an outcome. If you hadn't acted, those unknowns would still be unknown. By making decisions constantly based on the information available, you uncover newer information more quickly. Inaction rarely provides anything actionable.

Very rarely, you can make a call which turns out so horribly wrong that you wonder how you could ever have made such a stupid mistake. When this happens, talk it out. If your customers are pissed at you, get on the phone, email, twitter and talk to them. Apologise for your mistake and ask what you can do to make it better. If you broke something, let people know, and get help to fix it. It is highly unlikely that you'll ever make a mistake that you can't recover from. Put you hand up, own the error and start talking about how to fix it. Taking actions sometimes means taking risks, but without taking risks you will never achieve something great.

So when you're faced with a decision, look at your options, talk it over, experiment, research and ponder...but when you're done, make a decision. The sooner you get moving, the sooner you find out if you were right or not. The earlier you act, the more choices you will likely have available. Leave your decisions until the last minute, and you'll often find the options have dwindled significantly. 

Optimize, don't Organize: Part 7

Over the next week I will be giving out 7 (unedited) excerpts from an eBook I have in the works called Optimize, don't Organize. This is slightly less pretty than the eBook and doesn't contain any of the nice pictures or diagrams....but, as they say, you get what you pay for. I'd love to hear your thoughts, so by all means leave me some comments at the bottom of this page or contact me at alan@angrymonkeys.com.au or even Twitter @alandownie

Start at Part 1 of Optimize, don't Organize here

 

7. Sticky notes, and why they rock.

If you have a wall next to you (or even that whiteboard I told you not to use), sticky notes may well be your saviour.

It’s harder to escape your decisions.

A sticky note wall tends to promote a “first in, first out” mentality. The oldest and most important tasks tend to end up at the top of the list rather than at the bottom. For some reason when you added that task to the top, you considered it to be the most important. It probably still is, even if you don’t feel like doing it. Putting it off isn’t as easy as moving it to the bottom of the list, at least not unless you re-sort and re-evaluate the entire list (and even that’s not a bad thing).

Just because it’s new doesn’t make it more important.

We have a tendency to think that new tasks are more important than old ones. Someone jumps on the phone and tells us they need something done by the end of the day so we drop everything to get it done, forgetting that we have two other tasks that also need doing by the end of the day. Just because it’s newer, doesn’t make it more important. If anything, our older tasks should take priority. The sticky note list will tend to force you to put newer tasks below older ones. And if you really need to place it above your existing items, you have to be damned certain you want to raise the limit on “importance”, because eventually you’re going to run out of “higher” on your wall or whiteboard.

Sticky notes are only semi-permanent

My sticky notes are on a painted wall. The glue lasts about three or four weeks before the heater (or air-con) blows them off the wall. In reality, if I haven’t done a task that’s been on my list for three weeks, I’m probably not ever going to do it. When your notes fall on the floor, it forces you to re-evaluate them. Is this task worth rewriting on a new note, or should I just bin it?

Sticky notes are real

Taking down a task is a reward in itself. The little square of paper has texture and colour. If it’s been on your wall for a few weeks, you may have even gotten used to the quirkiness of whatever you wrote. It’s a real thing that existed in your little work space. It gives the task life and a sense of reality. Best of all, they’re something you can screw up into a tiny ball and take a shot at the nearest bin (or colleague’s head, whichever works). 

 

Previous chapters:

Optimize, don't Organize: Part 6

Over the next week I will be giving out 7 (unedited) excerpts from an eBook I have in the works called Optimize, don't Organize. This is slightly less pretty than the eBook and doesn't contain any of the nice pictures or diagrams....but, as they say, you get what you pay for. I'd love to hear your thoughts, so by all means leave me some comments at the bottom of this page or contact me at alan@angrymonkeys.com.au or even Twitter @alandownie

Start at Part 1 of Optimize, don't Organize here

6. Why most task lists don’t work

 

As a rule, task lists don’t work. They become cluttered, out of date and full of things we never intend on doing. 

Why digital lists don’t work.

Digital lists are too easy to add to. We add things that aren’t important, things that we don’t need to remember and things we feel we “should” do, but never will. Worse than that is that tasks are too easy to strike off. With a click of a mouse or a swipe of a finger we can permanently erase our failure to complete something that we originally thought was important enough to add in the first place.  With every second person owning a smart phone, digital tasks lists are popular for their portability and convenience. Whilst it may be great to remember what you needed to buy down the shop, organizing your work in a digital list is always going to end in tears. If it’s too easy to fill with clutter, and too easy to remove our failures, we won’t trust it. If we don’t trust it, we won’t use it.

Why pen and paper doesn’t work.

I have too many notebooks. I take notes in meetings, I take notes on the phone and I take notes when I’m programming. I don’t need a todo list on my desk as well. Pen and paper tasks lists are also the worst for maintainability. As your tasks are crossed off your list becomes more and more messy. This either forces you to regularly rewrite your list, or to throw it out entirely. You can’t sort, you can’t undo, you scribble phone messages in the corner and worst of all you most likely can’t read your own writing. We write something down in a hurry and are later left wondering, “what’s ‘sulmif buffon’?”

Why whiteboards don’t work.

Whiteboards are the worst. Even someone with the best penmanship can’t write for shit on a whiteboard. The whiteboard suffers from all the same problems as pen and paper but without any of benefits. Possibly the only thing in favour of a whiteboard is also its biggest drawback - the ability to erase. It might be handy to be scrub off that completed task, but it’s also just as easy to accidently remove your whole weeks work. Somewhat contradictorily, whiteboards are also a magnet for old information. Unlike a paper list which we may eventually throw out, a whiteboard tends to collect things that nobody ever thinks to wipe off. Out of date information is the worst kind.

 

Coming up:

7 - Sticky notes, and why they rock.