I’ve read, and re-read the Phoenix Project and absolutely love it, learning something new each time and picking up new ideas to keep my brainstorming going, but one thought that has plagued me through to the end every time, is the “guardian angel” to management and the IT person staying the IT person.

How different would the story be if Brent was the benefactor of Erik’s advice?

In my years of experience, I often find the Brents of the industry aren’t wholly self-made but often easily fall into traps that we’re not taught to get out of. It’s easy for management to rely on us, keeping us as the choke point of many critical projects without realizing it or facing it and we burn out, get angry, go BOFH. We’re often managed into systems, managed into context and managed into a story and we often try and logic reason ourselves out of this with no end in sight. What if there was a different story?

How different would the Phoenix Project be if Brent was able to learn some leadership, learn some collaboration and develop his persuasion skills to help motivate and transform the organization and himself from within? Would this story better help others facing similar situations? Would it help develop more leadership roles from the Brent types over the world? Would it help many of us Brent types “see the Forrest from the trees” more clearly?

The book is very good, don’t get me wrong, but I just have a gut feeling every time I read it that I wish Brent could have been developed, fostered and nurtured, not as a follower of management making changes but as the catalyst for management making changes and as a growth path for Brent himself, because I feel that better parallels my experience. Obviously in the story Brent does benefit from the changes and we can all learn from the story, but in the end, it feels like a management win and it left me wondering how I could do something as if I’d just meet Erik.

I parallel this thought to many of the discussions I see on twitter and my own sorted experiences to help make changes at an organization. In some tweets, I see people struggling to do what I’d call applied DevOps, replying to others to quit a job because they can’t convince management/peers of the logic of DevOps, people describing you must to this, do that, and run this or be that, and lots of frustration or indifference towards DevOps values by everyone else but them. I’ve just been insanely curious about trying to parallel the story of the Phoenix Project to myself, my own short comings, my own experiences and those I observe (such as the mentioned tweets and indifference) and how to approach this. It was an awaking of sorts after reading MANY stories and books on leadership and growth that not only are a lot of “Brents” trying to make these changes in their organizations but ironically they do so in a very “Brent” way and here is how I’d answer that story.

For me, the new story steams from a few books I’ve read (mentioned below) and an excellent class available from the Teaching Company – Transformational Leadership and how I thought this could make a new Story for Brent if Brent meet Erik and hand the skills to transform.

How to sell DevOps at your org if Brent was the benefactor of Erik’s advice.

The hard way – The Brent way of convincing organizations of devops.

Strongly stated position – speak to things as facts – applied “DevOps” – get focused on mimicking successful organizations more than anything else. We’re good at having strong views and strongly stated positions.

– speak to things as facts – applied “DevOps” – get focused on mimicking successful organizations more than anything else. We’re good at having strong views and strongly stated positions. Assertive Supporting Arguments – “This is the way, we must do this or else…” – Our logic is what we feel makes us assertive and how we speak objectively to something as if that will win people over.

– “This is the way, we must do this or else…” – Our logic is what we feel makes us assertive and how we speak objectively to something as if that will win people over. Closing the deal – resisting compromise, using only logic/data and extreme passion to make out point. Combining everything above, we often trap ourselves into an all or none type system/belief.

Would the book have made much more sense to many of us if Brent was developed to learn better collaboration? Be a better leader? Would you be able to recognize the hard way above as the hard way? After all, most leaders are taught that the better way of persuasion (and leadership) is, collaborative persuasion. Collaborative persuasion helps us achieve the very goals we convey and yet, we don’t speak or really practice to this much, if any at all. While I felt the leadership story in Phoenix Project was very mature and bold, I’d just like to see more parallels of how Brent could have been fostered to lead the transition too and I believe many of us do it the hard way, or Brent way.

The Collaborative Way – Collaborative persuasion – using the very concept we’re trying to convey as a solution as the solution.

Establish Credibility – Don’t over estimate your own self! (Big thing for us Brent types!) – Conduct experiments & develop pilots to share what we’re trying to sell. Build credibility as DevOps applies to YOUR organization. Begin Somewhere!

Build TRUST! Would Brent be able to experiment (Vs jump to applying) with the advice of Erik? Could we translate that to Management/Leadership? Could we do so without falling back to our logical bias and do it collaborative for small wins and tactical leadership positions? Automation may be Brent’s goal idealistically (it is after all, following our logical trend) but could we step back and be happy showing a Kanban process and the wins thereof or simply starting with communication? Could we lead the small wins to a strong catalyst for cultural changes? Sometimes culture defies logic and that’s tough for us Brent types to understand or often don’t comprehend at all.

