[clue-talk] Assessing technical skills?

[Nate Duehr]

It's late, so this is going to ramble a lot.  I know myself pretty well, 
that way.  :-)

(By the way, I had a teacher named Rex once and he was a very fine 
person.  Good teacher, good person, and one of the most mellow people 
I've ever met.  Only saw him mad or agitated once, and it was for a VERY 
good reason.  Perhaps from that experience, or just because of some 
personal preference, I've always thought the name "Rex" was cool! 
Anyway...)

rex evans wrote:
> Nate,
> 
> I am trying to avoid the Our Department
> versus Your Department issues, for now.
> Plenty of time of that on a later thread.

Yeah, companies beyond a certain size ALWAYS seem to lose the team 
ethos.  It literally vanishes one day in a cloud of managers playing for 
"keeps" for their department's budgets and people.  I've seen this many 
times, and after a while you even learn how to move yourself closer to 
the manager who's going to win, just to protect your job -- but that's 
not real teamwork, nor is it conductive long-term to company health or 
growth.

Even stranger, at an even larger size, this problem goes away because 
the company becomes so large, no one department has any idea what the 
other departments "do" all day.  It's amazing, really, that anything 
gets done, other than by the grace of having people dedicated to the 
customer... the only thing that really matters at all in ANY company.

> More importantly, I think you were 
> describing an "accountability" concept,
> to which I say "Amen". 
> However this can immediately scare
> people, they can mobilize, and defeat you.
> I would implement the accountability in
> careful steps.

No worries, I got out of management in my early 20's and won't be going 
back unless I own the company -- babysitting (even well-paid 
babysitting) holds little interest for me, personally.  I know a lot of 
people excel at doing it, and I wholeheartedly encourage them to do the 
job.  I like working with systems and people, but not overseeing 
anything larger than a small team.  Watching one of my employees come to 
work and sit at his desk and play video games, while knowing that I'd 
been told he was not to be reprimanded beyond verbal reprimands by the 
boss above me, just drove me batty.  He should have been fired, and 
eventually he left on his own, more than year after I quit (the only way 
out of management and back into the technical ranks was to leave the 
company, which is a common problem), and started a landscaping business 
-- which by the way he talked about it when I ran into him (we stayed on 
good personal terms, I just found his work performance abysmal) at a 
movie theatre later --  was his passion.  He really loved working 
outdoors for his own company.  (And there are many days, I might agree 
with him!  GRIN... but the grass is always greener on the other side of 
the fence.)

> Whether Development, QA/testing, Operations,
> Implemntation, etc, there is usually a lot
> of key knowledge that is 
> 1)not recorded
> 2)not recorded in a useful format
> 3)not transmitted to the proper dept.
> 4)lost over time
> 5)collected but ignored (easier to make a
>    phone call than read the doc, especially
>    under stress) , then forgotten,
>   then trashed.
> 6)Add your own.

Yep.  Databases are one of the most hideous inventions of IT, ever 
created.  Not because they're bad in and of themselves, but because 
they're so often mis-used and no one considers the full-picture benefits 
and losses to the organization that a particular database and 
user-interface might have to the bottom line of the company.  Ever see a 
database that made the job HARDER than it would be with a paper and 
pencil or pen?  I've seen MANY databases that fit that criteria that 
were also the pet projects of someone far up the "leadership" chain, who 
had no idea the chaos the badly-implemented or badly-designed system was 
causing below them.

Managers that manage things or processes and not PEOPLE are the most 
dangerous people in ANY organization.  Processes are supposed to have a 
net good effect on the organization, not a negative one.

> Nate,
> You would like more detail on how not to
> burn out employees. 
> I would welcome ideas or examples from 
> anyone on this list, because I have am
> asking this question myself; I do not
> have an adequate handle on this myself.
> 
> Here is a little more detail, and it
> applies to all employees, not just IT.
> 
> Given that Employees are in a stressful 
> environment, they must see real hope for
> change. 
> Two concrete examples:
> 1) the things they do, are changing the 
>   situation e.g. Make better probing tools.
> 2)their team and their bosses are generally
>  favorable (or at least neutral) to improvement. 
> "bosses" can be Leads, first level Management,
> Higher Management, various workers in adjoining
> departments.

I think this covers the "up close and personal" needs of "having hope" 
at a low-level, but the one thing missing in countless organizations is 
information from leaders about where the ultimate goal of the 
organization is.

It's so rare to hear a REAL goal from a U.S. company these days, and I 
understand the myriad of political and legal reasons why -- but it's 
disappointing to anyone working at the "grind out the software" or "keep 
the customer happy" levels to NOT hear the "Why?" answers of "Why are we 
doing this?", "Is this really adding any value to any of our 
customers?", etc.

