Building up : Looping back

Building a styleguide, a set of guide lines, establishing ways to monitor and know how the product runs, automating what can be, hosting and running the product, all these are key elements to build a technical culture within a technical company.

It's not a one day journey, usually it can take months for this to happen and be established. It's not impossible either and while some things can be done in parallel it can start very small with a set of styleguides and guiding lines. Those will help tremendously to create foundations for the next steps while giving more time and capacity to the team to work.

Once that is started the team will start picking it up from there, especially if there are senior people and higher up supporting and pushing for a solid technical approach based on general good practices, an aim for quality and stability in production.

Give it time, give time

It will take some time to start to be apparent, especially if there is a big amount of technical debt. So give it time, and give time to the people in the team to figure out their way, and get into a new rhythm. It might be needed to say it several times that it's ok to do quality work, to follow the styleguides, to split changes in smaller parts, to do code review and take time to discuss the code, and so on.

It's rare to see teams and projects where quality is the norm. Often teams are told to just move and not to worry too much about quality, technical debt, ... At some point this has a cost, a terrible one both in terms of stability of the product but also in terms of team's morale and talent retention.

The truth, like in any other work field, is that quality takes time, that it does matter to prepare your work, to maintain your tools, to clean up your work area regularly and to leave a clean result. It matters. And it's not opposed to getting work done either. It's not opposed to ship features.

Managing expectations

As often, again, as pretty much any other trade, we need to manage expectations of people we work with and work for. Clear, honest communication pays a lot better than throwing smoke screens and over promising.

It's sometimes said that the role of SRE and devops teams is to keep the services running, as close to the 99,99999% bar as possible. It's not to deliver a feature at that specific date to make people happy.

I grew up in a culture where people were expected to match a specific delivery date for any project. In general, a client or leader that decide on such a delivery date should have a rough idea if that's doable or not. A teacher is not going to ask you to write a 200 pages essay on Alexander the great conquests for the next day.

Yet in many companies the project lead will often decide of the date without really looking at the feasibility. This is done too often, and is pretty crazy.

In response to this, agile methodologies (or things similar) give the client and the team ways around this requirement to be able to get value quickly and add up value on top regularly while still adjusting to change.

This is how to manage expectations : communication, collaboration.

Fitting all together

This also applies within the team itself. The making and use of a styleguide, of guidelines should also follow the same principle. The making and use of automation, of the hosting platform should also follow the same principles.

This can be done by using regular technical and less technical retrospectives with all team members. These will give the opportunity to see how things are going, if the styleguide, guidelines need to be changed in any way, if the way some work could have been prepared and done differently and so on.

There should also be regular retrospectives on performance and incidents. These will give the opportunity to give the team a bigger picture as to how the code changes are affecting the user experience. These will also feed the list of tasks to do if performance is going worse in parts of the product or if there are too many incidents of the same kind happening.

Slowly all this will establish a rhythm to work with for the team members. The work will happen, regular discussions will happen to review how work is happening, the way the work is done will be altered consequently and the loop will continue.

Fancy talking more on this topic ? Contact me to discuss how I can help your team establish or refresh exception and log handling in your product or an incident management strategy.