2023 was a year of testing my abilities as I transitioned to a new team.
Looking back, I had many new experiences, but there were also moments I wish had gone differently.
Leading Team Culture
This year, I spent a lot of time building and leading team culture after joining a new team.
My manager assigned me to this team, saying, “It’s one thing to join a team with a great culture and another to build one from scratch. Leading in a place without culture is a valuable experience.”
When I first joined, the state of team culture felt discouraging. However, as the year progressed, I realized this was a chance for me to learn how to lead and shape a team culture.
Building a Review Culture
When I first joined, even basic code review practices weren’t in place.
My initial goal was to establish a proper review culture. Here’s how I approached it.
- Conducted discussions and retrospectives on review speed and quality.
- Created review ground rules.
- Introduced reviews not just for code but also for operations and documentation.
Improving Communication
I focused heavily on improving communication within our team.
- Encouraged more conversations via Slack.
- Introduced “reaction culture” asking team members to respond to messages using Slack reactions or threads.
- Used small talk to lighten the mood and improve team dynamics. It could just my natural style.
While there were challenges due to differences in perspectives among team members, we made progress in creating a safer environment for open discussions.
Sprint
One of the biggest changes I’ve made is improving the way our team handles sprints. Previously, the team leader assigned tasks, and members worked independently without much collaboration.
I introduced new practices.
- Rotating sprint leadership among team members.
- Changing sprint cycles, meeting formats, and documentation methods.
- Incorporating sprint retrospectives, story point estimation, and task breakdowns.
I’m not a leader, but I had to change team culture. Because of this, it went slower than I thought. Still, it was good that our team leader gave me an answer with “anything okay” when I gave a suggestion about the team culture.
I felt again that the leader is important because I saw some people around me struggling as a leader who wanted “anything as it is” in a similar situation to me.
From this experience, I learned that building a great team takes time. While we’ve made significant progress, but there’s still room for improvement.
New Service
Switching from sync server to backup server was a new challenge.
I realized I adapt to new domains faster than I’d expected. Reflecting on recent design meetings, I noticed that I’ve been explaining concepts to others rather than asking questions to others.
Backup and synchronization were similar, but there were different policies, and I’ll write this down later.
While I expanded my expertise from sync to backup, I regret not exploring new technologies like gRPC due to the heavy demands of backup service development.
Refactoring
It’s refactoring, which I do every day, but this year I’ve thought about refactoring again.
The new service had so many legacy codes that there were many things to touch. I think I’ve always had refactoring in everything I’ve done with my existing code.
I’ve already done so many big refactoring in my previous team that it felt like a boring task.
The part leader gave me a comment to organize more solidly about the refactoring, and I think it’s time to organize my thoughts on the refactoring.
This year I tackled broader changes, including
Big Refactoring
Martin Fowler calls large-scale refactoring that affects a wide part of a project “big refactoring”, rather than just fixing code smells while developing features.
Most refactoring discussions focus on techniques, so I organized my thoughts on what to consider in big refactoring here.
I also spent time removing various types of unused code, realizing that eliminating such code is beneficial.
Cost-Aware Refactoring
During big refactoring, I sometimes redesign key architecture or messaging methods.
This year, I started considering cost in these designs, which was a new approach for me.
Managing a service that handles billions of API calls per day, I have a lot to think about the cost. I was thinking about whether to put SQS between modules, but when I calculated the cost, it became a billion unit per year with just one additional SQS and changed the design. One of the team members suggested the idea during the design meeting. As one of the reasons against it, I also presented the calculation of the billions of S3 costs added when applying the idea.
I had considered costs before, but naturally using cost calculations as a basis for design decisions and objections made me realize I’ve grown in refactoring and architecture.
MSA
Looking back at the features I’ve been busy adding, I feel I missed opportunities to break our large monolithic service into smaller parts.
I discussed MSA with a senior colleague, and in hindsight, I see cases where MSA would have been a better choice. Especially after reading a book How to Adopt Microservices, I regret not transitioning gradually to MSA.
I handle a lot of the system design in my team, and I now realize that at the beginning of the year, I didn’t fully understand the benefits of MSA or how to transition from monolith to MSA. That lack of understanding led me to miss designing a better system, which I find disappointing.
Speaking Opportunities
I had the chance to speak about slack automation bots at two events this year:
These experiences were both fun and fulfilling, and I hope to create more opportunities like this in the future.
There was a lot of time to think about leadership this year.
I first thought about the part leader’s role in rearranging the team and motivating through interviews.
And I think now I could see the atmosphere of the team. and the atmosphere made by the attitudes of the former team leader, the current team leader, and other team leaders.
And as I led the team culture, meetings, and design, I thought more about the leader.
It was a year where I had many new experiences.
Two speaker experience, new roles taken after moving to a new team.
It’s a pity that I couldn’t have the experience of developing new technologies that I expected, but I think I’ve pulled off new roles well.
Although it is a small team, it was fun to work in a position where I lead team culture and design. I think it fits for me better than I thought.