A few years ago, I was a fresh graduate with an engineering degree and some experience in coding and non-tech fields. I went ahead and did what most tech graduates do - applied for a job and started working as an engineer.
I had no idea I would eventually transition to a management position that doesn’t necessarily involve coding. Now I’m working as an operations manager at oVice - a platform that helps connect remote teams.
Since this decision is somewhat unpredictable, I thought I’d love to share the lessons I learned from my coder-to-manager transition.
Generally, I believe coding is a fluid skill. It rests on the foundation of problem-solving and creative thinking - managers need both. The thought process of an engineer will be helpful in management, as you think about the best way to allocate resources or optimize processes.
I often use coding when working on automation or building sales infrastructure. Knowing how to program puts me on the same page with the product team and gives me a solid understanding of what is and is not feasible. The similarities end there.
In other aspects, management comes with the challenges engineers rarely have to deal with. Personally, I had to come to terms with several new realities:
Endless meetings - as obvious as it sounds, a manager’s day is full of quick catch-ups, scrum, 1-on-1s, and performance reviews. For engineers, meetings are often the bane of existence that only distracts us from deep work. Being on the other side, I realized the importance of transparent and consistent communication and have come to appreciate brainstorming and having discussions in teams.
Not having full control. Supposedly, managers should have more control than anyone on the team considering that oversight and leadership are their direct responsibility. Realistically, as soon as you start leading the team, you realize that you have little executive power and quickly discover that motivating people to do something is different from doing it on your own.
Having to know about everything that’s going on at the company. As an engineer, you can selectively check relevant Slack channels without having to care a ton about what happens in different departments (it’s an added bonus if you do). As a manager, situational awareness is your responsibility which means you should connect the dots between product, sales, marketing, and engineering. It takes getting used to but gives you a big-picture view of the product and the facets of building a startup.
As an operation manager, I spend a lot of time designing and optimizing processes. Through my journey, I’ve learned that the view of the platform I had as an engineer was sometimes too narrow and tech-centered.
As I transitioned to management, I had to work on investor pitch decks, track metrics and set quarterly goals for the team. I could no longer limit myself to stability, scalability, and the lack of tech debt.
Instead, I had to see the product our team is building from a non-tech lens - as a client, an investor, or a partner.
That helped shift the focus from the “how” (what is the best functional way to build a feature) to “why” (why does the user need this implementation) and shift focus from app performance data to ARR and DAU.
As an engineer, I heavily focused on getting things done and much less - on talking about them to people outside of tech.
As a manager, I discovered that people aren’t necessarily hyped about the elegance of my solutions if they can’t clearly see how they help promote the product, bring new users on board, and drive revenue.
To build a link between the large-scale success of the product and the underlying tech, I had to back up my claims with business-facing data, share client use cases that prove my hypotheses, and explain complex ideas in layman’s terms.
A visual component was heavily important - aesthetically pleasing charts and graphs help people make connections and arrive at the idea I presented as it if were their own.
In a sense, I am extremely lucky as a manager because I use our own product - a virtual office platform - to manage the team.
Knowing the tool you rely on to run a team inside and out (and having a lot of say in its new features) is helpful - but, even if you don’t, technology still saves a lot of time.
My current project is my first experience working fully remotely. There are people from all over the world on the team - connecting with them without technology would be impossible. To go beyond dull status updates on Slack, I use oVice to communicate the way I did when working at the office.
In our virtual office, I can walk up to a teammate’s desk and ask a quick question just like I would back in the office days.
Also, in oVice I see when teammates talk to each other - this way, I know that people are comfortable having discussions and everyone is included. If I want to listen in or contribute, I can easily join without having to ask for conference links.
oVice helps a lot in building a culture effortlessly. In a physical office, a huge part of working together consists of casual water cooler chats - teammates venting about traffic, discussing the latest news, or sharing common pains. We have a similar environment in a virtual office space - people can casually talk to each other and bond during short daily breaks.
If you are curious to see how this works, you can drop by my workplace any day.
As for other tools, I have a small but broad stack for key operations:
- Work communication: oVice (virtual office), Slack (asynchronous communication)
- Documentation: Notion
- Process automation: Zapier
- Design: Figma
- CRM: Hubspot, Zendesk
- Charts and diagrams: Miro
When I was starting out as an engineer, I knew I liked communication - yet I wasn’t planning on working in management. My focus was on technology and development. Understandably, when I was offered a new position, I took it rather cautiously - I wasn’t sure I would succeed.
A preconceived notion of natural-born leaders contributed to my hesitation. It’s common to think you are either born to manage or be managed - but that isn’t true.
From my experience in transitioning to a management position, I realized you can learn leadership in several ways:
- Resources: blogs (McKinsey Insights, Harvard Business Review), podcasts, and books.
Watching your team leaders and assessing their management practices. As an engineer, I interacted with the CEO of the company a lot - as a manager, I still use his tactics to stay persuasive and connect with the team.
Experimenting and testing: since the beginning of my journey in management, I got used to evaluating ideas, implementing them, and analyzing the outcome. I’ve also learned that some experiments will fail - but the ones that succeed make the pain worth the gain.
Asking your team for feedback. As a newly appointed manager, I felt tempted to “ride a high horse” and show no side of weakness. Eventually, I realized that does more harm than good and distances me from the team. Instead, asking my peers for feedback, admitting my shortcomings, and saying “I don’t know” created a culture of openness and transparency within the team.
Admittedly, I have been thinking about it. Do I want to grow as a manager or do I want to come back to engineering? I think that technology is still my primary passion, so learning alongside the engineers on my team will always be a priority.
However, I know that having seen how technological implementations turn into products, are communicated to investors, and pushed to end-users will make me a better professional in the long run. That’s why I’m happy to have made this transition and learned a lot of things I would otherwise never discover.
I’m sure there are fellow developers-gone-managers on Dev.to. I’d love to read more about the things you learned when making the move and your reasoning behind it. In the meantime, you can catch me in my office or on social media.
Also, we’ll be launching a major update on Product Hunt soon - feel free to check it out and share your feedback.