Introduction
If you’re running a business, “We need to refactor this module.” is not something you’d like to hear. It doesn’t mean anything unless you come from a technical origin. In fact, it’s a scary statement because that means you need to change something that was somehow working before. As Kent Beck explains in his book, “Tidy First?”: “No new features, possible damage, and nothing to show for it at the end. No, thank you”.
Managers understand the problem space, the domain, and how to manage an organization, not technical implementation details. They aren’t concerned whether you use Next.js, React, Symfony, or Laravel with Livewire. This is also a valid statement for your users. They don’t care about technical implementations; They care about the service.
Managers are responsible for acquiring a market share in a specific domain. They prioritize a product that works reliably and addresses end users’ needs. However, the problem arises when engineers become disconnected from this reality of business world. We expect managers to comprehend our technical point of view and even feel disappointed when they don’t. We want them to understand the significance of “We need to refactor this”. Because it’s really important for us. If you have a manager coming from an engineering background, that is great! Today, we’re going to talk about the other half, where managers and engineers are disconnected.
Why Don’t Managers Understand Software Engineers?
Because we don’t really know how to explain ourselves. We’re stuck with technical terminology. We’re saying stuff like “refactoring” or “technical debt” that doesn’t make sense to most people. They don’t understand about the trade-offs. If a task can be done fast, we should finish it fast. We should stop saying, “Yeah, I could try to do this in a week, but it will be really hard”. This translates into you’re not trying very hard if you’re not delivering it within a week. So you just created a problem for yourself. We often fail to communicate effectively because we don’t think much about how we sound. We don’t try to understand how business operates. Because we’re stuck with technical details. We don’t have time to think about our users, our business, and their needs. We can’t come up with non-technical solutions. We don’t look professional.
I want to make it clear that this is not an attack on engineers. In fact, I used to be in the same position earlier in my career. This is simply an honest self-criticism. I was frustrated by the fact that nobody seemed to understand the importance of refactoring.
Make It Important: It’s More Than Just Bad Code
We need to explain that if we invest some resources in refactoring the problematic module, it would free up mental space for us to focus on other areas of our product. However, this shouldn’t be only about technical reasons. We should provide other rational reasons that make sense to everybody, not just developers.
It’s hard to maintain is not an argument. Your job is to maintain it. It doesn’t matter if it’s hard or not. It’s hard for you, not for the other side of the business. It only matters when you make it important. Many engineers struggle to understand this part. They know the problematic module hurts the business. However, they don’t know how to communicate this issue in non-technical language. We need to find a common language that everybody can understand. Why don’t we present it with actual numbers? Something like this:
We have to refactor the booking module because it’s not only hard to maintain, it caused 11 moderate bugs, and 2 severe bugs last year. The severe bugs cost over $47,500, while the moderate bugs cost around $43,000. We received a total of 197 reports from our users, and one of the bugs even caused a severe security issue that could lead to legal consequences. We have a concrete plan to refactor this area over the next two months. We’ll create a workforce of 3 developers, each focusing on different areas. You can find the plan and detailed list below. These two months of refactoring will save us approximately $65,000 this year, and almost the same amount next year. This will not only solve current bugs, but also improve User Experience (UX), and help us solve future issues quickly. At the moment, we’re spending a lot of time on even small issues. The booking module is currently like a maze, making it hard for everyone. We could put that effort into developing new features.
It feels different from saying “We need to refactor this”, doesn’t it? Sure, it takes a bit more effort than writing one sentence, but if you add up all the complaints, they probably take even more time. Don’t say it’s hard to maintain it. Explain how it hurts your business and User Experience (UX). Try to put yourself in the shoes of the business and the user. Explain how everybody could benefit from this change. It can be difficult for managers to understand why a profitable business should spend time fixing something that makes money.
Complaining vs. Problem-Solving
Soft skills are incredibly valuable to make a great career and connections. Nobody can understand you and your problems if you can’t explain yourself. It’s your responsibility to make sure others understand you, not theirs. This statement is also true for your personal life. Do you genuinely care about resolving the issue, or do you want to complain? Complaining might feel convenient, but it only provides temporary relief without addressing the actual problem. I’ve had colleagues who complained about everything the moment they walked into the office every day. They wanted everyone to understand their issues, but they never tried to understand anyone else’s. To be honest; I don’t miss working with negative people who complain all the time, without attempting to solve any problems. They only spread negativity. You shouldn’t be that person. Complaining doesn’t solve any problems, including yours.
Some people tend to complain, but they also try to find solutions and understand the situation better. It’s totally normal to feel overwhelmed and sometimes complain, especially when you care about something and want to improve it. What I’m saying is, you should remain logical and objective while expressing your frustration. Maybe the problems you’re facing aren’t only your problems, and you don’t have to solve them on your own. It’s perfectly fine to ask for help. But keep in mind that just complaining without taking any action doesn’t help anybody.
Communication
We use computers and code to solve our problems, but we don’t solve computer problems. Ultimately, we are solving human problems. Computers are not our clients. There will be always communication and connection. If we disconnect from our clients, team, and managers, we won’t understand the problems we need to solve. We should focus on the actual problem and avoid drowning down in technical details. That’s why understanding and practicing both Domain-Driven Design (DDD) and Test-Driven Development (TDD) is helpful. We become more connected to the actual problem rather than focusing solely on implementation details. Effective problem-solving requires communication. That’s what companies, managers, and other people are looking for, they’re looking for problem-solvers who can communicate.
Ability to Express Ideas
You’re what you can express to the world. People can only understand you as much as you can explain yourself. Many of us had times when we knew something but couldn’t put it into words. That even made us question if we knew that thing. It usually happens because we have trouble articulating our thoughts. Sometimes, it’s just a lack of understanding or vocabulary. Sometimes, the other person doesn’t have a technical background. Sometimes, we don’t know how to simplify it. We don’t know how to abstract the concept. You need to organize your ideas and make them clear. They need to be result-oriented. If you’re having trouble explaining what you know and what’s causing you trouble, maybe it’s time to start reading and writing more. You don’t have to share it. Writing is a great and relaxing practice. Explaining yourself on a white paper will eventually help explain yourself to people. You will understand how you sound and find ways to make it better. It allows you to brainstorm with yourself.
Constructive Self-criticism
It’s hard to accept that our personal and professional lives are affected by many aspects of ourselves. It’s hard to accept that impacts beyond us, our teammates, or partners. No one ever teaches us this skill, and it’s hard to comprehend. Sometimes, we constantly judge ourselves, which can become an unhealthy habit. But generally, I think constructive self-criticism is an effective tool. I focus on behaviors that I can change rather than global and unchangeable problems. Also, I don’t think about the feelings but prioritize outcomes. These outcomes don’t only influence me, but other people as well. You don’t need to be pushy on yourself but understand situations from other people’s perspective. Constructive self-criticism gives you space and understanding. It’s a tool that helps us form feedback about ourselves.
It’s possible that the functionality you spent hours on might not add any value to the product. Your code reviews may be just holding other developers back rather than providing constructive feedback. If you’re grumpy all the time, it may make people not want to work with you. If you always push people without empathy, you might not be the best leader. It’s about understanding and having empathy.
Conclusion
Of course, external factors can affect our work. Sometimes, a manager has no skills to manage a team, or they’re difficult to work with. Other times, they may lack empathy or micromanage, making it hard for the team to function. I totally understand all those situations. They’re common problems. This article is not about them. Instead, it’s about your personal growth. If you want to build the best version of yourself, you shouldn’t limit yourself to technical skills only. You should develop communication and problem-solving abilities. Don’t let external circumstances limit your potential.
Stay Connected
Feel free to share your thoughts in the comments! I hope to publish every week on various software-related topics.
If you enjoyed this article, let’s connect on https://twitter.com/akmandev and https://www.linkedin.com/in/ozanakman for more content like this!