Every so often I get asked the question of modernization and standardization. Especially from passionate engineers who just joined new teams and want to make a true meaningful change. Here’s how the scenario goes:

I just joined this new team, and it doesn’t seem that the systems they’re working on follows any guidelines in terms of standardization. There are no tests, clean architecture or any resemblance to a meaningful documentation that can help me understand how the system works.

Here’s another scenario:

There used to be a very smart engineer who built most of this system through the night over the years, and now he left (or doesn’t have time) and we are scrambling to understand how the system works. All we have is just tribal knowledge about how things used to work and that’s all.

When you run into situations like these you have to first realize that you’ve entered a Chaos Zone. Chaos zones are engineering systems, teams and cultures that don’t proactively, intentionally or systematically foster and advocate for best practices and engineering standards. There could be so many reasons for that. Sometimes it’s just laziness, doing the right thing takes consistent learning and extra effort to make sure things work now but also in the foreseeable future.

Sometimes it’s ignorance. Engineers who stopped investing in themselves after they got the job and now, they try to reinvent the wheel or come up with chaotic solutions because it gets the job done and there are no pairs to work with to review their ideas with.

But more importantly, Chaos Zones are created because of engineers who know the right thing to do, but they’re scared of their business or leadership to speak up. They care more about themselves and their next promotion, so they shut their mouths and do whatever they’re told in the worst possible way because it’s the way that makes the business happy.

This article is a step-by-step strategy for those engineers who still want to do things right and truly extract fulfillment out of what they do on daily basis.

Let’s get first things first. You are not wrong to aim for higher quality in the systems you build, the cultures you work within and the teams you work with. You may feel this way because everyone else is doing the opposite of that, but in reality, you are absolutely doing the right thing. Essentially you didn’t sell out. You didn’t trade your integrity for money and therefore as someone who’s been around these corners for over a quarter of a century, I am here to tell you: you are just fine.

Now, let’s talk about modern strategies to solve Chaos Zones.

Your actions will rely heavily on three main things.

• Your position and power within the organization or the team you are working with.
• Your communication skills/social credit
• Your knowledge

In our world today, it’s not enough that you know the truth. It’s not enough that you know what’s right and wrong. You must have the power to enforce it and the skillset to deliver it. But more importantly you must have the knowledge to support it!

These three skillsets, power, knowledge and communication are the overall skillsets that every engineer out there must have. It’s not enough that you know modern patterns in systems design. And it’s not enough that you know how to talk to people. You need to have the power to change and authority to drive that change.

Let’s talk about these in detail:

Power/Position

If you are joining a new team as a lead or a manager, then a big part of the mission is done. You are in control of making the decisions on behalf of your team and you are ready to take the responsibility for the outcomes of these decisions.

But while organizations might give you the powers as a lead or a manager to make these decisions, you must also recognize and understand that you must instill that power and authority within your team. This comes with sincerity, trust and authenticity and nothing more.

But what should you do if you are not a lead? What if you don’t have the organizational power to make such decisions on behalf of a team?

In this case you must find allies. Allies at the leadership and the team levels. You must rely on knowledge and communication to be able to convey the right message. And while you personally might not have the power to make the change you aim for; you allies will and they will support you to get where you want to go with the organization.

If you don’t have power nor allies and everything is against you – you have these options:

Brute Force

Continue to modernize wherever you can in every bug you fix or every feature you build. This is the toughest option because you will get heat for not “playing along” and “overengineering things”. So, you shall be ready to take on that kind of criticism.

This option will land you in hot waters, but you will feel good about your work anyway. This is the option I personally recommend for the strong-hearted. For those who fight for their dignity and integrity. For those who are unwilling to sellout, change their faith or give up.

Those are very few.

You may eventually get fired, and that’s okay. Because at the end of the day you can show up with a good track record of writing clean standardized code for your next job. And there will always be another endeavor to take. Don’t doubt or underestimate yourself. It’s a badge of honor, not something to be ashamed of.

Preach

Keep voicing and bringing up the best practices until someone decides to support you. And even if things don’t seem like they are going in your favor. Continue to preach. Continue to advocate and invite others to a better way.

Setup meetings for tech-leveling and take advantage of every single meeting you are a part of to bring up the in these meetings. People will get fed up with your ideas – don’t let that stop you. Keep going anyway.

