Monthly Archives: February 2014

Change the testers hiring process

Leave a comment

Current process: The typical questions were “What tech do you know?” “Do you know these tools?” and not much more than that. If someone got along with the interviewer and his answers had been adequate or better, the company would extend an offer.

My observation: I looked at the good testers around me and tried to identify the “whys” of their success. All of them were driven to learn and capable of adapting to change. If they didn’t know a tool or a tech, they learned it. Because under the hood, testing is learning and relearning software everyday. The following are seven changes I made to my interviewing process.

Change One: Stop Asking Tech and Tool Questions First
It’s much more important to find the right mentality. My first interview is now mostly personality based. Followed by, how would you test this, where this’is a generic thing— like a vending machine, a trash bin, or a telephone. I leave it generic enough to encourage the person to start out with questions. The best testers ask lots of questions instead of diving into examples of how they would test, questions like “How much time do I have?”  “What resources do I have?” “What is the goal of this testing?” and on and on and on. Good testers are capable of assuming what kind of this it is and break the problem down into good examples of high-level test design and low-level test specifics.

Change Two: Never Rely on Just Yourself to Interview People
You can be biased and ignore glaring errors that others spot. You might have an off day. Maybe you and this person just mesh and you don’t finish your due diligence, consciously or unconsciously.

Change Three: Write a Job Description, Not a Person Description
Testers are a very diverse bunch; what you want someone to accomplish in a job position can be accomplished many different ways. You don’t know ahead of time what specific skills that will require, but you do know what goals you want accomplished by this person in three-to-six-to-twelve months (don’t you?). I’ve found some of my best testers from all walks of life: ex-Microsofters, HVAC repairmen, high-school drop-outs, and mechanical engineers. Figure out what the job description should be and don’t assume what skills you need to get the job accomplished.

Change Four: Put Them In a Stressful Situation
Testing is stressful; your job is to prove to people how ugly their baby is. Give them to a test a small website and find their “most important” bug.

Change Five: Retrospect, Reflect, and Improve!
Finally, keep a record of the people you interview and when. Did they get a second interview? Why? Did they make it past the second interview? Why? Did you make them an offer? Did they accept? How did they do after they’ve been there three-to-four months? Can you make changes to the way you interview to weed out the people who didn’t work out in three-to-four months? Or to isolate the people that are doing awesome after three-to-four months? Interviewing is not a static exercise; don’t treat it as such.

 

Change in Project Manager role

Leave a comment

Summary:

It used to be that a project manager did one thing: manage the success of the project. As IT budgets shrink and job responsibilities expand, there is no such thing as a typical project manager role. You’re expected to wear many hats, facilitate human resource issues, become a subject matter expert, and assist with key technical activities.

“I am managing a team of a thousand employees.” “I take care of five projects with more than six hundred employees.” “I am the program manager for a very big project rollout.” Do all these quotes from managers sound interesting or hollow to you? Statements like these may have been exciting a few years ago, but not these days.

I am playing the role of risk and mitigation manager in a SAP rollout project for a major retailer. I am the performance test architect in a core banking migration project for a bank. I am playing the role of test consultant for an insurance client who just recently acquired two other insurance companies. I am the cost optimization manager for a global securities client.

Should a project manager play the role of coordinator and people manager? With multiple technical and domain roles, it is easy to see how my original focus as project manager became diluted.

A Guide to the Project Management Body of Knowledge, or the PMBOK® Guide, defines project management as identifying requirements; addressing the various needs, concerns, and expectations of the stakeholders as the project is planned and carried out; and balancing competing project constraints, such as scope, quality, schedule, budget, resources, and risk.

Take a typical IT program and check out how many managers are performing an extraordinary number of disconnected tasks. What benefit are they providing in controlling scope, schedule, and budget? How effective are they in managing quality and resources? Is there any available time to effectively plan for project risk and risk mitigation? By dividing time among several concurrent projects, is the role effective in an agile environment? And because most of us in project management come from technical backgrounds, do we still have responsibilities to perform technical tasks as architects, consultants, domain experts, and quality auditors?

Due to the complexity of projects in terms of size, new technology integration, cloud, performance, and security, there can be multiple managers taking projects in various directions.

Especially in the agile environment, these responsibilities are shared with team members who are expected to scale up.

Assuming the traditional definition and responsibilities of a project manager, the role is independent of specific technologies employed in the project. It is very difficult, however, to manage a team effectively unless you are comfortable in the technology or domain of the project.

Can a project management office coordinate all the activities of multiple managers? Do we still need people managers or project managers who manage real-world issues that are simply added on to the already heavy workload of technical managers? Project management roles that do not require technical or domain expertise are rapidly disappearing. The perception is that consolidator or coordinator roles don’t add value to the business.