You learn when you are listening; you learn nothing when you are talking

Developers are technology experts who need to collaborate with business experts (users) to understand how the business works, what the requirements are and the software needed.

Creating software involves meetings, plans and decisions involving multiple people. Developers need to listen, ask questions to understand the requirements and solution. It then needs a plan and different people getting tasks to create software.

The common problem is developers talk too much, listen to little and regularly create the wrong software.

Developers need input to understand, clarify how the software should work, the more developers talk the fewer requirements and clarification they get. Developers fill these gaps with assumptions, which are requirement guesseses which are often wrong.

Developers should speak less, listen more to allow them to focus on creating software and reduce distractions.

Systems thinking

Developers Are the Most Valuable Resource when creating software because they are the only members who create software.

Developers with specific knowledge or skills can become a bottleneck or single point of failure because no one else can do that task. This happens with users and specific domain knowledge in an area of the business.

The more meetings and non development activities a developer gets, the less time developers have to create software. Everyone on the project has their role and responsibilities. For the project to work smoothly, everyone should do their job.

The more developers talk, the more tasks and responsibilities they pick up. Developers don’t want to decide because they become responsible for those decisions.

Developers want to ask questions, put forward suggestions, give options and then the product owner or the right stake holder decides. e.g. Developers work from signed off requirements.

If the customer wants changes, they need to change the requirements, update the plan and then the developer can work on it.

To help this process developers and IT professionals should

• Talk less
• Listen more
• Ask more questions
• Let the customer drive and own

Why do we talk?

Reading the book start with no, the book says we should control are neediness. Talking and neediness are closely related. The reasons we talk are.

• To be liked
• To be right
• To use our ideas and solutions
• To save the day

Neediness is a trigger to talk. Talking tells people what to do and stops them from putting forward ideas. In an ideal world we want our ideas coming out of their mouth.

If you raise an idea, a common response is for you to own it. If you create a solution, the simple choice is for you to own, plan, run it and see it through to completion. You have given yourself more work to do, on top of your existing work.

Good project managers and senior architects/developers rarely know the details but they ask the right people the right questions to get the answers.

Controlling the conversation

Most people talk because they think this is the most effective way to control and drive a conversation. It feels like the talker is control but if you look closer; you notice the person who asks the questions controls the direction of the conversation.

The person talking feels they are in control, putting forward their ideas, dominating the conversation. Let them talk and direct the conversation with open questions.

Open questions are ones that start with How, what or then. They are questions where the person needs to think of the answer.

• How can we do that?
• How should we proceed?
• What are the next steps?
• What does the plan look like?

They are powerful questions to help people understand their ideas won’t work, like

• How can we do the extra work with the same resources?
• Then what happens?
• What will adding extra work to do to the current plan?
• Have we given up on the current plan?

Lead developers/Functional consultants/architects have deep knowledge of the business and the solution. They can come up with the solutions, but they gain more work and tasks this way.

If you look at what happens is other people in those meetings keep quiet and let the leads from the development team speak. The result is leads get the work.

The leads use silence and open question to let the right owners talk and create the plans. The goal is to get to the right solution, idea and make the right decision, but without it being yours.

If the development team decides, they will become responsible for the decision.

Say less than necessary

In the Robert Greene’s 48 laws of power, law number 4 is

“LAW 4 — Always Say Less Than Necessary”

When you are trying to impress people with words, the more you say, the more common you appear, and the less in control. Even if you are saying something banal, it will seem original if you make it vague, open-ended, and sphinxlike. Powerful people impress and intimidate by saying less. The more you say, the more likely you are to say something foolish.” — Robert Greene

The more we talk, the more information we leak, the distractions we raise. The more developers talk, the less the customer is driving the conversation.

senior developers have in-depth knowledge and can answer most questions, it doesn’t mean they should

The more developers talk, the less everyone else talks. Silence doesn’t hurt you, it doesn’t get your more responsibilities; it doesn’t leak information; it doesn’t highlight areas that aren’t relevant; it doesn’t waste time. The more the development team talks, the more decisions they make, the more tasks they get.

The more other people talk, the more important they feel, the more in control they seem. The development team benefit from getting information more than solutions.

Silence makes other people talk and the development team can learn more.

