communication

Communication, General, Teams

Hitting Refresh

Unlearning is one of the hardest parts with any transition. You bring with you many years of experiences, expectations and biases. These have built up over time through different work situations you have adapted to. Past experiences allow you to hit the ground running when it comes to work and communication. They can also be heavy baggage, slowing you down. In a startup this baggage could be the very thing that’s holding you back. You’re looking at completely new problems with views that don’t match your situation.

Here at Dolittle, we’re hitting refresh on many of our previous assumptions. Looking at old problems with fresh eyes. How we approach our coding practices. How we are working with customers. How we are approaching contracts. How we are building products. We’re re-learning, and allowing our culture to grow.

“If your mind is empty, it is always ready for anything, it is open to everything. In the beginner’s mind there are many possibilities, but in the expert’s mind there are few. ” –Shunryu Suzuki

An example is communication. Coming from a very distributed team, a few of us wanted a more formal process. More documentation, more written communication. This is important down the line as we grow, but not so much in the beginning when priorities change almost daily.

Hitting refresh is an important part of starting anything new. Making it explicit that you need to take a step back and reconsider your expectations. You’re going to have new problems and you can’t deal with them if your focusing on solving the problems you had in the past. At the same time, it’s importatnt to leverage universal learnings and principles. It’s also important to recognise the context in which those are valid.

Are they really valid to you now?

Photo by rawpixel on Unsplash

This post appeared originally on the Dolittle blog

Communication, Developer growth

Quit blaming others. It’s your fault!

When working in a team trying to deliver software things don’t always go right. Quite often they actually go wrong. Sometimes though they go so wrong that there are consequences for others. And when things go wrong, someone is to blame.

It’s natural to protect yourself and make sure all attention is on the next person by blaming and pointing. Perhaps you just sit idly and let others deal out blame and this helps you get by on a day-to-day basis. If you and the people around you are dealing out blame, you aren’t only making it bad for those around you, but for yourself.

Continue Reading

Communication, Developer growth

Use Emoji to improve communication in your distributed team??

You’re sitting there, writing code for another feature request and a message pops in. You know it’s important, since it’s a direct message. You glance at the notification and see the words:

Dev: “You broke the build…”

You click the notification and get taken to the 1-on-1 chat, where you read:

Dev: “You broke the build, you fix?

Short and to the point. An efficient message. Perhaps not the most effective though, since you’re sitting there and scratching your head. You’re feeling annoyed. Not because you broke the build, nor that this person let you know about it. It’s because you can’t seem to get hold of the feeling of the person behind the message.

Are they irritated? Maybe mad? Possible stressed out? None of the above? The uncertainty of this can easily put you in a negative state of mind, and that won’t help with collaboration. Continue Reading

Developer growth, Practice Empathy

Leading teams with Empathy -Providing Psychological Safety

As a technical team lead, you are in a unique position to facilitate the growth of your team or watch it spin out of control. You can run it with an iron fist or meekly get overrun by strong forces. You can encourage psychological safety or allow watch things fall apart in a toxic environment.

What makes or breaks a team? How can you bring out the best in the people around you? What can you do as a technical team lead to ensure the success of your team, and as an extension your product? Continue Reading

Craftsmanship

Capturing Intent – Making sense of code

Picture the scenario: You are staring at the computer screen and scanning the lines of code that fill it. You scratch your head and think: Why?

You debug the code, step-by-step and see a method call that sticks out like a sore thumb. It’s doing an out of process call to another subsystem before the code has completed its job in this method.

Why is that out of process call made there? There’s no documentation explaining why. Moving it to the end of the method makes more sense, but then everything breaks. WHY? 

image01

As a software developer, you might have experienced situations like this. You’re looking to fix a bug or extend a feature and you stumble over code that just doesn’t make sense.

You can see what it’s doing, even understand how it’s works, but you just can’t understand why.

In this post I’ll show you why making the extra effort to capture the intent of the code is so important. Continue Reading

Agile, Developer growth

Trusting in the Mob – A story of bringing distributed team members closer

Working in a distributed team isn’t easy, especially when members are spread across 4 locations. I was recently part of a team that was doing pretty well, but wasn’t functioning as a cohesive unit. There seemed to be hesitance towards pair-programming sessions, even though doing quick Skype calls seemed to be fine. We were relatively open during retrospectives, but were missing out on the deep conversations.

I had a feeling this was a trust issue, and that spending more time together could help. Sitting in an online meeting doing team-building exercises didn’t seem like the best approach, which is when I stumbled over Mob Programming as a way to both get work done, and build up the team’s collective trust and understanding. Continue Reading

Agile

Accepting that every team member is doing the best job they can

Many software development teams have a process including retrospective meetings. An opportunity for the team to look back at a period of time and assess how it has functioned. It’s often connected to the Scrum, but you don’t need to be adhering to any process / approach to see the value of having retrospective meetings. The goal of the retrospective is learning. What worked? What didn’t work? How can we improve something that’s broken? Should we continue with something that’s working?

Another aspect of the retrospective is that it’s meant to be a safe place for team members to speak their minds. The idea being that given a safe place, a team can figure out its own problems and possibly even solutions.

To create that safe place there needs to be trust. Enough trust so that team members can be candid with each other about issues that arise while working together. Enough trust that allows the team members to be vulnerable, and know that they won’t be judged. Where blame isn’t handed out, but rather bonds created and learnings are formed.

But how do we create a space in the busy life of a software development team, where deadlines and bugs are commonplace and there’s often a pressure to deliver something that will create value? Continue Reading

Developer growth, Practice Empathy

Examples of “Radical Candor”

I recently wrote about candor as a better way to achieve truly open and honest communication. Candor Inc created the framework of “Radical Candor” as a way to categorize your feedback and communication.

radical-candor-2x2
Radical Candor chart.

What I didn’t do in my previous post, is dive into how the different ways of communicating actually would sound like. In this post I’ll explore the framework more deeply and also look at an example.

Continue Reading

Developer growth, Practice Empathy

Communicating with Candor – when honesty alone isn’t enough

Working in any team environment will involve communication between its members. To really bring the best out in others and yourself, having a culture of where honesty is important. It’s also something almost anybody will verbally agree to. Yet being open and honest in a good way is extremely hard. How often do you refrain from saying something completely honestly because you don’t want to embarrass someone. Or what about the time somebody called you out on something in front of the team? Sure you may have needed that feedback, but what happens to your relationship with that person? What about the team dynamics?

Blunt honesty can not only be harsh, but downright devastating to hear. How then are we meant to move beyond the complications of honest communication and get to a place where our being honest actually provides room for everyone to grow? Continue Reading