Developers, Ecosystems, the Universe and Everything, i.e. 42

Someone once said that “at a startup you’re not competing with other startups, you’re competing with apathy”.  I’ve found this to be true over a long stretch in startup-land.  I never got crushed by competition, but against apathy my batting average is sub-Mendoza line.  I think about that a lot.  If you and I both jump in a lake, the fact that I floated longer than you did doesn’t matter much if we both drown.

greenhouseWhat brings this to mind is a discussion I had at a team dinner with the estimable Citizen Sigmund of Scrum Inc.  She mentioned some challenges she was having coaching Scrum with a particular team at a company out in a lightly populated section of the state.  The team-dynamics she described reminded me of a difference I always see between teams in hothouse ecosystems like Boston, New York, Seattle and San Francisco and those outside the hothouses.

In a nutshell,  even among comparable companies, it’s almost always more difficult to get teams to buy into tactical Scrum outside the hothouse.  And this is true even when these teams are failing and desperately unhappy.  They often seem like they’d rather fail in a way that’s familiar to them than succeed doing things differently.

sumoThe third leg of this observation, was a dark data point I gathered a lonnnnngggggg time ago.  Back in the day I figure skated.  Yes, it was often as funny as it sounds.  And having done it for many years, I had a certain impression of how I looked out there, how good I was.  Then I saw myself on video.

Oh, ignorance was certainly bliss.  When I skated, it felt good, so it must look good … it must be good.  It wasn’t.  Same thing happens to dev teams in the wild.  They get into a way of working and the paychecks keep coming so it must be good.  But it often isn’t and they have NO idea because they’re not surrounded by world-class competition.

How does this relate to startups and apathy?  It’s the age-old question of how do you know when you’re succeeding.  Startups often measure themselves against each other – how much money we’ve raised for example – when what they need to measure their success against is their market’s innate inclination to DO NOTHING.

When I skated, I knew what good skating looked like from seeing good skaters in person, and on TV, but I didn’t know what I looked like.  Devs in the wild have the opposite problem.  They know what they look like, but they don’t know what good devs look like.  They only have each other to refer to, not a wider pool of people doing the same thing in different ways.

What does it all mean?  Measure things, don’t assume you’re doing well as I did on the ice before the age of video.  Measure the right things, don’t be That Guy sitting around at Starbucks bragging about how much money your company raised.  And finally, compare your, your team’s, and your company’s metrics to the best in the world, not just to the people and companies in your immediate vicinity.

 

 

Some Concrete Things To Think About With Technical Co-Founders

I talk to a fair number of people who are looking for technical co-founders to help them build web-based businesses.  When we get to the point where we decide not to work together, the smart ones always ask me if I have any advice for them moving forward.  And I do.  Here it is.

cofounder.jpg

It’s tempting to think of yourself as the next Steve Jobs and to imagine that the bearded man you’re having coffee with later today is the next Steve Wozniak.  Not happening.  You’re not Steve Jobs and that guy you met on cofounderslab is just an ungroomed jumble of untested technical skills, social awkwardness and unknowable cofounder potential.  The question is – What can he do for you in the next 18 months?

If I were a non-technical cofounder building a web app from scratch I’d have two demands of a technical cofounder, or contract house. First, that they build good stuff – i.e. that the product work and that it looks good.  Duh. Second, that they can create, and from day one deploy to, a continuous integration infrastructure – aka immutable infrastructure.

“CI from day one” means throwing away a little bit of time in the beginning setting it up, and dedicating a little bit of cash burn in the long run. For your purposes, CI is a system that can take a change to a web site as committed to source control, run automated tests against it, raise a flag if the tests fail, or deploy successfully to staging/production if they pass.

cheeseburger.jpg

Think of your infrastructure as a sort of 3D printer that takes your designs and turns them into real-world objects.  Your business, at heart, is a machine for producing iterations of a web site.  If it can do that quickly, at high quality, it may be worth something someday.

If your business produces iterations of a web site that take days to code trivial changes and those changes fail deployment every single time you go to production then what you’ve built is not a business – it’s a learning experience.

What you will get if you talk to the young and ambitious crowd is a lot of people who:

  • can work within an infrastructure that someone else has set up OR
  • can set up a one-off web site from scratch in the cloud using a bare-naked Linux instance with a bunch of stuff configured on it and can redeploy manually, or via source control (not deployment packaging).

They have no idea how to setup something that multiple people can contribute to, that automates testing, and that deploys correctly every single time.

bus-factor.jpg

