When I reflect on how my real-world experience shapes my training style, I realise just how pivotal my journey has been. I began my career as a software engineer, diving into the world of coding just before .NET emerged. My first year was spent with ASP, but once .NET came along, I found my sweet spot. This foundation has been instrumental in my understanding of software development and the intricacies of the industry.
In 2008, I was honoured to be recognised as a Microsoft MVP for my work with Team Foundation Server (TFS). This accolade opened doors to a wealth of resources and connections, particularly the annual MVP Summit in Redmond, Washington. Imagine three and a half thousand MVPs from around the globe converging in one place! It was an incredible opportunity to network and learn from some of the brightest minds in technology.
During my time as an MVP, I was part of a tight-knit group of 80 to 90 professionals focused on DevOps and Application Lifecycle Management (ALM). This was a transformative period as DevOps was just beginning to gain traction. I absorbed knowledge from my peers, which not only enhanced my skills but also allowed me to impress others in the field.
My journey took me to Australia, where I worked remotely for a year with Adam Cogan, before moving to Seattle as a DevOps consultant. Over three years, I had the privilege of working with various clients across the United States, spanning 15 different states and numerous industries—from aerospace to healthcare and even finance. One particularly memorable project involved a finance company that managed the finances for Hollywood stars. Their building was mostly empty, save for one floor dedicated to their operations.
This diverse experience has equipped me with a treasure trove of stories. I’ve encountered organisations facing challenges that often seem insurmountable, yet I’ve always found that there’s a silver lining. When I share these stories during training sessions, it resonates with participants. Knowing that others have faced even greater dysfunction can be a powerful motivator. It instils hope and encourages individuals to believe that improvement is possible.
In my training, I emphasise the importance of learning from both successes and failures. I often recount instances where certain strategies didn’t pan out, highlighting the lessons learned. This approach not only fosters a culture of openness but also encourages participants to engage more deeply with the material.
As a Professional Scrum Trainer (PST), my background as a software engineer lends me credibility when working with teams. I’ve been in their shoes, and I understand the challenges they face. My years as a DevOps consultant have provided me with a broader perspective on the processes surrounding software development, particularly the journey towards continuous delivery. I firmly believe that there is no software on this planet that cannot move towards continuous delivery.
Ultimately, my experiences form the bedrock of my training and consulting efforts. They inform the classes I develop and the insights I share, aiming to empower others to embrace change and enhance their practices. My hope is that through sharing my journey and the lessons learned along the way, I can inspire others to embark on their own paths of growth and improvement in the ever-evolving world of software development.
How does my real world experience translate into my training style? Well, I think they’re neat for that you to a little bit understand my experience, I guess. I was a software engineer for 10 years. I just got into software engineering the year before .net came along. So I was ASP for a year and then straight into .net and that’s where I’d really been ever since. I mean, I do other things, but that’s mainly where my sweet spot is, right? My comfort zone.
And then I got recognised by Microsoft as doing some interesting things with Team Foundation Server. I was that was and I became a Microsoft MVP in 2008. And then what really happened was you got when you become an MVP, right? You kind of get access to a whole bunch of internal stuff. You get access to lots of free tools and lots of things, but the big thing is you go to the MVP Summit every year. The MVP Summit is three and a half thousand MVPs from all over the world, all the different countries, all the different technologies, all descend on Redmond in Washington State in the US.
We basically take over the whole of Redmond, all of the hotels for a week, and Microsoft puts on a whole bunch of sessions and events and all kinds of things. So you get you start to get these personal connections with all sorts of other people in the organisation. But my experience was my competence was TFS, kind of TFS DevOps, ALM was that space. There was between 80 and 90 MVPs in that category, and this was a really tight-knit group because DevOps was emerging at the time. It was definitely loads of people who were at the top of their game, right? Because they’re into all these different things and technologies and coming into that world and writing a lot of content in that world and really understanding what it is that we’re trying to do with DevOps.
I leveraged a lot of their knowledge. Absorbing all of their ideas allowed me to then, I guess, impress some of the people there. I worked for a year remotely for an Australian company with Adam Cogan, and then I got hired by Steve Borg to go live in Seattle as a DevOps consultant. I spent three years, I think it was, ALM, right? Application Lifecycle Management, a bit DevOps consultant for three years in the US. I effectively had a different customer every week or a different customer every two weeks across the US, so I think I spent time in about 15 different states.
I saw all the industries. There’s no specific industry that DevOps is relevant for. It’s any company that has software. So we did aerospace, we did military. I think I didn’t work on that project, but the nuclear power plants, healthcare, finance. I did a gig for a finance company that does the finances for all of the stars in Hollywood, and so they have this huge building and they only have one floor at the top, and the rest of the building’s empty. It was really interesting.
But that experience of seeing all these different organisations, seeing what they’re doing, seeing how they’re treating and engaging people means that I almost, I think I’ve never had a circumstance where I don’t have a story for where there’s somebody else that’s more dysfunctional than whatever the person that’s talking to me, the story that they have. So I think that’s a huge power in the training world because you want the people that you’re training to realise that there’s light at the end of the tunnel. You want them to realise that they can get to somewhere else, and unfortunately, I think this is a very human thing. Knowing that somebody else is worse makes you feel better, right? And it makes you go, maybe I can be less worse, right? Maybe I can.
So then I’m listening more and engaging more. I think those stories help from that perspective, and also bringing the stories of how people have solved particular problems or even things that haven’t worked, right? Oh, I’ve had a couple of customers that I’ve tried that this way, and it’s just not worked for them at all. They just had to ditch it. I think that is one of the core characteristics of not just me as a PST, but most of the PSTs that I interact with are people that have worked in industry, that have worked with lots of customers, that have all of these stories.
There’s nothing more interesting than a whole bunch of PSTs getting together to have a conversation about all these crazy things that have been happening in organisations because then you can share those stories and bring more things to the table when you’re training. So I feel like that experience of being a software engineer, right? That’s one thing that lends me credibility when I’m working with people in teams that build software because I have been the person building the software. I understand how that works.
The seven years as a DevOps consultant is that little bit level above all of the processes around how we build software, moving towards continuous delivery. Being able to categorically tell people there is no software on this planet that can’t move towards continuous delivery, right? There’s no pulling the wool over my eyes for capabilities in that space.
And then moving into training and agile consulting means that all of that stuff is the foundation upon which I’m building the classes and the courseware and what I’m trying to do and what I’m hoping people will learn and engage with and find out more about what they can do.
