From Leadership to Lines of Code: A Team Leader's Guide

Hi There!

I think that every developer who transitions to a team leader role initially strives to return to coding and solving tasks alongside the team. Later on, we start to encompass more business tasks and issues, diving into business-related challenges, communication between departments or clients, and architecture.

From this point on, we no longer have either the time or the desire to do something else. A typical team lead's calendar begins to resemble this:

How Do I Return to Development and Start Coding Again? Where Should I Begin?

It's also important to assess how genuinely busy you are and what your typical workday looks like. Do you engage in self-improvement after work or not? These are all crucial factors.

Based on my experience, I suggest taking steps along the path from “no time before or after work, no desire or opportunity” to “I'm always at the computer, and this is my passion.”

Block Your Time!

An effective starting point is to schedule dedicated time for development. Simply block out 'coding time' in your calendar for an hour or more. If possible, consider reserving half a day or a full day each week specifically for tackling technical tasks.

Yes, it might involve moving meetings around, eliminating unnecessary ones, or discussing the necessity of attending some of them. However, consider reassessing whether certain grooming sessions are still relevant for you.

Perhaps you're spending an hour there without much impact? Redirect that time towards coding!

Code Review With Your Team!

The second and most crucial aspect for optimizing certain processes around you is to communicate the project's values or approaches to your colleagues. Not every developer sees the same approach to problem-solving, so it's essential to predefine coding styles, test coverage, and the fundamental methods and mechanics of the platform or services separately.

Always conduct code reviews, and if there's a sense that a question is dragging on, gather the team to swiftly address issues in the pull requests (PRs). As practice shows, this approach speeds up issue resolution time, consequently improving the time to market for features.

Over time, your team will fully understand and apply development approaches that require less attention. You'll be focused solely on solving the task at hand and its logic, which will save a few minutes initially and, in the long run, potentially hours of development time.

What Are You Responsible For?

It might not seem like the most obvious task, but ask yourself, what are you responsible for? What do you need to do? Write down all these points on a sheet of paper and see if you've taken on anything unnecessary.

Perhaps you're doing someone else's work just because it has become a habit. Maybe you've been helping a neighboring team with their processes, and you're still involved.

Clearly define your position and what you contribute to the project or the company. If you lead a large team, use notes where you can create a queue of tasks and issues. Always conduct reviews, and ensure that if you're a DevOps lead, for example, you aren't inadvertently handling tasks meant for mobile app developers.

If you find yourself overloaded with tasks and dependencies, it's worth stopping to talk to your superiors and figure out why this is happening in your department. For example, if you're a DevOps team responsible for Data Engineers, and they have their own lead, it might make sense to delegate responsibilities back to their lead instead of your department.

Create specifications and necessary documents to formalize agreements or any hidden details about setup or maintenance and return people to their respective teams.

It's essential to note that this is just an example, and everyone has their own teams and principles of their formation.

Prioritization and Delegation

It's possible that you're not getting things done because priorities keep shifting. The entire company operates on two-week sprints, but this setup no longer suits you, and you don't see value in it. Features aren't making it to completion within a sprint due to weak priorities.

This is relevant for service-oriented teams.

Consider exploring Kanban or a waterflow approach. Our teams are like separate islands where we have the right to try changing processes for the better. Test transitioning to the new approach for a month, and observe your metrics. In my experience, a couple of weeks were enough to notice that Scrum wasn't suitable for us, and we switched to Kanban.

Next, try breaking down the team into domain zones, but not too granularly.

Immerse each team member following the 70/30 rule:

• 70% dedicated to their main stack, project, or product
• 30% for everything else

If your team has more than 5 people, you'll cover all services and functions, allowing individuals to dive faster into the subject area.

What does this achieve?

It allows you to delegate some tasks to the team rather than doing everything yourself if you see that a developer already has a good understanding and immersion. You don't need to describe the entire algorithm and integrations! They already know it all!

Time Management and Productivity

How Is the Team Planning Its Work Time?

Let's start with something simple: how do you operate as a team? Take a look at your estimations and how you assess tasks. Is everything in order? Perhaps there's room for improvement or the introduction of a workload coefficient?

The workload coefficient helps understand how each team member is loaded during a sprint or week, considering potential distractions for support. For instance, if you're a service team with your own product to maintain, other teams might seek your assistance or request enhancements, leading to time spent on communication within the sprint.

