brunch

라이킷 11 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Rapha Apr 24. 2023

Software Development Manager

Smart Coupangpay developer life

Start

Coupang Pay has a role called SDM (Software Development Manger). I would like to introduce why this role was created, what it does, and what makes it different from general managers. For reference, I am currently serving as an SDM in Coupang Pay.

Was SDM really necessary?

When I first joined the company, there were about 15 to 20 engineers. At this time, there was about one person who looked like a development manager, and this person was also an engineer who was quite good at developing. Coupang basically pursued a horizontal organization that minimized the role of manager, while solving technical challenges with Tech Leaders for each domain.

Let me give you a few representative examples.

The development manager's workload increased and reached its limit. One of the most important things in a development manager's job is to identify requirements or problems and lead them to the desired destination. It became. There were too many engineers, organizations, and domains for one manager to handle. “I wish I had 3 people!” was heard.

It is relatively difficult to secure development time because engineers have to attend many meetings. The advantage is that engineers attend all decision-making meetings, so they know exactly who they are for, why they are developing, what problems they are trying to solve, etc., without having to explain. As for the downside, there was not enough time for development to the point of saying, "So when are you going to implement it?" There have been times like this. After talking loudly for a while, "But who develops this? The solution is enough, but who develops it?" I once looked at my phone with slightly sleepy eyes. As the number of domains increased, it was not efficient for all developers to attend all meetings, and someone had to take the lead and turn this inefficiency into efficiency.

Because it is an agile and passionate organization, decision-making was also quick. At some point, engineers waited for a decision to be made, and there were also cases where they proceeded with redevelopment without making the right decision.

Besides this, there were other minor problems.

I don't know exactly what goals my manager set and created the role of SDM at the time, but I recall like this.

"Let's work more efficiently to achieve organizational goals! Let's try it out, see if it's the right way, and fix any problems."

I don't want to... I don't want to...

Engineers hold a meeting every two weeks to decide what to do. There was a culture where people took what they wanted to do whenever possible. Sometimes there were things the engineers didn't take, but at this time, "If I feel like I have to do something, I do it." There was a saying. I can't exactly define what engineers don't take. There were a lot of things that seemed difficult, things that no one wanted to do, things that didn't show up, things that seemed like they would be challenged a lot during code review. At this time, for some reason, I felt the atmosphere of the engineers wanting me, and I remember saying "I will do it" at that time.

I think it was similar to the situation when I went to the head of the organization and said that I would become an SDM. My mind was complicated. Coding was still fun, and I thought there were many things I needed to know more about technically. On the one hand, the organization was growing, and the few SDMs were beginning to struggle.

Suddenly, I had this thought.

Wouldn't it be possible to look at the service from a wider perspective by using the time given to me while giving up coding? Others say to see the forest, but I liked seeing the trees. Isn't it said that smoking is not about quitting, but about holding back? It's a pity, but let's say goodbye to coding for a while.

I want to become one with engineers and experience more services.

I want to do well in this field like the manager I think is cool.

There must be another value that I couldn't feel as an engineer while doing SDM.

It was hard until I made up my mind, but after that it was easy. I sometimes had a desire to code, but I was overwhelmed just by getting the job done.

Everything except coding.

It's real. Everything except coding. We work with engineers in almost every field from the software development and operation point of view.

Since SDM is not just a manager, it is natural to be curious about software and ask many questions. When a failure occurs, take the lead to find the cause and solve it together with engineers. Since there are many processes from developing software to launching it, it is impossible to explain everything, but it seemed the most appropriate word to say that everything was done except coding. Let's talk about what CoupangPay SDMs value.

Engineering rather than management

If a manager who simply manages schedules and resources or blindly pursues the boss's orders was needed, why would a manager with rich development experience be needed? It won't be.

When it comes to questions about who our software is for and what problems it is trying to solve, SDMs need to be clear. Based on this, we lead the software we create to go the right way.

Rather than detail, understand the whole, and after understanding the whole, go into the details. If you look inside the software, there are many things such as algorithms, handling of exceptions, data exchanged by API, concerns about stability, and so on. "I have to code self to know these details, but what if someone asks? I'm worried." After becoming SDM, I worried about this for several months. These worries are still there from time to time. :) By the way, even when I was an engineer, I thought, did I understand all the code? My strategy was to understand the whole rather than go into details, and then get into the details once you understand the whole. Because Coupang Pay is a very nimble organization, we often talk to each other rather than write documents. In addition to the engineering organization, SDMs also play a leading role so that other organizations can make the right decisions.

Table talk - A deep understanding of software solves many problems and plays a key role in making the right decisions. I've seen many companies spend a lot of time in meaningless meetings. what a waste of time Even worse is waste due to bad decision making. Time spent discussing with engineers, designing, and making good software is the most valuable.

Hire good people and do things with few rules.

When you joined the company, was there a time when you thought, "How did they gather such talented people!"? Usually only one or two engineers stood out, but almost all were good. If it was only clear what to do and why, the meeting of engineers quickly heated up. I only said a word about what we should make, but at the meeting, everything we had to implement, what to look into in more depth, what to test, and even the release schedule were all provided. Rather than managing them, I breathe with them and obsess over the problem. Instead of making rules, we observe the creativity of engineers from the sidelines and keep raising the topic of what to do.

Don't build a team that won't do anything without you.

From the time I became SDM, I wanted to make about two engineers to replace me. In my previous company, I actually had experience. I went on vacation for about 2 days after opening the service, but I had a disability. The downtime only got longer and there was no sign of resolving it. One of the problems was that there were many things that only one person knew and could solve alone without delegating the task. My goal is not for just two people, but for all team members to be engineers who think and act for themselves. I hope the team members grow as each month or year passes.

When I create a team that works well without me, I will work on a different level. The manager I thought I was cool in front of me personally showed me this, and now he is working on a bigger level.

Nothing just happens. You need to know when to make waves.

If you do nothing, nothing happens. For example, while operating, there are many additional things to do, but there are cases in which priorities are pushed or the necessity is low.

Even if Full GC or Minor GC (GC - Garbage Collection) occurs from time to time, it returns to normal immediately, so we do not look closely. During development, we develop so that if there is a problem, we notify the problem, and we build to monitor various basic system resources. Because of this, we are inevitably aware of software's sore spots, but we tend to observe them from time to time.

Data is manually extracted and provided on a regular basis. - Engineers should hate manual work and should build and provide tools to do it themselves.

Hesitant to review architecture. Engineers usually like to develop and are uncomfortable sharing.

FrontEnd technology trends change frequently, also BackEnd technology trends also have good attempts in various fields and sometimes need to be boldly introduced. Rather than insisting on the previous one, we need an attitude of taking on challenges. Only then can we go one step further.

Even if every cell in your body tells you not to do it, you have to make waves.

Influence without Authority

There were managers who tried to make decisions based on authority rather than rational grounds. I think it's rare these days. It has already been proven that this method has failed. It may work temporarily, but bad decisions soon come back like boomerangs, ruining a business or causing a lot of waste. The future is not bright for companies with many managers who assert their authority. An understanding of data, business and software is required to make rational decisions. Of course, Just because you're a manager doesn't mean you get those skills for free. You have to be nervous, you have to be serious, and you have to study all the time. And one more thing, you need to keep talking to the engineers.