After 12 years as a JavaScript developer in client services and product development Kahlil moved into management. For the last 2.5 years, he has been leading frontend teams at GoTo. Kahlil hopes to continuously grow to be a better leader and create a positive impact together with the teams he works with. He likes to spend his free time with his family, improving his writing, listening to podcasts, and reading books.
Exaltitude newsletter is packed with advice for navigating your engineering career journey successfully. Sign up to stay tuned!
Writing. They should be a good communicator in the written and the spoken word. Writing improves your thinking, and a developer needs to think clearly about problems all the time. At the same time, writing is important to document things for posterity, be it how-tos, decisions, or just meeting notes. Writing has a positive compounding effect on the writer and on the people consuming the writing.
Collaboration. Being willing and eager to collaborate is important in order to make a team more than the sum of its members. Support other engineers, transfer knowledge and solve problems together. It allows the individual team members to grow faster and the whole team to produce incredible results.
Empathy. Understanding where the other person is coming from is essential for respectful communication and for collaborating effectively.
Pragmatism. Accept the constraints of the situation. Oftentimes, developers are unhappy with certain circumstances in the organization or with the current state of the code or the infrastructure and/or the requirements for the current task. Some of these constraints are immovable, and it can be a distraction to get hung up with them. Focusing on solving the problem within the current constraints produces the best results for the organization and will be rewarded appropriately.
Curiosity. They should ask questions all the time. Find out as much as possible about the company, the system architecture, and the politics, and get context on everything. This has positive compounding effects over time, will inform decisions the developer makes and gives them leverage for creating their own path and career in the organization.
Long-term thinking. This quality can help a developer make sure software evolves well over time. It can help a developer or a group of developers to cause change in an organization that is more hesitant to change by coming up with a strategy and relentlessly pushing that agenda.
The transition from individual contributor to engineering manager is not a promotion; it is a career reset. It took me a while to understand that.
There is so much to learn when you first start. You ask yourself, what is the manager's job really? Are there any frameworks to do this work? Help! I am drowning in meetings!
Typically there is incredibly little guidance on doing this job, let alone a proper onboarding. Some people are just good managers because it comes naturally to them, and they don't even know why they are effective. Where do you turn to to learn about this job?
Many books become very philosophical or abstract. I think what someone needs who just turned manager from an IC needs a definition of the manager's job and solid frameworks that help them structure their work and make them as effective as possible right out of the gate.
I was very happy when I finally found that in the book “The Effective Manager” by Mark Horstman.
After that, there is still lifelong learning, but it's good to get a solid start.
So, needless to say, the transition was bumpy, but I did learn a lot, and I feel like I am starting to get the hang of it.
Work-life balance at GoTo is great in general. I typically work 8 to 9 hours a workday and then shut off the computer. I work from home, and when I’m off work, it’s my turn to take care of our daughter. I play with her, make dinner for the family and take her to bed.
Here is a nugget about shutting off work when working from home. I got it from my friend and fellow engineering manager Daniel Hauck:
It can be hard to switch off work-mode after you get up from your desk because there is no built-in wind-down.
To create a way to transition from work-mode into home-mode you can set yourself a recurring todo for the end of the workday that is called "Shutdown" and looks something like this:
Anything that you need to get off your chest or what you want to reflect on? Who have you met today? How did the interactions go? Did you give your best in everything that you did? Did you play with best intentions? If you die tonight would this be a good last day?
- Got 1% better?
- Shutdown completed
This allows you to process your workday and to shut down work-mode.
Don't take your work home.
The first two years were challenging. And it seems like dealing with very challenging situations is just the engineering manager's job.
Typically, the basic tools and frameworks you have access to as a manager and that make you effective at your job are not taught to new managers in a structured way.
This was also the case for me. It was difficult to understand what the essential skills and tools are that a manager needs to learn to be effective vs. to be effective as an individual contributor.
After some time, I muddled my way through various sources. I formed a better understanding of what the manager's job is from first principles and how to use the systems available to an engineering manager to become more effective at my job.
The book I mentioned above was very important for me in regards to this. It provides systems for running 1-on-1s, giving feedback, coaching and delegating that are backed by real experience and data collected over many years. Understanding this information and using it allowed me to bring a certain structure into my job. This provides a great base for dealing with the ongoing challenges at my job and building and growing as a leader.
Another way to introduce structure into the manager's job is to start running your day. I wrote a blog post about this over here. As an engineer, I was used to optimizing for flow time, working on tickets, and coding. As a manager, you have to make sure you run your day, structure it with intent, and make sure you have time to think and strategize in-between meetings; otherwise, meetings just overrun you.
When I started with 1-on-1s, I started out mimicking my previous manager's model, which was 45min every two weeks. It didn't work well for him and did not work well for me either. Even though they are not skipped often, when it happens, you just have too long of a pause in-between, and you lose touch with the team member.
This is the Manager Tools model for 1-on-1s in a nutshell, which works very well for me and it would have been great to know about this from the beginning:
Exaltitude newsletter is packed with advice for navigating your engineering career journey successfully. Sign up to stay tuned!
.png)
.png)
