Refactoring Development, Part Two: Are You the Problem?

Refactoring Development, Part Two: Are You the Problem? 

20 February 2024

Kilian Niemegeerts

Overcoming Non-Technical Roadblocks in Your Development Process

In modern development processes, there are plenty of elements to consider, leading to just as many potential bottlenecks. We often see our customers run into the same problems, so we decided to write a two-part blog on how to refactor those roadblocks.

In the first part, we talked about the technical roadblocks that can slow down the development process, including testing, security, developer tooling, and technical debt. However, it’s not always about technology. In this second part, we will shift our focus to less obvious aspects that can also affect the development process.

Corporate Culture

The corporate culture of an organisation can have a significant impact on the development process. For example, a culture that values speed and short-term results over quality and long-term sustainability can lead to technical debt and other roadblocks. On the other hand, a company that values teamwork and learning will naturally have a more effective and sustainable development process.

Since the culture of a company is so deeply ingrained, it’s far from easy to change. As Kilian explains, it’s all about introducing a new way of thinking:

"One way to encourage innovation is through chaos engineering, where you deliberately introdue failures into your system to test its resilience and see where it can be improved. If you embrace the possibility of failure and learn from it, you can prepare your systems to be more resilient when push comes to shove.”
Kilian Niemegeerts

In the same vein, a corporate culture can become a roadblock if it discourages innovation and change. As contradictory as it seems, sometimes you’ll just have to give your engineers carte blanche, because it can be cheaper to start from scratch than to break up an existing monolith into smaller services. We talked a lot about technical debt in the last part already, so we won’t go into detail here.

“It’s always good to keep the development paradox in mind: the more time you spend building new stuff, the less time you have to build new stuff.”

Finally, if the organisation is structured in such a way that it creates “ivory towers” where different teams and departments barely talk to each other, it can also hurt communication and collaboration. This can be especially bad when it comes to security, as we discussed in the first part of this blog series.

Business Users

“Your customers shouldn’t be a problem in your development process, and if you think they are, the problem might be you.”

What is possible, however, is internal users from the business causing a roadblock. This largely depends on their level of involvement. As a manager, you need to make sure that their needs have been met to make the process as effective as possible. Not involving them enough may lead to delays and extra work if all their requirements haven’t been met, while involving them too much can also lead to complications.

Business users and other stakeholders can also create roadblocks if they are constantly changing requirements or scope, set unrealistic deadlines, or don’t provide enough budget. This can lead developers to cut corners, causing technical debt to increase.

Effective communication and teamwork between everyone are crucial, but this requires having the same objectives. Having different KPIs for your operations and development team, like uptime percentage and number of delivered features, can lead to counter-productive conflicts between departments.

In some cases, other stakeholders can also create roadblocks. For example, if the marketing department launches a viral campaign without telling the operations department, it can lead to a surge in demand that the system is not prepared to handle, causing the entire business to grind to a halt.

Management Styles (You)

That’s right: you. It can be hard to see that you’re the problem, but it’s important for you to be open to innovative ideas and willing to change. As a team lead, technical architect or manager, the way you handle your team has a significant impact on the development process.

A top-down management style that focuses on control and hierarchy can stifle innovation and creativity, causing delays and inefficiencies. If you invest in a more collaborative and empowering management style, you can create a culture of experimentation and continuous improvement.

As we mentioned above, you can also indirectly cause problems through a culture that discourages innovation. Of course, this is easier said than done. Innovation is a necessary process, but it needs to be balanced against important business concerns like continuity and maintainability.

If you find it hard to find the right balance, it can help to have an external technical partner by your side who can help you implement innovation without causing continuous disruption to your critical processes.

"We could list a hundred different roadblocks, but at some point, you should at least consider that you are part of the problem. If you want to grow, you may need to face some harsh truths."
Kilian Niemegeerts

Conclusion

As a (tech) lead, it’s your responsibility to create an environment that promotes innovation and creativity. You’ll have to address the corporate culture, deal with the demands of business users, and adapt your management style through reflection.

This means being open to new ideas, encouraging experimentation, and providing the resources and support your team needs to succeed. By doing so, you can help overcome the roadblocks in your development process and drive your organisation towards success.

Looking for an expert DevOps partner that can help you overcome both technical and non-technical roadblocks in your development process? Let’s talk!

Related posts
No Comments

Sorry, the comment form is closed at this time.