“DevOps is not about a specific team or a specific process, it’s about people and culture.”
Having successfully implemented DevOps at three very different organizations, including Teachable, where he is senior manager of infrastructure and information security, Eiwe Lingefors can say that with confidence.
Autonomous ownership across teams and collaboration are two distinct traits of a strong DevOps culture, Lingefors said. The result is efficient operations that can translate to an internationally successful business.
Teachable isn’t the only tech company seeing the fruits of a DevOps culture rooted in the aforementioned values. Other New York City engineering leaders Built In spoke with — at MayStreet and Paige — echoed the same people-centric methodology, along with some additional insights.
A common theme? A communication feedback loop with all stakeholders is critical, both internally and externally.
Creating a safe environment for that communication allows for evaluating processes without blame, continued experimentation and shared learnings. A culture of transparency and tolerance also goes hand-in-hand with the collaboration and ownership necessary for a healthy DevOps methodology.
The following 13 DevOps leaders share their tips for a strong and effective DevOps culture.
tips for a strong and effective DevOps Culture
- Prioritize learning over blame
- Ensure goals are transparent
- Encourage strong cross-team collaboration
- Provide autonomy and ownership
- Practice continuous feedback
Avenue Code
Amir Razmara
CTO & PARTNER
How did you implement a DevOps methodology within your tech organization?
This has been more of a continuous journey. When we started the company over a decade ago, we started by applying all of our learnings from past experiences using the Agile methodology. As technology progressed and allowed for more automation, we focused on investing and experimenting more and more to deliver continuous integration. As optimization on the process progressed, so too did the sophistication of the technology. We learned to experiment and fail fast if needed. What we learned from our failures, we applied to the next experiment.
Our core culture is based on what we call continuous learning. DevOps methodology is part-technology — which delivers the know-how — and part-cultural mindset to apply this knowledge. To succeed with this mindset, one has to keep on learning to adjust to new processes and develop with new technologies for optimization.
What are the key characteristics of a strong DevOps culture?
Organizations succeed in building strong cultures when they are focused on solving the challenges at hand, are open to new approaches, are willing to fail fast, learn from past mistakes and improve upon them. For an organization to be successful, it is important to avoid the blame-game culture.
We focus on educating our consultants. We demand curiosity from them and that they yearn to learn all the time. This means providing a culture where they feel free to come up with new ideas for improving things within the company. Our consultants have built several tools that we’ve adopted and are further investing in. Nurture a culture of iterative development. Avoid big-bang deliveries and focus on continuous improvements.
"Keep an open mind so that you can learn from everything and adapt for the next iteration.”
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
You must be open to change and be willing to fail. Keep in mind that not every single initiative will be successful. Keep an open mind so that you can learn from everything and adapt for the next iteration. If you have technical expertise within the organization, it’s key to engage that talent early so employees can show how technology can help achieve business goals. This will address any concerns the operation team members may have when you start.
If you don’t have technical expertise in-house, bring it aboard from outside, and ensure that the consultants are great communicators in addition to great technologists. DevOps is an ongoing journey, and there is always room to improve. Be transparent with your team, and secure their engagement early on. In addition to being open-minded, you must also be able to stand up to naysayers. It will be a tightrope balancing act in the beginning, but it will get easier as changes introduce greater efficiency.
CircleCI
Michael Stahnke
VP OF PLATFORM
How did you go about implementing a DevOps methodology within your tech organization?
Start with the ways teams interact. Is one team always depending on another? Why is that? Are both teams handing off things to each other? If something goes wrong, does the same team always feel the pain of it?
Early on, we saw that development teams would build something. It would work for a while. Eventually, developers would update it, and operations teams would be left holding the bag for why it wasn’t working and how to make it work again. One of the fastest ways to combat that over-the-wall mentality is alignment on pain: If I break it, I should feel that burden. If I know the burden is likely to come to me, I am more invested in validation, testing, architecture, non-functional requirements and making sure it works correctly. Have teams that build things, run things, if you can.
"You want to move quickly. You do that with a strong process.”
From your experiences, what are the key characteristics of a strong DevOps culture?
A strong culture prioritizes learning over blame. When things go wrong, do you try to find the root cause? Or do you try to see what you could have been done differently in identifying and mitigating the issues more quickly?
For example, when we had some heinous database contention in a collection, we were up and down a few times over the span of several hours. We thought we’d mitigated our problems, but our priority was ensuring we had the correct tooling to see exactly what was happening should our problems resurface. After the series of incidents was resolved, our after-action work focused on improvement in investigation, response and detection, as opposed to really honing in on exactly which team wasn’t clairvoyant enough to see this problem.
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
It’s not really a technical problem. It’s about flow, trust and collaboration. You want to move quickly. You do that with a strong process. Strong process builds confidence. When you can, automate that confidence-gaining procedure and you’ll have time for what’s next. That’s why automation tools have experienced a rise in uptake in the last decade. The more certain I am that the way something is done is complete and correct, the less I need to manage it, the less I need to modify it and the more time I have for the next set of problems impacting my business. Gain confidence, and do it with automation.
Teachable
Eiwe Lingefors
SENIOR MANAGER OF INFRASTRUCTURE AND INFORMATION SECURITY
Teachable’s success as an edtech platform for online teaching can be directly attributed to its DevOps culture, Lingefors said. That culture is one rooted in ownership, free of silos and aligned in support of business goals.
First off, how did you go about implementing a DevOps methodology within your organization?
I think a true adoption of DevOps can only be successful once you understand the vision and goals of the organization. In addition, DevOps support needs to come from the top. During the journey, it’s important to always make implementation decisions that support business goals, foster collaboration, eliminate silos and reduce friction. Measure and commit to improving lead time, deployment frequency, change failure rates, time to restore, and availability.
At Teachable, we are expanding our use of infrastructure-as-code and migrating our applications to Amazon EKS. This will empower our software engineers to deliver code with less friction and greater ownership, but more importantly, empower creators to transform their knowledge into income.
From your experiences, what are the key characteristics of a strong DevOps culture?
I’ve had the opportunity to lead DevOps implementation in three very different organizations over the past decade. By far the strongest indicators I’ve seen of healthy DevOps culture is that collaboration across teams is effortless, and engineers feel empowered with a deep sense of ownership over the software they deploy.
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
Make sure you understand the current state of development and deployment practices of the organization before you begin. Educate senior leadership about the business value of DevOps adoption to ensure you have buy-in. Start small and iterate over the process. Foster a culture of collaboration, experimentation and learning. Make sure DevOps is something the entire software engineering team is engaged in rather than it being siloed on a single team. Create robust feedback loops so you can evolve the implementation in support of business goals.
DevOps is not about a specific team or a specific process, it’s about people and culture.
Paige
Razik Yousfi
VICE PRESIDENT OF ENGINEERING
For Paige, a startup using artificial intelligence to help pathologists study cancer progression and more accurately diagnose and treat the disease, Yousfi said empowering teams to feel ownership, experiment and collaborate across functions is the key to a DevOps methodology that’s constantly improving the organization and product.
How did you go about implementing a DevOps methodology within your organization?
We believe in cross-functional, autonomous teams owning strategic parts of the product, end-to-end. Uniting uniquely-skilled people is key to a strong DevOps methodology and culture.
To implement DevOps, we started by forming these teams and adopting Agile practices to build and support our software. We’re automating our processes and ensuring we have the tools to help the teams and the whole organization to monitor its progress. Bridging this gap between development, operations and other functions is instrumental to Paige’s success as an entity.
Hiring also plays a key role in our DevOps implementation. We want to build a culture of ownership and continuous improvement for our products. Everyone at Paige is encouraged to own the process of ideating, developing, testing, delivering and monitoring products.
How have you adapted this methodology to meet the needs of your team?
There are two paths to implementing DevOps practices. One is a centralized team of experts in platform engineering that lets all product teams submit tickets for tasks related to platform and infrastructure. The second is to embed a platform and infrastructure expert within each product development team. The first approach makes it easier to implement consistent expert practice and reusable infrastructure, but at the expense of speed and autonomy. The second approach works in the inverse, yielding a less consistent approach to solving problems, while enabling autonomy and speed.
At Paige, our DevOps approach sits between these two: We have a platform engineering function operating across multiple teams, meeting on a regular basis to provide systematic infrastructure that can be used companywide. However, we also have some platform engineers directly embedded within the product development teams to really push the culture, providing support and infrastructure in a timely manner to get everyone aligned on our common DevOps goals.
From your experiences, what are the key characteristics of a strong DevOps culture?
Autonomy and ownership: Our code base is internally open source and anyone is welcome to send a pull request with necessary changes. This self-serve model empowers everyone to move forward at their own pace.
Collaboration: Working together improves our efficiency from ideation to production, while providing a strong feedback loop to the development team.
Psychological safety: We encourage experimenting with new technologies and processes as a learning tool. Sharing learnings with the rest of the team creates a better future for the team and organization as a whole.
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
Adopting DevOps is an ongoing journey and there is no right or wrong implementation. Experiment with the practice, get feedback from your team and iterate from there. Use metrics that measure productivity, and focus on your customers. If you deliver value and respond to customer feedback in a timely manner, you are on the right track.
Internally, your goal is to minimize any disconnects within the product development life cycle across your teams and functions. Everyone should be on the same page from product management to support, and of course, the development team.
Maystreet
Norbert Paulsen
SVP OF SYSTEMS ARCHITECTURE
MayStreet, which provides market data to Wall Street players, ensures all teams are trained in DevOps and fully own their roles. This alignment shows up in the platform’s speed and accuracy, Paulsen said.
How did you go about implementing a DevOps methodology within your organization?
MayStreet was founded by two technologists — CEO Patrick Flannery and CTO Michael Lehr — so we very much have an engineering-led culture rooted in ownership and shared responsibility. From the start, they’ve ensured our developers, system admins and QA engineers are in alignment. Planning meetings and sprints are organized across disciplines, since having everyone pull in the same direction is key. Once we laid that foundation, we focused on the release lifecycle, pipelines and technology necessary to automate much of what we thought was important.
From your experiences, what are the key characteristics of a strong DevOps culture?
Communication and trust are key in a strong DevOps culture. A loop of continuous feedback and iteration is critical to keeping the pipeline healthy and efficient, which is why we practice blameless retrospectives. We’ve found it’s important to get unfiltered and unguarded feedback to get a more objective view of where the process succeeded and fell short.
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
It sounds basic, but it’s important all stakeholders fully understand what DevOps is and what it isn’t. Taking the time to communicate this upfront leads to much less confusion down the road. And instead of redesigning the entire organizational structure to move toward DevOps, training existing teams allows them to properly configure the tools and apply new practices.
The benefits of DevOps are plenty: improvements in product quality, minimal cost production, faster deployment times and a greater sense of ownership and work satisfaction from engineers.
But while the benefits of shifting to a DevOps model may be clear, understanding how to do it can be a lot less straightforward. For companies ready to start implementing a DevOps culture, the first step is to throw out the rulebook.
“I think one of the common mistakes leaders make who want to adopt DevOps is that they think they can read it in a book and implement it,” Damien Jones, CEO of Blue Pisces Consulting Inc., said.
The foundation for DevOps culture is communication, a shared vision and the right tools. However, it’s a culture that’s meant to evolve. Not all DevOps methodology works the same for every team or project. Adjusting communication techniques and tools is part of the strategy.
Successful directors know when to step back from their DevOps team and let them ideate. Giving them the room to learn from failures will also give them the freedom to collaborate and succeed.
Blue Pisces Consulting
Damion Jones
CEO
Jones implements three C’s in DevOps culture at Blue Pisces: communication, collaboration and coordination. There is no rulebook; executing DevOps requires adjusting its methodology for each project. From there, openness to adaptation and change helps evolve DevOps into the best fit for the company.
How did you go about implementing a DevOps methodology within your tech organization?
Implementing DevOps in an organization takes the threes C’s: communication, collaboration and coordination. You must gain buy-in from your peers that may lead other segments and work with them to ensure a smooth transition. It is imperative to remember that DevOps hinges on partnership, a common goal and that everyone is part of something bigger than themselves. Being a servant leader in this time of implementation will serve you and your team well. Once you have the methodology in place, don’t be afraid to adapt and evolve it to fit your organization. Iterating and refining the process over time will ensure a much stronger, flexible and scalable solution for your technology organization.
From your experiences, what are the key characteristics of a strong DevOps culture?
When it comes to DevOps, I like to say it’s about “working in the gray, not the black and white.” In other words, given the nature of DevOps and the need to be collaborative and partner with your business leaders, it’s important to avoid drawing hard lines and rather be comfortable with working in the gray area. That’s not to say you should have to overextend your team all the time, but be a willing partner in the true sense of the word. It’s OK to take a little more, or a little less, if the greater good is being served.
A good example is that as a very notable client began implementing DevOps, it was really being led by infrastructure-oriented teams rather than application developers. Where you might expect developers or release engineers to build pipelines to meet their deployment strategy, it was the infrastructure team building pipelines to match the code deployment methodologies and educating the development teams on various tools and integration strategies to surround CI/CD. That was OK. It worked and the teams all evolved. Over time this could be handed back to development teams who were in a much better position to own this than had it just been thrown in their laps.
"One of the common mistakes leaders make who want to adopt DevOps is they think they can read it in a book.”
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
I think one of the common mistakes leaders make who want to adopt DevOps is that they think they can read it in a book and implement it. Oftentimes, they understand the general concept and think “that makes sense, I get it,” and then struggle to implement it successfully. DevOps is not a textbook or playbook that you can just take and follow. It is a culture. It’s something you have to build, nourish and continuously evolve. To do this right takes experience paired with a strong understanding of your enterprise capabilities, talent and appetite for change. In other words, don’t be afraid to ask for help. But be careful when searching for that help as companies like to throw the word DevOps around without having practical experience.
Pluto TV
Daniel Lloyd
VICE PRESIDENT OF ENGINEERING OPERATIONS
Pluto TV, like most companies, didn’t begin with a DevOps team. Lloyd said that in order to execute a DevOps culture without causing disruption to the business, it’s important to set boundaries and have clear definitions of roles. DevOps leaders need to be experts in the infrastructure and automation, but also communicative in how their team should implement those processes.
How did you go about implementing a DevOps methodology within your tech organization?
We needed to make a fundamental shift in thinking. We focused on automated processes and tools as opposed to a rapid “results-first” methodology. It’s required a balancing act of providing for the operational needs as an organization and thinking how to best solve potential issues further down the line. A DevOps culture can’t be built in a silo.
"A DevOps culture can’t be built in a silo.”
What are the key characteristics of a strong DevOps culture?
An interactive process, communication and transparency of goals. It also requires a bit of evangelism to act as a representative for DevOps as a focus. We work to provide a working proof of concept early, transitioning to MVP and then a fully baked pipeline for the organization.
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
Set boundaries and clear definitions of roles. Most organizations don’t start with a DevOps process, so DevOps resources often have to become experts not only in providing new infrastructure and automation but must do so in a way least disruptive to normal business.
Appetize
Danny Patel
SENIOR DIRECTOR OF TECHNOLOGY OPERATIONS
Patel said DevOps culture is a collective effort of people, processes and technology. To start, defining clear business goals is essential. Once the DevOps team has a shared vision, they then can have ownership over projects. For example, when Appetize was changing their infrastructure to Kubernetes, the DevOps teams had the freedom to research, build, iterate and create the platform.
How did you go about implementing a DevOps methodology within your tech organization?
DevOps is more than a methodology. It is a collective effort of our people, processes and the technologies we choose to use and leverage to enable our internal customers (our employees) to deliver Appetize’s products and services in the most efficient and sustainably scalable model to Appetize’s customers.
In order to have a successful DevOps culture and methodology at Appetize, we first had to understand our business goals and needs, as well as the existing processes and methodologies in use to deliver the business goals and fulfill business needs. We then started with the mindset of “we’re here to help you succeed in whatever you need to do to help Appetize deliver its products and services.” This approach enabled us to work collaboratively with everyone to create automation and compute platforms that increased overall velocity yet maintained standards and a sense of joint ownership of everything we build and run. The key is to have a team with the right mindset to help create a DevOps culture that permeates across all other organizations to work collaboratively.
"Start with simple core principles, and build on top as you mature your DevOps culture and methodologies.”
What are the key characteristics of a strong DevOps culture?
Some of the most essential ingredients for a strong DevOps culture are a high degree of collaboration, continuous information sharing, iterating and learning from failures and empowering people to succeed. Recognizing efforts that exhibit and embrace core DevOps beliefs has gone a long way in nurturing and strengthening the team culture. Giving team members the freedom to explore, ideate and collaborate on projects has yielded a strong sense of ownership and accomplishment, all the while continually growing our platform and services.
One example that clearly comes to mind is our effort to transition our infrastructure to Kubernetes. We started with a simple goal to move everything to Kubernetes but gave the DevOps team members the freedom to research, build, iterate and create the platform. Though it was challenging and demanding, the team delivered and takes great pride in what has been created and achieved.
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
Start with introspecting your understanding of DevOps. Ask how it aligns with your team and your company’s needs. Are you fully cognizant of the various dimensions that encompass DevOps? Start with simple core principles, and build on top as you mature your DevOps culture and methodologies. It is an ongoing effort that requires constant nurturing and iteration.
When Andrey Zusko, a software engineering manager at Caterpillar’s digital branch Cat Digital, was first introduced to DevOps, he was immediately hooked on the philosophy, methodology and mindset. Like many engineers, he loved being empowered with full control over the complete software development lifecycle. Five years later, he only hires developers with DevOps experience or those who have a willingness to learn.
But engineering leaders across Chicago will be the first to tell you there’s no one-size-fits-all way of incorporating DevOps into an organization. So how do team leaders build a culture that evokes an enthusiasm like Zusko’s?
The engineers we spoke with said DevOps is constantly evolving. To seam together development and operations teams requires communication, a shared vision and the right tools. From there, it’s important to step back and let the DevOps team research and ideate what to do next. Finding new ways to improve the process is what makes engineers excited.
IMC Trading
John Unger
TEAM LEAD – SYSTEMS ENGINEERING
Ownership and common goals are essential for a strong DevOps culture, Unger said. Different teams shouldn’t have competing priorities. Instead, they need to work toward a shared vision. To help foster that mission, IMC Trading created cross-functional teams.
First off, how did you go about implementing a DevOps methodology within your tech organization?
DevOps was not implemented overnight. It is a methodology and mentality that was adopted over time and continues to evolve today. At first, we tried eliminating our operations team altogether. However, we realized that there is value in having a team specializing in operations. To accomplish our goals, our operations team started owning a few development tasks, and our developers took on some operational responsibilities. Now, our technology organization is less siloed and flexible enough to meet the demands of high-frequency trading. We also had to partner with end users to create workflows that facilitated DevOps.
For example, we use a combination of email, chat and in-person meetings to make sure issues reach their target audience as quickly as possible. Tools such as TeamCity, GoCD and GitLab helped streamline our release process and gave more control to developers. Our operations teams are empowered to make code changes themselves and work directly with developers to implement long-term improvements. With a shared sense of ownership, the right processes and helpful tools, DevOps at IMC is a success.
"Shared ownership and common goals are key to a strong DevOps culture.”
From your experiences, what are the key characteristics of a strong DevOps culture?
Shared ownership and common goals are key to a strong DevOps culture. We need all technology teams at our organization to work together to accomplish DevOps. I’ve seen DevOps fail when different groups have competing priorities. For example, if the operations team is only responsible for uptime, they may push back on a quick-release pipeline. If developers only work on new features, bugs or stability issues can creep into the system.
When the entire technology organization is unified and working toward a shared vision, it gives purpose and direction for DevOps. To help foster these characteristics, we frequently create cross-functional teams to work on projects and accomplish our goals. This includes members from different parts of the technology organization such as development and operations, as well as business stakeholders.
An example is when IMC started trading on a new stock exchange. We created a cross-functional team consisting of developers, network engineers and traders. The team had a shared goal: trade on the new exchange the day it opens, as safely as possible. With a unified goal, we were able to achieve success.
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
First, understand the problems you are trying to solve with DevOps. Are your releases slow? Are there too many bugs in production? Do your operations teams spend all day firefighting? Once you know the root issues, speak with the teams that are impacted and would see the biggest benefit from DevOps. Collaboration is key to the adoption of DevOps and you need everyone in the technology organization on board. Developers may be hesitant to take part in operations and ops teams may feel uncomfortable changing code. Listen to concerns, and build a DevOps model that works for your organization. Accept that there will be some initial setbacks and make adjustments as you learn. After all, DevOps is about being agile.
Unify your technology groups with common goals and create KPIs that can be accomplished by practicing DevOps. Form cross-functional teams to work on these projects, and share both successes and failures equally amongst development and operations to ensure the groups are truly aligned. Every organization is different.
Cat Digital
Andrey Zusko
SOFTWARE ENGINEERING MANAGER
Zusko said he likes DevOps because engineers are empowered with full control over software development lifecycles. In order to implement DevOps successfully at Cat Digital, engineers are required to wear many hats. Not only should they be thinking about the task at hand, but also questioning how that task will be tested or deployed later in the development cycle.
How did you go about implementing a DevOps methodology within your tech organization?
My first experience with a DevOps-enabled engineering team was about five years ago when I joined a new team. I was immediately hooked. Like many engineers, I love being empowered to have full control over the complete software development lifecycle. I think the methodology is easy to adopt because the pillars of DevOps — such as a deep understanding of CI/CD processes, automated testing and infrastructure deployment — all help engineers build better software.
Now, when I grow my developer teams, I always try to hire people with relevant DevOps experience or those who are curious about learning and adopting the mindset.
What are the key characteristics of a strong DevOps culture?
DevOps has to exist in a blended culture where engineers rotate and wear different hats. In my team, there is no clear distinction between developers, quality assurance, DevOps and technical support personnel. Each set of experiences contributes to a better overall outcome.
For example, when you have experience writing automated tests, you will naturally think about how to structure your code to make it simpler and more straightforward to test. When you participate in infrastructure design and configuration, you will gain the experience to address production issues more effectively.
Second, I believe every project should be planned and developed with DevOps in mind. On my team, we think about support and maintenance before we even start writing code. We think about expected load when we plan our infrastructure. If there’s a production issue in the middle of the night, we are the ones who get the call, so we are motivated to pay extra attention to the amount and quality of our tests.
"Develop your own performance test suite, and you’ll see fast results.”
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
Start gradually. If your team still relies on QA, start building your own automated test suite. Build your CI/CD pipeline to run the tests. Automate your own deployment in lower environments. Design and build your own preventive monitoring and alerting. Develop your own performance test suite, and you’ll see fast results. Your teams will get excited, too. I’ve yet to see an engineer who didn’t like learning new technologies.
Optiver
Alex Segre
DEVOPS ENGINEER
Optiver operates as a global electronic market maker. Optiver’s traders and engineers work together to design proprietary systems and execute strategies that provide liquidity and increase market efficiencies. Segre, who sits on the company’s Chicago-based team, said development teams must understand the full lifecycles of projects in order to build a successful DevOps culture.
How did you go about implementing a DevOps methodology within your tech organization?
Optiver U.S. has long had a strong culture of DevOps thinking throughout the organization. Our development teams are directly responsible for the full lifecycle of their projects, from design to deployment and troubleshooting, all the way to decommissioning. Our operations teams ensure consistency and stability throughout the production environment. They understand the big picture and work closely with developers throughout all stages of projects.
This approach lets us iterate quickly without sacrificing determinism in production. Our DevOps tooling helps us scale this existing methodology. We mechanize processes in order to give our teams the leverage to do more; however, a human is always in charge. This key distinction between mechanization and automation is crucial in maintaining control and stability with so much on the line.
What are the key characteristics of a strong DevOps culture?
Every problem area needs a single owner, but people must not be siloed into their roles. Every team with a stake needs to be involved in projects from the beginning so that operational concerns are a top-level part of the design. We tackle DevOps tooling challenges the same way we approach any other engineering challenge — with principles such as simple solutions and iterative design. Our culture encourages experiments in all areas, including both our technology products as well as our DevOps tooling, as long as it's done safely. We often willingly take on temporary technical debt for these experiments, starting small and iterating as they prove worthwhile. Some fail and are cleaned up, but others succeed and become permanent parts of our infrastructure.
"Every problem area needs a single owner, but people must not be siloed into their roles.”
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
Engineer the full lifecycle of every project right from the start. The development teams must understand the full depth of their projects, from implementation through operations. The operations teams must have a complete breadth-view of production and must additionally act as a control on the development teams to ensure consistency and stability of the whole environment. Both these teams need direct input at the design phase of every project, as they both contribute different points of view.
Be cautious of new technology, both in your product and in your DevOps tooling. Although new libraries and frameworks can ease the implementation part of a project, dealing with the operational issues they incur is often an afterthought. When reliability, scalability and maintainability are part of the initial design process, many bleeding-edge stacks just don’t meet the bar. DevOps tooling in particular can impact the stability of all your products, so simplicity and determinism are key.
PatientPoint
Chris Jones
SENIOR MANAGER OF DEVOPS
Jones said collaboration and enablement are the two principles needed to build a successful DevOps culture. From there, a “continuous improvement” mindset is necessary in order to implement the best methodology for your team and project. Don’t rely on automation tooling to lead the DevOps team; Jones said it’s humans that make the culture a success at PatientPoint.
How did you go about implementing a DevOps methodology within your tech organization?
There is no one-size-fits-all methodology for implementing DevOps, but there is certainly a DevOps mindset. That mindset can be summarized as “continuous improvement.” As I work toward that mindset, I’ll identify sources of waste and try to reduce them. Common examples include unnecessary hand-offs of work, a lack of adequate planning and lots of invisible work. In our organization, we’ve been gradually finding ways to eliminate hand-offs, or at least to reduce their frequency.
For example, we’ve implemented a lightweight change management process that enables our engineering teams to do their own deployments if they don’t require any kind of manual or non-standard work from the DevOps team. We’ve instituted better planning processes designed to make cross-team dependencies visible so that we reduce surprises and churn.
Finally, we’ve started allocating general buckets of “operational” work each sprint to capture the fact that many of our teams have day-to-day responsibilities that don’t rise to the level of stories but which take time away from other planned work and cannot be ignored. This keeps from unknowingly overcommitting our time and reduces context switching between tasks. Above all, we keep metrics on the predictability of our work and the things that have the greatest impact on that predictability. Regular retrospectives are one of our greatest assets.
What are the key characteristics of a strong DevOps culture?
We are early in our DevOps transformation, but I think that two philosophies characterize any successful DevOps culture: collaboration and enablement. Our DevOps team was originally acting as a pure operations team, but over time we’ve worked with our engineers to change how we deliver software.
These changes weren’t earth-shaking. For example, one change we made was to enable our development teams to request their own infrastructure changes. Such changes had previously been reserved to the DevOps team. Now, any team can request an infrastructure change just by creating a pull request. DevOps is still involved and offers guidance, but it’s a much more collaborative model rather than a transactional one.
These changes are reflected by the development teams as well. We have ongoing discussions about what kinds of changes will enable our engineers to be more productive. For example, QA can work with our Android development team to make an application more testable or DevOps can work with our back-end developers to automate manual processes.
"Craft your own goals for your DevOps transformation.”
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
Craft your own goals for your DevOps transformation based on your organization’s particular business needs. Not every organization needs to adopt continuous deployment as a matter of practice, but the changes that are introduced to enable it will have a profound influence on your approach to software engineering. While DevOps often has an engineering focus, it needs to be advised by the needs and goals of the business for it to be truly effective. For example, you will require time to address technical debt and to automate manual processes such as builds and testing. There is an opportunity cost to that time, so be prepared to justify your DevOps transformation in business terms. You should also devise and keep good metrics so that you know when you have reached your goals. Finally, avoid focusing solely on tooling and technologies. While good tools are useful, it is sound practices and an emphasis on the human aspects of engineering that play the greatest role in the success or failure of DevOps.
Vail Systems
Dan Lenar
TECHNICAL TEAM LEAD
Lenar said he encourages his team to stay current on DevOps trends by participating in book clubs, attending DevOps meetups and participating in conferences. Engineers can take what they’ve learned and apply it to the DevOps culture at Vail Systems. There are no set-in-stone rules when it comes to DevOps; Lenar said it’s a philosophy and thus is open to evolving.
How did you go about implementing a DevOps methodology within your tech organization?
The evolution of DevOps at Vail started with containerization. With the power of containers, a new developer could join a team and have an entire stack running in a matter of minutes instead of spending an entire day following a lengthy README to install all the external dependencies needed to get an application running on their laptop.
First, teams were trained to build and run Docker images. Once teams were comfortable using Docker, we slowly introduced Kubernetes as our container orchestration system, which made deployments take a matter of seconds compared to our traditional methods with configuration management systems.
After implementing a DevOps methodology, we have seen more collaboration between development and operations teams on things like infrastructure code, and many silos that had formed over the year began to break down. With Kubernetes, developers were given the freedom to deploy their applications in development environments without help from operations staff.
Our ultimate goal is to build a GitOps methodology that will allow us to declaratively describe every part of pipeline as code; we can commit code to Git, which would trigger a CI/CD pipeline that would build a Docker image, run integration tests and deploy an image to a Kubernetes cluster.
"DevOps is a philosophical mindset used to build modern applications.”
What are the key characteristics of a strong DevOps culture?
A strong DevOps culture should encourage team experimentation and not shy away from failure. In order to encourage more experimentation, we try to have less than 50 percent of all our work tied to toil. Toil can be best described as work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value and that scales linearly as a service grows.
With this mindset, we have more time to think about how we can improve our processes and find the rights tools for the job. We encouraged our teams to become part of the Cloud Native Foundation community, attend and host various local DevOps meetups, participate in book clubs and attend KubeCon and DockerCon every year to keep up with current trends.
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
One of the first things to understand about DevOps is that it is more than just technology or a toolset; it is a philosophical mindset used to build modern applications that take full advantage of cloud computing.
To effectively implement DevOps within an organization, buy-in from the top is essential. Once you have buy-in, it is best to start with small incremental changes while continuously soliciting feedback from development and operations teams on what’s working and what’s not. Communication between cross-functional teams and knocking down silos to empower every team member to make fast and reliable deployments is also essential for success.
