Startups, Take the Pledge for Your Community

We’re about to kick off another year, resolutions have been made, lots of parties have been attended, a bunch of milestones have been reached, and it hopefully feels good to get some closure on a year and plan for another.

I’d like to challenge you to add one more resolution to the list, and instead of thinking of it as a resolution, treat it as a habit, a lifestyle, a core part of your duty as being a member of your startup community.

As a bit of background, my startup Administrate is founded in Scotland, backed by Scottish investors, and a member of the fledgling Edinburgh startup community.  Using the term fledgling to describe a group of companies that has produced two unicorns (Scotland has the highest rate of unicorn production per capita in the world) seems a bit weird, but it’s true.  Like most non-Silicon Valley, non-Boston, (dare I say non-American?) locations, the community here is fairly young.  Most of the founders and senior management teams are first timers here.  All of us are trying to tackle the inherent challenges of building a sustainable business while learning as fast as we can, hoping to not commit that fatal mistake (last piece of learning?) along the way.

It Doesn’t Get Easier, You Just Go Faster

In cycling they say that it never gets easier, you just go faster, and I really believe the same is true with startups.  This stuff is really hard.  Even when things are really rewarding, you know you’re on the cusp of making it, you’re getting that positive press coverage, you’ve just raised money, you just signed that huge deal, whatever the milestone is, it’s still really, really hard.

And here’s the thing – if you’re a senior team leader or founder, there’s not many options for support.  Your spouse won’t fully understand what you’re going through.  Your board isn’t the right venue for a freakout.  Your direct reports have problems of their own that they need support to help address.

Feeling alone is one of the worst feelings, but it’s also one of the most common in a startup.

A Solution?

I’ve found that the single best avenue for support as a founder, CEO, or senior team member is to talk with a peer, usually someone who is ahead of you on the journey.  I don’t even mean support as in therapy, I mean support as in “I’m having this problem, how did you solve it?”, roll-up-the-sleeves style problem solving.

In the last 2 years, there’s been several key moments where I’ve received advice/suggestions/thoughts from members of our community that have caused me to rethink, come up with a plan, and have ultimately seriously transformed our company and helped make it one of the fastest growing tech startups in Scotland.  Things would have been very different if I hadn’t had that time from others who were ahead of me on the journey.

Take the Pledge

Spend 30 minutes every week helping other startups within your community.

You can spend an hour every other week, two hours with one person, etc., I’m not bothered about the mechanics, but just make sure you’re investing.  You can still run a highly structured calendar, you can ask people to come with a specific question or problem, you can implement this however you want, but the key is to be available, be supportive, and spread as much knowledge as possible.  Even if you don’t know how to help your fellow startup, refer them to someone who might, or tell them to read a book or go to a conference.

The funny thing about this is that the people that helped transform Administrate by spending time with me usually didn’t remember the conversation when I went back and thanked them.  I’ve had several instances of the same thing happening to me when someone mentions what a great help I was and it turns out it was a 10 minute conversation at a party.  These things add up, but they can only do that with consistent attention, over time.

The other interesting thing about this is that it’ll help you run a better business too! Taking your head out of your problems to focus on something else can provide clarity, and I’ve never found a situation where I couldn’t learn something from another company.

Lets Talk

If you think I could be of help, let me know! Hit me up on Twitter, email (if you don’t have my direct email, send it through the main Administrate email), phone, etc.  Sometimes it’ll take a week or two to get something arranged, sometimes it’ll be via the phone, but hopefully it’ll be helpful.

I’ve Never Wished I Was Less Technical

I got an early-ish start with computers when I was about 6 or 7 years old.  My dad created an MS-DOS boot disk that got me to a DOS prompt on the one of the hard diskless IBM clones in his office.  Once I had booted to the command line, I’d put another floppy disk (these were 5.25 inch floppies, the ones that really flopped) in the B drive, type in the commands which I quickly memorised, and my six year old self would be ready for some hardcore word processing.  Using Multimate at first, but then moving on to PC Write, I penned a few short stories and would love to visit the office and use the computers.  My Dad’s staff even gave me access to the holy of holies – the one real IBM PC (not a clone) which had a 5 megabyte hard disk, and was protected by a password.  I was solemnly lectured to never disclose the password, not to anyone, and I never have, even to this day.

