Back in 2012 we recognised that the customer landscape was changing. Large traditional companies were forming agile teams, implementing a DevOps culture and exploring lean methodologies. The application landscape was also shifting. In a desire to move fast and innovate, cloud native applications were being built that broke applications down into microservices and split out dependencies so they could be run independently of infrastructure.
Image source: https://icons8.com
While application teams were changing, the silos of traditional IT teams were not. Cloud should have been a term to define transformation of IT infrastructure teams to a new operating model, but instead became a word that described outsourcing the running of IT to a few hyperscalers. Many CIOs became frustrated that their infrastructure teams were too legacy, too slow and not agile. How could you become a digital business when opening a firewall port or creating a new VM took months. Business users wanted to be able to dream up new ideas in the morning, test those ideas with customers in the afternoon and scale them that night.
In our business we realised that we needed to change. The people we hired needed to not only have different skills, but they also needed to think differently and be part of a new sub-culture that was forming in the industry. We had all the tools, products and platforms to help a customer on this journey, but this journey is 90% people and process. Tools and products are only an enabler for the customer journey.
We needed to transform to stay relevant to our customers.
We also needed to transform before we could transform the infrastructure teams within customers.
Our first approach was a good leadership learning lesson on what not to do when transforming a team. Luckily we failed fast. I had set about to excite the entire team on the new world of IT. And while some, maybe 20% of the team was inspired by the new journey, the rest of the team was not bought in. The majority were on the fence, but a part of the population, the last 20%, was seething and I had missed it. Eventually I had feedback from a senior leader that the team felt “in Matt’s world, if you are not DevOps, you are nothing”. The biggest problem was that this 20% was critical to keeping the lights on and running the most important part of the current business. I had failed at making this important part of the organisation feel important and needed.
We had to pivot.
And so in 2015 the idea of project piper was conceived. We would take those 20% that had a desire to change away from the rest of the team and run a talent program that would both educate and inspire them. They were asked to not talk about what they were doing with the broader organisation. The first rule of piper is you do not talk about piper. The second rule or approach, was that we had to identify those that were critical to keeping the lights on and ensure they were feeling equally recognised and rewarded. The core part of our team had to feel as important as the transformed part of the team.
As team members came to piper they would hear from industry experts on how the world is changing. They would visit pivotal labs and see DevOps in action. They would attend a meetup and start to experience the new sub culture that was forming. They would read books like the Phoenix project and the new kingmakers. But most importantly they would experience by doing. They would leverage github to share code, push code to cloud, build out microservices, do stand ups and work with Kanban boards. They would estimate work effort for sprints and connect the physical world (through IoT) to the virtual world. We would also talk about culture and identify symbols to represent it. We would house the team away for the week, in some grungy but funky location. Jeans and hoodies would be essential (a clear no suits rule). And at the end they would showcase their work by building a project combining what the have learnt into something unique. The understanding and experience of agile and lean was equally important to creating and building new application architectures.
We knew over time that word of piper would spread, and that was part of the plan. Some team members would eventually say what’s this talent program I have heard about and how do I be part of it. And those that did could join. We structured piper in waves. The 3rd rule – if you attend one wave, your role is to lead the next. You give back by teaching others what you have learnt.
In one piper program the team tackled a social good cause. They had an idea to help solve an issue in the US around service animals. So they built an MVP – effectively a prototype of an application that could be used by a not for profit who is trying to address this issue. During this program I found that prior to joining the program some of our team members had never written a line of code. And yet here they were solving social problems by building a cloud native application.
I often get asked where the name project piper came from. A core theme of the program is the TV series Silicon Valley which follows the journey of a startup called pied piper. We wanted our teams to innovate and think like a startup. We also wanted the attendees to lead others, much like the pied piper of hamlet led through his flute. We wanted those around to be enchanted by what they were seeing happen to those that were transforming. It’s also part of making the program fun and interesting.
Thank you to the first pioneers of the program – Danny, Vedad and Dean. And to those who carried it forward – Lloydy, Alberto, Arron, Theo and many others.
Piper has now been run dozens of times with many waves. We have scaled the program to China, India, Japan and South East Asia. It is no longer a hidden program but something that team members can choose to be part of it. Now we are open sourcing it, taking it to our customers and partners and sharing our learnings so that they may build on what we have done, innovate on the program and make it even greater.
Every time a new wave tackles piper, they enhance and evolve. They add ideas and bring new themes. My ultimate hope is that piper becomes a self replicating, cascading program that gets adopted across the industry.
Want to read more about project piper and how it runs. Click here.