Engineering culture - The key to successful digital delivery

The idea that all businesses are now technology businesses is not a new idea. Whether they know it or not, digital needs to be at their core. In retail, online commerce is the new norm and Artificial Intelligence (AI) is now a part of many types of organisations helping to optimise business processes. If this is indeed true, engineering culture is now more important than ever before and could make or break a business.

At Red Badger, we think a lot about people. Not only our employees but the employees of our clients and ultimately their customers. Fostering a good culture, we feel, is key to digital success. Without a people focus, a business could end up doing the wrong thing in the wrong way which can result in huge amounts of waste, high staff turnover and the potential for competitors to take the lead.

Through our experience working with many clients in different sectors, as well as managing our own engineering workforce, we have highlighted a few of the common problems we see time and time again.

Is autonomy a problem? - Either too much, or none at all

Autonomy within an engineering team that is aligned to the product vision will enable them to add value at speed, however, too much autonomy within a junior or less experienced team can lead to chaos. Without focus from all disciplines in a cross-functional team (normally made up of a Product Owner, a Delivery Lead, Engineers, QA Engineers, UX and UI Designers), engineers are likely to focus on non-user facing tasks. It can also lead to a scatter-gun approach to attacking a backlog which ultimately adds little to no value.

The freedom to use the right technology and tooling to solve a problem helps with quality control and speed to production. Autonomy of product ownership is also key. Product Owners need to be empowered to work with the team to define stories, make tactical decisions and get value in front of end users as quickly as possible.

Autonomy, however, should be seen as a relative and not an absolute. If a business is made up of many teams all pulling in a different direction, it could find itself trying to maintain code bases made up of tens of programming languages with costs escalating from the wide gamut of third-party services being used. On the other hand, total dictatorship from up the ivory tower can create so much constraint that teams are unable to move. Mandating technology choices that are not fit for purpose rather than listening and allowing for some diversification will mean that teams are ineffective and waste hours, days or even months of time trying to fix issues or finding workarounds to get their job done.

It is frustrating to see teams who are mandated to use, for example, a build pipeline tool which is not fit for purpose waste days or even weeks of effort trying to fix issues with unstable and temperamental tooling. This is time which could have been used on providing user value. On other occasions, teams get so frustrated with the tools that they might comment out parts of the pipeline so that they can get their builds to pass but by doing so are removing the quality control checks that are put in place to stop erroneous code getting into an environment. This then can have the knock-on effect of breaking shared environments which then leads to even more waste whilst teams have to get together and debug the issue rather than delivery backlog items.

Teams who find they are constrained in this way will likely be unmotivated. Steve Jobs was spot on when he said: “It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.” No one likes being told what to do and moreover not being listened to. Providing a forum for engineers to express their frustrations and then acting upon their recommendations will empower them and allow them to do good work. After all, engineers are smart people and their thoughts and opinions should be taken into consideration when thinking about technology choices.

Silos are stifling projects

Engineering culture is not just about engineers, their happiness and the practices they employ, it is also governed by how other disciplines and parts of the business treat and interact with the engineering team.

The adoption of lean and agile methodologies have led to teams aiming towards real-time and nimble collaboration. When done properly, it is not only the technology department that needs to work this way. This process can only succeed if all aspects of the business get involved and work in this way. The old “throw requirements over the fence and hope for the best” can no longer happen and is now regarded as an outdated and broken approach.

If a business team embarking on a new digital delivery and see their technology department as a cost centre who they are outsourcing to get a job done without getting involved, no one will be happy; the business, the customers or anyone involved in the process. It is key that the business gets involved. Product Owners need to be given the time and empowerment to make decisions and key stakeholders need to make time to visit showcases and go on the journey with the team. Without this commitment from the business large amounts of re-work is inevitable which will result in a frustrated and demotivated team.

The most effective and engaged teams are those that own their delivery from backlog to production. Partitioning them into silos can lead to frustration and massively slow down the delivery user value. Fully cross-functional teams made up of all the key disciplines needed to get stories complete will be able to move quickly and take more ownership of their work. Furthermore, bringing in key stakeholders from the business to work directly with the team and make decisions is key to speedy product delivery.

Physical silos hinder the speed of development so locate teams in the same space allowing them to work through problems in real-time. Encourage conversation over digital communications, pairing and cross-discipline collaboration. It is amazing how moving a team together can transform a team both culturally and in terms of delivery.

The most effective way to alleviate these pains is to restructure teams, and even the business, to make sure that technology is at the core. If every company is now a technology company then make it so.

New talent isn’t interested

When a business is able to address the above, they are more likely to attract new talent as well as reduce their employee churn. Engineers are likely to look elsewhere if organisations operate with old waterfall methodologies, if they can’t contribute to the product in anything else other than code and if they are siloed off into disempowered teams.

Attracting good talent is now an industry-wide problem. Businesses that are not operating like that new sexy start-up or companies that are known for their product and technical prowess will struggle even more. People want to feel like they are able to contribute and be proud of the work they do so it is important to foster a culture that allows for this.

Conclusion

Moving to autonomous, empowered teams who can own their delivery end-to-end is not an easy change to make and will take time. Striving for continuous delivery is a great way to start this transformation and will give teams ownership and focus. The business will be happy as they are seeing features in the hands of customers quicker, learning from customers more frequently and teams will be able to react to business changes in a truly agile way. Culture is, and forever will be, a hard problem to solve but knowing where to look is a great start.