Throughout my career I’ve seen the same thing happen over and over: whole teams would be trained or managed by a certain type of person, only when they leave the company their legacy lives on, often times for the worse.
Here is an example. A small company grew to a point where they needed to start standardizing their work processes and even get an architect to help out and manage the knowledge gap of the various teams. This is wonderful. Nothing better than to see a small company grow. So an architect was hired, let’s call him Bob (not his real name), and he set forth to standardize some approaches that were needed at the time. Everything was grand.
The teams managed to do their work, given the time constraints and have a way of working that was manageable for the project sizes the company was doing. Happy days!
The company and the team size grew, as well as the size of the projects being built, and due to the tremendous work pressures that were placed on Bob, he decided that that wasn’t sustainable and decided to leave the company. A sad day for the company, indeed.
But this is where the trouble started. The team grew even more, and while the company was looking for a replacement the team didn’t know any better but to follow the path that Bob has laid out. In other words, Bob gave the team a hammer, and now all they see is nails. Don’t get me wrong, present them with a problem and they can hammer a solution together (pun intended) but now their solutions don’t scale well.
So after a few months a new architect got hired, let’s call him Charlie (not his real name). Charlie identified the problem that the teams had. And after a month or two of looking into projects he set forth to change things. Management gave him all the support he needed but a strange thing happened – the teams were reluctant to change. Teams would go rogue and would disregard his recommendations and would default to Bob’s way of working.
Charlie went to great lengths to try and help the team transition to the new way of working but ultimately they wouldn’t listen. They thought they knew better and they kept to their dogma as set forth by Bob. Fair enough, there were projects that were stuck in a certain architecture, and changing them would require an unrealistic amount of effort that couldn’t be commercially justified.
There are three problems here that Charlie faced: the company grew relatively fast, the size of the projects grew even faster and he was stuck in a company whose employees were blinded by dogma and nobody challenged it. Now, to be fair, Charlie couldn’t ask the company to stop growing, that’s just silly and he couldn’t change the size of the projects as they were set by the clients. So he attempted to change the team, by trying his darned best to open their eyes to new technologies, techniques and methods. He brought in a ton of books, started working with people he figured would have enough pull to start changing the mentality but even there he encountered resistance.
Everyone had their excuse: family, other obligations, not enough time etc. Everyone had a reason why not to change and nobody had a reason to change. This is a very dangerous position to be in. Especially for the company as the core team can’t scale well and they become the choke point for any future growth.
The company is now brought into a difficult position: they can’t let go the people that won’t change because they posses a lot of project related knowledge that is valuable to the company and it’s hard to find skilled people to replace the core team. Those employees still produce decent amount of code and the company doesn’t have any realistic justification to let them go. On top of that new project work is coming in and they have to delegate it to those people in order to hit their financial goals for the quarter / year.
Essentially, it’s like the employees have taken the company hostage. The company has to keep hiring more and more people, that’s just the natural part of its growth, but they can’t scale well because the employees refuse to change.
Personally, I have a problem with dogma. I challenge the status quo every chance I get. This isn’t because I’m some sort of rebel and I want to disturb the natural order of things. I just want to shake up everything to see if the model that was set forth is still fit for purpose. A company, at different stages of growth requires different ways of approaching things and I just want to make sure we’re not stuck because of some dogma.
As an example, in a startup, in it’s early stages, everyone is responsible for almost everything. There aren’t any standardized processes, there might be barely any automation and the whole point of that is that you spend as much time hacking away at a MVP and worry about everything else later, when you start getting customers.
A year or two down the line in that startup, when there is some cash flow coming in and the core team has been established and you have something out there, you then start thinking about automation and working a bit smarter. Five or so years later when everything has grown and you now have enough presence on the market and are no longer considered a startup, you then work towards standardizing some practices and workflows.
There are several stages companies have that fall under the growth phase, from the seedling phase to the maturity phase. And then there is the decline phase. One way you know if you are about to go bust if there is a serious increase of bureaucracy. And I’ve seen so many companies head towards there, even during their startup phase, thinking that’s how you know you are maturing, when in fact it’s how you know the company is actually close to dying a slow and painful death.
So what’s the lesson here? What should you take away from this article?
Well if there is anything to take away it’s to challenge the status quo. Ask yourself, is what we’re doing what is fit for purpose? Is there something out there that can help us scale better? Are we holding onto some dogma because we’re afraid to let go?
Are we standardizing things to make us look mature or are we experiencing so much chaos in how things are done that we need a standard to help us keep our sanity? Is the documentation we’re writing actually going to get used by someone or do we need to find different activities to fill in any downtime?
Also, just asking “why” can oftentimes lead to interesting answers, often times leading to very stupid reasons like: well that’s how we’ve always done it. Asking why is one of the most powerful weapons we have and we don’t seem to be using it enough. We just keep accepting things as they come and never question them. This needs to change if we are to grow, both as people and as companies.