Telling someone to "let the world judge their development practices" without being condicending?

Question

There's a person in management on my team, that:

1. Doesn't ask questions on Stack Overflow.
2. Doesn't read development blogs.
3. Doesn't use development best practices.

This person is about to make some major decisions about the technology stack that will be used throughout the company.

(I asked him what the technology stack was they were planning to use was, and it included many things that are not even development tools).

How can I tell them to "Let the world's experience" judge their development practices, before they set them in stone; without being condescending or upsetting them?

Answer 1

Find something published (or presented at a conference, posted on a blog, anything) by a company in your industry about their best practices (or horrible experiences). Pitch it as "Well, let's learn from others' mistakes first...". That might open the door to further conversation.

A real company solving similar problems to yours should be easier to digest than something more theoretical, like a primer on SOA...

Answer 2

You can't.

Your attitude, as expressed in your post, suggests that you are condescending. You show no evidence of having looked at the problem (or issue or situation) from the other person's point of view. Why make this vague appeal to "the world's experience" ? Surely the requirements of your organisation should be the framework within which any decisions should be proposed, judged and made ?

And why do the 3 things that this person doesn't do disqualify him from making the decision. He doesn't:

1. Waste time on SO asking questions. Perhaps he goes ahead and answers them himself.
2. Waste time reading development blogs. Let's face it, there's a terrifically low signal-to-noise ratio in this area.
3. Use development best practices, but possibly uses good enough practices.

Answer 3

The most polite thing to do would be to privately let them know that you have some concerns about the technology stack that they are going to propose. Don't just state that you dislike it though. Have some reasons why you dislike certain components of it, and offer up an alternative with reasoning why it's better.

Essentially don't just tell them they are wrong. You need to offer an alternative solution with supporting evidence. Office politics and all. :)

Answer 4

Managers love numbers. This is why you see lots of pitches for software have sales numbers and user numbers in them. Take a look at this Google Apps propaganda. If your manager isn't asking questions, it's likely that that person gravitates toward flashy speeches (which even I get excited about sometimes and know better).

So, I would suggest finding numbers. Find ROI statements, which your manager will love. If you can prove to him that a certain technology will save him money AND make him a rock star to HIS manager, then they'll absolutely take the bait. The key is really hard numbers that you can put into a form to throw down on his desk and get the idea quickly. Whatever technology your team (and ultimately, your manager) chooses, will need to be approved for funding, and it's always exciting to managers to be able to spend a little money and get a LOT of value.

Answer 5

Have you already told him that you have concerns? If so, you can't change his mind. If he was able to listen, he would have listened by now.

What you can do is let him make the decision, let it be carried through, and then work to show that it was a bad decision that needs to be changed.

So, once the stack has been selected, push to start work on tasks that will reveal its weak points. Say he's decided to implement a real-time trading system in shell script: build a quick prototype and start some performance testing. Say he's decided to implement an ESB with Microsoft tools in CORBA-dominated environment; tackle some of the integrations first. Think about your objections to the stack, and how you can demonstrate them.

Note that i am absolutely not suggesting you sabotage the project. Don't make things look worse than they are. Pick a weak spot, do your honest best work on it, and let the weakness of the decision shine through.

If the problems you foresee really exist, you'll reveal them, and it will be impossible to hide them - you'll have developers on all sides wailing, and QA screaming, and project managers gnashing their teeth.

If, on the other hand, your fears are groundless, which they might be, you'll discover that too.

It's worth mentioning that even if you think the right decisions have been made, a "hard things first" approach is generally a good idea anyway, for exactly the same reasons.