Categories
Insights Teams Uncategorized

“Hiring good developers is just like sexing chickens”

A memorable – if not a little disturbing – simile once used by an industry legend during his seminar.

Sensing the discomfort of the crowd, he frowned & bellowed, “Well, you know what I mean, right?” Not a clue, but you certainly have my attention… “It’s like being able to tell the gender of a baby chicken just by looking at it.”

Apparently it’s a subtle art (in the loosest sense of the word) developed with many years of experience, one you can attain to determine chicken gender, or, more usefully in our line of work, developer quality.

I don’t know about you, but I certainly don’t know anyone that has the ten thousand hours required to master that skill.

Anyway, we’d prefer to hire whole coops, sorry, teams of developers for a number of reasons.

  1. The developers already work together so have a quicker startup time.
  2. Cross-functional teams will be able to fulfil all the roles required for project delivery – UX, development, QA, DevOps & so on.
  3. They usually have a project project manager, scrum master or coach who’ll take responsibility for helping the team organise their efforts, report on progress & deliver the project.

Hiring teams is a completely different proposition to a single developer – we can’t make them all do whiteboard interviews. Here are some of the things we look for & ask at Digital Village when hiring great development teams.

Show us what you’ve done (please)

Stand & deliver. We’re technology agnostic & focus on the best processes for delivering reliable value in. In short, we spend less time looking at tech teams work & more looking at the projects they’ve completed.

Are the projects ‘significant’ & did they challenge the team’s ability? ‘Significant’ is of course subjective, but we’re looking for teams with strong capability & ambition.

Are the projects accompanied by glowing testimonials? Unfortunately self-assessment can be a little, let’s say, biased from time to time.

Now let’s talk about it

A curated brochure of past products is nice, but we aren’t window shopping here. We need to dig into things a little (lot) more. A good ol’ fashioned interview with some representatives from the team is a perfect way to find out:

  1. What challenges the team faced while building one of their showcased projects & how they resolved them.
  2. What they enjoyed about the project. Seriously, we’re all supposed to enjoy this or what’s the point?!
  3. Which projects they’re most proud of & why (forgetting pride is of course a Sin).

Abiding by the old proverb, “it’s not what you say, it’s how you say it,” & without dabbling in amateur psychoanalysis, there’s a lot more you can take away from the interview.

Are they excited to talk about the projects? Do their eyes light up when explaining technical triumphs. Perhaps an eye-roll when describing the challenge of containing scope with an ambitious client?

Honestly, the last thing we want to see is ambivalence. We want to see anything to show a deep engagement with all the challenges (technical & otherwise) that arise during a complex project.

If they pass both stages with flying colours, hire them & give them everything they want.

Ok, just kidding. I’d feel very hesitant to hire a team purely on this basis. So, I hear you ask, what are the key questions Digital Village asks before engaging with development teams..?

How do they know they’re building (whatever it may be) correctly?

A simple yet serious question. How do they know what they’re building works as it should? It’s an opportunity to understand their practices, processes & also attitude towards producing quality software.

The answer, of course, should involve a seven letter word that causes more headaches than most: ‘testing’. But what kind of testing? QA staff are great & will pick out errors like a sniper, but automated developer tests are also important.

The bravest programmer you’ll meet (& the one you want to meet) is running a gauntlet of unit, feature & integration tests. “Does my change break anything?”, is just an automated test run away.

Adopting such methods allow teams to stride quickly & ambitiously because the safety net of automated testing is always waiting to catch them after a misstep.

How do they know they’re building the right thing?

At least this one’s simple… “it’s what the client asked for”. Get out.

Every project is a big investment for a client, so how can we be sure the investment is going to pay off?

At Digital Village we have a huge range of clients: start-up to enterprise, tech wizards to non-tech founders. With each client, we assume full responsibility for helping them understand if the proposed project is going to make their business more successful.

If not, we can steer them in a better direction even if it means having difficult (but always positive) conversations. Clients come to us looking for guidance & it’s fundamental to our service that we find the right solution.

So our question for any team is, “how will the client know if what they’ve asked for is what they really need?”

If they reply, “the client agreed to the specification, if the code meets the spec then they’re getting what they want,” they’re not the kind of team we personally like to work with.

I’d love to hear how the team proactively validates work delivered to a client, their strategies for eliciting feedback & how they manage that moment when a client says, “wait a minute, this isn’t going to work”.

So, where is everyone?

Long gone are the days of expectation & necessity for singular locations. We’ve worked with all kinds of teams: onshore, offshore & a hybrid of both. So far, we’ve found each model brings its own benefits & challenges.

If a team has offshore members, great! Some of our current teams that contain offshore members produce incredible results at a fantastic price-point.

Traditionally, communication is seen as a potential pitfall for offshore teams, but our success is due to amazing team leads who are responsible for communicating with project stakeholders locally & team members offshore… a conduit, if you like.

So let’s hear about who is responsible for communicating the client’s needs to the team & relays the team’s questions, concerns & suggestions.

What’s the silent killer of projects?

To be clear, I’ve never asked anyone, “what’s the silent killer of projects?”. One, because it’s over dramatic, & two, there are always symptoms.

I would love to know, however, what the team thinks is most likely to derail a project. Although answers will vary, if this were a game of Family Feud I’d expect “communication problems” to be a top answer.

As Bernard Shaw, a man that revolutionised comedic drama, said, “The single biggest problem in communication is the illusion that it has taken place”.

