Forem: Young Soo Hwang

Are you an absent manager or a micromanager? 10 red flags to watch out for and tips for finding a middle ground

Young Soo Hwang — Fri, 30 Sep 2022 12:54:10 +0000

In my career path as an engineer and then - as an operations manager for a tech company, I’ve come to believe that there are two worst types of managers - those who don’t care at all and those who do too much.

I’ve noticed that the shift to remote work made both lines of behavior even more pronounced and detrimental to employees.

The first case is the one where managers don’t check in on their team at all. They show no genuine interest in people’s work and are slow in responding to red flags.

At first, employees might enjoy the freedom of lackluster management - no one is standing over you to check if you are writing code or scrolling through Reddit. The work is so scarce you can wrap it up in five-ten hours a week, and no one is asking for more.

That typically holds up until the C-Suite notice that a lackluster manager’s department is underperforming, at which point, the entire team can be disposed of.

Since there are so many absentee managers in remote workplaces, I am sure most people here had at least one leader in this category. Still, I’ll illustrate this behavior with a short example provided by a Redditor:

“I have an 'absentee boss' - genuinely nice guy, but he mostly works remotely and we're lucky to see him in the office 2-3 times a month. He's largely disengaged and has a go-along-to-get-along management style. As a result, it's pretty much the inmates running the asylum these days, bullying/harassment goes unchecked, no plan, no focus, status quo - no news is good news, but you'll hear from him if someone has a complaint over some petty slight.
E-mails, IMs, and calls don't get responded to unless you pester him relentlessly - and when he is in the office, the door is closed as he's in meetings most of the day. The rare time you do get his attention, his mind is in 20 different places.”

The second type of manager is a micromanagement nightmare. Such leaders are absorbed in productivity to the point of not accepting employees at their low and not intervening when burnout is creeping up. On their teams, people are scared to show a moment of weakness and make a mistake.

After a while, pent-up stress and exhaustion drive employees to a dead end. Some leave (a fitting expression would be GTFO) the toxic workplace, others might end up exiting the workforce or switching industries. Letting highly skilled professionals perish because of micromanagement is a loss to organizations and to the economy at large.

In my opinion, this story a software developer shared on Reddit shows how damaging micromanagement is to a confidence of a top performer. I didn’t post the full story (you can read it here) but the general picture comes across.

_“The boss I'm currently working for asks tons of confusing questions. The boss also has an uncanny memory, perhaps even perfect recall. Boss can recall word-for-word conversations from months ago. YEARS ago. And can remember large tree directories without even glancing at the interface. It's kind of spooky…

So boss and I have regular tag-ups. They are intense. I have to give a summary of my week, sometimes my day. A lot of times, it feels like a confessional, but it normally feels like an interrogation.

I don't think I'm special. Boss does this to everyone. We've lost some really talented people over it, but everyone is scared to speak up because it's really just not worth the outcome.”_

In both cases, the overwhelming majority believe it’s better to leave both a company with an absentee manager and one with a controlling leader.

So, for leaders, the question is: how do you strike a balance between disinterest and shattering your fist around the team? Now that remote work and hybrid work are growing in popularity, finding the middle ground is getting harder by the day.

What used to be seamless in the office (for example, daily catch-ups) quickly verges on the edge of over-bearing when done in Slack or video conference.

That’s why managers have to be all the more careful about not being overbearing while showing genuine interest and involvement in their team’s work.

Based on my working history as a programmer and a manager, I outlined 10 aspects that define both absentee managers and micromanagers. I will examine extreme behaviors in each of these and explore the ways to find a middle ground.

1. Reporting

Absent manager: typically has no process for reporting. Such leaders can sporadically ask subordinates about project status updates but are easily satisfied with whatever answer they get. Absent managers have no desire to track month-on-month progress, pinpoint bottlenecks, and encourage their subordinates to proactively seek out ways for improvement.

Micromanager: these leaders need everything to be reported. They have a policy of “If it wasn’t reported, it hasn’t happened”. As the result, the rest of the team feels like they spend more time writing reports than doing the work they are paid for. For micromanagers, reports are not necessarily limited to updates on ongoing tasks but might include all interactions - they would want to know who and when teammates have talked to and have a detailed record of what was discussed.

2. Communication

Absent manager: often prefers asynchronous communication over in-person interactions. Such leaders often take a lot of time to answer and have to be continuously pinged for a reply. Absentee managers also tend to have a reactive approach to workplace communication - they rarely show initiative and intervene only when it’s time to put out fires.

Micromanager: expects employees to be always on and report whenever they are offline. Even the slightest delay in response triggers a micromanager, especially if the team works remotely. To make sure teammates are always available, micromanagers stack their reports’ days with meetings and catch-up calls, leaving people no time to focus on work.

3. Trust

Absent manager: on first glance, it would seem that a manager’s lack of interest is proof of trust in the team. However, it is often a display of indifference - absentee leaders do not really care if the team is underperforming or putting out subpar projects until their managers or clients call them out.

Micromanager: doesn’t trust anyone, least so in a remote environment. In a micromanager’s mind, everyone on the team can do a better job but has an inherent tendency to slack off. In extreme cases, the lack of trust gives rise to questionable employee monitoring practices (often unconsented).

4. Discussions

Absent manager: generally is hesitant to start discussions because they would require such a manager to take up extra responsibilities. On the rare occasions such a manager gets together with the team, there’s little willingness to show proactivity. A disengaged leader typically goes with the flow, hoping that the rest of the team reaches consensus independently.

In discussions, an absent manager has no filter to separate ideas that are and are not worth pursuing. When wrapping up the meeting, such a leader will often try to make it look like everything went incredibly well even though no action plan was created.

Micromanager: will often simulate discussions to get the entire team together and have a sense of control. However, micromanagers are extremely reluctant to accept ideas that interfere with their way of doing things and typically listen to what they want to hear, tuning out out-of-the-box suggestions.

Since having the last word in discussions is crucial to controlling leaders, they would flip out when employees criticize them openly and turn ideas down for obscure reasons like “This is not the way things are done in this company” or “I have more experience thus we should do as I say”.

5. Delegating

Absent manager: typically follows one of the two patterns. Such a manager can either be too engaged in IC work that leaves no time for communicating with reports or have not enough skills to understand and contribute to ongoing projects.

Micromanager follows a similar trajectory. For some, micromanagement is a way to mask their own incompetence. They feel like, by controlling and gaslighting others, they shift the focus from their lacking skillsets. Others are high performers who expect everyone to give their best at work.

They are generally used to seeing their reports doing subpar work and tend to redo the tasks employees submit. As the result, such a manager is always busy and frustrated with the team. “If I could, I would clone myself and do all the work properly” - such a manager thinks.

