First and foremost, management have delivery targets and budget
restrictions. One thing that can be hard for coal-face perfectionists
(of which I am one) to handle is the idea that the solution you are
working on is 'good enough' - i.e. it satisfies the functional and
contractual requirements and can be delivered on time and within
budget. It is unrealistic to go into any situation and expect people
to follow your lead simply because you believe it is the right
approach. You have to sell your idea, put it in terms of the benefits
to the project - management will always be wary of change for the sake
of it, and rightly so.

Second, a technique I use when making architectural decisions is to
write a white paper on the subject. I identify a shortlist of
alternative solutions and list the selection criteria to be used for
deciding which option is to be adopted. Investigate each option with
respect to the selection criteria with an open mind and document your
findings. Do this with an open mind and the best solution will present
itself. This approach can also be applied to proposing changes. If the
white paper approach has been used then you can validate the original
decision and see how your proposed change stacks up against it. If the
white paper approach hasn't been used then you can produce one that
covers the current approach, your proposal and at least one other
option.

Don't be tempted to skew this approach in favour of your personal
preference, people will notice! You want the right decision, yes?

The best thing to focus on is not whether a decision or approch is
'right' or 'wrong' from your perspective but whether it meets the
technical requirements. I always listen to arguments made from a
technical perspective, I have less respect for arguments that boil
down to "we should do it this way because I think it is the right
way". Be prepared to concede that when all factors are taken into
consideration it may not be possible to adopt what you are proposing.

Phil.

On Jan 14, 6:34 pm, Robert Casto <[email protected]> wrote:
> I don't think being right is over rated. It is going to depend on the people
> you work with and the organization.
>
> One large company I worked for never had problems listening to their
> engineers. Management actually deferred to their knowledge and expected them
> to stand by what they said. Being right was very important and highly
> valued.
>
> Other places I have worked, people get caught up in politics and spend a lot
> of time trying to protect themselves. Being right is not as important as it
> is being a team player. For engineers, this is very hard. They tend to think
> in absolutes such as right and wrong, good and bad, correct and incorrect.
> It is part of their analytical nature. They have no malice or ill will
> toward other people. It is just perceived as such. Most of the engineers I
> know don't care what you think about them. They want to contribute, add
> value, and be told why their idea is not good if it is rejected. They are
> insulted if you tell them it was a stupid idea. If you told them they look
> funny and insult their mother, they couldn't care less.
>
> Anything you do that improves yourself is very worthwhile. Even if it only
> helps a little bit, it is something that can help you in every part of your
> life. Best of luck!
>
>
>
>
>
> On Thu, Jan 14, 2010 at 1:03 PM, <[email protected]> wrote:
> > Being right is over rated, if you need to be right then you come across as
> > difficult.
>
> > Just try to understand why others have their view it is then much easier to
> > come up with solutions that everyone is happy with.
>
> > I found this book quite interesting though
>
> > How to get your ideas adopted:(and change the world) by anne miller
>
> > Shaine
>
> > Sent from my BlackBerry® wireless device
> > ------------------------------
> > *From: * Robert Casto <[email protected]>
> > *Date: *Thu, 14 Jan 2010 12:53:16 -0500
> > *To: *<[email protected]>
> > *Subject: *Re: [The Java Posse] Communication skills
>
> > I too have seen the problem described by Rakesh. I frequently find my
> > recommendations ignored or dismissed for some reason. Then a couple weeks
> > later they are proven true, but now I have to deal with the fallout.
>
> > I have attributed this to be an engineering problem. More specifically,
> > people's problems with engineers. We come off sometimes as arrogant and lack
> > people skills which makes it hard to communicate effectively. We are
> > frequently not the one's in charge, and so while we might be right, the
> > decision is being made based on many more factors than just our analysis.
>
> > Being right is not enough though it helps over time to get people to listen
> > to you. You can try to improve your ability to communicate, but many times
> > some other reason (such as money) trumps engineering. What I find most
> > annoying is when management asks for an estimate, but then says there is
> > only a certain amount of time available. They should ask if something can be
> > done within a time frame and if not, what could be cut out so the rest can
> > be done in that much time.
>
> > On Thu, Jan 14, 2010 at 12:37 PM, Viktor Klang 
> > <[email protected]>wrote:
>
> >> My recommendation is to try to see where the others are coming from. Why
> >> they do what they do, and how you can interact with them without doing
> >> unintentional harm. (honor, rank etc)
> >> Being right isn't key, it's to collaborate to achieve the goals at hand.
> >> And don't forget to have fun while you do it.
>
> >> On Thu, Jan 14, 2010 at 5:27 PM, Rakesh <[email protected]>wrote:
>
> >>> Hi fellow Javaposse'ers!
>
> >>> turns out being right isn't enough. No, I'm not just talking about
> >>> relationships!!
>
> >>> I'm struggling to get my point across in meetings with other
> >>> developers/management and I think its me.
>
> >>> Anyone else feel the same? Anyone done anything about it? NLP?
> >>> Presentation skills? Body language courses?
>
> >>> Cheers
>
> >>> RP
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "The Java Posse" group.
> >>> To post to this group, send email to [email protected].
> >>> To unsubscribe from this group, send email to
> >>> [email protected]<javaposse%2bunsubscr...@googlegroups­.com>
> >>> .
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/javaposse?hl=en.
>
> >> --
> >> Viktor Klang
> >> | "A complex system that works is invariably
> >> | found to have evolved from a simple system
> >> | that worked." - John Gall
>
> >> Blog: klangism.blogspot.com
> >> Twttr: twitter.com/viktorklang
> >> Code: github.com/viktorklang
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "The Java Posse" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> >> [email protected]<javaposse%2bunsubscr...@googlegroups­.com>
> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/javaposse?hl=en.
>
> > --
> > Robert Casto
> >www.IWantFreeShipping.com
> > Find Amazon Filler Items easily!
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "The Java Posse" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<javaposse%2bunsubscr...@googlegroups­.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/javaposse?hl=en.
>
> --
> Robert Castowww.IWantFreeShipping.com
> Find Amazon Filler Items easily!- Hide quoted text -
>
> - Show quoted text -
-- 
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en.


Reply via email to