5 things CIOs misunderstand about application development

IT leaders, you didn’t get to where you are today without knowing your stuff.

Still, as a CIO or high-ranking IT exec, you’re probably not doing in-the-trenches development work anymore. Rather, you’re leading your company’s overall digital business strategy, ensuring your team is driving toward critical business goals, crunching budgets, communicating with the executive team, meeting with customers, and so forth. If you’re writing code on a regular basis, something’s probably amiss.

Which is all to say: It’s natural for IT leaders to have a blind spot or two when it comes to the day-to-day realities of their development teams. Modern application development is a constantly changing field: new languages and frameworks, new processes and best practices, increasing automation, and so on. Even if you’re good about staying abreast of new trends and issues – as you should be – it’s both likely and reasonable that you might not know everything.

[ Learn how companies like AT&T, Walmart, and Toyota use agile methods wherever possible in the Harvard Business Review Analytic Services report “Transformation Masters: The New Rules of CIO Leadership” ]

One way to clear up misunderstandings and blind spots when they do occur: Make a point of stepping back and taking stock once in a while. Ask those around you: What am I misunderstanding – or altogether missing?

We asked several application development pros to share what CIOs and other IT execs sometimes don’t “get” about modern application development. Here’s what they shared. 

1. You can’t micromanage DevOps teams

DevOps (or DevSecOps) is becoming the dominant culture of modern application development. This is a considerable change for many application teams. What doesn’t always click for IT executives and managers that oversee those teams: You might need to adapt your leadership style, too. Micromanagers in agile clothing can scuttle the best intentions of DevOps culture, adding development bottlenecks instead of reducing friction in the delivery pipeline wherever possible.

“Stop micromanaging development,” advises Nate Berent-Spillson, senior delivery director at Nexient. “Both Agile and DevOps need executive sponsorship and a certain amount of top-down leadership to get going, but all too often middle management gets in the way. Most of your success is going to come from the bottom-up.”

[ Working for a bad DevOps boss? Or are you one? Read: Bad DevOps bosses: How to deal with them ]

You can check in sometimes. But focus on leadership and enablement, not command-and-control tactics. Ask how things are going, and don’t sit on feedback when your team says there’s room for improvement; be ready to intervene and offer appropriate help when things go off track.

“If you ask what’s wrong and what can be improved, and then ignore the feedback, expect morale to crash and your best people to start leaving,” Berent-Spillson says.

2. Bad project estimation processes drag people down 

Berent-Spillson says he often sees development teams get bogged down by misguided or inaccurate processes for estimating timelines of development projects.

For example, on teams that use Agile user stories, Berent-Spillson sees executives and managers translating story points into an arbitrary number of hours, rather than basing timelines on the team’s historical performance and other factors. This approach is exacerbated when it is used to compare different teams.

“Don't compare story point velocity between teams. It's nonsense,” Berent-Spillson says. “You’re just going to encourage point inflation and sandbagging.”

In general, arbitrary or one-size-fits-all estimation processes don’t suit modern application development practices.

“If you want to get better at estimating, you need to estimate smaller amounts of work, in story points rather than hours, by a team that is using a consistent approach [across projects],” Berent-Spillson advises.

3. Legacy security approaches won’t work with modern applications

One reason why DevSecOps is gaining traction with IT leaders: DevOps teams often end up building or reinforcing a silo around security, even as they eliminate friction elsewhere in the software pipeline.

“Many CIOs are still relying on legacy application security activities and timelines in a modern DevOps world, which is doomed for failure,” says Shivajee Samdarshi, SVP of engineering at WhiteHat Security.

If you’re using the same old security playbook, you’re doing it wrong. If this is an issue in your organization, it’s likely going to need an executive champion to facilitate change.

[ Read our related story, How to build a strong DevSecOps culture: 5 tips. ]

“CIOs leading DevOps movements must strive to proactively empower developers to code using security best practices, and suggesting up-to-date security integration strategies that make sense for developers,” Samdarshi says. “Therein lies the true challenge of security in DevOps – the ability for CIOs to completely revise their legacy thinking to embrace the modern world of application development, where security with speed is a top priority.”

4. Automation isn't optional

Automation is critical to ensuring speed without sacrificing security or quality. 

In terms of the latter, Berent-Spillson says CIOs need to understand that automated testing will enable development teams to move faster, and do so in a scalable, sustainable manner. If you misunderstand (or miss completely) the value of automation, it’s time to address that:  Automation will play an increasing role at just about every stage of the software development lifecycle.
“Automation is what will allow you to go fast forever,” Berent-Spillson says.

5. Application development isn’t a series of one-offs

Some CIOs might view application development – or product development, more broadly – as a string of one-off projects. That’s monolithic thinking, and it’s increasingly distant from how modern applications get built and operated.

Berent-Spillson sees this mindset manifest in a hypothetical scenario that might come from good intentions but proves counterproductive. It goes something like this:

You set up a team to build a particular application or solve a particular problem. That team embraces DevOps culture and the tools, processes, and practices that enable it. And it’s a roaring success: The product owner and team are building applications and features driven by business need, metrics, and regular feedback loops. Everything is humming; this is an “A” team.

“And what does the organization do next? It dismantles the team and puts everyone back in their silos so they can ‘spread the knowledge.’” Berent-Spillson says. ”They take the product the team created, send it over to operational support, and forget about it until something breaks. Then they try to get some funding to fix it as a new ‘project.’ Why even bother?”

This line of thinking is the IT version of the “if it ain’t broke” adage: Don’t fix problems that don’t exist. Let highly productive teams continue to be highly productive. 

But there are better ways to spread knowledge. Moreover, it’s antithetical to modern application development best practices.

“Product development isn't a one-off,” Berent-Spillson says. “It's an ongoing process that depends on a skilled, well-coordinated team. When your people are firing on all cylinders, don't scrap the engine for parts.”

[ Are you a DevOps job seeker or a hiring manager? Get our free resource: The Ultimate DevOps Hiring Guide. ]