Different Skill Levels
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).