6. Focus on operation vs strategy

Absent managers: these are often visionaries with little willingness to focus on details and plan operations. They see the picture so big that individual details are blurred out and seem insignificant. However, the devil is often in details, and errors in minute tasks can nip promising ideas in the bud.

Micromanagers: as was the case for a leader in the Reddit story referred to above, micromanagers often have excellent attention to detail (though it doesn’t necessarily have to be perfect recall).

The problem is they are so absorbed in operations that the bigger picture is lost. What’s worse, micromanagers are often stuck in their ways and can’t reconcile with the notion that, through automation or a creative approach, some tasks can take less effort while others can be discarded with no impact on the end product.

Heavy focus on the “how” of a task: the look of the code, the organization of the codebase, the timelines of releases - rather than the “why” - creating a product that delights the end-user - is a common behavior pattern in this manager category.

7. Balancing the good cop and the bad cop

Absent managers often take the approach Kim Scott, author of “Radical Candor” adopted at the beginning of his career in management:

_“In an effort to create a positive, stress-free environment, I sidestepped a difficult but necessary part of being a boss - telling people clearly and directly when their work is not good enough”. _

An employee who hears only praise and no constructive criticism should start suspecting his manager of disengagement. No one is perfect, so if every outcome your employees produce seems amazing, you either don’t know any better or don’t want to risk a confrontation because handling it is too much work.

Unfortunately, outside of the workplace, disengaged leaders often have excellent relationships with their reports making it harder for employees to call out the shortcomings of their supervisors.

Micromanagers, on the other hand, go big on the stick and completely disregard the carrot. They are quick to point out failures but slow to praise successes. At their worst, micromanagers have no tolerance for errors - they want teammates to “go big or go home” which is a bar too high to be humanly possible.

8. Giving teammates control

Absent managers expect employees to be fully in charge of their tasks. They would emphasize the importance of being a self-starter and taking the initiative and will offer teammates no feedback on their ideas or a second opinion when it’s needed.

More often than not, disinterested managers have no organizational structure and have no idea what they expect from someone in a specific role. In such teams, employees are used to waking up to a blank workday, scrambling for tasks to put on their to-do lists, and battling the impostor syndrome.

Micromanagers, on the other hand, give employees zero control over their routines. From the number of tasks to the deadlines and priority - everything is decided by the manager. Employees feel trapped by their roles, so rigid that they fail to accommodate changing priorities, desire for career growth, or occasional plateaus.

9. Dealing with failure

Absent managers sweep failures under the rug to protect their well-being. Even when employees are alarmed and point out red flags, managers overcompensate for incompetence or inertia by trying to instill false optimism. With their concerns ignored or not taken seriously, subordinates can feel helpless and lose trust in their leaders for not noticing challenges and risks.

Micromanagers often deal with failures by scapegoating their reports. Since they think everyone is underperforming, it follows that every bad news is someone’s fault. As the result, teams don’t want to let their leaders know about bad news because they don’t want to see the havoc a manager will undoubtedly wreak.

10. Leading by example

Absent managers are rarely seen in action, so it’s common for subordinates to question the skillsets of their leaders. Disengaged leaders are usually removed from their organizations and show no passion for the company’s product, strategy, or mission.

Micromanagers are often the managers who are micromanaging themselves. Buried neck deep in tasks, they feel overwhelmed by all too many to-do lists and are driving themselves into a crisis. When they become managers, overworked employees are at risk of micromanaging their teams because they don’t know a better way to do things. To them, working means working a lot and they will have a hard time trusting teammates who are not putting in long hours.

How to find a middle ground: tips for managing a remote team:

Micromanagement, as well as lack of interest in the team, is not exclusive to remote teams: it’s just as common at the office. However, the transition to remote and hybrid models exacerbated management challenges across both extremes - recent Microsoft survey data shows that 85% of leaders struggle to trust in the productivity of their employees.

How should leaders approach manage remote or hybrid operations? Here are a few practices we adopted at oVice and find life-saving in managing an over 100-people international team:

Create a space for communication even in a remote workplace. One of the biggest challenges remote teams face is the inability to quickly reach out to someone with a quick question or ask teammates for updates. Heavy reliance on asynchronous communication leads to people losing track of their discussions, bottled-up issues, and stalled projects. On the other hand, video conferencing isn’t the best solution for synchronous communication, especially when data shows teams are already swarmed with meetings. For us, oVice, the platform we built for internal and client use, was a way to create a space where people can communicate in real-time or work side-by-side without feeling the pressure of being on camera eight hours a day. The ability to quickly connect with colleagues gave my team the ability to instantly solve problems and speed up project completion. We also saw significant improvement in engagement and retention: a virtual office space helped interconnect teams and streamline interactions between departments.
Focus on task-based, not time-based performance tracking. Trying to see how much time people spend at their desks in a remote environment is a fool’s errand. To begin with, time spent at the workstation doesn’t equal productivity - haven’t we seen people surfing the web during their office hours? That’s why I believe that the future is not in time tracking but in task-based progress tracking. The tricky part is in accurately estimating which workload is manageable for an employee and overloading your team - but you can learn where to set the bar by connecting with other players in your industry or conducting monthly employee surveys.
Make it easier for people to ask you for help. A manager who drops by an employee’s desk every 30 minutes with a “How can I help you” will come across as annoying and irritating. On the other hand, if you remove yourself from the team, you will never know when people need help and will be surprised to see that there was no project progress. For me, the middle ground is to step in when people need me but make sure it’s easy for them to reach out. For one, during my working hours, I log into my virtual office space to make sure my teammates can come by and ask a question. Other than that, I have a Calendly page teammates use to book 30-minute appointments.

Although micromanagement seems to be highly popular, I am yet to see managers who admit to going too hard on their teams. Similarly, I’ve seen few leaders recognize they don’t give their teams enough attention.

But, as they say, the first step to fixing a problem is admitting you have one. So, if you spotted some of the red flags listed above in your behavior, don’t beat yourself up and start looking for ways to either build up employee trust through setting realistic expectations and refraining from policing your team or increase engagement by creating more opportunities to connect with your subordinates.

To see how a virtual office space like oVice can help you achieve both goals, explore our case studies or visit the tour space (you can probably catch me there as well).

Lessons from scaling a tech startup to multi-million ARR (Part I: communication and management)

Young Soo Hwang — Mon, 15 Aug 2022 07:50:58 +0000

The startup I’ve been working for is nearing its 2nd anniversary. I’ve been there from Day 1 and have seen a few-people team grow into a branched structure with over 150 employees.