If you set up immutable infrastructure, the bus-factor for your technical co-founder goes to zero, which is something that you desperately want and that they shouldn’t fear.  But even better, when you have an infrastructure that works, you can profitably employ all those cheap and available people who can only do good work within a working infrastructure – e.g. junior web devs, recent Startup Institute grads …

And if you’re thinking about outsourcing – you must, must, must own your own infrastructure, every little bit of it including DNS.  And think very carefully about the access rights and take continuous backups.  Get a friend to setup the accounts if you have to, but don’t rely on your outsourcer to do it, and don’t have them as administrative owners of any piece of it.  Having your outsourcer provision your infrastructure works great right up until the first time the two of you disagree about money.  Ask me how I know this …

I would also spend some time reading up on the concept of a Scrum Product Owner, even if you don’t intend to ‘do scrum’. As founder you have the ultimate authority over everything, but some of these responsibilities you’ll entrust to people you collaborate with. After all, you don’t want to micro-manage.  That’s fine, but the PO concept defines the set of things that, as “product person”, you need to own and not compromise about.  I’ve found over the years that successful companies, even ones that don’t do Scrum, concentrate the same set of responsibilities within product management that Scrum entrusts to Product Owner.

And, from day one, implement the concept of the sprint demo. You will find, talking with devs, that you’ll ask the question “Is it done?” and they’ll say “Yup, X, Y and Z are all set.” Only later will you discover that “it” and “X, Y and Z” are different things. If it’s done, prove it, and if you can’t show it, it ain’t done. This is HUGELY important with outsourcers.  The sprint demo is about quality and accountability.  Live it.

Notice that I haven’t said anything about stack.  Frankly I mostly don’t care about the stack and you shouldn’t either. RoR with some javascript framework seems to be a standard thing, and well-known among the offshores, but there’s a dozen good ways to write a web app these days.  In any case, whatever stack I recommended today would be wrong tomorrow.  Immutable infrastructure, on the other hand, is a sine qua non from this point forward.

In a nutshell, here’s my advice:

  • Immutable infrastructure
  • Own your own infrastructure
  • Be a Product Owner
  • Enforce the Sprint Demo

And remember, easy for YOU to do is easy for ME to say.  Ahh, the joy of blogging.

Please Wait – How It’s Your Friends Not Your Enemies Who’ll Get You In The End

dinosaur-02Like most developers, I have a couple of non-profits that I’ve supported for many years (see here, and here). When I first met these folks,  Kip and Fran, dinosaurs roamed the earth and their professional home was paying tens of thousands of dollars annually in maintenance contracts for their Wang word processors. That’s how long ago it was – Wang was a thing. The progression of that relationship, and how it compares to my paid work has taught me a lot.

One of the things I learned is that, it’s not your enemies that will get you, it’s your friends. I spent the first few years bemoaning the performance, or lack thereof, of some of the volunteers Fran roped into helping her. I was in the process of evolving into a Scrum fanatic and the behavior of volunteers drove me straight up a tree. They delivered, they half-delivered, they showed up … or not – crazy-making stuff.

duhThen it was my turn. I committed to a task (now forgotten – I wonder how that happened?) and dropped it completely. I’m sure I had an excuse and it may not even have been lame. But the job was on my plate, they waited for me, and it went undone. When I realized what had happened it struck me almost instantly that for Fran at least, her friends were way more dangerous than her enemies. I’m sure Fran was thinking “Duh – volunteers.” but to me it was light dawning over Marblehead.

At the same time that particular light dawned over Marblehead, I was coaching, forming and scrum-mastering a number of Scrum teams. At standups, over and over again I’d have this little exchange with one or more team members:

Team member: I’m waiting for X

Me: Why?

Team member: Ummmm

I started looking closely at the “waiting” phenomenon and realized that the waiting impediment always fell into one of these buckets:

  • Waiting for someone to do something
  • Waiting for a purchase
  • Waiting for an external deliverable

I also realized that the waiting was 99% bullshit.  I started asking people “why didn’t you do it yourself?”. Magically, half those impediments disappeared without my doing anything more than arching an eyebrow and asking a simple question.  The Scrum principle being served is

Incentivize cross-training, de-incentivize specialization/siloing.

mi-ch438_amex_j_20150121164942Waiting for a purchase? Buy it.  Put it on the company credit card and fight with accounting later. What are they going to do, fire you? Many times, I bought stuff on my own nickel just to “not wait”. Abusing the corporate credit card became a foundational principle of the group and I got most of those personal nickels back in the end too.

