I've been a CTO several times. I've worked with many CTO's. Last time I checked, every one of them was a natural-born human being. No cyborgs, no alien intelligences controlling a homo sapiens body. So why is it when most organizations try to hire a CTO, their requirements clearly demand capabilities and accomplishments that no human being could ever achieve?

The Impossible Dream

I've seen a whole pile of CTO job specifications over the years. They are remarkably similar. If I were in the executive recruiting business, I'd be embarassed to deliver my "custom-built" CTO job requirements document, knowing that all I've really done is some light editing from previous efforts. The word "plagarism" somehow comes to mind.

But that's chicken feed compared to the blue whale in the room — this is a way bigger issue than a mere elephant in a room. It's the fact that no actual, living human being born of human parents (to rule out the alien connection) could ever possibly satisfy the requirements! The "requirements" aren't requirements — they're an impossible dream.

The Impossible Dreamer

Here are the first couple of verses from the song, the central song in the 1965 musical Man of La Mancha

The song and the musical are about Don Quixote, hero of one of the greatest and most influential novels of all time. Don Quixote and his faithful companion Sancho Panza go off on a quest to revive chivalry and do good works.

One of the most famous episodes is Don Quixote going after the windmill, which he imagines to be a giant. Things don't go well.

This is the origin of our phrase "tilting at windmills," in which you are taking on an impossible task.

Impossible CTO Requirements

Part of the trick in writing these requirements is to make it not seem to be an impossible task. I admire the clever writing needed to slide the impossibilities past the average reader, who, frankly, pays little attention to the wording.

The requirements amount to something like the following list:

• The successful candidate will be over 7 feet tall and be able to successfully pass under a limbo pole exactly 2 feet high without touching the ground.
• The successful candidate should be able to crank out bug-free code at the rate of hundreds of lines per hour, while being an empathetic, nuturing leader of technical talent.
• The successful candidate should have a proven track record of hiring technical talent that dresses in board-of-directors-friendly "business casual," works during normal working hours at the designated location, and is consistently cheerful and friendly.
• The successful candidate will have demonstrated the ability to be a self-starter, while at the same time executing management directives enthusiastically and without deviation or failure.

Have I exaggerated? No! I've only slightly edited actual requirements that I've seen in order to protect the guilty.

Conclusion

Trying to hire an in-your-dreams-only CTO is business-as-usual in my experience. I try not to get upset about it. And in-your-dreams is not even the biggest problem in CTO hiring; even worse is making requirements that actively filter out the most promising candidates! This madness is yet another side effect of people without a technical bone in their bodies thinking they can manage it, because after all, technology is just another thing to manage. This absurdity is so widely accepted in management circles that even solid examples of how ridiculous it would be to act this way in other fields just whittle away at the deep-set conviction.

Postscript

I know, I know, I'm being mean. The recruiters are, after all, doing the best they can with what they have to work with. They won't get very far with their customers (the companies doing the hiring) if they say "that's a stupid requirement, I won't put it in." And in the end, they're measured on the success of the person who eventually gets the job, which is way beyond a document — which people don't take terribly seriously anyway.

But there's a serious point here anyway: the document could be meaningful and helpful if it specified something that could be satisfied by something less than a celestial being, and if people could get clear about avoiding "there are at least 15 top priority items here — yes, they're all equally important!"

What's the right focus for managing a bunch of software engineers? Should you focus first on assuring that you have a congenial team with good working relationships, or should you focus first on assuring the substance of what they're creating is the best it can be? This is a similar question to the choice of process and substance that I covered in a previous post and it's just as important.

Substance vs. Process and People

