Hello! What's your background and what do you do?
My name is Tomek, I’m the CEO & Founder of codebeat, codequest, and most recently, hay.
My forays into programming began with a language called, Turbo Pascal (Remember that one? 😂) I later went on to pursue finance and banking at the Warsaw School of Economics. After the fall of communism, this was a promising sector, so I jumped on the bandwagon and followed the crowd. However, my passion for coding never went away, and I eventually got a degree in management and information systems, learning how to properly code in Delphi. I also became a huge fan of Java during that time.
After graduating, I worked as a software engineer for various big corporations, including Big Pharma. The next step up for me was when I joined Polar Rose, a facial recognition startup bought by Apple. Upon acquisition, instead of moving to California with some of my colleagues, I stayed back and founded codequest, a software studio that focuses on building web and mobile applications. I'm also passionate about machine learning and plan to build a dedicated team to help our customers benefit from different AI services and methods.
How was your transition from software development to management like?
Like most software engineers, I started my career taking the technical path. After six years of being an individual contributor, I was promoted as manager at Polar Rose. My boss noticed I had people skills and that I had a natural ability to organize people and efficiently make use of project resources.
The transition wasn’t easy. I was thrown into the lion’s den with little or no experience. The peopleware aspect of development was foreign to me, so I followed my gut instinct and made many mistakes along the way. Soon I realized that being a boss is a profession, not a calling or a reward for merit.
Though “learn as you go” might be a great way to move forward in your position, it’s not the best strategy when you’re trying to balance managing a team and scaling a company. That was exactly one of my biggest regrets - not preparing myself for the situations engineering managers face but learning how to deal with them as they came.
What does your day-to-day work look like, and what motivates you to do it every day?
I don’t write code anymore, but if the situation calls for it, I’ll get my hands dirty 😆 Most of the time, however, I’m on meetings and making decisions that ensure my teams are happy and have nothing that stops them from doing their best work. I usually address these points in all-hands meetings or in 1:1 meetings.
The 1:1 meeting for me is the most crucial meeting. They have always been challenging to run because when you’re giving feedback, rewarding your developer, or solving an issue, the relationship may change, especially when a salary is involved.
Also, in my experience, contexts constantly change, so I need to have the tools ready to solve these and many other problems. People expect that from you; you owe it to your developers.
In recent years, I made a huge effort to treat 1:1s as a springboard for my developers’ success. The challenge was to find a balance between discussing productivity with happiness. I wanted my developers to feel great working on cool projects using the newest technology. My goal was also to run fair and transparent assessments that were free from ego and based on data and objective principles. I tend to focus on four core aspects like work output, wellbeing, team feedback, and personal growth.
What's the best advice you've received about being a manager?
Practice boss ceremonies and learn how to run 1:1s and performance reviews. Being an engineering manager is a role, it’s a job you need to perform. The best advice I got was in a book written by Kim Scott. She stresses the importance of being honest, calling things what they are, and avoiding being too empathetic.
What do you tell developers who are considering making the switch or new to the role?
It’s an awesome journey, very multidimensional, but it’s more complex than being an individual contributor. In my opinion, it’s easier to be happy and content with your work as an individual contributor; it’s easier to get into the flow and get that necessary shot of dopamine when you realize that your code is really good and works perfectly. But being an engineering manager brings another kind of happiness — you get happy when you build a system or a process where the people who play an important role in it are happy. Your gratification (and shot of dopamine) come after.
Final call to action! Where can we go to learn more about you?
I recently started a venture where we help young engineering managers become more effective at their job through role-playing workshops. I’ve also developed a tool that helps managers manage the happiness and wellbeing of their developers. You can read about all this in our blog here.