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.


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.


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.


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.


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.



First Impressions Matter

I started a company once with some awesome people who had lots of virtues.  But … at one point early on, one of them introduced me to an outsider as “the developer”.  Those of you who know me from the real world (hi Ed!), can imagine how I reacted to that.  Why is an introduction like that a problem?  After all, I was the developer. It’s a problem because for that particular outsider, I am now, and forever “the developer”.  Not CTO … “developer”.  I won’t get that intro back.  It made me feel bad.

despicable-me-2-gru-minions-pp33118_zpsdcda23f2My feelings, of course, don’t matter much because a lot more than my feelings were going to be hurt by the time that ride was over. There’s nothing anyone could do about that.  And you can’t be super-sensitive in this business blah, blah, blah.  But there are good reasons for even a heartless CEO who disdains, even hates his subordinates to be careful about intros – good self-serving reasons.

I worked for a guy once who consistently put his people down when introducing them to outsiders.  His Director of Engineering became “the software guy”, his Project Manager became “my assistant”, his CFO became “the accountant”.  He did it, I’m certain, because he was deeply insecure about his own chops and didn’t trust us not to show him up with outsiders.  So in any meeting, right from the intros, he was “The CEO” and the rest of us were minions.

I remember watching people’s faces as he did this, and I could see their loyalty to this guy draining away.  It was sad.  Nobody wanted to travel with him.  In meetings we all sat there quietly, having been appropriately down-titled during the introductions.   We felt bad, but those are just feelings which don’t count, right?  They did count because when hard times hit, they hit us hard, and it all came back to him.  He’d throw something out in a meeting and be met by dead silence.  He’d look around the room and say “doesn’t anybody have anything?”.  And nobody did.  After all, we were just minions.

rumbleOn the flip side, I worked for another guy who consistently oversold his team, myself included.  When he introduced me to outsiders I was not just whatever title I had at the time, I was also a genius, rockstar, ninja – any of the ridiculous things Silicon Valley CEOs call their tech guys.  I actually asked him at one point to tone it down – I’m nobody’s idea of a rock star and it was a little unnerving.  But he was more right than wrong in doing that.

The basketball analogy I used back here works well for this.  The overselling CEO was actually “making space for himself”.   He could say objectively-stupid shit and get away with it because he had peers who could laugh and correct him.  By working introductions the way he did, he put the rest of his team in the game.  Any one of us could jump in if he got in trouble.  And because he was surrounded with ninjas and rock-stars he got called on stupid shit much less than he would have otherwise.  After all, if I were actually a ninja I might jump in and kick your ass if you put my CEO in a bad spot.  I could see people thinking about that when Mr. Uptitler went off the rails in a meeting.

That didn’t sound right. Should I jump on it? Or do his guys know more than I do and they’re just sitting there waiting for me to stick my neck out … Meh, it’s not that important, I’ll let it run and see where this all leads.

Imagine this scenario. You’re meeting with a VC and you’ve introduced your CFO as “the accountant”. You’ve started the meeting by insulting her, or worse, refighting a battle you already lost about her title.  Is she going to be willing to jump into the conversation and help you past a rough spot?  Will anyone even listen if she does? Or will she be dismissed out of hand?  And this is not even addressing the question of why you would bring an “accountant”, “developer” or “assistant” to an important meeting.  When Mr. Uptitler said something stupid, we fixed it and moved on.  All it meant was that he’d misspoke.  When Mr. Downtitler said something stupid, it meant the company was stupid because no one on his side had the juice to fix it.  “Accountants”, “assistants” and “developers” don’t correct the CEO in a meeting. They don’t even speak.

Next post, we’ll tackle the sensitive topic of startup titles from the CEO’s perspective, and everyone else’s.

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.


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.

Google Glass, Taken Seriously (with predictions!)

In my last post I gave a mostly factual, but seriously facetious account of my 10 weeks with Google Glass.  Lest  you think me totally unserious, it seemed wise to post a followup that informs as well as amuses.

Mirror API

