Nothing to Hurry About – How to Manage by Purpose instead of Urgency

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.

Wir sind die Roboter – Why and how to build a chatbot

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?

Deliver Engaging Negative Feedback

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.

  1. Observe: Start the conversation with a non-controversial fact.
  2. Feel: Express how you personally feel about this fact, while emphasizing the subjectivity of this feeling.
  3. Need: State the general need you have, the general change you would like to happen.
  4. 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 Not Paid To Write Code, Configure Machines, Create Project Budgets…

… 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.

Responsibility Ping Pong

This is equally tragic and ironic. Ironic, because most people got into the business due to their love for solving problems, for hacking at and fiddling with things for hours on end. Tragic, because the problem is not going to go away. While we discuss who does what, a system remains broken, a key feature unusable, a service inaccessible, a project on the brink of failure and a deadline likely not being meet.

Hurting Ourselves

Bunker mentality not only hurts the business side of things, it also badly affects our teams, co-workers and lastly ourselves:

“I often see people measuring their worth in code, in systems, in tools […] I see it come at the expense of attending meetings. I see it at the expense of supporting other teams. I see it at the expense of cross-training and professional development.” – Tyler Treat @ Brave New Geek

Not My Job

Despite these adverse effects, we are often going to retreat to our job title and description to fend off “unjust” calls to action and responsibility. This “Not my job” attitude and argument has been facilitated by the rapid fragmentation of roles in the software development field: “I would like to help you out, but I cannot, because I lack the knowledge of the XY guys…”.

Focus != Concern

Which is true – and missing the point. Diversification of roles/”abstraction is not about boundaries of concern, it’s about boundaries of focus.” Exactly because the knowledge involved is too vast, the systems and their interactions are too complex, we need to be extra careful before pulling out, handing off responsibility, denying others access to our information and ingenuity.

We The Team

Solving problems more than ever has become interdisciplinary teamwork. Therefore…

“[We need] understand that [we] are not defined by [our] tools but rather the problems [we] solve.” – Tyler Treat @ Brave New Geek

Great inspiration by : You Are Not Paid To Write Code.

The Only 8 Software Innovations We Actually Use

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.

Image: Klaus Nahr from Germany, Zuse Z1 – Flickr – KlausNahr (3), Mirrored, black & white edit, curves adjusted, CC BY-SA 2.0

Don’t Be An Ass – Or: How To Become A Senior

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.

My highlights:

  • 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… Working with each other is about communicating with each other. Which is even more true, if you are not in the same room, floor or building. Paradoxically, the harder it get’s to communicate, the more you need to do it. Remote work is not less, but more communication, as you need to compensate for a lack of physical presence by overcommunicating.

Acknowledging this fact is the first step. Meeting this challenge for remote work with some great ideas and deliberate effort is the second one.

A Toolbox For Remote Work

For inspiration in regards to processes and tools check out TailorDev’s setup. They rely heavily on asynchronous communication via Slack and Github, use a pretty neat bot as a mini-command line and communication advocate as well as an interesting mail app to better structure communication and enhance transparency.

Three Principles For Remote Work

The three principles of remote work at Groove are also worth a look: 1) Recreating the Water Cooler, 2) Setting A Regular Meeting Rhythm and 3) Hiring Great Remote People. While a virtual water cooler (Slack, again ;)) helps with everything from getting status to bonding personally, short, structured meetings will help getting everybody on the same page professionally. For “Hiring Great Remote People”, well, that’s simply a banality hiding a more interesting insight:

Working Remote: It’s All About Attitude

“[Remote] is a mindset first, following by great tools and processes. It does not work because we are a small team, it works because we do everything we can to make it work.”

Water Melon Green

“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.