I wouldn’t say the journey had no bumps across all levels (engineering, marketing, product). Still, I believe that what we achieved from the technical and customer satisfaction standpoints was quite impressive.

I think half of our success was in knowing how to design systems and implement practices, understanding when and who we should hire, and quickly adapting to the market (that, during the pandemic, changed by the day).

The other half of our success is in using technology where we could, automating tedious processes, and finding tools that would help us make the most out of human resources.

In this post, I want to reflect on the practices and platforms we used to drive growth as a small team and sustain it as we scale. I put this with engineers, project managers, and business owners in mind to help them tame chaos and turn ideas into organizations.

In part two, I will delve deeper into software engineering practices fellow developers can apply to their projects. Stay tuned!

Quick background on the project

To make sure we are on the same page for the rest of the post, I’ll give you a quick reference note about the project I have been working on:

Idea: oVice is a virtual office space company that brings hybrid and remote teams together in the same virtual room. It trumps Slack by bringing a visual component to remote teamwork - you see everyone in the organization at a glance.

It beats Teams and Zoom in spontaneity and engagement - you can walk up to teammates and casually chat with them. You can move around as you talk or have different meetings in different areas to spice up the routine of back-to-back calls.

We also focused on stability making sure our product leads the market by the stability of audio and video.

Launch process: we launched in August 2020, when the world was still processing the pandemic. oVice is based in Japan, where teams who mostly worked at the office, were now scrambling for tools that would help them get by remotely. Most of them missed the connectivity, even the look and feel of the virtual office space. That’s where oVice came in, offering businesses a way to move their offices to the web.

Later, we expanded in South Korea and started building up our global department. Now, oVice has three divisions: a Japanese, Korean, and global one. Managing such a distributed company has its own challenges - I’ll talk about them in more detail.

Milestones:
Since its launch, the project blew up in Japan and had moderate success in other markets. Two years later, we are looking at:

Multi-million ARR that tripled since 2021
Over 2,200 clients worldwide
Over 60,000 DAUs worldwide
Over 100 virtual spaces are created every day

Challenges teams faced when growing the project

In 2020, launching a startup felt like exploring the Wild West - on the one hand, digital projects were booming and breaking records in revenue. On the other hand, setting up infrastructures and operations during the pandemic was overwhelming.

At the time, leaders were getting used to digital-only interactions, wondering what they should do if key knowledge holders have to take a break due to COVID, and looking for ways to shield teams from stress.

For me and my team, the key challenges of growing a project were:

Market expansion - when piloting an innovative idea, you have no way of knowing how the market is going to take it. Before we could focus on promoting our product, we had to first show team leaders they had communication challenges and convince them to try tools they had no idea about. That required a lot of work in awareness, especially in the Japanese market where Slack, Zoom, and other collaboration platforms had slower penetration.
Communicating with distributed teams. From day one, the availability of project teams was all over the place - some worked in EST, others - in CET, and most of us were based in JST. Finding sweet spots where everyone is available was a pain in the neck.
Connecting with target audiences. During the pandemic, we couldn’t rely on event-based networking or meeting with people face-to-face. Instead, our sales teams had to focus on social media prospecting and find tools that would facilitate data gathering and lead nurturing in a digital environment.
Hiring new talent. We launched the project in a heavily candidate-driven market. Everyone was hiring - from Google and Netflix to startups and small businesses. Finding a package of benefits that would lure skilled candidates in took us time. Also, teams had to learn to make the most out of the resources at their disposal - people, tools, and time.

Organizational best practices

When a new project like ours enters the market, it doesn’t have the prestige, budget, or enough talent to successfully storm into its target market. What we lacked in these areas, we made up for with an intentional approach to engineering, product design, and marketing management.

Here are the practices I and other team leaders have discovered on the journey of scaling a multi-million startup in two years.

Know when you are ready to hire (because you might not be)

We launched oVice during the pandemic - back then, the collaboration market was booming. New products were sprouting out of every corner and the pressure to do better was in the air.

A surface-level solution was obvious: hiring. We could put our revenue into bringing in more engineers, push the product to the market faster than anyone else, and snatch that first-mover advantage.

The math is as simple as a standard pop quiz question: “If one person can dig a hole in two days, how long will it take for two people to dig a hole?

From a managerial point of view, the answer is not straightforward.

By doubling your resources you will not necessarily double the output if the people you hire to dig a hole keep arguing about the best way to hold a shovel and get no work done.

That’s why I believe that hiring is not always the best way to boost project speed. You should only hire when you have enough resources to invest in leadership, processes, collaboration tools, and other building blocks of an expanding organization.

If your goal is speed alone, there are other ways to reach the destination:

Automating workflows
Lowering the bar of requirements
Reusing components
Buying off-the-shelf solutions
Bringing in a third-party contractor who has the team and the infrastructure set up

Expanding your in-house team might be the most obvious answer but, whether your organization needs it or not, is a very case-by-case discussion.

Don’t underestimate communication when working remotely

Numbers show that most companies interact more once they start working remotely. A lot of engineers are unhappy about it because when meetings take up most of the workday and drain us emotionally, when are we supposed to code?

I used to think so myself but, the more I work in management, the more I realize the value of collaboration. If two exceptional engineers don’t communicate, teams are running a risk of:

Work duplication
Having two pieces of code that don’t fit together
Low codebase reusability: the dev who wrote it is the only person understanding the code
No organization-wide best practices: two features of the same product will look drastically different making maintenance a nightmare
And many more issues…

There’s the classical “this meeting could’ve been an email” rant which I agree with - for the most part. I’ve had a project that the team discussed mainly asynchronously (email, Slack, etc.) and, when the result came out, no one was happy about it, though everyone seemed to agree in writing.

The issue was in the fact that people had small comments or concerns which didn’t feel important enough to write down on Slack. Yet, as these details compounded, we ended up with an unusable output.

That’s how I learned I should take the time to put people in the same room and encourage them to nitpick the project and share the littlest concerns. Now I know that some emails should be meetings instead.

Let the data solve arguments

This may be a “duh” statement for many but, as teams grow bigger, so much time is lost over people arguing.

I’ve seen this on every level - engineers fighting each other over best practices, designers having heated debates on wireframes and prototypes, and marketers speculating which campaign will do better.

Unfortunately, teams can spend months bickering and have no tangible progress. That’s why, rather than trying to reach a consensus on calls, I encourage my reports to shortlist 2-3 digestible ideas and test them.

Once we do, there’s data on which teams can base conclusions. Since numbers don’t have personal preferences, egos to protect, and faces to save, they are way better at telling the truth.

Build cross-department connections

As a manager at an international company, keeping a keen eye on what other teams are doing is vital.

