How to Ask for Advice / Feedback About Your Startup

One of the things I’m passionate about is helping other startups and the community of entrepreneurs we have here in Edinburgh (and in Scotland).  Since becoming more intentional about “taking the pledge“, I’ve been meeting with lots of folks locally, and been surprised by the amount of requests!

So much so that other team members here at Administrate are helping me shoulder the load, according to areas of expertise (thanks Mike and Patrick!) and time constraints, and I know of many others in the community who are donating their time and expertise.  Helpfulness and support has always been a hallmark of the Scottish startup scene, so this isn’t anything new, but there’s so much more activity now, so many more companies, and so many more entrepreneurs now!  It’s great to see!

I’ve found that sometimes people don’t know what to expect, so I thought I’d lay out a brief framework to help everyone get the most out of the time.

  1. Remember that most advice is delivered within a context vacuum.  Don’t take my advice (or anyone else’s) without fully thinking things through and satisfying yourself.  Bad advice can come from really great people.
  2. In order to be at all helpful, I need context.  Things I usually ask about are: the problem you’re trying to solve (as a company), your business model (SaaS, etc), your market, some metrics around revenue, customers (people paying you money), team size, how long you’ve been going, growth, and churn.  It’s ok if you don’t have all of this information, but the quicker we can rattle through these items, the faster we can get up to speed.
  3. It’s totally cool if you just want to chat, but I’ll usually ask you what you’re biggest challenges are – we have these at Administrate and sometimes they feel cyclical (first we’re worried about sales, then tech, then support, then sales again, etc.).  Even if everything is going well, the question will often be “ok, how do we double down and make it even better?”
  4. I probably can’t help you too much with hiring (particularly “line” staff) – my network is mainly in the USA (so not local), and we’re in high growth mode here at Administrate, so if I know of any devs or whatever we’re probably going to hire them!
  5. Expect me to be very, very blunt.  If you’re British it may come across as almost hostile sometimes.  Sorry.  When I get into problem solving mode or analysis mode, I tend to interrupt, ask lots of questions, and don’t filter much.
  6. Expect me to play devil’s advocate.  Expect me to really push you on a few things.  Expect to be challenged.  The best advice I’ve ever received was from someone telling me they thought I could be a lot more ambitious, which annoyed me at the time, but really made a difference.
  7. One thing you won’t get from me is griping about raising money in the UK, finding a team, or complaining about Scottish Enterprise or Scottish Development International.  If you’re annoyed about these things, fine, but expect an argument from me!
  8. I’m not going to be very helpful to you with introductions to angels, VCs or syndicates.  These people all make their own decisions and won’t look at you in any different light if I make an intro for you.
  9. I won’t share anything about our conversation unless you specifically tell me you don’t mind.  I also expect the same in return.  This means I don’t mind if you want to ask me about challenges I’m facing now, etc.  We like to be transparent, and often it can be comforting to hear that someone else is going through something you’re struggling with.
  10. The majority of my experience and expertise is in high growth Business-to-Business Software-as-a-Service.  So be aware I’ll bias towards that style of company.  I don’t like most B2C ideas because they are riskier, require more funding earlier, require a lot of traction to be successful and are often harder to build and/or monetise.
  11. A couple of times things have gotten emotional (really!).  That’s OK! Building a business can be really hard.  Relationships are involved. It can feel overwhelming.  That’s normal.  Don’t be embarrassed.  It’s not the first time.
  12. Unfortunately, you may have your appointment changed around a few times.  Sorry, but Administrate comes first!  Also, it may be awhile before we can meet, and depending on what you’re looking to talk about, we may provide someone else from our team to give you a better perspective.

Hopefully that helps you get an idea of what to expect and makes everything run just a bit smoother!  I’ve enjoyed all of the conversations I’ve had and am always encouraged by the amazing people we have in Edinburgh working away on building things and solving problems.

HSBC Anti-Fraud Measures Vulnerable to Phishing Attacks

I’ve been an HSBC customer for roughly two years and have complained about these practices probably more than a dozen times without any real acknowledgement or change.

HSBC, like most banks in the UK, provides every customer a 2 factor security token to make sure that logging in requires something you know (your password) and something you have (your token’s time-limited code). So far so good. They even have a signing procedure for sending money (personal accounts only, strangely) that requires you to hash the transaction amount with your token, and put in the corresponding code as part of the transaction. A nice touch.

A Horrible Anti-Fraud Algorithm

