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.

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.

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.