Whenever I got too caught up in a problem my team was trying to solve and forgot to see the big picture, I would inevitably discover that someone in the Japanese or Korean team had already found the answer.

In such situations, it’s always painful to think I would’ve spared my team months of effort if I knew what was happening outside of my division.

That’s why I encourage leaders to take aligning with other teams seriously. Helping each other out and sharing knowledge can propel growth and save you a lot of resources.

Here are the practices we set up:

Document all meetings so that people from other teams can keep tabs.
Add translation bots like Deep Thought (by DeepL) to Slack - it helps us translate the Slack channels of the Japanese team to English.
Create designated “bridge” roles - hire people who would follow and align processes in both teams.
Share knowledge in weekly town halls and team-building events.
Meet in person whenever possible to build stronger relationships

Spend as much time on research as you do on execution

When you work for a startup, there are millions of ways to use your time and there’s always ground to cover. That’s why, at some point, teams find themselves (as mine did) endlessly juggling task lists and trying to maintain the processes we had set up.

Your reports might get so absorbed by agendas that they no longer have the time to explore market trends and best practices and reignite the passion for their field.

For a continuously evolving market like ours, working in a vacuum is a disaster. Trends come and go - so, if I missed an opening, there’s no way to get it back. Our team is not immune to this - in retrospect, I know there were market signals I should’ve taken more seriously and once-in-a-lifetime opportunities, that we could but failed to seize.

To make sure we keep track of market trends and technology advancements continuously, I adopted the following practices:

Created Slack channels where people can share news
Asked the marketing team to create weekly roundups of industry updates and share it on social media so that both our clients and our team can stay updated

Subscribed to relevant tech and industry newsletters (Programming Digest, McKinsey On Point, Management Tip of the Day by HBR, and others)
Curated a list of social media influencers I follow on LinkedIn and Twitter to stay in the loop

These discovery sessions add a sense of direction to our work, fuel creativity, and promote personal, as well as career development.

I believe that encouraging people to get involved in the industry of the project will give them a sense of purpose and a clear “why” behind every item on their to-do lists.

Tame the chaos when you can, embrace it when you cannot

Unfortunately, chaos has become the synonym for working at a startup. When you have competitors like Microsoft and Meta to go against, as well as ambitious market entrants, it’s easy to get overwhelmed by everything you as a startup founder or department leader have to do.

For a while, working in a chaotic environment might not bother you but, in the long run, its damage is lethal. Your reports will feel stressed by instability, their work hours will get insane due to the task and information overload - I’ve seen engineers on Reddit complain about panic attacks, weight gain, and severe mental health issues developed in disorganized workplaces.

From the productivity standpoint, a chaotic environment is just as damaging - no matter how fast your teams are moving, if that velocity is directed every which way, it will cancel itself out, leading to no net progress.

That’s why, in managing teams, I focus on structuring processes and putting things on track. Here are a few easy-to-set-up practices I adopted to spare teammates stress:

Learning how to create data-driven timeline and budget estimates

It takes no effort for a manager to pull a guesstimate out of thin air and pass it over to the team as an industry standard.

It will take a lot for the team to try and squeeze a mammoth’s work into a tight timeline. If you keep asking people for the impossible, your reports will feel like they are failing all the time until, one day, they will break under the pressure of continuously underperforming and start silently handing in resignation letters.

That’s why I took some time to research Youtube videos, blogs, forums, and the scientific evidence behind deadline planning to make sure my team doesn’t rely on guesstimates but on carefully constructed prognoses.

Focusing on processes, not tasks
Another realization that came to me was that, rather than assigning one-off tasks to my team that people would have to repeat from scratch without a consistent timeline, I would create structured workflows where every step logically leads to the next one and the result is clear before you start.

I find tools like Miro are extremely useful in visualizing a workflow and summarizing complex processes.

As part of the same initiative, I try to not assign one-off tasks to my team altogether.

When I think about future projects, I ask myself “Can I make this idea a consistent practice?” If the answer is “No”, I will explore a different idea.

Setting up flexible routines

There’s an interesting discrepancy between flexibility and stability. Lately, there’s a lot of buzz about employees valuing autonomy and yearning for full freedom. Some managers are happy to follow that train and set up no routines whatsoever - no meetings, no weekly reports, nothing.

Yet, there’s a different side to the coin. Studies show that, once given the flexible arrangement, employees still tend to build routines around it - they come to work at the same time, work for roughly the same number of hours, and clock out on a steady schedule. It is fascinating how predictable humans can be, and managers should leverage that tendency.

In my case, I started setting up regular weekly syncs and dedicated project meetings to give my reports a sense of structure and order - especially since I know that, for many, a prospect of a day full of unknowns is uncomfortable.

These are some of the practices I adopted to reduce stress levels and increase predictability in my team. While they help me somewhat structure operations, I can only ever know one thing - change is constant.

Things outside of my control will keep happening, the workplace will keep changing, and there will be new fires to put out.

A degree of flexibility and adaptability is essential - otherwise, organizations become too rigid and ultimately go down, outpaced by faster, more flexible, and daring competitors.

Last but not least: failure comes before success

The last and most important lesson I learned is that my team's successes grow in line with our failures. I used to be extremely worried about not always being on schedule or not hitting a milestone - in my mind, these were the red flags for a dying project.

Over time, I’ve seen how much failing contributed to resilience and encouraged us to keep searching.

During the last two years, we had to make major product tweaks and redesign our website because the solutions we had before weren’t right. I won’t even mention countless iterations of specific features, design elements, or social media ad campaigns we had to test and discard.

At the time, they seemed like failures but, in retrospect, we interpret them as experiments that led us to better answers.

As I look ahead, I know some calls we make will be wrong. However, I’m not concerned about them - at this point, I would be worried a lot more if my team stopped failing. That would mean we are playing it too safe.

If you want to follow my journey in management and are interested in my insights in working in engineering and leadership, come back for weekly updates. If you want to talk to me about my project, discuss partnership opportunities, or chat about running a remote/hybrid team - come by my virtual office.

How I knew that going from engineering was right for me (and quick tips to figure it out)

Young Soo Hwang — Thu, 28 Jul 2022 08:55:08 +0000

At some point, when engineers reach a level of seniority, they become curious about management. I am convinced that every individual contributor arrives at the point of getting larger-than-oneself ideas and wanting to use the insight they accumulated through technical work to lead teams.

For years, management seemed a logical next step for a developer’s career, up to the point of a strongly-held belief that getting a manager’s title is a “promotion”. Only after having made an engineer-manager transition myself, I am confident this is false.

When you are a manager, you stop being an active contributor or have to cut your workload and give up challenging tasks. Over time, you might discover your coding skills have deteriorated and realize you are behind on tech trends and best practices.

