Communication Prevents Business and Tech Battles
An effective CTO has the most impact in the middle of a project -- after the
optimism has burned off, the breathing room in the schedule is dim memory, and the list
of features has grown unmanageable. The key talent at this stage is communication.
The great communicators among us have answers to the following questions: When did
you last adjust your project schedule? Where did you document the change? How did it
affect other projects? What committee approved it? How was this communicated? If you
don't, your project may be headed for a "business vs. technology" communication
Business and technology are two sides of one brain that is vital to the success of
most modern companies. At the best companies, the two sides work together elegantly,
with communication flowing simultaneously at many levels. In the worst situations,
total war breaks out and nothing gets done. But with good communication a company
becomes nimble and can turn on a dime.
In my experience, the marriage of business savvy and technical expertise is always
a feisty union. The partnership is constantly threatened by the pressures of succeeding
in a competitive market and coping with distinct personalities.
The ideal world for the business side is one in which the answer from IT is always
yes. Can we add a new feature? Add another client? Move the deadline up? Yes, yes, yes.
The business side wants to sell and make customers happy.
The tech side's ideal world is one in which getting it right is more important than
meeting deadlines. In most companies, important projects are done with new technology,
with new teams, or to volatile specifications. An unknown in one of these variables
makes a project hard to schedule.
That said, everything is great at the beginning of most projects. Yeses are flying
around. The schedule is created by an optimistic tech staff eager to produce. The
business side is excited about the potential, but doesn't spend too much time poring
over exactly what will be delivered.
Then come the changes. New features are added without assessing their impact on the
schedule. The competition is doing something, so the deadline is moved up. When a
deadline is missed, it becomes clear that no one will get what they want. Customers
will have to wait, features will be delayed, and there will not be time to get it done
right. The result is rancor and hostility. Many a business has been destroyed by such
The recipe for avoiding this disaster is explicit communication and a well-defined
process. A project committee with tech and business people must set clear priorities
and approve every change. As CTO, you must assess the impact of changes on schedules
and make sure they are communicated. You must develop a clear sense of the capacity of
your tech organization and fragment projects into small, testable milestones. Deals
made need to be written down. You'll end up with a tech side and business side that
understand each other and can work effectively.
I once worked with a vendor who promised a new feature but was going to have to
adjust development schedules to make the deadline. I asked the CTO if I should call the
CEO and make sure he knew the importance of this feature. The CTO just smiled and
said, "Don't worry about that. I'll talk to him. He'll understand." Here was a healthy
company with the mutual respect, communication, and trust required for success.