Contempt

You've all seen it. The over-paid, under-qualified developer who determines his self-worth by undermining those whom he thinks are even less qualified. Or the micro-managing project lead who wants to know if you're 51% or 52% done with that task. Perhaps, the well-traveled consultant who clearly knows this product space better than anyone.

These are all signs that part or all of your team has the blight of contempt rising within itself. Contempt, you might say, what does that have to do with implementing technology. Clearly, technology is a science of which reason is the best determinate, you say, why would human emotions affect my project? A fair question, but I ask you now to review the lessons learned from your last failed project. What caused the majority of issues? In my experience, these have been primarily human error. Lack of communication, misunderstanding of requirements, incorrect people in roles.... I would doubt that missing status reports, lack of a project plan or other process/technology issues were not at the top.

So... we've determined that emotions, not just reason, do have an effect on projects but why would contempt rule the roost. Well, let's define contempt and give some examples. Contempt is disapproval towards what seems worthless. In other words, this is a lack of buy-in from the team towards the end-goal or more personally as a divisive force within the team that alienates others viewed as less worthy. Now, we're getting to the heart of it. How does a project succeed if key participants don't believe in the end goal? Or how does a project succeed when the developers 'look down' upon the database analysts or, even worse, the business analysts. These two examples provide the basis for project failure, either the team doesn't believe the project will be successful in itself or someone is standing in the way of the project's success.

The first example requires an effective project manager to drive deeper into these emotions. What if we were tasked as project managers to create happiness in our teams. On the face, this is an absurd goal. Why do we care about the happiness of our staff? Simple....one key ingredient to happiness is the belief that we control our destinies. Surely, project managers would love to control the destiny of the project, but the bizzare truth is that we must let go of the project in order to be successful. We must place the control of the project destiny into the hands of those doing the work. What does this mean? It means that now we are no longer the engine in the ship, but simply the rudder. However, the benefit is that now the developers, testers, analysts... now believe that they control their own destiny. This equates to job satisfaction, which equates to ownership.

Ah, now we've found something. Our team now feels ownership of the project. With ownership comes a plethora of good things. These include a better attitude, more motivation and most of all the desire to care about the projectBut what about the second example, where one sub-team views another as being a detriment to the project? Or, even worse, the team architect decides that the team doesn't understand the elegant solution being provided. A much tougher question that I will suggest an alternate to conventional methods. First, as a project manager, one of your main objectives is to remove roadblocks from your project. Second, you must determine those roadblocks by the amount of contempt shown in the embattled partners. If your architect is acting with contempt towards the project team and you are sure that the team is engaged, then remove the architect. Sure, this may cause fall-out, but you've removed the blight that will kill your project. Sounds easy, but in truth, removing a key participant in the project may not be that simple. In this case, I would advise using the biggest tool in your arsenal. In most cases, that is raising the flag up the pole, or escalating to upper management. By making the issue public, you will have endeared those in whom the success of the project falls and isolated those who have endangered the project.

I know what you're thinking...give me four outstanding developers and we can run circles around a group of twelve average developers. There is little disagreement that motivation and ability are the key determinants in a successful project team, but just imagine if those four outstanding developers were all contemptous towards each other. Remember the key to project development is the interaction of those resources.

Quality Redefined

In an ever-increasing world of technology, how do we know the products that are being delivered are driven by quality? As we move towards metrics-based solutions to understand the quality of our applications, how do we know that the measurements are accurate? As Six Sigma and Lean Thinking migrate from manufacturing to services, what benefits to quality are assured? Or suppose we adopt Agile Methodologies, how can we use this new guidepost to build better, faster, cheaper applications?

Is it reduced defect count, more lines of code, an elegant solution, or maybe all three in combination that provides quality?

Taken from an analogy by a much smarter gentleman than I, assume that we have a world without quality. This world would be a bland, non-descript, boring life in which we would simply survive. Rice and perhaps corn or potatoes would be the only food products available. In IT terms, ‘hello, world’ would be the only program that existed.
So…from that vantage point, every application has some quality, but how do we know if it’s enough?

My solution is simple. Let’s redefine quality and see where that takes us. Let’s rename quality as care.

Now, we’ve taken down a turn that moves us from the hard corporate measurement culture to one more personal. Can we reconcile the two? I hope so; otherwise technology for technologies sake may get the best of us. Let me explain with two truths of quality.

• Quality is the interaction between subject and object. In the case of IT, it is the creation of a line of code, database table, or screen design.
• Quality is nearly always understood and gauged at first glance.

Next, we need to learn to generate care in our team. As we move to this new definition, it moves us closer to romantic than classic terminology. This illustrates part of the struggle between the developer (romantic personality type) and tester (classic). To generate care, three key items are essential:

• Pick the right people

This, as many others have argued, is the key step to creating care in your organization. Key questions can easily differentiate those that truly care about their work versus those that got into IT for a quick buck. What types of journals do you read after work? What did you enjoy in your previous job/college? You’re looking for motivation and ability. If they have both, then you’ve picked a superstar. Always ensure that your best programmer gives them the thumbs up and that they excelled in something pre-career at your organization.

• Prime them

Once they’re in the door, it gets easier. Now it’s time for you (PM) to engage them fully. Remove roadblocks (the DBA won’t listen to my tuning suggestions…), listen, and most of all stimulate them through empowerment. If a developer doesn’t feel a sense of ownership, it’s game over and you may as well move to a new career, because you’ve failed. This stimulation should be transparent to the developer. As another stellar writer said, use psychology to keep their motivation alive. This requires keeping a positive attitude and outlook. Primer words will always create positive subliminal outcomes for the team. If you can’t do this, perhaps it’s time to move on…

• Maintain their identity

After they’re in the door and primed, it’s a maintenance process that is required. This next step will move the developer into a lead. Never be afraid that your position will be lost by hiring and maintaining the best staff possible. Remember, once you’ve worked yourself out of a job, the next position will be waiting for you. If you feel uncomfortable in this role, then go straight to jail and do not collect $200.00.
We’ve gotten a bit off track of the quality issue, but we should delve into why developers are so difficult to gauge by ‘scientific’ measurements. The quality developer will never feel that his code has bugs, but we all know that defect-free code is impossible. The quality tester will always know that he can find a bug in any program. So, how do we ensure a quality project? The answer is simple if you have quality on both sides of the fence. I know what you’re thinking, this won’t happen in my organization, there’s only so many good people to be hired, my hands are tied because the organization requires me to off-shore testing, my boss won’t fire the lackadaisical programmer on the team…. STOP. If the ‘bad’ people are already in the door, then your job just got more difficult. Remember, everyone wants to do a good job; you just have to find out what that is.

Ok, so how do we measure then? The answer is that it doesn’t matter. Hire, nurture and maintain care on your team and the customer will find it. If you think I’m full of it, then look at your team closely to determine whether they care. If they don’t, then fix it. If they do and you still aren’t providing quality, then let me know because it will be the first…
So…given that it’s difficult to measure the quality of an application, except by feel, how can we ensure that future applications will generate a similar amount of quality? It’s actually fairly simple. Maintain, maintain, maintain. Ensuring that your team will continue to care about the team is not a given. You must continually reinforce their belief structure. Not an easy task and one that is worth a view into later.

We’ve looked into how to hire, generate and nurture care, but how do I know if it’s gone? Lots of words could describe it. Carelessness, lack of attention, boredness, lack of motivation…. But, most of all would be contempt. Success breeds success, but always be on the watch for contempt. A simple word with a powerful effect that can kill your team.