Meetings

Talk less, listen more.

People feel better and in control when they are talking.

Use silence to let other people input into the conversation and let them work their way towards the answer. If you feel the meeting is going off track, provide information and ask open questions to people to guide them towards the answer.

Developers should listen, take notes, ask questions and use silence to let other people talk and own the issues.

It’s not the person talking who is in control, but the person asking the questions. Control your neediness to feel important and talk. Let others do this.

Presenting — Explaining — be the expert

Developers talk too much and in too much detail. A common scenario is a developer answers a question or explains a technical point, but instead of shutting up, they keep speaking and speaking.

The more you talk, the less it seems you know.

Instead, be an expert, explain the major point and then shut up. Experts don’t need to keep talking because they are confident in the information they have given and there is nothing else to say on the subject.

Deciding

“If you’re explaining, you’re losing.” ― Ronald Reagan, The Reagan Diaries

The details aren't needed, it overwhelms the audience and will raise more questions.

The less you talk the fewer points you raise, the less distractions and potential discussion points. Developers should stick to the main points and the benefits.

Saving the day

When the drivers of speaking is to save the day, save the relationship, save the project. It’s for you to come up with the idea or solution that saves the day.

There are two things to consider:

• When you save the day, you become responsible
• The day will be saved without you (we aren’t as important as we think we are)

When we are saving the day, we take responsibility and further consequences will be put onto the development team.

If there is a problem with the idea or decision then this will come back to the development team.

Silence

When you are silent, this put the emphasis on the other side to speak. Silence can make people negotiate against themselves.

There is a great story from Edison featured in Negotiating 101

He decided to set up the ticker tape machine and just let it run without saying a word. He stepped back and let the banker read the tape. He let the machine do all the talking.

Instantly, the banker saw the value in this new invention and offered him $5,000. Hearing the offer, Edison sat with a terse look on his face and said nothing.

“$10,000,” the banker barked. Yet, Edison sat there looking slightly confused across the other side of the table.

“Ok! Ok! $25,000,” the banker exclaimed. And Edison still did not bat an eye.

Assuming that Edison was a tough negotiator, the banker gave one more offer. “$100,000 and not a penny more,” he said.

Edison looked at his partner with a frown, and he nodded in agreement. The banker laughed and said with a boastful smile, “I would have paid you $150,000.”

Edison finally replied and said, “I would have taken $10,000.”

This is a great example of not talking, using silence and letting the other side talk.

Open questions

Put the talking and deciding on the other side, let them create plans. If the plans are wrong, ask open question to guide them back on track.

How can we do 100 hours of development when we have 50 hours of Dev time available?

Put the problem to them to solve, make missing the deadline their problem and the solution that breaks it their solution.

The person talking has the illusion of control. The person who is silent and asks open questions is controlling the conversation.

Reversal — When you should talk

It’s hard to keep quiet when everyone is talking nonsense. It would be quicker and easier for you to lead and take over. This is driven by neediness, its rewards are in the short-term but in the long-term this slows you down.

You can’t always keep quiet, in some situations, you have more knowledge and better ideas. Don’t want to let other people make poor decisions that will make the development team's life harder.

In situations where you need to decide quickly, you might not have time to let other people get to the right answer.

Developers talking and taking charge is the short-term solution that will create longer-term problems later. It should be he exception, ideally you want to guide the other people on the project to make the right decisions by giving them information.

It’s better in the long term that the whole project gets more understanding and makes the right decisions.

Conclusion

The more developers talk, the responsibilities, decisions and work will come their way. This squeezes developers to do the development and these extra tasks.

A developers job is to learn the software needed, understanding the business and requirements. Once they have the right information, they can make the right software.

Ask questions and listen to discover the requirements and understand what software to create. The more developers talk, the less talking other people are doing and the more gaps and undiscovered requirements there are.

The person who makes the decision takes responsibility for the outcome. Developers don’t want that responsibility and shouldn’t have it.

If you don’t believe the advice, watch the meetings you attend and notice who speaks. Some speak because of neediness, others listen and use silence. They don’t up with work they are not responsible for.

“Wisdom is the reward you get for a lifetime of listening when you’d have preferred to talk.” — Doug Larson