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, Teams

Please, break the build!

The feeling when you hit the button and push the code to server. You’re done! You’ve implemented a new feature that’s going to be ready for the end-user. Soon. You see that the code has reached the build machine, and a new build gets scheduled. You get up to take a quick break and end up chatting with a few colleagues on the way. When you get back you see there are 10 messages in your inbox and the same number of notifications on your team chat.

Looking around, you see that the scheduled build has failed. And now there are 5 other schedules builds that ended up failing. It looks like you’ve just broken the build. The rest of the team of 20 developers are now blocked from committing in their code.

You sit down feeling… Continue Reading