Skip to Main Content

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, Kevin.

Asked: November 26, 2007 - 10:27 am UTC

Last updated: December 10, 2007 - 10:49 am UTC

Version: 10.1.0

Viewed 1000+ times

You Asked

Greetings Tom

I have been reading both the asktom site and your blog for a while now and have found both to be a valuable resource - not to mention your books which I tend to point our developers to.

I am curious as to some of the non-technical challenges you have run into or have seen in the world of Oracle database development and management. Recently I have had a couple of experiences in my own company where the technical aspects were evident and well documented but the "political" issues were more difficult to work through. With the role of the DBA evolving with time some of the non-technical skills like being able to present ideas and suggestions to non-technically savvy groups or groups with a different technical focus will become more a part of what a DBA will need to include in their skill set.

Thanks

and Tom said...

This is a good question.

Communication is the most important thing - 100%. In my experience the successful person is the person that can build consensus, get people to see their point of view, influence.

And if you cannot put five words together in a cohesive sentence, you'll never be able to do that.

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.


Understanding the business is important, understanding the primary goals, understanding what is really important.

For example, I am frequently asked to come in and talk to a customer - explain to them why Oracle is the 'best choice for them'. My first question is always "so, what is important to them - what is their goal, what are their challenges, what is the single largest problem facing them?" If I get as a response - oh, just come in and talk to them - you know a lot about Oracle, just tell them, I decline the invitation. The problem is - I could talk for 8 hours (well, a lot longer than 8 hours in fact) about the database - and not mention a single thing that is relevant to them, because I don't know what they are trying to do. If I don't know what they need to hear, I cannot communicate to them.

Nothing makes you feel dumber than talking to a room full of people and have them stop you and say "that is all well and good, but so what - we don't care about that at all". That happened to me once - the local team had an agenda they wanted to push which was not what the customer was interested in. Fortunately - I was able to ask them what their real problem was (migrating from another database) and could then address their problem. I was fortunate in that I knew quite a bit about our solutions in the area they were interested in - but that customer visit would have been a total waste (worse than a waste, a setback) if I hadn't.

So, in addition to being able to communicate effectively, 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.

Understanding the organization and knowing how to navigate it are important too. I remember once I was meeting with a customer - going over their architecture. I did not know everyone in the room. One of the cornerstones of their proposed architecture involved lots of update anywhere replication. I am very much against that in the general case - it adds so much complexity to the design (and most people ignore that and hope for the best and crash and burn later). I stated my opinion on that (update anywhere replication) and demonstrated how it was absolutely not only not necessary - but a bad idea. Then, I found out the person that proposed replication was right next to me - and not entirely pleased with what I was saying.

So, understanding the organization and the 'power structure' is very important too - you need to have a clue, be able to communicate and understand who you need most to influence (in a gentle way...)


Maybe we need to pretend we are all in sales :) You are selling your idea, your approach. You have to market it, promote it, advertise it, sell it. Not literally - but pretty close in some cases.

And realize it might take more than one meeting. And you might have to compromise.

So, communicate, understand, navigate...

see also:
http://asktom.oracle.com/Misc/what-attributes.html

Rating

  (14 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

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
Tom Kyte
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.




Tom Kyte
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.