I've had the HONOR of working for a few managers who were forthright 
about their reasons for just about every decision they made, and they're 
a JOY to work for.  Some people are scared off by them when they explain 
the in-depth political reasoning behind what otherwise might seem to be 
a completely irrational decision, but I'm not.

I have the privilege of working for one of those guys now, and it's one 
of the main reasons I enjoy my job.

He will answer ANY question posed to him, by any person, at any level 
below him, and is honest even when the truth is difficult.

In the last year, he's explained some completely irrational things done 
in the company very precisely and accurately and while we didn't always 
like the answer, he always shared what he hoped he could do to alleviate 
whatever "pain" the organization's decisions were causing at the time. 
He's REALLY good at his job, and he leaves us enough space to be really 
good at ours too.  Managers like this are few and far between.

He expects us to help him the same way when we find really difficult to 
digest political problems, bugs, hardware defects, etc.  Honest, open 
communication.  If we share both the problem and our concerns about how 
it might affect us, the customer, or our concerns about how other 
departments or individuals might react -- he's there and ready to back 
us up.  Even if we accidentally "surprise" him with a difficult 
situation (not something you really should ever do to your boss), he's 
cool under fire.

Only if he's directly limited by someone higher than him (usually for 
very good reasons) or legal issues, does he not answer directly, and 
he's always open enough to state simply, "I'm sorry, I can't answer that 
right now."

This is in contrast to many middle-management folks I've run into who 
have an agenda, but they won't share what it is.  Usually they're out 
for only themselves, and come across as uncaring and sometimes even a 
problem for their staff.

So... to keep this on topic -- one of the amazing things about 
open-source and Linux is the ability for people with amazing skills at 
coding to find a niche to fill, but rarely is it truly "managed" in any 
way.  This leads to some really wild code diversions (just watch the 
Kernel Traffic list for a week to see them!) in Linux, especially.  If 
there were more "management" around, would Linux be better or worse? 
Always an interesting topic.

The "code to scratch an itch" model only works to a certain point.  Deep 
design flaws or code-rework seems to require so much pain that at least 
4 developers are screaming in agony who also have the skills to fix it, 
that from the "outside looking in" Linux seems totally disorganized. 
Why would anyone let "THAT" go on that long, an outsider wonders?  But 
then... all of a sudden a flash "meeting of the minds" happens, and out 
of nowhere the problem goes away.  And a HUGE amount of code gets 
cranked out.

Is it insanity, or genius to "manage" this way?  Only time will tell, I 
guess.  So far, it's working.

Even the original "feel" of "Benevolent Dictator" of the Linux kernel 
itself, eventually broke down under the sheer weight of changes being 
propagated into the Kernel.  I'd say today it's more a "Benevolent 
Monarchy" approach, with small teams breaking off to work in groups on 
various "itches"... or breakout individual efforts that clean up massive 
sections of code, but are hard for the Monarchy and Dictator to 
"swallow" unless they have spent a lot of time being spoon-fed smaller 
bite-sized patches by the individuals involved.  Quite interesting to 
watch, from "afar" as a non-kernel-coder, and very open.  Side-notes 
would be: The Monarchy is quite argumentative at times with each other 
(GRIN), and a large percentage of the Monarchy are now paid by real 
employers to do their "Kingly" work.  Quite different than the early 
1990's!  And always entertaining.

Instead of constantly asking the same question the magazine and online 
writers ask, "What can businesses learn from open-source", I think a 
more direct approach would be: "What can businesses do to incorporate 
the specific practices of open source while maintaining control of their 
business?"  Some companies seem to do this, but don't publish HOW they 
did it, because it's a very distinct competitive advantage for them. 
(RedHat)  Some gained a little by "dabbling" in open-source, but never 
really got the big-picture, or had too many serious legal and other 
limitations that wouldn't allow them to fully embrace the concept until 
they started to feel massive market pressure to do it.  (Sun?)

Appreciate your comments.  They're good ones.  And they challenge me to 
think, which is becoming quite rare in modern corporate settings. 
Processes take away the need for real thought -- if the "process" says 
one MUST do X, thinking about it rarely helps change it, unless one goes 
to great lengths to have a communication path to those setting 
policy/procedure.  And depending on the organization and people 
involved, can be either a simple thing to do (my case), or a very 
difficult thing to do.

I find all this "people watching" fascinating while I work.  Some people 
really "get it" and others, just don't.  And I think that comes back 
around to the "interview questions" topic nicely.  When you find an 
employee that just "gets it" it's usually really REALLY obvious.  They 
almost intuitively know your business, your concerns, and your problems 
from either good observation skills, or lots of experience in the field. 
  THOSE are the people you're looking for.  The former will be less 
expensive, but need "seasoning", the latter -- VERY expensive, and 
possibly need some bad habits built up over years broken, but both are 
well worth it.