Waiting for an external deliverable? Split the story, finish the half that can be done and put the dependent half on the product backlog.  That makes it the Product Owner’s problem, not yours. And that means it’ll go away because the PO has way more juice than you do, and his ass gets fired if the product doesn’t happen not yours.

People realized quickly that reporting a status of “waiting for X” would lead to an awkward standup moment, so they got proactive and started bringing them to me asynchronously.  And the group went faster.

Eventually I just told people,

Don’t wait for anyone or anything.

It was that simple. If you’re building stuff for me, you don’t wait for anything.  Call it Rodley’s First Law of Getting Stuff Done.

As I worked with more and more concept-stage entrepreneurs I realized that they needed the First Law of GSD even more than I did as Scrum Master of a team of builders.  Waiting is death for startups.

When you wait, you’re wasting the only resource that you can’t replenish – time.  Mark Suster addresses this indirectly here when he says

In a startup market the biggest competition is inertia

Waiting is inertia.  Stop it.

 

 

Consultants Aren’t People, and Other Fallacies

A long time ago, in a suburb far, far away, I was a solo consultant, making my way in the world doing fun technical stuff. It wasn’t an easy life, but it had its attractions, and few dangers or so I thought. The solo consultant’s only natural predators are other consultants and CFOs who are always looking to stretch payment and cut headcount.

In this long-gone time, I was sitting pretty having just completed a two month contract. All I needed was the check. After farting around for far too long, I’d finally gotten my invoice in the queue and I wasn’t worried. Until I got a call from the friend who’d sold me into the contract. The company was in trouble. Deep trouble. If I wanted to get paid, I needed to get up there.

When I got there, I met the friend, and the new CFO who I realized had been brought in to wind down the company. This guy, who owed me nothing, pulled a check from the bottom of a big pile and handed it to me.

This will clear, if you can get the CEO’s signature on it.

I took a deep breath.  I am not a leg breaker but I really like getting paid.  Thirty minutes later, a very surprised CEO got a call.

tonysopranocar3

I’m sitting in a car outside your house. I have the check you guys wrote me but there’s no signature on it. Could you come outside and sign this for me?

Not knowing that I have a peaceful nature and all the muscle tone of a jellyfish, he hurried out and sheepishly signed my check. I ran to the bank and cashed it.  “Yes, I’ll take that all in cash please”.  Two days later, the sheriff padlocked the doors as the company went Chapter 7. A week later, I used that money to buy a new car for cash.

As I said, the new CFO owed me nothing. But he looked at the mess this company had become, saw that I was going to lose almost 20% of my annual gross out of it and he took care of me. I’ve never gotten to repay that favor and probably never will, but I also never forgot it.

In the intervening years I’ve had occasion to use contractors and remembering that episode, I’ve always been hard on them in only one respect. Get your invoices in. I don’t have to do it, and various CEOs have wished that I wouldn’t.  But I do and a couple of times along the way it’s paid off in a guy walking away with one or two more weeks of money than he would have gotten otherwise.

It’s the same with permanents as I covered back here. Over the years there have been a handful of employees who have done great work for me and I’ve almost never been able to pay them market rate, so you take care of them in other ways. I take care of everyone who works for me, but the performers – I will do anything for them. That’s kind of the deal, everyone who’s done good work for me has moved my career, and that’s what I owe them.

How to Get a Developer to Build Your Healthcare App

As a Google Glass guy, and a bit of a healthcare gadfly, I have doctors coming to me with ideas all the time.  I love them, they’re beautiful people and fun to talk to.  Imagine for a moment that you’re one of those guys.  You have an idea.  Congratulations.

outofhisleagueYou need “a developer”.  So somebody hooks us up.  But there are a few things you need to know about me before we ‘do it’.  I’m really popular these days.  You, on the other hand, are the guy in the hockey shirt.  In dating terms, I’m a 9 and you’re a 6 (maybe).   If I’m any good at all, and I am, I have companies led by non-MDs that could make me sick-rich knocking on my LinkedIn account every day.

So how do you get me to ‘do it’?  Remember that sick-rich comment?  What I hear most of the time when a doc pitches the potential of a project is

this could be made into something by someone who isn’t me if they worked really hard for a long time without  any help from me, because of course my day job saving lives keeps me very busy, none of which should affect the 90% of equity I deserve for having the idea

Seriously, just stay home and learn how to code yourself.  I mean it.  You want better outcomes? So do I.  But if you want some action, make me laugh.  Have a sick-rich pitch.

