The Psychology Of Software Development Part 2. Building Premier League Quality Software Teams

In this series I wanted to offer the posts in somewhat of a chronological order of the cycle that most software developers and companies will go through when looking for a new employer/employee partnership. 

Following on from my take on phone interviews, I want to offer an insight into something that i'm pretty passionate about, something that employers should think about before any face to face interview, especially when putting together new teams; I want to take a look at how you build a truly successful software development team. 

I've been thinking about an analogy around this for a while and I can't get out of my head the concept of software teams, much like football teams (or any sports teams), have various styles of players, or in our case; various styles of developers. 

I came to this conclusions because, my overriding skills lie in leading software projects and getting applications to market. I say this with some modesty, being good at this and focusing on these skills will always come at a detriment to other aspects that may be desirable within a successful team.

So what comprises a good software development team? What compromises a good team in any situation? Well, we could mention collaboration, teamwork, communication, understanding? But all of these things only really come into play once the team is together. 

The core basis of any team is balance, each position that's supposed to be filled is filled. No matter how exciting a football team with 11 strikers sounds, you'll never find a team that plays it, and it's obvious why, right? What happens when the other guys head down your end? Your strikers can't tackle, they give away penalties and free kicks get carded and before long you're down to 8 men on the pitch because you've put them into a position that doesn't naturally suit them and invariably they haven't trained for!

So how do we get the balance we need to succeed? Just like a football team we need to fill our positions to provide the balance. 

The Goalkeeper

The goalkeeper is the guy that stops the opposition ball hitting the back of the net, the one that stops things going against you, the protector from something as ridiculous as the opposition putting the ball into an empty net. 

Ideally your goalkeeper is a preexisting member of the company, someone that has knowledge of how the company works, the intricacies of the system, where people can find the information they need.

They should be at the core of the team supporting and contributing to development, they should ensure that no matter how much brand new shiny work is completed the team don't concede to the intrinsic issues that they wont find through google or their own experiences at other companies, the basic stuff that everyone know except the new guys. You wouldn't play a game of football without a goalkeeper; don't build your software team without one either. 

What to look for: An existing member of staff that understands the environment and ecosystem, someone that can realistically dedicate their attention to getting the team up, running and working, this can be more than one person if needs be.  If there is no existing members then bring in a lead a month before you hire the rest of the team and fill their brain up with as much information as you can.

The Defender

The defender generally protects the goalkeeper, he stops the opposition scoring goals, he's hard working, no nonsense, he gets hold of the ball when he needs to and gets gets rid of it safely and effectively. 

You need a defender in your software team and he carries much of the same characteristics as the guy on the pitch, he gets on with his work, keeps his head down, asks questions when the times right and answers the ones that's asked of him. He's a grafter, a work horse and rarely complains but speaks up when his opinion is valid. His hard work and dedication will keep the ball out of your own net as he'll see you meet your deadlines with little fuss. 

What to look for: Smart developers with a passion for coding but aren't obsessed that they must use and learn the latest frameworks. Developers that can demonstrate a good work ethic and are committed to getting the job done for the team in whatever way the team chooses. They are just happy to be contributing.

The Creative Midfielder

The creative midfielder brings you flare, class and really makes the ball move, the fans love to see him play but don't expect him to be focused on keeping the ball out of the net.

A software creative midfielder will be your driving force when it comes to new technologies, he'll be obsessed with the next big thing and will want to complete the project with 20 new technologies, his passion for whats new will flow through the team and keep your developers engaged and excited, the tech list on their CV's won't look too shabby after working with him either.  

It's important that the creative midfielder focuses on the common goal though, if he isn't pulling his weight when it comes to defensive slog or offering too much creativity and no end product then he may as well not be on the pitch. 

What to look for: Developers who know about the next big thing before it's even come out, developers who have a genuine passion for software and frameworks. Usually into open source stuff.

The Striker

Arguably the most important player in the team, a team is a sum of all the parts but without putting the ball in the back of the net you can never win a game.

The striker is goals focused; they get the project over the line. They are focused on the needs of the business and the timelines they should adhere to. 

They're looking for the creative midfielders to set them up with the best technology in order for them to take it and put it in the back of the net. Like a good striker these developers are often rare.

They need the stability to come from the defense and goal keeper to ensure that they get the project win without conceding along the way.

What to look for: Developers with a keen business sense, good work ethic, they're personable, have good soft skills and can converse with management and business stakeholders, they're leaders. They have a wealth of experience.

In the world of football you get defenders that score and strikers that are good at defending from the front or when there's corners; the same is true for developers they can be versatile; utility men, that will take on any position.

No developer wants to be the guy slugging away without doing some of the fun tasks, or getting excited about the new technology. 

Similarly, you can't have one team member having free rain adding in 50 new technologies, he's got to be a team player, realise that leaves the team exposed and do his part to defend, he needs to realise that sometimes you have to filter down some of the creativity for pragmatism, the striker will be more than happy to tell him this in order to get the project in the back of the net.

In an ideal world your developers will be an equal composition of all the parts and as developers it's what we can aspire to be. 

The Psychology Of Software Development - Part 1. Telephone Interview.

Interview - even the word can strike fear in the hearts of men and women. I'm not sure I've ever met anyone that actually likes interviews, and I most certainly haven't met anyone that likes giving them. I've sat on both sides of the table and experienced the feeling of a successful interview and a few not so successful ones.

