Michael Lant

Software Archictecture, Development, Agile Methods and the Intersection of People Process and Technology

Agile, Project Management, Software Development, Teams

How To Build A High Performance Agile Team

Altered Reality VI - Pattern against Conformity

High Performance People

“Imagination is more important than knowledge.” Albert Einstein

Software development is an inherently human endeavour. It is not a process (although process helps), and it is not a science (although science also helps). If it simply were a process, then anyone could in a very short period of time learn to do it. If it were a science, you could give the same problem to a dozen programmers to solve and you would get the same results from each of them. Experience tells us that neither of these things is in fact true. If it is not a process, and it is not a science, then what is it? Before answering that, consider that no two software solutions are ever alike – or at least they shouldn’t be. If you find that you are creating a software solution that is exactly like something else that already exists, you should seriously reconsider what you are doing because you are either a) infringing on someone else’s copyright or patent or b) wasting time and money solving a problem that someone else has already solved. Implicitly this means that for each new project you begin, you must “create” a new solution. In other words, you are dreaming up a new way to solve a problem. This means that to “create” a new solution, you need – well… creativity. Creativity is an intangible. It is highly unique to each individual. It cannot be measured and for the most part cannot be taught. We often refer to this intangible as art.

We tend to think of art in a very narrow way. We all know of art in its traditional forms: painting, music, dance, theatre and so forth. Take a look, however, at business, sports, automobile design and many other endeavours and you will see how the very best like Wayne Gretzky, Michael Jordan, Richard Branson,  Steve Jobs and Enzo Ferrari have elevated what they do to an art. Even in traditional sciences like physics, who can deny the inspired creativity of Einstein and Newton. These are just a few of the truly exceptional people the world has seen. They redefined what was possible and the likes of them will never work for you – but not for the reasons you might think. They are the outliers – the ones that don’t fit neatly into nice little packages with items that can be ticked off on their résumés and if you were reviewing their résumés before they achieved their great successes, you would almost certainly pass over each one of them.

Hiring Processes Eliminate The Wrong People

“Insanity: doing the same thing over and over again and expecting different results.” – Albert Einstein

The processes used by most organizations to hire and build software development teams are not designed to find the outliers. They are in fact designed to weed out the outliers and instead create a homogenous mix of sameness. Most companies make their hiring decisions based on some mix of the following criteria:

  • Does the person have a degree
  • Number of years of work experience
  • Number of years experience with a particular tool or language
  • Has the candidate built something like this before
  • Does everyone on the team give the person the “thumbs up” when they interview the candidate

What you have here is a recipe for homogeneity – a soup of sameness where you have unwittingly filtered out anyone who can bring new ideas to your project. You have blindly targeted the middle of the Bell Curve of innovation and have excluded the possibility of bringing fresh new ideas to bear on your project. As well, none of the criteria listed above can in any way be correlated to success either of an individual or a team. All you have is a specious set of criteria that gives you (the hiring manager) a means to cope with the process of hiring and a way to save yourself if the candidate turns out to be a bad hire… “Well he had a great résumé and the team really liked him…”

Hiring top notch people is more important on Agile teams because so much more of the decision making is handled by the development team. They need to make good decisions (not necessarily safe decisions) and they need to devise creative solutions. If you are in a software company, the need to find the outliers and the artists is even greater. You cannot afford to create a soup of sameness.

I have over the years interviewed hundreds of people. I have in turn been interviewed maybe 100 times. It is my experience that very few people know how to interview prospective candidates, and the truth is: why should they? The typical hiring manager has to hire a new employee a couple of times each year. They have no training in how to conduct an interview, what to look for in an interview or how to assess the results of an interview.  So what do they do? They fall back to things they can put in lists and check off and it is likely the same list of questions that was used to assess and hire the existing team members. They then turn to the others on the team (who likely have even less hiring experience) and look for confirmation. How can you end up with anything but more of the same of what you already have?

Stop Hiring Dogs

The fear of things that are different is a tremendous driver for people. I recently attended an Agile Conference where I struck up a hallway conversation with a group of Attendees. I asked the question “On an Agile Team, how do you deal with a super bright architect who simply gets things before anyone else and has that crystal clear vision of what needs to be done?” I was shocked by the response. There were about ten people in the conversation and the comments ranged from “get rid of him – he will unbalance the team” to “it’s all about the team and he needs to go” to the most extreme “cut him out like a cancer.” The reactions troubled me for a couple of reasons: 1. there was an automatic assumption that really bright people can’t participate in a team environment and 2. the nice friendly team atmosphere where everyone agrees on everything was the most important thing. I believe that both assumptions are dead wrong.