Don’t tell me you have no money.  In dating terms this is the equivalent of telling her you have no car and live with your parents.  You wear a tie and work for an institution that is both immensely profitable AND non-profit meaning that rich people give it money for no good reason.  There’s an entire department dedicated to raising money for you – they’re called the Development Office.  Go visit them.  You’re in a highly-compensated profession.  All of your peers have money and some of them angel-invest.  Your employer gives grants for ideas about better handwashing.  If you can’t find money to develop your idea either you suck, or your idea sucks.

And speaking of your employer, you signed some papers when you went to work for them.  It’s time to reread those.  If your employer is one of those that claims ownership of everything you think while you work for them, then you and I will not be having a relationship.  You’re like the frat boy who never goes anywhere without a half dozen drunken brothers.  Nobody wants to date that.

engagementIt’s also important to remember that the guys coming at me every day on LinkedIn with the sick-rich pitches aren’t looking for a one-night-stand, they want to get married.  They’re pitching CTO or lead-developer roles with salary and founder-equity on teams that are “going to be the next Uber”.  When you come at me with a one-time idea for an app that will take a few weeks to develop and probably won’t make boatloads of money, you’re pitching a one-night-stand where I pay for the taxi and the motel room and end up feeling used.  You’re not that handsome.  A one-off project that has no money now, and no breakout potential later, is a job for a fuck-buddy.  Think back to your dating days.  How many 9s slept with you on those terms?

Clinicians are popping up all over the place building companies with long-term potential based on technological innovations.  See here, here, here and here.  They focus, park their egos, commit their own time, realize that the idea is the seed, not the tree, and they collaborate with people who can do the 99.9% of building a business that they can’t.  You can do well and do good in this business while working on fun technology with smart, dedicated people if you approach it that way.  Be that.

When Is It Okay To Write Shit Code?

poopThe way I’ve always done startups has, as possibly the foundational element, a Jungle Law Rule*:

If you make it to the next level (seed funding, Series A, pilot, first sale …) whatever you did to get there, barring illegality or unethical conduct, was by definition the right thing to do.

Many a beer has been hoisted to that particular gem of wisdom.  It is the “Get Out Of Jail Free” card for writing shit code.  On the other hand, I’m also a big Scrum guy and the way I’ve always done Scrum has, as a foundational element, a National Park Rule*:

Never end a sprint with more technical debt than you started with.

Now it should be obvious that the National Park Rule and Jungle Law are in conflict.  From concept through seed stage Jungle Law may be the only rule.  If you don’t get revenue traction and/or seed, you don’t exist.  You could be coding with your feet, naked in the middle of Times Square and the universe still has no excuse to pay attention to you.  As the computer that’s unplugged is as secure as it can be, so the source base that has no source committed to it is as clean as it can be.  Unlike Catholics, source bases are born free of sin.

As part of Scrum, the National Park Rule is aimed squarely at organizations that have already achieved a level of dysfunctional maturity.  When there’s a substantial code-base, multiple people contributing to it, and chunks of production code whose original authors have gone on to “better opportunities”, the National Park Rule clearly prevails.  So in the production of actual code, Jungle Law prevails at conception and National Park Rule prevails at maturity.  There must be a point where Jungle Law yields to the National Park Rule.  Where is it?  How do you know when you’ve left the Jungle and entered a National Park?

Number of contributors.  Shit code is harder to maintain than the other kind.  Harder means “takes longer”.  That “takes longer” increases exponentially with the number of people who are hacking it.  Experience has shown that a decent rule of thumb for that number is 3.

Availability of original authors. The success of shit code often depends entirely on the presence of the original coder to tweak it.  If you can dish a tweak simply by saying “you wrote that piece of shit, you fix it” then Jungle Law is potentially still viable.  If the original coder is gone, then in the immortal words of @StartupLJackson “you need to fix that shit”.

Product market fit.  One of the few valid excuses for writing shit code is that the concept behind it may be so stupid that the whole thing will be thrown out. Once it’s clear that the product will survive for some length of time then you’ve entered a National Park.  In fact, the presence of product-market fit alone makes the codebase a National Park.  If you want to keep those hard-won customers, you need to continually reduce the chance that they will ever find out just how many crimes against computer science you committed while wooing them.

