The air is a breeze with mega-trends and next-big-things about the upcoming year 2017. If one is to believe the shamans of digital evolution, one of those next big things are chatbots. Reason enough to do a bit of digging and answer the 3 fundamental questions in regards to chatbots: Why to build a chatbot? How to build a chatbot? And what to beware of?
There are few things as common and challenging in everyday work as giving feedback, especially negative feedback.
What is (negative) feedback all about?
When delivering such negative feedback, we are often meet with fierce opposition or worse, quiet indifference. Both mean we failed the goal we had in mind when delivering our feedback: To change a behavior or an attitude of the person or group we addressed. Both signify a lack of engagement that would be the base for the desired change. If we want to avoid this fate, we need to ensure to deliver the most engaging feedback possible.
How to deliver engaging feedback
With Observe, Feel, Need, Request – Charles-Axel Dein describes a great structure to deliver negative feedback in the most convincing and engaging way possible.
- Observe: Start the conversation with a non-controversial fact.
- Feel: Express how you personally feel about this fact, while emphasizing the subjectivity of this feeling.
- Need: State the general need you have, the general change you would like to happen.
- Request: Explain the concrete action you would like the other person to take.
Building engagement – One step at a time
Observe, sets the topic and gives you a common, conflict-free starting point, as an objective fact is hardly a cause for controversy. Feel, both helps by getting the other person emotionally involved and by limiting options for confrontation, by acknowledging your feelings and stories subjectivity. Need, makes the transition from your subjective observation into the objective realm, by keeping the the need or change general, you limit the options for confrontation again. Talking about a need in general helps with involvement too, who would not like to help, in general? Request, finishes the argument, giving your request for change a concrete form and direction. Because that’s what we are here for, after all.
Observe, Feel, Need, Request
Observe, Feel, Need, Request is an equally simple and powerful structure to deliver engaging feedback. To get a taste beforehand, check out Charles Dein’s examples on how not to deliver feedback.
… we are paid to solve problems. That’s it. We are not paid to sit in silos, mumbling about who ought to fix what and abstracting away responsibility. Still, in a great deal of meetings, tickets, heated e-mail exchanges, we play responsibility ping pong. Hurling “the problem” back and forth, burning energy, time and money. Not in order to solve the problem, but to get somebody else to solve it.
Both a critique of current software development practices and an erratic deep dive into software development history: Systems Past: the only 8 software innovations we actually use.
Well worth your time. Not only if you are interested in a history of software innovations, but also a refreshing way to learn or brush up on some basic software development concepts and their origins.
Awesome advice from user rckclmbr on hackernews for anybody aspiring to become a senior dev. Which happens to also apply to anybody else wanting to grow and become a master of his trade.
- Don’t strive to be a senior developer. Strive to solve peoples problems through technology.
- The quickest solution is generally the best solution — or at least helps you understand the problem better.
- Build relationships with people. Be their friends.
- Keep meetings to 30 minutes. Always have a takeaway from a meeting.
- Hold yourself accountable.
- Don’t be an ass.
What are your highlights? Here is the complete list.
What’s the base of negotiating hostage situations, trying out exotic sex practices and working remote? Communication, communication, communication… Sharing some ideas on how to work remote, while being awesome at it.
“He does know, we are 6 weeks behind schedule, right? – Well, I’m not going to be the one, who tells him, we are that far behind…”
Repeated on every level, this is the simple mechanism enabling projects to get incredibly, absurdly late, expensive and under performing without anybody noticing, or, to be more precise: Wanting a superior to notice.
A Recipe for Disaster
Every time a team member decides it is the better choice not to notify his or her superior about a threat to project success this is a crisis in the making. Every time a superior decides not to want to know about an issue, or even punishing the messenger, he encourages a culture that makes the imminent problems ever harder to solve. Until there is no going back and it all ends with a catastrophe or a very, very close call.
You are Going to Fail – Deal with It
If people refuse to take responsibility or worse, punish others for doing so, is going to make your project fail, in one way or another, sooner or later. Projects are hard, planning is hard, there will be delays, dead ends and workarounds, let’s acknowledge and deal with it, openly and transparently.
Loved all three seasons of Silicon Valley, by the way.
Google Audio Ads, Google Print Ads, Orkut, Google Wave, Jaiku, Google Buzz, Google Video, Google TV, Nexus Q, Google Checkout, Google Glass and last but not least Google Plus – Steffan Heuer and Thomas Ramge try to write the story of #Google #Fails for Brand Eins.
Apart from giving rich testimony to the fact, that there might be no such thing as “the rules for success in the Internet century” (the tag line of a recent book by former Google CEO Eric Schmidt), it also offers a nice overview over Googles long and colorful history.
Bottom line: “It does not look like their ultimate goal is world domination.”