A few years ago, I stumbled upon the following article. It was written by Miki Saxon of RampUp Solutions Inc. and posted on the Notre Dame Mendoza College of Business website. The article is unfortunately no longer available but I was lucky to have saved a copy and I am thus be able to share it with you here. I think the article provides a valuable perspective.

A few days ago an executive I’ll call Dan called me to bemoan the lack of creativity in his organization and I told him to stop hiring dogs. He informed me that he had great people and when I agreed, he demanded to know why I called them dogs.

The problem is that Dan hires people he likes, who fall inside his comfort zone, so his organization gets along well. And while it’s well diversified from an HR point of view it has little mental diversity. It’s a happy place, kind of like a dog park with a large variety of breeds and mutts all well socialized to play together and those that don’t play nice are asked to leave. That kind of peace may be good for a dog park, but it can mean death for a company’s innovation efforts.

Unfortunately, people have been moving away from thought diversity for quite awhile now. The attitude has a name, homophily, it’s been around forever and it’s an attitude I run into frequently when it comes to hiring, although it’s rarely intentional. It’s a word you should learn just so you can avoid it. It’s what makes it difficult for Dan’s people to be creative; when something is suggested it’s often accepted with little discussion and even when a counter idea is presented it has similar DNA.

It’s not that Dan needs to toss a bunch of cats in the middle, but he does need to start hiring people that come from a variety of companies and industries, with different experiences and with whom he may not be as comfortable as he is now. It also means that Dan will have to work harder. Not because his people won’t get along, but because diversity of thought does foster exactly what Dan wants—higher creativity.

Creativity means multiple ideas with no common DNA leading to passionate champions, intense discussions and heated meetings. Dan will have to actively manage the various elements if he wants to harness that energy for the benefit of the organization.

Whether you consider yourself a manager, a leader or a manager-who-leads the more mentally diverse your organization, the more difficult to manage, but the rewards are high for doing it well.

How I Hire Great People

When I hire people, I rarely look at their formal education. I find it is largely irrelevant unless they’ve done something out of the norm, in which case I pay closer attention. Richard Branson, Michael Dell, Steve Jobs, Paul Allen, Larry Ellison and Bill Gates seem to have all done fairly well without a university degree. The best programmer I have ever hired did not finish grade 11.

Neither do I look for people who have worked on projects that are the same as the current one – in fact I often specifically look for people who have not. Even better, I look for people who come from different companies, different industries and have worked with different technologies. Why – because I want new thinking and I want innovation. That never comes from doing more and more of the same. I remember debating the VP of a company in the financial services sector who was trying to get a new product off of the ground. He was pressing to have the best, most innovative product on the market. He wanted new thinking, and to get it, he was trying to hire the lead architect from his direct competition who was leading the design of a similar product. I call that irony.

Years of experience is somewhat relevant to me, but more relevant is diversity of experience. My father, who spent decades, managing a data processing department once said about hiring: “So this guy has ten years of COBOL experience. Does mean he has ten years of experience, or one year of experience repeated ten times?” Ten years with a wide range of technologies and projects is far more valuable than doing the same thing over and over again for ten years in a row. How many years of experience with Java or C# did you look for in your last hire, and be honest – how much relevance did it have to the success of the person in his/her new role?

“Truly successful decision-making relies on a balance between deliberate and instinctive thinking.” — Malcolm Gladwell

If you can’t follow the cookie-cutter process that most companies use, then how do you hire great people? In large part, avoid the pitfalls I’ve mentioned and try some of the suggestions I’ve made above, but more specifically, try doing things that will help you to find the people that are different – not the same. I mean finding the outliers. I look for the creative thinkers. I look for diversity – not homogeneity. I look for people who have innovated and who look like they will continue to innovate, and I look for people who can really think. This is a tough thing to uncover, but to do this I ask questions in the interview that place their thought process in the open.

Here is an example:

I am going to give you a list of three things. I want you to put them in order of importance, from most important to least important, and I want you to tell me why. The three things are:

  • Hard work or work ethic
  • Technical aptitude
  • Communication

I repeat the question to make sure it is clear, and that is all I give the candidate. There is no right or wrong answer to the question, but I do not let onto that because I am studying their problem solving process. I want to see how they get to the answer, and I want to know why they got there. I have asked this question hundreds of times and as such, I have been able to calibrate the responses. It is amazing to observe what happens. I’ve seen everything from sheer panic to an answer rattled off in seconds without even pausing to think about it. Others might take a full five minutes to provide a response. What I like to see is the candidates ask questions of me – questions like “is the question asked as it applies to this particular role, or is it a general question as it might apply to the organization?” This demonstrates the person trying to place the question within the right context. Placing decisions in an appropriate context is a subtle, but very important component to the decision making process. One candidate looked me straight in the eye and said “There is no correct answer to this problem is there?” to which I responded “You are correct.” He continued “So what you are doing is trying to see ‘HOW’ I answer the question – correct?” To which I also said “Yes.” He went on to provide a superb answer and not surprisingly, gave a great overall interview. I ended up hiring him, and he was a superb addition to the team.

