Enhancing Developer Productivity: 4 Approaches for CTOs

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.

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 sends 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 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 accessible information, 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 an open flow of information that 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 consequences.
• Reward balanced risk-taking, and emphasize 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 organization 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.

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 don’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 Collaboration

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 to solve this, and I’d love to hear your feedback.

Stepsize AI is an Operational Intelligence Engine that integrates neatly with the tools you use to work and collaborate and observes everything that happens. It reflects on activity and forms higher-order thoughts, effectively building a data graph.

In other words, it can understand your business context, project context, and goals and use this to surface what matters.

That allows it to share personalized context-aware status updates, insights, reports, and alerts. You can configure bespoke updates to do things like…

• Replace daily standups with fine-tuned updates.
• Cancel your weekly status update meeting.
• Get alerts when something you care about happens, like outages or bugs affecting your key customers
• Generate ad-hoc reports, which you have the chance to edit first, to send to whoever needs them
• …And loads more!

We’re already seeing evidence that 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 let me know how it lands with you!

Also published here.