People Management Unplugged: Real Talk, Real Results

The first thing that you will notice when having one-on-ones with people, especially in Filipino culture, they don't often share. They often say, "It's okay." "How was the sprint?" "It was okay." That sort of thing. The best practices in such a case are really just good communication practices, sometimes even just good conversational practices. So probe a lot more.

Have a good list of the typical pain points that affect the team. For example, you know that ticket quality is not always perfect. You know there are typical technical issues. Ask pointed questions: How was the ticket quality this sprint? Were there any technical issues? Did you have problems dealing with certain people? When you ask pointed questions like that, they start to think about things that concretely happened, and that gets the stories going. The conversation flows and they're much more relaxed.

Offer an environment that's very engaging and very safe. Make sure confidentiality is paramount, so they know that anything they share, they can share freely. When the conversation is free-flowing, that's where you see what happened during the sprint, what the real pain points were. You see it in their communication styles: what exactly strikes a nerve, and what went well. Be sure to ask about the positives as well.

Then follow up. It's just conversational practice. Echo: repeat their language back to them. If they say, "Something happened that wasn't so okay," you just ask, "Ah, not so okay?" And of their own accord, they'll bring out the issues. So I find it's really just good conversational practice in general.

What I can say is, sooner or later, you'll reach a point where you need to manage or to talk to other people. Being an individual contributor, at least for me: I really love developing. I really love coding. But at some point, you'll reach a point where you need to talk to other people for you to grow and for you to learn. And usually, these experiences are not something we get from coding alone. We need to understand how team members work, how we should communicate our deliverables, how we manage deadlines and the project.

So overall, what I can say to the ICs out there who've been at it for a long time: try doing people management. It will help you grow as a person.

It's very similar to what happened to the current engineers in Angkas. We have an existing system that we wanted to maintain, and the responsibility and ownership was transferred completely to us. One of the first steps for me is to change the mindset of the members that this code is yours to maintain and to grow. Because some engineers don't want to dig into the code, since it's not theirs in the first place. So we need to fix the mindset.

Secondly, once you fix the mindset, it becomes easier for people to find things in that existing codebase and figure out how to fix them, and to know it like the back of their hand. Eventually the challenges become easier once you change the mindset.

From my personal experience managing underperforming individuals: first, you have to define the metric of the expected performance, right? Then, based on that metric, if I see that this person isn't performing to expectations that were well communicated, I need to have a one-on-one with them. Ideally it's biweekly, but I don't have to wait for that one-on-one. When I see they're not performing according to expectations, I meet with them and tell them.

First, come from a place of curiosity. Maybe something is going on with their life. Maybe something is bothering them and affecting their performance. In that case, we want to have empathy. But we also need to set boundaries, and some leeway, because we are here to perform, right? We're not a family; we are a team, and we have deliveries to reach. So really just have an honest talk with them. Give them a timeline to see changes in their performance, and if they don't reach it, deliver the decision that we have to let the person go. But as much as possible, be present, coach the individual, and provide the support that they need.

In inheriting an existing engineering team, I think the important part is knowing every team member: their character, their attitude, their skills, and especially the current culture of that team. After that, you need to decide how you're going to integrate yourself into their existing practices. You can't put any changes immediately because maybe they'll get culture shock. So you'll just need to adapt gradually: introduce new rules, introduce new standards. I think the most important thing is blending in.

I've actually experienced that. When I joined a previous company, I was the only developer at the time, and a lot of technical debt was coming up while we were doing the project. In my opinion, the best thing we did was this: every time we would do a sprint, we have a specific ticket for refactoring. Every time we touch something, it's a must that you refactor the specific component you touched while doing the feature.

Another thing that was effective, at another company, was a Friday hackathon. It was basically about addressing the tech debt that was really prominent or really affecting the project. Those are the things that really helped us.

For that, I need to learn deeply the architectural structure of the company for me to decide what resources would properly fit in and what roles do we need. And then incorporate the team's and the company's goals in parallel, which would eventually translate to the success of the team and the company.

I think the point is this: all companies are being pressured to grow, and you cannot support your operations if you are not growing. People, especially executives and leaders, are being pressured to grow their businesses. From a startup, even if you're already mature: what's the next level of growth for your organization?