Tuesday, July 26, 2005

Different Skill Levels

This was a question I received about managing people with diverse skill levels. I felt is was more appropriate for here, rather than there.

I am curious to know that having known so many things in depth, your expectations level from your staff must be very high. Then, how you are able to manage these people? Especially, I am sure there could be occasions when you might have expected something in one way and they might have done in other way, and with time constraints, you can not go back and re-write something. This could be as simple as maintaining standards to writing single SQL (rather than PL/SQL) etc., as we all are different, and we all do not know everything at the same level...

Actually, this year I have no "staff".  For the first time in 14 years.  And it suits me just fine so far. But I can still take a stab at this.  I remember in 1992, I had to hire some 30 people to staff a project. Have you ever tried to do that?  We ended up interviewing weekends (had the day job during the week plus hire people). We wanted to get people in and out really fast and used a hotel (funniest interview – we couldn’t get a conference room and a person I worked with – Janice – and I interviewed someone in a regular hotel room, with the bed and all.  Very strange setting).  After tons of interviews, you start to lower your expectations (you just want to get it over with).  Needless to say – we ended up with a team that had really good people, people in the middle and people that didn’t quite measure up.

I think this describes your situation. Yes, in the beginning, I expected everyone “got it” – if they nodded and said “I understand”, you thought they understood.  You learn really fast “I understand” can also mean “I have no idea what you just said, but there are lots of other people in this room, there is no way I’m going to say that out loud”. Lots of false starts.  But this is why writing things down (remember specifications?  documentation?  Sometimes some of that was done before a line of code was written) is important.  And why peer code reviews (when working on a software project with lots of fingers in the pie) are really important.

But you get to learn pretty fast who knows what, and who you can ‘trust’ as the person ultimately responsible for delivering the end product.  You learn who consistently would pump out a user interface that people could intuitively use (and didn’t have every screen looking like a brand new piece of artwork – have you ever worked with a GUI developer that made every screen a different color scheme, put the buttons in different places, ugh – you want to just say to them “what are you thinking!”).  You would learn who the coders were that you could just say ‘I need a routine that does X given Y” and they would just do it and it would work.  You would learn who you had to give 1 hour goals to (some people need to be micromanaged for one reason or another).  You would learn who works good in a team of 2 or 3 concurrent coders working together on the same thing, and who must always code alone (I always had to code alone :).  In short, you learned the group dynamics – who were the natural leaders and who were the natural followers and who needed to be managed into a different position in life.  Funny thing is – if you didn’t have a bit of all of them, you wouldn’t be able to do anything.  Given a room full of leaders, you just have lots of head butting.  Given a room full of people that needed to be guided – without the leaders you would not get far fast.

I actually prefer not to think of it as different skill levels, but just different skills.  It takes all types to make a project successful.  There are people that like the configuration management/quality assurance aspects.  There are people that like to have daily milestones and write code from specification.  There are people that like to be given a hard problem and no guidance.  There are people that like to be given a hard problem and a couple of bodies with heads to work on it.  I think you learn over time who is good at what you and dole out the work that way.

Walking into a new team and having to learn that all from scratch would be the hardest.  If you were just adding an individual to a team, you could try them out (nothing super mission critical until you learned what they are capable of).  But an entirely new team, that would be hard going at first, until you learned what everyone was good at.  But even then, if you are watching, that might only take a week or two to understand.

But I would use it as a reason to educate.  I remember this one guy – he didn’t quite understand the concept of a “subroutine”.  It was for him I instituted a rule that your code must fit on a screen.  You could buy the biggest monitor you want, but I needed to be able to see the top of the subroutine and the bottom on the screen (declares didn’t have to fit, the logic did).  The reason – I would take his code and hold down ctl-f in vi (page down) and you would see the same pattern over and over and over.  I’d ask “why” – “because I needed to do that loop to 10 things”, why not put the loop into a subroutine and call it?  “Oh, didn’t think about that, block copy worked well”.  That code would go back – that had to be fixed.  But this brings back the importance of CODE REVIEWS again – if you let the problem fester too long, you won’t be able to fix it and might have to live with it for a while. If you are monitoring it, you catch it first. 

So, it is part education (do it this way, let me show you).  It is part spec’ing it out (tell me, how are you going to do this).  It is part monitoring (tell me, what is the implementation looking like, how is it going). 