Just as schools of education purport to teach people how to educate without reference to the subject that is being educated (math, history, etc.), management schools (you know, the kind that give MBA's) purport to teach people how to manage without reference to the kind of work that is being done or the kind of people who are being managed. The idea that "good management" and "management skills" are entirely distinct from the actual work being done pervades our work environment. The more esoteric the work skills, and thus the more difficult it is for a manager to have a clue about what his people are doing, the more this seems to be the case. Software development is right up there with particle physics in its ability to induce glassy eyes among the non-initiated.

Substance vs. People

It's really tough if you're a manager and you're trying to manage something when you have no clue what the people doing the work are doing. This is what leads to the strong tendency for anyone who claims to be a good manager to focus on process instead of substance, and to focus on people and human relationships rather than substance. Truth be told, if you don't have a clue about what people are doing or talking about, you don't have a lot of choice. A normal human being observing an exchange between two engineers can easily discern that engineer A is being nasty and disrespectful to engineer B, but how can that normal human being see that engineer B is proposing a completely stupid approach that will take a lot of time and then fail, while engineer A is being quite restrained (relatively speaking) in his reaction to the uneducated drivel drooling out of engineer B's mouth? The manager is likely to react to the only thing he actually sees, i.e., the disrespect being given by engineer A to engineer B, and therefore chastise engineer A, when actually it's engineer B who should be sent back to the farm teams, if not worse.

I am not claiming that there is a binary choice between people and substance, that if you focus on one you can't pay attention to the other. Of course, both are important. But as I look at software shops, I frequently see managers treating one of these as the primary goal, while figuring that the other will mostly take care of itself if they get the primary one right. The less they know about the substance, the more likely this is to be the case, but even experienced engineers who are trying to make the transition to management get a clear message on this subject from their superiors: good management is independent of substance, and a "good manager" makes sure above all that the human relationships in his group are in good shape, and that if they are, good software will naturally be the result.

Management focus and company success

In the best of all possible worlds, a manager would create harmony and excellent relationships among the programmers, while at the same time achieving maximum productivity towards making the company successful. That's a nice fantasy. But that's all it is. While being nasty doesn't imply great programming any more than being misunderstood implies that you're a genius, the fact is that there's a strong correlation between a focus on substance and company success.

The reason putting major emphasis on substance (i.e., "who's right" is more important than "who's more respectful of other opinions") is a winner is simple. The groups who all agree that writing the best possible software to meet the company's needs are more likely to … write the best possible software to meet the company's needs! Compare this to groups who all agree that having personal harmony among its members is more important than achieving the best possible software — doesn't it make sense that you'll make all sorts of compromises in software to optimize everyone's feelings? Oooo, better give everyone a medal, we don't want to risk diminishing anyone's self-esteem, do we?

Organizational Size

I've noticed that the larger the overall organization, the more that general, content-free management is the norm, and the more likely it is to be imposed on groups that develop software. This is completely understandable from a human psychology point of view. Everyone thinks that the skills and knowledge they have are the really important ones, and the others (which they don't have) pale in importance by comparison. The big bosses are likely to come from sales, finance or consulting and think that having an MBA is a good thing. Why should software be different from, say, running a store, or making deliveries? Or making tubes of toothpaste? If you're a … drum roll, please … manager, then that's what you do: manage. Your skill trumps all the others!

This is the dominant view of people who run organizations, or are on the management ladder. In order to advance, you have to adopt the organizational management-centric creed. Otherwise, you'll be "stuck" at the bottom of the management ladder, along with all the unwashed, unrewarded hordes who have to sit quietly with their heads down as various management fashions sweep through the grasping folks with sharp elbows who occupy the rungs of management ambition. If you even try to say "software doesn't work that way," all you've done is further disqualify yourself from advancement in rank.

If you've ever wondered why it is that small, under-funded organizations are nearly always the one who build ground-breaking software, and that giant, "well-managed" organizations with hundreds or thousands of programmers rarely do, this is your answer. "Good management practices" assure that good software rarely emerges from their large organization, and that outstanding programmers with superior ideas about how to do things are marginalized and otherwise made unproductive.

Software and Baseball

This may sound cynical and harsh. But think about, say, baseball. While it is tempting to think that all those beards

had something to do with the Red Sox winning the 2013 World Series, it is more likely that their outstanding pitching, fielding and hitting enabled them to defeat an excellent Cardinals team.

The 2012 season was awful for the Sox. It was their first losing season since 1997, and worst season since 1965. How did they respond? Did they update their project management methodology? Did they send in HR specialists to get everyone to be nicer to each other? Did they sideline people based on failing to high-five someone when they struck out with men on base? They did none of these things. Here's what they did:

• They fired the manager, even though he had a year left on his contract.
• They got rid of a bunch of players based on … their poor performance!
• They acquired a bunch of players based on … their superior performance!
• Finally they focused on their energies on, you know, … winning games! Doing whatever it takes!
  

Building good software is surprisingly like building a winning baseball team. Everyone does their job and puts everything they have into delivering great results. If someone isn't performing, too bad — you're not good enough to be a Red Sox! (Oh, just think how badly his feelings must hurt. How cruel!) Even so, sometimes someone is so awesomely good that it seems like he's carrying the team on his shoulders — and with Series MVP David Ortiz, you can make a strong argument that's exactly what he did with the excellent Sox.

Conclusion

People should be nice to each other. There should be mutual respect. But software is about results. The difference between average and great can easily be 10X for an individual, and 100X for an organization. You don't get "great" by focusing on process issues or good general management practices. You get "great" by … wait for it … focusing on software! Just like a musician focuses on the music and a painter focuses on the painting, the best software people focus on the software. The substance.

