7. Trust Enables Strategic Partnerships
Avoiding the Friday Afternoon Bug

Imagine this scenario: It's 4 o'clock on a Friday, and you receive an urgent voicemail from one of your key account managers. They inform you that a customer can no longer receive order confirmations via the API with your systems. You know it's going to be a weekend of conference calls, troubleshooting, and persuading colleagues to find the root cause and implement a fix, all while hoping to have it resolved by Monday morning. Sound familiar?

In this post, I re-introduce the concept of the organization partner maturity model, where teams, departments, or organizations demonstrate symptoms related to their level of maturity. I discuss the ramifications of outages, which often form a narrative among non-technology peers and can impact budget decisions. I explore the trade-off between additional features and maintenance, often perpetuating a reactive mode that creates a negative feedback loop.

To break free from this, I emphasize the importance of trust. Trust measures the quality of our relationships and can work for or against us. By demonstrating good behaviour, clearly communicating and delivering on commitments, negotiating shared outcomes, and actively listening without judgment, we can cultivate trust, build better relationships, and move up the organization's maturity scale toward becoming strategic partners and avoid the "Friday Afternoon Bug".


Listen, watch the media or read the transcript below to get practical examples and understand the tips on what this means in practice.

Other links mentioned in the article:


 
 

You can listen or watch on your favourite platform:

 Try for free our course here:  FREE COURSE TRIAL

Discuss with like-minded people :  FREE EVENT

Transcript

So imagine the scene. You get an urgent voicemail on your phone, and it is from one of the key account managers. You listen to it, and they describe that the customer can no longer receive order confirmations via the API with your systems. It's 4 o'clock on Friday, and the product team responsible for the API is about to clock off work, so you'll have to raise a service ticket. You'll probably spend your weekend on conference calls, persuading various colleagues to figure out the root cause and implement a fix, hopefully fixing it for a Monday morning.

It's a great start to the weekend. I've been there, and I bet you have too. It's a careful balancing act between getting everybody to contribute to a shared problem and avoiding the blame game between the person who designed the product, maintains it, and then uses it.

And we want to reduce the number of incidences, right? It takes time out of a weekend, causing stress; we have to put down work that we would otherwise want to do, and, reputationally, it can be very damaging as peers and colleagues in other departments will be asking if we have everything under control. It's the worst-case scenario when the client tells us of an issue. What is this symptomatic of, and where do we start?

---

I'm jon, and this is part of a series of short articles called "Tales from a Portfolio Manager". I help people in corporates plan technology across teams. You could be someone who has a technology portfolio - of clients, projects, or services or a backlog of features, and you have to manage them across a wide variety of teams to achieve any number of goals. I have been doing these roles for over 20 years for many corporates, and I have a few tales to tell. The best thing I can do for you is to encapsulate that experience into my advisory, online training and coaching so that you have the opportunity to reflect on how you can solve some pretty challenging issues that you come across and be more successful in your technology role. If you like the content, you can subscribe for a free two-week trial of our online courses at the side here ->. Thanks to those who have already subscribed; I look forward to speaking to you soon.

---

I will look at this problem at a higher level rather than just shortlisting quick fixes. In my third podcast, "changing gears", I introduced the idea of the organisation partner maturity model, where teams, departments or organisations demonstrate symptoms relating to the level of maturity at three levels, starting at reactive to service and then strategic partner. This situation I described earlier relates to a reactive partner level. I have yet to see an organisation where this situation doesn't arise. Still, at least the number of incidences gets less as the maturity increases as practices such as planned maintenance windows or a CI/CD pipeline is employed.

The ramifications of these types of outages form a narrative amongst your non-technology peers, and it is quite often those people who control the budget. Suppose you have been arguing for a budget increase to improve the maintainability of Apis, which would, in fact, solve some of the problems. In that case, Those who decide the budget may still focus on additional features rather than core stability. This trade-off between extra features and maintenance plays out in many companies, and quite often, we find ourselves on the losing side of the argument that perpetuates the Friday afternoon bug. It feels like a vicious circle where you're not allowed to remove the root cause yet punished for the symptom. I call this groundhog day, where you can't escape this negative feedback loop to keep you in this reactive mode.

This is often perceived as a wrestling of who controls what gets done.  I argue that the perception of control is an illusion. No one has ultimate control over anything. Yet, we focus on becoming the owners of decisions rather than influencers of decisions. Whilst we have that mindset, we are also not focusing on the level of trust, a more important and key enabler for you to solve this and many other trade-offs with decision-makers.

I focus on trust for a few reasons. The first reason is that it measures the quality of our relationships. Trust can either be positive or negative regarding whether it works for you or against you. For example, it is working against you when your peers are discussing the quality of your work negatively and without providing you with feedback for you to improve, using this as an opportunity to pursue their agenda. An example of where trust works for you is when people seek your advice on resolving their business pain points and take your advice on board. These aspects are partly cultural and partly the dynamic between you and another person. Whilst you can't change the culture, you can certainly influence the relationship quality with individuals.

The second reason I focus on trust is that it breaks the negative feedback loop I was talking about earlier and converts it into a positive feedback loop, where you can start moving up the organisation's maturity towards strategic partner status.

The final reason is trust is the oil that lubricates the gears. In many corporate companies, irrespective of where they are on the organisation maturity scale, getting things done, requires relationships which require trust. So whilst you may be an outcome focused person driving towards an objective, you may need to interact with 10 2030 people even to get something simple resolved. This means bringing people on the journey and negotiating the corporate bureaucracy also means that they only see how you perform for the brief moment on a teams call, the rest of the time they do not know what you do. Whilst I always strive for a positive outlook, it's been my experience that people often tend to think negatively and so, in the void, will assume the worst. I have found that we have to work harder to demonstrate the results of our work clearly and consistently. Note, I didn't say just work hard, but work harder to demonstrate the results.

Let's step down further into the detail of this.  One of the worst things you can say is, "Trust me". It's a demand for compliance and an attempt by you to control the situation., Especially without any evidence for people to rely on. To cultivate trust, you need to demonstrate good behaviour, so I suggest communicating what you are doing clearly, doing it and then sharing that you've done it. Being consistent in this approach helps people understand and match what you say against what you do. The other element of trust is negotiating shared outcomes you can both agree on and commit to. These outcomes might be tactical; they may not be what you want exactly, but they actually serve a greater purpose than your own. I discuss this in greater detail in my shared outcomes blog post.

Creating trust is a profound and broad topic, which I cover in some detail in the relationship management course and upon which all my subsequent courses rely. However, an essential piece of advice I have learnt is to listen. To listen without judgement, without interruption, with your full attention focused on the other person and to reflect on what they've just said. I mean, literally, repeat what they said in your own words so that you demonstrate you've understood. It's compelling. Yet in the hurly-burly of back-to-back meetings, where everybody on the call has their own agenda front and centre, we have to make use of our two ears and control the use of our mouth. I have experienced the difference in people's approach to me when I have applied these techniques - it is like night and day when you go from a person who is known for saying no (for example) to someone who engages in what other people have to say, no matter what you think of them, their demands, beliefs or attitudes.

So some different tips from what you might've expected around strategic partnerships. Understanding some of this counterintuitive approach to getting things done took me a while. Still, these are some of the first steps to building relationships, building trust, getting stuff done, to avoiding those Friday afternoon bugs.

So there you have it - Stay tuned for the next episode of Tales From a Portfolio Manager.

7. Trust Enables Strategic Partnerships
Baxter Thompson Ltd, Jon Baxter
17 May, 2023
Share this post
Archive
Sign in to leave a comment
6. How do we know when we are successful?
Unlocking value and measuring the right things