And so it was against this backdrop that I became interested in computers.  When I was nine my family bought our first computer from a back alley vendor in the Philippines.  It was an IBM compatible XT Turbo, which was technically an 8088, with a twenty megabyte hard disk and a monochrome CGA monitor.  It was outdated when we bought it, as the 386 had just been released, but I loved it.  I spent hours learning different software packages like Norton Commander, PC-Tools, and playing games like the Commander Keen trilogy.  We kept it until I was twelve, and then gave it to a Chinese friend when we replaced it with a 486 DX-33 we picked up in Hong Kong.  Built like a tank, it is probably still in operation somewhere.

Despite this early introduction to computers, I didn’t get started programming until I was sixteen.  It was harder then – we had just got the internet but the tutorials and blogs and wealth of easy information we have now didn’t exist.  It was also difficult to get the necessary software you needed – thanks to living in China I could buy a pirated copy of Borland C++ or Microsoft Visual C++ for about a dollar, but they were a bit overwhelming to setup.  I finally found someone who knew how to program and begged him into giving me a few sessions.  He had a book, helped me setup my compiler, and agreed to meet with me once a week to teach me.  I even managed to get these sessions accepted as school credit during my junior and senior year.  I still keep in touch with Erik now, and he was one of the groomsmen in my wedding.  Together we even managed to cobble together two “junk systems” from spare parts and after a few weeks of constant trial and error, we got Slackware running in 1998, still one of my proudest technical achievements.

Every American college bound student knows that their junior year of high school is crucial for getting accepted into their university of choice, and I began targeting computer science as my major.  I was heavily advised that I should focus on a business degree instead.  At the forefront of that group were several of my math teachers, who knew that I didn’t do well in that subject, but there were also many others who thought that I shouldn’t “waste” my people skills in a technical role.

But I was really enjoying programming!  My first real project was a string indexing program which could accept a block of text (much like this blog) and then create an alphabetical index of all the strings (words) and the number of times they appeared.  Written in C, I had to learn about memory management, debugging, data structures, file handling, functions, and a whole lot more.  It was way more mentally taxing than anything I’d ever done in school, and it required a ton of concentration.  I wasn’t bored like I often was in classes.  It was hard.  Erik would constantly challenge, berate, laugh at me, and most importantly, accurately assess me using an instructional style that I’d never been exposed to before – he only cared about the results, not the trying.

Although I was dead set on computer science, I really liked making money too.  My parents noticed this and for one semester during that crucial junior year they offered me financial rewards for grades achieved.  After I’d hosed my dad for over a hundred bucks due to my abnormally high grades that semester, he announced that “grades should be my own reward” and immediately discontinued the program.  There were plenty of people telling me that a degree in business would better suit these talents of mine, and if I was honest, at the time I knew they were probably right.  I was great in my non-science subjects, I could mail it in on papers and still get an A, and I knew that diligence, attention to detail, and math were weaknesses.  Getting a business degree would be stupidly easy.  Getting a computer science degree would be pretty hard, at least for me.

I was close to changing my mind when Erik mentioned, “You know, I’ve never wished I was less technical.”

This is advice that I really took to heart.  It rung true when I was seventeen.  It’s even more true today.

For me, the advantage that I incurred by getting a computer science degree meant that I could start my own consulting company and be one of the technical contributors while also being responsible for the business stuff.  It helped me obtain positions of leadership because I didn’t need technical middle men to explain things to me.  If things were going poorly, I could help manage the crisis effectively, and when things were going well I could explain why and point out the technical decisions that had carried us to success.

Guess what?  I got to do all the business stuff too!  Having a technical background has never limited my business acumen or hampered me in any way.  I haven’t coded for money since 2007, but I use my knowledge and experience every day, and I stay up to date with technology as much as possible.  I love it when our technical lead shows me the code behind the latest feature.  If anything, having an appreciation for complexity, code, and systems design has only helped me design and implement better budgets, business models, and pricing schemes.  I’ve never met any “business person” who is better than me at Excel, the language of business, and much of that stems from just knowing how to program.  This has made me the goto guy in almost every planning or budget meeting I’ve ever been in.

