What exactly is technical debt? When discussing your organization’s technical debt - and possible changes to it - with various audiences, you need to articulate the key issues in plain terms. Here’s expert advice on how to do that.
Target CIO explains how DevOps took root inside the retail giant
Brick and mortar stores have been cautiously embracing data, but Target has turned its cornucopia of information into a key to market success. In part one of this two-part interview, Target CIO Mike McNamara explains how DevOps helped move his team to the next echelon in customer service.
The Enterprisers Project (TEP): What process did you go through to get your team on board with DevOps?
McNamara: When I arrived at Target in mid-2015, I was excited to find an active grassroots DevOps and agile movement in pockets of the technology team. We’d already seen some great results with our digital teams and our enterprise architecture group moving to agile and DevOps. And we had a lot of engineers and team members who were hungry to start working this way.
One vital part of Target’s process was the creation of an accelerated learning environment our teams call “the Dojo.” It’s an immersive, six-week session where teams execute their normal work with agile coaches on site to support them and provide anything they need from a DevOps point of view. The Dojo has been fantastic in getting teams engaged with agile and DevOps, removing the natural resistance and fear of change, and then supporting the team through the changes while maintaining productivity. It’s been a huge success for Target. And as we move through the journey, we continue to use the Dojo to refine, reinforce and strengthen our engineering capabilities.
TEP: What was the most challenging part about championing and creating a more agile environment?
McNamara: As I mentioned, Target already had teams advocating for agile and DevOps before I walked in the door. That was great. The grassroots movement was just looking for support, and the rest of the organization was looking for guidance – so it wasn’t a terribly difficult sell.
What you come up against is: “My area can’t be agile because…” It’s a natural resistance to change – and in some mission-critical areas, the concerns are warranted. So in those areas, we started developing releases in an agile manner but still released in a controlled environment. As teams got more comfortable with the process and the tools that support continuous integration and continuous deployment, they just naturally started becoming more and more agile.
TEP: Where are you on your DevOps journey?
McNamara: Target is well along on our DevOps journey – we’re, frankly, further than I thought we’d be at this stage. We’ve been recognized by TechBeacon and others for our efforts and thought-leadership in this space. Our engineers have fully embraced DevOps. But since DevOps is in large degree about culture, that’s something we will always be improving and working on.
Plus, DevOps is fluid and constantly evolving. Practices can and will change, sometimes significantly, as some of the underlying technologies change. So people have to go through learning new things all the time. For instance, containerization is something that’s been talked about for a long time but is now a technical reality. And to containerize your software requires new tools for the engineers to learn. So it’s absolutely a journey that continues.
TEP: How do you ensure that your developers have the tools and skills to keep up with market demands?
McNamara: That’s simple: they tell me. I think the difficulty is containing their enthusiasm, rather than having to go out and search for stuff. We have a big meeting every quarter, our architecture forum, where Target engineers will come and petition for new products. We want to see things that are unique and things that will have staying power. We’ve got criteria to govern what we’ll adopt, but we encourage our engineers to play and to figure out how we can leverage the latest and greatest.
Target’s engineers are also very, very involved in the open source community. They’re major contributors to projects – in both big and small ways. The reality is a lot of the good DevOps tools of recent years have emerged from the open source community, so that’s where our engineers spend their time so they’re aware of everything that’s out there.