A number of the Atlassian team leads recently went through a variety of leadership training courses, ranging from the leadership of individuals, teams and, stakeholders and change. During one of our workshops, we were tasked to convert the eight step process of creating major change theory to align a little more closely to the terminology/cultural values and understanding of Atlassian.

Whilst somewhat humourous, I think what we came up with encompasses more of an Atlassian truth than we realised. Please excuse the colourful language – call it an Australianism if you will, we think it adds impact.


1. How fucked is it?

The lives of software developers is all a matter of fuckedness. We are in a constant battle with legacy code, impeding release dates, lack of sufficient resourcing, external competitors – in essence, everything is always suboptimal. If we want to introduce change, we first need to identify just how bad the problem is, in the grand scheme of things. Often urgent issues get raised at the pub. Don’t ignore them, take the beer away and drink twice as much when the issue has started to improve.


2. Who’s going to fix it?

So you think we’ve got a problem which is worthy of being more screwed than most of the other problems around you. The second stage is being able to identify who can adequately instigate the change that is required to fix your problem. One of the core values of Atlassian is Be The Change You Seek, however “btcys” does not necessarily mean that we individually need to be movers of said change. The responsibility we have to ourselves, our team and Atlassian is to allow the change to happen, by whichever channels are most appropriate. You want to get something done? Consider delegating it to the person/team that has the most relevant experience and capacity to do it. Own it or not, make sure the right people are on the job.


3. Show me what you mean – and ship something small!

You think the problem you’re dealing with is big enough to go through the Atlassian Eight-Stage Process of Creating Major Change Process™. Invariably, any solution you might have will require proving to your stakeholders that your solution is the best one. In engineering, we call this prototyping or spiking, but it is just as relevant to our other departments. Try new things, try them soon! We often call out that we simply don’t do this enough – don’t be afraid to fail, as this will allow us to minimise the cost of change and still attempt to resolve the core issues.


4. How will you get there?

Once the initial spike is successful, it’s important to communicate with your stakeholders just what the plan will be. Call them sprints, milestones, targets, endpoints or whatever you want. Making sure you have a clear plan which can get you buy-in and support from those surrounding you.


5. Refer to Step 3 if necessary. Remember to iterate!

Hold up – sometimes strategies fall apart after we start moving at pace. That’s fine. Iterate and refine where necessary and don’t be scared to go back to the drawing board and prototype or whiteboard a new strategy. It’s better than digging yourself into a hole. Generate wins faster and more frequently. It’s good for morale, and it’s good to show those around you that change can happen and can happen right.


6. Share responsibility.

Delegate pieces of responsibility to those surrounding the problem and impacted by it. Empowering more people to be part of the solution can help ensure success in your change by holding more individuals and teams accountable to prevent the cookie from crumbling (yes, it can be avoided, no matter what that idiom says!)


7. Keep shipping.

Reckon you can go it alone in the dark? Think again. No major change can happen overnight – ship incremental wins early and often. This will help you keep friends and allow you to iterate as required. We all know how quickly ideas slide into irrelevance and how quickly they slide down the “how fucked is it” scale, so readjusting expectations and targets will help keep changes relevant and in the forefront of everybody’s mind. Don’t bog everybody down with meetings to make simple decisions though (remember about decision making authority). Share responsibility, but be the law maker when required.


8. The Sigmoid Curve.

It’s done. Your change is made – congratulations. Except you’re a twit, because you didn’t take the sigmoid curve into consideration, and whilst you were busy riding your pony at the top of the rainbow things are already falling apart. Readjust and reset expectations. We need to realise when we are riding a bull market – so that we can jump ship to make changes which will allow us to continue riding upwards (you know, to infinity and beyond).

Keep moving, don’t forget about that thorn in the corner, Gestalt’s paradox of change.

“I will call it the paradoxical theory of change, for reasons that shall become obvious. Briefly stated, it is this: that change occurs when one becomes what he is, not when he tries to become what he is not. Change does not take place through a coercive attempt by the individual or by another person to change him, but it does take place if one takes the time and effort to be what he is — to be fully invested in his current positions. By rejecting the role of change agent, we make meaningful and orderly change possible.”


I think we learned and accomplished a lot during these recent leadership training courses that we participated in – and I hope we’re able to continue to break down one of the big barriers that I’ve heard repeated over and over again within the company: information silos. Put a group of (relatively) disconnected people in a room with a common vision and set of goals, and we create amazing things. This is obvious in our engineering efforts by our products, but I think we’ve realised how much more we can grow by gathering leadership and vision experience together, too.

This is a few of us, making just a few changes:

 Making change at Atlassian

The Atlassian Eight-Stage Process of Creating Majo...