Mirror API, just for background, is a server-side API for injecting HTML-ish cards into the UI of a user’s Glass.  That’s it.  You write a web application, deploy it to Google’s AppEngine, and that web application calls Google’s Mirror API to put cards of your design into the timeline.  A Mirror app does NOT run on the Glass as far as you, the developer, are concerned.

The Mirror API is limited, seriously limited. Having thought really hard about it for lo these 10 weeks I have gradually come to understand the thinking behind it but that doesn’t mean I agree. There are uses for it.  Consider, for example, test results in the medical field.  You’re a clinician running around as they all do, but as a test result comes in, it pops onto a card in your timeline, you can click down into it to acknowledge receipt or flag for followup.  As a user experience I think that case makes sense.

The only problem with the Mirror API and the timeline metaphor is that right now it’s an all-or-nothing proposition.  You can’t do anything (official) on Glass that’s not Mirror.  I can see a rework of the timeline such that it’s cooperative with other apps, a timeline View that you can incorporate in your app.  Even a required timeline View that, as an app developer, you have no control over would probably work.  But as a walled garden Mirror doesn’t work.

The Future of Glass

220px-CarnacSo Mirror API is a dead issue.  Google has to figure out how to enable useful apps without throwing away its emotional investment in Mirror. There are strong indications that they already have figured it out and are just rolling it out VERY SLOWLY.

With that as background, let’s put a stake in the ground and make some predictions so that you, my fans, will know exactly what is not going to happen:

  • September update that includes a “hole in the timeline” that allows side-loaded native apps to be invoked and run without jumping through hoops.  Could be as simple as making native apps voice-invokable via the Ok Glass menu.  This update will still require side-loading to get native apps on there.
  • November 15 limited-access trial of a Glass app store
  • February 15, 2014 GA date for the device and app store
  • Only available online through Google
  • Retail price of $299 (h/t to @wareflo who reminded me I forgot to predict price)
  • App store submission includes actual Glass-certification process a la the iTunes app store “black hole of approval”. Much closer scrutiny of apps adherence to usability guidelines and astronomical initial rejection rate.
  • Number of apps in the Glass app store on opening: 5,000

Well, I’ve stuck my neck out.  What are YOUR predictions for the future of Glass?

One Glasshole’s Timeline

I am a Glasshole. There, I’ve said it. If you come here for nothing more than to know what I’m doing, leave now. (Bye Mom!) If you also come to keep up with the latest cultural trends, read on:

Noun glasshole

  1. insensitive, privacy invading, distracted driving, techno-knucklehead who’d drive off a cliff if Sergei or Larry told him it was a good idea.
  2. someone who got Google Glass before I did.

Alright, the rest of you can go home now so I can talk to myself, as usual.

I’ve had Glass for 10 weeks, so in the spirit of proving my superiority (really isn’t that the point of all blogs?) I deign to share a little of what it’s like to be so cool.  “Timeline”, as all you #glasswaiters know is the foundation of Glass’ much-maligned mirror API so I’ve sketched out a rough timeline of my own Glass-Self-Discovery adventure. On every milestone (timeline card) is a picture, a short description of what happened that week, and the Selfies-Count – i.e. the number of people who borrowed the Glass, usually to take a picture of themselves wearing Glass that they can tweet to the world.

Day 1:
 benmustache Hungout with my friend Ben, who also got Glass.  Ben doesn’t really have a handlebar mustache.  Discovered that “doing hangouts” on Glass is Stupid because when you’re talking to someone they want to see you, not the crappe you’re looking at, duh. Spent the rest of the day hanging out with myself trying not to feel stupid. Went to bed convinced I was the coolest kid in America.
