5 things CIOs misunderstand about application development

5 things CIOs misunderstand about application development

Do you have a blind spot or two regarding the daily realities of your application developers? Here's what IT execs sometimes don’t “get” about modern application development

216 readers like this
Marketing Talk for the CIO

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."

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


Change very few words and you

Change very few words and you have one of many great article I read in 2008 about "what CIOs don't understand about application development."

Great article - If I can add

Great article - If I can add a 6th thing or at least an add on to the 5th about a series of one offs, it would be the expectation that a DevOps teams and business lines are separated groups that have only partial interaction. This is also old style thinking that business leaders give requirements and then application development teams code them. Full business line integration is no longer optional, it is critical to maintaining a competitive advantage.

Kevin Casey writes about technology and business for a variety of publications. He won an Azbee Award, given by the American Society of Business Publication Editors, for his InformationWeek.com story, "Are You Too Old For IT?" He's a former community choice honoree in the Small Business Influencer Awards.

7 New CIO Rules of Road

CIOs: We welcome you to join the conversation

Related Topics

Submitted By Mike O’Malley
July 07, 2020

The pandemic has created a seismic shift in today’s workforce. The increased emphasis on remote work and ongoing shift to cloud computing affect the future of security jobs.

Submitted By Conor Delanbanque
July 07, 2020

How did IT teams at financial data giant Bloomberg pivot to stay enterprise ready during COVID-19? Here’s what their head of telemetry shared

Submitted By Kevin Casey
July 06, 2020

Kubernetes helps IT teams increase efficiency, reliability, and consistency – which helps reap budget savings. Let's look at four people-oriented examples, from the value of a common language to freeing up talent to do new projects.


Email Capture

Keep up with the latest thoughts, strategies, and insights from CIOs & IT leaders.