Feb23

SharePoint Code Published on CodePlex

After thinking this over for a while, and hiring a new employee, I've decided to truly make my SharePoint library both a more accessible and more collaborative effort by publishing it using CodePlex.
 
 
The SPARK project includes many of the examples published previously in articles from this blog, so those who have commented that you received 401/403 errors here should go there and download the source code. Just search through the files in the Behemoth.SharePoint project it to find the classes mentioned in the blog.
 
Why Behemoth? Well, because at least right now, the code is a big unstoppable monster. There's tons of code that needs to be ported over, (re)tested, and documented. Like any mythic beast, it is powerful and also a little scary. Plus the name fits with the theme of my company Colossus Consulting.
 
I'll be doing more additions and documentation in the coming weeks, so I hope if some of you find the code informative or useful that you'll leave me some love in the comments and reviews. (I also accept beer from those in the DC area.)
Published: Feb-23-09 | 0  Comment | 0  Link to this post

Dec01

My Annual Review: Revisiting the Idea of the "Job I Love"

Some time back, I wrote this little gem as a musing about what kind of job I would enjoy.
 
At the time, I had a job that wasn't particularly thrilling. Here were a few of my reasons for daydreaming.
 
  • Stagnant pay: In spite of positive reviews and even awards, I'd received no raise for two years. In fact, I observed a general trend towards stinginess, particularly towards those who demanded the best compensation up front. To me this begs the question, if you are competitive about acquiring talent, wouldn't it be prudent to be as-or-more competitve to keep it.
  • Abusive management: I had seriosly considered giving some of the people I worked for copies of The No Asshole Rule for Christmas. (Work Matters, Bob Sutton's blog is also a good read.) In my line of work you have bosses back at the company and at the client; there were no shortage of jerks embedded in both places.
  • Few (if any) prospects for promotion: With plenty of competitors, relocation out of the question, and my path blocked by immediate superiors, realism demanded that I did not delude myself into thinking I could move forward by moving up.
  • Allies leaving the company: when those most willing to defend or make a place for you are finding better opportunities elsewhere, it's time to pack your chute.
If you start to see signs of any of these things, take my advice and do whatever it takes to find yourself another gig quick.
 
Looking back, it was almost as if my bosses were reading my blog, because only a few days after I made that post, I was shown the door. I have heard stories of such occurrances.
 
I was lucky. Despite a very strong desire to be loyal to the company, I had never fully come to trust in them to do the same for me. After alternately witnessing and being on the wrong end of a number of instances of office "unpleasantness", I had resolved to stay on my assignment only throught the 1st of March and had prepared myself for the market, so by the time I was dismissed I already ahd everything in place to find a new job.
 
And so I returned to the world of independent contracting from wence I had come two years prior. I can't be bitter at my former masters. For one thing, losing my job was the best thing financially that could've happened to me. Also, as it turns out I think I am better suited for the life of an independent consultant.
 
So, as I come up on one year from that time, I want to take a look back at what my goals were, and make some observations about where my work life has met them and where it has fallen short.
  1. A+: Work mainly with SharePoint
  2. A: Don't work (directly) for the "Evil" Empire
  3. B: Variety in work
  4. B-: Limited practical and social impact of assignemnt changes
  5. C: See lasting changes (transformation) from my work
  6. B-: Focused mostly on the new and "yes you can" and less on the existing and "why you can't"
  7. A: Autonomous commute
  8. A+: Show me the money
  9. D: Leadership, example to others
  10. B: Fewer conflicts with others
These letter grades are relative to last year; so "A" means I made a major improvement, "C" means little has changed, and a "D" means that my attempts were fristrated. (It wasn't in the original list, but I threw in #10 "just because".)
 
I'd say overall, the changes have been good. Perhaps I'm best sutied to working independently after all. I'll be making my resume a standing part of the web site, so no need to repost a link here. Anyway, here's the drill down - more for myself than in case anybody cares.
  1. MISSION ACCOMPLISHED I want to work with SharePoint most or all the time, because it's really cool!
    Well, the demand for SharePoint has seen to that better than anything. There's been such explosive growth in this product line that it's just insane. I never did spend much more than a week on the bench lat winter, and even during the wall street meltdown in September/October I was only seriously looking for work for a few weeks. (My biggest error was in taking a much needed inter-gig vacation in late August.)

    Having my own consulting firm means being able to make a choice to turn down any assignments that don't make good use of the skills I have. That anyone at my old job ever for a moment thought it was a good idea to assign me any work that didn't include SharePoint proved to be completely short-sighted; in doing so, they had sacrificed both long term profitability and my marketability.

  2. MISSION ACCOMPLISHED But, I don't want to work for Microsoft.
    It's easier than you'd think, but I did get a call about a couple of jobs from one of their people in Reston.

  3. DOING BETTER I like working on lots of little short-term projects. Veriety in work and in solving different problems for different types of users is exciting. For that reason, I could probably spend my whole life building nifty web parts and showing people how to use them.
    Well, being an independent contractor does lend itself to changing tasks and roles at least as well as working full time for a consulting firm does. I would prefer to have things mixed up a bit more while on a single project. DHS had so much variety it was almost a problem. Here at IMF it's less so, but I suspect that as I grow into the role that will change somewhat.
  4. MODEST IMPROVEMENT But, I hate having to think about my commute [or the people I have to work with] changing whenever the project ends.
    I still hate this aspect of changing jobs, but there have been some improvements. I've had some mixed success. I did form some lasting friendships while I was at Constellation, and I try to keep in touch with people that I enjoyed working with. I've had trouble keeping in touch with some of my old colleagues - John, Erin, I am lookin' at you - lol. Joining a local user's group helped too, but I haven't been to a meeting in quite a few months now. One good thing is that my current gig is only a few blocks from my previous one, so I can get together with pals from the old gig every now and then.

    As for the commute changing, it was for the better. These days, I have more control of the locations where I work. Though there were moments when I worried that finances would force me to take an assignment that would make commuting a challenge, fortunately things worked out differently.
  5. STILL ABOUT THE SAME I truly enjoy using technology to help transform a business. Getting only little wins is really frustrating, so buy-in from the top is very important to me. If that means part of my job is to fight for that support, then so be it. Unlike many people, I find debate invigorating.
    In many ways, SharePoint lends itself to "little wins", so I see a lot of those. Transformations can be hard to fight for and take a while to happen. I think the trick is to keep the little wins lined up so they keep coming. Give a day or two each week to doing the little things that impress the people who are easily impressed, and use the remainder to take on the big challenges.

    I am very fortunate that here at the Fund, the CIO is a big advocate for SharePoint, so maybe I will get to see some of that awesomeness soon.

  6. MODEST IMPROVEMENT I like doing work on proof of concept and design. Finding out what can be done is fun. Finding out that you *could*, except that you *can't* because there either a) aren't the skills, b) aren't the resources, or c) isn't the time is no fun at all. So, a place where there is a real investment in technology (as opposed to band aid solutions) is a real plus. (Update: Add "lack of political will" to that above list of frustrations.)
    So what else is new? Many companies large enough to truly leverage SharePoint run into the problems of bureaucracy, process, and political willpower. The ones that are small enough to be agile run into the time-skills-resources roadblock. Part of the challenge of working with SharePoint is finding a way in spite of this conundrum, so I am learning to accept this.

    I still prefer development over software maintenance, so I am making the use of TFS and wiki for documentation at part of my mission here. I want other people to take over my stuff so it does not weight me down later.

  7. MISSION ACCOMPLISHED I would like to either have a very short commute to downtown Baltimore, or else a reasonable train ride to Washington DC that I can do myself. I am tired of relying on my wife for transportation. I wouldn't mind working in my boxers either, but I need an excuse to get out of the house once in a while, and some things are better done face to face.
    I spent about twleve weeks of the year working in my boxers. I also did a short term part-time gig that was mostly telecommuting - though it tried like hell to become full time or worse. Later, I took an eight week unpaid vacation and sat around the house.

    As for the commute, all my other work has been either very local to my house or in Washington DC. Only a few visits to Booz Allen in McClean, VA in the early part of the year were outside that spec - and although they were quite a haul, they didn't undermine my autonomy. These days, my wife only gives me a lift to the train station, and I'd love to find a way to save her from that.
  8. MISSION ACCOMPLISHED I'd like a job title where the median base salary is in the neighborhood of $150,000/yr. Software Engineering Director looks nice, though frankly I have never seen anybody hiring for that one. They always use terms like Developer, Analyst, or Architect. Sorry, but the pennies don't spend like they used to, and wages don't seem to be going up to meet inflation. I guess I could accept a lower salary for the right perks, but the money is pretty important.
    I won't go into specifics, but I am making much better money as an independent contractor. Even with the two month gap in employment this fall, I am well set this year. The net compensation is about double what I used to make as a salaried employee. Although, one thing I really need to be mindful of is the taxes.

    This is important though, and I can't stress this part enough. I would not be able to pull this off if my wife were not working. Her job provides the health insurance, taking that worry off my plate. Also, even though her salary covers virtually nothing beyond the mortgage and day care, it provided the much needed butress which allowed me to go through extended unemployment without sinking irrecoverably into debt. Given enough time to amass some savings and shop for benefits, I could possibly take care of both of these issues on my own, but this year it was an indespensible aid.
  9. NOT QUITE WHERE I WANT TO BE Funnily enough, I like managing technical people, and I am good at it too. That's an aspect of work that I miss when being stood up as a lone gunman in consutling gigs. You rarely if ever have the authority to direct a team. Well, at least sometimes you can act as the trusted advisor; that can be nice.
    I have to be honest, this is the one thing that hasn't been everything I'd like from a job. Being realistic, that's probably a good thing, since this year has been full of challenges that would've made taking a stronger leadership role difficult. I did get some technical leadership responsibilities at DHS. Due to the practicality of working with govies it wasn't what I was originally promised, but what it morphed into was acceptable. There is a good chance that some leadership duties will emerge here at the Fund, but it's too soon yet and hard to predict at this point. There is some of this in running my own business, but I need to find a way to profitability beyond my own hours if I want it to have any measurable role in my daily life.
  10. DOING BETTER Work in an environment that is less hostile and/or stressful. Have fewer conflicts with others and resolve them more amicably when they occur.
    Life as an independet is absolute not conflict free. For starters, I had one client who got to be over $12,000 in arrears early in the year when I needed the money most, and he practically begged for conflict. I mean how many times was I supposed to accept "it's in the mail" as an excuse, anyway? Another client tried to bully me into working more hours than we'd previously agreed on - honestly more than I could handle while trying to run and grow the business. Finally, the security clearance process at DHS will just wreck your sanity - especially if like me you are prone to explaining things in detail and have a lot of petty baggage to disclose.

    That said, I will take all this in trade for one abusive boss, or one client who thinks it's funny to tell his developers to go wash his car. There is a different power dynamic at play when a business is your own and you are (at least on paper) supposed to be independent. For one thing, it is much easier emotionally to stand up for yourself.
Published: Dec-01-08 | 0  Comment | 0  Link to this post

Jan25

I Thought I Was Done, But I Had Another Thought

So, I guess I am not finished my brain dump. Given my previous post, what do we know, and what's to be done about it?
  • Because people don't accurately remember times for compelting small tasks, programmers should measure their own productivity.
  • This is boring work and should be done using software.
  • Programmers will resist having their true productivity measured by management, so they should have the tools to do it for themselves.
  • The measurements of one programmer are utterly useless for anyone other than that programmer, as code production can differ by a factor of 10:1 depending on the individual and circumstances.
  • If programmers do not share their individual data, then it isn't possible for management to make accurate estimates.
  • This information is most valuable to the programmer themselves, because it would improve estimaties.
  • Management is more concerned about creating reliable estimates than in comparing individual output.
  • In programming, low level tasks of different types are not necessarily interchangeable in terms of time. Individuals have different specialization even within a lagnuage or a framework.
What's this mean? Should we just give up? That probably won't fly, but here are a couple ideas that might help.
 
It would probably be better if we don't ask programmers themselves to provide estimates. Instead ask a programmer to describe the tasks involved in getting a project done and then use reliable large-scale data to determine how long a project should take given a average level of productivity.
 
Forrester or the like may have done some of this research or found studies done at universities. I have read some general studies on this topic that were produced by Corporate Executive Board during my time on their SharePoint project in 2003, but I don't know if they have drilled down on specific activities. Another good source would be to follow Fredrick Brook's references and see where they lead and if there have been any modern updates.
 
Why would programmers not like this done within an individual company? Well, it's basically along the same lines as truck drivers having GPS in their trucks or weight detectors under the passenger's seat. I think that while the programmer who knows or believes that he is 10x more productive than his peers would welcome such a system, there would a majority of others who wouldn't want to give that person more ammunition or ego fuel. In the end, I think even the super-programmer knows that it is better to have solidarity with his brothers if he expects their help later on. 
 
Sidebar: Some of the lady programmers out there may have noticed my assumption that my hypothtical programmer is male. Well you ladies are unfortunately still very rare in our feild, though I do wish that would change. In any case, being so rare, you're probably going to get our help no matter what you say or do, so it would be survivable I think to lord your superior productivity over the group and demand that everyone count their code lines. (Of course, I hope by now you all understand that I am kidding, right?)
 
We could probably all benefit from a large scale (open source?) project that would allow the entire IT community to provide details about how long tasks take. There could be plugins for popular tools like TFS/vs.net for task management to make participation easier.
 
If the data is collected in large anonymous sets and each developer has access to their own numbers, then it would remove much of the resistance to the idea of managment grading everyone. This would be much more like the way insurance groups are created. You're boss doesn't have access to the information about your health that the insurance company uses to determine how much they will charge him or her for your medical plans. (Actually, the insurance company doesn't get the whole picture either, but that's not the point right now.)
 
To make such an idea work it would have to be easy, it would have to be reliable (fake proof), and it would have to be fun.
 
Food for thought. I'll come back to this again some other time.
Published: Jan-25-08 | 0  Comment | 0  Link to this post

Jan25

Why Are Programmers' Estimates Usually Wrong?

Okay, I don't have a ton of time for this post today, but I wanted to get it out of my headspace so I can focus on other things. I'll just be summarizing my ideas here very briefly, so if you can't keep up I'll understand. I plan to come back and write something more formal later on.
 
Here's the basic idea. I've been thinking about why programmers tend to come up with estimates that are always too short. This is a problem that is pretty well known in the IT community.
 
Many programmers apply the Scotty Rule to their estimates (take what you think it will take and multiply by three). I can tell you that I've tried that, and it's still very possible to come up with an estimate that is still too short.
 
Fredrick Brooks has gone into detail on this topic in several of his essays. If you aren't familliar with him, I suggest you run out and buy a copy of the Mythical Mon-Month (Wiki, Amazon) right away. There are also some discussions of the problem in the book Dreaming in Code (Amazon), which I have only half-read.
 
Here's a summary of the discussion I've had with colleagues about this, based partly on the sources above, and partly on my own and others' experiences:
  • Programmers aren't capable of coming up with solid estimates because they are too optimistic. Their nature leads them to believe the impossible is possible and to chronically underestimate the level of effort required for any task.
  • However, without this (psychotic? disassociative?) optimism, they would not be capable of taking on the burden of creating large and extremely complex systems that must function [nearly] perfectly [mostly] all of the time.
  • Further, estimates are generated at the start of a project, when very little is actually known about what specific small scale tasks will be required. Even if the design is known, the detail level where the actual work lies is generally not fully understood.
  • Update Added as a caveat to the above item: obessive listmaking does not help. It is inevitable that a single person drilling down into the required tasks will overlook something, somewhere, and that thing will likely be important. Peer review or collaboration will only help this to the extent that people are actually willing and capable of reading such a detailed laundry list. Imho, the best lists would be generated by logging actual tasks done on several similar jobs, and combining the results into a superset - with notes about when and why certain tasks were only sometimes necessary.
  • A good programmer would rather try to do something that is hard.
  • There is a real transition along the lifespan of a project, from a learning and creative process at the start to a controlling and list maintaining process near the end. Programmers who are talented at design and early development are not necessarily well suited to do stabilization, but are frequently required to.
  • We actually know a lot about estimating software and managing development projects, but for the most part we don't actually act on that knowledge. Brooks is correct in asserting that his book is the software development Bible (everyone reads it, nobody follows it). In 30+ years since its publication our tools have gotten better, but we really haven't learned to actually *do* things much differently.
  • Yadda, yadda, the list goes on...
I am adding an item to this list today, after having read this New Scientist article about research into how we perceive the passage of time. My premise is that one of the important reasons programmers can't accurately give estimates is that they can't accurately remember how long any particular low level task has taken. To support this idea with facts will require some more research, of which there isn't that much available.
 
But, I think there might be enough to support the idea that we can chronically underestimate how long a future task will take if we chronically mis-remember it as having not taken very long in the past. In other words, being in "the zone" or acheiving a flow state (which are good things, right?) can make it harder for you to remember accurately how long a task actually took you.
 
Perhaps some enterprising student of Management Science will stumble on my blog and figure out ow to arrange the experiment and get some funding.  For now, I'll have to keep digging until I have exhausted the pool of data that is out there today.
 
If this theory is true, then it is possible that estimates could be greatly improved by programmers simply keeping detailed logs of their activity. Sadly, that doesn't seem to be consistent with the "flow state" behavior and might undermine it. I am thinking that software might provide an answer for how to gether the data without disrupting concentration.
 
For example, could we use TFS to measure time taken for work items, and how might one incroporate such a tool into development so that it is a true habit and not disruptive to the creative process? I guess I'll have to answer that some other time though.
Published: Jan-25-08 | 0  Comment | 0  Link to this post

Jan24

To Heck With What I'd Like, How About What I'd *Love*?

Congratulations, Alara!
 
So, congratulations to Alara for landing a pretty sweet gig today. She starts on Wednesday, doing business analysis type work for a healthcare company in Elk Ridge - in addition to whatever else it was she's been doing with the city to earn money through her business.
 
The extra money she'll be bringing in from this new contract will really help a lot. Even if it doesn't go past the 2-3 months that it's commited to, it'll teally put a dent in what has become our too-damn-big pile of debts.
 
A lot of people don't like to talk about money, but for me it is not something I am coy about, and I'm generally very up front about it. The truth is that I make better money now than most people out there - more than I ever expected that I could. I'm not ashamed of that, because I work very, very hard and have cultivated some pretty unique skills. (Acutally, I'm not full of myself, so I know it's a lot of luck plus a little talent.)
 
So, when I say that this past year has been very difficult for us financially, please understand that if it was rough for me, then my heart truly goes out to the 90%+ of Americans who bring home less than I do. I grew up in near poverty; my mom took help from her parents, food stamps, and college aid as she raised me by herself. I know how it feels.
 
Lately, raising four kids, it's hard to figure out where the money goes and why we don't keep more of it. Maybe that is just a part of having kids. Or maybe we should both work a little less hard and instead devote that time into managing our money better. Less time spent in setting up the TVPC and a bit more in balancing the household budget might help. I think a lot of it has to do with the simple fact that the dollar just is not worth what it once was. If I had to guess, I would say it has had about the same effect as a 25-33% pay cut.
 
Oddly enough that's not what I wanted to blog about. I just wanted to thank Alara for her hard work, and for taking the stress (and the daycare bills) off of my shoulders a bit.
 
So, What Kind of Job Would I Love To Have?
So, her getting this gig made me start thinking about my job, about raises I did not get, about what I enjoy about my job, what I'd rather take a pass on, and how I really want to be spending my time.
 
So here goes, my wishlist for a dream job:
  • I want to work with SharePoint most or all the time, because it's really cool!

  • But, I don't want to work for Microsoft.

  • I like working on lots of little short-term projects. Veriety in work and in solving different problems for different types of users is exciting. For that reason, I could probably spend my whole life building nifty web parts and showing people how to use them.
  • But, I hate having to think about my commute [or the people I have to work with] changing whenever the project ends.

  • I truly enjoy using technology to help transform a business. Getting only little wins is really frustrating, so buy-in from the top is very important to me. If that means part of my job is to fight for that support, then so be it. Unlike many people, I find debate invigorating.

  • I like doing work on proof of concept and design. Finding out what can be done is fun. Finding out that you *could*, except that you *can't* because there either a) aren't the skills, b) aren't the resources, or c) isn't the time is no fun at all. So, a place where there is a real investment in technology (as opposed to band aid solutions) is a real plus. (Update: Add "lack of political will" to that above list of frustrations.)

  • I would like to either have a very short commute to downtown Baltimore, or else a reasonable train ride to Washington DC that I can do myself. I am tired of relying on my wife for transportation. I wouldn't mind working in my boxers either, but I need an excuse to get out of the house once in a while, and some things are better done face to face.

  • I'd like a job title where the median base salary is in the neighborhood of $150,000/yr. Software Engineering Director looks nice, though frankly I have never seen anybody hiring for that one. They always use terms like Developer, Analyst, or Architect. Sorry, but the pennies don't spend like they used to, and wages don't seem to be going up to meet inflation. I guess I could accept a lower salary for the right perks, but the money is pretty important.

  • Funnily enough, I like managing technical people, and I am good at it too. That's an aspect of work that I miss when being stood up as a lone gunman in consutling gigs. You rarely if ever have the authority to direct a team. Well, at least sometimes you can act as the trusted advisor; that can be nice.
