How do you Re-energize a workforce?

Drive... what a great book. And great TED talks.

One thing though, many of the things Pink describes in "Thirteen Ways to Improve Your Company, Office, or Group", I've tried them in several jobs. But they don't always work!

I have tried:

1. Time for the non-comissioned big idea.
2. The 20% "Operations Excellence" time.
3. The Google or Fedex day.  (Or the Hackathon.)
4. Inversion of control.

I have not tried:

1. Autonomy audits.
2. DIY performance reviews.
3. Peer-to-Peer performance reviews.

The problem is how to foster intrinsic motivation?

I've been in big ideas meetings where literally I was the only one putting out ideas. And this was at a time when myself (and most of my PM peers) were getting assassinated by management.

I've been in a group where the first Hackathon was scheduled with good participation, but the next had no engagement. Turns out engineering had a hate on for management because of lack of transparency.

I've been promoting hackathons and OE time when management fully supported it. Yet few wanted to participate because there was so much fatigue due to non-delivery. There was no trust in management, because there was no perceived leadership.

So what I really want to know (Do I really want to know?) is how to do a Whole 30 style reset of engineering and product culture - to get a toe hold back in building the relationship between engineering and product.  Ideas?  Anyone?  Bueller?  Anyone?

How to rebuild trust. How to regain enthusiasm. How re-energize the organization.

When I figure it out, I'll let everyone know.

Human Capital

My opinion on certification has changed. I am taking a journey towards a Certified Information Systems Auditor (CISA) designation and have joined Information Systems Audit and Control Association (ISACA.) I also plan to take at least one environment and sustainability certification in 2012. Professional development and self improvement are excellent goals. The personal networking opportunities are also incredible. I am not 100% convinced of the value of the various hurdles placed to maintain any certification, for example the thousands of dollars and a month of time on continuing education via conferences and what not. In my opinion, experience, aptitude and self-directed learning are still trumps in that game.

As I study up for the CISA exam using the CISA Study Guide by David Cannon (amongst other resource), I'm noting a lot of scrutiny in the realm of IT outsourcing that further validates some of my beliefs on the topic. I've seen some interesting notes and experiences, including:

• Outsourcing is done for a variety of reasons
  • scope of work is unknown (we can't afford to do it ourselves)
  • staff isn't competent or experienced (we don't know how to do it)
  • upper management thinks it is a good idea (not a core competency)
  • we're CMM level 5 and anyone could do our jobs (we've got it totally figured out)


• If a company and its outsource have not both performed an independent audit and/or shared those results before the contract is signed, there is only "hope and prayer" that the company's service requirements will be met. (p.150)


• Outsourcing must be based on facts and evidence. (p.337)


• If you're not CMM level 5, don't bother outsourcing.


• Many outsourcing initiatives are done for the wrong reasons and possibly half end up in "in-source return" situations (p.136-138)

I also continue re-reading Death March by Edward Yourdon. Everyone in IT should read this book as its almost as instructional as Scott Adam's Dilbert. (It is amazing how in over ten years since this book was written, nothing much has changed.) I've gone over the section on process dynamics a few times, and years ago I shrugged at the Abdel-Hamid software process model, but now it is meshing with my thoughts on effective staffing and building corporate value.

I've read that human capital brings three things to the table that can be abstracted; training, expertise, and awareness. Training is what you can be educated on, and in IT, it would be the technical aspects of a job (like a programming language.) Expertise is your exposure to business knowledge and how to apply your training (like building Health and Safety applications.) Awareness is knowing how your organization works and who to talk to overcome obstacles. The intuition that comes with that is incredibly valuable, as you may learn when to ask questions and learn from the experience of others, as opposed to re-inventing the wheel.

Outsourcing can be okay at the technical aspects, but expertise can be problematic (as stated in previous blogs) because to keep the cost down, an outsource tends to (attract and) hire less experienced workers that likely don't have direct domain (business) experience. They are even worse at awareness, because the outsource is not part of the company's business culture.

