During the numerous product rollouts that I’ve managed, I’m quite certain that I earned a reputation as a semitechnical busybody who doesn’t know as much about technology as he thinks he does. My only defense against this criticism is that I really don’t think I know all that much about IT. I usually found myself scrambling at the last minute to figure out what the dev team was talking about when it threw around terms like CLOB, ODBC, and terminal services.
Believe me, I would rather worry about subscription projections, user focus groups, training, and all the other stuff that goes into launching a successful Web site or workflow application. But I’m always sucked into discussions that immediately adopt IT’s largely secret vocabulary.
There are tons of institutional devices you can use to separate business goals and technical implementation: that’s the reason for creating both functional and technical specs, after all. But at the level of the working manager, there will always be some blowhard business type asking why you’re doing something a certain way. The risk of this friction increases as eXtreme Programming and other new methodologies bring business and IT closer together.
Several folks have asked me how they should communicate with a nontechnical manager who is asking annoying technical questions. My oversimplified advice is to tell them to mind their own business—in a professional manner, of course.
In root business parlance, what you have here is a situation in which tactical details have overwhelmed strategic goals. Your job as manager is to take an overly tactical conversation up a notch to the level of the strategic goal that your team and a partnering business unit share—and then keep the conversation there. This isn’t always easy and, in addition to a little interpersonal tact, it requires two primary building blocks:
- Your team has to meet its technical obligations so that you can confidently say, “We’re on it—don’t worry.”
- Both you and your partnered business manager have to truly understand the global goals of the project, so that you can effectively communicate in that shared universe.
For the purposes of this column, I’ll assume the first pillar is a given; the second takes a little homework, but I think you can get there with these tactics.
Pass around some collateral in advance
When your team is first introduced to a new project, whip up a three- to four-page document that describes the technology you may choose to implement your solution. Above all else, make sure this document focuses on the goals of the technology—not the details. “Storing tagged data in XML format will allow integration with partner applications, which can decipher the information on their own terms” is enough, while describing the DTD process is just too much info.
I’m tempted to suggest you go to major vendors’ Web sites and download “tutorial”-grade documents, but those may well be more technical than you actually need for this purpose. TechNet is no place for a guy from accounting. Borrow as much as you can, but above all else, keep it simple. This may seem like overkill, but running out to a technical dictionary site and compiling a glossary of terms such as XML or DMZ may well be of real benefit. Pass this document on to your immediate lateral peer, but don’t send it to the CEO—keep that guy or gal as far out of your hair as possible.
Get some collateral in advance
Before you get to functional spec phase, ask your lateral partner to describe for you in one to two pages the goals of the project over the next few years. Again, stop short of Excel budget sheets—focus on issues such as which revenue/cost-saving opportunities the new project will support. This will put you in a position to credibly change the topic if your peer starts asking you about port numbers.
Draw lots of pictures
I can’t tell you how many functional specs I’ve seen that don’t have a single diagram in them. Get to know Visio. Instead of just describing in text that there will be a DMZ, throw together a flowchart that visually describes the process. In exchange, get your peer to draw you a timeline graphic for the lifecycle of the project.
Put the focus on user interface
If you have a nontechnical partner who is bound and determined to get his or her hands dirty with a project, sic the partner on the user interface (UI) portion of the project. Hook the partner up with a UI staffer and let the two of them fret over where buttons and fields will go. You’ll probably end up having to explain why certain database fields have to be updated in a certain order, but the payoff will be in reduced overhead of rebuilding functionality after alpha. You’ll find a lot of functional problems through this process that you won’t find in a review of a text-only spec.
Do not talk about technology in passing
Whatever you do, don’t just make a flip comment like, “You know, Oracle actually is a little better for this task than SQL” as you leave a status meeting. I actually had a VP once ask me if I thought we should go with Oracle or Microsoft SQL for a project (to my credit, I said that I had absolutely no idea). There’s no end to how far out of proportion comments can be blown—people will grasp at any straw you give them, particularly if those people are managers who want to feel like they are contributing to every aspect of the project.
When you establish the baseline, stick to it
Once you’ve laid the groundwork for the level of technology you are willing to discuss with your business peer, you have to be willing to say, “Listen, I appreciate your enthusiasm, but running through this database schema is not going to move the project forward.” I’m not suggesting that you be duplicitous; projects can just get weighed down with too much information. Providing a solid overview of the technology involved on the front end is enough to keep your partner educated to the appropriate degree.
Believe me, I and other business drivers don’t want to be the guy that makes you miserable and holds up the project. Like you, we have a ton of other things to worry about. Just tell us enough to make us comfortable and don’t use big words we don’t know in status meetings.
And, oh yeah, deliver the app three weeks ahead of schedule and under budget.
Ken Hardin is a freelance writer and business analyst with more than two decades in technology media and product development. Before founding his own consultancy, Clarity Answers LLC, Ken was a member of the start-up team and an executive with TechRepublic.com and ITBusinessEdge.com.