At the same time, I believe that transitioning into management is the right move for a fair share of developers - this was definitely the case for me. It’s been over a year since I accepted a management position at oVice - a remote-first company that supports remote and hybrid teams with collaborative virtual office spaces.

In this post, I’d like to share a few pointers that will help you understand whether a career path in management is the right one for you.

Dip your toes before you dive in

In my career as a developer and a manager, I’ve seen several reasons why people make the transition from an individual contributor (IC) to an engineering manager (EM):

Team leaders present the new opportunity as a raise and offer a higher paycheck (a huge organizational mistake since skilled engineers are as important as managers).
Working as a contributor isn’t stimulated enough and engineers want to try something new.
ICs start questioning their managers and feel like they can (and should) do a better job.
An urgent position opens and an engineer decides to fill it in as a favor.
The opportunity to switch the business side (for people who were not too passionate about coding).
Being a manager and having a team report to you stroke an engineer’s ego.

Then, once they made the decision, engineers often discover the not-so-glamorous side of management: constant stress, interruptions, back-to-back meeting, and no feeling of control (the opposite of what you could’ve expected). Before they know it, they hate the job and regret their decision.

If you want to get rid of the weight of regret, I recommend testing the waters first - take up a few manager-like responsibilities within your IC role or get a position on the edge between coding and management.

Here are a few low-effort ways to try management without committing to an EM role right away:

Mentor junior developers and oversee their career growth. This way, you will discover if constant communication, teaching, and the need to answer questions are not putting too much stress on you.
Work as a tech lead. While tech leads and EMs have somewhat similar responsibilities - communicating strategies to the team, helping developers prioritize tasks, and contributing to developer training, tech leads are more involved in the nitty-gritty of development. They oversee code reviews, introduce development practices, even code themselves. By getting into management as a tech lead, you will see which between the two (hands-on programming and dealing with people) you gravitate to and make an informed decision.
Shadow an engineering manager. It’s a simple but effective way to see if are ready to commit to an EM role. Shadowing a manager at your organization for a few weeks should give you an idea of the workload, amount of stress, and typical responsibilities.

Let’s suppose you tried all of the above and are still not sure which way to go. What I did in this situation was a round of introspection - understanding what I like about engineering and management and the challenges I might face both ways.

Pros and cons of staying an IC

These are the things I took into consideration when making my decision. They might not be universally applicable so I recommend doing the same analysis with the specifics of your job and company in mind.

I assigned a score to the benefits benefit of working both as a manager and as an individual contributor so that I can see which way the pendulum swings.

Benefits of staying an engineer

Broader job market
The numbers speak for themselves - there are 68,382 “senior software engineer” job openings on Indeed compared to 32,875 open engineering management positions. If I stayed as an IC, I would’ve had higher job security.

Personal relevance: 2/5
I am not highly driven by job security - in my opinion, as a skilled EM I should still be able to find a job even in a smaller pool of opportunities.

Following technical trends and improving coding skills
I like to think of engineering management vs individual contribution as an intersection - at one time, you can either go one way or another. Eventually, you can come back and go the other way, but it will be too stressful to do both jobs well at the same time.

I knew that, if I flip a switch and transition to management, I will have to focus on improving in leadership, communication, and strategy - much less on technical problem solving or architecture design. Thus, it was obvious I wouldn’t be top of the market in programming like my colleagues who committed to coding.

Personal relevance: 4/5
Deciding to slow my progress in software development down was not easy. I found solace in the fact that understanding the bigger picture will make me a better professional even if I come back to an IC role.

I still see the work my colleagues are doing and absorb some knowledge by passive diffusion. I still do my best to follow the latest industry trends. At the same time, I understand that alone is not enough.

I understand I will be behind if I decide to come back but I am confident that having a backbone in leadership and a 360-degree view of a project will help me focus on the “why”, not only the “how” of coding if I am back to engineering.

Sense of accomplishment
Working directly with the codebase gave me a lot of fulfillment. It is satisfying to finally ship a feature, solve a difficult problem, or fix an error no one else could figure out. That thrill is the backbone of software engineering but it is not as applicable in management.

Engineering management is a team sport, which means you are responsible for everyone’s success. There’s no way to remove yourself from organizational issues by telling yourself “Well, I’ve done my job”. There’s no sense of short-term accomplishment either - you can oversee plans and strategies that will pay off in months or years. Everything in between will be uncertainty and trying to convince your and other teams that your strategy will work - even though you are never 100% sure.

Personal relevance: 3/5
Even as an engineer, I got little satisfaction from just doing my part of the job well. I would get invested in what happens to my code, the part it plays in the product, and the way it benefits the end-user. I didn’t feel a ton of joy from shipping a feature if I didn’t understand how it benefits the project in the long run. That’s why, when I switched to management, I enjoy the ability to see things through and no longer be restricted by my scope.

Total: 9/15

Benefits of transitioning to management

Working with the “why” of technical work
As an engineer, I often felt restricted in my focus. There were a lot of technical details to keep in mind whereas what actually interested me was how to work more efficiently and meaningfully. When I was given a task, I would often find faster or cheaper ways to arrive at the same outcome - but making these decisions wasn’t always up to me.

Now that I am in the management role, I am involved in important conversations and strategic decisions on budgeting, product development, marketing, and sales. My view of the project became broader and I got to talk to end-users, experience their struggles and receive feedback on the product face-to-face.

Personal relevance: 5/5
The ability to clearly see how the project impacts the market and helps companies is the most fulfilling part of my work. I am grateful when clients share testimonials about how a virtual office platform improved their approach to remote and hybrid work, and being in management gave me access to this proximity.

Connecting with more people
Constant synchronous and asynchronous communication with colleagues is the key to successful management. Although I chose a technical path, I always liked connecting with people and kept doing this through a range of part-time jobs - I worked as a barista, a secondary school PE teacher, and so on.

Engineering has a strong communication component (a good developer is a team player) but it still revolves around focusing on the task at hand. Meanwhile, management is communication. You get to connect with your team and other teams, other department leaders, clients, partners, and investors - you name it.

In my career in management, I’ve met dozens of people from all over the world. Connecting with them on a daily or weekly basis is a highly rewarding part of my work.

Personal relevance: 4/5
Developing communication and leadership skills, as well as defining and communicating the company’s strategic vision was always interesting to me.

At the same time, management comes with a lot of responsibility, especially that of handling my teammates’ careers and making sure they have a work-life balance, feel appreciated, and fulfilled at work. That’s why I believe that, in management, mistakes come at a higher cost than in coding, because teammates are the variables you are working with.