Even though there is no right or wrong answer to the question, I do have a preferred response. It generally goes something like this:

  1. Communication – Because without a complete understanding of the challenges at hand including understanding customer needs and having great team collaboration, you can work hard and brilliantly solve the wrong problem.
  2. Hard work and work ethic – Because hard work and a strong work ethic will drive you to learn anything you need to accomplish the task at hand.
  3. Technical aptitude –  Although still very important it is lowest of the three because it is the easiest to acquire and compensate for, especially if you have a solid founation in the first two.

Incidentally, the candidate I mentioned above who figured out what I was up to, listed the items in reverse order, but he did so with brilliant reasoning and a hypothetical context that he supplied. The truth is that he was extremely bright, and very creative – one of the outliers I was looking for, and I suspect he was playing me at my own question to see how I would react. He produced great work and it was the art I was seeking.

The best teams I’ve led or participated in have had a very high percentage of the team members that were outliers. To be sure, they were in some respects harder to manage. Sometimes tensions ran high because all them were constantly working the problem-space, but everyone had great respect for each other as we shared and debated ideas and concepts. There was always brilliant work being produced, and the pace at which work was delivered was often astounding. These teams were fun and stimulating to work on because each member was continually raising the bar with innovative ideas, and thus challenging the rest of the team to contribute at the same level.

So if you want to build a great team, find great people – find the outliers – not people who are the ingredients for the soup of sameness. Develop questions for your interview process that help you filter out average instead of filtering out brilliant. If you have questions you’ve developed that you think help you uncover the outliers and the artists, please share them in the comments below so we can all benefit.

As always, I look forward to your feedback.