Where HSBC has a glaring security hole is their fraud detection and prevention. As near as I can tell, the HSBC fraud algorithm is essentially “IF online transaction AND/OR foreign origination AND/OR amount is greater than [some nominal amount] THEN fraud”.

There’s no history taken into account, and they routinely ignore travel advisories called in ahead of time. So for example, if you signup to a monthly recurring charge for a software service outside of the UK (many of them) it doesn’t matter that the charge has occurred every month for a year, they’ll still pop an alert. This is particularly problematic for subscriptions billed annually, as it seems that their fraud team can perform a manual override on most things, but not on infrequent subscriptions.

An Outsourced Anti-Fraud Team

Foreign can often mean “somewhat far away” too. There’s no concept of accepting a card present, pin verified transaction as maybe worth the benefit of the doubt either, so I’ve had my card declined for sandwich shop purchases in towns less than fifty miles away from my home address.

A Dangerous Fraud Verification Process

But all of this could maybe be lived with, if not for the horrific fraud verification procedures employed by one of the largest banks in the world.

Here’s how it works:

  1. Their horrible fraud algorithm pops an alert. This can occur on a subscription charge, a pin verified card present charge, or a verified by visa online charge.
  2. You will receive a phone call from an unknown number (blocked).
  3. An Indian call centre rep will tell you they’re calling from HSBC and they’ll need to verify some important information before they speak to you. So far, this has been my birth date or post code (enough to get your full address in the UK). If you refuse to speak to them, your card is blocked. If you call them back, it will take roughly 25 minutes on hold being transferred around to clear the block.
  4. If you don’t answer the phone, they will leave a voicemail. Again, an Indian call centre rep will preface the voicemail with an urgent request for contact, then they will play a recorded message. Often there will be a problem here, and they’ll have to call back to get the recording playing right.

It’s important to note that the phone connection quality is invariably terrible. This means you can’t understand the person, and the recording is garbled as well.  I also don’t care if the representative is a native English speaker or not.  I do care that the cut-rate policies of HSBC mean they have chosen an outsourcing provider who can’t seem to get decent phone service, thus making the entire thing more vulnerable to phishing (it’s easy and cheap to sound just like HSBC or even worse, do a better job by having a nice fluent British accent  via a clear connection).

An Active Phishing Threat?

For the past two years I’ve been uncomfortable with this process. It leaves you open to phishing attacks, particularly spear fishing. It relies on data that could be publicly obtained fairly easily (birthdate and post code) and even if you can’t get this data, you can easily phish it by impersonating a representative then using that information to escalate privilege elsewhere.

A better solution would be to mimic the procedures in place at other banks. Chase for example has an app that will securely message you the details of a questionable transaction which you can approve or deny in a few seconds. They’ll also SMS you the details of the charge, which you can respond to. Lastly, if you don’t have a smart phone or can’t receive text messages, they’ll call you and use a challenge response procedure to verify yourself, or leave you a voicemail instructing you to call the number on the back of the card. The entire process is safe, easy, and quick not matter what mechanism you use (I use all three depending on the situation).

It appears that these weaknesses in HSBC’s procedures have now caught the attention of others. A couple of days ago I was called by someone who mumbled around that they were from HSBC, and asked me for information. I declined, like normal. I called the bank back like normal. Except this time, nobody from HSBC had called and no suspicious charges were flagged. Apparently someone had attempted to phish me! I wonder how long it will take HSBC to address this now that their customers are being actively targeted?

Lets review how we got here:

  1. A poor anti-fraud algorithm means false positives are common.
  2. A lot of alerts means you need a large customer service staff.
  3. You outsource this, you don’t automate it, and put in place procedures that are fraught with security problems.
  4. Your frustrated and desensitised customers lose respect for the process.
  5. Phishers take note, and begin to capitalise.

HSBC Customers, Be Careful!

Be careful out there! Never give any personal information to anyone calling you, no matter who they claim to be and no matter how annoying the procedure is.

Cynical Optimism: Technical and Business Planning

I thought Rand Fishkin’s recent blog post on “Cynical Optimism” was a nice read.  He talks about how while there are plenty of things to be cynical about when it comes to humanity and our tedencies towards negative things, there is plenty to be optimistic about with regards to our progress as a whole.  The phrase “Cynical Optimism” is one that I really like to use when describing how to attack business plans, budgets, technical roadmaps, or other kinds of planning.

First, Be Optimistic

