The CTO Playbook

Chapter Two - Bridging the Gap

As a follow-on to the last post I'll go into a little more detail on how to build and maintain productive relationships with the rest of the business.

You may have heard the phrase "relationships take work" - while this is true in our personal lives, people frequently neglect to apply this in their work relationships.

The simple truth is, being unable or unwilling to develop productive, professional relationships with your peers is career-limiting.

What does professional, in the context of building relationships, actually entail? It means being friendly and approachable. (And yes, there's a lot more involved in being professional in general that will not be covered here).

Even if you believe "friendly and approachable" stretches the definition of "professional", in a modern organisation where you need minimal friction and maximum alignment and communication, it absolutely is part of your professional responsibility to be friendly and approachable, and to model that behaviour for everyone in your team.

So HOW do we do this? What are the practical steps required here?

I've alluded to to this above - you need to work the relationships.

Let's separate this into some general steps:

1. Interview everyone and understand their world
2. Dig into issues
3. Focus on the future
4. Come clean
5. Get results
6. Say No
7. Move from reactive to proactive

Interview everyone and understand their world:

Set up interviews with all of your peers across the business, first at the executive level and then with key staff who report to them (continuing down the hierarchy to whichever level's necessary and practical).

At the end of these interviews, set up a regular 30 minute catchup - this should be weekly for your peers, less frequently as staff get further from you in the organisation hierarchy.

This achieves two things - first, the goal of these interviews is to gain an understanding of the needs and frustrations of the rest of the organisation, and how these departments interact with and rely upon yours. You need to do this to be effective in your role. Second, is the process; sitting with individuals and listening to what's important to them is key to building these relationships.

Dig into issues

Take notes during these interviews and write down issues that people mention. Chase them down. Dig deep into the issues you find. Do it visibly and communicate back frequently. Set the example for your team as to how to effectively get things fixed. Demonstrate the importance of addressing the needs of the business and expect your team to do the same every day.

This is probably the single most effective way to learn how the organisation's systems, processes and people work. It gives you valuable insight into your department's capability.

Part of doing this means you'll have ongoing opportunities for face-to-face interactions with the staff involved, which is key to building these relationships.

Focus on the future

Let's imagine a peer complains about a project that wasn't delivered on time. You know that their department changed requirements a dozen times, was unclear about time-frames and were late getting the project approved.

None of that matters.

The bottom line is that the project was unacceptably late, and you're going to take ownership of that. If you're doing this right, all you're interested in - and aggressively so, is how is how you, your team and the organisation can do better next time. You're not focussed on preventing your team from 'looking bad'.

As an executive, you're required to step back and address the overall needs of the organisation - and that is to deliver value to the market.

So the questions you're asking should be focussed on the future:

• How do you build the right relationships to ensure better and more timely communication with the other teams?
• What processes need to be changed and tested to catch problems early on?
• What aspects of your team's delivery can you improve upon?
• How can they deliver faster with better quality and less re-work?
• How do you better elicit requirements from the other teams?
• How do you assist them getting the project approval over the line on time next time?

You're focussing on the future, and the past is only there to improve upon.

In terms of building relationships, if you've adopted the above frame you'll be able to drive conversations forward much more productively.

Come Clean

Is your department delivering zero-defect code on-time, at low cost and doing so repeatedly and consistently? Are all of your systems resilient, secure and always available with zero performance issues or service interruptions?

Probably not. (But if they are, kudos to you!).

In reality, I expect you're painfully aware of shortcomings within your area - you may have frequent incidents, lots of underlying security issues, a mountain of technical debt, staff who are struggling with workloads, project complexity or personal issues - and you don't have appropriate budget to fix most of it.

Pretending that everything is "just peachy" is detrimental to building good relationships and a great way to lose credibility. People see through this - they're fully aware that there are issues, and have probably experienced many first-hand.

So do the opposite. Be open and transparent about your department's strengths and weaknesses, and the work you're doing improve.

Too many people become evasive and defensive when they - or their team - are facing criticism.

If you find yourself in a conversation like this, you don't have to immediately agree with all of their criticism - but the first step is always to listen. It may take a lot of effort to keep your mouth shut!

Take a mental step back - while their accusations may be unfair or incorrect, you may still be able to agree (out loud, so they can hear you!) that the overall outcome could have been far better. At this point, if you're watching them carefully, you may even see them relax - because they realise they're being heard, and they suddenly have a way forward - a stepping stone to improving things. And it started with you shutting up and listening.

As you go through this process, you're going to uncover all manner of issues, and being forthcoming about these as well as how you're going to address them, is one of the most effective ways to build trust and alignment with these teams. As part of this process, share your vision of what you'd like your team's delivery capability to look like (you're also sharing this with your team, right?). Again, this demonstrates that you're aware that there are issues and you will be working to improve things.

Every departmental issue is an opportunity to improve something and to deliver better next time. Every time you do this, and communicate it, you gain credibility within the organisation, and you strengthen your relationships with those involved.

Get results

In your next weekly meeting with your peer (you have set up weekly catchups, yes?) you should be able to step through the issues raised in the previous meeting. You'll note what's been fixed, what requires further work and what can't be done (and why).

I've frequently encountered a level of astonishment when I do this - because nobody's ever done it for them before.

Keep doing this.

The goal is to change their perception of the technology function within the business. The current perception might be that things are constantly breaking and the tech team are unresponsive. We want to improve what we do to the point where the rest of the organisation's sentiment becomes "The technology team understands us. They care about what we do and they work hard to help us deliver".

There's a world of difference between the two.

Say No

I've presented a relatively one-sided view of this so far - in reality you're going to have significant competing initiatives, and general day-to-day distractions that take your focus away from delighting this particular imaginary department.

You'll still be able to get some small or medium issues fixed but then be left with larger systemic or architectural issues that can't quickly be resolved without a larger project. Again you can be open and transparent about these - there's generally a cost-benefit discussion to be had here. These projects should be weighed against the many other projects in the pipeline and prioritised (or not) as appropriate.

And this is where the relationships you've built so far help, because for many of the things that people want, you're going to have to say 'No'.

Side note: I haven't talked about it here, but I strongly recommend setting up a project ranking system (transparent to all project stakeholders within the business) that shows everyone where their project is in the delivery cycle (or backlog). This system and the ranking of projects therein should be defensible based on cost benefit analysis as well as alignment with the larger business values, goals and mission. Properly done, this system is also a process that occurs at the executive level, fostering alignment and buy-in - not just a roadmap that gets handed down. Perhaps that will be another chapter.

Move from reactive to proactive

This is covered my many operational maturity models, and it really is where most of the hard work is.

The goal is to move your department from a reactive mode of operation to a proactive one.

Perhaps you don't even feel you're at a reactive state yet (non-responsive and floundering? Be honest!). The next step is to get to a responsive state, with metrics and SLAs that you can use to highlight issues and measure progress. Don't forget to continually communicate improvements.

And from there, gradually, to proactive - where you have a technology vision for the organisation, can anticipate the needs of other departments, of the market and are approaching them with solutions they didn't know were possible. There's no straight line to get there and you'll always be balancing against underlying technology, budgetary and people constraints.

But it will go much easier, much faster, and be far more enjoyable when the relationships you've built with the organisation mean that they've got your back and they want you to succeed.

Link to Chapter 3: https://www.dhirubhai.net/pulse/cto-playbook-rob-hill-d9eqc