Year-End Insights: How Lacking Delivery Focus Leads to Major Tech Hurdles

2023–Learnings From Working With Tech Organisations

To close this year, I want to write about some commonalities I experienced when working with other tech organizations as a fellow. At the beginning of 2023, continuous delivery (CD)¹ wasn’t as much of a priority to talk about as at the end of the year.

When I started to help others as a fellow in 2022, I had already been practicing CD for years. During the years beforehand, I wasn’t really aware of the terminology; it just felt suitable to practice it, including Trunk-based development. It felt natural, especially for the traditional SMB type of company.

After joining several organizations this year as a fellow and mentor, continuous delivery was the most lacking practice. The longer we dug into root cause analysis, the closer we came to the same conclusion each time:

👉 The engineering wasn’t centered around the idea of delivery.

The following Wrongs were common:

Development and Software Releases were tightly connected (Git Flow)

That was incredibly dominant in cross-platform setups, in which web and native development were done simultaneously. The entire development cycle was centered around complex and more significant feature releases. In theory, that was a good idea for everyone; in practice, it never really worked out.

The reason for that was simple: Constraints. The teams never had enough time and capacity to make those giant leaps due to much feedback from the last feature release, which was often about dysfunctions. Instead of working on the current feature, engineers worked on many features in many contexts, which led to the stacking of a second backlog.

In more extended isolation periods, the developers worked independently to fix bugs or somehow ship the current feature set. That resulted in many Git branches having huge differences between platforms.

👉 A very negative side-effect was the toxic culture emerging from that. Instead of openly talking about problems, things were covered up, and finger-pointing was the day-to-day culture. In reality, it was just about losing control.

🍪 Solution: Decouple Development from Feature Releases. Release what you have done this day, get feedback, and iterate on that. Don’t work in long-lived branches; only push to version control when your changes pass tests and are ready to deploy. Consider Feature toggles to “shadow” deploy partly working features to collect technical feedback (Stability) and user feedback (Acceptance) already.

Working with large and complex tickets (Opposite of small batch sizes)

The missing sense of a short development life-cycle is related to the last point. Badly-defined tickets were created without the involvement of the engineers in any way, which contained too many ideas for just one task. This is often the root cause of many quality problems. Quality was never defined, not by the product owner, not by the project manager, or by the engineering department. Even more problematic is that quality is hard to determine for the engineer during development.

A clear sign of dysfunction is when an engineer starts to work on a ticket, there’s an immediate need to clarify things. But we are already in the development phase; the task should be straightforward and single. Otherwise, the engineer won’t determine if the task is done.

When this is the case, you can be sure that the engineering department is disconnected from the feedback cycle of changes made to production. Instead, other people in a “department” gather and process feedback without involving software engineering.

The funny part: Somehow, companies don’t want to understand that software development is about the process of engineering and feedback; it’s what the software engineer is supposed to do. Well, that’s not funny; it’s sad and a root cause of many business problems and toxic cultures.

🍪 Solution: Start to work in smaller batches, at best defined together with the engineers. A single ticket should contain a single task, clearly defining when it is “done.” To clarify, done means ready to deploy to production and collect feedback to iterate. It’s not meant to be feature-ready! Accept Feedback-Cycle as part of the development process, including product owners, engineers, and users.

Waiting for being “Done” before releasing to production.

Imagine you have a more extensive feature, an estimated 3 weeks of work. Now, an engineer has started working on that feature and disappeared for 3 weeks, just reporting here and there some cryptic reports, pretending “we are on track.”

On what track, please?

We are talking about a feature of a minimum of 120 hours of work if a single developer is working on it. How can a poorly written set of tickets and a Figma file represent what the client needs, and how can you ensure the engineer understood the needs and why things were described like that?

Understand: The engineer is still developing the feature. Feedback is necessary during this period!

After three weeks, we realized the estimation was wrong, and we needed two more weeks because of X, Y, and Z problems. Business stakeholders become nervous, the Product Owner puts more pressure on the engineering department to get the feature “done,” and users still haven’t seen anything of value.

Instead, users keep reporting other issues, which the mentioned developer needs to fix while working on the current feature. Which is probably the X, Y, or Z problem.

👉 That’s the recipe for failure.

🍪 Solution: Deploy at least at the end of every day as an engineer. Deploy and show the results to stakeholders, PO, and users. Gather and discuss the feedback. By doing that, there is already clarity about the “track” you are on after a week, which is 1/3 of the time. Stakeholders know colleagues know, and users may have provided feedback already. You delivered business value before even releasing the feature.

Great side-effect: You remove a lot of stress-based toxicity from your culture. Stakeholders want to see progress. You show progress daily, not after 2 weeks of overtime.

A related topic: Do we need branching?

Delivery and feedback should be the central aspect.

Let’s be honest: the problems or Wrongs mentioned above show that no one cares about delivery and feedback. It’s more about pushing towards an artificial, roughly defined release in the future. That’s the easy route; tempting but sure to fail long.

Yes, this is one of the major commonalities I have faced in different companies of different sizes in the last two years.

Nurturing a Continuous Delivery culture is a safe way to mitigate these problems to create ongoing value and clarity into which direction we wanna go as a company and tech organization. It’s about mitigating unnecessary stress and open communication.

Business stakeholders aren’t bad people; they also have their “stressors”. Help them as engineers to keep them informed daily and haptically about the process you do. Even if you have estimated wrongly, the business will understand and “forgive” if you can honestly explain that by showing the actual process daily.

That’s basic human psychology – no hocus pocus.

🍀 My year’s last words

I wish you a great start to the new year 2024! Thank you for reading and providing feedback in many messages and conversations. I am grateful to have met many great people on Substack and LinkedIn.

Thank you so much, everyone! I am looking forward to the following:

🍪 over 52 article issues about Tech Leadership, Culture, and Software Engineering

🎓 over 52 mentoring article issues, based on my direct learnings from being a fellow.

🍪 over 200 hours of streaming with

Denis Čahuk

“Our Tech Journey”

🍪 over 200 snackable mentoring-type-of-posts on LinkedIn

🍪 A lot of video clips, like done this year!

So, please subscribe and consider supporting me in this endeavor :)

Yours faithfully,

Adrian

Related reads about this topic:

Article Thumbnail Credits: Canva Pro

1. https://minimumcd.org/minimumcd/