As an interim-CTO, consultant, coach and advisor I have a chance to work with a lot of companies. Being part of CTO-networks I hear about even more. I got gradually aware of a few dangerous patterns, which I saw repeatedly ever since I started my career. Sometimes, these technical management traps are unavoidable. Sometimes, the mistakes pile on top of each other and create a highly dysfunctional climate in organisations. This in turn causes smart people to struggle in their roles and shifts the path of the organisation away from actually creating value. I picked seven patterns I observed – read on for my reasons why you should be very careful whenever you notice them.
Agile methodologies have been implemented very poorly, internationally. This is true in particular for Germany, where the esoteric wrong-value dogmatism went over the top.
The extreme looks like a team focusing on idealistic discussions about the question if certain aspects are ‘truly agile’ instead of your business problems and delivery.
If you feel everyone is stressed and busy with alignment, small tasks are taking forever, and nobody knows where they should aim to be after the next iteration, milestone, quarter you likely fell into the agile trap.
The worst outcome of falling into the Agile trap is driving your best people to lack motivation and disconnect from the value they (should) create. Side effects include over-engineer everything (you may have heard me rant about the importance of ‘simplifying everything’), lack of productivity and purpose. Last but not least: once fallen into the Agile trap, the organisation is not ‘agile’ at all. Quite the opposite. The environment tends to become very static and inflexible, causing people to be uncomfortable with change and challenges.This makes sense as being stressed, demotivated and overloaded is not a good state of mind to accept additional challenges. The way out of the trap is to treat agile values as a shared baseline. Put the tools agile methodologies provide, into your toolbelt. But also add those that are not ‘agile’ per se, like learning from the old school guys. The bottom line is – do not follow any methodology and do not rely on any framework for its sake. Make sure to think for yourself and to keep the purpose of your company in sight at all times. A healthy people+performance oriented culture is a place in which everyone wants to work, that maintains energy and motivation – a place that truly creates a return on the investment.
I still remember the early days of open space offices. There were some reports about how they boosted productivity and motivation and how they reduced cost. A silver bullet for all industries. Very shortly after those reports, it got scientifically proven that there are severe negative effects of these work environments: increased stress levels, decrease of work quality, increase in sick days, more conflicts at the workplace. These outweigh the initial positive effects in a matter of months.
The interesting part of the story starts here: we bought into the story that had already been disproven. A global adoption of open space offices happened, completely ignoring the knowledge at hand. Sadly, this was not the only time – the same dynamics occur over and over. One of the recent prominent examples: the Spotify model (of organisational structure in engineering).
Spotify released a few slides, later videos, in 2012, describing how they intended to structure their organisation. At that time, the changes were already partly implemented and promised to work. The change consisted in combining a decentralised, vertical organisational structure with many of the aspects of classical line/matrix-style organisations.
I am convinced, when aiming at both, you get none of the benefits of either, but you end up with the pains of both. Indeed, there were reports that it sucked, did not work and that it was partly reverted before even implemented fully. Some claim that this was all about employer branding, which likely is the reason to remain quiet, while everyone else is killing their business in an attempt to copy a bad idea.
I have several more examples. Zalando hiring half of Europe and going all-in on waste and nonsense is also a good company to copy mindlessly if you want to kill your business.
The bottom line is – do your homework, research and understand what you are planning to implement. Big changes are important and they should not be decided on a fad – they should make absolutely and undoubtedly sense for your specific organisational need.
While I am all-in for transparent salaries (without having answers for all the problems involved, let alone the legal concerns), paying people as good as possible, and allowing everyone to grow, I believe this is not a deciding factor. People being engaged and motivated is based on purpose first and foremost. Your people need to want to work towards a goal that is bigger than their ego or paycheck. When you are stuck in attracting talent and cannot figure out why it takes so long to hire, the reason likely is that available talent does not buy into your team or your vision. You likely do not sell yourself well. People are leaving? It is not about their salaries and titles.
Trying to motivate people by raises and career progression is a sure bet to end up in a ‘what’s in it for me’ culture rather than in a culture of shared goals and purpose. Smart and good people do not need you for their career development. They are either happy where they are or already working on the change. Being happy where you are is something we should honor and reward rather than indicating that people need to progress all the time.
Treating people with respect, paying them fair and helping them to grow is something that should result from your culture and values and not a thing you do to attract and retain talent.
I worked with legacy systems most of my career and what I always did, when I joined, was diving in, understanding the system, ensuring test coverage and documentation are sufficient. Took ownership. Worked on improving the system or iteratively replacing parts of it, when it made sense.
This rarely happens today. I repeatedly meet teams that avoid any work on ‘the monolith’ and do not take responsibility for it. Let alone learning from it. What will usually follow is initiatives that take several years in which the teams try to rewrite the system utilising different technologies and fail at the attempt to replace the old system. This ultimately results in a bad situation with the business feeling fooled and the engineering team feeling bad as they do not achieve anything.
Interestingly, most of this has been researched and understood years ago (e.g. https://martinfowler.com/articles/patterns-legacy-displacement/ ). Not that anyone heeded attention. The basic assumption is ‘we know better’ and ‘we are better’ and oh, so different. If you have a well-running business operating on a system that was implemented years or decades ago, which you find unsexy, avoid diving in, understanding the problems it solves and developing a plan to work with the system based on actual requirements for the business. Instead, adopt a solely tech-driven approach of bluntly re-implementing random parts, adding complexity. That is: if you want to kill your business.
Yes, there are use-cases in which those make sense. Chances are likely 1:10000 that you are amongst them, and likely still 1000:1 that adopting them will severely harm your productivity. Writing Java/Spring services with an ORM-Framework and a SQL-Database, potentially enhancing with a bit of Queuing and Caching in between, will bring you pretty far (as in hundreds of millions of users per month for most scenarios). But why should you do that? For the non-technical audience: the old and boring technologies were so far advanced that computers could actually fully understand all kinds of integrations of different parts of your application. Even before assembling the application, while typing the code, the computer would make developers aware of the errors they made. It was possible to have automated and integrated testing of all parts of your application very easily and without added effort. Linking parts of the program was done semi-automatically while typing. This was way too boring for developers – they could focus solely on your business problems without any distractions after they mastered the programming language and framework. That opened some free time, so developers as open-minded and creative as they are, found the microservice-trend. And boy, it was gold. It promised to solve all our problems in a fun way. It scattered functionality across different small applications, which were loosely integrated. Great!
In fact, microservices kill nearly all of the achievements made before. What happens when applications are loosely coupled is computers cannot understand the coupling of functionality any more, and therefore cannot catch our errors, functionalities cannot be linked semi-automatically any more and testability goes down the drain or becomes crazy-complicated and expensive.
If you were not entirely satisfied to have ruined the business, you could go into serverless, which is guaranteed to remove all your measures of automated quality assurance and automated testing, bloat your monitoring until you ignore it – a system no one understands.
It may be that your organisation is very resilient. Ah, those pesky smart and skilled developers and architects, who still occasionally deliver business value despite all your efforts. Then try Event Sourcing (https://martinfowler.com/eaaDev/EventSourcing.html ). Event Sourcing is a very-hard-to-do-right technique, in which you derive state from events. Developers need state everywhere, they will go crazy on this and solve for it differently at different parts of your system or solve it centrally by maintaining state at a central point. In the first scenario, it becomes nearly impossible to understand why a system behaves as it does. In the latter, at least you are applying a complicated architectural pattern to achieve nothing, but overloading developers and keeping them from creating business value.
I coded in Basic, Delphi, C, C++, Assembler, Python, C#, Javascript and Java with Java Enterprise and Spring. After not liking Java/Spring at first, I got very productive with it. Learning the language, the libraries, the ecosystem in and out over the years. I was an expert in Spring at some point. Hyper-productive doing it. I also worked on infrastructure, soldering hardware and coding frontend.
What I am a specialist in, however, is the backend and architecture. I think of this as a funnel. Having a broad set of capabilities, contributing wherever I need to achieve a goal, but being the expert in one field. Utilising experts and letting them work where they are most productive is a good way to actually achieve a lot.
In our quest to ruin the business, I recommend choosing a programming language none of the existing team knows: something fancy, definitely not chosen by availability of senior/expert talent in the market, which would be the only sane metric. Then, motivate everyone to switch stacks. When hiring, do not seek for experts – ask for ‘good engineers’, that you then expect to work their way into the new stack because everyone should be a polyglot. Ideally, require everyone to be ‘full stack’.
If this is not enough to kill your business, leave it to the developers to choose programming languages and frameworks freely. It will not have an immediate effect, but in three years you are guaranteed to have a Tower of Babel disaster and struggle with code nobody understands or takes responsibility for.
If you diligently followed my advice above, chances are you drove six businesses into the ground by now. It is time for a break. The next challenge is easy – refrain from communicating direction and aligning teams. Get some very fuzzy objectives, say “growth” and “scale”. Implement OKRs down to the individual level (this will kill a lot of the productivity and motivation of people as well). Take up some time training in S.M.A.R.T. objectives and the philosophy behind OKRs. Ideally, you do not align the OKRs and formulate everything in a way that leaves plenty of room for interpretation. Sit back and relax. In no time, you will see teams pull in different directions, getting frustrated and building things that are so far off the real business needs that there is absolutely no risk of success. If value happens accidentally anyways? Next cycle is just around the corner.
