I fell in love with coding at an early age. After my dad bought us a Commodore 16 and my techy uncle visited us from Los Angeles. He brought a Basic programming book with him, and I started copying the code and feeling the thrill of executing it. I wasn’t one of those whiz kids that could actually code at an early age though. But something clicked inside me, and I knew what I wanted to have a career in. Over the years I realised I am more of a logical thinker and the logical problems coding supplied was a good challenge.

Throughout my career, I spent a significant amount of time contracting. Being parachuted into different teams, projects and industries. The constant change allowed me to move through the tech roles of dev, architecture and leading teams. I then started to be exposed to the mechanics of the things that need to happen before a project being approved to build. I was able to observe the commercial decisions that are made, and their impact on the business before a project even started. I started to enjoy the management and business side and was fortunate enough to have some fantastic managers that could see my potential. They were willing to give me the responsibilities and coach me on my gaps.

This was a big deal for me. Since up until this point I would hear remarks or comments like "you are too technical for the management side" or "You're too techy". Hearing this and seeing most manager roles go to people without a technical background was disheartening. So, having a supporting manager investing in me is something I will always be grateful for.

I wanted to write this article and share ten tips for techies with an inkling to do more than coding. Your technical knowledge can be your greatest power and your greatest curse. All depending on how you use it. I leverage coding principles and apply them to non-technical situations in management. Below I have provided some mappings that I hope you will find useful and might help you move in the direction you want to go.

“Your technical knowledge can be your greatest power and your greatest curse.”

Zero. Commenting code. Let’s first address your self-doubt mindset. Unfortunately, there are always some that are going to make comments that label your skills. Or worse the comments are self-inflicted and anchoring you down. Think of it as running a performance analyser over your code. The lines that are coming up in red indicating a performance bottleneck is your self-doubt. How can you expect to take on a new role with a mindset that has a performance issue slowing you down? All you need to do is put the doubtful methods in a class all on their own. Then go through and comment out the lines of code instantiating the class or calling the methods. This can be a gradual process. One line of code at a time. I would recommend reading or listening to summary versions of The Subtle art of not giving a F*ck (link) to get you started on the right mindset.

The lines that are coming up in red indicating a performance bottleneck is your self-doubt
One. Big Fixing. Bugs have to be the most frustrating and most rewarding thing with coding. Business problems are like a coding bug. The main difference is the humans that are involved that are telling you which path to follow and what they think the real problem is. In management, you just got to follow your same pragmatic approach as you do in code. Ask the questions that start at the top of the problem, followed with questions on the next level down. Like you are debugging in methods and their sub-methods. You are trying to sort through the assortment of facts and opinions to find the root cause of the problem. Once you see it, you need to spend the time to understand it before working to resolve it. If you jump into a hack fix, you don’t know what the ripple effect will be. Take your time, ask the questions you want to ask and avoid going down random rabbit holes. If there is anyone more resilient to working through stress to find a root cause of a problem it is a coder.

If there is anyone more resilient to working through stress to find a root cause of a problem it is a coder.
Two. Mutual authentication. The notion of authentication is on the premise of trust. People are no different. You need to work on building trust with the people in your team and cross-functional teams. This is a time investment that is required. Going for a coffee to get to know someone better will make a problematic discussion down the road easier. The time invested in building trust has a very high return. I recommend reading Speed of Trust by Steven R Covey (link) or a summary version. It breaks trust down into 13 logical steps which are easy to apply in real life. Once you establish a trusted connection, communication becomes more efficient.

Three. Source control. There is a constant to what your team needs. The constant is they want to feel valued. They want to feel like their work means something and want to work with great people that are open to sharing. It is your job to create an environment where this will thrive. Lone wolves will make this environment very hard to build. You should be talking to the knowledge hoarders to understand if it is intentional behaviour. Then help coach them around the benefits of collaboration and sharing. Once you have improved the checking in of code. You need to be deliberate in linking the work they are producing to the business outcomes. Like checking in code related to a user story. Sometimes they can’t see the connection themselves, so you need to help map it for them.

Four. Variables. The thing that I have come to enjoy most is the fact that humans are variable. When you are coding, and you stop halfway through a method and go home and come back the next day. The code will be there waiting for you. In those 24 hours a human might of endured all sorts of highs and lows. They might have new information that has changed their opinion and are now less aligned. Now you are discussing the same thing with a new angle. The code has changed, and that is ok. This is normal and something that is not going to change. You need to use your curiosity and listen. Ask questions and discuss different approaches to a solution.

Five. Methods. Communication is key to your new role. But unlike a method, the same input will not return the identical output with people. You need to get to know some profiling basics and to work to adapt your approach when dealing with the different types of people. Consider people with an optional parameter for their profile. The profile parameter could be one of the four main groups. Amiable, Expressive, Driver or Analytical. Don’t make a mistake to think that all coders are analytical. Also, don’t make the mistake that you can approach non-techies with an analytical approach all the time. You want to improve the success of your communication messages. Try having a looking up those profiles and thinking about who you are interacting with and what the best approach would be to get the desired result.

Six. Separation of concerns. When you are trying to get an idea across, or you are trying to influence people. It is difficult when you are in a room with different types of people. Different personality profiles and different end goals. You wouldn’t add multiple items of logic in one class, would you? So why would you do it with people? When you have an idea, don’t go into a dark corner and flesh out all the details and set up a meeting for everyone to attend. Start by putting a 1 pager together and spend time with individual people who have different goals or approaches. Gain insights and feedback and iterate your plan with a common goal in mind. By separating the conversation from 1: M to 1:1 it allows you to have conversations that won’t get diluted or distracted by rabbit holes. Keep things simple and gain early consensus and then set up the meeting.

Seven. Micro APIs. Your success in your new role cannot be defined by one monolithic coding method. We are in a new age of micro APIs where each API has a distinct function. The cumulation of the APIs working together is what makes them successful. Your success is no different. Don’t look for a big win to define your success. Your success is an accumulation of small wins that work together.

Eight. CI/CD. Don’t expect that the first time you check in your code that it is going to compile against the trunk. Or worse it does, and the defect is deployed into a production environment. In management, you are going to make mistakes. The key is to recover quickly. Focus on what is wrong and take action to resolve. Be vulnerable and admit you made a mistake and you will do better the next time. It is about continuous learning especially from the failures that will make you better in any role. You can read more in my article 5 Tips for continuous improvement through failure (link)

Nine. The trade-off. The requirements have changed, and now you are faced with a dilemma. Focus on speed sacrificing best practice or Focus on best practice and sacrifice functionality. The tradeoff comes up all the time in many forms. In management, it is no different. It is easy to review someone else's code out of context and criticise it by saying you would have designed it differently. The reality is the grey area is the trade-off. Making a decision for your team one way or another means it came at a cost. Although we think coders are binary. The approach to management/business decisions is made in the same way. You factor in the environment, the outcome, the pros and cons of the decision. Then choose a direction and move forward.

I hope you have found this article useful in your journey to your next management role. If you have any other coding principles that would apply. Feel free to reach out as I would love to hear about them.

For any non-techies that have read down to the end. When I was discussing this article topic. It was also suggested to write the reverse article. For non-techy people wanting to move into a techier role. I will take that on and start thinking about the main obstacles and how to overcome them.

Image Credit: Photo by Jefferson Santos on Unsplash