Preaching Requires strong communication and knowledge – you must continue to invest in these so you can fend off arguments against your proposals and share knowledge that can’t be refuted.

Walk Away

This one is the weakest option, but it certainly is a better option than staying around in a Chaos Zone and doing what you don’t like or believe in.

Running away is a good option when you don’t have enough knowledge or communication skills to communicate your message. It’s also the best option for your mental and spiritual health.

Running away can make a large impact if it’s made in big numbers in an organization or a team. But it can be just as impactful if the person walking away has their importance and weight in the organization. Especially “saviors” who know the ins and outs of certain domain and no one else even cares to ask.

Walking away could send the strongest message if the time and place are correct. So make your decision wisely.

Knowledge

It doesn’t really matter if you have power if you don’t have knowledge. In fact, ignorant leaders are the main breeders of Chaos. In order to make sure you don’t end up being one of those leaders, you must have the knowledge.

Knowledge comes in three different ways:

• Reading: this includes books, videos or engaging in discussions on social media and with others.
• Practicing: trial and error is one of the ways engineers used to learn before the internet.
• Pairing: Learning by pairing with others is one of the greatest ways you can gain knowledge.

Knowledge should be a daily ritual for you. But unguided purposeless knowledge can be quite dull and boring. Knowledge that you can incorporate in your daily work and engage a community of engineers in evolving it is much more exciting and more likely to help you avoid misunderstandings.

Any effort out there for modernization or standardization without knowledge is destined to fail. Especially in bigger organizations and teams where you’ll likely be questioned on every single bit in your proposals.

You may hear things like: “New guy doesn’t understand” or even to your face like: “It’s more complex than it seems” and so many other things people would say to lower your spirit and kill your ambitions. Don’t listen to any of that – 90% of the innovations in tech that we have today were done by “the new guy” – it’s the new guy that brings new ideas not those who’ve been around for decades doing the exact same thing and not investing in their growth.

Knowledge without practicing is destined to be forgotten. Knowledge without engaging others in discussions is destined to be misunderstood. You must combine all three aspects and vice versa to ensure your knowledge is rooted in experience (yours and others) in addition to true engagement and discussions and exploration.

What if you don’t have enough knowledge to bring others to modernization?

The least you could do is to start tech-leveling sessions within your team or organization. Bi-Weekly or at least one a month. Go learn something and practice preaching it to others. It’ll help you evolve your communication skills while you’re building strong knowledge for your next proposal for the team.

Find those who are as much passionate about standardization as you and make them mentors of yours. Find time to sync up with them and learn the latest and greatest. Don’t ever expect your day job to teach you what you need to evolve as an engineer. Take control of your own evolution and seek knowledge then share it and learn as you go.

Communication

A knowledgeable leader who can’t communicate is destined to fail in his mission. No matter how knowledgeable and powerful he may be. Communication is crucial aspect of being able to push for modernization in any engineering team.

Communication isn’t just about being able to talk others into your ideas. But rather being able to listen to them and incorporate their point of view into your overall vision.

Engineers must have the emotional intelligence not to get angered or triggered because of a certain insensitive or distasteful comment during an engagement with an engineering group. Especially those who are new in a role, you may hear a lot of things like: “Oh, we’ve tried that! It doesn’t work!” or things like: “We don’t see the value of this”. And you will hear things like, resourcing, and timing and planning and so many other things are completely far, far away from what’s being discussed.

Communication is all about maintaining composure and being able to get commitments, agreements or support from as may team members as possible. Don’t underestimate anyone. Jr. engineers who believe in your mission are more likely to influence their leaders and sway them towards the right direction.

Be warned not to treat everyone the same. Irregardless of their position, experience or any other aspect. Every single individual is an important ally in your journey in changing things for the better. And when you try to sell your ideas to others, you must show them how beneficial it is for them before talking about the organization or the company or anyone else.

Now, let’s say you have all these three, power, knowledge and communication – what’s the next step? What are the strategies engineers could follow to modernize any system anywhere?

There are three methodologies that you can follow to modernize any system in any organization depends on the type of support you have. These methodologies are:

• Starting Over
• New Code
• Bits & Pieces

Let’s talk about those in the following sections.

Starting Over

