Buzz Pressure

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.

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.

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.

My kids are pretty crafty. They’ve instituted a policy to celebrate half birthdays at our house. Before you think they’re really crafty, the rule is only homemade gifts so it isn’t a present grab. It’s also only a half cake so it isn’t a (total) sugar rush grab either.

Tomorrow is my half birthday and I’m turning 38.5. One thing I’ve noticed this year is that I’ve suddenly become way more comfortable with my positions on various issues. Either I’m getting self-actualized, or apathetic towards other people’s impressions of me. Or perhaps just old and cranky.

So, in that spirit, I’m going to start commenting on things about startups and the software biz that have always confounded me. Don’t worry, I can’t possibly be as cranky as Joel. He’s older then me so I’ll need some time. So without further adieu…

Over the years, I’ve been involved in a number of tech companies. Consistently there has been an expectation that the ‘techies’ must understand ‘the business’. In fact, it is often used to dismiss the technical side of the house’s opinion on things - like go-to-market, feature set or RFP responses. Now I’ll admit to being more then a little egalitarian in my mindset, (see I’m comfortable with that) and it has always bothered me that the converse isn’t true. In fact, there have been times where I’ve seen what can only be described as “learned helplessness” by sales and marketing in order to get their way. Sadly, it has been positioned as “not pissing the deal away”. Hmmm, is it pissing the deal away if you can’t possibly deliver what is promised?!?

Now I’m not suggesting that the marketing folks need to know the ins-outs of threading best practices but they should at least understand the basics of software, development, and deployment models. It’s even more critical with CEOs. The captain of a ship NEEDS to understand the working components of their vessel. All of them. People’s lives are at stake (not to mention investor money). So why, oh why, do we see CEOs without a lick of technical skills at the helm? Take a look at the most successful software companies out there (e.g. Oracle, Microsoft, etc…). Almost all of them had a techie, someone who once wrote code, as CEO. Shouldn’t we learn something from this? I know I have.

If this is your perception of Agile…

And if you’re in the Waterloo, Ontario area, you might want to come out to a Communitech Event on Dec 17.

Are your software projects:
Defect free?  Yes ? No
On-time?  Yes ? No
Under budget?  Yes ? No
Thrilling your users?  Yes ? No

If you answered Yes to all the above questions then congratulations, read no further. If you answered No to one or more then read on.

Since Agile was first introduced in 2001 it has taken the industry by storm. Recent surveys in Dr. Dobb’s Journal (www.ddj.com) have shown that Agile approaches are being adopted in 69% of organizations in North America and that Agile enjoys a significantly higher success rate than traditional projects. In this presentation Scott Ambler will describe what Agile is, address some of the myths that you may have heard, and discuss how Agile will affect your approach to software development. He’ll go beyond the Agile rhetoric surrounding programming and describe how project management, database development, documentation, modeling, user experience, and quality assurance activities are addressed by Agile teams.
Please join us for a complimentary afternoon seminar with Scott Ambler. Scott W. Ambler is the Practice Leader Agile Development at IBM Corporation. Scott is an award-winning author of several books, including books focused on the Unified Process, agile software development, the Unified Modeling language, and CMM-based development. Scott is a regular speaker at international IT conferences and is a contributing editor with Dr. Dobb’s Journal. Scott led the development of several software processes, including Agile Modeling (AM), Agile Data (AD), Enterprise Unified Process (EUP), and Agile Unified Process (AUP) methodologies.

This seminar is produced by eLead.Inc in collaboration with Communitech

You can register here. For free (as in beer)!

The Agile series was pulled together by local Agile mavens Declan Whelan of DP Whelan and Associates and Jeff Berardine of Innosphere with support from Communitech. I helped a bit but not nearly enough — sorry guys!

If you’re practicing Agile and love it, or if you’ve tried an Agile method and hated it, or if you’re just Agile curious please come out and join in the discussion. Heck just come out and hear Scott Ambler.

This afternoon Mark Slee of Facebook made it semi-official: it is Facebook’s intention to place Thrift into the Apache incubator.

For those of you not familiar with Thrift, I’ll quote Mark:

it’s a lightweight system for cross-language programming using code-generation, RPC, and object serialization. It’s designed first and foremost to provide high performance in real-time environments (i.e. Facebook’s backend, no surprises there).

We’ve been experimenting with Thrift a bit and it’s pretty cool. Some interesting parties playing with Thrift like Powerset and the Persai guys. Not to mention it powers Facebook. As a result, it is worth some experimentation. I have a draft posting of  building Thrift on OS X which is a little bit of an adventure. I’ll post it once it will actually be useful to anyone.

