Nike Engineering
Published in

Nike Engineering

Continuous Learning — Part II

I strive to be a lifelong learner. I continuously seek out new information, so I can grow, acquire knowledge and expand my understanding, with the goal of always learning. I am proud that technology leaders at Nike put an emphasis on continuous learning and believe it’s a critical component to our success and evolution as innovators in the digital space. Leaders and employees alike are constantly pushing the boundaries of what’s possible, expanding their competencies with a diversity of thought — and technology — in order to get after new opportunities in the marketplace. At Nike, this means leading retail’s digital transformation and creating the future of sport for athletes* globally.

Events like the DevOps Enterprise Summit provide an incredible opportunity for learning. I have been attending the summit since it began in 2014. That year, I spoke about Nordstrom, my previous employer, and our journey to transition its software development practice from one that optimized for cost to one that optimized for speed. That was also the year that I met people from Target, Disney, Nationwide, CSG and Capital One, among many others, all of whom have served as inspiration and sounding boards for my own continuous learning, as we all work to drive transformation at our respective companies.

This year’s DevOps Enterprise Summit in Las Vegas did not disappoint. Below, I’ve summarized several key learnings and their importance to me, personally, and to Nike’s digital engineering organization.



Nike sent a whole team to this event — all of whom were first-time attendees. Our strategy was to split up and cover as many of the talks and workshops as we could, using a Slack channel to share our learnings. After we returned to the office in Oregon, team members started practicing things they had learned. I’ve already received feedback about how excited our teams are to see leaders demonstrating their commitment to creating a learning organization.

Suggested content: DevOps Enterprise Summit founder, Gene Kim’s, kick-off


Anyone can simply start practicing DevOps techniques within their organization, but doing so without wider buy-in will only get you so far. Having a strong business partnership is a critical component; it accelerates results — and sustains them. At Nike, our engineering leaders are focused on building close ties with our business stakeholders, like Anne Bradley, Nike’s Chief Privacy Officer and Legal Counsel. She found great value in attending the event, so much so that she even started a new hashtag: #bringyourlawyertoatechconference. Below is a photo of Anne and me with members of the Capital One team (Topo Pal, Distinguished Fellow and speaker at the summit, and Jamie Specter, legal counsel)

Topo closed his presentation sharing his #DevOpsHashtags, including a new one — #MVC (Minimum Viable Compliance) — which came from our Nike presentation.

Suggested Content: CSG Capital One


Throughout my career, I have seen the industry reward heroics. Pulling all-nighters to deploy releases has been considered a badge of honor. I believe this leads to burnout in employees, and I’m working hard to change this culture within our engineering organization at Nike. My goal is to create an environment that does not encourage this behavior and, instead, focuses on more healthy and sustainable practices. Exhaustion, cynicism and professional inefficacy are all symptoms of burnout. Exhaustion is individual stress (“can’t take it anymore”). Cynicism is a negative response to the job (“socially toxic workplace”). Professional inefficacy is negative self-evaluation (“no future”). One small but critical step I have taken is to do my best to avoid sending emails outside of work hours. This can be really difficult to do, especially in organizations with meeting cultures, where the only time you have to send emails is often after hours. Another tactic I have used is to create a daily stand-up with my leaders. It gives us the opportunity to check-in, align on the plan for the day, balance workloads, if needed, and minimize emails and other communication mechanisms.

Not many people will raise their hands and say they are burned out. So, rather than focus on signals and indicators, my preference is to focus on making sure my teams are getting time to recharge, eliminating toxic behavior and leading with intent and purpose. In this way, teams are connected to the work they are doing, to the organization’s mission (in Nike’s case, “to bring inspiration and innovation to every athlete* in the world”) and to the consumers they are serving. In January, I will be starting daily stand-ups with my direct reports. I’m really excited to try it at Nike because I have seen it help a lot in past roles. I’m hopeful we will see the same outcomes. And, if not, we will learn and adjust. #alwayslearning

Suggested Content: Dr. Christina Maslach Industry Panel Josh Atwell



A lot of enterprises have silos and continue to deliver technology in a traditional way — development teams develop, test teams test, release teams release, operations teams operate, security teams secure, architecture teams architect, project managers manage projects — you get my point. I believe that all roles in organizations need to evolve towards a DevOps model, and it was refreshing to see some of the ways big companies are doing this with a focus on optimizing for engineers, speed and moving to a product model.

Technical architects, along with a product manager, from Target talked about moving away from governance and toward guidance. This involves eliminating governing bodies, like ARBs (Architecture Review Boards), and having a crowd-sourced recommended technologies approach with a focus on accessibility, transparency, flexibility and culture. This resonated with me because, at Nike, we are focusing a lot on creating a strong internal community of practice, focused on inner sourcing and making architecture everyone’s job.

Operations is another area requiring evolution. Damon Edwards gave a great talk about the forces undermining operations. This also resonated with me because I started in operations, and I know that we still have opportunities to build trust between teams, improve feedback loops and break down silos. At Nike, we are focusing on aligning outcomes between teams. For example, my engineering teams have OKRs around MTTR, MTTD and change failure rates, and we are sharing outcomes with our operations teams, including deployment frequency and cycle time. This will help our teams focus on outcomes and find ways to improve. It’s important for us to use data because every team is different; some are further along, and some are still requiring investment in capabilities.

Moving from project to product is a very popular topic, as organizations transform, and it was great to hear from Rob England and Dr. Cherry Vu about how “project management was the worst thing that ever happened to IT.” I’ve experienced this in my career, as I’ve seen three big companies try to move away from projects to products. Often, attributes of the project approach are challenging to change. Projects require you to plan, plan, plan, plan, know everything up front, provide estimates for the length of the project (often 12–24 months) and deliver in a big bang approach. It does not promote a dynamic, learning organization and makes it really challenging to adjust or change course. Traditional project management is an anti-pattern for practicing DevOps.

Suggested Content: Target Damon Edwards Self-service guidance doc Rob England and Dr. Cherry Vu


At Nike, our technology teams are focused on creating a dynamic, learning organization — one that can out-learn the competition. Creating a culture of continuous learning is strategic and creates competitive advantage. In this context, I don’t like using the phrase “fail fast.” It’s more important that we “learn fast.” When issues arise, I try to shift the conversation away from “who” and, instead, focus on what in the system needs to be improved. It’s important to move the focus away from finding root cause to finding the contributing factors in order to understand them and move forward with a problem-solving mindset. Finally, I’m working to eliminate “human error” from our vocabulary when discussing root cause. Human error is never the root cause, and there is never a single root cause. It’s more important to focus on the contributing factors that led to a breakdown in the system.

Suggested Content: Dr. Spears Scott Nasello


The fireside chat with Chris O’Malley, CEO of Compuware, was one of my favorite parts of the conference. He talked about creating value and not making excuses. The DevOps community is too focused on talking about traditional metrics (MTTD, MTTR, deployment frequency, etc…), he said. Instead, we should be focused on the ideas that our teams bring to life and share those stories with product management. We need to become storytellers, he said, and we need to celebrate the people who take risks. O’Malley shared that, every two weeks, he holds a town-hall to showcase the ideas and products being delivered. Teams share their blockers and constraints and put problems front and center and, in doing so, move the organization forward.

He closed by telling all of us to stay persistent and continue to drive change. At any given point, 2/3 of the organization will either be passively or actively resisting change. Stay courageous. This made me think of a phrase I use a lot, “Keep fighting the good fight!”

Suggested Content: Chris O’Malley

All videos from the 2018 DevOps Enterprise Summit in Las Vegas can be found here.

  • If you have a body, you are an athlete.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store