“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.
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.
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, 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.