POST A COMMENT

21 Comments:

Blogger Jeff Hunter said....

This comment has been removed by a blog administrator.

Tue Jul 26, 05:01:00 PM EDT  

Blogger Jeff Hunter said....

Code reviews are a big part of trusting the person that is writing code for you. The first time will be a real drag, but after a couple times you will start to know their work and they will start to know the way you want it.

I always have high expectations for every member of my team. I expect them to be better tomorrow than they were today. Sure, they progress at different rates and they start from different points, but I expect them to progress.

Tue Jul 26, 05:02:00 PM EDT  

Blogger Rachel said....

I don't love managing (I'm competent at it but by no means gifted). But the times I've had to manage, I've tried to manage people the way I want to be managed. Sometimes that works, sometimes it doesn't. Give them responsibility, don't micromanage, check in with them on a daily or every other day basis. Protect them from people trying to interrupt them.

You do learn quickly who has to be micromanaged, who you can leave alone and just protect, who needs complete and detailed specs and who can be given a "we need a routine to do this", etc.

Managing is an interesting process

Tue Jul 26, 07:09:00 PM EDT  

Blogger Fahd Mirza said....

If the number of DBAs would be the same as of number of kids in the world, then I am sure Toms's books would outsell Harry Potters.

Wed Jul 27, 02:36:00 AM EDT  

Anonymous Anonymous said....

You said "I actually prefer not to think of it as different skill levels, but just different skills".

Excellent point! I recommend a book by Marcus Buckinham and Curt Coffman called "First, Break All the Rules: What the World's Greatest Managers Do Differently". It basically teaches that we all have different strengths and skill sets and that the most successful managers recognize that and thier people in the appropriate roles.
Also, and I agree with this 99% of the time, it says that you should spend your money on developing and training your workers for the skills and talents they have. In other words, I'm a terrible project manager, I could be sent to training to learn to be a better project manager, but chances are, I’ll never be a great project manager. Train, develop and enhance one's skills to their strengths.

--Dan

Wed Jul 27, 08:06:00 AM EDT  

Blogger Joel Garry said....

A concept has stuck with me since a Project Management course in the early 80's: Managers hire people who think like themselves, but should hire people who think as differently from themselves as possible, preferably with the goal of having a range of thought processes in a team.

This is what drives me nuts about DBA interviews, and specifically books or articles on "How to hire a DBA," or blogs where people claim to be able to snap-judge DBAs.

Not that there's anything wrong with testing/certification for a specific skill set, but the process often seems counter to the goal of winding up with a good DBA.

I partially agree with Dan's "train to the skills" idea, but must add that people do grow and change over time, and it is worth it to train outside the known skill set, as sometimes one is most pleasantly surprised. You don't want to overlook a diamond mine just because all you've seen is pumice.

One can certainly rant on the American way of corporate training.

Wed Jul 27, 10:50:00 AM EDT  

Anonymous Anonymous said....

Tom, sorry for abusing your blog, but I was wondering: what are the first things I should check if an Oracle 9i on Windows instance freezes every few hours and we have to bounce the instance? No new connections can be established and users can't even close their current connections. Everything is frozen.

This started happening yesterday. We're running an OLTP application (forms and some reports).

We don't want to enable full tracing yet as it may slow things down by a lot.

I looked at asktom.oracle.com but querying for "instance hangs" didn't give me much to go by. Any clues, links, keywords to search by, whatever (!) will be extremely helpful. Again my apologies for the abuse.

Wed Jul 27, 11:04:00 AM EDT  

Blogger Thomas Kyte said....

Anonymous said...

Tom, sorry for abusing your blog,


I'm always curious as to why the first thing that doesn't pop into anyones head isn't:

contact support

Wed Jul 27, 11:16:00 AM EDT  

Anonymous Scot said....

I'm curious why they are concerned about this:
We don't want to enable full tracing yet as it may slow things down by a lot.

When they are experiencing this:
instance freezes every few hours and we have to bounce the instance? No new connections can be established and users can't even close their current connections. Everything is frozen.

Wed Jul 27, 11:23:00 AM EDT  

Anonymous Peter K said....

rachel said...Managing is an interesting process