Selfies-count: 5, including my 80 year old parents. Dad was surprisingly handy with the touchpad. My children did not tweet out their selfies.
Week 2:
PatientBefore (1) In the second week, my team of crack coders, (including Griffin playing the part of a patient at left), took Glass to AngelHack Boston and built a prototype hospital rapid response team management system called aRRTGlass. We committed several major crimes against computer science, watched the Bruins on the big screen in a Microsoft conference room and violated the unwritten rule against letting me name things. We were the only Glass play at the hack, and by a wide margin the best hack and coolest demo.
Selfies-count: 53 with a tweet-rate of ~73%. The force is strong among the angelhackers.
Week 3:
johnrodley-thumb-300x340-104878 Sulked about not winning AngelHack with our cool Glass thing. Got a nice writeup in the Boston Globe by Scott Kirsner who took, and published, the worst picture of me ever taken.  Considered suicide when I discovered that you can’t do Glass without participating in Google Plus.
Selfies-count: holding steady at 53
Week 4:
 money Returned to work re-energized and waited for @richminer to call and offer us 8 figures to sit on our asses being cool. He must have been on vacation that week.  Fell immediately back into depression as I worked on streaming video off Glass and discovered what everybody else already knows about streaming off Android – it’s torture. Fell further into depression after realizing that the Cost of Sales in healthcare is 1 billion times the Cost of Sales in any other industry except defense or local government.
Selfies-count: 71 including one free 5$ coffee and one free 6$ beer
Week 5:
 moneyno Waited for Glass Collective to call and offer us 7 figures to develop Solitaire for Glass. Made several concerted efforts to “connect” with Google developer advocates for help with Glass development issues. Was told, “Glass developer advocates have very specific goals” right now. Apparently, helping developers write for Glass is not one of those goals.  Discovered that everybody else who knows anything about healthcare is totally depressed about the possibility of fixing it.  Strangely, this made me feel better.
Selfies-count: 77 – fair warning, if you’re a fast-food cashier and you want a selfie, I now expect a freebie in return.  Seriously, don’t even ask.
Week 6:
20130710_182635_393 Hosted the Exploring Glass meetup to explain to the unwashed masses what Glass is all about. This forced me to pause the money-wait long enough to figure out what consumer Glass is all about. This involved loading every Glassware available onto my device and using them. This took about 15 minutes. Ominously, the first card that the CNN Glassware showed me was a video clip about a dog that can ride a scooter.  Sometimes the jokes write themselves.
Selfies-count: 117, a free burrito, and the business cards of 7 hot women. #winning
Week 7:
 hanglass Started wearing Glass in public. Wore it around my work neighborhood in Cambridge (@workbar) and found out what it’s like to be a rockstar. Wore it around my Republican suburb and, paradoxically, got as close as I will ever get to knowing what it’s like to be black. A Learning Experience. Thought I’d sworn off those. Got another nice writeup in the Boston Globe from Cal Borchers who took the one unfortunately colorful thing I said in our two hours together and used it as the punchline of the story. Really Sergei, I don’t think that wearing Google Glass is comparable to running around pointing a gun at people.
Selfies-count: 131, wondering if I should subtract dagger-stares from the selfies-count. Review of the video from Cal’s visit indicate a high sneaky-dagger-stare quotient.
Week 8:
 Fred1 Changed all my social media profile pictures to some picture of me wearing Glass. The transformation is complete. Google starts making noise about a GDK. People who haven’t been paying attention swoon as if you can’t develop Glass apps without one. Those of us developing Glass apps without a GDK grind our teeth and remind ourselves that this keeps the field clear of knuckleheads for another few weeks.
Selfies-count: 152, decided to ignore the dagger-stares. Can’t distinguish the Glass-related ones from the unattractive-middle-aged-man ones.
Week 9:
20130715_110550_277 Got hit by a car while wearing Glass. First car accident in 25 years. I had been stopped for a good minute in the middle lane of the Southeast Expressway at rush hour when the urban assault vehicle behind me gave me a serious love tap. Thought that only happened to other people. Hmmph, another Learning Experience. I thanked The Deity that he didn’t just do the monster-truck-crawl right over my little plastic Element. The Glass was turned off. Wish I’d been recording, though it only would have shown the car jumping forward 5 feet.
Selfies-count: 157 – the mojo appears to be wearing off, though the force remains strong inside Chipotle as I score another free burrito.
Week 10:
 comingsoon Took a pile of existing Android code and developed something useful for Glass. Stay tuned.
Selfies-count: 164 – selfies count seems related to how much I stay at my desk developing code, and how much I go out and show off the Glass. Worth investigating.

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.

Your beautiful idea means nothing to me

