How to Tackle the Talkers and Enable the Doers

Let's examine why it's important to figure out who on your team is a "talker" and who is a "doer". Talkers talk and don't do; doers do, but don't talk. There are doers who may be good talkers, but it is rare to find a talker who is also a doer. What typically happens is the doers' talents are inhibited by the talkers taking over.

It's so important to tackle the talkers because they get in the doers' way of getting things done. The talkers waste time, like to have meetings, and like to make the decisions (a lot of times the wrong decisions). The doers usually know when a decision is wrong, but feel repressed by the talkers and so they don't speak up. The doers don't feel capable enough to influence decisions because they are afraid of what will happen if the decision is wrong. The talkers, for the most part, know how to talk their way out anything, blame someone else, and move on so they really don't mind this part. The doer is someone who is going to respect his work and be more skeptical and careful when making a decision. In software development, success is not about one person, it's about the team. Doers usually know this; talkers don't.

Let's look at a real-life example. I was working as a consultant at a Fortune 100 company. The challenge was, I was joining a project that was already ten months underway. There was no agile, no architecture—literally, not a single PowerPoint of any architecture—and the team was still making decisions on what kind of technologies they wanted to use. I'd already done this type of project many times over. In fact, the project was an ecommerce project and there was no one on the team who had ever done an ecommerce project.

After doing a presentation to the team, one of the contractors (who also happened to be the pseudo-chief architect because this company didn't have one at the time) announced to the room "I knew all of this, but it was a good refresher." This was really just a nice, politically correct way of diluting the importance of everything I had just said and showing it was meaningless to him. Once I had done a couple of presentations, I saw it wasn't really going to change anything because the VP of development trusted this consultant and this consultant continued to show his "knowledge" with that exact same line. The VP had confidence in this architect, but for 10 months, had seen nothing but promises and talk, and really no results from him or the team. The VP had started believing this was how software development worked and that results couldn't be expected as a part of delivery.

When you have a team of 60 people, it's difficult to quickly ascertain who are your best people: who are the talkers and who are the doers. I came up with a plan to figure it out. I decided to do another, more in-depth training, on a version of Web API that was set to be released to the public that same day. I had the bits because I worked with Dan Roth, the program manager for web API and I'm an API advisor, and so I already had all the information on the new features that were going to be added to web API. None of this information was released to the public until that same day. I knew my team wouldn't have time to review the release prior to my training.

Right before my presentation, I talked to the VP of development and told him, "No one in the entire world has seen these bits yet except for a few people inside Microsoft, plus the other API advisors who are under NDA. I'm going to do a talk on all this information and let's see what your people say." After a couple of hours going over all the new API features and how they could incorporate them in their project, I asked the same exact question to the team: "Did you guys learn anything?" Most of the room was already clapping, excited about the presentation and the information presented. I then asked the pseudo-chief architect this same question and his response was, "I already knew all of this, but it was a good refresher." This was a turning moment for the company because the VP now realized that his most trusted consultant was really just a talker and not a doer at all!

This is an issue a lot of companies deal with because they have to trust who they think is their number one guy. This particular trusted consultant was telling the VP that this project would not be done for another three years, but my team was able to get it done in six months and with just 12 people! When you have the right people, it's amazing what you can accomplish.

The learning lessons here are:

• Time gets wasted in unimportant meetings or in meetings that don't need to be attended by every single person on the team. Remember, when you have a team of 60 people, a one-hour meeting is really costing you 60 hours.
• When you have about 60 people in a room, it's hard to determine who the best people really are. Maximize the output of your team by minimizing the size of the team and composing it of doers, not talkers.
• Remember, the success of your project will be best served by identifying the talkers and getting them out of the way of the doers.