Stackshare did some (big) data crunching. Analyzing over 40 000 technology stacks and plenty of other data they identified the most used developer tools in 2016. The Top Developer Tools 2016 is a great read. Not only in order to get an idea what happened last year and what will be happening this year. But also in order to stumble upon a new tool or two.
But, it’s urgent! We are late! We need to hurry – our client expects this. There it is, a stakeholder calls to put “a bit of pressure” on the team, to “go the extra mile” or “work double as fast”. All in order to meet a milestone, deadline or sprint goal. And as you crack your whip and shout “Faster!” your team miraculously pulls through – another crisis averted, another deadline meet.
Or not. Because this scenario rarely plays out like that. And even if it does, managing through urgency comes at both a high risk and price. Let’s take a closer look and evaluate if there is an alternative.
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.