Unfortunately, it doesn’t work the other way.  People who aren’t technical will always struggle in any technically related environment.  I’ve met so many people who have struggled and struggled to make their great idea a reality chiefly because they weren’t technical, couldn’t contribute, couldn’t cut through the bullshit, and therefore couldn’t effectively manage their way to success.  Sometimes, they’ll try to fake it and just lose the respect of the programmers.  As many times as I’ve thought to myself how glad I am that I have a technical background, I’ve had others voice to me the frustration that they just wish they knew more about technology.

If you’re reading this, and you’re trying to figure out which way to go in life, make sure you get technical first.  If you didn’t choose that path, there’s still plenty of time – get out there and learn to code.  There are so many resources.

This is what the “everyone should learn to code” movement is really saying – not that everyone should be a coder, but that everyone could benefit from understanding the environment, pressures, and disciplines that drive a huge part of our economy.  It’s not just business either – artists can benefit from more creative displays and better performing websites, not-for-profits could benefit from volunteers who know how to help out in technical areas, and it’s just nice sometimes to be the guy who can get the projector working in a foreign country!

So get technical.  You’ll never regret it.  And if you’re a programmer and you ever see a kid who wants to learn, help them out, you may just find a friend for life.

Focus on Systems, Not Goals

DilbertI had the pleasure of reading a recent article by Scot Adams (creator of Dilbert) on the secret to success.  One of the points he made really resonated with me as it’s something we’ve been stressing (with increasing success) for the last few months at Administrate:  Don’t focus on goals, focus on systems.

In short, rather than focus everyone on your Key Performance Indicators (although these are important to know and track), focus instead on systems and processes that breed success.  For example, like most organisations with a customer services team, we have a lot of data about tickets, resolution times, how long issues sit in different status states, and a whole lot more.  It’s really easy to get caught up on “how many tickets we have open!” when zero bugs or zero open issues isn’t really the point.  Instead, we’ve been focused on perfecting the systems and processes we use to tackle these metrics.  Instead of feeling successful when we reach an arbitrary (and impossible) goal of zero outstanding issues or problems, we’re focusing on improving the systems we have in place to tackle these issues.  Now we feel successful when we can know that issues will be triaged, attacked, and solved in a correct and repeatable manner.  See the difference?

Get the system right, and your KPIs and other indicators will fall in line.  Get the system wrong, and you’ll be chasing an increasingly dismal looking set of metrics that never seem to improve.

As we continue to grow and scale, focus on systems and our values becomes more and more important.  I’m really proud of how far we’ve come as a team, and am very excited at what’s still to come!

Thoughts on Samsung, Apple, and Patents

I’ve been struggling about what to make of the recent patent spat between Samsung and Apple.  I do think that the level of discorse provided by most techies on this issue is somewhat lacking.  Hacker News seems to have come down firmly on the “patents are evil, ergo Apple is too” side of things.  I’m not sure it’s quite so simple.

Here’s what I know:

  • I’m against business process or “method” patents.  This generally covers most software or patenting things like algorithms.
  • I think there is an incredible amount of copying that goes on in the tech world.  Every company does it, and every company cries foul when it’s done against them.  I’ve written about this before.
  • I do believe that copying a tangible product should not be legal or tolerated.  Fake clothing brands, for example, or counterfeit items are not only crass, they can be dangerous (remember the baby formula issue in China?).
  • It was obvious from day one that Google and Android blatantly, crudely, and poorly ripped off iOS.  They didn’t spend any effort on being original or attempting to innovate.  I think the mental gymnastics that are performed by many geeks trying to absolve Google in this respect are intellectually dishonest and silly.
  • In my experience, the best defense is a good offense and the only real way to beat someone who’s ripping you off is to out innovate them.  Consumers will generally figure out who’s for real and who is playing second fiddle.
  • There have been several incidents over the past few years on Hacker News where a startup felt they were being copied by others, and the entire community expressed a lot of outrage over this.