So what are their individual thoughts regarding communication? How could they be sure a client has understood them (& vice versa)? Perhaps most importantly, will they be willing to take on the commitment to communication that Digital Village does?

Dev teams are often missing one vital piece of the puzzle. The client. Now we aren’t expecting 40hrs a week, but we always try to bring clients & users into the project team. Invite clients to join meetings & the same communication channels as the rest of the team.

The last word(s)

So, a case study & an interview. We’re hardly rattling the established pillars of HR & recruitment with this one, are we? But what it all boils down to is can we answer the following questions with a reasonable degree of certainty:

  1. Is the team proficient enough to produce technically sound work?
  2. Do they care enough about their client to provide them with results that make them more successful & do it in a way that makes the client feel empowered during the process?

I’d be happy to work with anyone who can do that.

Categories
Insights library meetups

Why IT Projects Fail

What causes IT projects to fail & what does a successful project take?

Since the 1950’s, when humans started writing software and programming machines to do things, failure was common. It was also very expensive, but it was necessary. Most of the proceeding years were focused on improving the technology and it is a testament to humans of our capability, intelligence and dedication. I feel it is important to take a moment to stop and look at what humanity has achieved in terms of technology advancement.   ?

Jump to the present and the technology we have at our fingertips enables us to build amazing products and services and solve some serious problems as well as open up amazing opportunities for people and business. But now that we have the technology, the demand and expectation from markets (people) is pushing us to innovate more, build faster, be more efficient.  Makes you wonder where it ends or if it ever does.

However, now that we have the most advanced technology, this has not necessarily reflected in more successful projects. So makes you wonder, If technology is not the problem, then why do IT projects fail?

This month, at a Digital Village Meetup, we explored this question as a group. 

Session Outline

At Digital Village Meetups, we sometimes play a card game. The card game is simple; 6 decks of cards. Each deck representing a category, each card has a question or statement on it. A player rolls a dice, and picks up a card from the respective deck, reads it out, has a go at answering it and then the group discusses it.

In this session, we decided to focus on only one card from one deck and go deep on it as a group.

The original plan of the game was for each group to pick up a card from the deck without knowing what each other group selected. We did this to avoid group think, but we had rigged it so that each person would pick up a card with the same question on it (so we are all answering the same question without knowing).

BUT as each group came to select their card, they would dig into the deck so not to choose the card from the top (as we had planned to happen). The unpredictable nature of people set the tone for what was to come.

Once we broke into groups, each group spent 30 minutes coming up with a summary of their thoughts and ideas about the card they pulled from the deck. Below are the finding for each group:

Group 1:

Question Discussed: Why do IT Projects Fail?

Group 2:

Question Discussed: When running a project, what can you do to improve the feedback loop?

Group 3:

Question Discussed: Why do IT Projects Fail?

Group 4:

Question Discussed: Waterfall vs Agile?

Findings

As a collective group we discussed each groups findings and went deeper into peoples reasoning and experiences and explored what makes a successful project happen? The high-level results were:

Empathy & Attitude towards ‘right and wrong’ 

Of course culture is central to success but having a team culture and attitude and belief that “it is OK to fail, so Im not scared of experimenting and trying something new” is crucial for people to feel comfortable to be relaxed and be intuitive. However, there is a difference between it being OK to fail and and just being incompetent. The difference is in the learning. Were lessons learned and will that happen again?

Leadership

One thing that was obvious is that there needs to be one person holding the torch and keeping everyone aligned and heading in the right direction. This person is crucial to resolving issues and making sure that everybody understands each other. This person is a listener and a communicator and doesn’t necessarily have to be the most liked person in the team.

Process

Having a process in place makes things easier for everyone. So people know what to expect and they don’t ever feel lost about what is supposed to happen next. It gives a structure to something that is very peopley and soft.

Flexibility & Balance

An interesting observation was that there is not necessarily a ‘right’ or ‘wrong’ way to run a project. Agile vs Waterfall; it doesn’t matter and it is unhelpful to argue. It comes down to what is the best process and design for the project at hand.

Project Teams

However a proven structure of running teams is small, cross functioning teams. With complimentary skill sets and knowledge. The formation of the team is that of a group of 3-5 with one project leader. An example of a successful team structure is 3Wks, a software development firm which was acquired by GrowthOps in 2017. Project teams like this are well balanced in their individual capability and this gives a flexibility to solve most problems that are faced within a software project.

Conclusion

It was a lot of fun, but the general gist was humbling. The theme that kept being raised was PEOPLE.

#Peoplearecrazy. They are unpredictable. Everyone is unique and we cannot expect people to behave or think in a particular way.

The silver lining here, is that although the communication and  difference between people is the cause, if we combine these differences in a unified, harmonious and collaborative way, the outcomes are amazing.

This is why Design Thinking and related methods work so well. Because they extract and present each persons thoughts for others to see and understand.

What makes a successful IT Project?

Creating a common ground and shared understanding for all people around the same problem, solution, goal and outcome.

3wks, practiced a relatively unique project management method they designed to include all project stake holders in the development process. With a focus on outcomes that all people (tech and non-tech can understand, it is easier to keep people aligned on track and engaged in the project and the goal.

If you are interested in this process I highly recommend reading this book written by the 2 founders of 3wks; Beyond Agile.

Thanks for reading and hope to see you around the Village sometime soon.

Jason Hardie

Get Involved

See how DV runs Projects

Join the next monthly Meetup

Join the Village to work on a project

Engage Digital Village to run your project