Skyrocket Your Output with Dev-Like Thinking Strategies – Expert Tips by ZDNet

fotostorm/Getty Images

Culture not only eats strategy for breakfast but also dines on DevOps as a mid-morning snack.

The key to successful collaboration within software shops is not just to align developers with operations teams, but also to release the inner developers within ops team members. The head of DevOps for Nasdaq says the time has come for the ops side to take on greater roles as developers.

Also: Implementing AI into software engineering? Here’s everything you need to know

Encouraging more of a developer mindset is now critical, said Amado Gramajo , vice president of infrastructure and DevOps engineering for Nasdaq, who shared some of his experiences with attendees at the recent Developer Productivity Engineering (DPE) conference in New York, sponsored by Gradle. You have administrators on the ops side and developers on the other side. It’s time to encourage admins to think more like developers, he urged.

Newsletters

ZDNET Tech Today

ZDNET’s Tech Today newsletter is a daily briefing of the newest, most talked about stories, five days a week.

See all

Productivity on the developer side has always been a challenge. But productivity leads to happiness, and “happiness is the key,” he said. “Happiness means a lot of things to different people, and especially to developers,” Gramajo said. “But in the context of DPE, happiness for developers is staying on top of their creative flow, with stable quality, stable code, stable deployment. A happy developer means they have good software. A happy developer means that they’re going to be nice to ops.”

The final remaining frontier for such positive collaboration, he continued, is in build and test – which calls for engagement from both development and operations teams. Rapid deployment, automation, and continuous integration/continuous deployment have enabled shops to turn around software with great frequency – “but it’s not that shiny anymore,” Gramajo said. “It’s just deployment of software, and it’s fine to deploy fast.”

Opportunities for productivity, as well as new ways of working, are now arising within the build-and-test phase preceding it, focusing on development productivity engineering, he said. “That’s how you improve the quality of software. That adds real business value.”

Also: Everyone loves low-code/no-code development, but not all are ready for it

The challenge, he continued, is that software is conceived, built, deployed, and managed by separate teams: “As new technologies sprung up – cloud, Kubernetes -- enterprises have had dedicated teams, such as infosec, internal audit, and infrastructure – many teams that have one function for a specific reason or purpose. It’s not a negative thing, and you’re getting more controls, more guards and guardrails.”

Integrating more of this work is stymied by the fact that IT professionals are compensated and mandated with single-purpose roles, Gramajo explained. “What I’ve seen is some teams with hundreds of projects and thousands of developers, you have different scopes and different capabilities. But the development teams can’t pick up and continue the work of security, get other things done, or add modules for resiliency. The context is the developer is working on this project work that their getting paid for, and can’t switch the entire thing around. And that’s creating friction between the development group and other teams.”

Not the path to developer happiness, for sure.

Gramajo’s solution at Nasdaq – which operates more than 130 markets around the world – is to build shared services platforms on which developers, operations teams, and other IT professionals can collaborate. Gramajo, who comes from the operations side of the house, recognized that many of the people working with him were becoming de facto developers in their own right. Also, “we can pick up all the stuff developers don’t want to deal with that’s causing friction.”

Also: AI will change the role of developers forever. Here’s why that’s good news

Corporate or workplace culture – which everyone wants to change – is almost impossible to change, he says. Instead, he calls for a systematic, engineering approach. “If a company is trying to do DevOps or whatever, the first thing you think is, ‘well. how do you change the culture?’ You have to change the culture, through three-ways or feedback loops or whatever. But nobody ever changes the culture, right? They just talk about it, and put up a sign in front of the elevator with values.”

But what can be changed is the mindset of IT teams, “which is more engineering-minded, instead of waiting for something to happen, you start developing a solution for something. Now they’re realizing that they’re not just the admins, they’re also engineers writing code.”

By leveraging a systematic approach, “you’re able to change the culture,” he added. “By having a look at what makes a company defined is the way the people work in the enterprise, and the way they work is based on the policies and procedures. So the challenge is to start looking at the policies and procedures, start enabling the ops team to work and operate more like developers.”