Now if you have any pride as an engineer, you’re crossing yourself and screaming, “It’s never okay to write shit code!!!”  Well, get a grip Matilda, that’s exactly what I’m saying.  It’s okay sometimes to write shit code.  Here’s how to decide:

  • Are you in a Jungle Law situation?  No?  Then it’s never okay to write shit code.
  • So you’re Jungle Law … have you at least looked into how to do it well?  No? Then why do you think your way is wrong?  Come back after you’ve spent an hour Googling.
  • It’s Jungle Law, you have an idea how to do it right, and it’ll take too long for you to do it that way.  Is there someone else on the team who could help and you just haven’t asked because you’re afraid of showing them how much of a dope you are?  Yes? Come back after you’ve asked.
  • Have you laid the choices out for the management team? If you’re committing crimes against computer science, you’re doing it in their name.  It’s always astonishing how flexible the schedule gets when you tell the CEO just how ugly a hack you’re gonna have to do to make the schedule he’s laid out.  Jungle Law pretty much means that you’re in a life-and-death situation for the company.  That’s really his call, and startup CEOs have an ugly but unavoidable habit of keeping their foot on the accelerator even when the need for that has passed.

It’s Jungle Law, you have an idea how to do it right, it’ll take too long to do it right, there’s no help available and there’s no flex in the schedule?  Okay, you have my qualified blessing to write shit code.  But remember, I’m holding it against you and  you should hold it against yourself.  If you were a better coder, you wouldn’t have to write shit code and I wouldn’t have to fire your sorry ass when we finally get to Source Tree National Park.  Welcome to the startup life.

*, ** Neither of these rules should be confused with The Superhero Rule (formerly known as The MIT Guy Rule):

Whatever I did to get wherever I got was, by definition, the right thing to do because I did it.  Only other people write technical debt.

How to be a manager

People talk a lot about “the startup life” and how it is to dive into it from regular employment, but what about the other way round?  Having recently completed a rare stint managing developers at a large-ish company of about 400 people (don’t laugh – that looks big to me) I wanted to share a few thoughts on how it is to go from raw startup life, to life in a big company.

The best part of managing devs at a big company is that if you do it right you can have a substantial number of people writing production quality code together at the same time, doing great big things you can’t dream of at a two-man startup.  I never fully appreciated the joy of that phenomenon until I went big. No demos, no wild pivots, no fire drills, no due diligence, no clueless angels or arrogant VCs, actual QA, a Build Guy (Hi Mike!), no working with crazy people and C players because they’re the only people crazy or desperate enough to work with you. Just big monitors, pricey tools and people who know how to use them going full bore.  The company was hugely successful, the group was hugely productive and for the most part, people enjoyed working there.  I enjoyed the hell out of that part.

Still, it had it’s downside.

irrelevantLesson #1: You are irrelevant Part I.  There is nothing you can do all by yourself.  Even if there is, you won’t be allowed to do it all by yourself so … there is nothing you can do all by yourself.  I often found myself reveling in (i.e. milking) the tiniest little tasks simply because I could do them by myself on my own authority.  The depressive effect of this lesson is offset by …

Lesson #2: You are irrelevant Part II: you are actually irrelevant.  Unless you are prone to huge mistakes, your presence or absence will not affect the business in any material way. This can be comforting if you have a long commute, enjoy long lunches or if you like to turn your phone off when you go on vacation.  But in those fleeting moments between arriving late and going to an early lunch, if you feel like, you know, doing something, you can apply …

Lesson #3: The most productive thing you can do is to hire and keep productive people, and fire unproductive people.   If you’re in a one-new-hire-every-couple-of-months growth mode, the hiring takes maybe ten percent of your time.  The firing, maybe a couple of days per year.  This still leaves you lots of time for applying …

danquayleLesson #4: Keep your crew happy.  In some organizations, happy people are not productive.  For example, prison guards are happier when they’re not watching prisoners.  Fortunately, software development is an addictive activity and thus its practitioners are happiest when working.  The faster they are working, the happier they are.  The harder they are working, the happier they are.  Whether you want monstrous edifices of code, enormous slinky snakes of elegant functionality, or lots of little hacks, well … that’s all the devs want … to be allowed to make these things for you and your only job is to let them do it.   On paper, it’s easier than being vice president.  Dan Quayle could do this job.  Mostly it requires getting the developers to tell you what needs to be done, telling them to do it, and then resisting the urge to tell them how to do it**.  In general, this makes them happy.  As Dilbert said when HR installed a lab-rat feed-slot in his cube wall:

This job is so stressful … but the pellets are excellent

You can hang out with the crew, or brood in your office but all this management by walking around bullshit doesn’t matter.  The only time the crew really needs to see you is when you’re applying ….