– Don’t over estimate your own self! (Big thing for us Brent types!) – Conduct experiments & develop pilots to share what we’re trying to sell. Build credibility as DevOps applies to YOUR organization. Begin Somewhere! Build TRUST! Would Brent be able to experiment (Vs jump to applying) with the advice of Erik? Could we translate that to Management/Leadership? Could we do so without falling back to our logical bias and do it collaborative for small wins and tactical leadership positions? Automation may be Brent’s goal idealistically (it is after all, following our logical trend) but could we step back and be happy showing a Kanban process and the wins thereof or simply starting with communication? Could we lead the small wins to a strong catalyst for cultural changes? Sometimes culture defies logic and that’s tough for us Brent types to understand or often don’t comprehend at all. Framing for common ground – It’s important to collaborate, it’s important to explain things and frame them in such a way to express ourselves better. Instead of saying “this must be the way, look, everyone else is succeeding at it” frame the topic so that the focus is drawn to the attention of where you desire to be. Lead people to positive results. Framing is how you can steer the DevOps story to be better applicable and connected to your organization.

– It’s important to collaborate, it’s important to explain things and frame them in such a way to express ourselves better. Instead of saying “this must be the way, look, everyone else is succeeding at it” frame the topic so that the focus is drawn to the attention of where you desire to be. Lead people to positive results. Framing is how you can steer the DevOps story to be better applicable and connected to your organization. Connect emotionally – Is this possible for Brents of the world? Can we adopt our strategy to a broad audience in a collaborative way that connects with management and works through these gatekeepers? Can you focus on the divergent thinking to make it happen? Are we presenting REAL solutions or are we presenting problems? I know it’s terribly easy for us Brents to focus on problems and solutions as if their logically black and white. Can you connect emotionally to your peers and speak to them as if you put on their shoes?

– Is this possible for Brents of the world? Can we adopt our strategy to a broad audience in a collaborative way that connects with management and works through these gatekeepers? Can you focus on the divergent thinking to make it happen? Are we presenting REAL solutions or are we presenting problems? I know it’s terribly easy for us Brents to focus on problems and solutions as if their logically black and white. Can you connect emotionally to your peers and speak to them as if you put on their shoes? Evidence – how can we build stories, examples and metaphors? How can we make this evidence connect emotionally? Frame it for common ground? Build trust and establish credibility? Evidence absolutely comes natural for many of us “logical Brents” but the hard part is connecting it to the collaborative persuasion process and realizing that this collaborative persuasion it was grows us from a Brent who may have learned something and wants to achieve it into a Brent who becomes a leader to enact it.

Brent types can transform to be leaders. As leaders, we don’t need formality to express our desires, we need strategy, history, allies, solutions and we need to work with and through the gatekeepers to tell the DevOps story. I think once we learn this, we also learn that perhaps there isn’t an absolute way for everything, that collaboration can lead to new ideas, new thoughts and new models of getting things done. We can not only grow to become leaders, but grow in our understanding and interpretations of the values of DevOps and how those values benefit the growth of your organizations and just as much, if not more importantly the growth of ourselves.

So while the Phoenix Project didn’t focus on the Brent solution as many of us are or have been over the years, I hope this post invigorates you, Brent or not, to think differently, think like a leader and realize that what you are trying to achieve doesn’t have to be an effort of management directly, but an effort that when done right can come directly from you. I implore you twitters not to tell people to quit their job, give up, find something else to do or beg and chew your way up or simply try and mimic or apply logic as if that’s the only way – as DevOps values aren’t something we believe in and force upon others, they’re stories that connect emotionally and speak elegantly to us to learn, practice, share and collaborate on. We need to do better selling that story to management & leaders or better develop ourselves to become those management & leaders.

Thanks for your time. I realize not every Brent wants to be a leader and may be quite content with an organization that delivers DevOps values for him/her, but at the same time, I think there are a lot of us who do want more and I hope this helps you think of how to achieve more and how to lead that effort in a very DevOps way.

Books & Resources I’ve drawn much of this from and wouldn’t want to do without 🙂

PS, I’m terribly new to writing, feel free to leave any feedback about my style, grammar, spelling or any methods to improve. I’m mostly sharing my stories and thoughts but I’m always open to improve. Thanks!

As always, feedback appreciated. Feel free to find me on twitter as well.