If someone doesn't seem to "get it" about your business, or your 
concerns, when you're interviewing -- move on.  You can tell.

Whenever I've been asked after interviewing someone, "Can they do the 
job?  Do they have the skills?", I always have a yes/no answer ready...

But, I've found that it's a VERY poor indicator of whether or not 
they're ultimately successful at the job.  However, I've seen NUMEROUS 
times where if the question were asked instead, "Does he/she seem to 
understand what we're trying to do and care about it?" -- looking 
back... all of the people I would have answered "Yes" to were around a 
long time, and were highly successful at their jobs.  Their skill set 
coming in only determined how long it would take for them to become 
successful.

Now trying to relate that back to my "Professional Engineering" comments 
-- if Certifications weren't a complete joke in the industry (for the 
most part), and you could hire from a pile of people you knew had very 
specific, very solid knowledge of the job of Engineering computer 
systems... and you could focus on asking questions that would answer the 
"Do they understand our business and do they care?" question -- 
interviewing IT workers would be a lot simpler and a lot more productive.

We've incorporated this at my workplace.  A skills assessment is done in 
written form, BEFORE the interview, but NOT shared with the people doing 
the interviews.  We answer the OTHER question, and a smaller one but 
important, "Would they fit into the group?"  If yes from us, then it's 
the senior technical staff and management's decision to make about the 
skill deficiencies... "Can we afford to wait X months to get this person 
up to speed technically, and/or can we create a crash-course that will 
get them the knowledge they're missing."

So far, it's working very well.  Time will tell, but I'm very impressed 
with how our "junior" staff members we've added take care of our 
customers, and as a "senior" staff member, I can TEACH them anything 
they haven't picked up yet technically, as long as they came in 
understanding our business and customer's needs.

So this all "tempers" my comments about Professional Engineering. 
Anyone can BECOME a professional, if they "get it" up-front.  After the 
hire, it's just different time-lines for each individual person.  And 
we're all on one... no matter how well I think I know our systems and 
products, I learn something new every day.

A real-world example might be:

"I don't understand why this isn't working correctly, but I do 
understand how it's affecting you and your business, and I'll do X, Y, 
and Z to find the cause."

Is always better than:

"I know exactly what the problem is, but I'm sorry I broke most of your 
corporate rules fixing it, and had no respect for your needs in the 
process.  Your problem's fixed, but I caused you bigger political 
problems with your customers or your bosses because of my lack of 
understanding about how you do business."

Of course, no one ever says #2 there -- it's never that black and white. 
  It's just the support person who everyone in the department knows in 
their gut is a great tech, but makes EVERY customer they talk to angry. 
  That just doesn't work out, long-term.

Thanks for the discussion, it's great.  I'm constantly looking for ways 
to hash out these types of thoughts into concrete arguments and 
validations in my head.  Blame it on taking too many classes from 
teachers who understood that the real reason for teaching was to instill 
an ability to think, and not to cram knowledge into heads long enough to 
pass a test.

Maybe someday I'll feel up to starting a company and trying out some of 
the ideas I've had over the years.  Right now, I have no interest in 
doing it with any existing products or services I've seen, and I think 
I'd rather do it with something "new" -- so I spend some small amount of 
time every day brainstorming ideas for products or services in niches of 
business that I understand.  Since the vast majority of what I know is 
front-line deep-problem-solving customer-service skills, I generally 
find working for large organizations on big customer accounts and their 
associated problems fits my personality best.

But... I do miss the entrepreneurial "style" in the smaller companies 
I've worked in and would be willing to "risk" working for a small 
company with a tight focus on a particular niche that was dedicated to 
filling that niche completely and growing to fill the need in the 
market, no matter how big.  Especially fun are the "multiple hats" jobs 
that happen no matter what you do in a small company -- there aren't 
enough people (yet) in a small but growing company to have each person 
have a single "job"... wearing many hats and juggling priorities is 
stressful, but very fun.  For some.  I love it.

Today, I juggle projects for one large customer account in a similar 
fashion.  They have numerous techs, two engineers, and various managers 
to do all the "stuff" they do with our product, and I handle keeping 
track of all those people's requests and bundling them into digestible 
pieces that I can personally tackle or that I need to pull in resources 
to assist with -- it's great fun, most days.  The days I hate are the 
days when I have to go hunting for things to do, but they're rare, and 
there's always projects that "need" to get done, but aren't important 
enough to actively put resources on.  Making the switch from "busy with 
customer requests" mode to "need to get busy on old non-critical 
projects" mode is sometimes difficult for me, and usually really takes 
me two business days to make the switch -- I've been hunting for 
techniques that will help me move back and forth across that mental line 
and watching a few pepole "blessed" with the ability to make that jump 
almost instantly.

Fun stuff, again thanks for the discussion.

Nate