I think many in the business would agree that a good senior resource can accomplish work in half the time it would take a junior resource. The senior resource has probably solved the problem before, or has parallel knowledge. The senior resources should be the norm against which all work is measured. These are the folks that have been with a company long enough to know how to get things done within the organization's culture. There are also experts, or gurus, that ascending above the average senior resource and tend to move mountains with their thoughts.

Consider the following diagram, where the Y axis is cost per resource, and the X axis is time in months. The work is constant (as the functionality of an end product would be the same.) Let's assume the junior resource cost $50/hr (2/3 of the senior resource) and takes twice as long to do something as a senior resource at $100/hr. Let's also assume that the guru is being measured at $150/hr, and he can move about nine times faster than the junior resource.

It seems obvious to me that assigning senior staff to a key project is both cost and time effective. And the really important thing is these staff represent in-house resources. Outsources don't have the gurus because they can't afford or retain them, and they have fewer senior resources because that domain knowledge is missing and they're insulated from a client company's culture.

The other part of the junior resource problem, as I gleaned from the Yourdon notes, is the buffer time it takes to get junior or senior resources engaged on work. Some might call this the learning curve, but it is more than just a technical aspect as you learn the tech, the domain, and the environment. There are other buffers as well (that may be bureaucratic or resource scheduling in nature.)

Here is my extension of the resource process model, including the concept of buffers, and adding some feedback. For posterity, let's call it the Wieser model of Human Capital.

At the start of process, new hires come into the system. You can measure their rate of entry. Once in, they will be assigned work, and you can also measure the "Rookie Buffer", that is, how long it takes them to achieve baseline (senior) performance. This feeds the assimilation rate. Sooner or later the junior resources evolve into senior resources. An important thing implied by the diagram is training. You can infer the effectiveness of training by the same means (because it should decrease the time it takes to do the work, and also decrease the number of iterations and/or errors.)

Once the resources have been assimilated (and that means they have the technical skill, the business experience, and cultural awareness) you can again measure and define baseline performance and know the pulse. The next big thing is the exit rate, that is, assuming the junior resources become senior resources, watch what happens to them. There are some interesting metrics here, because it can guide your adjustments to the entry rate.

Lost	A resource may get redirected, that is, take a different career path within the organization.
Fired	A resource may get let go with cause.
Quit	A resource may leave for some reason (that is important to figure out. Did they get a better offer? Was there something negative about the working environment? Threats lurk in high exit rates.)
Retired	Resources retire (but tracking early retirement is an important indicator for culture.)
Died	Accidents happen, but work place accidents or related incidents need to be watched very carefully.
Discontinued	The resource, for whatever reason, was no longer required.

The big thing missing is exit rates at points of interest. For example, if you spend a lot of time and money training resources that balk during the training or shortly thereafter, that is a very alarming cultural indicator. Some put this into the retention rate and measure it over milestones like on-boarding completed, five, and ten year anniversary.

Now, if you look back at outsourcing, either as a company that is in transition to outsourcing and is having attrition issues, or as an outsource where you may have a culling of senior herd to keep profit margins high, you will see the model is front-end loaded. The true value and potential of developing the human capital will not get realized.

Momma Don’t Let Your Babies Grow Up to be IT Guys

Momma Don’t Let Your Babies Grow Up to be IT Guys
Don’t let ‘em play with computers and install dual OSes
Make ‘em be doctors and lawyers and such…

I saw a report from the University of Alberta that showed the number of graduates in Computer Science have dropped from about 400 ten years ago to about 100 now.  This trend seems to be consistent across North America.  At the peak of dot com, it seems a ton of people flocked to the field.  They graduated about 2004.  And since then, youngsters just aren’t jumping to get in to Computer Science.

The noted Willie Nelson song is going through my head.  How many of us with Computer Science degrees who work in tech or software development would recommend our kids follow in our footsteps?  My six year old son recently said “Daddy, I want to do what you do when I grow up,” and without even thinking about it I said “No way.  Be a doctor or lawyer or something where you can use your brain.”

