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.
Jeff Fedor’s CTO Handbook | About Mobility - The Mobility Weblog says:
[...] More on CTOs or was that Moron CTOs? (follow-up article/post by Jeff) [...]
10th January 2008 at 9:24 am
Jim Murphy says:
I’m intrigued by the possibility of a CTO that could manage. Never seen it. I’ve only ever worked with CTOs that were the alpha geek and head visionary.
In 3 startups I’ve worked with CTO’s that were the chief technical founder never a manager type in the slightest – in all cases absolutely zero managerial skills. These small startup teams were highly technical, tight, flat and (usually) mature enough to not need a lot of management so, maybe the CTO was the defacto manager but it didn’t feel that way at the time. As stated/predicted we *always* bitched a lot and seemed pretty disfunctional on a personality basis but in retrospect usually got things done.
The CTO was often the one doing the external stuff: doing the analyst briefings, giving press interviews, conference speaking and other very external jobs. He provided guidance internally but it was more a team effort to construct the vision and the details. Our CEO (when we had one – which in one startup we didn’t for a long while) was often more the manager type and worked on the funding and other operational/general management and some marketing roles.
As we grew the CTO role was dominated by product management – because the work required more focus and customer contact than the personality of the CTO would provide. CTO moved off to “research” the future.
10th January 2008 at 11:07 am
jeff says:
Ah yes well I did say most effective but I hear ya. I guess there is a general caution in your story above not to confuse “leadership” with “management”.
And your right if your CTO is out doing the external stuff (and I’d argue they should) then it is really tough for them to manage the dev team. Depending on the size of your team, there may be a beta geek to lead dev but probably the rest of the geeks won’t let she or he do so
I’ve actually had one case where a n00b tester picked up the day-to-day management, I think mostly because no one was threatened by him.
That said you can certainly have an effective CTO without having them manage your dev team. And you’re absolutely correct most CTOs neither want to manage nor are capable of it. I think what Fred was suggesting is that, like anyone on your startup team your CTO needs depth and breadth.
10th January 2008 at 9:29 am
Jason says:
Not bad… Maybe I’d let you stay in there with the foosball table.
10th January 2008 at 9:48 pm
jeff says:
Jason,
glad I’m making some progress.
j
10th January 2008 at 11:15 pm