How effectively "sell" a good design in large meetings

Question

Many times I have witnessed a sad tragedy. Here's what happens:

1. A team design review for a new project.
2. I see a simple design that has quite a few holes.
3. I casually mention the holes and ways to avoid them.
4. The warnings are ignored with comments like "that 'never' happen in real life"
5. Eventually the things that "will 'never' happen" happen
6. An emergency team design review for a broken project.

So what do I do? Copping the "I told you so" attitude is not going to win friends and influence people. Sometimes years go by and the comments from step 3 are forgotten anyway. I definitely don't want to be the annoying pest reminding the world of the gotchas. I often sit back and watch the Titanic sail off to Europe.

It's frustrating to see bad designs move forward. It's also frustrating that I can't seem to convince others of the pending peril of the current path. I do worst on team meetings where everyone has different ways of understanding different terms. Also, egos tend to win of reason and thought. I'm looking for good tactics to convince groups people to use some new and complicated ideas.

Answer 1

If possible suggest modifications that will not add significant time to a project. Try and stress that if it's not done now, then re-work later will be much more painful. It will be harder if you're trying to convince your team that a complete new direction is better, cause that will probably delay the project, etc.

Don't put people in defence mode in a meeting, they'll just fight you to be the winner. You won't get them to agree that the earth is round. This is normal politics (e.g. anyone on FoxNews)

It really helps to have the respect of other developers. If you're the new guy on the team, I think you are SOL. So just build up some team rep and really try to get to a level were you won't be dismissed right off the bat. Of course, if you are always pessimistic amount stuff, then you will just be labelled as the "negative" guy.

For simple stuff (i.e. does not impact schedules ), be sure to do your work the best way. If you put the effort into your immediate output (e.g. building test cases, or getting a some simple (but cool) features) eventually other people will notice that your code works reliably and withstands the test of time. When you start showing them some neat tricks with the code, they'll think twice shooting you down in front of everyone.

Finally, I agree you don't want to do the "I told you so" routine, but be sure to try and drop hints to your boss/tech-lead when it turns you actually were right. Maybe resend an old e-mail with your old comments. Ask them if this would help solve the "new" problem. If you don't do this, they won't even remember that you were the one who brought it up the first time. Eventually they'll get the hint that you're not just trying to be a showoff in the meetings. Next time they'll think twice about blowing you off, especially if it gets around that your "old" design is now replacing the current broken one.

Answer 2

Try to build a reputation as being the person who can identify what will work and not just what you think will have a problem in some rare use case. When you see these potential problems, just consider them a footnote that may need to be addressed later.

People get crazy in congregations. Mention your concerns to a key person outside of the meeting. They will see this as less threatening and may take the time to hear your argument instead of thinking about their defending the design. They may also take more time to explain to you the circumstances why you may have a valid point, but it is not feasible to address in v1.0.

Key! Go into the meeting with a complete understanding of what your direct supervisor's agenda is. Maybe they see this as a minor project and the last thing they need at the meeting is a naysayer taking time away from more important issues. Ask them to help you help them.

Answer 3

If you want to influence them, talk to them about it outside of the design meeting. Otherwise they are just going to think you are trying to "score points" off them. A lot of people don't ever want to have real discussions in a meeting with an "audience".

Answer 4

I don't see how this situation is much different from a lone developer with a clueless boss. Unfortunately, I've lost count of the number of times that I was 'convinced' to build a project a certain way and ship it, despite my warnings of impending doom. That leaves you not only building, but sailing the proverbial Titanic right into an iceberg all by yourself.

Just as you described, when the bits hit the proverbial bucket, my warnings had long since been forgotten. Sometimes (luckily for me) things went bad months or more after I was no longer involved in the project. Unfortunately, this left my successor thinking that I must be crazy, as you can bet that the boss denied any hand in it :)

Anyway, a group of 'convinced' programmers can be just as clueless as a pointy haired boss, sometimes even more because they are confidently clueless, as Jeff O mentions. When this happens, you have ample time to fix things. Don't try to make a single voice of reason be heard over a collective brain fart. If you can do that effectively, your place is in congress, not behind a desk writing software.

As actions speak louder than words, you can:

• Show (with test scenarios) why the design will fail under normal circumstances. This will probably result in a smaller meeting where you are the one presenting, and is probably all you need to be heard.

• Show a competing product that adequately addresses what the group thought were only 'corner cases'. You would be amazed at what lengths Google goes to anticipate mistakes in its spreadsheet program, for instance.