When setting goals, you definitely want to be an optimist.  Aim high, don’t limit yourself, and always strive for accomplishments that are meaningful and aligned with your values.  This is the classic “CEO” way of looking at the world and deciding where to go – strategy, vision, and confidence are huge assets here.  When goal setting, make sure you show your work!  Define goals in the form of “We’d like to do X because of A, B, and C”.  This provides important context and you’ll find that there are often other cheaper better routes that could be had which your haven’t considered.

Second, Become a Pessimist

Once you’d laid out your goals, make sure you switch hats and cast an incredibly cynical eye over your plans.  You want to identify everything that can, will, or should go wrong.  This is the perspective that a “COO” or “CTO” would take, as they’re the ones seated more firmly in the trenches.  The important thing here is to engage your team and let them know it’s OK to second guess goals in the context of determining how they’ll be achieved.  By critically assesing what it will take to arrive at your destination, you’re ensuring you don’t run off the rails enroute.

Now You’ve Got a Plan

Forcing yourself to wear both hats is hard – it’s often difficult to pull yourself across the chasm if you’re naturally predisposed to one outlook or the other, but if provides the following:

  1. Builds a culture of intellectual honesty.  It’s always easier in a team environment to just go along with the flow and feel like you don’t have any skin in the game.  If your team feels they can object or hone objectives, they’ll perform better.
  2. It can reduce the risk of making major mistakes.  By critically attacking your objectives you’ll anticipate problems and avoid major pitfalls that could have been forseen.  You’ll never know what you don’t know, but often teams drift into problem areas they could have avoided.
  3. In dysfunctional organisations, it’s amazing how almost everyone involved will know (and be able to point out good reasons) how goals won’t be achieved, well ahead of time.  You’ll prevent this kind of “death by politics” syndrome which affects a lot of companies.
  4. Bottom up planning is always the best way to meet top down objectives.  In other words, the high level goals can be set by the product owner, CEO, or visionary, but they’re on the worst vantage point to actually see how to go about achieving these things.  A tip on how to encourage realistic plans – don’t confer time estimates of any kind when setting strategic goals.  Just say “We’d like to do X” and see what comes back!

Lastly, Remain Engaged

Plans sometimes need to change.  You’ll need to react to new things.  As your team engages with the problem the goal-owner will need to remain intimately engaged with the team.  Fine tuning your goals is a necessary part of any meaningful project or endeavor – not fine tuning will just ensure failure.

This was My Brand Too!

Recently I’ve had two really dissapointing experiences with companies that I’ve admired and sought to emulate.

One of them I’ve admired for something like 12+ years.  If you asked me who the top companies in the world were, unequivocally, I’d list this particular outfit.  I loved their philosophy, their marketing, their service, everything.  I told people the way I felt as well.  The other company was a fast growing outfit who conquered their industry and was an inspiration to me at every step of the way.

Both of these companies have clearly lost their way and it’s a cautionary tale for those of us who are running, growing, or seeking to start out on something new.  The weirdest part of it is that I feel as though heroes of mine are gone.

These companies were my brands too!

How could this have been prevented?  What can we learn?

  • Don’t overreach – both companies broadened their product line to the point that they were doing too many things.
  • Don’t ignore the small stuff.  Things like consolidated invoicing don’t seem like a big thing in the developer scrum, but they’re huge to customers who are probably using all of your products because they love you.
  • Don’t underestimate the power of a financial credit.  Several times along the way a discount or permanent waiving of fees for what was admitted to be substandard service would have set things right in my mind.
  • Don’t ever tolerate rudeness to customers by you staff.  If this happens, get the staff to seak out the customer and apologise.
  • Don’t blame your failings on a third party.  It’s your fault for introducing the third party – third parties mean more responsiblility for you, not less.
  • Don’t allow tickets to wallow unresolved for months.  This just festers the entire situation.

At the end of the day, I won’t be using these providers as much anymore, and that’s sad, because I truly loved both companies.  We’re probably all guilty of a some or all of the above at some point, but it’s how we respond that matters.

Here’s How to Salt Your Own Passwords and Prevent a LinkedIN Style Password Problem

With all of the publicity surrounding LinkedIN, League of Legends, and possibly others, I thought I’d take a moment to explain how I manage passwords.  Yes, I quickly changed my password on LinkedIN, but using this method will add you just a bit more security if and when a provider screws up.  Remember, not every security incident involves a massive “post to everyone’s wall and make the evening news” style announcement!

I started this method after a screwup at Reddit a long time ago, which back in the day was storing plaintext passwords, and leaked them.  It has worked extremely well over the last six or so years.  For those who are unfamiliar with salting – it’s a method to increase randomness of passwords, and prevent rainbow attacks against password databases.  Technical readers may point out some more particulars about that statement, but the general statement should hold true.

