More on CTOs or was that Moron CTOs?

5 comments

Posted on 10th January 2008 by jeff in Startups

, ,

Thanks to all who commented on my CTO Handbook. Well except for the one from that that Jason guy :-p this post’s title is for you bud.

First to answer the obvious question I’ve been getting “what type are you?” Well, I started out as #1 (technical founder) in two separate startups and transitioned to #2 “Visionary” as I backfilled my team in my last personal startup. Note I define “personal startup” as one where you personally made payroll! I’ve never been chuted-in but I have CTO friends who have had the “pleasure”. My style is probably 70% Visionary and 30% Technical. That doesn’t make me any less of an ass at times but more likely an ass at different times.

Now, there must be something “CTO” in the water; Fred Wilson posted “What to say to a room full of CTOs“. I like a lot of it and I agree that in a small company (< 30 people), the most effective CTOs are ones that can manage dev and drive the technical vision. Several paragraphs jumped out at me because they resonated with me and because they brought back some painful lessons learned.

First this gem:

First and foremost, I see the CTO as a manager. Great managers are hard to find in any line of work. But managing developers is even harder. The better the developer the harder they are to manage. I assume its a bit like managing high maintenance entertainers. The best developers are artists who are often moody, are anarchists who have bursts of creativity and equally long periods of uselessness. They are strong willed people who will fight with their colleagues over anything and everything. The people who have mastered the art of managing these kinds of people are a rare breed and every great technology-based business needs one of them.

Amen brother! But you have to admit, managing developers is never a dull moment. Recently the guys I’m helping out with driving some education on Agile methods here in Waterloo managed to land Scott Ambler. Scott was an awesome presenter and I was in tears from laughter due to his presentation more then once. Note to data management people: if you’ve been booked into a meeting with Scott, I’d find a reason to bail. I’m telling you this as a friend. Non-data management people, you might want to bring some popcorn and a comfy chair to the meeting. Ok I digress again, the reason I bring up Scott is that he had a great point about managing and incenting devs. To illustrate, he used the old herding cats analogy.

Herding cats is tough, if not impossible – if you don’t understand cats. You can send terse memos to your disobedient and non-complying felines but it won’t help a bit. But toss even the tiniest piece of fish in the direction you want your herd of cats to go and you’ll be pleasantly surprised. I think that’s the main reason why the Technical Founder CTO is most effective in early stage companies. They’re pretty much still a cat and they instinctively toss fish around to get the job done. Plus they’ve got the technical chops to be the alpha cat.

Hiring a Player/Manager:

I have found that for young companies a “player/manager” often works best. If you can find someone who is or has been a world class developer who also has the ability and more importantly desire to manage a team of at least ten developers, do it. That person, by virtue of their engineering talent and prowess, will be able to manage a small group effectively. And they can contribute to the development too which at crunch time is incredibly valuable.

Another total truth. I will never, ever, ever hire a development manager who cannot or will not code. Period. At least not at an early stage for precisely the reasons Fred cites above. My best VP Dev experience ever was a guy just like this, though he had prior experience with his own team — Tom Gross kicks ass.
And now the pain…

As companies get bigger, you really need a full time manager. The best ones, like all things in startups, have done it several times before in high growth startups. As Albert said in his post, it’s not usually a great idea to hire a CTO from a super big company for a young growth company. Companies growing from 10 engineers to 50 engineers to 100 engineers over a 2-3 year period are a unique situation and you really need someone who has lived that situation a few times. Again, it’s incredibly hard to find a person like that.

Hells yes. I lived through rapid growth and totally screwed it up. My “cats” were fighting. Code was not happening and we were completely consumed by it. Eventually you figure out what works and what doesn’t . You start to see patterns in your developer types and you figure out what “fish” works and what “fish” stinks.

Hmmmn note to self: “Developer Handbook” is the new black and the next blog post.

CTO Handbook — How to care for and feed your CTO

20 comments

Posted on 8th January 2008 by jeff in Startups

