Resumes: Views from a hiring manager

I’ve been fortunate to grow a team significantly in the last year. To achieve this, I’ve had many screenings and interviews. This process led to the following observations.

Focus your skills list
Just because you programmed in Prolog twenty years ago doesn’t mean it belongs on your resume. I am put off by a resume that list dozens of languages, operating systems, and tools. It leaves the impression you can’t self-assess your strengths. Secondly, it doesn’t allow me to determine the technologies you actually know well.

You might say, “I list my skill level for each technology!”

Strike two.

Can you really say that you are 4 out of top level of 5 in C#, C++, Java, Perl, Ruby, PHP, SQL, OOP, MVVM, MVC, M-I-C-K-E-Y M-O-U-S-E, Agile, and Waterfall? Yes, I’ve seen this type of listing repeatedly. No they didn’t get a call.

Anything you put on your resume is fair game. If you haven’t used something for years or you have only dabbled, you won’t discuss it well. That can only hurt you. If you list something in this category, acknowledge it was a while ago. And rehearse why you still mention it.

Highlight strengths
List your strong skills that match the job for which you are applying. Eliminate everything not relevant to the job description. If I’m looking for .NET C# with Visual Studio, then Java with Eclipse isn’t necessarily going to help. There is an exception.

If you have substantial domain experience (e.g., Healthcare), then highlight it. Domain experience is often more valuable than technical skills. In this scenario, drive home the domain experience while acknowledging that you used different technology.

Demonstrate that you understand the external environment and are self-aware regarding your technology skills. Then highlight (through examples) your ability to acquire new skills and obtain a level of excellence with them.

Closing thoughts
Tune your skills list to the job description. It is better to identify a few skills you know well than to dilute precious interview time on average or weak ones. And remember, knowledge of languages and tools isn’t the only deciding factor for hiring someone. Your attitude about learning and passion for software are as much a factor as experience and skills.


Be ruthless with what you put on your resume. If you don’t, I will.

Giving Feedback

One management skill I have found essential is giving feedback. Here are a few tips I have learned about giving feedback.

Don't be afraid
OK, this may seem obvious. Lets face it - giving feedback is awkward and hard. I think this stems from an innate desire to be liked. If you have to give corrective feedback, you run the risk of making the other person mad at you. Or hurt.

There aren't many things I can tell you about this. Well, actually there are *tons* of things I can tell you about, but that's not the point of this post... I will say this - don't own your employee's response. If you follow these guidelines you've done your part. If they are angry, hurt, or anything else - that is their feeling to own. Wow - I feel like I should be asking you for a therapy co-pay...

Give feedback as close to the event as possible
If someone is out of line at a meeting, call them out in front of their peers (if it is warranted) or pull them aside privately after the meeting. This is a delicate balance. The general rule is criticize in private. However, if someone crosses a line publicly, address it immediately.

It is important your team knows you won't tolerate this behavior and that you are addressing it. Of course, if someone is so out of line publicly, you probably have another issue...

Give feedback from the heart
Wow - can I get more touchy feely? Maybe not.

The point is to have your employee's best interest foremost in your mind. You have to care about your employee. Show her you are concerned for her professional growth and relationships.

There is a saying that "feedback from the heart penetrates the heart." I believe this. Your employee will sense if you are jumping on them to make a problem go away or if you are sincerely trying to improve their character.

Make sure you aren't angry when you give feedback. Think through why you are giving feedback.

Is it to show someone you have authority? Is it to feel better because you felt wronged?

Or is to help someone who is struggling to get better?

Be direct
Early in my career, I found all kinds of reasons to delay getting to the point. That doesn't work. I've found it best to be direct, factual, and brief. That last point is important.

When you are nervous, you may tend to keep talking. That dilutes the message. Your job is to provide feedback, not debate. If your employee makes excuses, listen but redirect him. Let him know you understand his point but see things differently. In other words, don't buy into the drama.

Offer alternatives
Mature employees may ask you what you would recommend they do differently when confronting similar situations. Be prepared to offer alternatives. Help them role play alternatives so they can build new coping skills.

If you prepare in advance, you will have empathy with their situation. You will be forced to consider their position. I've often found myself softening my position when I realized my employee's actions were not malicious.

Giving feedback can be daunting. If you approach it with the intent to improve your employee, you'll be fine.

Don't avoid giving advice. It will get easier over time.

So you want to be an architect

Over the last year or two, I’ve spoken with a handful of developers about their career. Several of them desire to become software architects. I’ve never really been satisfied with my guidance to them.

With apologies to them for my poor initial responses, here are attributes I look for in an architect.

Be a coach and mentor
You might think technical excellence should be the first item on my list. While it is a requirement, it is not sufficient to be an architect. What matters is one’s ability to coach and mentor others to higher levels of achievement. A highly technical individual who cannot coach and mentor is not an architect. She is a highly technical individual contributor.

Architects build large systems through a team. So while the architect may be the most technical, he must maximize the output of the team as a whole. Some examples of coaching and mentoring:

• While reviewing other’s work, look for opportunities to praise good practice and to demonstrate improvements in critical thinking skills. It’s not about showing a better way to implement a specific module. Use the opportunity to teach a better way to think about the problem and possible solutions.