12 Comments

  1. shawn barrett

    November 11, 2010 at 11:56 am

    Hi,
    I enjoyed your article as it forces you to think about the content and not just read it. I found myself debating pro and cons of various points and will take something positive away from reading it. So my thoughts,

    I am finding it hard to agree that technical aptitude is not high on the list when hiring. I am principal developer in an agile team that uses Java and .NET . This has led me to be involved in and responsible for hiring suitable candidates.

    I should also say I consider myself a developer; someone who utilises the best suitable development tool for the job at hand. These days developers are “java devs”, “C# devs”, “.NET devs”, “PHP devs”, “Web devs” and so the list continues. If we just consider Java and .NET, it is highly important to me that if I am hiring a .NET dev, they should have excellent .NET experience. Syntactically, there’s nothing in it between Java and .NET, but a decent knowledge of the underlying base class libraries takes years to master. Never mind that the .NET framework advances at a rate such that even experienced developers find it hard to keep up to date; LINQ, Lambdas, .NET 3.5, .NET 4.0, C# 5.0. I would agree that if you are experienced, you can cross-train much easier as you understand the core concepts.

    Besides the core frameworks, you also need to have a good knowledge of patterns and practices relative to your chosen development language. If I’m hiring a silverlight 4.0 developer, secondary to core silverlight development, I would expect them to understand patterns used as standard, for example MVVM, IOC (MEF) and a few others.

    The same applies if I was hiring a Java dev. There is also the trivial aspect of IDEs; Visual Studio vs. Eclipse. So for a relative junior / intermediate there is too much to learn, if you are after a creative talent that is a dev resource. Sure they may have great ideas, but who will implement them? You’re hiring a dev resource remember. Never mind produce architecture. There may be exceptions, but is it worth the risk at interview stage? If your company has 3 to 6 months to allow your new starter to get up to speed, then it’s a different story.

    In an agile environment I find communication hugely important. It is too well known that requirements communication is hazardous to an agile sprint. This may be requirements changing, or miscommunicated. If there is no decent communication, projects are doomed.

    Hard work is important, but if you are creative developer you will think outside the box to come up with ways to avoid hard work 🙂

    Shawn

    1. Michael

      November 12, 2010 at 10:00 am

      Hi Shawn,

      Thank for the very detailed and well considered response.

      As I mentioned in the article, there is no right or wrong answer to the question – only my preferred response. Technical aptitude is indeed very important, just like it is important to know your scales in music. Two of the greatest and most innovative guitarists in the history of Rock Music were also known for not being superb technicians. The two I am referring two are Jimi Hendrix and Jimmy Page. As innovators and people who were major influence in their field, there are few very few that can be considered to be in the same class. Neither Hendrix, nor Page were exactly slouches when it came to the technical elements, but there are many people who can from a technical perspective, play as well and even better.

      Indeed in creating brilliant software, as in creating brilliant music (both arts with technical skills required), a certain base level of technical proficiency is definitely required. Technical proficiency does not, however, beget creativity or problem solving ability. The likelihood of building an entire team of creative geniuses is virtually nil, so you will only be able to find one or two whom you will be able to convince to join your team. But it is not just the Rock Star innovators you should be looking for. You need diversity of thought and experience. I too am a programmer, and I have worked with many languages and technologies. The more of them that I use, the more similar they all seem. The vocabularies and syntax of the various languages are both small, and very similar to each other, so as you say – this part is easy to learn. Yes it takes years to master the class libraries of .Net or Java, but in truth, most applications use only a small portion of their respective frameworks. So therein lies one of the pitfalls of technical interviews: If you ask a person technical questions about specific parts of .Net, C#, Java or whatever, you are testing only two things: 1) Have they worked with that portion of a framework that as you say is so large that no single person can understand all of it or – 2) You are testing their memory for rote recital of arcane bits that the IDE helps them with as they type, or that they can easily reference in online help or on the web. You need to do some of this in order to establish a baseline capability, but beyond that baseline ability, these two things are in no way related to a person’s ability to write brilliant code. This is why you need to figure out how they think, and how they solve problems, including prioritizing things, being able to rationalize why, dealing with the context by asking questions of you, and so forth. This will give you clues as to how they will use their knowledge, and this is the most important thing you want to know about your prospective hires.

      Thanks again for your terrific feedback!

      Michael

  2. Mary Brodie

    September 2, 2010 at 10:45 am

    This is a wonderful article and I wholeheartedly agree with your observations. I think the beauty of a team is that so many different perspectives are brought together so when you do come to consensus – you really have a good solution. And the dog park analogy is awesome – and at times very true. Being in a team isn’t about democracy and voting – it’s about getting the right vision and solution in place. I think we at times lose that and think we are playing a reality game to get voted off the island because we don’t comply.

    1. Michael

      September 7, 2010 at 11:44 pm

      Hi Mary,

      Thank you for the wonderful comments. I agree with you… the strength of the team is the diversity of ideas and opinions. Different idea DNA introduces solution possibilities that either not possible, or are impractical without diverse opinions. Your comment about reality TV and getting voted off of the island made me laugh out loud – literally.

      Thanks!

      Michael

  3. Olivier Gourment

    August 29, 2010 at 3:06 pm

    I would have answered the same as your “superb addition” because:
    1. technical competence cannot be acquired that easily and I actually believe it is even more rare than hiring skills
    2. the other two can be compensated by management (myself) and work ethics is obviously more important than communication.

    Would you hire me? 🙂

    1. Michael

      August 30, 2010 at 11:37 am

      Hi Olivier,

      It would depend on how the balance of the interview went… 🙂

      Michael

  4. Tom Van Acker

    August 27, 2010 at 7:09 am

    Every once in a while, you read an article where your own ideas seem to be incorporated, but in such a clear way you can never explain it yourself. Thank you for this article, and thank you Miki Saxon for the dog metaphor. I will use it too someday …

    1. Michael

      August 27, 2010 at 7:04 pm

      Hi Tom,

      I’m glad my ideas and writing resonated with you. Thank you for your thoughtful comments.

      Michael

  5. Miki Saxon

    August 26, 2010 at 12:50 pm

    Hi Michael, I am the author of the original article and had no idea that it had been reposted without attribution at Mendoza; I’m complimented that you found it so memorable.

    Along with your excellent approach to hiring, your readers might find it useful to know that, based on my experience, charm is the number one cause of bad hires.

    1. Michael

      August 26, 2010 at 5:03 pm

      Hi Miki,

      I am so glad that you stumbled upon this post and commented. I don’t know if Mendoza posted it without attribution as I found the article a few years ago, but have not seen it since. I had copied the text of the article into an e-mail I had once sent to a friend and was lucky enough to still have that message. In any case, I can now properly credit you and I have updated my article appropriately.

      I looked at your site and you have some excellent material, In particular, I enjoyed the article and video “Leadership Lessons From Dancing Guy” http://bit.ly/9ZIu1b humorous and very informative.

      Thanks for making the connection!

      Michael

      1. Miki Saxon

        August 27, 2010 at 12:00 pm

        Hi Michael, I didn’t stumble, I got a pingback from your post:) I’m glad you like my stuff and it was very nice of you to take the time to update your post.

        It’s impressive you still had the email considering the original post was four years old. Also nice to know I’m not the only nut that keeps years of back email (decades if one sys admin hadn’t messed up and lost it all:)

        1. Michael

          August 27, 2010 at 7:09 pm

          Thanks Miki,

          Just glad you made the connection. The metaphor is a good one, and it stuck with me.

          Yes, I have years of e-mail archived. I’ve lost some of it in machine changes, but I have most of it, and I’ve found it to be very useful on occasion.

          Michael

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.