Arguably, the most frequently asked question from an engineer is: 'When will this be done?' And yet in our engineering principles document we stipulate that 'we don’t do fixed time/fixed scope work'. No wonder, this is one of the most frequent questions that different parts of our organization are asking about: 'How can we make an agreement or sign a contract if we don’t have a fixed point in time when we can all agree that something will be ready for our clients?'

We support teams in deciding how they work, mob programming, paired programing, individual work, or a mixture of all three.

Downtime sucks, regardless of whether it’s planned or not. As a user, when you visit a site to complete a task but you can’t because it’s down, you’re frustrated. Whether or not the site put up a cutesy banner a week earlier warning you about the downtime isn’t really relevant. Banner or not, you can’t complete your task.

Production issues and bugs are a common albeit frustrating part of software development. Imagine a tale of two organizations, with different approaches towards addressing this problem.

Remember when you were little and someone told you a secret? Whether it was someone they liked or a funny story they heard, you felt excited that they trusted you and that you knew the secret. Fast forward to the present day. Carli is a software engineer who has worked at the company since the very beginning. She has a secret, the knowledge of how the reporting module works.

Your team has been discussing a great new feature with some stakeholders. Everybody is really excited until… the question that every engineer dreads… So when can you have it done by?

Let us consider the value proposition of flow efficiency.

What we hope to experience while working on a cross-functional team.