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.

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.

The J Word

I have two young children.  Every now and then, one of them will say something like:

Daddy, I just want one more minute of TV time!

And the other one will chime in, more than a bit maliciously:

Daddy, she said the J word!

When they started in on that just crappe I was ready for them because I was a startup guy and I’d been dealing with startup CEOs for years.  In fact, long before either of my kids were born, I used to have a sign in my office that looked like this:


There is no just anything.  Everything takes work.  I didn’t just whip out this post.  I sat down, fired up wordpress reached back into my experience and told the best story I could.  Sure it’s just 500 words, but it took work and I’m proud of the result.  If it were just anything, just anyone would have written it, but they didn’t, I did.

The origin of the J-word ban was months of bad CEO behavior on the order of:

  • Just add a screen that takes the address and verifies it against the USPS database.  Oh, and it needs to present the user with the choice of using the corrected address or the original.  And it has to popup a dialog if they choose the original and the ship-to address is Illinois.  And there’s some other rules too – call this guy (that I met yesterday at a trade show) – he knows all the rules.  I want to show it at the VC thing this afternoon.
  • Just hack up the xyz product – no I don’t want a demo, just hack it into the product.  We can sell this if I can show it to them tonight.
  • I just want a shippable prototype that cures cancer, violates the laws of physics and can be shown at CTIA on Thursday.

I would sit there glumly under the no-just sign waiting for the lights to go on in CEO-land.  They never did.

But just abuse isn’t limited to the business types.  My favorite example of J-word abuse was when one of my teams sat down to do sprint planning for the first time.  We’d been running cowboy forever and finally got sick of the feature misses (where were you when I needed you Customer Development?) and schedule overruns, so we started with scrum and at our first ever planning poker, one of our guys can’t contain himself.

Story 1 – 8s and 13s around the table, except for The Lone Ranger.

That’s just a stored proc!

Story 2 – more 5s and 8s, except for The Lone Ranger.

That’s just a web page!

Story 3 – The Lone Ranger realizes he has better things to do than learn how to make software in an organized fashion and disappears from sprint planning never to return.

I used to think that this was just the way technical groups worked, that minimizing perceived effort was a necessary fiction people told themselves and each other because … whatever.  Then I worked with a group where the J-word was non-existent.  Every item of work stood out in plain view, clear and unshrouded by value judgments like just.  Every interaction felt crisp and professional.  It was refreshing, a cool drink of water.  Talking to these guys made me feel smarter.  It actually did make me smarter.

Just is glib, sloppy thinking.  There is no just anything, so stop saying it.