What it takes to succeed

Dear Bob …

Your most recent Keep the Joint Running triggered some thought:

As a working CTO I’ve built a lot of software in my time. And the one conclusion I have reached is that regardless of how bad anything else is, good people will always find a way to succeed. The corollary to that is obvious: No matter how good anything else is, screw-ups will always find a way to screw up. And so when I see a success I commend the people. And when I see a failure I blame the people.

I’ll grant you that architecture is important. And that the success of many projects depends on having a good architecture to act as the foundation and framework for everything that follows. I’ll also posit that good people build good architecture through an inherent recognition of what is needed to succeed.

And while I’ll grant that internal projects often have budget and time constraints that are unreasonable since no one wants to spend overhead dollars on software projects. I’ll also state that it’s the IT department’s responsibility to make it clear to management why those funds are required and why the time estimate is what it is.

It’s fear of the unknown that is driving businesses to deal with software projects in the manner that they do. IT has been inordinately bad at estimating the cost of projects and in delivering them on time. Management strategy for dealing with this risk has run the gamut. I’m not saying they haven’t contributed to the problem. But they aren’t the problem. IT departments are to blame – they’ve lost credibility with management for failing to deliver time and time again.

And by the way what is a good architecture? Ultimately it’s whatever it takes to succeed. It should be good enough architecture.

– It’s the people

Dear People …

I have to respond with a yeahbut: “… regardless of how bad anything else is, good people will always find a way to succeed. The corollary to that is obvious, no matter how good anything else is, screw-ups will always find a way to screw up. And so when I see a success I commend the people. And when I see a failure I blame the people.”

First, yes, although I’d say “great” rather than “good.” Great people will find a way to succeed no matter how messed up a business’ systems, processes and leadership are.

Here are the yeabuts. First, I’ve been in too many companies whose leaders figure that gives them free reign to push messed up systems and processes on their staff, then require heroics to overcome them. When challenged, they say they expect their staff to find ways to overcome all obstacles – not particulary convincing when the biggest obstacle is them.

And second, what’s this about blame? Blame is the corollary to focusing all of your attention on the people rather than processes, systems and leadership. Blame is about making sure you hang the captain before the Titanic sinks.

It’s like this: Companies succeed through their people, their processes, the tools they provide (including information technology), how they’re structured, and the underlying culture established by their leadership. Taken to the extreme your proposition would be that you should be able to give employees a bunch of scrap ore, wood, and stone hammers and they should be able to manufacture competitive automobiles.

Not taken to the extreme, take two companies. One has great people. The other has great people, supplied with top-notch tools and who use well-honed and refined processes to do their work. “Great people will find a way to succeed” doesn’t cut it here, because both competitors have great people.

To your other points: Yes, both business management and IT have a beef. Business management negotiates project costs and schedules to numbers that are to their liking, then complain when the project manager can’t make that schedule. IT is notoriously bad at project estimation, and not all that good at project management either. They’ve solved the problem by blaming each other and engaging in dysfunctional behavior that ensures the next project will be even worse.

My biggest concern about your note, though, is your contention that good architecture is defined by what it takes to succeed. As a CTO, I sure hope you aren’t serious. Any given project can succeed by taking shortcuts, building a spiderweb of unmanageable interfaces, and using a hodgepodge of technologies to solve similar problems in different ways based solely on the preference of each individual programmer. That gets the project done quickly.

But it also creates costs and risks that aren’t discovered until three projects later, when another team has to deal with the mess.

And when doing so causes delays, chances are good their manager will say, “We expect good people to find ways to succeed.”

– Bob