Lesson #5: Make enemies of anyone who disrupts “the flow”.  The meeting-callers for example.  Being just a manager who by definition had nothing better to do I used to go to meetings in place of my guys whenever I found them invited to some bullshit meeting.  This cut way down on the meetings, bullshit and otherwise, especially when I told the other participants that I came in Sally’s place because Sally had better things to do and I didn’t.  I made it clear to my guys that I would forgive them for writing bugs, but not for wasting time in meetings.  It got to the point where my guys apologized to me for going to meetings, or worse for calling them.  This is the way you want it, but it will make plenty of enemies.

Then there’s the team-organizers, the guys who want to form a flying squad for every little project that comes into their heads. This squad deals with a single issue and the organizer feels like a hero, then the members go back to what they were doing before … assuming they can remember what it was and why they were doing it and that whatever it was didn’t fall apart because they couldn’t keep a team together long enough to finish it.

Watching the flying-squad phenomenon in action reminded me of those corny TV shows where everyone gets together to put on a show to raise money to put a new roof on the orphanage.  Let’s have a show!

thomasWell actually, let’s not.  When you see one of these trains coming down the track, your dignity as well as your membership in the Agile community requires you to throw yourself in front of it.  Fortunately, as a manager you have nothing better to do than lay on the tracks, waitin’ on the Double E, and this on-the-fly team would probably have lots of meetings so squashing it is a two-fer.  Gumming up the wheels of the locomotive and bleeding all over the tracks ensures that you won’t go far in the company, but even if the train runs you over, you will certainly go to Agile heaven.  And going far in the company isn’t an issue anyway because of …

Lesson #6: So after a) hiring a bunch of good people b) realizing that you’re irrelevant c) letting the devs do pretty much what they think needs doing and d) making enemies of everyone in the company who likes to interrupt the flow, the smartest thing you can do is to not overstay your welcome.  You’re a startup guy.  Every big company needs a dose of that now and again, but too much is toxic.  Don’t be toxic.

** Okay, there IS also the small matter of getting Product Management to organize their thoughts, but if you can’t do that  you probably shouldn’t even be vice president, let alone a dev manager.

Sometimes the little things aren’t so little

In my last post, I gave myself and all the devs a beating for being passive-aggressive about marketing-driven name and terminology changes.  For not being-with-the-program when the product team wanted to make an itty-bitty change they’re entirely within their right to make.  In thinking back over some of those types of situations, there was really only one good reason for being a dick about that stuff – when we had the old name embedded in the source code of the product itself.

babynamesLet’s say we have a product called BottleRocket.  Well, then we probably have a java package named com.pointyhairedstartup.bottlerocket.  Then let’s say we rename the product to Kite.  Okay, renaming a package is no big deal.  We probably also have a class named BottleRocketMain.java.  Again, renaming a class isn’t a big deal.  But maybe it’s a webapp and we have a war file called BottleRocket.war.  Ooh, that’s a little uglier, because that means we have URLs calling https://pointyhairedstartup.com/BottleRocket.  And the tools for refactoring URLs within a project are not as good as the ones for refactoring class names.  And URLs are also abused – called willy-nilly from wherever someone who wants to call it can jam a hard-coded URL in.  They live in config files or are constructed dynamically in ways that are hard to detect.  And you won’t catch them in the build like a bad class name.  You’ll catch them at run-time, when some sad little user clicks a dynamically constructed URL that has the old name in it.  If you’re lucky, you have tests that exercise the URLs.  If you’re lucky.

So you rename the war file, march with the new URL and alias the old URL to the new one, which adds inexplicable cruft to your web configuration.  Two years from now, the new guy will delete the alias as being nonsensical (WTF is a BottleRocket?) and of course end up breaking something that nobody knows how to debug.

And of course no product is useful without a database, and databases need names so we have a database named BottleRocket.  Hmmm, this is a tough one.  Having a DB with a legacy product name isn’t THAT bad.  But it’s not good either.  But doing a database upgrade is ugly and dangerous, so doing it just for the DB name doesn’t make sense.

Wow says the product guy, this is way more complicated than it looked.  But let’s make it really ugly.  We’ve decided to go full touchy-feely because that’s what marketing is all about and now we refer to our users not as “customers” but “guests”.   Well that’s good for our customers … er guests … but guess what?  We have a table in the DB named “customer”.  And as I said before, database upgrades are ugly and dangerous.  But table names are different than database names.  If you don’t rename that table then engineering will always call users “customers” and they’ll have every right.  At the same time, they’ll have every right to bitch you out about doing a DB upgrade to change a table name.  One of the perks of being a dev – you can look down on product guys because situations like this prove that God does not love them.