• Share your knowledge with the team. Use every opportunity to share not only your technical decisions, but options you considered but eliminated. Help your team understand how you made the decision, not just what the decision was.




• Expect your team to have great ideas. You don’t have to be the smartest all the time. You cannot expect your team to be willing to learn from others if you won’t.

Desire to learn
The best architects learn constantly. One monitor has Visual Studio open and the other has a blog about some piece of technology.

Take time to read, study, and practice.

I’ve known architects who spent personal time developing programs to exercise one or two language features. They may not need it immediately, but at some point they encountered a problem that feature was suited for.

Architects learn from everyone. That includes business folks, QA, developers, and their leadership team.

Experience
There is no substitute for experience in architecture. I’ve run into twenty-something developers with architect titles. I find that laughable. Experience brings diversity of challenges, solutions, technologies, and business contexts. It also brings time to have studied under other architects and senior mentors.

You don’t have to have had many jobs and worked on dozens of systems. An architect must be exposed to a multitude of problems to solve. Each challenge faced and solved adds a tool to be used for the next problem. It provides maturity and confidence required to push through hard problems and solve them.

A senior developer may master many software engineering technologies. An architect combines this basic requirement with coaching, personal desire to learn, and experience.

An architect brings these elements together to solve new challenges. In this process, the seeds are sowed for new architects to be developed.

On a personal note, I want to thank architects Mary Holstege, Andreas Guenther, Derik Whittaker, and Roger Larson. This article is merely a summary of what separates these folks from the rest of the bunch.

People over technology

I just returned from the largest healthcare technology conference in the world, HIMSS 2011. There are hundreds of vendor booths ranging from a 10 foot table to city block sized two story complexes. It seemed everywhere I turned I was told that if only my doctor had an iPhone or tablet, patients would be healed faster, medical mistakes would plummet, and hospitals would recoup more money.

There was so much technology that I found myself forgetting a basic fact. Healthcare is about healing people. And those that do the healing are people.

I didn’t recognize how little I thought about patients until I put my girls to bed tonight and began reflecting on the show. Then it hit me.

Every good and rewarding memory from the show involved people, not technology. It was the joy of being greeted with genuine fondness by former executive leaders. It was the smiles and embraces I received from past colleagues. And it was the tears when I ran into a prior customer as she turned a corner and I received the biggest hug of the entire event – and her kind and exaggerated words of thanks for the years of being a trusted partner to her organization.

We are here to apply technology so our customer’s lives may be people-centered, not gadget centered.

Regardless of your industry, remember that there is a person on the other end of your solution. Start with them and let their needs, their goals, and their hopes drive you – not the technology.

One final story.

I visited a hospice customer several years ago. After a day of IT, finance, and CIO type discussions, they asked if I’d like to tour their inpatient hospice unit. If you aren’t familiar an inpatient hospice unit, it is a place where people come to spend their last days. The average stay is measured in days, not weeks.

It was sobering to be shown a typical patient room. By itself, that would have altered my view of my product and my role in leading the team developing it.
Then I saw the computer screens at the nursing stations with my application running. At that point I could trace a path to the choices I made daily directly to the patients who were in this unit dying. It ceased to be about technology. It became a quest to build something that would allow my users (nurses) to do their job better (help people die with dignity).

Don’t lead with technology. Listen, observe, and seek to understand. Next time you find yourself getting enamored with new technology, don’t forget to ask yourself what difference it is going to make in the lives of your users.

What-if-itis

I've discovered a potentially fatal disease that can severely damage all or some of a software project. Initially it seems benign. You don't notice it at first, since it appears as a helpful set of behaviors: caution, thoughtfulness, building robustness, and many others.

After a while, you notice that your team's ability to decide and produce software has slowly eroded. Before you know it, you have succumb to this disease.

Your team has contracted what-if-itis.

Symptoms
Symptoms include team members introducing scenarios, new technologies, and arguments proposing overly-complex solution to problems that may never occur. Here is an example of how the disease presents.

Someone on the team will (in all sincerity) raise an issue about the application usage. Something like, "What if a customer buys 1,000 different books at once?" Everyone may start out looking around at each other saying, "Wow 1,000 books *would* bog down the shopping cart. We ought to think about pagination, implement some client side caching to avoid server round trips, and..."

Curing Sudden Onsets
Acknowledge the input but gently ask the team, "Is anyone really going to buy 1,000 books?" And if someone did, how frequently would it occur? In other words, yes, this scenario could happen. But is it worth spending precious effort on it?

The easiest and fastest way to rid yourself of a sudden onset of what-if-itis is to get business stakeholders or customers to validate or refute the scenario. Even here you have to be careful. Don't ask if the scenario is possible (it is). Ask:

• How frequently would this scenario occur?
• Under what circumstances?
• What type of user would typically perform this task and towards what goal?

Depending on your relationship with sales, you could also add:

• Would handling this scenario win more sales?
• Would not handling it lose customers?

Once you have answers, you should have a good sense of whether this is worth addressing or not.


Immunizing your team
There are several things you can do to immunize your team:

• Educate
  Educate your team on the domain, the users, and their goals. If the team knows your website is intended to sell books to the general population at a competitive price, then the 1,000 book scenario will be understood immediately as unlikely. Without this knowledge, a team member could legitimately wonder "What if a librarian came along looking to do an annual purchase or to stock a new library?"
• Keep a backlog
  When what-if-itis strikes, "quarantine" it to your project backlog. Your goal is to understand quickly whether the scenario is realistic or not. People often fight for it because they think it will get ignored and cause harm to the product later. Having a backlog assures people that their concern will later be addressed or shown to be outside reasonable system expectations.

The key is to reduce or eliminate the amount of what-if-itis. When it occurs, move quickly to validate it or move it to the backlog. The damage occurs when resources are diverted to researching, designing, and building software for scenarios that may reasonably be considered to be outside normal system usage.

One final consideration. Your market and your customers are the final arbiters of normal system usage. What you may find outside normal system usage may in fact be a very real scenario that your customer faces infrequently, but that you have to handle with elegance. Unless you are highly certain, engage your customers.

Getting Change Done

I am responsible for helping set strategy and direction. When I change current direction, the change may be a little. Or, it may be a lot. The greater the change, the greater potential for angst among the people impacted.

No executive wants to cause her team additional stress. On the other hand, no executive wants to maintain status quo and allow his business to fold. Navigating this tension is difficult. Here are a few things I’ve learned along the way to ease (but not eliminate) this tension.

Start doing, stop talking
Once you know the direction you want to go, start walking. Planning is needed, but not at the expense of learning. You seldom know how things will turn out, so begin to execute and make adjustments. Plan enough to get you started and to share the general direction and goals with key team members. That may mean a few hours or a few weeks – that depends on the scope and magnitude of the strategy to execute. Here are some recommendations:

• Encourage key team members to find the quickest items to start executing, as well as defer everything that doesn’t need to be known immediately.
• Reinforce to them you aren’t looking for perfection and you expect adjustments to be made continually along the way.
• Lay out significant milestones and ask for a plan to achieve them. They own the plan (how); you own the results (what).
  

Stay focused on the storyline, not the sentences
I recently worked with my team to deploy a new (to us) suite of development tools. Do I agree with every configuration and option the team selected? In honesty, I can’t answer the question because I don’t know every configuration and option the team selected. I am pretty sure if I reviewed every choice, there are things I would do differently.

That doesn’t matter.

What matters is that the tools are deployed effectively to increase the efficiency of the development team. In other words, allow the team to determine how the change is implemented. The message to the team is twofold: I trust you to make good enough (not perfect) decisions and I trust you to make course corrections as needed.

Acknowledge the team’s discomfort
It is normal (and part of being human) to feel anxiety and excitement simultaneously during changes of direction. Knowing that feeling frustrated and anxious is normal won’t stop the pain, but it is enough for most people to help them get through the change.

• Be there to help them work through the initial angst. When the first set of people emerge “on the other side”, enlist them to help bring others across.
• Remain firm that the direction is not negotiable (keep in mind if you really blew it, then of course redirect – for now assume your direction is appropriate). Some people may continue to resist, but strangely, knowing that you are committed is reassuring to them.

In the end, How much is too hard to push? If you are moving people out of their comfort zone, then aren’t you making them uncomfortable? And is that bad?

These questions have been buzzing around in my head for years. I’m not sure there is a right answer. More than likely, there isn’t.

Coding a Mile in Someone Else's Market

It is easy to look at legacy software systems written by others and criticize the design and implementation. I'm not proud to admit it, but I've done this myself through the years. Time and experience have allowed me to appreciate the difficulties inherent in building software in an ever changing world.

Consider 10 years ago.

What technology were you using? We had just come out of the Y2K scare, the web was still about "eyeballs", and Silverlight and the iPhone were years away. You had Java as your main option for writing web applications (which I'm not sure were called web applications).

Were the applications written then bad because they aren't using Entity Frameworks and Service Composition? Of course not. Smart people were using the latest and greatest patterns (Gang of Four, anyone?) and practices (eXtreme Programming).

It is interesting to approach "legacy" applications from a historical perspective. What was the state of technology when they were written? What was the state of the market they were serving? How has that market changed over time?

You may find it interesting that these are the same questions you ought to be asking about technology, your application, and your market today.

The bottom line is this: It's hard to write software. Period. You have to handle today's problem. You have to anticipate what the market may need in the future. And more often than not, you are tied to customers who are using your current product.

Instead of re-writing an application, consider extending it by adopting newer technologies for new features. You may have to write some adapter code, but that may be easier than re-writing a bunch of functionality that works fine today. For example, I managed a project that integrated C# WinForms into a Delphi application. We extended integration and other processing by surrounding the core Delphi engine with .NET web services. We saved a lot of time not re-writing and regressing testing code that worked.

I'm not saying don't rewrite applications. What I am saying is that you should make sure you are doing it for sound business reasons, not just to move to newer technology for the sake of new technology.

Keep this in mind: That hot Silverlight application you are writing today will be someone else's legacy application in five years.