When I joined Clever as a software engineer in Summer of 2018, I didn’t have an answer to the quintessential question “Where do you see yourself in 5 years? In 10 years?” I simply wanted to join a company that was having an extraordinary impact on technology in education and was so excited to be a part of that effort.
The decision to become an engineering manager
Fast forward to the beginning of the pandemic and Clever’s product and customer base was growing faster and bigger than we had ever anticipated. I had started to think about widening my impact as a software engineer, and had plans to apply for the intern manager position for that Summer. (Sidenote, at Clever, an individual contributor engineer is given the opportunity to dip their toes into the world of management by managing our cohort of interns for 3 months.)
While thinking about this move, another opportunity arose for me to take over and manage the team I was on instead. I thought to myself, “why not?” I knew that I would have all the support I needed to transition into this role and that, if it didn’t end up working out as the next step in my career, I would be able to return back to being an individual contributor with no hard feelings. It seemed like the perfect time and opportunity for me to expand my impact at Clever and with my career.
Now, it has been a little over a year since I became the manager of Secure Sync, the same team I joined when I first started as a software engineer, and I couldn’t be more grateful for all that I have learned and grown this past year. Not only did I learn what it’s like to manage a core product team, but also what it takes to manage a distributed team as well. Here are some of my biggest takeaways throughout this past year.
How to give and invite effective feedback
As I got started in being a manager, one question I found myself asking constantly was “Am I doing a good job?” The success metrics of being a manager were more opaque and nuanced than what I was used to: write the code, ship the product, fix the bugs. So, I relied on the people on my team and my peers around me to tell me whether I was doing my job well. At the end of the day, they are the ones who are directly impacted by my performance.
When asking for feedback, it is important to be specific about what you are looking for, beyond just a general “How am I doing?” The more specific you are, the more specific your feedback will be, and you avoid the general response of “Keep it up!” so you can actually get meaningful responses in return. Some examples of my feedback requests include
- I’ve been working on making sure meeting agendas are well structured at the beginning of team meetings. Can you provide me feedback on how the last two team meetings went in this area?
- During the last rollout of our new API version launch, I was focusing on making sure all non-eng stakeholders were involved. As a non-eng stakeholder on the project, did you feel fully informed throughout the rollout process? Anything else I could have done that would have made it easier for you?
On the other hand, I also learned how to give effective feedback. I learned that it is never worthwhile to beat around the bush when giving constructive feedback, because it simply throws people off-guard and distracts them from the core message. It is also important to give feedback consistently and often. At Clever, we practice giving continuous feedback, and even unsolicited feedback, because if a person is surprised by their performance review at the end of the year, then something has gone wrong. You’ll hear the term “Radical Candor” in the office sometimes, it’s a management philosophy of Caring Personally while Challenging Directly. This concept has been steadfast amongst leaders at Clever and especially comes to light when Cleverites give and receive feedback.
Mastering communication across the team
On the topic of continuous feedback, I have learned how essential good communication is. Communication happens with many different groups of people at Clever for me: the team, Product Manager and Designer, my manager, my manager’s manager and VP of Engineering, customer-facing teams, managers of other teams, so on and so forth. I have found it helpful to set up recurring meetings with teams that we frequently interface with to create space to address critical rollouts, feature changes, or personnel changes that are happening and to communicate them so other teams can plan accordingly.
I have also iterated the importance of communication to my team. Some points where I found an engineer’s communication to be extra important are:
- When the timeline on a project starts to slip. If we know as early as possible, we can work on a backup plan together.
- When a project is very inter-departmental and there are many non-eng stakeholders involved. We always set up recurring meetings with all stakeholders to keep everyone up-to-date on progress.
- When there are things I can do to help our team or the engineer be more successful. I am the sword and shield of the team and the engineers on it, and we are able to achieve the most when someone is direct with me about their wants and needs.
Shift focus from project management to people management
As an engineering manager at Clever, I have shifted my focus on what it means to be a leader in engineering from project management to people management. I led quite a few projects as an individual contributor at Clever, most of which had multiple engineers working on them. But I have come to realize that the way I worked with others on the team as a TL is very different from the way I work with others now. Rather than focusing on the project at hand, including deadlines, rollout plans, and reducing bugs post launch, I focus on the people on my team. As a manager, my mission is to create a working environment that encourages everyone to do their best work. With the trust that I have already cultivated with my engineers who used to be my peers, I believe the project management done by TLs on the team will then come naturally.
Plus, with multiple projects going on at once at any given time on the Secure Sync team, it would be impossible for me to keep up with all of them closely. Delegation at this point is very important, and a great way for the folks on my team to take on more responsibility in areas that will offer them growth opportunities.
Be ok with saying “I don’t know.”
As a first-time manager, I was accustomed to serving as the expert in my roles as an individual contributor. Most often, when people transition from individual contributor to management within an organization, it’s their technical expertise on the team that put them in a position to become a manager. However, letting go of this part of my workplace persona was extremely important, if not also very difficult. I realized that the rules of success have changed as a manager, there is less emphasis on my specialized knowledge and more placed on my ability to deliver results through others. In fact, acting as the expert will not only slow the team down, but also cause team members to feel devalued by my insistence on supplying the final answer. This is why I have come to value the phrase “I don’t know” in two main scenarios:
- When a decision needs to be made or a team member reaches out for guidance, the most important response I can give is not an answer, but instead “I’m not sure, what do you think we/you should do?” Even when the answer is obvious to me, I always give others a chance to give ideas or suggestions, because it could very much be way better than my answer. By doing so, I show that I value everyone’s ideas on the team, and that people shouldn’t think I always have the “right” answer or the “final” answer.
- Sometimes I honestly just don’t know. When I first started managing, I was so scared to admit that I didn’t know anything about a lot of things that came my way. When faced with a high degree of ambiguity in my new role, I naturally wanted to revert to what has worked historically, drawing upon my specialized knowledge as an individual contributor. However, most of the time I either provided solutions that were subpar by forcing myself to seem like I knew what I was talking about, or dug myself into a deeper hole by not reaching out for help. None of these got me toward fixing the problem. I have since learned that it’s a positive trait to be able to admit that “I don’t know” and work together with others to find the solution.
Of course, learning in the world of management is neverending. I am comforted by the fact that my team will always be there to give me the feedback I need to continuously improve as a manager. Clever has made this transition an incredibly meaningful one. It is truly a place where you can expand your career beyond what you’ve imagined. If you are interested in a career where you can grow quickly beyond your expectations, consider joining our Engineering team here at Clever!