The real reason I’m excited about Thrift heading to Apache is that it’s the basis of what I think is possibly the coolest technology around right now — Thrudb. Thrudb is a framework for document oriented database services and is the brainchild of Jake Luciani of 3rd Rail. You can see Thrudb in action at JunkDepot. Jake has a nice write up on Thrudb on the 3rd Rail blog.

Check it out for yourself and thanks and kudos to Jake.

Carm (my wife) found possibly the most tragic, cautionary example of why you need to be market driven. For the benefit of those non-Canadians or non-caffeinated reading this posting: every year Tim Hortons (think Duncan Donuts) runs a contest called “Roll up the Rim“. The contest runs for a couple of weeks or until Tim Hortons runs out of cups.

Most Canadians gnaw at their cup to make the rim malleable enough to discover that they have to “play again”. Mr. Kind, the inventor of the “Rimroller” obviously was unhappy chewing away on his cup like some caffeine crazed freak trying to get every ounce out of his coffee, or more correctly every millilitre for us Canuckleheads.

Actually when I think of Mr. Kind, I imagine a tweed jacket with leather elbow patches — a sort of Curious George character. Clearly Mr. Kind is far too dignified to gnaw his way to disappointment and Roll up the Rim defeat. But you know you missed the mark when your sole distribution channel has taken pity on you and is only stocking your product because they feel so darn bad:

Paul Kind, had plowed a ton of time and capital into bringing the product to the point where it was ready to market. So, while Lee Valley is clearly not the most appropriate retailer of this product, we could only stand by for so long watching Mr. Kind work hard to sell this product without success.

Ouch. So other then the fact that Mr. Kind wasn’t very successful what else can we learn from this tragic story? That Lee Valley will pick up your crap if you’re unsuccessful? Um no but yeah they do seem to be reinforcing bad behaviour but you have to applaud their support.

Ok yeah the title was a clue. I have a feeling if Mr. Kind spent a little time with the market he would’ve discovered that while his invention is novel, his design elegant if not decidedly brown, it isn’t a “must have” product with a compelling, overt user benefit. Note: reducing cup gnaw is apparently not overt.

I’m sure this invention was justified throughout its development because I bet Mr. Kind has rolled up a rim or two in his time. Man that sounds dirty. But it is that “I’m the market” point that is probably the biggest learning here. It is really easy to say you are your market but the second you become inventor you’re no longer your market. Mr. Kind’s market is scarfing crappy coffee and downing sugary fat. They’re not taking risks, developing an invention. Hopefully the cost of tuition for this little learning wasn’t too much for Mr. Kind.

The good news is that it was free for all of us — unless in a moment of sympathy and weakness you popped for a Rim Roller. Now get out there and talk to your market, your fans and more importantly your critics.

Of course you can’t expect the market to tell you exactly what they want. They haven’t a clue but they know what they like when they see it and they know where it hurts. Now run along and invent and refine products that make your users’ world a better place.

Quinn was very excited tonight that he could see the planet Mars. Finally I took a look and holy crap the Moon was red. Apparently it is a bad sign for air quality but it’s pretty funky nonetheless.

I snapped a photo from our balcony — hopefully you can see it ok. I’m using the crappy Powershot 410 since someone stole our good camera while I was sailing at the Youngstown Regatta.

Red Moon over the hills of Chicopee

Twittering about how ridiculous the reaction to the first snow is  - $0.05 for SMS costs

Missing a lunch because you’re stuck in a ditch  - $20.oo saved

Public humiliation on the AideRSS site - priceless

B-Cubed recently posted about an Amazon screw-up with their recommendation engine where they failed to disambiguate the author Alan Cooper (of Cooper Design) with Alan Cooper who apparently writes about the history of war. Thus if you bought About Face you should buy Bravery Awards for Aerial Combat. Design is hell people. Apparently this recommendation engine affliction is both contagious and mutating.

Today I was doing some research and was poking around on the term “Hmaster” along with some other terms that I won’t mention for IP reasons. Anyhow Google suggested that I was likely really looking for “Hamster”. Ah no but it made me laugh anyhow. Especially at the thought that Google was recommending hamsters for my distributed processing. Hmmmn maybe they’re on to something.

PS before anyone comments, yeah I know more people search for “hamster” then “hmaster”. Or more correctly people change their “hmaster” search to “hamster”.