Commit as a team

Here at Easy Agile we have a core set of values which we use to guide our principles and daily practices. Over the next few months we’ll be writing about each of these values in turn to give the outside world a deeper understanding of what these values mean and why they're important to us.

The value that we are discussing here is commit as a team, which we define as “We grow and succeed when we do it together. We commit to bringing our whole selves to work, to looking after one another, and to engaging with authenticity and courage.”

Pretty easy to read and understand, less easy to put into practice. Let’s go ahead and explore this value.

What is success?

What does success mean in the context of your job? In order to define this we can go back to business 101.

A business sets out with a mission, this could be a basic as “make a shit load of money” (aka maximise shareholder value) or as complex as “accelerate the world's transition to sustainable energy”. To win in this case is therefore to complete the mission but how do we chunk that down into achievable (agile sized) pieces. The mission is generally supported by a set of values. From the mission and values come strategic goals. We then setup projects (in our case opportunities) to support these goals. The projects can then get further decomposed into stories which get broken into tasks and then right at the end of the chain you will find yourself sitting at your computer on a Monday morning staring a some code on the screen, completely lost in the minutia of naming a function, a broken test or some bizarre if statement you wrote two hours ago which already makes no sense.

By effectively setting work that ties into our overall mission we make sure that our work contributes to the overall success of the business.

Committing as a team is a better way to work

Now that we have defined success what is the easiest way to achieve it? Well, here’s a false paradigm that seems to have emerged in the tech industry over the last few years - “The individual is more important than the team”. The term individual contributer has only been around for a few years but the effect has been profound. In the wider world we have also seen the rise of social media which has pertained to a move towards self-centred culture. We are being conditioned to spend more time alone scrolling through individualised feeds and to believe that we are the centre of our own personal universes. This all leads to our collective egos believing “I am important”, “I am special”, “I am more important than the team”. This means that as individuals we actually have to work against an awful lot of external input to genuinely commit to being part of a team.

With all that said, we could still choose to “individually contribute” to the mission in isolation. For me that looks like 80 hours weeks locked in a broom cupboard writing data flows and APIs with little to no contact with the outside world. Does that sound optimal to you?

At the other end of the spectrum is a collaborative approach where you are in constant contact with your customers, team members and look to deliver incremental value with the smallest amount of effort possible. If you accept that this is a better way to work then it is not too much of a jump to concede that committing to the team is more optimal than individually contributing.

A note on the ego

We all have one. We are all susceptible to warping our version of reality to fit a narrative that makes us the hero. In order to give yourself a chance to succeed, you have to subordinate your ego. The pursuit of excellence starts with beginners mind. Humility is a key factor in nearly every endeavour.

The whole is greater than the sum of it’s parts

I actually arrived at committing to the team being a better way to work through a very selfish path. I am an impatient person. I hate things dragging on. I was super frustrated with the amount of time that my code was “stuck in review”. The feedback loop with reviewers seemed to go on forever, they would ask for a change, I would immediately make the change and then wait for up to a day before the reviewers came back round and reviewed again. One of these loops could be bad enough but two or three would be enough to make me want to smash another keyboard, blame the reviewer for being pedantic and move on to something else.

After a few weeks of existing in this infinite loop I realised that the problem was actually with me!

The reviewers were overloaded with not only reviews but their own work. I was contributing to their work load by not investing the time to properly self review my code OR make it as readable as I could OR fully test all of the functionality. I worked out that any feedback I received was because I hadn’t invested the required effort up front. I also hadn’t built effective relationships with the reviewers. They didn’t trust the quality of my work and were right not to.

Very quickly I adjusted my style and quality to that required by the team. This reduced effort for everyone else involved in the process and ultimately led to value being shipped to customers far quicker. Work went down, productivity went up. This reinforced to me that when the team wins, the individual wins. Win, win, win, win.

What does putting the team first look like?

1. Accept responsibility for you actions and take ownership of everything that you do.
2. Assume any problem you have starts and ends with you. In almost all cases this will be true. Ask yourself “what can I do to help the team succeed”.
3. Question whether you are adding or subtracting value through your work. Consider your team mates, consider the effect that the work you do has on others. Code is far easier to write than it is to read. Does increasing complexity in the code that you write deliver enough value to warrant the brain power required to review the code (and to maintain it)? Could you make the lives of your colleagues easier by changing your approach?
4. Spend more time enabling others. Set out specific times when you are available to answer questions. Promptly review code and provide useful, actionable feedback or approval. When reviewing code ask yourself whether or not your feedback will help the team.
5. Provide radical candor, this is the most challenging one but being fully committed to the team means being authentic and honest. It’s hard to see your own blindspots but by cultivating honest relationships hopefully you will be lucky enough for one of your team mates to share some of your short comings with you. You should strive to find a productive way to do the same for them.

Finally

We are always looking for top talent to join us and pursue finding a better way to work. Swing by our careers page if you would like to apply to commit to a high performance team. If you’d like to discuss this post further then hit me up on LinkedIn.