What would you say you do around here?I changed the title of this article about 50 times. Some losing candidates:

  • CTOs driving your VPs crazy for fun and profit – true but fenced me in too much
  • CTO:”You got vision in my technology”- with apologies to the good folks at Reese’s. A bit esoteric and again not enough latitude.
  • CTO: “What would you say you do around here?” — with apologies to Mike Judge (please don’t sue me!). This was a tough call but I’ll learn to love again…

In both my personal and professional life I get a lot of questions around what a CTO is exactly. Everyone knows what a CEO does (mostly). COOs execute on vision through operations. CMOs do, ah something, yeah I’m sure they do something… with uh (capital ‘M’) Marketing. That means not the t-shirts or ball caps. [Easy Biff, I'm only joking] CFOs have it easy with the lack of ambiguity in that whole finance thing. Sadly it isn’t so cut and dry for CTOs. Probably because we’ve been our worst enemies. We like having fingers in *every* pie and are slow to give up those pies. Mmmm pie.

I threw this post together to try to explain what it is CTOs do, why we do it and how you need to manage a CTO up and down. Obviously this is only my personal views from being a CTO and from commiserating and hanging out with other ones, your mileage will definitely vary.

“Typing” Your CTO

You need to know what breed of CTO you’re caring for. Each of the following has different characteristics, preferences and personality traits. Although there are other “species” out in the wild, in North American software you’ll likely have one of the following beasts:

* The Technical Founder – the person that wrote the code that got the company off the ground. Has sweated to give the alpha/beta/product life and as a result any criticisms are effectively received/interpreted as “Your baby is ugly! Now where’s your Corn Flakes so I can piss in them too!” Is never far from code.
* The Visionary – sometimes seen as the flake without any “real” deliverables. Is never far from a whiteboard. Can write code but shouldn’t.
* The Figure Head – parachuted in, probably did or was associated with something impressive in a semi-related industry. Doesn’t know most of the company but is on a first name basis with most flight crew. Is never far from PowerPoint.

All of the above are neither nocturnal nor diurnal but more typically work almost all the time. A CTO tends to segment their day into multiple sessions — this is because they’re overly concerned about “flow”. This peculiar trait is challenging for the CTO both in terms of their expectations of other’s availability and similarly their responsiveness. Also unlike developers, CTOs are typically very social animals but their odd self-imposed schedules prevent ‘normal’ socialization outside of technical circles. Ironically this social trait does not translate to excellent management skills which most CTOs lack.

Related Species

VP Dev/R&D/Engineering – often confused with CTOs, VP Devs are a different breed entirely. You can typically distinguish a VP Dev from CTO from the CTOs ability to match markets with problems with game changing technology coupled with their capacity to speak coherently about deeply technical things at a level that business people can understand all the while retaining credibility with the technical folk in the room.

VP Devs on the other hand can be determined by their freakish level of attention to detail and love of process (again freakish). They worry, a lot, about executing on the nutty crap their CTO (particularly “The Visionary”) just cooked up and possibly presented to a large audience and you’ve got to love them for it. As a result the VP Dev is crankier then even the crankiest of CTOs. That’s because Veeps keep it real, they shelter developers from the CTO and other C-types and in really productive cases they’re a great reality check for the CTO. Sometimes CTOs unnaturally camouflage themselves as a VP Dev until they are unconvincing in either role.

CEO – strangely the CTO and CEO are allies though cross-breeding is rare. Often they travel together on migratory patterns to key customers and events and plot “vision-y” things on cocktail napkins. This drives the organization crazy but is a really, really good thing.

Daily Habits

The Technical Founder CTO largely lives their day the same way as they did when they bootstrapped the company. Although both the coffee and the food has gotten better, the Technical Founder spends less time in code which can lead to a general crankiness. Prolonged exposure to a 3 monitor setup and some uninterrupted flow makes everything good for everyone.

The Visionary has 2-4 good whiteboard sessions per day all focussed on market dominance and shaking up the status quo. They then proceed to confuse everyone in the company with ad hoc discussion of their germinating ideas. They stare off to space during other conversations as they process even more tangential ideas. Visionaries get cranky where their days get stale or repetitive and need frequent trips to customers, standards body sessions or opportunities to speak at large venue conferences.

The Figurehead is constantly on the “circuit”. They attend 2-4 conferences and events per month. They’re excellent golfers and they spend *a lot* of time with customers and analysts. As a result have little time for anything else. They direct the development of ghost written whitepapers and blog postings and they appear in multiple, preferably pre-recorded webcasts. The Figurehead can get a meeting with anyone — no seriously they can. The Figurehead is happiest when left to run in the wild and then and only then will the company will reap the rewards.

CTO Language

With possibly the rare exception of the CTO Technical Founder, CTOs in general think, act and speak in the big picture. Although typically they’ve plotted things out at a fairly fine grained level, they consciously generalize details. They have to do this to serve the various audiences that CTOs interact with on a daily basis. Although it may appear that they’re glossing over details, they really aren’t they just haven’t needed or more likely had the opportunity to disaggregate at a finely grained level yet. Still I haven’t met a CTO yet who hasn’t felt their latest brainchild wasn’t entirely possible but not without risk. You should know that CTOs do worry about risk but they also find risk thrilling and will naturally be drawn towards alpha and beta software (nightly builds preferred) like a moths to flame.

CTO Time

Because of the CTO’s “big picture” context, their notion of time isn’t the same as most of the organization that puts up with them. When a CTO says “Take a look at technology/concept X” it’s honestly not an immediate thing. Rather it is a topic they’re currently noodling and they want your thoughts on the subject and are testing the validity of the ideas. Remain calm and know that this is why you have a VP Dev and Product Management to shield you from the tear in the CTOs time-space continuum that makes them temporally ambiguous.

Final Guidance

In summary, a CTO is the source of big picture technical and product strategy in an organization. This is often expressed during whiteboard deathmatches or through prototypes that they quietly whip up and surprise the company with. In short, they drive innovation often while frustrating the rest of the organization. CTOs are typically the external technical voice of the company and crave inspirational contact with the external world. They thrive on variety and find solace in chaos.

CTOs should not be mistaken for CIOs — a self-respecting CTO would never worry about rolling Exchange out. [Ok again, I kid.] Similarly they’re not VP Devs who actually do something tangible in an organization. Lastly CTOs are not product management though they typically do drive product strategy.

UX Challenges or I Forgot How Much I Liked David Lynch

0 comments

Posted on 5th January 2008 by jeff in Product Strategy

,

Ah yes forgot that artistes don’t appreciate small format screen experience. “I work on the big screen dammit…”

First reaction… OMG David Lynch has gotten old. Second reaction… spit take. I’m shocked he didn’t mention 1080p, oh wait that’s me.

Looking Back and Forward

0 comments

Posted on 2nd January 2008 by jeff in Uncategorized

, ,

Despite what the title might indicate, hopefully this post isn’t a product of having my head up my ass. Rather it is the obligatory year in review and prognostication of the year ahead post. Hmmmn maybe I do I have my head up my ass.

2007 was a strange year for me:

  • left one startup, now consultant/insultant to another startup
  • moved houses twice — wouldn’t recommend a move before Christmas, particularly if you have kids. New construction is a cruel mistress.
  • formally left XBRL standard development — deeply miss it and the people
  • started blogging again after a year break — meh
  • twitter, twitter and more twitter
  • switched back to OS X
  • left .NET development just as C# was getting really interesting
  • starting playing with Ruby and Rails
  • attended my first bar, demo and startup camps
  • blew through a ton of whiteboard markers
  • slowly became a freetard
  • met some good people
  • got in-touch with my inner Crankenstein :-)

So my simple plans for 2008:

  • unpack — so many books, so many boxes.
  • strike a better balance between whiteboard and code (i.e. write more code) — mildly-obsessive about RSS as the transportable web right now.
  • hang with the fam
  • rekindle love for design — being back on a Mac helps as did building a new house. Not getting a black turtleneck (yet).
  • help out with Jeff & Declan’s Agile efforts more not that carrying around a mic at the Ambler event wasn’t fun
  • be skillful and delicious (vs willful and malicious) — my kids watched Santa Clause 3 way too many times but that line always made us laugh.
  • sail smaller boats!

There it’s done.