This article draws on practitioner interviews originally published on informationweek.com, featuring engineers from u-blox, Adtran GmbH, and Woodward.
Achieving the theoretical benefits of DevOps in practice is rarely straightforward. Much of the public conversation about DevOps centres on mobile, web, and internal application teams — but the discipline is increasingly being adopted in larger-scale, electronics-based engineering environments that carry their own layers of complexity, volume, and compliance requirements. Practitioners from three such organisations share their experiences. Three themes stand out: culture, planning, and tools.
Culture: Understanding the Mindset Before the Mechanics
Stephan Uyttebroeck, Principal Software Engineer at Swiss wireless and positioning company u-blox, offers a grounding reminder about expectations:
While DevOps concepts are applicable regardless of the kind of development work involved, don’t expect to find instructions or recipes that apply to your set-up. It’s important to understand the big picture and then adopt the parts of what you learn that make sense.
Stephan Uyttebroeck, Principal Software Engineer, u-blox
Stefan Callsen, R&D Engineer at networking and communications company Adtran GmbH, reinforces that point from an adoption perspective:
Without understanding the proper concepts, vision and mindset, implementation may not necessarily fail, but you won’t get the maximum benefit.
Stefan Callsen, R&D Engineer, Adtran GmbH
Steve Pacheco at Woodward — an independent designer and manufacturer of control solutions for aerospace and industrial markets — highlights the importance of early team alignment:
It is very important to get the team on board as soon as possible and define roles up front, so they start to see the value early. We were able to get team buy-in quickly, which helped us better deal with some of the challenges due to the fact that our projects vary quite a bit. Customer involvement helps too, but that’s not easy to achieve.
Steve Pacheco, Woodward
The consistent thread across all three practitioners is that DevOps is not a toolchain you install — it is a shared understanding that has to be cultivated deliberately, especially when projects span multiple teams, geographies, or regulatory domains.
Planning: Scaling Agile Frameworks and Managing the Unknown
Large-scale DevOps — particularly in hardware-adjacent or embedded-systems industries — introduces planning challenges that single-team setups simply do not encounter. Requirements are more complex, dependency graphs are larger, and the cost of misalignment across globally distributed teams compounds quickly.
Adtran GmbH addressed this by adopting the Scaled Agile Framework (SAFe), a structured set of patterns designed for enterprise-level Agile adoption. Callsen explains what that looked like in practice:
We are currently implementing SAFe 4.5. In that framework, DevOps is not considered a team activity any more, but shows up as a mindset — though in practice, it is a combination of the two. Don’t forget to integrate DevOps in the planning process and encourage development teams to name their dependencies to specific DevOps methods rather than having each team defining their own CI or whatever. This is especially important when it comes to company-wide integration of artefacts from globally distributed teams, because building enterprise standards for code sharing dramatically improves build reproducibility, leading to better quality and productivity. A common understanding across teams, and a supporting DevOps community, is key.
Stefan Callsen, R&D Engineer, Adtran GmbH
The call for standardised CI conventions and shared artefact repositories is particularly relevant for organisations where teams in different time zones must integrate each other’s builds reliably. Ad-hoc tooling choices at team level create invisible integration tax at the programme level.
u-blox faced a different planning challenge: embarking on a complex project — the development of a new LTE Cat 1 wireless modem — before hardware and software specifications were fully defined. Uyttebroeck describes how DevOps provided a framework for managing that uncertainty:
We had to start the project before we had clear software and hardware specifications, so we knew we would have to make changes as we went along. DevOps gave us agility and control across hundreds of contributors in multiple teams. DevOps enabled us to achieve far more than would otherwise have been possible within the time constraints.
Stephan Uyttebroeck, Principal Software Engineer, u-blox
This underscores a point often overlooked in DevOps literature: the methodology is not only useful when requirements are stable. Continuous integration, automated testing, and short feedback loops are arguably more valuable when specifications are still evolving, because they make course corrections faster and cheaper.
Tools: Choose Deliberately, Stay Informed, Avoid Churn
The DevOps tooling ecosystem moves fast. Keeping up with every new entrant — and evaluating each one’s trade-offs — is a full-time job in itself. Callsen’s advice is pragmatic:
It is almost impossible to keep up to date and be aware of their pros and cons. So, don’t be afraid to stick to your tools decision if these fit your environment and fulfil your needs, now and in the future. Nevertheless, stay tuned to the outside world.
Stefan Callsen, R&D Engineer, Adtran GmbH
Woodward took the approach of bringing in external expertise to accelerate their tooling configuration. Pacheco explains:
External consultation helps focus your vision and gets you off on the right foot. We brought in a consultant to help us get the most out of Helix ALM. He spent four days analysing what we were doing and then spent 46 hours re-configuring the environment.
Steve Pacheco, Woodward
This is a useful data point for teams that are resource-constrained: sometimes the fastest path to a well-configured environment is a short, focused external engagement rather than months of internal trial and error.
u-blox adopted a more federated model for tool adoption — one that balanced standardisation with team autonomy:
Rather than enforcing particular tools, we gave people guidelines, best practices and led by example, but also gave them flexibility and responsibility. If a team finds transition to a new tool is too much for them, we allow them to step back and reduce the level of interfacing and delivery, as long as they take responsibility for ensuring what they deliver works with what other teams are delivering. The majority of users chose the recommended tools in the first place, and even the ones who initially stayed with their chosen toolset have gradually made the transition.
Stephan Uyttebroeck, Principal Software Engineer, u-blox
This graduated opt-in model is worth examining closely. Mandating tools organisation-wide can trigger resistance and slow adoption. Offering a clearly signposted recommended path — while holding teams accountable for integration compatibility — often produces the same long-term outcome with less friction.
Key Takeaways for DevOps at Scale
- Start with mindset, not tooling. Teams that understand the underlying principles of DevOps extract more value from their implementations than those who install pipelines without the cultural groundwork.
- Integrate DevOps into planning frameworks explicitly. Whether you use SAFe or another scaled Agile approach, DevOps practices should be named and coordinated at the programme level — not left as a per-team decision.
- Standardise artefact and CI conventions across teams. Shared conventions for code sharing and build processes reduce integration risk and improve reproducibility, especially for distributed organisations.
- Tool stability has value. Resist the urge to chase every new release or category entrant. Evaluate tools against current and anticipated future needs, then commit — while staying aware of the landscape.
- Consider external consultation for complex tooling environments. A focused engagement can compress months of configuration work into days.
- Federated tool governance can outperform mandates. Providing recommended paths with clear accountability for interoperability often achieves organisation-wide standardisation more sustainably than top-down enforcement.
- Plan for the long term. As Pacheco notes, today’s active projects become tomorrow’s legacy systems. Decisions made now about maintainability, documentation, and re-use have a long tail.
Final Words from the Field
Three closing thoughts from the practitioners interviewed capture the spirit of scaling DevOps well:
- Callsen (Adtran): “Do not underestimate DevOps tasks and allocate proper resources to achieve your goals.”
- Pacheco (Woodward): “Think of the long-term: today’s existing projects are tomorrow’s historical projects — they need to be maintained and leveraged for re-use.”
- Uyttebroeck (u-blox): “Just do it, but keep flexible, agile and continuously look to improve.”