It gets worse.  There are probably references to “customer” all over the code, in field prompts, embedded in graphic assets … If you’ve been good about your strings, that refactor is probably safe (unless you’re localized), but the graphics are another problem altogether.  Somebody has to own verifying the assets.  Shitty job.  And remember Mister Product, you’re doing all this work and getting not even one little bit of added functionality.  This drives devs crazy.

I could go on, but you get the idea.  Product guys – rename shit at your own peril.   Devs – protect yourself.  If you use marketing terminology internally in the product then the minute that terminology changes you’re actually going to be worse off than if you’d adopted an abstraction to begin with.  Know going in that terminology will change and abstract stuff right from the get-go.

And if you still end up with an ugly name change, suck it up, do the refactor and march to the new terminology like a good soldier all the way to that Facebook style exit.  And be nice to the product guys.  They make less than you, have to talk to customers and as was pointed out earlier, God does not love them.

Next week: why doing what I said in this post (i.e. abstraction) is a bad idea too.

How Startups Are Like Bejeweled Diamond Mine

Last year, my friend Ernest (@ernestw) did me the honor of including me in a pitch to get his game startup, Woo Games, into the MassChallenge accelerator.  This was mighty big of him since I didn’t know shit about games.  We didn’t make it into MC** but we had fun, learned some things and moved the business forward, so it wasn’t a loss.  As part of my crash course in the games business I started playing all sorts of games and there was one game that stuck with me.

diamondmineBejeweled Diamond Mine from Popcap is a simple but beautiful iPad match-3 that, as it’s hook, includes the notion of digging.  Match a diamond that’s touching the ground and it digs down one block.  Deceptively simple.  Having played Diamond Mine for a while now it has grown on me over time that the rules for success in the game mirror a lot of things I’ve discovered about startup life.  And since no one ever hesitates to compare business to unpleasant things like war, football and politics, I hereby present the definitive list of ways in which startups are like Bejeweled Diamond Mine:

  • Speed trumps accuracy.  In other words, one “right” shot is way less productive than three “now” shots.  To get into the million point club in Diamond Mine you have to move fast and continuously. Stopping the flow to consider the merits of one move versus another or to find a better move than the one right in front of your face is nearly always fatal.  As the ladies say, it’s the difference between Mr. Right and Mr. Right Now.  Until you are literally no longer a startup, always leave any party with Mr. Right Now.  There’ll be another party tomorrow.
  • Always be digging.  There are moves that get you somewhere and moves that don’t.  Matching a diamond that touches the ground gets you somewhere, everything else is waste, or as we say in the startup world, networking.  But JR, you say, this contradicts speed vs accuracy doesn’t it?  Nope – it’s a question of priorities.  Always work your priority list and digging is the top priority so look there for Mr. Right Now first.  To join the million point club, you have to look for digging moves first and only resort to non-digging moves if you don’t find any, then return to digging asap.  ABD – always be digging.   Every startup has its digging analog, new signups, revenue, key hires ..
  • Ignore the sound and the fury.  I’ve noticed that turning on the sound, while it makes the game more fun, is almost always less productive.  This is a pre-requisite for and also paradoxically a by-product of, focus.  Professional athletes typically claim that when they are “in the zone”, crowd noise disappears.  Focus is a self-reinforcing habit.
  • Design matters.  I notice new details about the game almost every time I play it.  Some of them are fluff, but a stunning number of them actually matter.  There are different sounds and visuals for each type of match and they’re tuned to convey the importance of the move.  Non diggers get one sound, diggers get another.  When I see a product like this it makes me think hard about where you draw the line for an MVP for different products in different industries at different points in time. If you ever wonder what Product Management is about, take Bejeweled Diamond Mine and ask youself, which of all these details are MVP, which aren’t and how would you know if you were right?

**Entering MassChallenge is a great way to move your business forward whether or not you get in.  If you want to know more about it, feel free to ping me.

The Harry Project or Yet Another Modest Proposal

bouncingtherubbleThere’s a saying from a long-forgotten war, The Cold War, that goes something like

of the 30,000 nukes available to the two sides, in any war the last 29,900 of them would merely be bouncing the rubble of a dead civilization

When I hear about the competition for developers, especially the salary, that’s what comes to mind.  Now I’m speaking from an entirely Boston perspective so if you’re in SF you might as well look away now.  But it’s my sense that provably good mid-career devs are getting salary, bonus and liquid option packages in the 150 range.  That’s a broad statement, but I suspect that if I’m not spot-on it’s plus or minus 10k on either side.

