A Day in the Life of a Tech Leader
How will your workday change if you go into leadership?
Have you ever wondered what your life would look like after becoming an engineering leader? Today, we have Nikola Sobadjiev from HipsterTech to share his experience.
I hope you like the insights in today’s post. Feel free to share your views and comments below!
Let’s start
So you are considering advancing your career into leadership? That’s great! Leading engineering teams can be an incredibly fulfilling endeavour and it’s an opportunity to make a real difference within a company.
That being said, what would actually change in your life if you made that jump? What would your day look like?
We all know going into leadership can be glamorous - there’s more power and the prestige that come along with it. But most benefits come at a price…
What’s the price you need to pay?
Different worlds
Adler and I “earned our stripes“ in very different ways. Adler did it in the more conventional way - by being promoted, now being an engineering manager. I, on the other hand, was too eager and I skipped the line by taking over a CTO position in a very early startup together with people I knew.
These two options lead to somewhat different experiences, especially at the beginning of the journey.
My Case - Building a Company from 0 to 1
Building a tech company from the ground up can feel overwhelming. All of a sudden, the safety wheels are off and there’s no one to catch you if you fall make bad choices. It can be freeing to start on a clean slate and not inherit some sort of legacy. But, oh, boy, does it feel lonely and frustrating to not have anyone to help out if you’re stuck. And you don’t even have to actually get stuck on something. The sheer feeling of having no one behind your back is painful.
Apart from that, this option can be more straightforward in other ways. In the beginning, you will be either alone or with 1-2 other people in the technical area, and you will find yourself writing way more code than you used to. In a startup, you can rarely hide behind meetings and team members - if you don’t write the code, the code will not be there. With no code, there’s no product. With no product, your days are numbered - you get the idea.
Later on, if you’re lucky, you can start hiring, and you can build a team of engineers and build a whole organisation around them. If you scale up enough, you will dig yourself out of the scrappy startup world, and your job might be more and more similar to the one of people that chose to climb the corporate ladder.
Which brings up to…
Adler’s Case - Becoming an Engineering Manager
Adler followed the traditional path of moving to the management path in a corporate company.
Throughout these years, he found himself very excited about organizational changes. For example: adding a new role, changing the evaluation framework, or splitting the team. One day he started to wonder that he might be more interested in moving to the management path than he thought. He expressed my interest to his manager; fortunately, the manager was very supportive.
They created a training plan together. It took around one year before he got recognition from the management members. Toward the end of the training, his manager left, and he took over his role.
You can check the full story here:
So, if you still want to embark on a similar journey, you should know what the actual job involves.
Your Life as a Manager
Most of us are expected to choose a profession or a path in life or accept a job offer without ever knowing what that choice looks like on a daily basis. It’s not the best way to make an informed decision, if you ask me.
This is precisely the reason Adler and I decided to address that topic for becoming a manager.
Here are a few things that will probably change for you if you become a manager, together with some advice from us on how to deal with them.
Continuing to Write Code as a Manager
If you are even considering staying hands-on in development, you can already pat yourself on the back. It’s a good thing. Managers that still write code get a lot of respect. From the point of view of individual contributors, who would you trust more - the old guy that hasn’t written a line of code in 10 years, or someone who understands all tasks being worked on and how they are implemented?
If you join a startup, this one is a solved problem. You will need to write code, even more than before. It’s just how it is - you have to wear many hats if you work in a small team.
Team leaders and engineering managers, on the other hand, are often struggling to continue coding. You might decide to not code at all - it wouldn’t be an unpopular choice. If you DO want to continue being hands-on, you might struggle to find time for it.
This turns more into a scheduling than a motivation question.
You will never have time for writing code. I can tell you that right here. The question then becomes: will you make time for coding?
I’m sure you’ve encountered a similar thing in your regular development job. There are always things you need to do and things that you want to do. It’s easy to be sucked down the spiral of firefighting, urgent tasks and rushing to make progress. But maybe it was exactly your ability to find time for that extra bit of work that got you the promotion. Many people will advise you that you don’t get promoted because you are doing the tasks you are given. You are often promoted because you go the extra mile. The same holds true for after you get promoted. And one extra mile you are going in your new role, could be staying hands-on in development.
More concretely, if you want to stay relevant as a developer, there are a few techniques you can use in order to sneak in some coding time.
Block Time for Development
As I said, you can forget about having time for development. You have to make time. How do you do that?
I’m sure there will be a few tasks that are important, but the company is not going to burn down if you do them a day later. So create a blocker for development, respect it and use it.
Alternatively, if you can bear a bit of overtime, you can work on coding tasks during slower times like early mornings, evenings and maybe even weekends. I remember, when I was running my startup, there was always so much going on during the day. Even though I was coding during it, it was code that was just necessary - day-to-day tasks. I found it then very refreshing to work on more “creative“ things after the work day, or on the weekend. At these times, I came up with a lot of original ideas. It was because I was free of the pressures of the regular working day.
What to Work On?
As a manager, you need to be deliberate about what task you take over. It needs to be something that’s not bigger than you can handle, for instance. Something you can be chipping away at for a while, without blocking anyone else. Here are some guiding principles:
Take tasks that are not urgent
Take tasks that don’t require a big amount of specific domain knowledge
Take tasks that others don’t depend on
Choose a part of the code that you know or plan on getting to know
Work on something that you enjoy - no point choosing a task that you’d hate
Don’t step on people’s toes - it might be tempting to take tasks that others would also love to do. You shouldn’t cut in line on those.
Hiring
Hiring can be a big part of a manager’s day. So you better learn to love it. Obviously, you can outsource it to other team members, but I wouldn’t recommend that. Of course, you shouldn’t be the only one interviewing candidates, but you should be involved in choosing who joins the team. It would also be strange as an applicant to go through the hiring process and never meet your manager.
The actual load depends on how often you have openings in the team, how many candidates you interview and what the process looks like. I know managers that sink at least half of their time in hiring-related topics. Others don’t lead interviews for months or even years, if the company is not hiring.
I think most people can learn to enjoy interviewing new engineers. The real struggle comes from doing interview after interview, asking the same questions and mostly getting the same answers. It can be especially frustrating if good applicants are hard to find. You always hope that the next candidate will be great and they will sign a contract with you. But often times, that’s not the case.
You should also invest in creating a good interview process. This is outside the scope of this article, but if you’re interested, I covered this topic at greater length in my “Designing a hiring process for developers” post.
Keeping the Team Healthy
A good manager not only ensures technical excellence, but also keeps the team’s well-being in check. If it were all about the technical side of things, it wouldn’t be a management position, but rather a tech lead or a software architect one. Your team (still) consists of humans and they come with their human problems. You shouldn’t avoid dealing with conflicts, blockers and motivation in the team. So much so that it sometimes feels more like psychotherapy than software development. My advice would be - don’t run away from this. Many developers are surprisingly bad at coordinating with even their closest colleagues. Sometimes they have low days. Sometimes they are plain unhappy and need their manager to give them some attention. During conflicts, they might look to you as a mediator.
If this last paragraph made you cringe, it might be time to re-evaluate your decision to go into leadership. It’s just a part of it. The good news is that most of the time, it’s not bad. In fact, it can be quite rewarding to guide your team into success, get to know them better and influence them into becoming better engineers.
How does this look day to day?
1-on-1s
Many leaders opt to have 1-on-1 meetings with their team members. It’s typically an appointment without a very fixed agenda where engineers can bring up ideas and concerns with you. I’m not going to get into detail about how to set them up. There’s a lot of literature about this. I personally liked the book “Managing humans” by Michael Lopp.
I personally, really recommend doing 1-on-1s, because developers are not the best at proactively approaching their manager with problems, so having an allocated time especially for this goes a long way.
Synchronizing
Very early on in my career, I discovered that being a team leader was a lot about synchronizing the team and resolving blockers. A lot of times, developers get blocked by something they don’t control themselves - should it be that some information is missing, there might be a dependency with another team, or often times they get blocked by the work of a fellow teammate. It sounds funny. Sometimes, work besties, sitting meters away from each other, get stuck waiting on each other. I don’t mean that they do it on purpose or because they are not good - it’s just the way it is.
In this situation, your work becomes a perpetual task of listening for and finding these blockers and resolving them as soon as possible. It sounds easy, and it can be easy, but some managers just fail to be around, to listen, or to realize how important it is to ensure each team member has all they need to do their job effectively. In fact, Scrum, Kanban, and cross-functional teams are exactly for tackling this problem.
My advice here is - try to be hands-on enough to know what each team member is up to, what they need to proceed, and be there when they complain they lack something. It sounds easy, could be easy, for sure it takes time and effort.
Architecture and Vision
This is where a lot of the pleasure from these management positions comes from - the ability to influence what the team is working on, in a big way. Bigger than an individual contributor could. Of course, it’s also not that easy. There’s a lot of pressure to come up with an architecture that is adequate enough to get the job done in a good way. It takes experience and know-how to avoid making a bad decision here.
Keep in mind that this doesn’t need to be a task for a lone wolf manager - in fact, many developers would be very disappointed if they are not included in these decisions. I don’t think it’s the manager’s task to invent the whole system in a vacuum and bestow it on the team as a law. It’s a collaborative process, and you, as a manager, just need to facilitate it and guide it through, based on your personal opinion and the requirements of the business. Don’t try to disregard people’s ideas - leverage them.
Soft Skills on the Job
It cannot be an article about moving to management without mentioning soft skills. Perhaps, this is precisely the reason you are reading, and also the reason you want to go to management. Needless to say, soft skills are paramount to successful leaders. So much so, that I wouldn’t recommend you going into management unless you want to improve and iterate on your social skills.
I’m going to stop advertising soft skills here, as there’s tons of literature on this. In fact, if you stumbled upon this post, chances are you’ve already seen countless others.
Instead, I’m going to give you some advice that helped me communicate better with my team.
Praise Publicly, Criticise in Private
I used to think being open and transparent was king, but when it comes to feedback, the audience matters. You might think that if you want to call someone on their bad behavior, you should do it in front of the team so they know that’s expected. But no one likes to get bad feedback in front of everyone. Even if you’re mad, take that person to the side and let them know privately. Give them some dignity.
Similarly, when praising someone, shout it from the rooftops. Let everyone know. Do it immediately - don’t wait. You will make the day of your team member. Even if they don’t show it. And on that topic…
Your Opinion Matters
Your words have more weight than that of a fellow developer - because you are the boss. Even if you are friends. So choose them wisely.
I like to joke around, even in the workplace. I’m famous for my jokes, some of which have historically been… edgy. I’m not a stranger to teasing colleagues. It’s always been great fun, especially once people get to know me and understand that I’m just fooling around. One day I was approached by the co-founder of our company and he asked me to be more careful with that. Because I was no longer “one of the guys”. If I said something sassy, people were left wondering if it was really for fun. Don’t be like old me - keep it clean in the workplace. If you want to joke around, do it after working hours.
Set an Example
People will look at you and mirror your behaviour. If you’re daring, they will be daring. If you care about quality over speed, they will care about quality. If you work until 11 PM, they… might stay 30 mins longer than they wanted. So act the way you want them to act. Be a role model.
Listen First, Talk Last, Don’t Criticise
Conversations with your team are like health checks - the responses you get give you insights to the wellbeing of the team. This only happens if these conversations are a safe place.
On a psychological level, people don’t want to feel judged, and they love talking about themselves. Let them. Let them feel understood. Criticising them only makes them close up. Understand why they do the things they do.
Of course, if they are doing the wrong thing, you have to let them know. But don’t criticise them - discuss with them.
Be Firm
Most of what I wrote in the previous paragraphs is a rather soft approach. The real difficult part is that you also have to be firm. A company is not a tea party. There are high expectations towards each member of the team and you have to resonate that. It’s easy to play everyone’s favorite, playing the bad cop is more difficult, and the most difficult is to be understanding, nurturing, but firm. This is a journey you need to embark on yourself, based on your character and values. What worked for me, might not work for you. And it doesn’t come overnight. Try and iterate for years, swing between being too good to being a tyrant and back. One day, you might hit the sweet spot. I’ll let you know if I do ;)
Conclusion
Adler and I set out to write up how your day-to-day life would change if you became a manager. The thing is - being a leader is a “choose your own adventure” kind of position. You are free to structure your day based on what you emphasize on. So in the end, we only give you a playbook of the constraints for what constitutes a leader worth following. At least from our perspective, anyway. And this is the last recommendation I’ll give you here.
Build your management style around YOU - around your values, your strengths and what you can enforce without making it difficult to look yourself in the mirror.
Last Words
Really appreciate Nikola for sharing his experience. Remember to check out his newsletter HipsterTech!
Thank you for reading the post!
❤️ Click the like button if you like this article.
🔁 Share this post to help others find it.
Resources
Tokyo Tech Lead is a blog/newsletter for engineering leaders. Check out this overview guide for all resources it provides.
Guest Post Opportunities
If you are interested in writing for Tokyo Tech Lead, check this guideline post and let’s build something together!
Contact
You can find me on LinkedIn or Substack.
If you want more content like this, consider subscribing to my newsletter.
See you in the next post!
 | A guest post by
|