I’m an Apple stock holder and an Apple customer.  Have been for years.  I think the conclusion that I’m coming to on this particular issue is that I feel a guilty party got what they deserved (for product trade dress copying) but the means to the victory was really awful (using the patent system).  I’m not a lawyer, but it seems to me if Levis can sue someone for ripping off their logo or making fake goods without owning a patent to the blue jean, why can’t we have that method in the tech industry?  I’m curious if using the patent system in this respect was a “nuclear option” that sends a signal to everyone else who might cross them in this area.  Apple certainly learned a lot during their lawsuit against Microsoft in the nineties and probably had their playbook well thought through prior to even launching the iPhone.  I also feel like Google got away with something here, as they were culpable in ripping Apple off as well.

The most bizarre thing about this whole mess is that somehow Microsoft came out looking like a world class innovator with their new Metro mobile OS which looks nothing like iOS.  Ten years ago, who could have imagined a scenario where Apple wins against someone ripping them off, Microsoft is the innovator, and Google is the evil corporation blatantly and poorly copying someone else?

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.

Simplify Everything

There’s a lot of abstract advice about employing simplicity when building great products or writing great code.  However, life and products (particularly in the Enterprise software market, where I’ve spent most of my career) are complicated.  It’s often hard to gleen concrete examples of what these maxims are trying to communicate.

The other day I was in a pub waiting for a lunch meeting to start and I got to witness the week’s beer delivery.  This is a fairly hard problem to solve efficiently if you’re in a city where parking is difficult (or nonexistent), buildings were constructed hundreds of years before accessibility laws (meaning stairs and tight doorways), kegs are very heavy (over 200 pounds when full), and where a lot of beer is consumed requiring frequent deliveries.

If you or I were designing a solution to this problem, we might come up with this solution:

  • 1 truck
  • 2 employees (1 driver, 1 loader/unloader)
  • 1 automatic lift at the rear or on the side of the truck
  • 1 appliance dolly that can move up or down stairs

We’d be pretty happy with that.  Not the worst solution in the world.  It’s possible we could reduce to one employee but the automatic lift will take enough time setting up and lifting that we’ll probably exceed our very short “stop with flashers on” window.  We’d therefore need to park and have someone stay with the truck, or make several “fly byes” to stay within the unloading time limit.  This will really limit how many delivers we could make in a day, possibly requiring a lot of delivery crews.

Here’s how they actually do it:

  • 1 truck
  • 1 driver / unloader
  • 1 airbag

The driver pulls up, parks the truck right outside the entrance of the pub with the flashers on, whips out his airbag from the passenger seat, rolls up the side of the truck, pulls off the keg and lets it fall right on the airbag.  He then rolls it into the pub (for those with cellar keg storage, they have their own airbag) and after about 20 kegs and less than 5 minutes, he’s out of there.

A lot less cost, a lot faster, and no expensive equipment.  

Simple.

Img_0871

Hating Your (Potential) Customers: Content Licensing from a Major Record Label

Have you ever wondered what’s involved in licensing a popular band’s music?  A few years ago I was curious and wanted to see about using a rock band’s song (signed to a major record label, Sony’s Epic music) for a marketing project.  There are some bands who get the internet, and some who don’t, and this band (one of my favorites) is probably somewhere in between.

First, I had to spend quite a bit of time googling and navigating around their record label’s website.  Finally, I found an obscure reference to call a certain phone number.  I called it, and had to navigate through a maze of IVR options, pressing several numbers to wade through several different menu levels.  Finally, I got dumped out to an answering service that played a message instructing you to write a physical letter describing the band, song, use you had in mind, and several other criteria.  The message helpfully repeated itself, then hung up.

I remember being shocked at how arcane the entire thing was, despite the well documented track record of major media labels and distributors to make things as difficult as possible for consumers.  Needless to say we never sent in the physical letter, and I never actually found out what it would cost.

I like to remember this experience when thinking about the barriers our customers have when attempting to give us money.