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.

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.

It’s the little things …

… that make the difference between good/fun and not-so-good/not-so-fun.

Terminology for example. (Oy, here he goes again on the name thing!) There are a fair number of things that have to be named when you’re trying to make something from nothing.  The company, the product, individual projects, components, workflow states and transitions, interfaces, even the term you use to describe customers (guest, client …).  They all have to be named.  And as close readers of this blog know (Hi Mom!) the first name you pick for something usually sucks.  Which means that not only does everything have to be named, it usually also has to be renamed.

When product (and seriously it’s always those guys leading the renaming charge) decides to rename something it takes a while for the terminology to work its way through the org, whether your company is 4 people or 400.  For some things, in some organizations, you never really flush out the old name.  The dual names then become a form of low-level, everyday friction.  C’est la guerre, right?  Well, no, it’s not.

I was forced to think about this by a stark counter-example.  I was sitting in a meeting one day, not paying much attention when I realized that we’d been talking for awhile and all three people from one particular group had nailed the just-changed-yesterday name for the product in question every single time.  The rest of us were all over the map.  It stuck in my head as a data point that probably meant something.

bossPersonally, I was always bad at this and tended to hang on to the old names.  I’m not very good at remembering people’s names so why should it be any different for things?  But when I thought about it, I realized that I didn’t hang on to old names for things because I couldn’t remember the new ones, at least not most of the time.  It was because I thought that renaming things was stupid and I was annoyed and often had “the juice” politically to get away with hanging on to the old name.  Passive aggression at its finest.

Very occasionally I see product people get annoyed by this phenomenon, but I’ve never seen anyone take it seriously.  From the product side of the house I suspect that this inability to make a name-change and have it stick quickly is a low-level irritant that decreases their effectiveness and quality of life, but never rises to the level of “I have to do something about this”.  It’s one of those things that leaves you pissed off but you’re not really sure why.  Well now you know why – you’ve been passively aggressed.

When you’re building a team and trying to get some momentum this is one of the little things you can watch, and use to prevent problems you’d otherwise have to ‘fix’ later, probably by firing someone’s sorry ass.  Somebody who consistently uses old terminology is actually arguing with your right to name things.  He’s saying “you’re not the boss of me”.  Fix him now, or fire him later.

For my part, hereby resolved – the next time I’m leading a crew, this is one of the things I’ll be paying attention to, for myself and for the crew.  Perhaps I’ll make a point of explaining it up-front. Or now that I recognize the root of the issue maybe I’ll just jump on anyone who’s not with the program.  Fair warning.  And to all the product people in my past – my bad.

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.