Yep. What I tried to do is invert the pyramid. Instead of a team working for me, it's the other way around. My role as manager is to ensure that my team has all the skills and knowledge necessary to get the job done and if there are obstacles preventing them from fulfilling that goal, then it's my job to remove those obstacles.

joel garry said...
This is what drives me nuts about DBA interviews, and specifically books or articles on "How to hire a DBA," or blogs where people claim to be able to snap-judge DBAs.
We ain't referring to a particular "much published" Oracle author here, are we? :D

Seriously one key trait that I look for in an interview is the candidate's willingness/interest to learn new stuff.

As for code reviews, amen to that. I remembered one time reviewing code that was written by an Oracle "guru" and what did I find? A bunch of UPDATE statements on the same table and same WHERE clause but updating different columns of the table. It's like "Huh? Mr. guru, you can take all 30 UPDATE statements and consolidate into one single UPDATE statement." :D

Wed Jul 27, 12:01:00 PM EDT  

Blogger Alberto Dell'Era said....

I hope that you would want to focus some more on social interactions in these micro-societies called "teams" (or in the society in general) in the near future - it's a topic that I'm very interested in, and that you seem to have a lot to say about.

As a possible related blog idea, that I'm sure would catch a lot of attention - what's your recipe to compensate bright technical people that are *not* interested in management ?

Say you have a bright girl, who's able to come out, consistently, with excellent ideas, architectures, bug-free modules of code; the typical top-notch technician that is 10 times as productive as the average (btw it has been *measured* that the individual variation in productivity is 1 to 10; 1 to 4 for teams as a whole).

Standard corporate practice would be to promote her to a managerial position, but say She dislikes managing. She likes to keep her hands dirty in the code.

How would (or how did) you compensate her results, knowing that her morale would go down eventually, if her results are not "acknowledged" somehow ?

Thanks-In-Advance :)

Wed Jul 27, 03:33:00 PM EDT  

Blogger Joel Garry said....

Peter K said We ain't referring to a particular "much published" Oracle author here, are we? :D


Well, could be. When the subject came up, I used to point people towards Ault's article when it was online, usually with a proviso that I didn't agree with all of it. Haven't seen the book, assume it is an expansion of the article. With hindsight, I disagree with it much more now. For example, I've been in large sites with numerous dba's that by any measure (including the stuff I didn't agree with) were excellent, except they couldn't deal with certain strangely designed apps, because such apps require a mixture of cynicism, historical perspective and creative analysis such folk often don't have.

And I maintain there are too many variables to figure out ahead of time whether someone will have such a mixture and be able to fit into the group - and I even go further to maintain common hiring practices can weed out the good ones. The result is often a period of time when something doesn't work (even with expensive vendor consulting), followed by a panicked hiring of someone who appears to have exact skill in the app, who may or may not be a myth-monger.

May we someday all have bosses like Tom!

Wed Jul 27, 04:43:00 PM EDT  

Blogger Noons said....

"I actually prefer not to think of it as different skill levels, but just different skills."

100% agreed. We're all different, it's part of being human. The worst projects I've ever worked in were the ones were damagers expected everyone to fit a mold and be just that: "human machines". Invariably this resulted in poor team work, missed deadlines, etc: we all know the horror stories.

Counterpart: two years ago I was in a project where the management basically behaved like PeterK: "we're here to help the folks in the project get what they need". This was the most successful project in that place, EVER! And the team involved still get together from time to time.

The thing management so easily forgets is that software projects need people to succeed and people are not hardware: they all have different approaches to life, skill levels and work ethics. The sum of that is what makes a person and it's persons that we hire. Not machines.

Wed Jul 27, 08:22:00 PM EDT  

Anonymous Anonymous said....

what type of methodology do you like to follow when you design software? How much time do you prefer to spend in analysis and design vs. coding?

Also, do you use ERDs and then convert those to server models when you do data modelling?

One last question, what do you think about the business rules approach? Its been big in ODTUG circles for 5 years now. There is a group of ODTUGers who are trying to create a tool that generates 100% of your code and you spend all your time analyzing the problem writing business rules for a rules engine. Paul Dorsey has a tool called BRIM that does this for PL/SQL and I believe java.

Ryan

Wed Jul 27, 09:52:00 PM EDT  

Blogger yas said....

Tom said "I'm always curious as to why the first thing that doesn't pop into anyones head isn't:contact support".