A lot what what is being asked of in interviews is quite frankly useless in ascertaining whether the individual being interviewed will actually be able to perform long term in the role, we'll get on to that later..

In my 10+ years experience I've encountered a lot of interview techniques, It's a spectrum, and I've generally found the more highly regarded the company in the tech world the more complex the interview process is. 

The initial phase usually takes the form of a telephone interview which this blog post covers.

Now the phone interview can be tricky but if you follow a few simple rules it should put you in good stead for breezing through.

The phone interview might get technical, it might not, a non-technical call can be just as revealing for the interviewer and there are a few distinct things which they'll be looking for

Can you communicate clearly

Aim to speak clearly, it's worthwhile finding a space you can do this in where it's quiet and you won't be disturbed, book time out in your calendar to have the conversation; a non-technical phone interview is going to look to tick the box that you can communicate clearly and you care enough about the role to give your interviewers time some respect.


It's sometimes difficult finding a space to do this when you're already in a job and understandably we usually prefer some discretion when it comes to your current employer knowing of our intentions to leave; whispering under the stairs isn't going to give the best impression over the phone. I would always try and organise a call later on in the day, if you're work hours are flexible then leave early and organise a call for 5.30 - 6pm. If you're better on a morning then go for that, however, I always thinks it's hard to engage your brain first thing for both you and the person interviewing.

Are you showing some enthusiasm about the role

The easiest way to show enthusiam is to not give one word answers, the interviewer is looking for some insight into what your thought processes are like and what your practical working experience is. The tone of voice you use is pretty important too, it's not a case of being in your face, one thing i always do is try and be personal, speak to your interviewer warmly, like a friend, it will make them want to work with you.  

Can you expand on your CV with some real world examples

I always think it's worthwhile having a print out of your CV in front of you, make some notes on the most recent job(s) that you've had, annotate with things that went wrong in projects, what went right, the stuff that you wouldn't think to put on your CV but are a bit more juicy and show you've got experience in things going wrong and problem solving in those times. Also have to hand times when things went right. Don't get too domain specific, keep it high level, as an interviewer i'm not looking for you to list all the objects in your common libraries to get to the point of the story..

Do you know something about the company

Google them before.

The higher level more abstract stuff is genearlly easy to talk about, you can talk about your past wins and losses because you've lived through them and you can prepare for the questions, what's not so easy to prepare for is very technical and specific questions about frameworks and languages.
Again, it's a spectrum, for the most part over the phone I’ve tended to find that it's more a general discussion about the types of technology you're using and information about current roles.

I've had some really bad phone interviews that get really technical with pop quizzes, one interviewer asked me to name a data collection type, then asked me the last time I used it and what I used it for, when I explained when and what I had last used a generic list for their response was “That's not really the answer I was looking for!”... OK..

Interviewers may ask you in depth technical questions, it's difficult to prepare for this given the vast spectrum of software development, that said, one thing that you should consider at the very least is to prepare based on what you have written on your CV.

If you've put dependency injection then make sure you can explain what dependency injection is.
If you've stated Agile then be able to explain what a user story is, or a story point.
If you've written TDD then be able to explain why TDD is useful and the stages you perform in TDD.

In some cases you may just get what I like to call trivia questions, if you know the answer then great, if you don't then they can make you feel insecure and foolish, it's hard to account for every possible element of every single framework and language you use, especially in todays market, if a company is pop quizzing you in an interview then they are looking for a very specific type of candidate, this may be you, it may not be.

You can mitigate for this by at least taking time to understand common interview questions thing like "what's the difference between abstract and virtual"? In a later post i'll pull together some common questions that are worth reading up on.

Finally, it's important to recognise that the interview is a two way street, you should be critical of how businesses present themselves to you and the questions they ask. Interviewers can get it wrong too, be critial of how they approach their questioning and allow that to be reflective of their business.

I've personally never worked in a company where they've ran up to my desk and thrown .net triva questions at me just to check i'm up to the task; to an interviewer that may signify developer greatness, to me it signifies they're looking for a memory box rather than someone that thinks outside of the box.

We live in a time where software developers are in demand, you're lucky enough to be able to take the time to choose the right role, but make an effort, learn about your trade and be passionate in how you speak about it, if it goes wrong, learn from it, be ready for next time. It may take a few to get it right but you'll get there.

The Psychology Of Software Development - A Blog Series Introduction

Over the coming weeks i'll be posting a series of blogs around my opinions on some of the non technical aspects of the software industry, the soft skills side, what you could loosely call the psychology of software engineering.

I've been lucky to experience a lot of different working environments over the last 10 years and I've witnessed a lot of working styles and more importantly, come across a lot of different personalities and developer types.

The aim of this blog series is to question some of the decisions companies are making in regards to hiring, how they put teams together and to give a view from a developer perspective on some of the business strategy that's forced upon us.

I also want this series to serve as a guide to other developers that are maybe starting out in their career, looking to build teams of their own, or, perhaps, just want to read about another developers view point on the more sticky sides of the industry.

I'll aim to give some tips on how to avoid certain situations, what to look for when hiring developers and moreover how to deal with some of the more tricky situations and souls you may encounter.

The Psychology Of Software Development - Part 1. Telephone Interview.
The Psychology Of Software Development - Part 2. Building Premier League Quality Software Teams