Management, Technical Leadership

20 Tips for Achieving a Team Leader Role

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

Becoming a team leader is the first step in a management career. It’s also a good opportunity to see if such duties would be interesting for you in the long term. This article lists ideas for achieving a promotion to such role. There is no guarantee, but the more of them you apply, the higher your chances for success will be. I have personally used most (if not all) of these tips, and they greatly helped me to drive my career onto this path.

Some people think it’s luck, or that you have to be born with leadership traits. I believe that with enough effort and sacrifice, most people can achieve such role and perform well in it. Some will need just a short time before they are ready and get promoted, for others it may take a few years of careful preparations and hard work on improving their soft skills, but it’s certainly achievable.

While this article is mainly directed to software developers, most of these techniques should also apply to other jobs.

1. Pick the Right Workplace

If you’re seriously considering a career in leadership, it’s best to be at a company that cares about long-term employee growth. You want a place that has established career development programs and some experienced leaders that you could learn from.

The company should be large enough to offer these benefits, while remaining flexible and open to ambitious individuals. Contract-based or per-project employment, as well as small start-ups would not normally be good options for this scenario. You also need a reasonable boss, who will help you grow rather than keeping you as a developer on the team at all costs.

2. Perform Your Current Duties Well

You don’t need to be a great software developer to lead a team. A good manager won’t promote someone just because they have the highest technical skills, they will rather look for employees that show specific leadership traits. However, a good manager also knows that they should not reward a poor performer with a promotion.

So you need to be doing a good job as a programmer before you move on. If you find it hard to motivate for that, you need to look for a different type of job, e.g. an analyst or a QA engineer. If the current project is too difficult for you, you need to increase your skills or look for a simpler one. Keeping the performance below at least a solid level won’t get you anywhere, so if you’re not doing well – change something.

3. Show That You Care

Not just about your own results, but about the whole project, team, or even department. When there is a production issue, offer that you will stay longer to help with it, even if you haven’t caused it. Be proactive, suggest long-term enhancements to the code and implement them in your spare time. During discussions, express your opinions, bring up ideas and ask questions. Show your interest in the long-term strategy for the project and the team.

4. Be Open About Your Goal

If you truly want to progress in this direction, you should really mention that to your current team leader. Some people are afraid that it will be misinterpreted, but keeping this ambition to yourself and waiting for someone in the company to magically discover it won’t usually work.

Just be sure to say that it’s a long-term goal, not something you necessarily need *now*, and that you would value your manager’s help in gaining the necessary skills. When the time comes that your boss will move to another role or company, you want them to recommend you as the best replacement, and being open about this goal is the first step.

5. Don’t Act Behind Your Manager’s Back

Once your boss knows about your career ambition, you need to be careful to not lose their trust. Be open about any actions you are taking in this direction, so that your manager doesn’t think you are plotting against them (and never actually do). You need an ally, not an enemy.

A different approach is not only unethical, it will also usually lead to a failure. Life is not like TV shows, and even if you manage to achieve something in this way, it will hurt the team and department in the long term. You don’t want to build your career on unhealthy and fragile foundations.

6. Be a Team Player

Be helpful towards your co-workers, treat them with respect and show interest in their ideas. Don’t avoid expressing your opinion if you disagree with something that they say or do, but make sure to do it in a way that doesn’t offend anyone. Good, professional relationships with your co-workers are key to building your authority in the team.

7. Don’t Always Be Right

It’s not the smartest team member that would normally get promoted, but the one with the highest leadership potential. Don’t be stubborn in pushing your ideas, welcome alternative opinions and don’t hesitate to admit mistakes. Help to facilitate discussions in the team so that the best decision is made, even if it doesn’t originate from you. The team will benefit from such approach more, and other employees – including your team leader – will notice and appreciate your open attitude.

8. Volunteer for Extra Duties

Keep your eyes open for additional opportunities and be eager to offer your help. Maybe some other team is facing a difficult technical problem, which you could research? Or the marketing department needs some help with HTML for their newsletter? Or there is some company-wide initiative and they are looking for volunteers? This will show that you are able to manage multiple unrelated efforts at a time. You may say you’re too busy already – well, we all usually are, but if you’re targeting a leadership role, you need to be prepared to occasionally give much more than at a 9-to-5 job.

