Industry - Learning to lead a team [Part 1]
Since publishing my last newsletter, I've started leading a small team at work. I've learned many things about team leadership since then. I'll break this down into two parts: “How does a team come about?” and “What skills have I learned leading a team?”
Team forms to fulfill these needs:
Enabling Scale and Growth: Teams form for different reasons, though some are more common than others. Our team exists because we need to scale. As our organization grows (here organization refers to the broader umbrella I belong to), we’re expected to support more customers, making it crucial to have more than one person (myself) doing analysis work. Our team formed to multiply our analysis capacity. This purpose-driven team differs from organization-oriented teams, such as those formed by people reporting to the same manager.
Developing for Long-term: People doing similar work don’t necessarily need to form a team. However, certain goals are hard to achieve without a structured team. Since last year, our management tried bringing in teammates to free up my time for more scientific research. I quickly realized that while we could handle more incoming requests (short-term tasks), we were very slow in completing analysis “development” tasks (long-term tasks). I learned that a group of people without structured collaboration doesn’t make a team. Events like team planning sessions are critical to align not only what each person should do in the following weeks but also ensuring our approach brings us closer to our long-term goals. (Individual long-term trajectories rarely align without regular synchronization.)
Centralizing for Visibility and Trust: This became the most critical and unexpected reason. While my immediate reaction to increased workload was to request more people, I realized these helpers were often assigned unrelated tasks from other people from the organization. After discussing this situation with management, I discovered that the best way to protect our analysis time was to centralize information, help the broader organization better understand our mission, and earn their trust in our priority-based decisions, e.g., tell them to wait because we cannot sacrifice the “not urgent but important” tasks.
In my case, I participated in identifying and addressing all three needs. Here’s what I did to form a team:
Many people in our organization (including myself) identified various opportunities we could support by scaling. This made the first need obvious.
Having a concrete long-term plan was critical for recruiting and team formation. Writing roadmap documents for the analysis work helped me gain clarity about upcoming tasks and demonstrate to management that I could effectively utilize new team members.
While the first two steps apply to any project regardless of scope or team size, the last piece was specific to group formation. Even if we have the best roadmap, people (especially managers of our team members) might still lack visibility into their direct reports’ work. This makes it difficult for managers to help protect our team members’ time for our needs. Therefore, I spent time with managers understanding how to best centralize information and provide appropriate visibility, ensuring they felt comfortable supporting our team needs and trusting our ability to deliver on promises to the broader organization. While we use standard formats like weekly meetings and ticketing systems, the key is the information conveyed through these channels.
Though I’m still a complete beginner in this area, I’ve learned valuable lessons along the way. I’ll share about “the skills I’ve learned leading a team” next time!
Robotics - Shooting vs collocation in controls
Another annoying thing to admit, as someone who did motion planning, I was not familiar with the terminology “shooting” and “collocation.” As I search on the internet (p.s. no AI agent is good at explaining this), I come across this lecture series that explains optimal control nicely! (Advanced Robotics at UC Berkeley) The detailed explanation is here [video] (the view of the video is messed up here, but the lecturer is referring to the figure below).
For someone who has experience about optimization, you will realize that these two formulations should give you the same optimal solution. So why bother? The answer is that collocation formulation has better “conditioning.” A high-level way to understand it is that good conditioning means the problem solution is less sensitive to small changes (i.e., small changes in input → small changes in output). This comes at a cost of having more decision variables (the list under “min”) to solve for. Will share more once I dive deeper!