What to look for when interviewing a candidate

Posted by mikeberry | Agile Executives,Leadership,Product Owner,ScrumMaster,SDLC Management | Thursday 21 February 2008 10:56 pm

My sister was recently promoted to manage a team of software project managers for a large bank on the East coast.  She told me she gets to hire someone for the first time in her career.

I told her that hiring is always a bit of a dice roll, but I offered her some advice after having hired about 15 people at various times in my career:

1. The most important indicator of future success is past success.  Good interviewers know this.  Dig into people’s past work experience and try to find out if they have been generally successful, or not.  Some indicators of this are whether they have changed jobs often.  If they jumped jobs on their way up the ladder of responsibility, this is OK.  If they jumped sideways, or sometimes down, this is a red flag.  Drill them about each job change.  You will get interesting results.  People will say they were fired, or had fights with their boss or coworkers.  These are usually not your desirable candidates.  If they fought with their previous peers and managers, chances are they will fight with your group also.

2. Look for enthusiasm.  Enthusiasm is a great sign of a star employee.

3. Examine their personal lives (you really can’t do this in an interview).  But whatever they tell you can be a clue as to how they respond to accountability, pressure, authority, and responsibility.  If they hate police, or the government, or have been divorced five times, then they may have issues with authority or responsibility.  You have to be careful here because you cannot descriminate.

4. Call their references and ask their references if that person was successful, and if they would re-hire that person.  Ask how socially distracting they were inside the workplace, and what time they came in the morning and what time they went home.  Ask if they were a good team-member, and if they were typically dependable enough to get things done.  Ask why they left and compare their answers to the candidate’s explanation.

5. Because software development is not always a 9-to-5 job, a good question to ask is if they have any extra-curricular activity that would prohibit them from staying late if needed.  I have hired people to discover that every day at 5:30 they need to pick up their kid from daycare.  This obligation makes them incompatible with leading a team that may require them to stay late and fix a critical problem.  This is a good thing to find out before you hire someone for a position like that.

6. Try to get them to express an opinion about something business related and that they are passionate about.  Pay attention to how they express their opinion.  Do they express themselves dogmatically, as if their opinion is fact and you must argue with them to object, or do they express their opinion in a collaborative way, where they would be more of an asset in a group discussion where others may disagree.

7. Pay attention to how they show up for the interview.  Are they on time, and dressed for the part.  Did they bring with them a copy of their resume? Are their shoes shiny?

8. Ask them several obvious question about your company to see if they did any research before the interview.  Find something on your website homepage that they would know if they looked there before the interview. This is a clue as to their proactive abilities.

9. Pay attention to how they describe their previous workplace, management, and executive staff.  This will likely be an indicator of what they will think of your staff.

10. If you sense an extreme level of dissatisfaction, high-maintenance, or lots of questions about what’s in it for them—beware!  This is an employee that will likely perform the bare minimum and be unnecessarily needy.

There are lots of books and tips about how to be the interviewee, but not so much is written about how to interview.  I wish I could have read these tips years ago when I began hiring people.  I hope this helps others and I would be interested in hearing what readers have to add.

Mike J. Berry
www.RedRockResearch.com

Book Review: The 360 Degree Leader

John C. Maxwell’s book,  The 360 Degree Leader, is an excellent field-guide for navigating the challenges of leadership at all levels of an organization.

Maxwell starts his book by dispelling many common dysfunctional myths that are found at line-level, or middle-level management.  Ideas such as “When I get to the top, I’ll be in control,” and “If I were on top, then people would follow me” are inaccurate adolescent attempts to understand the true nature of leadership–which is influence.

Maxwell continues by explaining the characteristics of influence:

  1. Position – Influence because people have to follow you.
  2. Permission – Influence because people want to follow you.
  3. Production – Influence because of what you have done for the organization.
  4. People Development -Influence because of what you have done for them.
  5. Personhood – Influence because of who you are and what you represent.

Maxwell gives examples of effective leadership in all directions: up, across and down.

To lead up well, he suggests you lighten your leaders load, anticipate your leaders needs and use their time wisely, and invest in Relational Chemistry–get to know what makes your leaders tick.

To lead across, Maxwell suggests you focus on completing your fellow leaders, instead of competing with them.   Be a friend, don’t pretend you’re perfect, and avoid office politics.

To lead down, Maxwell suggest you develop each team member, place people in their strength zones, model the behavior you desire, transfer the vision from above, and reward the results you desire.

Overall this is a good book worth reading and re-reading every so often.  I recommend it for managers at all levels.

Mike J. Berry
www.RedRockResearch.com

Book Review: Integrating Agile Development in the Real World

Hooray, another book on Agile Development!

In Integrating Agile Development in the Real World, Peter Schuh explains in depth how to get your team to adopt the Agile Development Model.

Schuh covers several Agile Metholodogies including the problems to watch out for during the process.

I do have to say, this book seemed like a “whole bunch of everything” and so I didn’t feel, after reading it, that I was really any more informed about Agile Development.

I would recommend the book for a group just being introduced to the Agile Development Model.

Mike J Berry
www.RedRockResearch.com

Book Review: The Five Dysfunctions of a TEAM

Posted by mikeberry | Agile Executives,Book Reviews,Leadership,ScrumMaster,SDLC Management | Thursday 15 November 2007 6:07 pm

In The Five Dysfunctions of a Team: A Leadership Fable, written by Patrick Lencioni, he discusses–well, five dysfunctions of a team.