Websites and other authenticators are supposed to salt passwords, but they can forget.  You can salt your own passwords by providing a hard to remember base password, then add some random characters to the beginning, after a fixed position, or end of the password.  This will make deriving your password more difficult, and will prevent (quick) account theft by an attacker taking your email and password and trying it at well known sites.

  1. Choose a decent password.  I recommend that people choose a nursery rhyme, favorite quote, saying, bit of religious text, or any kind of phrasing and choose the first letter or second letter of each word from that phrase.  This usually gets them a reasonably strong, easy to remember base password.  Capitalize a few of the letters and add a number at the beginning or end.
  2. Develop a salting mechanism. For every website that needs a password, develop a salting mechanism.  Have two rules of thumb as to how you derive a few additional characters based on the site itself.  Try to choose something relatively non-volatile.  For example – use the first four letters of the company’s name as it appears on their logo.  Or the last three letters of their domain name.  Or something else that may not change very often.  Then add these letters to your passphrase above at the beginning, middle or end of the phrase.  Why two rules?  So if your first rule doesn’t work due to some password scheme restrictions, you can use the second.
  3. You’re done. You now have an easy to remember passphrase that’s unique to that site (your base password + your derived salt).  Best of all, your password looks fairly random and even if your password from another site was stolen, it wouldn’t be susceptible to rainbow attacks, etc.

A few benefits of this approach:

  • You don’t need to rely on a “last pass” type application or system that stores all your passwords on a computer which may be hard to access sometimes.
  • It’s easy!
  • It’s free!
  • It really works – I’ve never had a problem with this, even with some of those sites that have weird password rules.
  • You now have a unique password to every system you access.
  • You can change the base password every year if you’d like, for even better security, and to weed out those accounts you forget about / never use.

There are no silver bullets to any of this.  Yes, this can still be attacked, but it’s certainly better than the “same password everywhere” or the “secure password for sites I care about and insecure one everywhere else” method.

I highly recommend you turn on Gmail’s 2 Factor security setting on your email account as well.  Particularly now that they’ve released an “offline” authenticator token generator which doesn’t need network access to work.

Stay safe out there!

Free Business Idea for a United Kingdom Startup

Start a Stripe.com clone for the United Kingdom.  Even better, launch to the wider EU and support accepting payments in GBP, USD and the Euro.  You’d instantly get worldwide press and massive attention from developers and startups within the countries you’ve chosen to support.

Stripe is too busy focusing on the USA despite saying they’re coming to the USA and other competitors in other markets are starting to spring up, like the newly announced PIN which caters to Australians.

Your competition will be incumbents like SagePay, Paypal, and Google Checkout, all of which won’t be able to move fast enough and are despised by your target market: startups and developers.  The only real threat to you in the United Kingdom is GoCardless which could attempt to compete, but they’re focused on UK Direct Debit payments at the moment.

The lack of competitors doesn’t really matter anyway – there’s plenty of room for you, plus the above, plus Stripe.  My training company software startup would use you in a heartbeat.  Dozens more would as well, just troll the forums begging Stripe to launch internationally and scoop up your first beta testers.  Seems all you need is a couple smart developers, a good lawyer, and a connection to a bank.

Any takers?

Whisky Web Day One Recap

Today myself and one of my coworkers attended the WhiskyWeb conference here in Edinburgh, Scotland.  This conference is in its first year, organised by a very small team, and was setup and organised from the ashes of a failed conference in just three months.  Located in the lovely Hub Conference Center (a converted cathedral) on the Royal Mile just steps from the Edinburgh Castle, it’s in a great location for those who have never been to Scotland before.  Most of the hundred or so attendees I met seemed to be from other countries and were really enjoying the city.

The conference technically started last night with a Pub Crawl that started at the bottom of the Royal Mile and worked its way up a series of pubs.  This was pretty well attended and all the speakers were in the crowd so it was a nice way to get introduced prior to the event.

Today the two tracks of talks were help in adjacent halls.  The ending keynote speaker even had a helium remote controlled shark swimming the air above the audience’s heads.  I’ve included some pictures.

Img_0487Img_0484Img_0492

Josh Holmes (@joshholmes) on Failure 

The opening keynote focused on failure, how to learn from it, and why it’s a good thing.  Josh is an American living in Dublin and we got to swap stories about motorcycles and Guiness and life without a car the night before.  I even got drafted to taking pictures of him with his own camera.  A nice short, inspiring, and positive talk to kick things off that was probably pretty foreign for most of the UK attendees.