Committing to that responsibility was (and is) stressful but the ability to connect with people from different cultures and backgrounds tipped the scale in favor of management.

Learning new skills and becoming an all-rounder
As a developer, I was mainly concerned about making progress in my field, rarely taking the time to see what marketers, salespeople, or HR professionals are doing. I knew, that once I switch to management, I will have to understand all the processes within the organization, and was excited to step up to the challenge.

As a manager, I have to work closely with HR to communicate hiring needs and participate in candidate selection. I am highly connected with the marketing team, helping them streamline operations, set up processes, and address concerns. I am involved in the activities of the product team, as well as those of the sales department. I also represent the company externally, attending events, and connecting with investors or prospective clients.

Personal relevance 3/5
A part of me is worried about not picking up new coding skills when working in management. Also, I have to accept the challenges I haven’t worked with before - that is stressful. At the same time, I realize I would never have learned as much about communication, marketing, product design, talent management, or budgeting had it not been for the transition. That’s why I am happy with the choice and wouldn’t take it back.

Total: 12/15

After analyzing the benefits of both approaches, I realized I would get more from working in management. That’s why I decided to accept the offer to transition and committed to my current position: Global Operations Manager.

Fast-forward: my observations after working as a manager for almost 2 years

I took the Operations Manager position in 2020. Since then, I’ve firsthand experienced the positives and negatives of management and have a rough idea of what can make an engineer fit for the transition.

Switching to management will be good for you if you:

Have a strong vision and feel restricted by having to focus on coding alone
Enjoy communication and don’t mind having a day full of meetings
Don’t require a quiet focused environment for work and are okay with interruptions and controlled chaos
Want to dive deeper into the business side of product design.
Always look for ways to improve processes for yourself and the team, love trying different collaboration tools and methodologies.

Staying an individual contributor is a better fit if you:

Enjoy the accomplishment that comes with accomplishing personal tasks
Love the technical aspect of engineering more than the business side
Are uncomfortable with “information processing tasks”: documentation, reports, presentations
Feel pressured by long-term planning and having to make large-scale decisions and would rather focus on practical tasks

I’ll finish this by saying that, if it looks like a manager in your company is doing nothing, they might actually be excellent at their work. I’ve discovered that the ability to filter the background noise and help teams focus on their tasks is what separates excellent leaders from mediocre ones - that’s the point I am trying to reach in my career.

So, if it feels like working in management is not a big deal, chances are your team leader is making it look easy. On the other hand, if you feel drawn to the field despite the constant stress, incessant impostor syndrome, and never-ending flow of tasks, going into management might be an excellent step in your career.

Engineers don’t have to be bad at communication: how I successfully learned communication skills

Young Soo Hwang — Wed, 20 Jul 2022 08:20:45 +0000

When I was working as an engineer, I would often hear people from non-tech departments complaining about programmers being difficult to talk to. In my opinion, there’s a grain of truth to that - but it’s not our fault.

Programming is a very niche field that is hard to talk about unless the person on the other side of the conversation knows what is going on. For developers, working with variables, functions, and methods is so routine we often forget not everyone is on the same page with us.

Also, software engineering has a strong solitary component - if you write code for hours without having to talk to anyone, before you know it, reading social cues will get more challenging.

So, if you are in software development, it is likely you’ll get out of the habit of communicating with the non-tech world (the majority of humanity). However, in our field, communication is important, and learning how to express concepts and ideas in a clear way or connect with teammates will propel your career.

In this post, I want to share a few tips that took me from a fairly reserved engineer to a confident manager of a team focused on sales and communication.

Personal communication: cracking the code

Regardless of the number of people and type of interaction, improving basic social skills will come in handy. I’ve seen a lot of my coder friends hide in the “I’m an introvert” bubble and give up on intentionally improving the way they interact with others.

Here are a few simple tips that, in my experience, improve water cooler chats with colleagues, help build connections with team leaders, and make the most out of a social environment.

Trust your gut. As programmers, we often expect conversations to follow an “if-then” flow:- if I say this, my colleague will answer that, and so on. Obviously, communication is way more complex - there are inflections, connotations, gestures, and other nuances. I don’t think it’s possible to dissect and monitor all components of a conversation. That’s why, over time, I started focusing on aligning the emotional wavelength with that of my conversation partner. So, before I strike up a conversation with someone, I usually think about the feeling I want to transmit - being relaxed, spontaneous, or on the contrary - professional and down to business. Once you decide on the tone of the conversation and get yourself in the right state of mind, the people you are talking to are likelier to match the vibe.
Don’t take all the responsibility (but don’t let it go completely). Another issue I’ve seen people struggle with is either feeling pressured to take full control of the conversation or hoping the other party will save the day. The first logic puts you under a lot of pressure and discourages you from reaching out to teammates or managers. The second state of mind gives you no control over the situation and leads to misunderstandings down the road. A more reasonable approach is in seeing a conversation as a two-way street. If it’s getting stale, it’s not your fault but there’s definitely something you can do to improve the flow: ask a question, make a joke, or offer a suggestion.
Failure is a data point. A lot of people believe that social failures reflect their core self - it doesn’t. From a coder’s perspective, when we find bugs or see that a module failed a test, do we think that the entire project is no good and should never be brought to production? Usually, that’s not the case - everyone accepts bugs as part of development. Likewise, from time to time I see bugs and errors in social interactions but I discard the entire “codebase”. Instead, I take the time to pinpoint and address the issue, run a few more tests (talking to more people), and ship my improved conversational skills to the production.
Find your version of Stack Overflow for social interactions. I am convinced that communication is a skill so the combination of learning resources and practice should help improve the outcome. Since, in programming, we don’t expect ourselves to know every function or method and ask online communities for help, the same should be true in the social context. When I want to put conscious effort into improving social skills, I go to books, communities, and YouTube channels. These resources guide me when I encounter an unknown social problem.

Functional communication: how to get things done

Building personal relationships with co-workers will make your career more fulfilling and enjoyable. At the same time, you want to stay productive and drive your projects forward.

That’s why a new - functional - layer is a crucial component of the communication infrastructure.

Here are the workplace communication tips I learned as an engineer and use to this day as a manager.