This one is for all the non-technical co-founders out there and their beautiful ideas.  I won’t sign your NDA.

I’m a technical cofounder looking for a gig.  This is no secret.  I hang out on cofounderslab (Hi Shahab!) and FounderDating and talk to lots of non-technical cofounders.  Great people, I haven’t met one I didn’t like yet. However, a small but energetic minority of these guys insist that I sign an NDA before we talk.  I refuse, but I try to do it nicely. Here’s what I say.

ios-nda1My perspective on NDAs is a lot like Brad Felds.  I talk to a lot of people about a lot of things and literally can’t have an ever-growing paper tail of NDAs (i.e. contractual obligations) dragging behind me for the rest of my life, pretending to restrict what I can and can’t say to people.  Back in 2009 I signed an NDA when I was talking to a web analytics company about a job.  Literally the next five guys I talked to were doing web analytics.  If I took the NDA seriously I couldn’t have had coffee with those guys.  I realized that stupid NDA was working like a non-compete.  I had traded my ability to speak openly about web analytics for a 10% chance of working for this one company.  I’d given something valuable and gotten nothing in return.  It’s the last one I ever signed or ever will, at least in that situation.

If we’ve gotten to the point where you want my JR on an NDA we can do one of two things: skip the NDA and go our separate ways, or have a discussion where the special sauce (i.e. the how) is elided.  I’ve done that with a handful of guys – have the discussion but be really oblique about the special sauce.  The problem for them is that they’re trying to recruit me, but they can’t prove how smart they are, or how wonderful the opportunity is.  And I can’t prove how smart I am because we’re talking around the actual thing.  I wind up underwhelmed and they wind up feeling like they haven’t solved the NDA problem.

unicornNot long ago I was trying to recruit a data scientist and wonder of wonders I found one.  An honest to God, freshly minted PhD in Stats.   He’s standing just out of the picture to the right of the unicorn.  I cropped him out so you won’t steal him.  Anyways … how many shots at a good data scientist am I going to get?  If I scare this one away by demanding an NDA will I see another any time soon?  No.  I need him more than he needs me.  Once I get going and people are coming to me for jobs?  Shoe’s on the other foot brother and you’re signing a reception desk NDA or my hot receptionist is calling security.  Bet on it.  But at that point in time, Mr. Data held all the cards,we both knew it and there was no point arguing about it.

But by far the best reason not to NDA or to play the guessing game with guys like Mr. Data is one that none of you business guys are willing to hear, so close your ears now.  Get over yourself, your idea’s not that great.  There’s zero chance Mr. Data is going to steal it.  That doesn’t mean it won’t make money, just that the money will come from you and Mr. Data working your butts off, not from the inherent beauty of the idea itself.

Bottom line? Be careful about what you say and who you say it to, but you have to take risks.  Do what you have to, use the idea as leverage when you need it, use your other leverage to protect the idea when you can.  Just be firm and consistent in discussions with any one person and don’t throw it open for discussion.  If you’ve decided not to expose special sauce in this discussion with this guy, then don’t do it, and don’t get into a big discussion about why you should or shouldn’t because he won’t be convinced and you’ll look like a dope.  If you change your mind in the middle, schedule a followup.  Waffling makes you look like an amateur.

Take a look at VC blogs like fred wilson brad feld ben horowitz marc andreesenmark suster.  They all say that ideas are like armpits, everyone has two and most of them stink.  Sometimes they’ll analogize a different, singular part of the anatomy.  They also say that they bet on teams, not ideas.  Maybe that’s just self-interested VC bullshit.  Or maybe it’s a fact that most founders overvalue their ideas, overrate their ability to “move the ball” alone and underestimate how much time and effort it takes to execute on an idea.  And guess what?  You are like most founders.  Personally, I’ve stopped thinking I’m a smart guy (no it wasn’t a stretch). If I’m not a smart guy, then any idea I’ve had, someone else has already had it.  If they’ve had it and haven’t made a business of it – it’s either a bad idea or they screwed it up and left an opportunity.

So tell me your idea and let’s see if there’s a deal to be made.  Or not.  That’s cool too.  Just leave the NDA out of it.