Some of his main points:

  • You will fail.  It’s unavoidable.
  • A famous quote by former IBM CEO who had an employee make a 600k (in 1950s dollars) mistake.  Instead of firing him, he responded that he “Just spent 600k training him”.
  • Talked about a personal failure on a technical choice: SOAP vs. Remoting
  • “Losers always lose” – don’t give up and become a loser!
  • When times get tough, that’s the time to press on
  • Failure is always an option, so respect that.
  • Fail fast is a good concept, but doesn’t give you leave to be stupid (referencing a recent Michael Church blog post)
  • How to integrate failure into your life in a positive way:
    • TDD – fail before writing your code
    • Business Development – fail before writing your app or starting your company by doing research on your concept or idea.

A good way to start things off.

Rowan Merewood (@rowan_m) –  Estimation: “How to Dig Your Own Grave”

Next up was a talk on estimation and some common pitfalls.

Some Classic Estimation Mistakes

  • Sales creating estimates
  • One guy creating estimates
  • Creating estimates from detailed task lists
    • you know it will change
    • gives misplaced confidence
    • encourages micro management
  • Estimating a day as 8 hours

Moving on he talked about some strategies to get around some of these areas.  First he talked about how hours are too granular and suggested using half days as an example – “from the start of the day could you finish by lunchtime?” which can bring more clarity.

As a project’s length scales out, scale up the increments to 1, 3, 5, 7 days.  Anything over this and you’re not estimating anymore.  In response to the tendency of Agile folks not wanting to estimate or developers thinking estimates are useles: fine, stop calling yourself an engineer!

The last bit of the talk was spent talking about some conceptual models used to communicate estimation processes and risks to clients which were pretty interesting:

  • Good, Cheap, Fast – choose two
  • Triangle with points of Scope, Cost, Time – as you vary them, you vary the area which is the quality of the project
  • the MoSCoW model
  • the Kano model
    • Basic features don’t deliver high customer satisfaction
    • As performance improves, customer satisfaction goes up in a linear scale
    • “Exciter Features” generate a bigger satisfaction the more of them are added

Sebastian Marek (@proofek) – Ten Commandments for a Software Engineer

It took something like 15 minutes to get the powerpoint working on this talk, so I was annoyed before the talk even started, but Sebastian pulled it out and gave a great talk on software engineering principles important to him.

  1. Don’t disrupt legacy systems – extract, blackbox, hide behind an interface.
  2. Don’t reinvent the wheel.
  3. Commit often and make sure your messages are informative.
  4. Document early when the problem and your mind is still fresh.
  5. Don’t fear Q/A – use automated, unit, and functional tests along with a CI server
  6. Design for simplicitly.
  7. Don’t kill maintainability.
  8. Don’t repeat yourself – use copy/paste detection and other tools.
  9. Speak up early and often.
  10. Recognise and retain your top talent.

Brian Suda (@briansuda) on Data Visualisation

This was a very interesting (although I’m not sure how practical) talk that was a bit out of the norm for a technical conference.  Brian lived in the UK for awhile and is currently living in Iceland, authored a book on data visualisation, and spends his time seeing how we can help visualise various data sources.  His very graphically intense presentation was a very refreshing look at some unusual or creative ways to get data in front of users in more practical and memorable ways.

A few points:

  • 3D Charts are not advisable (proportion, view obscure)
  • Pay attention to your “data to ink ratio” (tufte, 1983)
  • reduce visualisation as much as possible e.g. simpler is better, remove unnecessary clutter
  • 2 schools of thought (simple, tufte and nigel holms more complex)
  • He showed several examples of PHP generated SVG visualisations which were really interesting, these are located here: github.com/briansuda

John Mertic (@mertic) – Lessons Learned from Testing Legacy Code

John is a member of the SugarCRM project, and described coming on board a few years ago when Sugar had zero unit tests and zero functional tests.  They’ve spent quite a bit of time changing this, and he discussed some tools to assist on finding bad code.

  • phpcpd – copy/paste detection
  • phpmd  – code quality report
  • phpdcd – dead code detection

He also made great points on the following items:

  • Don’t be surprised when you see crap
  • Better to focus on functional tests first
  • Build a culture of testing
  • Use CI or else tests are useless

Whisky Web Day Two

Tomorrow is a Hackathon located on the exact opposite end of the Royal Mile.  I probably won’t attend but all in all for £50, this conference was a bargain.