I want to hear about problems, not solutions

What!!??

Ever heard the phrase “I want to hear about solutions, not problems”?  Executives, managers, consumers of services, and users of software use the phrase when all they want is for a problem to get solved, among other reasons. Software developers should only use it when filling one of those roles, even though you should avoid it to prevent an unsolvable problem from rising to the surface. Software developers provide the solutions to problems. They should approach their interactions with users, and sometimes our peers, as “I want to hear about problems, not solutions.”

Several times in my career, business owners and technical peers approached me to present several solutions for unclear problems. I’m guilty. I present my share of solutions without clearly stating the problems they intended to solve. In many cases, the solution presented did not solve the problem the presenter intended to solve. In others, the presenter’s authority or tone gave no option to developers for inquiring about the problem in order to find another, perhaps better, solution.

As a software developer myself, I want to hear about problems, not solutions. Every feature request, bug, improvement, etc. presents a problem someone needs to solve.

I’m not suggesting anyone use this statement as a challenge. The “solutions, not problems” phrase is typically used to eliminate excuses. Software developers should professionally inquire about the problems a presented solution intends to solve. We owe it to our users, managers and executives to do this… it’s what we, as software developers, are paid for.

Focus on problems before identifying a solution. When you start to identify a solution, think and/or find out about other similar problems that might exist. Evaluate those against your solution. When you’re done, restate your problems when you present your solution.

P.S.

I wrote the article above on an internal blog at my old my old place of business minus some minor editorial adjustments. At the end of last month, Coding Horror included a couple of posts on a similar subject. The first said the following that triggered me to thinking about this post again.

Users often don’t know what they want, and even if they did, the communication is likely to get garbled somewhere between them and you.

Hiring – Do I Have To?

After starting my new job, I figured out one thing right away; pretty soon I would be hiring some people.  Of all supervisory responsibilities, I hate this one the most.  The decision makes the biggest impact of any other decision you make as a supervisor.  Not that the decision itself is difficult.  Once you find the right person, the decision is actually easy.

The hiring process itself is very time consuming.  Unless you are very lucky, you have a backlog of work, which is the reason you’re hiring.  I’m not lucky.  You have to decide what work can wait, and who to risk making angry, so you can review that stack of resumes, conduct phone screens, schedule interviews and take the time out of the day to hold the interview.

In order to keep myself motivated to do this task, I need to make it routine.  I tend to gravitate to more interesting tasks unless I do so.  For me and many others the process involves:

• Preparing the Job Description and Salary Requirements
• Preparing a phone screen questionnaire
• Preparing a list of questions to guide the interview
• Marketing the position, i.e. post it to Monster, Jobing.com, local lists, etc.
• Review the plethora of resumes sent after the posting hits the streets
• Conducting the phone screen and, hopefully, scheduling an interview
• Conducting the interview, preferably in person
• Extending an offer

A job description and salary requirements are pretty straight forward, since I know exactly what I want the person to do.  But there are a couple of other parts of the process…

Reviewing Resumes

After posting a position, you immediately encounter an influx of resumes.  In this instance, about 90% of the resumes were worth reviewing.  I consider myself lucky on this particular posting.  On other postings, I have received 100’s of resumes where 5 have been worth call backs.

I fail to understand how someone can submit a resume to a position with no regard for the responsibilities and skills requested in the posted position.  I received a couple of resumes this time where there candidate discussed no technical skills.  Do these people think wasting my time will gain them employment?

One of the resumes I received for this position had a clever format which I hadn’t seen before.  It had a 2-column layout with “skills you require” on one side and “what I have to offer” on the other.  At first glance, I started to get excited.  This format was cool… until I read into it a little.  The guy did not bother himself with actually listing the skills required from my job posting and responding to them.  The skills required column was filled with phone sales skills, for a technical support representative position.  More of a waste of my time… and stupid.  Nice way to make an impression.

Phone Screen

Many people have written about the importance of a phone screen.  Jeff Atwood wrote about it at a very convenient time; right at the time I was preparing the job description.  As he mentioned, getting this wrong can be a huge waste of time.  Getting it right makes the most of it… important since I dislike this process so much.  Not that I have made the most of this prior to this job, though.  In some cases, where you are using a recruiter, you assume they’re doing it for you, even though they probably aren’t.

Scripted Interviews

I worked for a couple large companies that required a standardized interview process.  The process intends to create a fair interview process by treating all candidates the same and, subsequently, fairly.  The problem with this is not every candidate is the same.  I experienced a large variation of responses to one particular “script.”  Most of these relate to time.  It amazes me how the same “scripted” interview can take anywhere between 10 minutes and 1 hour to complete.  This particular scripted interview was not done in conjunction with a phone screen and resulted in a lot of wasted time.  The most memorable interview involved a person who clearly should not have been there.  The interview took approximately 10 minutes.  When it was complete, the interviewee practically ran out of the room and through the secure work area, just trying to get away from me and the other interviewer.  Even though we were expected to escort her out of the secure area, we could hardly keep up.  We know the “script” was not to fault, because we hired several other people with the same “script”.  That didn’t stop us from evaluating that script before the next one.

I learned something from the stodgy old script, though.  A script of interview questions help frame and organize the interview, so I still use one.

Extending an Offer

After conducting our interviews and choosing a candidate, I quickly realized I never extended the offer myself.  I was always going through the other steps of the hiring process and handing it over to a person to extend the offer.  I headed for my trusted browser and fired up Google to help me with this.  Turns out actually extending the offer is not difficult.  Waiting for the candidate to respond in either acceptance or refusal was painful, though.  After a misfire, we have a new employee starting on Monday.  Whew!  Now I’m just waiting for the next couple of openings to get approved.