9. Lead a Project in Your Free Time

Ideas for that could range from leading an open source effort with some of your developer friends, to activities outside of IT, like organizing events or group meetings related to your personal hobbies. Look at what you are doing already in your free time, and see if there is any opportunity to gather leadership experience there. If you achieve any interesting results, mention them to your boss the next time you’re discussing personal development.

10. Keep Your Commitments

Your manager, as well as other co-workers, need to be sure that they can rely on you – that you will always do what you say. Maintain a list of what you commit to for others and review it on a regular basis. If any of your deliverables is at risk, be sure to notify appropriate people, and propose any alternatives that you can think of. This is key to earning trust of your manager and peers.

11. Assist in Your Manager’s Duties

You can offer your boss to help in some of the duties related to team management. You could represent the team at a meeting, help in some mandatory reporting or be your manager’s deputy when they are on vacation or sick. If you can become your team leader’s right hand, it will be a great foundation for further progress.

12. Help with Recruitment and Onboarding

Participating in the hiring process can teach you a number of skills required in your future job, and once again show that you care about the team more than an average employee. Once a new person is hired, offer to help them out in the first few weeks, even in basic stuff (like showing how the coffee machine works). Many companies have a ‘buddy’ system or peer mentoring program of some sort – make sure to sign up for it.

13. Build Good Relationships with the Customers

It’s not just your management that should see you as a potential leader. You also want the customers of your team (e.g. end users, product owners) to be satisfied when cooperating with you. Don’t work behind your team’s back, and don’t break the established rules of cooperation, but still try to do your best working within those boundaries. Be helpful, build a positive relationship and look for further improvements that would serve the customers. The more good opinions about your approach that come through to your managers from various sources, the better the chances that they will consider you for such role.

14. Be Self-Driven

You don’t want your manager to invest a lot of time for getting you through the details of your duties, and I don’t just mean technical ones here. Show that you are able to get work done from the beginning to the end. If you need additional information to complete a task, go to the source. If you don’t know who that is, ask around. If someone is not responding to your e-mail, follow up with a call or try with their peer or manager. If you need a decision from your manager, list them the pros and cons. If there is a problem to solve, try to propose solutions instead of just asking what to do.

In general, keep your manager informed about your progress, but avoid engaging them actively until it’s necessary. This doesn’t mean you should avoid asking for direction, or escalating important issues promptly. Just make sure that you explore the actions you can take yourself first.

15. Show Your Loyalty

Managers usually try to hire people that offer high chances of staying at the company for a longer time. That’s even more important in case of leadership positions – nobody wants a situation where a new leader leaves the team after just a few months. That’s why it’s important that even as a regular team member, you show your support during hard times and don’t immediately start looking for a new job when problems appear.

You can also show your loyalty by supporting unpopular decisions made by management (assuming they are not unethical or illegal). Even if you disagree with them, once they are made there’s usually no alternative, so it’s best to look for positives and try to help in implementing them well, rather than showing your frustration and adding to the negativity in the team. In this way you also show that you are a responsible person and understand the wider, strategic context, which may not always be evident to other employees. However, you need to be careful to not lose trust of other team members – you want to be loyal towards them too, and it may often be challenging to find the right balance.

16. Assess Your Strengths and Weaknesses

There are many skills that you need to have in a leadership role, and the first step to ensure that is learning about your current strengths and weaknesses. While you may have some assumptions, it’s important to verify them, as other people’s perception can frequently turn out to be very surprising. There are many ways to do that, the simplest being just to ask other people directly – starting with your manager. You may also use some formal techniques such as 360 Feedback or MBTI tests.

17. Learn, Learn, Learn

As a developer you should already know that you will need to keep learning new things throughout your whole career to stay good at your job. As a future leader, you have a whole new area to explore and it’s important to establish a learning routine, so that your knowledge will be increasing consistently.

