The day I was right

Today, just before I was going home for the day, one of my team called out to me and said “you’ll be glad to know you were right!”

Wow! I wish I had recorded it! Because I’m sure there won’t be many times now as I transition from a technical role to a leadership role where I’ll be right on technical decisions. 

We have a major project on right now to migrate and upgrade many things and a challenge came up during the project. It was called out in one of our stand ups. The technical decision made by the team member was to build a new file server rather than migrate the existing. He explained his reasoning and they were all valid points for making that decision. 

I then raised my concerns such as the extra considerations needed for the change in the project scope, the extra work migrating other services on the server, the problems I’ve had in the past with DFS and so on and so on. It was very clear I was opposed the decision but I have empowered my team and they have taken ultimate responsibility for the success of this project… and against my better judgement, I allowed them to carry on. 

Needless to say, the issues with the new file server were more than the issues with the existing file server and that’s why I was right.

Even though I was right, and felt that I would be right from the start, it is important for the team to know that it is ok to try and fail. And that while they continue to learn from their failures, I will always have their back. 

Until next time.


Driving Digital Disruption

Today, I attended an event about driving digital disruption beyond 2020.

One of the key messages about today’s event was that the rate of change in technology is at the fastest it has ever been. Quite frankly, I couldn’t agree more. Even discussing this further with others attending the event, they shared concerns about just how fast vendors are developing new technologies that even channel partners selling these technologies are having a hard time keeping their staff trained and up-to-date to know enough to sell, design and implement these technologies.

There were some other interesting points about how IT teams need to change and become more of an enabler of the business. Teams need to focus efforts on transitioning, or maturing, through the following steps to really drive value to the business and build a true partnership with the business:

  1. Provide Stability
  2. Continuously Optimise
  3. Increase Agility and Business Responsive
  4. Drive Business Innovation and Experimentation

It also raised a question as to “What’s stopping us?” This is a valid question. One that I don’t believe is asked enough or thought through enough. What is limiting our speed to deliver business value? What are the constraints holding us back? True disruption and innovation will come from those that have taken the time to understand these questions and find ways to work around them.

It is interesting, because today, I feel that there is so much that me and my team could do to really drive disruption in our organisation and our biggest challenge is prioritising some time to being innovative when everything we work on is top priority, or worse… urgent!

Talking to others after the event, it really was apparent that this is a common thing. Finding that even someone working in a very similar role as me for a much larger organisation in a similar industry also has the same challenges I have around disruption and innovation in technology, and in processes in his organisation.

IT Leaders probably have some work to do in educating Business Leaders more about how technology can be better leveraged to improve key areas of the business, such as the Customer’s Experience, the Employee’s Experience, Operational Processes and the overall Business Model.

How you do you drive disruption and innovation in your team? What challenges do you face?

Until next time.

6 ways to create an amazing agile team | Atlassian Blogs

Today, as manager of an IT Operations team, that also has a backlog of initiative work for improving business systems and tools and works in a business that is transitioning through Agile practices, it has been a real challenge getting a typically waterfall type team to jump on the Agile bandwagon. I’ve been selling it to the team for more than 12 months now though today’s team has changed significantly since the team 12 months ago. 

My team has more focus on its responsibilities. More experience and skills. More thoughts and more questions. 

When selling Agile, it has been tough. It is challenging for me and the team but I don’t believe it is impossible. I had even been asked to revisit the reasons why I believed in using Agile in our team. 

This article from Atlassian, I believe, explains the key things needed to have an Agile team… and most importantly… it doesn’t have to be a development team.

For me, the transition continues and I have all the patience it takes, so long as we continue to change and adapt to our learnings. Even if we are an IT Operations team. 

Until next time!

PowerShell: Remembering PowerShell Module Names

This is a small and simple post. I don’t know about you, but I am always forgetting the correct wording of a PowerShell Module that I need to import before I can start typing away the PowerShell cmd-lets I am trying to use. So, instead, I remember this:

Get-Module -ListAvailable

Doing this shows me the available modules and I can then enter the Import-Module command I am after, instead of trying to guess what the Module Name was.

Until next time!