The methods in widespread use for interviewing and selecting software engineers are appalling. It is only because they are so bad that ridiculous methods like those often used at Google in which applicants are given trick puzzles to solve can seem like an improvement. The sad thing is, asking candidates to solve mental puzzles is better than what's usually done, which is not much at all. Come on, people — we can do better!

Typical Selection Practices

Managers need more programmers. They get a job requisition from finance, then go to HR to get candidates. Since HR knows nothing about the substance of the work that needs to get done, what ends up going into the job requirements are a bunch of motherhood-and-apple-pie blah-blah (self-starter, etc.) and a list of keywords of the technologies in which experience is required.

HR screens candidates based on whatever is in the resumes and may interview candidates, basically to see whether they mouth the expected platitudes when prompted by the HR people. Those who play the game are then passed to the programming department.

Typical Interview Practices

The candidate is typically scheduled for a round of interviews with programmers and managers. Since the managers rarely know much and have usually forgotten what little they used to know, they don't ask questions of substance; they basically find out if they like the candidate and if they believe the candidate will "fit in" and follow orders. The fellow programmers who interview remember their own interviews, in which questions of substance were few and far between, so they basically chat up the candidate and decide whether they like them. At the end of this "rigorous" process, if everyone agrees, the candidate is accepted.

What a joke! When you're hiring a musician, an audition (in which the musician performs) is standard practice. When you're hiring a writer, reading things previously written by the candidate is standard practice. So when you're hiring a writer of software programs, naturally you'd expect that reading programs previously written by the programmer would be standard practice — but it's not!

Leading Edge Interview Practices

Instead, the leading edge at places like Google is to hit the candidate with trick questions. For example: "Suppose you were suddenly shrunk to the size of a nickel and found yourself at the bottom of a blender. The blender is going to start in a minute. What would you do?"

If I were the size of a nickel, most of my neurons would be gone, so I wouldn't be me anymore. But more seriously, how relevant is the kind of skill questions like this test to writing programs?

I could make an argument that this kind of thinking is relevant to a kind of programming that is important, but very rarely needed: algorithmic design. No one has ever (to my knowledge) measured it, but I would be surprised if algorithmic programming amounted to as much as 1% of all the code in a typical application. The vast majority of code that's written needs different kinds of skills: visualizing user interactions, understanding data structures and data flows, understanding and effectively using complex subsystems, and many other activities. These activities benefit little from the kind of skills and instincts required for solving trick puzzles.

Are there people who can do the puzzles and be great "regular" programmers? Of course. The problem is the reverse: there are many people who would be perfectly adequate programmers who are flummoxed and generally disconcerted by questions of this kind. I've been in groups of trick question masters. They're great for finding what's complicated in basically simple things and other arcane but fundamentally counter-productive skills. Other than that — you can have 'em! Take 'em all — please!

What can be Done?

There are lots of simple steps that can be taken to improve the outcomes of sourcing and selecting software people. Any step you take is likely to make things better. I hate to do it, but I have to admit that even trick questions are better than the "Hi, how ya doin'" method of interviewing. But surely we can do better.

Reading code. When hiring writers, we read their past works. Why are we so reluctant to do so for people who write code? I suspect it's because very few people would actually be able to read the code and make a reasonable judgment of the author — for all too many typically mediocre programmers, that would amount to a tour de force way beyond their limits. That's OK — find out who can read code with meaning and judgment, and they become your main filtering agent. Maybe, just maybe, you'll end up with .. people who write better code! What a concept!

Auditions. What's wrong with an audition? If someone is supposed to know database design really well, show them one of your current ER diagrams and ask for comments. Tell them a change that is proposed and ask how they'd make it. Pose a recent tough problem you had to solve (which you've already solved) and ask them to solve it.

Detailed archeology. A candidate programmer may not know much about your stuff, but she'd darn well be an expert on stuff she's coded in the past. Find a subject where your experience overlaps hers, and ask for a detailed rendition on what she did, why and how — and what she learned and would do differently today.

Subject Matter Testing. Yes, testing. Like an audition, only more objective. If someone really is the expert php programmer they claim to be, they'll ace the test. No problem.

Conclusion

Software hiring is an embarassing mess. In a field that is over-the-top exacting with fairly objective pass/fail criteria (the program works or it crashes), the methods we use to ask new people to join us are random, ad hoc, and almost completely unrelated to finding out whether the candidate can actually perform as required. Asking trick questions can actually be an improvement, but that's not saying much. We can and should do better, and even a little better can make a huge improvement in the quality of the people who build our software.