Why It’s So Hard to Hire Great People


Google admitted that its infamous brainteasers — e.g.: “How much should you charge to wash all the windows in Seattle?” — are awful at predicting who will be a good employee.

Your reaction might be: um, FINALLY. And, sure, thinking about windows-per-housing-unit isn’t the most direct way to assess engineering skill or creativity. But Google’s flawed strategy was the answer to another brainteaser: What’s the best way to hire great employees, anyway? People are complicated, organizations are complicated, matching people and organizations is complicated, and it’s extremely difficult to predict who will be brilliant and who will be a bust.

“Years ago, we did a study to determine whether anyone at Google is particularly good at hiring,” Laszlo Bock, Google’s senior vice president for people operations, told LinkedIn. “We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess.”

Brainteasers didn’t matter. Colleges didn’t matter. GPAs? Yeah, those didn’t matter, either. The ability to hire well turned out to be utterly random for everybody…

Frankly, this is why understanding culture is so important. Google could have used something like TeamScience to help them:

– Understand their unique team culture
– Then hire the right cultural fit to their teams

Makes sense right? We already know that it makes sense… but most companies don’t take the time to do a cultural survey.

[HT: The Atlantic]

Agile Habla Aqui?

Agile doesn’t speak English, Spanish, or Martian. It just speaks efficiency and speed to market. Here’s how to implement agile across languages.

As agile grows in popularity, many businesses are finding that one of its greatest gifts is its common vocabulary. Other methodologies often struggle to communicate across different languages, processes and cultures. But by working from a foundation of mutual understanding based on a shared language, agile prevents misperceptions, delivers the customer’s vision and accelerates time to market – all by implementing some simple yet highly effective practices.

So how does this common language of agile development work? While smart vendors and customers will make an effort to work with culturally compatible teams, the effort to synchronize expectations and processes can’t stop there. Teams from different regions, backgrounds and companies will still need to reach out and create a synchronized language.

The five agile practices below can help teams work across their differences to ensure a smooth, streamlined project cycle.

Provide real-world examples of what we mean

Effective agile teams will find a way to work around an unavoidable truth: we all define words and concepts differently. We come from different backgrounds, some of us speak different languages, and all of us are influenced by sources such as former training, bosses or projects. As a result, our viewpoints and definitions can vary widely, which can quickly lead to erroneous assumptions on a project. By using real-world examples to accompany our agile terminology and directives, any guesswork is eliminated.

Let us look at the following scenario. We recently entered a new software development domain. There is usually “shorthand” that has developed among team members when they have worked shoulder to shoulder for a long time. In this particular case, our customer’s team has worked together for over 15 years. So the terms used while expressing requirements in user stories are clear to them. For us as an external developer it would have been easy to misunderstand the meaning of that shorthand. However, the real-time interaction required of agile allows us to overcome such deviations due to misunderstanding in just a matter of hours.

Implement a framework like CMMI or SCRUM

On one project I found myself in Mexico with an extremely diverse team. Engineers, developers, economists and government workers all played different roles on this project, and everyone was focusing on a different piece of the puzzle. The viewpoints and ideas clashed to such an extent that I really doubted we could hit the project deadline or meet the customer’s goals. Yet in the end we did deliver a successful product – and it was because we implemented a framework that helped everyone understand and carry out their specific roles. The magic of implementing the right framework is that it defines parameters, institutes clear communication and spells out the right processes and directions. Putting a framework in place at the start helps dispel any confusion over priorities and roles down the road.

Define the literal language

This is absolutely necessary in a time-boxed iterative process. The reason is obvious; if we’re working with 14-30 day development cycles, even a slight misunderstanding can lead the project disastrously off course in a very short time. Once again, remember that we all bring different understandings to a project.

