A Different Paradigm for CTO’s
Throughout my career I’ve had CTO’s express their frustration with their developers being “at the bottom of the totem pole”. Sales teams, product management, or founders generate ideas that need to make it into the product development process. These ideas, regardless of the methodology used, are stepped through a process of specification where details are laid out and an attempt is made to communicate to developers exactly what should be built.
Many times these ideas come with hard dates attached at which point the features need to be in production. Once development is underway, however, edge cases, error states, and critical functionality are found to be missing from the specification. What does a developer do now that an estimate has been given and a date set for production release?
All of the ills in the planning process have hit the developer like a ton of bricks and they are left alone to figure out how to make things work, thus feeling “at the bottom of the totem pole.” Some colleagues have described to me developers that cope well with ambiguity and those that do not. In essence, when left without specifications a person considered a great developer will be able to fill in the blanks without missing the deadline.
Unfair? A bit but not entirely a non-developer problem.
I’ve been meeting with CTO’s recently and many are working to define product development processes that attempt to account for this situation. Some seem disillusioned with any process’s ability to get it right and the resultant culture established is one of defensiveness, missed dates and overall lack of confidence in what developers can deliver. My feeling is that the main manifestation of this problem is simple: product doesn’t ship when it ought to.
In fact, I’m hearing more and more that this particular issue is second in accounting for missed deadlines and letting the product team down when a lackluster feature finally makes it into production. The #1 most disruptive scenario: having to respond to off-release requests that come in from clients, sales, or impatient founders.
I believe, though, that a CTO has failed the second they have attempted to create a process to account for this dynamic. They certainly have failed when their level of confidence has been diminished to the point that missing deadlines is not only acceptable but expected.
It’s my belief that CTO’s need to stop thinking of themselves as people at the bottom of a well trying to deal with everything that is being dumped into it. Product development processes aren’t linear and to the extent developers are the last stop on the train it’s because perception or process have put them there.
Throughout my career I’ve managed half or more of the people in my start ups by virtue of being the guy that controls the resources building the company’s core asset. What does it say if 50% of the people in an organization report to the CTO? Furthermore, what does it say if 100% of the people in an organization need technology to get their jobs done? It means that the CTO is literally beholden to everyone and can have significant impact on efficiency, culture, and process.
I would argue that a CTO owns at least one process with every single department in their company: sales has to know how to communicate recurring client requests into product development, marketing needs to coordinate messaging with product releases, IT controls desktops and networks, customer service is significantly more efficient if they have the proper tools to quickly handle service requests.
The CTO isn’t the buffer at the bottom of well between everyone dumping things in and the developers. The CTO is the hub and everyone else is a spoke.
A CTO’s ability to effect culture or implement sweeping change is unparalleled and subtle in most organizations that I’ve been a part of or have interacted with throughout my career. CTO’s need to be proactive, transparent, confident, and present. When a problem arises, it is likely a result of her/his people or process or something that, with a bit of focused work, she/he can solve being the center of an extraordinary number of exchanges.
Make no mistake, these issues start early and can lead to significant frustration and breakdown. I’m coaching more and more CTO’s to get up from their desks and create relationships and processes that get ahead of these deficiencies. I’m helping them to craft processes that instill confidence in their ability to deliver and in the organization’s to get things done and ship product. The first step, though, is getting them to realize just how core they are to everything that is happening around them and getting them comfortable with learning to see problems, rolling up their sleeves and getting in there to fix them.