Recently, a friend told me, “Mustafa, I’ve been coding for 10 years, and I feel like I should become a manager, but I’m afraid if I lose my technical skills, I won’t be able to go back.” This concern stems from the misconception, shared by many technical professionals at a certain point in their careers, that transitioning to a manager role is an irreversible decision. Yet, in my own experiences, I’ve seen that becoming a manager is not a one-way ticket; there’s always a flexible fluidity between technical roles and management.
This dilemma is particularly familiar to me with my 20 years of field experience. Often, organizations approach engineers who become managers with prejudices like “they can’t code anymore” or “their technical skills have atrophied.” But this is only part of the truth. What’s important is how you manage this transition and how you realize what both worlds can offer you.
The Decision to Become a Manager: Why Is Reversibility Not Discussed?
Transitioning to a manager role is often presented as a natural step up the career ladder, almost a “promotion.” This perception reinforces the idea that after a technical role, an individual can only go “up,” meaning more people management and less technical work. However, this one-way thinking leads to little discussion of options for returning, preventing many talented engineers from pursuing this path.
Yet, in my own career, and among many friends around me, I’ve seen countless times that this isn’t the case. While working on a production ERP, a very experienced developer in our team was promoted to project manager. For about two years, he dealt with intense meetings, budget discussions, and HR processes. He was successful, but after a while, he said he “missed new technologies in the ecosystem and longed to write code,” and transitioned back to a technical leadership role. This transition was challenging at first for both him and the company, as he had to change the habits and perspectives he gained as a manager to focus on technical details. However, this friend returned to his old technical form within 6 months, and even became much more competent in contextualizing technical decisions within a business framework, thanks to his management experience. This, combined with his understanding of general business flow and organizational dynamics gained from the manager role, made him a more valuable technical leader.
So why is this discussed so little? Because corporate cultures generally favor linear career paths, and performance evaluation systems are designed in this direction. They operate with a simple equation like “he became a manager, so he did a good job.” Yet, the reality is much more complex and based on individual preferences. Therefore, when making this decision, we need to listen to our inner voice and know that this path is reversible.
Technical Leadership vs. People Management: The Conflict of Two Different Worlds
Technical leadership and people management, although sometimes intertwined, are fundamentally two distinct worlds requiring different skill sets and daily practices. As engineers, we typically focus on problem-solving, coding, designing architecture, and optimizing systems. The first 10-12 years of my career were entirely spent in this vein; I dealt with tasks like configuring Linux services, speeding up PostgreSQL queries, and fine-tuning Nginx configurations.
However, when you transition to a manager role, your focus quickly shifts. Your main task is no longer writing code, but enabling your team to write code, removing obstacles for them, supporting their career development, and translating strategic goals into operational plans. At one point, while leading an 8-person team on a client project, I realized that approximately 60% of our weekly working hours were spent in meetings and one-on-one discussions. Whereas I used to spend 4-5 hours at the terminal to solve a problem, now to solve a similar issue, I was coordinating with different teams, managing email traffic, and consulting 10-15 different people throughout the day to make decisions.
For example, in one of my side products, to solve a performance issue, I had to directly examine PostgreSQL WAL bloat metrics and optimize max_wal_size and checkpoint_timeout settings. This was a purely technical problem, and its solution was technical. However, when I encountered the same problem while managing a team, my job was no longer to directly make these settings, but to delegate this task to an experienced DBA on my team, provide the necessary resources for them, and follow up on the process. Even further, as a manager, it was my responsibility to ensure they conducted a root cause analysis of why this problem occurred and to review architectural decisions to prevent similar issues in the future. This requires understanding the fine line between “when to intervene” and “when to empower.”
This transition can create an “identity crisis” for many. The person who once “only coded” has now become someone who “only talks to people.” However, this conflict, if managed correctly, offers a unique perspective that adds value to both roles. Thanks to your technical background, you can better understand the technical challenges your team faces, set realistic goals, and provide effective mentorship.
Unexpected Costs and Benefits of Being a Manager
Transitioning to a manager role often comes with overlooked costs and unexpected benefits. For someone like me, who has spent 20 years in the field with hands accustomed to the terminal, one of the biggest costs is the diminished desire to contribute directly to technical production. Instead of writing the latest test for a feature or optimizing a system’s performance at a micro-level, you deal with more abstract problems: team motivation, conflict resolution, budget planning, and strategic roadmap definition.
In a production ERP, during the development of a new feature, I used to write the most complex algorithm myself. After becoming a manager, my job shifted to finding the right engineer to write that algorithm, ensuring they had enough time, and anticipating potential obstacles. For a year, my coding time, which used to be an average of 40 hours a week, dropped to about 10% as a manager. The rest of my time was filled with meetings, reports, one-on-one discussions, and emails. This situation, especially if you are a “builder” by nature, can create an internal dissatisfaction.
However, alongside these costs, there are also unexpected benefits to being a manager. For instance, when a critical issue arose in a manufacturing company’s supply chain integration, as a technical engineer, I would have focused solely on the technical solution. But as a manager, I had to consider the problem’s impact on business processes, customer relationships, and financial outcomes. This showed me that software is not just about code, but also an organizational flow. This perspective made my future architectural decisions much more comprehensive and business-oriented.
Another benefit is creating an impact through mentoring and team development. Contributing to the growth of young engineers, guiding their career journeys, and sharing your knowledge and experience is a different but equally satisfying feeling compared to writing code. For example, explaining a Redis OOM eviction policy issue I encountered in my side products to a young engineer on my team, and having them solve it by explaining the trade-offs of different strategies (LRU, LFU, volatile-lru), was not just a technical solution for me, but a success in “knowledge transfer.” This is a different way of increasing technical knowledge.
Barriers to Returning and How to Overcome Them
Returning to a technical career from a manager role is often not as easy as it seems. One of the biggest obstacles you might face is the concern of “skill erosion.” When you haven’t directly written code for several years, technology advances rapidly, and you might feel left behind. For example, when I was a manager, I could only follow the replication mechanism changes from PostgreSQL 10 to 14 or new network configuration options in Docker Compose by reading about them; I didn’t have time to implement them in practice. This can create an “impostor syndrome” and lead to the thought, “I’m not as good as I used to be.”
Another obstacle is organizational prejudice. Companies may hesitate to reassign someone who has been a manager back to a technical role. Thoughts like “They were a manager, they must have forgotten the technical stuff” or “This person only wants to manage people now” are common. Sometimes, even if you return to a technical role, you might face expectations for a salary or title commensurate with your previous management level, which can complicate the process.
So how can these obstacles be overcome? First, making continuous learning a way of life is crucial. Even if you are a manager, dedicating a certain amount of time each week to reading technical books, researching new technologies, or writing code for your personal projects (like my Android spam blocker or my own financial calculator) is critical. For instance, even as a manager, I kept my mobile app development practices with Flutter up-to-date in my free time, while also researching system security topics like kernel module blacklisting. This helped me both maintain my skills and boost my confidence when I decided to “return.”
# Example from an automation script in my side product
# Even as a manager, I maintained my connection with small but technical projects like this.
# This script deletes old log files on servers,
# while also sending important system metrics (disk usage, RAM) to a Kafka queue.
import os
import datetime
import subprocess
def clean_old_logs(log_dir, days_to_keep=30):
"""Deletes log files older than a specified number of days in the given directory."""
cutoff_date = datetime.datetime.now() - datetime.timedelta(days=days_to_keep)
deleted_files_count = 0
for root, _, files in os.walk(log_dir):
for file in files:
filepath = os.path.join(root, file)
try:
mod_time = datetime.datetime.fromtimestamp(os.path.getmtime(filepath))
if mod_time < cutoff_date:
os.remove(filepath)
deleted_files_count += 1
except OSError as e:
print(f"Error: {filepath} could not be deleted - {e}")
print(f"{deleted_files_count} old files deleted in {log_dir}.")
def get_system_metrics():
"""Collects system metrics (disk, memory)."""
metrics = {}
# Disk usage
df_output = subprocess.run(['df', '-h', '/'], capture_output=True, text=True).stdout
# Example output: Filesystem Size Used Avail Use% Mounted on
# /dev/sda1 50G 20G 28G 42% /
lines = df_output.strip().split('\n')
if len(lines) > 1:
disk_info = lines[1].split()
metrics['disk_usage_root'] = disk_info[4] # Use%
# Memory usage
mem_output = subprocess.run(['free', '-m'], capture_output=True, text=True).stdout
# Example output: total used free shared buff/cache available
# Mem: 7984 3456 1234 567 3294 4000
lines = mem_output.strip().split('\n')
if len(lines) > 1:
mem_info = lines[1].split()
metrics['mem_total_mb'] = mem_info[1]
metrics['mem_used_mb'] = mem_info[2]
metrics['mem_free_mb'] = mem_info[3]
return metrics
if __name__ == "__main__":
LOG_DIRECTORY = "/var/log/nginx" # Example log directory
clean_old_logs(LOG_DIRECTORY, days_to_keep=60)
system_data = get_system_metrics()
print(f"Current System Metrics: {system_data}")
# Here, data could be sent to Kafka or another monitoring service.Secondly, clear communication and expectation management are important. As a manager, openly discuss your desire to return to a technical role with your manager and HR. Emphasize that this decision is not a failure, but a different exploration in your career journey. Even explain the value this transition can bring to the company with arguments like, “in my production ERP, I can use my management experience to make more informed decisions on system architecture and operational efficiency.”
The Value of Career Rotation: Gaining Both Technical and Managerial Competencies
Career rotation, meaning transitioning between different roles, has always created value for me. Instead of just progressing along a single path, experiencing both technical depth and managerial breadth makes a professional much more well-equipped. It’s like looking at the world through two different lenses; each role offers unique insights into the other.
For example, when we needed to perform a critical database migration in a production ERP, we decided to use logical replication instead of physical replication. As a technical engineer, I would have only evaluated the technical advantages and disadvantages of these two replication types (e.g., physical being faster but requiring version compatibility, logical being more flexible but slower). However, thanks to my management experience, I knew that this decision was not just a technical matter, but also required considering managerial factors such as business continuity, the goal of zero downtime, the adaptation of different teams (QA, business analysts) to the process, and even the project budget.
Thanks to this dual perspective, by using the flexibility of logical replication, we broke down the migration process into parts and transitioned each module separately, reducing the total downtime to zero. This was not only a technical success but also an operational success. The in-depth PostgreSQL knowledge gained in a technical role and the risk management, stakeholder communication, and project planning skills learned in a manager role combined to produce a much more robust solution.
Another example is a situation I experienced in cybersecurity. When designing network segmentation for a company, I considered not only VLAN tagging and firewall rules but also how this segmentation would affect the operational flow of business units. As a manager, I could foresee the data exchange dependencies between different departments (accounting, production, sales) and the potential bottlenecks of this segmentation. This allowed me to strike a balance during technical design that would not disrupt business processes but would also maximize the security level. This was possible not only with my technical knowledge but also with my business analysis and stakeholder management skills gained through management experience.
Questions I Asked Myself: What Does the Manager Role Add to Me?
At different stages of my career, when I received manager role offers or felt a tendency in that direction, I always asked myself specific questions. These questions helped me make more conscious decisions and understand what the manager role meant to me beyond just a title. One of the foremost questions was: “How will this manager role affect my technical competencies?”
The answer to this question usually depended on the nature of the manager role and the company’s expectations. If the role brought purely administrative responsibilities and left no room for technical contribution, that was a red flag for me. But if the role involved defining the overall strategy of the technical team, guiding architectural decisions, and mentoring talented engineers, then it became more attractive to me. For example, when managing a team on a client project, I made sure to dedicate 2-3 hours weekly to researching new technologies and developing prototypes. This was a “technical pulse-keeping” mechanism for me.
graph TD;
A["Career Crossroads: Manager?"] --> B{"Potential for Technical Contribution?"};
B -- "Yes (Strategy, Architecture, Mentorship)" --> C["Valuable Manager Experience"];
B -- "No (Purely Administrative Burden)" --> D["Stay in Technical Role or Seek Other Manager Role"];
C --> E{"Gains Achieved"};
D --> F{"Career Evaluation"};
E --> G["Broad Perspective"];
E --> H["People Management Skills"];
E --> I["Strategic Thinking"];
G --> K["Better Technical Decisions"];
H --> K;
I --> K;
K --> J["Return (Optional) or Continue"];
F --> J;
style A fill:#f9f,stroke:#333,stroke-width:2px;
style B fill:#add8e6,stroke:#333,stroke-width:2px;
style C fill:#90ee90,stroke:#333,stroke-width:2px;
style D fill:#ffb6c1,stroke:#333,stroke-width:2px;
style E fill:#ffff99,stroke:#333,stroke-width:2px;
style F fill:#ffff99,stroke:#333,stroke-width:2px;
style G fill:#d3d3d3,stroke:#333,stroke-width:1px;
style H fill:#d3d3d3,stroke:#333,stroke-width:1px;
style I fill:#d3d3d3,stroke:#333,stroke-width:1px;
style K fill:#b0e0e6,stroke:#333,stroke-width:2px;
style J fill:#f08080,stroke:#333,stroke-width:2px;
Secondly, I ask, “What will this role add to my personal development?” Becoming a manager offers the opportunity to acquire new skills (communication, negotiation, conflict resolution, leadership) that a technical engineer might struggle to develop. While working on an internal platform for a bank, I had to manage priority conflicts between different departments. This required a “problem-solving” ability very different from solving a technical problem, and I noticed that I developed this muscle over time. This experience later helped me be more proactive in “edge cases” and “error management” when integrating different APIs in my own side product; because the experience of managing uncertainty in human relationships also contributed to managing uncertainty between systems.
Finally, the question, “How realistic is the return scenario for me?” This was partly about how well I kept my technical skills updated, and partly about how open the company was to such rotations. If a company had the mindset of “once a manager, always a manager,” then I would question whether to take that risk. But if it was a structure where career paths were flexible and fluidity between technical leadership and management was supported, then this became a much more acceptable risk for me.
Conclusion: Being a Manager Is an Experience, Not a Permanent Label
Being a manager is a valuable experience you can gain in your career, but it is not a permanent label. Just as you experiment with different VPN topologies or VLAN segmentations when designing a network architecture and then decide on the most suitable one, you should not hesitate to try different roles in your career. In my own journey, I have both designed complex software architectures in a production ERP and managed teams; I delved into the depths of Linux systems and created network security policies.
This fluidity made me a more holistic professional. As a technical engineer, thanks to my management experience, I better understood why the work was being done and its operational impacts. As a manager, thanks to my technical background, I could more realistically evaluate the challenges my team faced. Therefore, shedding the misconception that becoming a manager is an irreversible step will open up much more flexibility and development opportunities in your career. The important thing is to know what you want, to keep learning, and not to be afraid to experiment.