done-not-equal-doneThis is never as evident as it is with the word “done.” Generally, a team’s Definition of Done (DoD) is aimed at bringing a standardized quality to meeting client demands and making success repeatable throughout the project. But the standards themselves can differ from team to team. One team might decide that all coding, testing and peer review must be completed, before it can be called done. Another team might decide to split their DOD into additional levels of Done Done and Done Done Done. Still another might have adaptable DoD depending on the project type. To make sure that everyone is on the same page at every point in the project cycle, precise definitions are critical so take the time to develop them and ensure all team members use them.

Think of it like building a house

In the United States, you often pay for your house long before you move into it, since the house has to pass certain inspections and is only considered ‘move-in ready’ after those inspections. In another country, on the other hand, you might move in before construction is officially complete and then keep working on it while you’re in residence. Such different practices and expectation can easily lead to a misunderstanding – so you can see why it’s vital to clarify the meaning of our words.

Stay focused on the promise to the customer

True, a lot of businesses like to talk about their “promises” – but when it comes to agile, this isn’t just empty talk. Accountability is woven into every fiber of the agile model, while teams keep the customer’s needs in mind at every stage. The Promises Triangle aligns customers, providers and workers by ensuring the workers are both informed of the promise to the customer and empowered to fulfill it. The purpose of this diligent accountability? Avoiding a common pitfall of waterfall model, where the Requirements Document begins a promise that eventually winds through non-technical staff who then add in unrealistic promises – a process that often leads to disappointment in the final product.

Prioritize frequent communication and feedback

Agile cycles are built around user stories – first by gathering those stories, then prioritizing user needs, then deciding what can be delivered within the designated timeframe. Teams also constantly solicit and incorporate feedback to maximize customer satisfaction. On a practical level, this means that customers must be prepared for frequent interaction and able to deliver clear feedback, while vendors must be able to explain how element X affects element Y in a way their customers will understand.

Overcoming different backgrounds and conflicting expectations is important in any business endeavor – but in agile development, it’s absolutely critical for a successful product. By implementing thoughtful and effective strategies to align efforts, teams can eliminate potential missteps and fulfill their promises to their customers. In the end, it doesn’t matter what languages and backgrounds teams bring to the table – by following the above practices, everyone will be speaking the shared language of agile.

Guest post from Tiempo Development, which provides cloud-focused companies with a powerful, integrated platform of services that transforms the way their products are developed, deployed and supported.

Peter Saddington Session on the Science Behind High Performance Teams #agile2013

Dear Peter,

Thank you for being a part of Agile2013. Following is some information about your session.

  • Number of attendees at the beginning of your session: # 170
  • Number of attendees at the end of your session: # 170

We asked attendees to indicate whether they would recommend your session to their peers:

  • Yes (Green): # 120
  • Maybe (Yellow): # 3  ***CANT PLEASE EVERYONE*** 🙂
  • No (Red): # 0


Agile Alliance Team

Had a great time! Thanks Agile Alliance!

Below is the scribd version:

Action & Influence – The Science of High Performance Teams Teams Agile2013 Peter Saddington FINAL

Double Presentation at Agile2013? Sweet!

agile-2013-nashville-peter-saddingtonAn email I received from Agile2013:
As you probably know we are trying an experiment at Agile2013 this year. A new track, “Crowdsourced”, will be built in real time by the attendees at the conference. The format is simple: attendees go to the submission system at submissions.agilealliance.org/crowdsourced where they will see a list of sessions available for voting; attendees can then vote for the sessions they would like to see by placing a star next to any sessions that they are interested in. The voting runs until Wednesday, and the 15 sessions with the most votes will be announced and scheduled for a Friday morning time slot.
Based on early feedback from the Agile2013 sched.org website, your sessions are very popular and people have been wait listed. In order to give attendees the most access to the content they wish to see, we would like to add your sessions to the Crowdsourced track and make it available for voting. This would give attendees a potential second opportunity to make it to your session. If your session is voted on, you would be scheduled into a room for9:00 AM Friday morning.
Sweet! Come and see me on Monday… or Friday! 🙂