Technical personnel are not always invited to help solve a mission-critical business problem during the initial brainstorming stage. They're often involved later when they can be assigned specific tasks and responsibilities. So this is a unique opportunity. It's a litmus test to see if a technical person can relate to business decision-makers in a constructive way using both soft skills (communication and interpersonal) and technical skills.

Let's assume you can contribute technically, but due to lack of opportunity and experience, you're not especially strong on those soft skills. What are some general principles that can help you make a contribution? Let's break the scenario apart into two stages - the brainstorming stage and the proposal stage.

The brainstorming stage:

1. It's brainstorming session is a collection of equals - so be mindful of this point of etiquette. Technical personnel, due to lack of tact, can come across as patronizing, condescending, egotistical or demeaning. On the other side, there's no reason to act shy, apologetic or self-depricating. The chemistry you're after is friendly, helpful equality. Remove competing interests, politics and competition.

2. Try one helpful idea at a time. One doesn't have to worry about constructing a formal proposal right away that covers all aspects of the project. For instance, one might suggest: "I think I can help simplify the project by running a documentation tool against the databases. I can deliver a descriptive audit for us to work with in a short period of time."

3. Try suggesting an action item rather than just questions. In the scenario proposed, there are hundreds of obvious questions swirling around the air. They need to be asked and answered at some point. But the project moves forward toward completion from action items. Demonstrate that you're a person of action.

The proposal stage:

1. Set up a basic structure for your ideas. Good speeches and good essays have a basic structure. There's a beginning, middle and end. There's an introduction, a body of details and a conclusion. There's a thesis or a specific topic. For the body, consider making three main points. Sure you could make more points - but who's going to remember them? The basic structure is for the benefit of your audience. It's rude not to cater to the needs of your audience.

2. Help manage complexity. As technical personnel, one of our supposed strengths is that we're able to manage complexity. We can break apart complicated projects into simple, manageable pieces. So help do that right away. One mistake to avoid is to try to list off all the complexities of the project and then suggest you're the salvation - as if to say, "This could be a nightmare. Look at all the nightmarish aspects that could haunt our dreams and ruin our timelines! Look at all the unanswered questions! Good thing you have me around to save you. So be prepared to put up with me whether you like it or not." People don't respond positively to anxiety or resentment.

3. Act like a stakeholder. You might not have an equity interest in the company - but you do invest a good portion of your life by working for/with these people. In the end, along with compensation, you're also after satisfaction and a sense of accomplishment. What if you conveyed this attitude: "I think we'll all be very gratified once we meet this challenge together successfully." The opposite of the stakeholder is the incentivized subordinate who plays "hot potato" with projects. If you think you're getting too much dumped in your lap, learn to manage expectations, ask for the resources and help needed to succeed in a positive way. For more on this, see http://www.newfave.com/?p=37.

In short, the proposed scenario is a challenge for a techie to exercise soft skills and business acumen. You'll only get better with practice. So speak up in a way that is helpful, respectful and positive. If you're going to throw humor into the mix, watch the sarcasm. There's always truth in sarcasm.

Yours,

Bill