Lencioni’s style with his books seem to be a sort of fable-story-type narrative in the first part, and then real meat in the latter part.  I have to confess I skipped about half of the fable stuff, but found the meat at the back to be very interesting.

The five dysfunctions he examines are:

  1. Absence of Trust
  2. Fear of Conflict
  3. Lack of Commitment
  4. Avoidance of Accountability
  5. Inattention to Results

Being a single guy, I could most readily identify with #3, Lack of Commitment.  And the more I think about it, all of these dysfunctions could be more-or-lesss applied to dating.

His book comes complete with a team-assessment worksheet, and directions on how to identify and overcome these five dysfunctions.  A good read for any manager.

Mike J Berry
www.RedRockResearch.com

Meetings? We don’t need no stinkin’ meetings?

There seems to be no set standard for development meetings.  Some groups complain about being ‘meetinged to death,’ while others complain about a lack of communication, direction, or group cohesion.  Given the two options, it is generally agreed that overcommunication is much better than undercommunication.

One of the more innovative approaches to cutting down on meeting drain is the concept of the ‘stand up meeting.’  This is were all participants (except maybe senior citizens) stand for the duration of the meeting.  Amazingly, during this process, nobody seems to have long weekend stories to tell the group, and answers and discussion points become more concise.

Normal development meetings ought to serve the following purposes.

  1. Communicate transparency from development to corporate.
  2. Communicate direction and prioritiziation from corporate to development.
  3. Communicate present-status and next-step planning regarding a project.
  4. Promote team-workload communication among team-members.
  5. Six month employee review.
  6. Deployment rehearsal.

More on these later…

Mike J Berry
www.RedRockResearch.com

Improving Accountability Within your Development Department

Posted by mikeberry | Leadership,Product Owner,Project Management,ScrumMaster,SDLC Management | Wednesday 31 October 2007 12:03 am

Many Software Development Managers find their way into the “coveted” position from atrition after being a development team lead, or senior architect.

Having a technical background is an obvious advantage in terms of understanding the complexity dynamics the team deals with.  One big reality, however, is that these vast technical skills are only a subset of what is required to become a great manager, and the new manager soon discovers he needs to learn much more about the role.

In Jack Welch’s book Winning, he explains that being a good leader means you shift the focus from you to them–from being the only one able to solve the latest problem, to being the proverbial “dumbest person in the room.”  Accountability should come hand in hand with empowerment.  Learning to empower your teams can be difficult, and seem like a leap of faith at first.  You soon learn, however, that letting your team originate the solution, predict the schedule, perform the work, and solve the problem builds their trust in you and in themselves.

Another effective technique is to make your team accountable to the executive staff themselves–in person–instead of you being the go-between, shielding them.   Have the team leads accompany you to the Executive Committee meeting to report their progress.  This way, they can feel a sense of accomplishment for their victories, and feel the pressure from the top, instead of from you!  Teach them to be commitment oriented.  Develop a commitment-oriented culture by keeping track of their commitments and holding them accountable for each one.    Base their bonus structure on their ability to keep their commitments.  This will teach them to be more accurate, which translates into better predictability that that is better for everyone.

Joel Spolsky has a simple solution for this.  It’s called Evidence Based Scheduling and you can read about it here.

Mike J Berry
www.RedRockResearch.com

The Role of the Development Manager

Posted by mikeberry | Agile Development,Agile Executives,Leadership,Product Owner,ScrumMaster,SDLC Management | Tuesday 30 October 2007 11:47 pm

I remember my grandmother explaining what it was like to teach grade-school.  She said to be a good teacher, you had to be part teacher, part nurse, part referee, part coach, part police officer, part mother, and part collections agent.

Fortunately, software development management requires a smaller skill-set.  Software Development Managers really have four areas of responsibility.  These four areas are:

  1. Responsibility to the corporation
  2. Responsibility to the development department
  3. Responsibility to the customer
  4. Responsibility to the product

To the corporation, the development manager owes efficient yield,  predictability of delivery dates, and transparency regarding the health and status of each project.

To the team, he owes corporate transparency (what goes on in the executive meetings), clarity of direction, priority of tasks, empowerment, and accountability.

To the customer, he owes the highest reasonable product quality, and highest reasonable product relevance.

And to the product, he owes the best tools, architectures, and programmers he can find.

Mike J Berry
www.RedRockResearch.com

Why should Corporate Strategy be important to us in Development?

We code, right!?  We code, and play Warcraft.  Why should we know or care about corporate strategy?

Well, the answer is that most programmers probably don’t really know what their organization’s corporate strategy is.  If you do, you likely have an outstanding manager who has learned that part of their responsibility as a manager is to communicate executive directives back to Development.

A company that performs good ‘Strategy Management’ will do two things:

  1. They will broadcast their corporate strategy to all employees so that everyone can be on the same page.
  2. They will establish measurable metrics throughout the organization to determine how close everyone’s efforts are to the decided strategy.

When this happens, an effective plan is for the Development department to adopt their own ‘Department Strategy’ that supports the Corporate Strategy.  Then look for ways to measure how effective they are at pursuing that strategy.

For example, if your team has to report total hours for the week, reporting could be enhanced to include how many hours each programmer spends on each project.  Then each project can be placed into separate ‘strategy categories.’  Then, time can be measured for each project worked on during the week, and a summary comparison can be presented to upper management showing that the Development department is ‘following corporate strategic goals’ by spending a proportional amount of time on projects that are aligned with various corporate strategies.

If you are a manager and do this before you are asked to, you may even earn yourself a few stripes.  Kapish?

Mike J Berry
www.RedRockResearch.com

« Previous Page