• Reiterate the last project that required a ground up re-write a week before it was supposed to ship.

In other words the first step, no matter what you do is to deal with individuals or a (much) smaller group. If your concerns really are valid, I'm sure that they'll be better received a week or two into development. Just, as you noted, avoid the 'I told you so' stance.

Answer 5

If possible, review the design before (or even after) the meeting, and talk to the designers in private. Shoot people down in a meeting in front of all their colleages will tend to make them instantly defensive and closed-minded about your suggestions, and can lead to a reputation as a "trouble maker" even though you think you're being helpful.

A good (but often difficult) way to present "criticisms" is to ask leading questions - let the other person try to answer your question and realise the flaw for themselves. Then it seems much more like their own idea and they will be more likely to take it forward. Again, this works best in private discussions, but can be a more diplomatic and effective way forward in a meeting situation (Note: Try to avoid getting into an argument or long discussion to convince people in the meeting. Just get the idea across and try not to labour the point. It may be better to let go of it and then have a chat with the designers after the meeting to "clear up something I didn't quite understand" than to be "the guy who made a simple 30 minute meeting waste my whole morning")

Another approach is to email your suggestions (diplomatically) to the lead designer (or a relevant but small distribution list). It may help get your ideas considered, and also gives you a "paper trail" to support any "I told you so" situation in the future (if things go pear-shaped, you at least have proof that you tried to help but were ignored. But if things get that bad, you probably aren't working in the right company)

Finally, bear in mind that sometimes you may be "wrong". The people you're talking to may have a clearer or more complete understanding of their design than you do, and have good reasons for their approach (for example, I was recently accused by a team member of creating an "inefficient" design, but it was a deliberate design as I knew performance would still be acceptable, but it would halve the development cost - it was a business decision rather than a code quality decision). Just try to be open minded about others' ideas - sometimes what appears to be a bad idea to you may be a good idea for reasons you haven't considered.

Answer 6

When met with the "that will never happen" scenario, remind them of all the times in the past when they had to fix those "that will never happen" items. But you have to be careful not to come across as "I told you so." I find it most effective to bring up past problems (and how expensive and painful they were to fix) in discussing why you think that we should do something now for this project as examples of why you think this important before they bring of the "that will never happen" quote.

I think perhaps your problem is you say you casually mention a way to avoid a problem, Perhaps you should come armed with more information and show them in more detail why this is a risk to the system. Sometimes that means bring up the subject in a second meeting after you have had time to do a little research. Build a business case for how cheap it is to do now vice how expensive it is to do later.

Answer 7

Sounds like your best bet is to work to get yourself to a Team Lead Position. Use these opportunities to point out to the powers that be that you saw this coming and it could have been avoided. You shouldn't need to sell your current team short in doing so.

Answer 8

The "casual" in "casually mention the holes" seems to be a problem. Try to use (or bring in if it doesn't exist) some written-down process for analysing project risks. Typically the output of a risks analysis meeting is a simple two column table: the risk, and what the agreed strategy for mitigating the risk is ("we think that never happens" is an acceptable mitigation; the important thing is to record the current thinking on the issue at the time). Make sure your issues are recorded as risks. Risks should be regularly reviewed; chances are quite a few people will have come round to your point of view long before the crisis actually happens and a risks review will act as an "OMG that does happen; we'd be insane to carry on like this" catalyst. Longer term, a paper trail is useful evidence for saying "look, we seem to have an institutional problem here" and getting attitudes to design or whatever changed.

Answer 9

How to get your idea(s) implemented

First in meetings refer to problems as challenges. You fix problems, you overcome challenges. Challenges are good things, problems are not.

Start slow and use this technique on one single challenge at a time. Next time you want your boss to adopt one of your ideas do the following:

• Develop three similar but different approaches
• Tell your boss you need his help with something
• Explain that you are not sure which of the three methods is the best course of action for solving the problem
• Ask Him/Her to help you choose one of the three

1. This is extremely powerful. What you are doing is providing choices not an ultimatum. Ultimatums more often then not get shot down because it's not their idea and there is only one option.

2. Your use of words is very key here. "I need your help".

3. Let the boss choose "A", "B", or "C". In fact let the boss create option "D" by pulling out sections from "A", "B" and "C". What you are doing is letting your boss make a choice.

At this point you could care less what option he chooses, because they are all your ideas. He will think he's actually solving the problem because you let the decision becomes his.

Answer 10

Have Proof of Concept of your idea implemented. If you show your team something working and solving current problem at hand than they will like it.