Very true
A reader, November 27, 2007 - 12:03 pm UTC
Thanks for sharing these truly wonderful words of wisdom.
So True
Reader, November 27, 2007 - 2:50 pm UTC
1. "you have to have a clue - a clue as to what is the main goal. And then you communicate how you can achieve that goal efficiently."
2. "understanding the organization and the 'power structure' is very important too".
3. Let Go (from Blog)
Sometimes I find that #2 trumps #1. Recently I spent three months talking to people about a new application, gathering requirements, listening to ideas, priorities and really understanding what it was going to take to make the new application successful and meaningful.
I then spent weeks determining and writing up an Oracle based architecture that would meet these needs very well, detailing how the proposal would meet the specific needs of the new application and *only* talking about features and functions that actually mattered to the application. I wasn't try to sell them on ideas and concepts that we weren't going to use. However, when it all came down to it, the MS centric "power structure" won...not because it was the best solution or provided the best fit for the new application, but because of the organizational structure.
I didn't have that full and necessary understanding of the power structure that I should have before I spent all of the effort.
Of course #3, letting go, is the hardest part. This is a skill that I haven't figured out yet.
Non-technical database challenges
richard rabins, November 27, 2007 - 11:14 pm UTC
Excellent article.
Being aware of the non-technical issues around a project will invariably be helpful.
I am often surprised how smart technical people often seem to ignore this. Maybe it is just too tedious and does not exercise the cerebellum - but it does matter in the real world.
The statement from the writer that reads
"Also, being able to talk about something at many different levels. I have to talk to developers, DBA's, project managers, VP's, CIO's, CEO's - whatever. And I cannot say the same verbiage to the CIO as I do to the developer. They all need the same information - but at different levels of details - with a different focus - using radically different terms sometimes. "
is probably one of the smartest things i have read in a long time. Brilliant advice
Communication skill
Reader, November 28, 2007 - 12:23 am UTC
Yes. I agree that communication skill is the key skills you should have. and you need to know what is the pulse of the people you are going. To be truly effective, you need to do your home work (prepare). This is applicable for one off meeting, meeting the users, etc.
politics
Alistair Wall, November 28, 2007 - 5:33 am UTC
"Then, I found out the person that proposed replication was right next to me"
If you had known, how would you have handled it differently?
Communication you said
Mohamed Houri, November 28, 2007 - 7:09 am UTC
Several years ago I have been hired as a developer in a software project to be developed from scratch. At the time I have been hired, the technical architecture was already validated by the technical architect and the customer.
When this architecture has been presented to developers, I found, thanks to the two Tom's book and the two Jonathan Lewis books I bought and read many times, that this architecture will not work at all. Unfortunately, I was unable to change anything mainly because I have been hired as a developer and because I couldn't go to the customer and explain him in "radically different terms sometimes" so that he can support me. I realised when I tried to change things that I was speaking Chinese to a persons with French native language. In other words, I was unable to communicate not because "I couldn't put five words together in a cohesive sentence" but because "I couldn't speak to a non technical audience" and because I was viewed as a simple developer.
A year and a half after, the project started and have been delivered to the customer. Then problems and incidents generated by our new application start rising up. Due to the complicated architecture, those incidents were very difficult to solve, even for me who has been involved earlier into the development of this application. When the customer realised what he has been given, he remembered the private discussions we have had before the kick-off of the project. He, since that time, starts trusting me and accepting any change I was proposing to him. I didn't acquire new communication skills, in the meantime, to make my audience attentive. It was the disastrous application that made my audience attentive to me.
Before we delivered this new oracle application, our customer was using an old very stable, performant and easy to use Mainframe application. Since he has been in touch with us, he thought that there exist risks to implement an application in oracle. I told him that it was our incompetence, inaptitude and ignorance that put their new oracle application in an instable equilibrium and that built non performant software. Oracle is not to blame in this situation. I showed him this sentence I have taken from Practical Oracle 8i book
"The more people you invoke who do not have some understanding of how oracle works, the higher your chances of rolling out a failure."
I wrote these few lines only to emphasize that: you can have excellent communication skills but if other peoples in the same project have also excellent communication skills they may impose their ideas even if these ideas will not suit the business requirements in terms of performance, availability and scalability. It is not only a question of communication skills; sometimes it is question of ¿What have you done before that?" together with question of "Who you are?"
Imagine that both Tom Kyte and I are working in the same project, and imagine that we both have the same good communication skills, and Imagine (only imagine) that the technical architecture proposed by Tom will not work, while my architecture proposal will much the needs of the customer. Do you think that my proposal will be considered? The customer will never look at it. The only chance I will have to be considered is that the customer himself will realise (too late) that the Tom proposal was not adequate to their needs.
It is kind of ¿hierarchical sort¿. If you have been sorted by project managers or by customers in a level so that you are closer to the bottom than to the top, the chance to see your excellent communication skills ignored will be quite high.
Mohamed
November 28, 2007 - 10:58 pm UTC
...
Imagine that both Tom Kyte and I are working in the same project, and imagine
that we both have the same good communication skills, and Imagine (only
imagine) that the technical architecture proposed by Tom will not work, while
my architecture proposal will much the needs of the customer. Do you think that
my proposal will be considered? The customer will never look at it. The only
chance I will have to be considered is that the customer himself will realise
(too late) that the Tom proposal was not adequate to their needs.
....
that is something that keeps me awake at night. Not just this example with my name - but in general.
The appeal to authority.
http://www.fallacyfiles.org/authorit.html
A reader, November 29, 2007 - 1:46 am UTC
Hi Tom,
The "Politics" happened to me the same way what happens to thousands of real workers who a kind of "save the world" from the doomed projects with havoc created from insufficient knowledge base who are "politically" strong.
Communications is merely a routine here where people become pals in professional space just for that "big thing" and ignore the real workers' achievements.
This happened to me: As I was working with Oracle India and we were extending iSourcing application functionality in Detroit for American Axle and Manufacturing.
There was a component which was desinged in a way that required to extend a private class (which is not possible in the first place) in Oracle's OAF tool. It was the tunnel-end when the issue was discovered and people were shaky with the impact as the impact was a kind of roadblock to the expected wider market, post this implementation as deemed by the marketing personal in that region. I did not want to wear the superman's suit, but gave the commitment for getting out of this mess and then entirely designed in a very different way with the help of my team. The application worked with some bugs in it. The customer were ultimately very much satisfied with it but the local managers were not in a mood? The highlight was those mere bugs but the highlight was not the "they saved the world" part. I got very good feeback from the customer but the people around me played the dirty game and evidently enough I had to escalate the situation to the other side of the management - which you know of no use. There was everything that I did as far as communication was concerned but it does not make any sense after a certain level. And it was the end for me at Oracle.
The bottomline is: whatever you do, whatever mileage you provide to the project objective, it makes sense how you get migled around with people to let that "big thing" happen to you wihtout much of effort poking into the real work. It has a greater possiblity that you actually join the sea of "that group of people" instead of chosing a different direction, which was of no practical sense to me.
Any advice to such kind of people to come out of this situation, I bet there are lot many around?
Nihil novum sub sole
Etbin, November 29, 2007 - 3:22 am UTC
It always works this way
Point one: The superior is always right.
Point two: In exceptional cases (most rare) when the superior might not be right see point one.
Let's just hope an increasing number of superiors will be willing to take into consideration that
"WHEN YOU HIRE PEOPLE SMARTER THAN YOU ARE, YOU PROVE YOU ARE SMARTER THAN THEY ARE."
(R.H. GRANT)
Etbin
sports man spirit
Mehmood, November 29, 2007 - 3:41 am UTC
This is very nice thread. I am sure every one is facing similar situation or want to overcome on the shortage of skills.
There might be both negative and positive contributor in a team. What I think the best approach to tackle with the negative team player, we should play the positive game. We should follow the sports man spirit rule.
cheers
Yeah right...
A reader, December 03, 2007 - 4:39 pm UTC
"WHEN YOU HIRE PEOPLE SMARTER THAN YOU ARE, YOU PROVE YOU ARE SMARTER THAN THEY ARE."
(R.H. GRANT)
Leads to:
PHB: A good manager is one who hires people smarter than he is.
Wally: So... Your boss is dumber than you?
Alice: And your boss's boss is dumber yet?
Dilbert: According to your theory, our CEO is the dumbest person in the company.
This guy is smarter than me but I hired him so I am smarter than him. That doesn't make any sense.
I completely disagree
Kevin Walz, December 05, 2007 - 1:38 pm UTC
"This guy is smarter than me but I hired him so I am smarter than him. That doesn't make any sense."
You are missing the point.
As a personal case:
In my previous job I had a manager that I consider to be one of the best people I have worked for. The day he started he told us that technically we were all more accomplished in the technical aspects of our jobs then he ever could be. What he brought to the table was the dedication to making sure we COULD do our jobs. He managed the politics and and extraneous distractions that allowed us to concentrate on what we did best - manage the systems, fix problems, and suggest improvements.
As another benefit - since he was not as technically immersed in what we did when we had to explain what we needed to do - or wanted to do in some cases - we had to learn how to clearly explain what it was. I learned how to present ideas without getting too deep into the technical details that generally cause most management types to get that glazed expression in their eyes when something goes well beyond what they want or need to know.
There are different kinds of smarts in the corporate world - you are showing you are smarter in one aspect when you hire someone smarter in a different aspect.
There's a difference
A reader, December 07, 2007 - 2:01 pm UTC
"you are showing you are smarter in one aspect when you hire someone smarter in a different aspect."
I agree with that statement, now that you added "in one aspect". The original quote seems to imply someone is smarter in all areas.
"WHEN YOU HIRE PEOPLE SMARTER THAN YOU ARE, YOU PROVE YOU ARE SMARTER THAN THEY ARE."
That is a false statement.
"WHEN YOU HIRE PEOPLE SMARTER THAN YOU ARE (in some aspect), YOU PROVE YOU ARE SMARTER THAN THEY ARE (in a different aspect)."
This one is true.
December 10, 2007 - 10:49 am UTC
... "WHEN YOU HIRE PEOPLE SMARTER THAN YOU ARE, YOU PROVE YOU ARE SMARTER THAN THEY
ARE."
That is a false statement. ...
that is not a false statement, it is a "fable" like statement - it tells a story. It is a bit recursive - sort of like a piece of paper with
the other side of this paper contains a true statement.
printed on one side and
the other side of this paper contains a false statement.
on the other. If you hire people smarter than you are, and you prove that you are smarter then they are, then you did not hire people smarter then you are.
Anyway, the interpretation I take of this rather famous statement is:
do not hire under-performers, do not hire people that won't challenge you, do not avoid people that might some day totally eclipse you in some area. Do not be afraid of other people being better than you are.
Because you will always be challenged by someone...
Because you will be totally eclipsed by someone in some are...
Because there will always be someone better than you are....
It is unavoidable - you might as well make use of them (if they work for you, you get a bit of the credit for having such a good team see....)
In short, hire the best and brightest - fully knowledgeable that in some short amount of time - they probably won't work for you, they will likely either a) work "with" you as peers or b) you'll work for them or c) you won't work together anymore but in their organization they are likely higher on the food chain than you are in yours.
And remember to always point out in the future "yeah, good old Mary, she is smart - but heck, I hired her!"
I remember doing an employee review a couple of years ago (ok, many years ago)...
I told the person in that review that if they were still working for me in five years - they have totally missed the boat. They should eclipse me and go forward.
They do not work for me anymore.
They moved right on up into product management and now runs some of our Linux and VM infrastructure components now.
politics main project failure reasons
AMIR RIAZ, December 11, 2007 - 7:51 am UTC
In my experience politics run by influential peoples of a company usually bring down a project. politics to some extent is managable but extreme politics usually demoralizes your team and you will be in greater trouble when the person higher in the food chain consider you a threat because you are technical sound than he is. No communication way will work since your senior does not even understand the basics of what you are saying and the more you advocate good practices the more they get frustrated. It will quite interesting for me to know how TOM adovates his good practices to any person superior to him(if any). this is because whenever i tried to run his good practices the project is successful but i lost the job.
Followup
OracleAppsPM, January 13, 2008 - 12:21 pm UTC
This thread is really great, i fully agree that people in authority use that to supress the real good ideas of new generation technical folks, many time without knowing it.
I have been through the same and rejected quite a few peoples proposals , now i realise the same after project goes live.