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.