Whether or not the number is right, it seems to me that 150 is bouncing the rubble.  It’s absolutely the case that all the good devs I know or have known don’t view money the way business guys or sales guys do.  A business guy knows that 150 is 10 more than 140 and thus 10 more attractive.  End of story.  For devs, compensation is a step function.  There’s enough, and not-enough.  That’s the way it’s always been for me.  I’ve taken a discount to market most of the time to work where I wanted.   Prospective employers can just pretend they didn’t hear that.

For those who learn through pictures, here’s how it looks:

MoneyHappinessBusiness MoneyHappinessDevs

Note that there is no “enough” on the business guy scale.  It’s my contention that today, in Boston, we’re well into the area between enough and lots.

I Call Bullshit

So you can get most devs for 2/3 of market if you’re doing something fun.   And all startups are fun.  So why aren’t devs flocking to found new ventures and taking a fairly safe but fun ride through startup land at a salary == enough?  Because that 2/3 of market doesn’t kick in until you have money, and the money chase rests on a big fat foundation of bullshit.  Specifically, this hoary old truism:

you don’t deserve funding until you prove that you can get a technical cofounder to work with you for nothing

Now there’s just a little bit of logic in that.  This being that a CEO has to be a good recruiter, has to have a vision and personality that makes people take risks just to join him.   But that’s where the sense in this ends.  Just as a simple for-instance, your CEO who does show up with technical cofounder in hand could have made any kind of jackass promise to this guy and you’ll never know it until the whole thing blows up in “founder issues” six months after you’ve given them money.  Or, as another simple for-instance, your CEO may recruit a guy from the pool of people willing to work for nothing – i.e. the guys who can’t get anything done.  Again, you find out six months after you’ve given him money when your V1 is just a pile of TODO comments.

CEOs with vision and charisma are thrashing around trying without any help to learn a skill that they will never use again – how to recruit and vet a technical cofounder.  Think about it, if the venture goes somewhere, they will get seed, and they’ll use that seed money to get people for 2/3 market.  In fact, they’ll start paying their tech cofounder 2/3 of market.  The skill of “getting a high-paid technical guy to leave his job and come work for you for nothing” will NEVER come into play again.
And I have the networking scars to prove this. Over the last six months I’ve talked to dozens of business founders desperately seeking technical cofounders. Many of them are serious people with good ideas that mostly don’t require new science, just solid execution of known science. But their window is closing while they spend day after day trying to convince the wrong people to leave overpaid jobs at Google to come work for nothing.
Thus, I posit the following:

The startup world is losing viable ventures simply because the founder can’t turn water into wine.

The Harry Project

harryIn The Great Escape (the real one) a tunnel code-named Harry allowed 70 POWs to escape.  Well, think of The Harry Project as a tunnel allowing devs trapped in corporate limbo to escape to startup land.  How would it work?

The Harry Project is a company that builds stuff, specifically MVPs and prototypes.  So far so good, not all that different from what some consultancies do on the side already.  Here’s the difference between Harry and everyone else:

  • Harry’s mission is to graduate projects from concept to fundable prototype or MVP
  • Harry takes a cut of the action, specifically the equity difference between what a pre-money technical cofounder gets and what a post-money technical cofounder gets.  Or it can take a mix of equity and cash, but never straight cash.
  • Harry takes projects it believes in, not the ones it can wring the most cash out of.
  • Each of Harry’s devs is expected to follow a project out the door as technical cofounder.
  • Employment is an up or out proposition.  Within two years you’ve either left as a technical cofounder, or gone back to corporate life.
  • Harry trains technical cofounders.  Its processes are relatively rigid, current best practice meant to make its devs good technical cofounders.
  • Harry’s devs all get the same salary, somewhere around 2/3 market.
  • Harry shows business founders how to work with devs and vets technical cofounders they might want to bring in from the outside.

An organization that’s part recruiter, part angel, part consultancy, part code academy that gets concepts off the ground and ready for angel or VC funding if it chooses to go that route. For devs, it’s an escape route when you’ve been to one-too-many meetings, a way to take a chance without bankrupting your family and risking homelessness. For business guys it’s a way to get to MVP and vet a technical cofounder without marrying him. For the right consortium of seed stage players it’s a no brainer. After all what’s the worst that could happen?

Update 1: Having read this over it’s clear that this was 3 blog posts in 1.  3X the bloggy goodness for  you, 3 wrist slaps for me for spending all my social networking capital in once place.