Chasing efficiency in the Software Delivery Chain

In my journey to find ways of helping Tech Leads deliver better solutions, I often stumble upon a dilemma. How to effectively deal with the challenge of quickly delivering solutions while ensuring they are robust?

After working for over 18 years in the IT industry with services companies, one thing stands out as the key to success. Seeking efficiency by breaking silos, solving problems collaboratively and multiplying have proven to be good techniques.

“Talent wins games, but teamwork and intelligence win championships.”
— Michael Jordan

Chasing Efficiency in the Software Delivery Chain

My purpose here is not to delve into efficiency x effectiveness x efficacy and how they can be combined to drive performance. There is an overwhelming number of outstanding books and articles covering this area.

Although I couldn’t help but quote Peter Drucker, just as food for thought, as he brilliantly said:

“There is surely nothing quite so useless as doing with great efficiency what should not be done at all.”
— Peter Drucker to Harvard Business Review

Now, with that in mind, let’s assume that we aim at the right target to be effective in the delivery chain. How can we chase efficiency and aim at delivering more value with less effort/cost?

“Efficiency is doing better what is already being done”
— Peter Drucker

I am kicking off a series of articles focused on efficiency in the delivery chain. And in this article, you can find some ideas that resonate with my own experience and lessons learned.

Connect people with different perspectives

No matter how experienced or determined you are, it is impossible to catch every detail when working on complex software projects. And it’s OK, as long as the way you deal with it doesn’t affect the desired outcome. So, you better admit that you can’t get it right by yourself and seek different perspectives.

“Everything we see is perspective, not the truth.”
— Marcus Aurelis

The judicious education I received as a kid made it challenging for me to understanding that it is OK to ask for help. I had been taught not to do it, to stick to an image of self-confidence. This is a limiting belief that I am proud to have gotten rid of a while back.

I have always guided my Tech Leads team to seek an outside eye perspective as early as possible. I mentioned a few techniques we put in action in my previous article on 7 of my favourite tactics as a Tech Lead to empower a team of champions. In this series, I will go deeper into the techniques I use.

Chasing Efficiency in the Software Delivery Chain

Architecture Debrief sessions have brought enormous value to our projects at PhoenixDX, by helping teams find the path of least resistance earlier in the game. These meetings allow the project team to play the solution design back to other mates in the company. They happen for the first time while the project team is still in discovery mode, designing the solution. And then repeat regularly, every other week or so.

The last time we did it, we put together 2 Tech Leads with different project backgrounds and 1 Solution Architect in one room. All of them had extensive experience. The project’s Tech Lead introduced them to the big picture of what we needed to deliver. They shared ideas with a non-biased perspective, brainstormed, and brought up super valuable insights that ultimately benefited the project.

Their contributions spanned across a multitude of areas. NFRs (non-functional requirements) that were not clear enough to uncover and adequately mitigate risks. Components they had built when working on other engagements saved valuable time enabling the team to focus on delivering more value. They even shared essential tips to avoid troubles they had faced before on similar projects.

The problem is: Everyone is too busy nowadays, right? To get this going, you need to plan. Make sure that you get enough quorum is key. The gold of these sessions is the contribution of the external parties, and if they are not there, the team might lose the mojo, and it won’t get traction.

The truth is: after diving into build mode, it was clear that the power of the group put the project team on the path of least resistance.

Friendly advice: Leverage these opportunities to listen and ask open questions. Remember always to ask questions. There are no stupid questions.

“There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question.” — Carl Sagan, The Demon-Haunted World: Science as a Candle in the Dark

Stay tuned for more insights about how to improve efficiency in the Software Delivery chain.

 

Joao Melo
Technical Lead
Connect with Joao on LinkedIn

This article was originally published on medium.com.

A selection from our recent work