When you discuss something verbally, follow it up by writing it down on Slack or other collaboration tools. In verbal communication, details often slip through the cracks - after a while, your teammate can forget or misinterpret what you had previously discussed. To avoid confrontation and unmet expectations, I put together a short summary of meetings and share it on Slack, Notion, or other platforms you are comfortable with.
Don’t bottle up concerns. When I don’t understand project details or am unsure whether a manager’s approach is correct, I do my best to speak up. Doing a lackluster job because I am not aligned with the idea will set the entire project back. At the same time, rather than openly stating that something doesn’t work, I would for ways to understand the team leader’s train of thought - in most cases, there will be valid reasons that would get me on board with the project.
Make catching up with teammates a routine procedure. Connecting with the rest of the team might feel difficult when you feel like you are getting in the way of people’s work. That’s why, instead of asking people for their time out of the blue, I schedule regular catch-up sessions (once a week, once in two weeks, or once a month) for asking questions, sharing knowledge, and discussing ideas.
Writing and formatting go a long way. Workplace communication is in many ways similar to programming: we follow formatting and naming conventions to keep the code readable and neat. Similarly, catching spelling and grammar mistakes and making yourself clear in Slack messages and emails help me avoid miscommunication and make sure people understand my points. Since I am not a writing expert, I use Grammarly to check the tone of my messages and keep them clear and concise.
Plan your interactions. In casual conversation, being spontaneous helps me be fun and keep an open mind. In work-related situations, jotting my talking points and outlining the problems I want to solve work way better. This way, I save the team time and can easily understand if a meeting was a success or a failure. I highly recommend setting a time window for conference calls (for example, 30-45 minutes) to keep everyone present in check - otherwise, we might keep going back and forth for hours. ## Leadership: how to motivate, inspire, and teach When I started my career in software development, I was more used to following than leading.

I still think that doing what needs to be done is an important skill - however, as I progressed in my career, I would get new ideas and have to pitch them to the team. Also, my manager would ask me to mentor junior engineers and I would realize I don’t know where to start.

That’s why communicating as a leader is important - and it has unique challenges.

In my case, the quest for leadership started when I switched from engineering to management. I had to communicate and delegate rather than just do the technical work. I already shared the lessons I learned during the transition - now I’d love to dive deeper into how I practiced communicating as a leader.

Learn how to teach. Explaining ideas in an understandable way will be crucial in workplace communication. There are several ways to go about this - sometimes, I go through concepts out loud as if I’m teaching someone. Other times, I would volunteer to help teammates out just to practice mentoring. Also, watching educational content of any kind (The Coding Train or Derek Banas for coding, Veritasium or Kurzgesagt for broader science) shows how people explain complex ideas in a digestible fun way.
Listen and care. One of the approaches to management is “servant leadership” which implies putting the team first. I advocate for this leadership style because it encourages leaders to appreciate their teams and puts the focus on employee well-being. I found that managing a team successfully is often about understanding what other people want and looking for ways to make their aspirations a reality. To make sure I know what my team wants, I welcome and listen to suggestions, and resist the urge to say “no” right away even if something seems impossible or wrong at first.
Connect with the team. It is fascinating to me how helpful just being in the same space with your team is. The feeling of synergy and building projects together is empowering and helps boost engagement. The pandemic and shift to hybrid work made connecting with teammates harder but not impossible. To stay united no matter where we are, our team built oVice - a virtual office platform that helps our team and many others not lose connection and inspire each other to be more productive. One of my favorite management tactics is coming to the virtual office space as much as I can for work or meetings. When the rest of the team sees me being productive, they also feel motivated to finish their tasks.
When you work on a project, think of it as your own. As I was working in development, I would get caught up in tasks someone wanted me to do and lose interest in a good result. At times I would feel like: “I’ll just get this over with so my manager is not breathing down my neck”. Eventually, I changed that mentality and started treating the projects I was engaged in as my own. This flipped a switch in how I saw my to-do list - I started applying a business perspective to my engineering efforts and looking for ways to optimize everything I’m working on. When I transitioned to a manager role, this mindset helped me lead teams, strategize, and make intelligent decisions. ## Final thoughts Software development is an amazing field because it teaches people so much - problem-solving, discipline, creativity, logical thinking, and more. However, communication is often overlooked in a developer’s formation, making engineers struggle in team settings.

In my opinion, knowing how to collaborate is the driving force behind successful projects - there’s only as much we can do on our own but nothing seems impossible with the right people by your side.

That’s why improving communication skills and finding the right tools to stay connected with your team is one of the most worthwhile investments one can make.

To help tech teams communicate seamlessly without needing a physical office, we built oVice. It is a virtual office platform that brings engineers, project managers, and teammates from other departments together for status updates, discussions, and networking.

Leaders who use our spaces are confident that no employees are overlooked. Teammates use oVice to make the most out of their time at the company and not feel like they missed out on amazing connections.

I started working at oVice as an engineer and now help grow the product as an operations manager.

I am really proud of the work we are doing on the product and business side - if you want to check it out or consider creating a virtual office space for your team (which I highly recommend), visit our tour space.

Aligning technology and business goals: 5 lessons I learned after being on both sides

Young Soo Hwang — Mon, 11 Jul 2022 04:08:23 +0000

In the last 7 years, we’ve seen numerous failed tech releases - the time when Google released Allo or when Netflix updated its rating system making it more complicated and confusing than ever. Although backed by big names, they miss the mark and fail to drive revenue or operational changes.

For the most part, this happens because tech objectives and business goals are not aligned, there’s no bigger picture to show how specific innovations contribute to growth and development.

When I moved from an engineering to a management position at oVice, I had to flip the switch from focusing on the “how” to fully immersing myself in the “why” of product development. On that ongoing journey, I’ve learned several valuable lessons I’d like to share with team leaders and engineers.

Lesson #1. Start with the “why”

We’ve known it for decades - technology does wonders when it helps solve tangible problems - think Facebook (connecting with people you are no longer personally in touch with), Airbnb (sharing quick and affordable accommodation solutions in a crazy real estate market), or Uber (capitalizing on the sharing economy to improve mobility).

Yet, more often than not, you see managers requesting tech innovations because they are trendy or because competitors are massively adopting them. As the result, leaders request months of engineers’ productive time and a lot of resources only to create something they have no application or long-term vision for.

I developed several ways to fight the digital FOMO on my team and make sure I adopt technology when I need it, not when it is hot on the market:

Regularly reviewing client feedback and pinpointing ongoing problems. For example, a lot of our clients request new integrations for oVice. That’s why I can be confident that putting the time into building this feature is a worthwhile and intelligent way to use engineering resources. This reasoning equally applies to internal technology and tools. I regularly collect feedback from my team, discover loopholes in processes, write them down, and start looking for point-based solutions. When I approve the budget for innovation, I come back to the list of issues I identified and put more effort into solving those.
Setting expectations. It’s hard to determine whether a release succeeded or failed when you don’t know what “success” or “failure” mean to your team. That’s why I set benchmarks for every tech goal I have in mind - what feedback I want to get from the end-user, what internal change I expect, how much time I want the update to save, and so on. I recommend making these estimates as quantitative as possible.
Not making rash decisions. As I look around the market, now and then, a competitor with an intimidating and exciting feature appears, and I feel a sense of urgency, a need to catch up. Over time, I’ve learned to not trust this impulse and keep ideas on the backburner before putting them into development. Once the wave of excitement is off, I can calmly weigh all factors and make a rational, cold-headed decision - be it developing a new feature, changing the interface of the platform, or introducing a new internal tool to improve the efficiency of the team.