Maybe it is because of the disappointment with support.Getting solution to the tars is becoming more and more difficult.I do not know what changed but the skill level of Oracle Support is decreasing consistently.I myself prefer to search solutions without contacting support.This is faster.

Thu Jul 28, 04:53:00 AM EDT  

Blogger Connor McDonald said....

Quality of Oracle Support

I can empathise with them to some degree with Support - tough job with so many variants of platforms/versions etc. Then again, if one more support person asks me if they can do a internet conference when I've sent them a step-by-step SQLPlus script that shows the flaw...agggh!

Different skills

Then again, some people just can't be helped...Case in point just this morning. Datafiles in autoextend mode filled file system during overnight batch job. Production DBA resolved full file system by gzip-ing the datafiles!

"You can't fix stupid"

:-(

Thu Jul 28, 08:50:00 AM EDT  

Blogger Joel Garry said....

Noons: The thing management so easily forgets is that software projects need people to succeed and people are not hardware:

Conner: if one more support person asks me if they can do a internet conference when I've sent them a step-by-step SQLPlus script that shows the flaw.

I think these are both "if your tool is a hammer" issues. For project management, they use MS Project and stuff everyone into square holes. This is what MBA's are trained to do.

For support, I think they simply don't have enough categorizations to properly pigeonhole the different types of questions. (Or perhaps using the least-experienced people for the initial directing of the tar is a problem). But not reading the whole tar seems a rampant problem, I wonder if that comes from the boringly repetitive tar format.

Thu Jul 28, 10:05:00 AM EDT  

Anonymous Anonymous said....

I haven't dealt with Oracle tech support, but over the past twenty years in IT I've developed an almost insane hatred of dealing with support. This comes from years of butting heads either with clueless "script monkeys" or with arrogant geeks who are out to prove that their product is perfect and I'm a blithering idiot unworthy of their time. It's the primary reason I stopped buying Compaq computers back in 1995.

And then there's the little problem with all those people with weird accents who probably learned English through a correspondence course. Sorry, guys. I'd dearly love to learn Punjabi so I could converse with you in your mother tongue, but I'm afraid I just don't have enough time.

Basically, I'll do anything to avoid having to deal with these people. That's one reason I'm such a huge fan of AskTom. I can't tell you the number of times it has helped me solve my problems on my own. As the proverb goes: "If you teach a man to fish, you feed him for a lifetime!"

Thu Jul 28, 11:10:00 AM EDT  

Blogger Kalita said....

And then there's the little problem with all those people with weird accents who probably learned English through a correspondence course. Sorry, guys. I'd dearly love to learn Punjabi so I could converse with you in your mother tongue, but I'm afraid I just don't have enough time.

Different is the word you are looking for, not weird. They have different accent not weird, similar to difference in accent between British English and American English. You can't expect people from another corner of the world to speak a language the way you do when even in a small country like England people speak the same language in different accents.And no they wouldn't have learnt English through a correspondence course, they would have studied it in school.

Fri Jul 29, 12:37:00 AM EDT  

Anonymous Anonymous said....

Different is the word you are looking for, not weird.

Kalita: let me clarify. I don't have any problem speaking with well-educated people from India or anywhere else. I can find quite a range of different accents right on my home street: I have neighbors from Vietnam, Cambodia, Mexico and Russia, and that's just the people I've actually met and spoken to.

Unfortunately, a lot of companies, in a misguided effort to save money, have out-sourced their customer service to some far-away place where the representatives are almost impossible to understand. They may speak English, but not very well. That's what I mean by "weird" accents.

Of course, this is probably a bigger problem for "home users" rather than corporate users. As individuals, we frequently aren't considered to be very important in the grand scheme of things. That has been my unfortunate experience over the years, and the problem seems to be getting worse.

I don't think it's unreasonable to expect companies to support their customers in their local language, whatever that may be, with people who are well trained in that language, and easy to understand.

Fri Jul 29, 10:37:00 AM EDT  

Anonymous Nathaniel @ project management course said....

Nice post. In a team, there's group of people. We should remember that every person is unique, no one the same.

So, expected that everyone has a different way of understanding and doing things. If we are able to understand, communicate and handle with them well, everything will be alright and a successful project will result.

Wed Nov 17, 09:07:00 AM EST  

POST A COMMENT

<< Home