Nerd Journey: Career Advice for the Technology Professional
John White | Nick Korte
Podcast
Episodes
Listen, download, subscribe
Overwhelmed by Ambiguity: DevOps, Innovation, and the Search for Clarity with Daniel Lemire (3/4)
What happens when there is too much change at once after making a job change? Daniel Lemire had learned the principles of DevOps and combined it with his experience as an infrastructure architect to advocate for the adoption of new technologies and processes within a large enterprise. But when Daniel changed roles to focus on innovation and became a senior manager at the same time, there were many challenges for which he was unprepared. In fact, at times it was overwhelming. In the 3rd installment of Daniel Lemire’s story in episode 325, you’ll hear Daniel’s reasons for focusing on innovation in the first place, why he continued to persevere through challenges, the stress and impact of layoff events, and the unexpected way he found clarity amidst the ambiguity. Original Recording Date: 03-20-2025 Daniel Lemire is an AI Consultant working for ServiceNow. He’s also the creator of AI Mistakes. If you missed parts 1 or 2 of our discussion with Daniel, check out Episode 323 and Episode 324 Topics – A Personal DevOps Value Story, Planting Seeds of Innovation, The Challenges of Impactful Innovation, Progressing from Overwhelm to Clarity 3:33 – A Personal DevOps Value Story Daniel needed a reset and to determine how he could contribute to the organization where he worked. That’s about the time he discovered DevOps. After a recommendation from a colleague within the security organization, Daniel read The Phoenix Project, and it has changed his career trajectory for the better. He read the book not long after its release. Reading the book also changed the way Daniel thinks so he is able to help companies create value. “…When I read it, I didn’t understand what was so great about it. I just knew there was something there that I needed…. I read it and I got really excited about it. But I didn’t really know what to do with it.” – Daniel Lemire Not long after reading The Phoenix Project, Daniel recommended the book to a colleague who worked on the security and compliance team. There was a character in the book named John who starts off being very stressed but for whom things improve greatly during the course of the story. “After he finished the book, he came back to me and he’s like, ‘let’s do something with this….’ I still didn’t know what to do with it.” – Daniel Lemire Daniel’s colleague recommended they start by meeting and having a conversation. After their initial meeting, Daniel and his colleague started meeting on a weekly basis. They started talking about The Three Ways and how these could be applied to make things better. Daniel and his colleague gave a presentation to a large portion of the IT Operations team to share thoughts on the way people do work and how to improve it. “It really helped them think through some of their organizational challenges and the things that needed to be done because that was also a difficult time across our technology organization because of the big changes that were being made. But the lightbulb didn’t really all the way come on for me until The DevOps Handbook came out and I got the concrete ‘these are the things that matter to a technology organization.’ So much of what I think about from a technology manager perspective has literally come out of that story. It is The Phoenix Project helping me related to what was going on and then the handbook giving me the tools to do the things that mattered that have enabled me to grow my technical accumen into an organizational behavior mechanism…. Ultimately if you can’t apply the lever in the right place, it doesn’t matter…. You can have the best people. You can have the best technology. But if you don’t solve the right problem, you’ve done nothing. That is a contextualization on many different levels.” – Daniel Lemire Daniel cites The Goal by Eliyahu Goldratt as another very influential book. He says it helps you understand systems at a bigger level and would recommend it to any technologist, referencing the drum buffer rope concept. We must be able to do the right things within the right context to create value. Daniel achieved continued success applying the principles of DevOps which allowed him to continue into a management role at PepsiCo. Before Daniel was a manager, he needed to work with and influence people to do technical work across the organization. These people didn’t necessarily work with him on a daily basis or have a rapport with him. Learnings from his study of DevOps came together in a meaningful and useful way in these situations. Daniel cites understanding the metrics needed to get the kind of feedback you need as an example. Reflecting back on it, Daniel was excited about what The DevOps Handbook promised. The book’s introduction was telling a value story for the application of DevOps, including examples of organizations that had used the principles of DevOps to increase performance. “You needed everything that was in the rest of the book, but what got me excited was what those things could do. Understanding that promise of improving the system got me thinking more about how to build an effective system.” – Daniel Lemire, describing the introduction of The DevOps Handbook as a value story for DevOps 9:26 – Planting Seeds of Innovation Daniel was already helping colleagues understand how to make effective technical contributions to building systems. The principles Daniel learned from The Phoenix Project, The Goal, and The DevOps Handbook allowed him to push these conversations beyond just the technical – into the business domain. “You’re never going to be successful in architecture if you’re not able to encapsulate the business domain.” – Daniel Lemire It’s important to be able to explain why we do technical things. “Architects, in my view, are really masters of making tradeoff equations. In the infrastructure space, you can install a single server to do something, and you can get that system in place very quickly. But it’s fragile because if any individual component failure comes into play, you can’t do anything. So, you have to build these failure domains that allow you to maintain the integrity of the system, but that’s more expensive…. When I think about what I learned from DevOps, it is balancing those two equations.” – Daniel Lemire Daniel distinctly remembers a chart having to do with the number of developers working on a given project. It’s the Mythical Man Month concept. He gives the example of a baby’s development. It takes 9 months. This is a known limitation of the system. Daniel says architects understand technical limitations in specific areas but also overall system limitations. The limitations are used to make the right decisions in conjunction with the requirements to meet the business need so the overall program can be successful. “The better you are at putting those pieces together, the more successful you’re going to be in solving the problems that the organization at large has.” – Daniel Lemire According to Daniel, an architect doesn’t just put technical systems together and stop there because it can limit one’s success. Daniel mentions receiving guidance from people in the DevOps community to extend his skills beyond the technical. While learning DevOps did afford Daniel the opportunity to do some interesting work as an infrastructure architect, but he eventually reached the point of needing to do something different. Daniel remembers completing a specific exercise for his personal development plan focused on the kinds of things he wanted to do in his career. Daniel wrote down his desire to be an architect and focus on innovation. Daniel was a competent infrastructure architect who understood the challenges of the role very well. He experienced successes driving new technologies like DevOps and adoption of cloud technologies and was extremely proud of those efforts. The next architectural project for Daniel was building a very critical business system in the cloud. It was interesting but not interesting enough. “I knew exactly where I was headed with that program. I thought it was interesting, but I also thought it was boring. And that’s not what I wanted to do next…. I saw the pain that was coming for me by doing this next big thing. I wasn’t excited about it, and I just couldn’t put myself in that position going forward.” – Daniel Lemire Daniel mentioned many corporations across the world have a lot of work to do when it comes to cloud technologies. We are great at adding new technologies but not so got at getting rid of the old ones. The Phoenix Project describes problems and challenges that are applicable to many companies. We can learn from other companies without having to go through the pain. 15:07 – The Challenges of Impactful Innovation “And, oddly enough, an opportunity opened up for me to get to that next level and be a senior manager and go do innovation. Man, I was so excited about that.” – Daniel Lemire Reflecting on it, Daniel was very good at introducing critical new things within the company. He points to the beginning of cloud dialogues with colleagues and how their reactions changed from initial confusion and detraction to full support within a couple of years. “I was one of the guys that said, ‘yeah, we need to go do this.’ I don’t think I was wrong, and DevOps was the same way. Some people were like, ‘I don’t know why this is your thing.’” – Daniel Lemire Daniel mentions conversation he had with a mentor who disagreed about DevOps being what the organization needed to solve certain problems. At the time, Daniel knew he would not win that battle. “The challenge I always had with him was – he’d throw me off my game. He’d ask a really intelligent question that I had no way to answer. I liked that about him because every time I got in a conversation with him, he’d point o
Nerd Journey: Career Advice for the Technology Professional RSS Feed
