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 [...]
Previous Topic
