4 Forward-Thinking Strategies for CTOs to Improve Developer Productivity

I’ve spoken to hundreds of tech leaders over the last few years. If I’ve learned anything, it’s that relatively small operational changes can have an enormous impact on productivity.

Those changes might come in any form, from finding better ways to share what matters and getting to cancel 3 hours' worth of meetings every week, to making a strategic tool choice that makes code implementation 3.5x faster (no, really, I’ve seen that).

I see four strategic choices CTOs and engineering leaders can make, leading to significant inroads in developer productivity and developer experience (DX, or DevEx).

Let’s get started.

1. Eliminate communication missteps

Information transfer is complex, and almost every engineering team gets tangled in those complexities.

Code or infrastructure implementation failing to go to plan isn’t the only thing that send projects sideways.

I’d even say, more often than not, the underlying (or sometimes, overt) reasons projects go sideways are far more to do with information transfer issues.

For example…

• Duplication of effort. Ambiguous task assignments and information silos cause two teams to try and solve the same problem.
• Changes in silos. There are alterations to design, scope, or functionality, but developers may work on outdated information.
• Misinterpreted requirements. Product specifications are misunderstood, and we build the wrong features, disrupting timelines and wasting resources.

Humans, remarkable as we are, come with inherent limitations. 

Memories lapse. Bias is innate. Our capacity to consume and to share is inherently limited. These are the contours of the human condition.

Agile methodologies have tried to build guardrails for these limitations, but even with its merits, Agile has its own blind spots. 

We need to be strategic. Here’s what we can do…

1. Pursue concision and purpose. Less is often more when it comes to discussions. Cut out 'nothingy' meetings that merely regurgitate activity. Channel your team’s energy towards strategic communication and problem-solving collaboration.
2. Distribute information selectively. Overload leads to paralysis. As a tech leader, your role is to direct the information flow in a way that it reaches the right individuals at the right time – including you! Leverage the features of your communication tools to make this possible.

I have some big ideas for achieving this, and I’ll cover them in Strategy 4.

2. Exponential gain from smart stack selection

I can’t overstate the importance of selecting the right tools for a development team, but also being willing to make strategic changes.

This is not just a matter of simply increasing developer productivity or team satisfaction - it's a crucial decision that carries disproportionate weight in the success of our project outcomes.

Let's be clear - selecting ergonomic, intuitive, and enjoyable tools with a good user experience is not just a 'nice to have'. It's a critical driver of productivity that directly affects the bottom line. 

We are not talking about a mere linear relationship. When your team loves their tools and are having a good developer experience, the productivity boost isn't just additive, it's multiplicative.

And we add more multiples if those tools play nicely together.

Practices like sharing IDE settings, using macros for repetitive tasks, or setting up team-wide extensions are not mere options - they're prerequisites for creating a synergistic tool environment.

I wrote in more detail about that here. 

We risk losing potential hires (alongside our existing people) if our tools are not up to the mark, too.

I’m sure you know that many engineers – especially the best engineers – will have technologies that they simply won’t work with after a bad experience elsewhere. And they can afford to be picky.

3. Mastering visibility and transparency

Common wisdom says transparency and visibility are good, and this isn’t wrong! It’s just that there’s a difference between visibility through availability, visibility through surfacing and visibility through inundation.

I think of “visibility” as the simple presence of accessibleinformation, while “transparency” goes beyond that to encompass the organizational culture surrounding information sharing.

Visibility

We want

• Visibility through availability – All the information to be available, in principle
• Visibility through surfacing – The information we really care about to be surfaced, automatically

Visibility through inundation occurs when information we don’t care about or need to know is regularly thrust at us.

Visibility through availability – some examples

• Dashboards for tracking performance metrics
• Project progress kept up-to-date in Jira
• Verbose pull request descriptions and commit messages
• Good Figma file naming conventions

Visibility through surfacing – some examples

• As the project manager, you read the software developers’ daily standup reports to see progress, plans and blockers
• As the CTO, an engineer flags a product delivery risk to you directly
• As an engineering lead, you receive an AI-generated alert that there’s an outage that demands your attention
• As a software engineer, you see clear acceptance criteria on the ticket you’re working on

Transparency

A transparent environment is one where open communication, trust, and psychological safety prevail.

Where there’s transparency, there’s open flow of information which supports visibility and accountability.

I don’t want to get into a load of detail here, but in brief, I think some of the best ways to create transparency are:

• Ensure team members feel safe to express opinions and concerns without fear of negative consequence.
• Reward balanced risk-taking, and emphasise the importance of reflection and experimentation.
• Actively listen, openly validate your team members’ perspectives and welcome diverse perspectives. This is a crucial practice for inclusion.
• Be transparent yourself. Share thought processes, ask for feedback and admit mistakes.

One practical point – if you work in an organisation where communication often happens in hidden one-to-one exchanges, I would strongly encourage you to make sure the right public channels are available – say, in Slack, or Teams – for people to have most discussions in open forums. 

Shifting these dialogues into shared spaces simply makes visibility through availability possible. 

If you have this right, you probably have too many channels to keep up with.

That’s where we need to be smart about it. Which brings me to…

4. Leveraging AI

Teams that have already adopted AI tools report 250% gains in speed, according to this AI Adoption Report.
Let that sink in.

These gains aren’t hypothetical AI hype. To put this another way, engineers who have adopted artificial intelligence, regain 3 hours out of each 8-hour day.

And those same teams estimate that in the next year, they can be operating 350% faster – that’s 5 hours back out of every 8 hour day.

I wrote here in detail about the sheer size of the competitive advantage engineering teams who adopt AI will gain – and in contrast – the sizeable competitive disadvantage non-adopters are signing themselves (and their companies) up for.

AI for Development: Code Implementation, Review, and Tech Debt Management 

Not all AI is good AI. There’s a lot of stuff on the market right now that kind of sounds cool but is basically just a shallow layer between your data and an LLM, often GPT-4.

But there are also some game-changers in most categories. These companies who are getting 250% gains in productivity have nailed this.

For a full list of 7 AI productivity tools CTOs need to know about, head here.

Here are some use cases:

• Code implementation. Get real-time code suggestions, auto-completion, auto-generation, comprehension and more. Try Sourcegraph Cody as a next-gen alternative to the now behind-the-curve GitHub Copilot.
• Testing. Writing test suites doesn’t get most of your devs up in the morning. Specialist tools can yield better results – try Codium.
• Documentation. Your engineers will thank you… Try Mintlify Writer, an AI that deeply understands your codebase and auto-generates great docs.
• Code review. Automatically generate great descriptions, get AI to make minor changes and automatically merge “safe” pull requests. Try What The Diff or Planar.
• Tech debt. Dependency migrations and the like waste so much time. AI tools for tech debt like Grit automate this drudge work.

AI for Agile Reporting

Remember those communication and visibility challenges we discussed earlier? 

The overwhelming flood of data, the struggle to surface only the necessary details, and the constant battle to maintain clarity while reducing noise. These are universal tribulations faced by teams everywhere.

With my team at Stepsize, I’m working on Stepsize AI.

Stepsize AI is an Operational Intelligence Engine that integrates with your issue tracker and produces super accurate weekly agile reports with the perfect amount of context and detail.

That allows it to share introspective but concise reports that get to the heart of what matters, whether you use Agile sprints, Kanban, FaSt or some other Agile methodology.

‍

This is a deep, impactful use of AI tech that is transformative for teams – but you don’t have to take my word for it…

Stepsize AI is out in the wild, and you can get access here. I’d love for you to try it out!