Use your idle time (e.g. driving, commuting, waiting in queues) productively by reading books, listening to recordings or reviewing articles. Establish a time of day or week that you will reserve for such activities. Check with your manager if you can use some time at work for that. Also keep your eyes open for any leadership trainings or workshops that may be happening in your company.

18. Find a Mentor

In addition to your immediate manager, you may look for help outside of your team, department or even company. If you know someone experienced, who went through the same path as you desire, it may be very beneficial to learn their story and get advice about your activities on a regular basis. Don’t be afraid of hearing ‘no’ – it doesn’t hurt to ask, and many people will actually be flattered by such proposal. Remember to inform your team leader about this in order to remain transparent.

19. Network with Other Leaders

If you don’t want to work with a single mentor, you can try connecting with a wider group of leaders. If there are any local group meetings in your town that include leadership topics, join them. Ask others for advice or recommendations about learning resources. Follow people sharing interesting content, get into discussions on Twitter or blogs, join LinkedIn groups for leaders. There are many opportunities to learn from others.

20. Be Patient

Last but not least, don’t get discouraged if the above efforts don’t bring an immediate success. Getting frustrated certainly won’t help, and moving to another company just because of this could mean that you will need to start over. There are many situations that can happen every day, opening up opportunities for your promotion:

  • Your boss may get promoted or decide to join another company,
  • A new team may need to be created for a new project,
  • An existing team will need to be split up to be more effective,
  • You may be offered to replace a leader in a different team.

Sometimes it will take longer, but if you continue to apply the above tips and keep your management aware of your goals and progress, I strongly believe that sooner or later it will happen.

Summary

As you can conclude from many of the ideas listed here, you should strive to become a natural leader for people before you are appointed as one. This does not only increase your chances of promotion, but also prepares a good ground for your future role, and will make your start much easier.

When preparing this list, I was trying to include both my past perspective as a developer, as well as the current one – of a development manager, thinking about what I would expect from someone aspiring to a team leader role in my own team. I hope these tips help you get where you want to be.

Let me know in the comments about any other ideas you have (or actually applied) to steer your career to a desired path.

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail
Standard
Development Process

Fighting the ‘Almost Done’ Syndrome

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail

There’s a popular joke that 90% of software projects are 90% done, 90% of the time – and unfortunately it does have some truth behind it. But does it have to be this way? How can we, as leaders, ensure that our teams avoid this trap and deliver completed features in a predictable way? Here’s a few tips from my own experience.

We’ve all been there: your team is working on an important project (all projects are important, right?), and when the release is just around the corner you suddenly find out that there’s still a lot of work to connect all the dots: system integration does not work, performance is unacceptable for larger data volumes, edge cases in business logic are not properly handled, and so on. Your team ends up coding some last-minute patches, working late evenings or weekends in much haste, making mistakes. Once you release the software, the users experience some serious bugs and you have to spend several days or weeks before the customer can actually benefit from the application.

The client is unhappy, your employees are burned out, and your reputation suffers – not a result that anyone would want. So how can we prevent this ‘Almost Done’ syndrome, how can we ensure that we don’t get last-minute surprises calling for hasty patching again? There are multiple aspects that you need to take care of to succeed.

The Mindset

It’s natural for all of us to prefer simpler tasks over more complex ones, and developers are no exception. They will tend to put off the latter and overly focus on the former. It doesn’t mean they will avoid doing difficult work, just that they will choose to complete the parts they perceive as simpler and more clear first.

For example, when someone feels comfortable implementing complex algorithms and does that frequently, they will tend to focus on that part of a new feature, and may be putting off other important aspects – like detailed analysis of the business process, or a discussion about some integration details with another system’s developer.

What can happen without proper self-control is that developers will keep polishing one area or switch to other tasks, in order to avoid working on that least comfortable 10% of the feature. It’s natural, we all have such temptations, and the first step to fight this problem is admission. Once you and your people realize it, it’s a good ground to build your process improvements on.

Limit Work in Progress