This thought has gone through my mind a few times since.  Somewhere along the way I have lost the passion I had for computer science.  Recently as part of my New Year’s Resolution I downloaded the development tools for Windows 7 Phone and made an app in short order.  I felt the surge of coolness and fun I once felt when building something new.  Then I looked at where I am in my career, and where my future is, and I became depressed.  I am a smart, knowledgeable fellow and my talents are completely irrelevant in my field.

The reason Computer Science is dying is because anyone can get into tech.  There is no bar, no standard, and no common ground.  The folks in tech are disposable.  As an undisciplined service industry, they are always screwing up.  So there isn’t much respect from other business folks for those in tech.  And I don’t blame those business folks.  It seems that many IT departments solely exist to be bottlenecks and are woefully misaligned with their business user's needs.  Vendors churn out crap that business users buy on the recommendation of their techies without much concern about quality or fit.  Tech zealots argue about tech-du-jour.  The Dunning-Kruger effect is everywhere.

Computer Science wasn’t supposed to be a path to a tech job.  It was a way to think.  Algorithms and data structures were cool.  Optimization and simulation were really cool.  But how often do folks apply the best-fit solution in their applications?  Or monitor performance after delivery?  Most times you just use a toolkit, or bang it out, because industry has come to expect crap that is just good-enough.  Version 1.0 is the last version.  And that guy with the 2 month programming course can churn out broken crap much faster and cheaper than someone who has a 4 year degree.   Then they're gone.  The direction from Project Managers, Business Analysts, and the like is the wrong direction, because those folks come from very diverse non-tech backgrounds.

So my recommendation to anyone who is considering tech as a career: don’t.  Go into environmental science, law, or dental hygiene…  anything but tech.  There is more job satisfaction saving the environment, standing up for people's rights, or making sure a person's teeth are clean and their gums healthy.

Competency and the Art of War

Recently working in Environment, Health, and Safety has brought to the forefront something that has always confounded me: competency.

What is this exactly? A dictionary definition might be that a person is qualified to do a certain job. That person either has the knowledge, or can prove practical skill via a supervisor's assessment by some standard. In IT, there isn’t a lot of competency. I know that will probably irk a vast majority of people in the industry; but it’s true. Look at the history. People from all fields have flocked to IT, or have been seconded and promoted into IT positions. Think DOT COM. If you can’t find workers, you probably overlook the lack of education or certification in the attempt to have a warm body in a position that gets you some sign of progress. But would you let a plumber perform heart surgery?

Sure, you can argue that the heart is a pump, with valves and pipes- but what about all that medical mumbo-jumbo?

There has been a consistent pattern in IT as technology rushes forward without skilled labor to apply it. The history was, there weren’t enough computer science (a science discipline), computer engineering (an engineering discipline), or management information systems (a management discipline) graduates available, and computer stuff was shinny and new. So yes, you did see a lot of domain types jump the fence from accounting and whatnot into programming. This might have been okay thirty years ago if the employee remained in the same domain as their expertise.

So with the labor shortage, you saw a lot of colleges and non-accredited educational companies offer six month courses for a technology diploma. Your average university degree is four years. And I remember hearing the argument in the early 90’s, "We won’t hire a university grad because the tech schools push out learning on the bleeding edge, and that is what we need." Strangely, I heard that in a software company that was staffed majoritively by university engineering graduates. But the point is, technology moved fast enough then to question the credentials of people who were willing to dedicate a few years to training.

And it got worse. In the latter 90’s, all sorts of specializations of IT appeared. In some sense this was a quest for competency by business. All sorts of organizations started to appear (or get revamped) that covered enterprise systems architecture, business analysis, project management, information systems auditing, and many, many more. (This was shortly after you had technology certificates appear for short courses on tech-du-jour. I always found Microsoft accreditation funny, because being a user from day one, I giggled at Microsoft certified people that learned how to power on a server, start and stop services, and things that seemed trivial from either reading a manual or a few intuitive mouse clicks. But I digress...)