Too bad that nobody will probably ever ask me what kind of job I want. Wouldn't it be great if we interviewed companies instead of companies interviewing us?
 
For your pleasure, here's my resume. If you feel so inclined, tell me if you think I am qualified for the job I am describing, or for that matter if it even exists.
 
Resume in XPS Format (It's like PDF only Microsoft-ier)
 
Published: Jan-24-08 | 0  Comment | 0  Link to this post

Jan05

Soft Skills for Dummies? As If! LOL

So, as I explained in my earlier post, I took the exam this morning to certify for TS for MOSS (SharePoint) configuration. Aside from the test dragging a whole bunch of skeletons out of my closet, it also left me feeling just a bit spunky. So, I guess I can't resist the urge to stick my middle finger up at somebody right now. Here’s something that came pouring out after I got all the self-immolation out of the way.

--fold--

If you have skills - if you are truly brilliant - people will find a way to try and put you in your place. There is some truth to the expression that “the nail that sticks up gets hammered down”. A lifetime of punishment for doing well has changed my behavior over time; it has made me learn not to shine too brightly. The Dao says that you should never forget the value of worthlessness - the gnarly tree by the side of the road does not get cut down for firewood. There’s some truth to that as well.

When you leave college, or after high school if you don’t go to college, hopefully you will be lucky enough to get a job doing what you like. After all, you're going to do it for half your waking life, so you'd better like it. But, something I remember from school is that there’s no short supply of people in the world for whom what they truly enjoy is putting other people down - or rather, establishing themselves in a group that is superior to others.

These people need to find jobs they like too, and while I don't think that every manager is one of these people, I’ve done some off the cuff counting of the ones I consider to be good managers vs. the ones that are not so good. I think it is fair to say that the career of management is at the very least an attractive option to these sorts of people. Once established on that track, they have learned to emphasize the areas of their personality in which they are strong and call them "soft skills", while they also downplay the role of "hard skills", perhaps sometimes almost without realizing that this is what they are doing.

What are hard skills, anyway? I suppose they’re the skills that actually let you get something measurable accomplished, whereas soft skills are soft because - like the soft sciences - they are as much or more fluff than quantitative or empirical and verifiable fact. If I were feeling more generous I might admit that at least the actual results of employing soft skills are more difficult (or impossible) to measure, but their use can produce real results.

So, what do I want to say by this? Am I saying these skills don't exist? Hardly! In fact, I myself have been in management positions at different levels, so I know that there are skills you can learn and that some people are indeed more socially adroit than others. But is there a certification exam for working with people? Is there a bar exam that you need to pass to prove that you are not someone who will poison the work environment at your company? No, not that I know of - the PMP certification teaches hard management skills, not social skills - just as an MBA teaches you tools and rules for running a business. But, an MBA can’t make you fun at parties all by itself – quite the opposite I would think!

To the best of my knowledge, there’s no finishing school for businesspeople. Maybe there should be. If there were, then many people who are too quick to point to a skilled developer and loudly comment about his "lack of soft skills" would have washed out long ago and become something a little easier to handle like being a hand sanitizer, salad bar spray barrier, or tire patch-n-repair kit.

After thinking about it for some time, I have come to believe that much of the discourse about soft skills that we take for granted as part of our working life is actually a myth. In fact, the truth is that we all have soft skills. We go home and have to practice conflict resolution with our families. We all develop different techniques for time management that work for us – however badly that may be. Many sports nuts would have a hard time fitting in at an anime convention - and being outnumbered might not feel too comfortable about it. I’ve seen very powerful people who were universally disliked by literally everyone at their company, but who didn’t even know it (though I believe they may have suspected it strongly). I’ve also seen executive managers in high levels jobs slink around as if they had been labeled “most likely to wear a pocket protector” because they were ostracized by their peers. Anyone kicked in the teeth long enough will begin to behave in ways that show they expect it, and the opposite it also true. Give a lowly developer a private office and they will start to behave more like they are 'in charge' as a result.

It is true that this is nothing more than my opinion, but I believe the myth of soft skills is a construction generated by the people who were the “cool kids” in high school, created for the purpose of indefinitely perpetuating their position in the social hierarchy. It has theory X written all over it. It has its roots in the same insidious class based elitism that causes us to say things like, "ain't isn't a word." even though you probably can't find a native English speaker alive who can't tell you what it means (and it's even in the dictionary!). There are real coping skills that people learn for dealing with each other, but to put up an imaginary straw man called "soft skills" and attach to it all your preconceived notions that nerds are socially inept is worse than wrong; it's pure and simple bigotry, and people who do it ought to be ashamed of themselves.

To be truly effective, any evaluation of soft skills would have to be based on measurable facts, and even psychologists and sociologists will tell you that generating this kind of verifiable and repeatable data [ethically] in human beings is challenging. Despite this, they do find interesting way to shed light on human behavior, and management science does sometimes find ways to translate this into the business world.

But, business itself could do much more. If we honestly expected the same quality of performance from people who had working with people as one of their primary job responsibilities, as we do from people who perform technically, then I don’t think it would be unreasonable to require from them the same kind of objective certification of their "soft skills" as is required for IT, medicine, law, accounting, or the building trades.

Perhaps such a test would be too costly in terms of time and "actors" to be feasible for new employee screening. Without being emotionally realistic, it would be incredibly easy to just fake it. But, at the very least I think we could all (technical and non-technical alike) benefit from some simulation exercises and training. Just as an example, I would like to see a salesperson or recruiter placed in the position of having to work overtime for several weeks straight, and then measure their social skills as their project is slated to be cancelled prematurely and they’re forced into the position of defending their investment in time. Or maybe they could be periodically graded on the way they deliver constructive criticism to employees who require negative feedback. I had some other ideas too, but they were starting to take on the characteristics of the Stanford and Milgrim experiments, so I’ll just stop. Again, ethics, challenging stuff.

Truly thinking about it now, I guess it's very complex and would require a lot of thought, but one thing I do know is that there aren't nearly enough people devoting resources into this area of testing or training as there should be. To say it is an order of magnitude less than the scrutiny given to IT skills would be a gross understatement, and it is only fair that somebody's feet should be held to the fire to make it happen.

Since that will probably never happen, maybe instead I’ll just write a science fiction novel about what it would be like if we did.

Published: Jan-05-08 | 0  Comment | 0  Link to this post

`