The same goes for dealing with bugs; you might frequently get sidetracked to address urgent issues in the production environment.

But that's a separate topic, and I'd advise checking out my previous article on how to make gradual improvements in this area.

Now, back to the coefficient. If we acknowledge that each of us is called to a chat or a meeting at least 1 day out of 5 to resolve an issue, take that into during planning. This way, you'll realistically manage to accomplish tasks that truly benefit the team, potentially freeing up time to write code.

Try the Pomodoro technique.

Nothing groundbreaking; just use an app on your phone that allows you to focus on a task for a set time interval, like 45 minutes. Nothing special, I guess.

Utilize trackers.

Conduct an investigation into what you spend your 8 working hours on — record each hour and minute of your activities during the week or month. You might discover factors that distract you, or you might notice that taking a 15-minute walk after lunch makes you work more efficiently—perhaps that's the key to success? Or, if you have three consecutive meetings, do you find yourself doing nothing for an hour afterward, just reading specifications? Maybe it's challenging for you?

The point is to scrutinize what you're doing, and I believe you'll identify areas for improvement.

Participation in Technically Challenging Projects

If you find yourself unable to attend meetings dedicated to system design or architectural solutions, read follow-ups or documentation. Try to understand how and what solves the problem. It's preferable not to miss such meetings and strive to immerse yourself as much as possible in the technical aspects.

Select projects or project aspects that require a deep dive into the code. This will help you stay abreast of new technologies and development methodologies.

RnD for You

If you notice areas in the project that have issues or where functionality could be improved, feel free to create prototypes. This will not only allow you to visualize the proposed changes but also provide the team with tangible material for discussion and decision-making.

The main goal is not just to showcase ideas but to implement them into the project if they prove to be genuinely significant or beneficial. For example, if you've always dreamt of migrating outdated services from Java 1.8 to version 21, why not give it a try? Create a prototype, show it to the team, develop your solution, and thoroughly document the entire process for future reference.

This approach helps not only to implement technical improvements but also to create a shared understanding within the team regarding potential changes. Thus, you can make a constructive contribution to the project, ensuring its effective development and fostering innovation.

Review Point!

At this stage, you'll have a couple of hours to write code, propose solutions, and then you can take a breather. Of course, the leadership position simply won't allow you to do both, and if your focus is still on development, it might be worth considering a return.

There's nothing wrong with that—realizing that management is becoming dull for you, even if you excel at it, is okay. It's just that, at this point in time, it has lost its appeal for you.

If You Still Have Some Free Time

Learning and Self-Development

Continuously educate yourself by reading technical literature, exploring educational courses, and participating in technical conferences. This will help you stay abreast of the latest trends and best practices in software development.

Reading technical literature provides a unique opportunity to delve into the depths of new technologies, methodologies, and best practices. This can include books, articles, blogs, and other materials covering various aspects of software development.

Taking educational courses is a structured and systematic way to acquire knowledge on new topics and technologies. Online course platforms offer a wide range of courses on different programming languages, frameworks, and concepts.

Participating in technical conferences opens up the opportunity not only to learn about the latest trends and innovations but also to engage with industry professionals. Conferences provide a platform for sharing experiences, discussing challenging issues, and building connections within the technical community.

In summary, continuous learning through reading, taking courses, and attending conferences allows software developers not only to keep up with the latest trends but also to actively integrate new knowledge and skills into their daily work.

Examples: leetcode, Udemy, or Youtube (sometimes, we can find really good FREE content there!).

Working on Personal Projects

If possible, work on personal projects in your free time. This will not only enhance your programming skills but also serve as a source of new ideas for your primary job.

Additionally, combining this activity with the RnD point from the article can be an extra incentive for creativity and innovation.

Working on personal projects allows you to apply your skills in practical scenarios, experiment with new technologies, and solve real-world problems. These projects may involve developing your own web applications, creating open-source projects, or participating in interesting side projects.

Integrating this activity with the research and development (RnD) work mentioned earlier enables you to create prototypes and showcase them at your workplace. Opening your project to the public, such as participating in open-source development, not only improves your skills but also contributes to building valuable professional connections and gaining recognition for your creativity.

Conclusion

Finding time for coding as a team leader requires conscious effort and effective priority management. Remember that your role involves not only directly leading the team but also maintaining your technical skills at a satisfactory level.

It will be challenging, and I wish you the best of luck!

I saw the problem a long time ago. If you'd like to read professional books, I’d recommend you read books: link and link