This is the most powerful option as a strategy. You declare a code freeze on the existing legacy system. You alternate team members or hire vendors to keep the chaotic legacy system running, then you redirect your team’s focus fully on building a brand-new system from scratch.

This strategy mandates few things:

• Full knowledge of the domain – you cannot use this strategy if you don’t understand what needs to be done.
• Find customers who are willing to attend your bi-weekly demos to show progress and get feedback.
• Strong knowledge in standardization and modernization.

From the business side, someone needs to be able to support you with funds to make it happen. Usually starting over can cause a massive panic in bigger complex systems as it becomes harder for the business folk to understand the need to rewrite an entire system that’s “already working”.

You may hear some chaotic quotes such as “If it works don’t fix it” and things like: “Let’s not reinvent the wheel” and all that. Ignore all of these statements and keep going with your standardization journey.

When you decide to start over, you must ensure that your team is willing to undergo a massive rewrite and a huge effort with little business visible progress across long, long terms. That’s the reason why the word “modernization” could cause quite a stir amongst some organizations due to the massive cost and effort it implies.

New Code

This here is the second strategy. It’s a strategy that some engineers may take when they can’t for whatever reason do a complete rewrite of the entire chaotic system.

This approach is about modernizing and componentizing every new feature ask. For instance, if the ask is to add a pop up message for customers to ensure that they are willing to take an action – engineers would take that opportunity to refactor and modernize the entire component for messaging.

These are smart engineers. Because the factor the cost of refactoring into whatever they are building whether it’s a bug fix or a new feature ask. This type of engineers don’t really mind being called “slow” or “overengineering” by their peers when they modernize every component. Because they know eventually everything will become modernized or standardized to the point where the entire system is fully in good shape.

The problem with this approach is two things:

• It takes a very long time to be able to modernize a legacy chaotic system. It’s like trying to turn a Mazda into a Lamborghini. It can be just cheaper to get a brand-new Lamborghini instead. Usually, engineers who follow that approach never get to truly see the whole system standardized – then someone else comes and adds more to the chaos.
• You won’t always get the opportunity to touch every single aspect of the system. Therefore you will need to find a reason to explain why you refactored a component that no one really asked for.

These are risks engineers must understand when following that strategy. Usually shifting gears from a monolithic to a microservices architecture could be a good excuse to break pieces and modernize as you fulfill customer asks. But then there’s a good chance the chaotic system is already build as microservices – this is where things get quite difficult.

Bits & Pieces

This option is the weakest of them all. But it still is a valid option. Taking small pieces of the system and modernizing them with or without feature ask. Especially with systems that are in maintenance mode and there are no likely new features to be received for a while.

Modernizing bits and pieces of the system will help you understand the domain as you go – instead of trying to learn everything before building any new features.

There are teams and organizations that enforce a “design discussion” or “architecture planning” before making any significant changes in the system. These meetings could be quite daunting and demoralizing if not regulated and controlled. These meetings increase the costs of any feature ask to the point where both engineers and the business wish they never happen.

The bits and pieces strategy can be a good one for new engineers coming into the tech world recently and they don’t want to wage full war on chaos not just yet. They want to live within the chaos zone while building a good understanding and foundation on both the technical and domain realm. And also build social credit to find allies in the long term as they are willing to help everyone and pair with everyone to understand the system.

These strategies above are the ones I have tried in the past 22 years of being an engineer. They didn’t work all the time – sometimes there were situations where entire projects got shutdown. But regardless of the outcome, the one most important aspect in these projects is that engineers teams whom I had the pleasure to work with have always appreciated the team culture standardization brings and their ability to truly feel and work as software engineers the way they imagined before they joined the tech world.

These engineers become leaders in the future with clear vision as to how to build great modernized systems following standardization and innovation. But more importantly they become an available ally for the next endeavor into the tech world whether in the open-source space or within corporate walls.

Engineers who push for standardization are the true hope of innovation in the tech industry. They never settle for mundane tasks and they are never happy with how far they’ve achieved in the their craft. They go the extra mile to ensure what they build is truly solid and reliable but also ensure to bring everyone onboard on their vision to bring true change.

Standard engineers are the reason the tech industry is still attractive to others who are exploring that world and willing to take the jump to become engineers to, because these engineers show true joy and happiness into what they do. Their dedication to quality and soul is what’s going to give birth to the next evolutionary step for humanity.