A good software developer wore many hats. And many people gathering requirements were also involved in translating them into technical specifications. Software processes evolved and were refined. And it was okay to be involved at various stages of
software development. But then something changed; people needed to fit specific roles, be certified for these roles, and not cross the line. Driven by failure, the software industry and Information Technology compounded their problems by disconnecting the people and communication from business to developer. Worse: people that were competent, measured by their success, started to have their credentials questioned by human resource departments that expected certification-du-jour. HR: What are you? CP: A senior systems analyst, been doing it for 20 years. HR: We don’t recognize that job anymore, so do you manage people? CP: Yes, I manage five guys. HR: So you’re a project manager, do you have your PMP from PMI? CP: Huh? HR: We don’t think you’re qualified.

Got ineffective IT? Fire them all

Nothing is black and white. There is always a degree or more of separation, or a gradient of how bad (or good) any problem (or solution) is. However we are in interesting times, and usually when bad economics drive business initiatives, management folks tend to opt for more polarized solutions.

So given our new climate where companies are finding it difficult to borrow money or fund raise through the issuance of stock, some problems regarding ineffective IT become more focused. These problems often don’t seem like problems in good times, because when the cash is flowing in or it is easy to get, then you don’t often think about how you can get the most out of your IT staff and processes.

I remember reading a quality management magazine in the early nineties, that oddly was also interesting times, the likened any organization to the human body. Though the article was directed at quality issues, the gist of it can be generalized to any business problem. The premise was the more entrenched and systemic a problem is, like most fatal diseases, the more radical solution is for remedy.

When the body is compromised in some way, usually the internal systems kick in to assist. However if you have a repressed immune system, or you body is simply overwhelmed, you need external help such as medicine. If the prognosis is terminal, you may need a dangerous and invasive intervention. For example, if your arm has gangrene, chances are you need it amputated to survive.

So is your IT department out of touch with business needs? Can it not promote best practices or optimizations? Are service levels dropping, regardless of whether you have a Service Level Agreement in place internally or not? Does your business staff complain that everything IT does takes too long, projects are of low quality, or the IT staff are uncaring and incomprehensible? You may have IT necrosis, and you may need to have it removed!

The unfortunate thing about the 90s (and probably now) is that it was easy for companies to make draconian decisions. Just like our medical analogy, you really need to discover the root cause of the issue, because firing your IT staff in whole or in part may not guarantee corporate longevity. Sure enough, if the people are bad, it can kill your organization. However if the processes are bad, or your corporate culture is bad, you may end up with the same problem. Any solution requires analysis that includes both resource and process remedies.

Do some triage and figure out if your issue is top-loaded or bottom-loaded. In a top-loaded problem, the IT people in the trenches likely commiserate with business clients. There is often some sympathy. Do your IT generals know what the concerns are of the IT footmen? Are there more than 4 levels of middle management (or restated, do you have many managers for managers)? As CIO, consider changing your guard and flattening your hierarchy. The most important thing you can do is to visit your human resources department and read the exit interviews of all the really good trench fighters that left your organization. Usually people are very willing to talk to independent corporate HR about their successes and blockers. And if you have your middle managers do your exit interviews, shame on you.

Bottom-loaded problems are a challenge, because they can thwart really positive corporate IT initiatives, hindering their adoption. These may exist because of fear of change, or an organic growth of culture that saw people not accountable or receptive to process (and dare I say beauracry). That said, I was in a company once where some of the engineers refused to detail their timesheets. These guys were great engineers, but undisciplined. As the company grew from 80 to 200 employees, it became more and more important to track who was doing what, and to introduce (shudder) management. Unfortunately the family feel of the company saw the stress of growth, without the process planning for growth, and did not force these radical free agents to comply with simple and rational processes. The result was a few death march projects, shouting matches, and a poisoned corporate culture. Process compliance should be measured, and non-compliance should be consequenced. Sounds a lot like being a parent, doesn’t it?

So remember, triage might save your corporate life in the short term, but long-term solutions often require postoperative care, and often preventative measures that bolster your corporate wellness.