Be careful what expectations your team hears from you

I will often say that “you will get what you manage to” I think this is my version of Peter Drucker’s “what gets measured gets managed,” and since his quote is somewhat contentious, I will explain what I mean by mine;
In my experience, people and teams will work to produce the results that they are managed to. In other words, if your manager/leadership focuses on the number of lines of code you write (i sincerely hope not!), then your team will focus on producing more lines of code. If your manager/leadership focuses on meeting deadlines, your team will work to meet the deadlines.

We all have deadlines, so this may not seem like a bad thing. But it can be if you are only focused on making the deadline, as this often leads to making choices or decisions that will help meet the deadline but will compromise other things like quality, maintainability, performance, etc.

A warning for managers and leaders, be very careful what you choose to manage your teams to and be aware of what your teams perceive you care about most. What do your people hear from you most frequently? If all they understand you talk about or worry about is deadlines, then this is what they will believe you care about most and will try to ‘solve that problem for you,’ sometimes by cutting corners or making compromises to meet it.

I have heard so many managers and leaders say that quality is the most important thing. It is priority number 1, only to have those very same managers and leaders continually asking the team when we will be done and why a feature is not ready yet. They do not ask how well we developed the feature or how we assessed the quality.

People and teams will also develop habits and become habituated to working a certain way and making individual decisions; these habits and working patterns can then be hard to change.

An analogy for this might be how you formed certain habits based on how your parents ‘managed’ you as children. For example, if your parents insisted you clean and put away all the dishes and cookware after a family meal and make sure the kitchen and dining room were neat and tidy. Then, you have probably formed that habit and still do that today as an adult. And you may be uncomfortable if you are in a situation where dishes are left in the sink or on the dining table, as this does not feel ‘right’ to you.

Translating this into the workplace; You will probably be uncomfortable with technical debt. You may prefer to clean up after you have finished some work. Perhaps by adding tests, making sure the build pipeline is green after you merge your code. You may also update the operations docs and playbooks to ensure anyone on-call knows how to spot issues in the new code you delivered – making sure that there is no metaphorical food left rotting and generating smells.

However, if it was normal for you to leave dirty dishes on the table or in the sink, or if you formed this habit once you were no longer being managed to clean up after a meal. Then you will be used to not tidying up after yourself, or others make a mess and will be more comfortable with things being untidy, undone, not clean, etc.

Translating this into the workplace; You will probably be comfortable with technical debt. You will prefer to move onto the next fun task after you have finished some work, perhaps signing off or leaving the office after you merge your code, not checking or caring if the build is successful and if the pipeline is green with your changes. You will put off or expect someone else to run tests, tell you if anything was wrong, and forget to update the operational docs and playbooks. Metaphorically speaking, leaving some uneaten fish to rot and generate smells.

So, as managers/leaders and teammates, we need to hold each other accountable and manage the expectations that avoid smells and encourage good code hygiene. Ensure that all code is reviewed, delivered with great tests (don’t just tick a box that there are tests, review and evaluate them), that the build pipeline stays green, that system tests continue to run without failure or regression. That if issues are found, they are dealt with quickly. That code and systems are easy to maintain and quick to diagnose so that operational costs are low and customer issues and incident interrupts are very infrequent.

Take the time to change, and start to build good habits today!