There’s a simple yet beautiful concept in Kanban called WIP (Work in Progress) limits. It’s usually understood as the maximum number of tasks in progress for the team. When it’s reached and a new important task enters the queue, the team usually needs to focus on completing at least one of the previous tasks before they can begin it. Such approach does allow for some exceptions, but it greatly helps in making sure the team members don’t jump between tasks without control, leaving many loose ends.

You don’t actually need to follow Kanban or any other Agile practices to introduce this type of rule. You can also adjust it: sometimes you might be better off with a per-project limit (e.g. when your team is developing multiple applications) or any other variant that fits your environment best. The crucial thing is that you coach your developers to finish one task before starting another (at least in normal situations).

Definition of Done

The approach of WIP limits (or similar) will help your team avoid unnecessary multi-tasking, but a common understanding of what it means that a task is completed is also needed. Such definition should include all steps required to be performed before a feature is released as part of the new product increment (e.g. into UAT environment).

A sample Definition of Done would include steps like:

  • Code changes are checked into the repository,
  • The CI build is successful,
  • The feature is tested in DEV and all bugs are fixed,
  • Integration with other components is verified,
  • A peer review is performed,
  • and so on.

It’s usually best to write these steps down and make them visible to all team members, all the time.

Acceptance Criteria

Another aspect to work on is defining clear acceptance criteria for new features of your system. They should include both functional and non-functional requirements, so remember to clarify the expected load, frequency of the feature’s use, platforms that need to be supported etc. in discussions with your customer. Don’t forget about technical quality factors, such as maintainability, extensibility, or scalability.

You can consider including such acceptance criteria in your team’s Definition of Done too. While many of them can be difficult to describe precisely, your developers need to remember that the software won’t really be ready for a release until those requirements are met, so they need to design, code and test with all of them in mind, and not keep putting that work off till the last week of the project.

Clear Action Ownership

Many cases of loose ends occur due to miscommunication when making agreements on some side tasks (not directly related to coding), e.g. arranging some infrastructure change or confirming some edge case of business logic with the customer. I have personally run into this many times – everybody was thinking that someone else will do it, and in the end we had to rush it or just accept the risk.

To avoid such cases, make sure every action – even the smallest one – has a clear next step and an owner assigned. Coach your team members to finalize every discussion with a short summary of who-does-what, so that it doesn’t require your personal control.

Releasable Increments

Probably the best way to ensure your product will be ready for a release on the big day is to keep it always ready for a release. That can be achieved by employing a process of Continuous Delivery, where you can actually push the software to target environment at any time you want, with minor cost (‘one click’, ideally), and verify its completeness then.

However, as this technique is not very common yet and may take a long time to implement, in the short term you can at least ensure the ability to release a product increment that is created at the end of every iteration (sprint, milestone or whatever that is in your methodology). You may not be able to verify releasing it into the Production environment, but even running it on staging or UAT machines should help polish the system. It should allow you to spot and eliminate most, if not all, of possible issues with configuration, infrastructure and integration with other components.

So keep your product releasable during its whole lifecycle. Leaving that for the last week or month can often cause serious problems.

Realistic Test Data

One big source of surprises in the final phase of a project is the lack of proper test data during all stages of development. In many cases your team won’t be able to use real data and you will need to rely on fake, auto-generated sets. In such case, make sure the sets are large enough and allow to verify the system’s state not only at day one (when the database could be almost empty), but also after 3 or 5 years of its continuous use. Also, ensure that the data contains a wide range of values and includes edge cases.

The problems coming from data itself could go from simple too-long-to-display types of defects, to large performance/scalability issues that require a part of the system to be redesigned. It’s much easier to design and code for the expected volume and some data anomalies from the start, so ensure that this information is provided to your team and make the development environment reflect that.

Summary

The above advices won’t guarantee you a successful finish, but they should lower the risk vastly and allow your team to focus on other things in the last few weeks before the release. Of course there are many other aspects to take care of, like the estimation process or integration with other systems, but I hope this article motivates you to think through the topic and select items to focus on in your team’s context.

 

facebooktwitterlinkedinmailfacebooktwitterlinkedinmail
Standard