14 principles that every CTO must have
I believe that to be a CTO, you also need to be a good programmer, with that I make a list of 13 principles that every CTO must have.
- Management ≠ Leadership
Fortunately, this one is obvious: management is not the same as leadership. You are a leader because your people follow you. And you are a manager because your people work for you. There are managers who are not leaders and leaders who are not in managerial positions.
Management and leadership are not the same thing, but they go hand in hand. So, as my first point suggests, you need to develop both to succeed in your new position.
2. You Aren’t Gonna Need It — YAGNI
It’s simple and self-explanatory — but not everyone follows it. When adding code, make sure it is needed right away. Don’t leave the code suspended because you think it might be useful later.
This applies when refactoring. If you refactor a method / class / file, you shouldn’t hesitate to remove any methods that were left hanging. Even if they were useful in the past — they aren’t anymore.
There may come a day when they will be needed again and you can use the git repository to bring them back from the dead.
3. Leadership as a Member
“They don’t care how much you know until they know how much you care.”
Congratulations! You are now a member of your team. Or, to be more precise, you are now a leader with a member’s heart.
The principles of servant leadership are simple, but most people in leadership positions struggle to give up power. Your job is NOT to be above your people to boss them around, solve technical problems yourself, micromanage them, or exercise command and control. You don’t command but persuade. You put your team ahead of you. And through it all, you act with humility.
You are in this position to help them become better and work harmoniously and productively. Ideally, you become a multiplier, helping your team achieve higher levels of productivity.
4. Don’t Repeat Yourself — DRY
This concept was first formulated in Andy Hunt and Dave Thomas’ book The Pragmatic Programmer: From Journeyman to Master.
The idea revolves around having a single source of truth. After all, what is it?
“In information systems design and theory, the single source of truth (SSOT) is the practice of structuring information models and associated data schema so that each data element is mastered (or edited) in just one place. … SSOT systems provide data that is authentic, relevant and referable. ”
- Wikipedia
Keeping a single source of truth will help to have a stronger and more self-explanatory code base.
Having duplicate code is a waste. You’ll have to stick to the same logic in two places, take the tests in two places, and when one place changes, you’ll have to remember to change the other.
Most of the time, code duplication comes from lack of knowledge of the system. Before coding anything, be pragmatic: take a look. Perhaps the feature has been implemented elsewhere. Perhaps this business logic already exists elsewhere. Reusing code is always a smart choice.
5. Communication
The root cause of most management problems I have witnessed in my career has been communication. It is probably very difficult to become a good leader without being a competent communicator first. This is another area you may need to work on.
Whenever you have the option, choose face-to-face communication. For most of us, the written medium is not the best way to convey all the complexities of our thinking. When communicating, you would like to be able to read the body language of your interlocutor(s) and react accordingly.
While we’re on this topic, here’s a warning: don’t insist that communication flow through you. Let your team talk to other teams, other managers, or even your manager directly. Encourage ideas to flow freely without settling into the “proper channels” for the good of your company.
As a manager, you will learn to recognize critical information and how to handle it. You want this type of information to be fresh. That’s one of the reasons 1-on-1 is a very important tool you need to learn to use.
6. Keep It Simple, Stupid — KISS
This design principle is a design principle observed by the US Navy in 1960. This principle states that simpler systems will work better and more reliably.
You can find many similarities when taking this principle and reinventing the wheel, which takes you back in the 1970s. It was used as a commercial and advertising metaphor.
Applied to software development, it means just that — don’t over-engineer. Sometimes the smartest solution is the easiest. Building efficient, high-performance code with simplicity is beautiful.
One of the most common mistakes these days is trying to use the new tools just because they’re brilliant. Developers shouldn’t be motivated to use the latest technologies just because they’re new — but because they’re right for the job.
7.Transparency
Transparency is the main pillar that sustains the trust and fellowship that a good leader strives to build.
At a higher level, we want a business culture that embraces transparency. We would all like to know how well our company is doing and where we are going. One of the reasons founders and managers are sometimes reluctant to be transparent is the fear of the reaction they think they will receive for bad news. But we are adults and we want to be in control of our careers. We know that life doesn’t always offer good news and that the path to success is rarely straight. We want to feel like we have a confident and competent captain at the wheel, especially during a storm. Furthermore, we learn from these failures by looking back and continually adjusting and improving. Isn’t that one of the best ways to improve what we’re doing?
It’s similar at your team level. Celebrate your victories, but carry the burdens together as a team. If you rigorously inspect and adapt as a team, you’ll make each mini-storm stronger than before.
Also, you don’t lose authority by being transparent. At the very least, you want your people to know that you are not afraid of the challenges life throws at you and that you are able to stand firm. That’s how you earn your team’s trust.
8. Great Initial Design
This software development approach is crucial — and often overlooked. Before jumping into the implementation part, make sure everything is well thought out.
“Often thinking about things in advance saved us from serious developmental headaches later on. … Making this spec change took an hour or two. If we had made this change to the code, it would have added weeks to the schedule. I can’t tell you how strongly I believe in Big Design Up Front, which Extreme Programming’s proponents consider anathema. I’ve always saved time and created better products using BDUF and am proud to use it, no matter what the XP fanatics claim. They are simply wrong on this point and I cannot be any clearer than that. ”
- Joel Spolsky
Many developers feel that they are not making progress if they don’t start coding. This is wrong. By making a specific plan, you are avoiding the possibility of having to start from scratch again.
Sometimes other people need to be involved in a project’s failures. The sooner these conversations happen, the better for everyone.
A very common counterargument is that the cost of fixing problems is less than the time it takes to plan for them. This is certainly not true. The fewer bugs / inconsistencies the user faces, the better their experience will be. You may not get another chance to contact them.
9. Trust Your People
As I mentioned in the Servant Leadership section, you are not here to solve every problem alone. Communicate your vision, communicate the mission, and trust your people to deliver.
For this to work, you need to communicate well so that your team does the right thing. You also need to develop your team’s skills so they do things right.
There is another aspect to this: you need an environment where failure is not seen as the end of all things. At first, it may seem counterintuitive to make your people feel safe if they fail, but how else can you encourage them to be creative and show their full potential? And if they do, failures should be part of the feedback loop and the triggers that make the wheel of continuous improvement spin.
Let them fail, but don’t let them be failures.
10. SOLID
It is the best known software principle. Solid is an acronym for:
Sole Responsibility Principle
Its importance cannot be overstated. Each object, class and method must have a unique responsibility. If your objects/classes/methods are doing too much, you’ll end up with well-known spaghetti code. Here’s an example:
This method looks harmless, but it’s doing a lot:
- saving object in BE
- taking care of UI notification
- some navigation
Another side effect is testing. It is more difficult to test the tangled functionality.
Open-closed principle Software
entities must be open for extension but closed for modification. I mean, we shouldn’t override methods/classes just adding more functionality as we need to.
Inheritance is a good way to do this. In JavaScript, this is mostly done by compositing.
General rule of thumb: If you modify an entity to make it extensible, you failed this principle the first time.
Liskov Substitution Principle
This principle says that objects of a superclass must be replaceable by objects of its subclasses, and the application must function as expected.
Interface Segregation Principle
This principle was defined by Robert C. Martin while consulting for Xerox, and it is obvious.
“Customers shouldn’t be forced to rely on interfaces they don’t use.”
Robert C. Martin
The software must be divided into several independent parts. Side effects should be reduced as much as possible to ensure independence.
Make sure you don’t force objects to implement methods they’ll never need. Here’s an example:
Not all animals can fly, walk, or swim, so these methods should not be part of the interface or should be kept optional.
Dependency inversion
principle This principle cannot be exaggerated enough. We must rely on abstractions, not concrete implementations. The software must have loose coupling and high cohesion.
You shouldn’t be concerned about the way things are built — but rather the way they work. An easy example is when using dates in JavaScript. You can build your own abstraction layer. That way, if you change the provider’s data, you’ll only have one place to change and not a thousand.
Sometimes building this abstraction layer takes some effort, but it pays off in the long run.
As an example, check date-io, it creates that abstraction layer that lets you use it with multiple Date providers.
11. Leading by Example
“What you are speaks so loud I can’t hear what you’re saying.” — Ralph Waldo Emerson
You are your best tool for influencing your team. It’s not what you say, but rather what you do that sends the right (or wrong) signals to your team. Your actions will indicate what is most important. What you measure, recognize and reward will be the focus of your team.
I usually summarize these points by the concept of leadership for example. The nonverbal messages you will send out of your behavior speak much louder than your words. For example, if you want them to know the importance of being punctual, you always have to be on time for team or individual meetings.
12. Avoid optimization optimization
It is the practice that encourages developers to perform unnecessary optimizations before it is proven necessary. I think if you apply KISS and YAGNI, you shouldn’t fall for that.
Don’t get me wrong, it’s good to try to anticipate that something bad is going to happen, but before getting into the implementation details, you need to check whether these optimizations are really useful.
A very easy example is sizing. You won’t buy 40 servers because you think your new app will go viral. What you will do instead is add servers as needed.
Premature optimization can lead to delays in your code and therefore increase the time cost to market resources.
Many know premature optimization as the root of all evil.
13. Motivation and Engagement
At its core, life is about having enjoyable experiences. So it’s no surprise that happy people are more productive.
You are there to ensure that your team’s motivation and engagement is top-notch. Be careful! One can be motivated but not engaged. You need to understand the differences and different ways to increase them when necessary or keep them at an appropriate level.
Of course, paying attention to the other points in this article would create a healthier environment for developing motivation and engagement. For example, being a good communicator, being approachable and responsive, and maintaining regular personal contact will greatly increase your effectiveness in motivating your employees and creating better engagement.
Also, don’t assume that your people are motivated by the same things that motivate them. Use one by one to find theirs.
14. Be yourself
At first glance, this may seem obvious and even a little irrelevant. But listen to me!
One day you were working with your colleagues and team members, the next day you come back to the office as their manager and hope to become their leader. At that point, it would be easy to fall into the trap of creating a new persona and starting to play the boss. Unfortunately, this will surely fail. Do you remember what we mentioned above? Your job is not to boss people around and create a command and control structure. Their job is to create an environment where they can become better.
14. Advocate for your team
Leaders promote a vision that is embraced by the team. And what your team is doing is important.
In an environment where no team is an island (most companies have multiple teams), it’s important to talk about your team’s mission and how important it is to your peers and senior management. Cultivating good relationships with other managers, influencers and decision makers in your company can be important to the success and longevity of your vision.
Conclusion
These principles are not very complicated. In fact, their simplicity is what makes them so beautiful. If you are overwhelmed, don’t be. For now, just try to increase your awareness and try to include them one at a time into your daily routine.
Having some basic — but powerful — principles to follow will help you become a better programmer and have a clearer idea of why you’re doing things.
If you’re applying most of them intuitively, it’s good to have that aha moment where you see why you’re doing things a certain way.
