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.

Scrum Point Accounting for Unfinished Stories

Here’s one for the Scrum nerds out there.  Working with Joe Justice of Wikispeed, I cooked this post up because this is the last time I want to have to refigure this out from scratch.

beancounterThere’s a point that comes up every time I train or coach Scrum teams related to whether or not you re-estimate a story that was unfinished at the end of last sprint when you take it into the next sprint.  It drives me crazy because I personally despise hour-based project management accounting and these sorts of questions evoke bad memories of waterfall projects and PMP project managers.  I’m also really bad at math.

So let’s take a look at what happens when a story is half-finished and carried over to the next sprint by teams using different accounting methods.

conservationofpoints

The chart above shows the burndown for a hypothetical 40 point release (eight  5 point stories) by three different 10 point teams.  All three teams completed the release.  Team 1, in blue, burned down the project smoothly 10 points per sprint.  Don’t laugh, it could happen!  No accounting issue there.

Team 2 didn’t complete one of the 5 point stories in sprint 1 and got 0 points for it in that sprint.  They took it into Sprint 2 as a 5 point story, completed it along with two more 5 point stories.  They recorded 15 points of velocity for Sprint 2 and got back on the ideal burndown for the rest of the release, burning those 40 points down to 0.

Team 3 also didn’t complete one of the 5 point stories in sprint 1.  They also took that story into Sprint 2, but re-estimated it at 2 points.  They completed that incomplete story, now valued at 2 points along with two 5 point stories the same as Team 2.  But because they re-estimated the remaining work on the unfinished 5 pointer as 2 points, they recorded only 12 points of velocity where Team 2 recorded 15 for the exact same amount of work.  Essentially, the release lost 3 points of work.

Shrinkage

The method team 3 used, and the one I’ve advocated up until recently, I call Shrinkage.  That’s because the amount of points recorded to complete the release goes from 40 to 37 when the unfinished 5 point story gets re-estimated.  3 points simply disappear from the release.  I like it for some very tactical, team psychology, Scrum Master oriented reasons:

  • It forces us to be honest about the work
  • It helps teams avoid the trap of simply taking the product backlog estimate of a story into the sprint backlog
  • It reinforces the notion that incomplete work is waste
  • It exercises the team’s relative sizing muscle

Conservation of Points

The method of team 2, where they didn’t re-estimate the remaining work but simply took the story into the next sprint at the original estimate I call Conservation of Points.  The three points of work on the unfinished story in Sprint 1 are carried over into Sprint 2 and accounted as Sprint 2 velocity even though the work was done in Sprint 1.  No points disappear from the release.

Recommendation

I recommend using Conservation of Points now for one, and only one reason.  In a Shrinkage model, in order for the release burndown to continue to fulfill its purpose, the product owner needs to account for the lost points.  The PO needs to shift the whole curve down, so that instead of starting at 40 points for the release, it starts instead at 37.  Some automated tools may support this, but in a manual situation or where you’re tracking in Excel this can be a real pain in the neck and stuff that’s a pain in the neck ends up not getting done.

UPDATE: As commenter Nigel Thurlow points out, if you use Conservation of Points you must use a rolling average for velocity in Sprint Planning.  Using the single data point of “last sprint’s velocity” as your sprint planning velocity (rather than a rolling average) will leave you chasing bad data up and down the burndown chart, essentially amplifying the negative effects of unfinished stories.

Acknowledgements

Many thanks to Joe Justice of Wikispeed and my friends at GE Power and Water in Mumbai who inspired me to finally write this down.

 

 

 

 

 

 

 

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.

Rubber Stamp Rambo

So this guy comes into my office and says:

I need to take Monday and Tuesday of next week off.  Is that okay?

Of course it’s not okay.  Monday is a crucial day in the life of Startup Incorporated.  Never mind that it will be the 375th consecutive such crucial day.  Absolutely critical I tells ya.  Critical!

In my ventures over the last ten plus years, my CEOs gave me a hard time about every single vacation day I ever took.  Every. Single. One.  Three days, seven days, one day, half day – didn’t matter.  So in the spirit of being a real manager I tried, I really tried to think intelligently about whether in fact Monday was a good day for this guy to take off.  Once.  And my brain hurt so I stopped.  There is no answer to that question.

When someone comes to you with a vacation request, break out the rubber stamp, Rambo, and get stamping.  There is never a good moment for this guy to go on vacation so smile, rubber stamp it and wish him good luck at the D&D convention.

Where do you see yourself going at Startup Inc.?

One of the funniest moments of my education as a founder was the time one of our devs, a valuable guy, came into my office and said with a completely straight face:

I’ve been here a year and a half now and haven’t gotten a review yet.

And of course, as I’m sitting there, a handful of inappropriate responses flit through my brain.

I’ve been here three years and neither have I, welcome to the club.

You’re great. Get back to work.

You suck. Get back to work.

Hahahahahahahahahahahahahahaha.

Fortunately, what I actually said was

Uuuuuuhhhhhhhhhhhhhh – okay we’ll do one.

Think Butthead on a bad day. Then I went off and tried to figure out what I was gonna say to this guy because up to that exact moment I had never realized that I’d have to have these kinds of conversations with people.

In companies with an actual HR department, full of actual HR professionals who set actual policies based on actual HR science (is there such a thing?) what they tell you to do in reviews is ask people “where do you see yourself going at XYZ Co.?”

This question looks perfectly reasonable until the first time you ask it at a startup.

Mr. Founder: “So where do you see yourself going at Startup Inc?”
Mr. Employee: “Well, I could have your job.”

This is usually followed by an awkward silence where both of you regret coming to work that day.

Truth is, in the way of a bigger title, more responsibility, authority and salary, there is usually no place to go at a startup. If you’re doing it right, you’ve maxed people out along all those lines.  You can be a founder, or one of the guys.  So the only way to have the review conversation is to start by admitting that, even in the short term, people may have to leave the company to realize their personal goals.

Loyalty at a startup is a complicated thing.   Your guys bleed for you and all you can give them in return is options, flex-time and a foosball table. In the end most of these guys will be working somewhere else.  And that’s okay.  That reality doesn’t relieve you of your responsibility to help your guys get where they want to go.

So what do you do? You take a mortal risk (probably the third one of the week) and try honesty:

Hey, your best future might not be here but I’ll help you get there anyway.

This is something you can give people that managers at a big company can’t.  So do it.  Loyalty’s a two-way street, so take a ride down your side and see where it gets you.