If Your Tech Is Broken, Look At Your Culture First
20 March 2017 |
Chris Wintle | About a 3 minute read
Across my career, I have worked with (and helped to create – I am no saint) a wealth of broken technology. Poorly scaling websites, untested short-term hacks (which of course, never get replaced). I’ve worked with (and within) teams full of smart, engaged people whose hands are constantly tied behind their backs by the fact they have to work on unstable, non-maintainable codebases.
Every time someone finally makes the decision to ‘fix’ the problem with any of these codebases, the answer is invariable to re-platform the whole thing. Use a different language. Throw a bunch of cloud infrastructure at it. Start using microservices. Implement everything using TDD. You know the deal.
The interesting part is that this has almost never worked. The team always ends up in the same position, a few years down the line. Sure, the site might be more performant due to new, improved languages and frameworks, but we’ve probably also added a load of new problems as well.
So what’s happening?
When we see this pattern, we need to look elsewhere for the solution. The definition of insanity is said to be repeating the same actions, but expecting different results, but we (as software engineers, architects, tech leads, CTO’s) often do exactly this.
When faced with this problem these days, my first recommendation is always to have a look at your culture and ways of working. One of my go-to sayings is that ‘A good culture will drive good tech. Good tech won’t necessarily drive good culture’.
So step back from the nuts and bolts of the problems you’re facing, and take a good look at how you and your team(s) work together. Ask a load of questions:
- Do we focus enough on learning and development?
- Do we focus on high quality software over speed of delivery?
- Do we focus enough on tech debt?
- Do we actually keep track of it?
- Do we make enough time to do anything about it?
- Are our delivery teams empowered to make their own decisions about how to deliver our product(s)?
- Do we foster a culture of transparency and openness?
- Why are we using this Development methodology?
- So, if we’re using Scrum/Kanban/whatever – why? What’s the actual benefit?
- Does everyone understand the ins and outs?
- Does everyone think this is the best way of doing things?
- Do our teams have all the (right) tools they need to deliver?
- Do we collect meaningful metrics about how we work?
- And do we act on this data?
Naturally, this list of questions can go on and on (and on). The important part is the overall idea that we should be analysing how we work and trying to constantly improve it (before we improve our tech).
If we can’t properly answer any of the questions we use to challenge ourselves here, we have a problem. That problem is going to undermine any work we do going forward. The foundation of the house will be shaky.
Once we’re happy with our culture, and we’re confident in how we work together – then we are empowered to make sensible, forward-thinking technical decisions collectively. The rest will then fall into place much more easily.Read More From This Author
Tech Lead (Reading)
Bring your expert tech knowledge to the table to influence the direction of projects, whilst coaching and your team through engineering best practices.I'm Interested
DevOps Lead (Reading)
Bring your delivery expertise to the table, leading the pack as ambassador on operational requirements, influencing and continuous development.I'm Interested
Programme Lead (Edinburgh)
Bring your expert project knowledge to the table to own delivery of all our initiatives being delivered out of our Delivery Engine.I'm Interested