Lesson #2. Take the time to understand the basics of technology

As a tech-first manager, I had no issues with understanding the workings of product infrastructure when I became a manager. While I don’t think that having a degree and firsthand experience in product development is a must-have, I believe that understanding the building blocks of your project is essential for its success.

In my experience, exposure is one of the most powerful and organic ways to understand the basics of product development. I usually recommend the following types of resources:

Tech blogs and newsletters. These are great because, unlike books or papers, they are written in a layman’s language, constantly updated, and give you digestible nuggets of knowledge. My favorites are HackerNoon, Programming Digest (weekly newsletter), and this community on Dev.to.
Podcasts and Youtube channels. I love podcasts because they are seamless and easy to catch up on as you go about your day. As for YouTube channels, the visual component helps break concepts down, and reading the comments down the video helps you be part of the conversation and address your concerns.
Reddit threads. In my experience, understanding development goes hand in hand with understanding developers. Reddit threads give an unbiased view of how programmers reason, what they prioritize, the blockers they face, and the worries they share. Being on the same emotional wavelength with your tech team will make conversations more fluid and fruitful. I regularly check out r/programming, r/softwaredevelopment, r/dailyprogrammer, and other communities.

Lesson #3. Balance your trade-offs

Finding the balance between delivering an update on time and within a designated budget on the one hand and positive market reception on the other is challenging. In my case, I work for a startup - we are always in the race against time. If we take too much time to ship an update, someone else will do it and snatch the first-mover advantage.

On the other hand, “quick and dirty” releases are temporary and will have to be rebuilt, leading to redundant work at least and reputational damage at most.

Development costs come into play as well - in a startup, there are a lot of ways to allocate budgets, so you want to make sure you are not overspending or underfunding your release.

Balancing the three variables out is tricky but necessary - here’s how I go about it.

Capturing market signals. While I am against mindlessly hopping on the tech bandwagon, falling out of touch with the market and tuning out external risks and opportunities is equally damaging. For example, as I monitor supply and demand, I see that a lot of companies (including big names) are tapping into the niche of our project (collaboration for remote and hybrid work). I also see that there’s a surge of demand for hybrid work platforms - that means the engineering team has to, above all, be fast. From the tech perspective, I observe what features are vital to users - easy-to-use interface, stable connectivity, basic integrations - so I prioritize those.
Continuous delivery and testing. External market data is valuable but internal insight is priceless. To make sure I have a data backbone for making tech decisions, I am a huge proponent of continuous delivery. It allows the team to replace guesswork with data-driven analysis and know how the market reacts to our vision and ideas.
Thorough reporting. Taking the time to analyze past releases and see how much traction (be it awareness, revenue, or investor interest) our releases generate helps us understand how to allocate budget and time. Analyzing the roadmap immediately after and in the long run shows which decisions were the most impactful and how my team can reproduce them in the future.

Lesson #4. Understand the structure and responsibilities of tech team members

As a non-tech manager, I no longer contribute to building new features hands-on: instead, I have to delegate tasks and make decisions with the product team. The decision-makers must be involved every step of the way: missing out on the feedback of an important team member will lead to misalignment and miscommunication.

At the same time, I wouldn’t recommend burdening people with participating in discussions outside of their scope - there are better ways to allocate their time. That’s why understanding who is involved in making specific tech decisions and knowing who you should contact is crucial.

Here’s how I keep tabs on the organizational structure of the engineering team:

Use our organizational chart on Miro to stay up-to-date on people’s positions.
Have introductory calls with new team members to know what their role entails.
Share the upcoming call schedule and let people sign up to contribute - this way, teammates can decide whether they want to be included in the discussion.

Understanding the distribution of responsibilities within the engineering team will bring transparency and structure to identifying bottlenecks, getting status updates, and aligning operations.

Lesson #5. Leverage what you have before you create a new solution

Finally, as technology expands its reach and becomes ubiquitous, team leaders start seeing building new features, introducing innovation, or ramping up their internal toolset as the only possible answer.

Today’s startup community is largely technology-driven: buzzwords like AI, blockchain, and big data dominate. However, these are emerging fields with expensive talent so there’s no need to introduce innovation purely for the sake of generating awareness and growing buzz around the product.

To summarize:

Technology is not the only answer for** attracting investors**: business model and fitting the needs of the market are.
Technology is not the way to get press attention and generate awareness: building up a media presence, investing in search engine optimization, and creating unique customer experiences are.
Technology is not the only way to stand out among competitors: customer support, reasonable pricing, and the ability to address the pain points of the prospect are other alternatives leaders should consider. The feedback we get from oVice clients mentions stable infrastructure, security, and innovative tech as selection criteria but people are equally excited about an easy-to-understand billing mechanism and the ability to get step-by-step support from our team. Without the business model and the human component, tech alone could be not enough to tip the scales in our favor.

At its core, technology is a means, not the end itself. So, before they start looking for expensive talent and introducing groundbreaking features just for the sake of it, I’d like to ask managers: “Are you sure there aren’t other ways to reach the same objective?”.

At the same time, rather than building features or internal tools from scratch, you can find answers to tech problems by fine-tuning existing features or exploring open-access resources: plug-ins, libraries, and extensions.

Final words

As I worked both as an engineer and an operations manager on the business side of product development, I realized that business and technology cannot exist as separate entities. Innovation has to stem from clear business goals and see the end-user, not transitory metrics, as its key objective.

Another thing I’d like to mention is that checking in with the engineering team frequently and addressing concerns will help bridge the gap between tech workflows and business objectives. In my team, I do it in oVice - a virtual office space that connects hybrid and remote teams. Here, I can easily connect with the Global, Japanese, or Korean engineers and check that our goals are aligned.

If you are interested in the concept of a virtual office, read more about it here. If you want to talk to me or see the product in action, drop by my virtual office.

How I transitioned from engineering to management: 5 lessons I learned in the process

Young Soo Hwang — Fri, 24 Jun 2022 07:32:38 +0000

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.

Lesson #1. Management a drastically different job

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.

Lesson #2. You have to see everything through the business lens

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.

Lesson #3. Presenting your idea is almost as important as the idea itself

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.

Lesson #4. Technology is still my best friend

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

Lesson #5. You can learn leadership

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.

Where do I see myself in the future?

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.