6 engineering organisation anti-patterns

Building and running an effective engineering organisation is not an easy task. In fact, it's very very hard. It's easy to evolve into an organisational structure and for the process to be iterative but, hands down, it's the most important part of any effective tech business. Over the years I've realised that it is the difference between top engineering leadership and poor engineering leadership. The result of which is the engagement and productivity of talented engineers and equally important, the ability to attract talent. Good engineers care about this stuff. They want to be effective.

I've made a lot of mistakes in my career and continue to do so. Here is a list of things not to do, in my experience.

  1. Teams not owning their deployments - A deployment (or release) team is symptomatic of an evolution. You get to a point where deployments are complex and arduous, it takes engineering time away from actual engineering. The focus then becomes on moving the responsibility out of the team. The problem with this is that the team still knows the most about their software. About what changes were made and the impact of the release. The release team simply becomes a proxy and another wall in the value map.
  2. Bugs being your yard stick for quality - Granted, software quality is not easy to measure. But it's often a red herring for more deeper problems. There has to be a holistic approach to improving quality. Addressing cycle time, batch sizes, QA processes and metrics that give us insight into our software are far more important. Focus on enabling engineers, not restricting them. A more effective measure is mean-time to response (MTTR). If one thing is a certainty in software development, it's that bugs will happen, always. Focussing on putting systems in place so ensure they are caught early and fixed/deployed quickly is a much better use of time than tracking bugs and persecuting teams.
  3. Not focussing on DX (developer experience) - I love this term, which I actually stole from my friend Steve Higgs. Good engineers want to ship software without friction. They should be able to be completely self-sufficient in doing so. That means spinning up infrastructure (automated of course), setting up a deployment pipeline (which hopefully is already in place), building software and shipping it. The right tools and platform should be the foundations for them to move fast.
  4. "Agile" by enforcement - Don't get me wrong. Exposure to Agile or any other methodology is fine. But Agile is not a panacea. It will not fix underlying issues. Equally the focus should be on BEING AGILE rather than DOING AGILE. Standups, retrospectives, definitions of ready/done, are all good things, but they won't make you any quicker or agile if it still takes 3 months to deploy your software.
  5. Horizontal teams - Teams should be built around ownership. They should own the whole vertical of their domain or product. This allows them to know the product inside out and support their systems. The worst culprits here are external bug fixing teams or teams aligned to countries. The team that owns and develops the product know most about the impact of writing code. When external teams attempt to fix bugs they don't have the context and insight and spend time fixing the symptoms, not always addressing the cause.
  6. Building process in lieu of trust - Developers hate process because most of the time it's waste. Managers like process because there is an illusion of quality control as process increases. The worst thing a manager can do is to not review and map out processes and calculate the cost of each step. A good way to do this is using Value Stream Maps. We can map out processes and visualise the cost of a process and the transition between processes to identify waste.
    Value Stream Map Most of the time processes can be drastically reduced with automation. A good example here is the typical approval process in deploying software. Approval by hierarchy is a common mistake. Trust and train teams to own their process and continually assess quality within the team. They will make mistakes but good leadership allows for that and encourages a mindset of continuous improvement.

Author

Ryan Tomlinson

Director of Engineering, hobby photographer and tech blogger