Development Process, Management, Technical Leadership

My talk about DevOps culture at the 4Developers conference

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

A couple of weeks ago I had a pleasure to present a session at the 4Developers conference in Warsaw. The talk was about the DevOps culture and its growing impact on our industry. The full title in English was: ‘DevOps: (r)evolution in the development of people, teams, architectures and products that you can’t miss.’

Photo from my DevOps talk at the 4Developers conference

I was presenting it together with the distinguished Grzegorz Kozub (a.k.a. the Best-Dressed Speaker), a technical lead in one of my teams, working in the middle of the DevOps and cloud transformation of our products.

Here you can watch the video of the talk (we are speaking in Polish, but the slides are in English). Enjoy!

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Technical Leadership

Top 10 Beginner Mistakes of Technical Leaders

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

It’s usually better to learn from others’ mistakes when possible. Today I list the top mistakes that I either made myself, or saw others make when leading teams for the first time.

accident photo

1. Assuming you need to be the smartest. As a leader, you are expected to give advice and coach your team members. However, this does not mean you should know all the answers, have the highest technical skills or be the most experienced in every area.

You can and should give direction, but you don’t need to understand all the details of every technology your team is using. Your job is mainly to let your people be the experts in their respective areas, helping them grow and utilize those skills most effectively.

2. Setting incorrect priorities. In most cases, you will be trying to keep too many technical duties when performing this role for the first time. It’s important that you quickly switch your focus from your own programming tasks to ensuring your team members are satisfied, and are able to work and grow without obstacles.

3. Trying to enforce or fake authority. Some new leaders assume they have to present tough behavior or give some strict orders, just so the team can see who’s the boss now. Others think they should appear as being always right.

Neither of these will help in building authority. As a beginner, you need to remain humble, honest and respectful. Over time, after doing a ‘good job’ in the new role consistently, the results shall come.

4. Worrying too much – or not enough. In the first few weeks it’s probable that you will be especially concerned with any project risks that you see. After all, nobody wants to start with a failure. You may also be thinking other people don’t trust you as a beginner, or that some are even plotting against you.

However, this approach may lead you to trying to control things too closely, getting too stressed out with small mistakes of your team members, and letting the emotions takeover.

On the other hand, you obviously don’t want to appear like you don’t care about the results, as it will be demotivating for the team and you may build a bad image for your customers. As usual, finding the right balance is crucial to have a good start in the role.

5. Making decisions with full information only. As a developer, you were probably used to doing thorough investigation of solutions before choosing to go with one. As a leader, you will have to make many quick decisions (not just technical ones) to avoid holding off important work.

Don’t try to do extensive research for everything. Review what you know now, and take the risk. You can’t avoid mistakes in this job anyway.

6. Not delegating enough. Desire to control every aspect of your team’s work will quickly turn you into a micromanager that all developers want to avoid. Don’t assume you have to make all the technical decisions now that you’re a team lead.

For many it’s also natural to be afraid of appearing ‘lazy’ when asking others to perform tasks you used to do until now. Don’t fall into the trap of thinking this way. In fact, if you try to keep all the duties you had before, it’s likely that your leadership duties won’t receive enough attention.

7. Ignoring education. Leadership skills are just like technical skills in that they need to be learned. You use different methods for that of course, but it’s still something you have to invest time and effort to do well.

For some people it will come naturally, others will require a significant investment and a lot of practice to introduce new behaviors, but everyone should be actively growing such skills. If you like to read blogs, add a few ‘soft’ ones to your subscriptions list. Put some books on the topic into your reading queue. Look for leadership conferences or user groups if you’re more of an ‘offline’ person.

8. Getting discouraged after initial failures. You will run into problems, that’s for sure. Maybe you were the ultimate problem solver as a developer, but in this role not all of them can be solved just with time, focus and technical knowledge. In many cases the results of your decisions – and the learning from them – will come much later.

It tends to discourage a lot of beginning leaders and they decide to fall back into technical positions, feeling much more in control there. That may be premature and often a better approach would be to retrospect on the failure, bite the bullet and try again.

9. Defending your position. So far you may have felt you had a secure job. You were a solid developer with many alternative opportunities in case something didn’t work out.

Leadership positions are obviously less secure and it might leave some people with a strong feeling of discomfort. If you embrace such negative thoughts, it may result in making wrong decisions just to defend your position, while under pressure from your customers or managers.

10. Not caring about your customer enough. Having said the above, putting the right level of effort into building relationship with your customers is still crucial. After all, the business value that your team is producing is the main reason for its existence.

The key here is finding the right balance between protecting your team from interruptions and pressure, and remaining open to changing customer needs.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Development Process, Technical Leadership

FAQ for Your Project Manager

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

I decided to summarize some of the most frequently asked questions that I’ve been receiving throughout my career as a development team leader or manager. They usually come from project managers and product owners, sometimes also from stakeholders or customers.

I believe many of us often need to respond to the below, so putting these all together might save us some time. Feel free to copy & paste the answers as needed!

questions photo

1. Why is such a small change taking so long?

  • What might seem as a small tweak, can sometimes require re-designing a part of a system, if we didn’t originally predict that this particular aspect might need to change. And no, it’s not possible to predict all possible changes. Even if it was, you wouldn’t be happy with the cost…
  • Aside from making the code change, we have to test it, ensure it doesn’t affect anything else in the system, deploy it and verify in various environments (development, test, staging, production). No, we can’t take shortcuts if you don’t want to risk a major production failure.
  • Even when making tiny changes, magic can happen and we are never able to predict the impacts with full confidence. That’s just the nature of software development.

2. Why is it so expensive?

  • As developers, we have to take many aspects into account: code quality, security, performance, scalability, maintainability, usability and more. All of these require attention from the team. We have to plan for those concerns, verify them, write automated tests, etc.
  • Yes, we are putting business value as our top priority. We’re just not thinking about today’s business only. What will be the business value of the software if it stops working after the database exceeds 100K records? Or when hackers bring the website down? Would you accept a huge cost of future enhancements if we take design shortcuts today?

disaster photo

3. Are you sure it’s bug-free?

  • No, and we can never be sure. Even worse – every larger piece of software has bugs. That’s just one more thing to accept in this industry.
  • There are many factors that can cause issues, code is just one of them. Some of the other ones are: network infrastructure, server and client hardware and software, system integration mechanisms, web browsers, etc.
  • We are using tens or hundreds of third-party components. Each of them may contain bugs. No, we cannot get rid of them if you want the release to happen this decade.
  • Even when all the other components are fine, there’s a risk that we missed some edge case that nobody ever thought of – not even the analysts or the users.

4. Why can’t you just add more resources to finish earlier?

  • First, developers are not resources. They are not interchangeable, and you cannot easily add or remove them with proportional impact on the results.
  • Recruiting developers can take a long time. If we hire the wrong person, the impact on the project could even be negative.
  • Training developers takes time. The more complicated the system is, the longer it will take before a new person is fluent on the project. And they will make more mistakes that will need to be corrected by other developers.
  • All of these require time investment from the team, which will leave less time for growing the product. That’s why you won’t usually get any short-term benefits. Oh, that next month’s release you wanted to speed up? Better move it till next quarter.

5. Why can’t you tell me when it will be done?

  • We can estimate, at best. We can never predict with full certainty.
  • As explained, even the smallest and simplest change can have unpredicted complications.
  • Every task is a bit different. Even when building similar features for the same application, the related code areas might have been designed differently. Until we start working on them, we won’t fully know what lies beneath.
  • Even if tasks were identical, people working on them can vary in skills and experience. The differences in development time between team members can sometimes be an order of magnitude.

building photo

6. Why are you less productive than that other team?

  • How do you know that? How can you measure that? How do you define ‘productivity’ at all?
  • Every team is different – different people, skills, experiences, distractions, additional duties, etc.
  • Each team may be following a bit different set of practices, which have an impact on development time, as well as quality of the final product. For instance, some teams write unit tests, which increases development time, but also improves the system’s long-term maintainability (when applied properly).
  • Every system is different. One could be based on more problematic technology stack, have poor design, less readable code, etc. Or, quite contrary – it might actually be designed in a better way, having better security or scalability, at the price of more expensive future enhancements.

Are you getting similar questions frequently? Or maybe you have other typical examples? Please share your thoughts in the comments.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Technical Leadership

Are You a Conscious Technical Leader?

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

How many times did you hear a story about a good software developer, whose performance went down after getting promoted into a technical leader role? Unable to focus on either of the duties, frustrating himself and the team, he ended up backing out of the position. Or, alternatively, he kept running the team, but was generating frequent issues with project delivery or employee attrition.

Sounds familiar? It seems to occur much too often in the IT world. Companies often end up losing a good developer for a weak manager. That’s why I believe we need more Conscious Technical Leaders.

pilot photo

A Conscious Technical Leader is someone who was able to make the mind shift after transitioning from a developer’s role. Someone who understands the difference in priorities and expectations, and was able to change their behavior to fit the new situation.

In my opinion, every development team needs a Conscious Technical Leader in order to be fully empowered, to operate in the most effective way, keeping both customers and employees satisfied. Even when it’s not a formal position, like in self-organizing agile teams – most of them could still benefit by having someone with these traits on board.

But what does it really mean in practice? In my opinion, you can call yourself a Conscious Technical Leader when:

  1. You understand that you’re not just a senior developer anymore.
  2. You put the needs of your employees as high as your own.
  3. You understand that leading is not the same as giving orders.
  4. You are focused on increasing your leadership skills and growing in that direction.
  5. You see employee satisfaction and engagement as a high priority, even during difficult times.
  6. You prefer to leave the most interesting technical tasks to your people rather than coding them yourself.
  7. You seek mentors among more experienced people in this role.
  8. You are able to identify the most important soft skills that you need to improve.
  9. You allow your team members to participate in decision making.
  10. You limit the time you spend on technical tasks to make enough space for leader’s duties – and not the other way around.
  11. You actively seek opportunities to help your employees, rather than having them apply and wait.
  12. You know you don’t have all the answers, and you understand you don’t need to have.

Would you add anything to the above list? Please leave your thoughts in the comments.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Management, Technical Leadership

Help! There Are Introverts in My Team

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

In my last post I described some theory behind introversion, and mentioned that probably most software developers demonstrate such type of personality. Today let’s discuss some practical implications it may have for your team and things to consider as a leader.

office photo

Brainstorming should be abandoned. You won’t get the best ideas, you’ll just hear the ones your extroverts can come up with off the cuff. Introverts need time to think through a problem, and they won’t usually say anything just to appear ‘creative’. Use different discussion patterns instead, and if you really care about valuable input, give your people some time to prepare.

Open spaces are counter-productive. They result in your most talented introverts being frequently distracted by the most ‘active’ employees. And you thought you can just put people together into a large room so that they ‘communicate’ and be more creative? Think again.

Some agile techniques require a second thought. Pair programming? Maybe two developers working closely together, communicating all day long, is still fine from an introvert’s perspective – when they know each other well… That’s yet to be researched though. Maybe that’s why some people consider such techniques to do more harm than good.

Review your recognition approach. Many of your team members might not actually enjoy the ‘unique opportunity’ to present their idea in front of the whole company… Some might even see it as punishment. You may still need them to do this, but don’t pretend it’s a reward in such case.

Collaboration is not always the way. We might have been too aggressive in promoting the collaborative style of work, thinking it’s a solution to all problems. Allow your people to work in a bit of isolation sometimes, give them more privacy, and see if the results won’t actually be better.

Limit the number of meetings. Well, nothing new here… Just one more reason to do it (does anyone even need it?!).

These are just some basic observations. I’m sure once you start to look at your team’s everyday work from this perspective, you will notice many more situations in which the environment doesn’t help your introvert team members. Feel free to share them in the comments.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Technical Leadership

8 Very Specific Things about Software Developers

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Software developers are a specific group. While every person is unique, some behaviors and qualities of many developers, or aspects of their work, are clearly different than the average employee’s. In this article, I am going to list what I believe is so specific about programmers, and how it may impact your job as their leader.

If you’re working in a different industry, the below list may help you understand some challenges that managers in IT (or software development, at least) face. And, quite possibly, see things from a bit different perspective the next time you want to blame the IT department for not solving problems in the way you would expect (like ‘why can’t you just add more developers to this project?’).

science photo

1. Developers are very smart

First of all, you’re going to be working with people whose IQ is usually much higher than the population average. It’s an honor and a truly exciting opportunity, if you think about it. It also means an extra effort for you in order to make sure that their work remains challenging and that you keep their engagement high.

Developers will also be more resistant to various pseudo-leadership techniques, and will easily see through even slight manipulation attempts. Forget about sugar-coating, feedback sandwiches etc. Be open and honest if you want their trust.

2. Hiring developers is difficult

Even if you haven’t had a chance to hire anyone yet, you’re probably aware that this job market is very challenging. Finding someone with really good skills can take a long time. You’ll be competing with many other companies to attract the best people, and it won’t be enough to just pay them higher than others. Organization’s culture, working environment, tools and processes in use, types of projects, skills of the current team members – it can all count for your candidates.

Opinions about employers spread quickly throughout developers’ communities, so you may need to work on your brand for a long time. Moreover, it’s not easy to properly assess a candidate’s potential, and hiring the wrong person could mean wasting another few months.

3. Developers are narrowly specialized

You can’t simply replace one developer with another. Not only are they usually focused on a specific technology stack (like Java or .NET), they also typically have preferred lower-level technologies, tools or system layers that they focus on (like front-end or database). Changing that can take a lot of time (we’re usually talking years to become an expert), and it may be a similar case with knowledge about a particular system or project.

This makes replacing people who leave the team more difficult, as well as affects flexibility when planning projects. You can’t just move developers from one team or project to another when the business changes priorities – you need to make sure they will fit in with their skills, and give them time to learn the insides of the other application. And for a complex system, losing a developer may mean an irreversible loss of knowledge for the company. This is a much higher risk than for most professions.

4. Developers can differ in abilities vastly

Another reason why you can’t easily replace a team member is the difference in their skill level. Being a great developer does not only mean delivering software a bit faster or with higher quality than an average one. Such person may actually be able to accomplish things that others won’t, e.g. due to the problem’s complexity or deep understanding of some technology that required years to master. For some types of software, you may not even be able to move on without hiring some top talent in the field.

5. Developers hate being managed

This point can obviously be related to other professions to some extent, but it’s the software development world where Agile concepts have gained the widest adoption so far. Because of that, many developers are used to working in self-organizing teams and are especially sensitive to attempts of interfering with the details of their work by management. If you don’t have a fresh technical background, better stay out of the way and trust your developers to make good decisions. Even if you do, avoid forcing the team to use your own ideas for technical solutions. Help your people grow, coach them and facilitate discussions, but allow them to find the path to building high quality software on their own.

boss photo

6. Developers’ work is a creative process

There have been many attempts to fit software development into manufacturing patterns, treating employees like factory workers that have a detailed plan and execute it in a predictable and strictly controlled way. So far no such process has been applied successfully on a larger scale, simply because writing code is a creative activity that cannot be defined, estimated and planned so easily.

Building software means solving a different type of problem every day, even for very typical, ‘boring’ business applications. There’s always some unexpected obstacles or issues to investigate, new technology aspects to understand, high- and low-level technical design considerations, not to mention writing complex algorithms or designing UI details. Each of these activities may depend on having the right idea ‘click’ in a developer’s head, and thus each of them may ruin a carefully crafted plan.

That’s why programming is difficult to plan in detail and estimates are frequently missed. There are also other implications, e.g. developers need to work in peace and quiet most of the time, to focus and eliminate distractions. However, they also need the freedom to discuss ideas in a group, consult solutions or get help from others. Think about it when planning the office space or coaching the team in communication practices.

7. Most developers are introverts

It’s usually estimated that between 1/4th and 1/3rd of the population consists of people with an introvert mindset, who are motivated by their internal thought process rather than interactions with other people (I’m simplifying greatly). Among software developers these proportions seem to be opposite. This has a whole lot of consequences from the perspective of a manager, starting from your daily communication with such individuals and their preferred work environment, to the way you deliver feedback for them and recognize their achievements. I am going to write more about this topic in future articles.

8. Developers don’t dream about a management career

Most people treat their job as just something they do from 9 to 5 to earn money. Then they go back home and spend the evening with their families, or engage in their hobbies, counting days down till the weekend.

But developers… They just love writing code and creating software. Well, not all of them, but many. It’s not frequent for an activity performed at work to be so interesting that you would eagerly do something similar in your free time – and developers are just that lucky. Because of this, many don’t even consider other roles and are good to work as developers for the whole career.

This means a bit different challenge from an engagement perspective. You won’t motivate a developer by saying ‘today you’re working on crappy stuff, but hey, one day you may become a manager of this mess…’ No, you need to seriously take care of ensuring that the work your people do is meaningful and interesting.

Summary

For the reasons described above, some of the generic leadership advice that we can learn from various sources will not apply to our industry, or at least it won’t be so straightforward. You might need to focus on different aspects than other managers, assume different priorities, and face problems that would rarely happen outside of IT or software development.

Do you have any observations of your own about this topic, or anything to add to this list? Please share your thoughts in the comments.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Management, Technical Leadership

8 Things You Will Hate as a Team Leader

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Are you aspiring to a leadership position? Here’s a few reasons why you may wish to reconsider.

This list is not meant to scare you away from a job of a team leader, but rather to make you realize the challenges that you will most probably face (sometimes even daily), and thus help you prepare for them. How you deal with such difficulties will not only impact your team’s performance, but also your motivation for growing further in this role.

1. No Direct Control Over Results

This might be the hardest thing you will learn during your first few weeks. As a developer, you used to have a direct impact over the end result of your work. When you didn’t put enough attention to your task, you got into problems e.g. with code quality and had to spend extra time fixing issues later. If you wanted to do something really well, it was usually enough to work hard on it yourself. While you were part of a team, most of the time your performance was assessed based on your own actions.

When leading a team, this is different. Your team’s results are your results now, and you can’t usually impact them directly. As one of my fellow managers put it (thank you, Gosia):

‘As leaders, we can’t control our team’s results, but we can control the behaviors that lead to the results.’

This is essential to understand and accept, otherwise you will keep getting frustrated by lots of things being done differently than you are used to, ending up micromanaging your employees. And that’s a short path to failure.

2. Giving Feedback and Punishing Employees

Giving feedback is an activity that should be happening all the time, and should not be limited to managers. For instance, developers have a frequent opportunity for that during code review sessions. The reality is different though, and many of us tend to avoid giving feedback, especially when it’s negative (constructive).

Here’s some bad news: it doesn’t become any easier when you’re the boss (unless you’re a mad tyrant, that is). It is something you’ll just have to learn to do effectively. Having difficult conversations frequently seems to be the only way to make it less painful. Also, be prepared for extreme situations, when you may have to punish or even fire a team member.

3. Increased Stress

Every job can be stressful, and it’s often a sign that you really care about the outcome – which is a good thing in general. However, as a leader, you will get into stressful situations much more often. A ‘comfort zone’? If you want to be good, you’ll need to forget what that thing is.

It gets easier over time and with more experience, there are also several techniques to reduce it, but it won’t go away entirely. Increased responsibility will always come with additional stress and one just has to learn to live with it.

4. Leader’s Loneliness

Partying together, sharing personal feelings and problems, making funny jokes? That may still happen, but don’t expect your employees to be as eager to do that with you after you become their boss. If you focused on growing relationships with them only, you may actually be feeling a bit lonely now.

We’re spending a lot of time at work, so many of us need to have some deeper relationships with other employees – regardless of how rich our social life is in general. Building such relationships with your new peers or other managers can take some time, and you may never really get that close with them.

lonely photo

5. No Longer on the Coolest Tasks

As a developer, you probably enjoyed work the most when you were dealing with really interesting, difficult or innovative tasks. As a leader you now should be letting others perform the most exciting ones. And it will hurt, for at least two reasons: you won’t be getting the fun from solving them, and they won’t get implemented in the same way that you imagined.

What can help you deal with that is realizing that every time you let your employees perform exciting work, their engagement rises, and your team’s results will improve thanks to that. Which will, eventually, lead to more exciting projects for the team and yourself. Possibly.

6. Limited Transparency

Transparency is the corner stone of many modern leadership models. Despite that, you won’t always be able to stay as transparent with your employees as you would like. For instance, there might be an important decision affecting the team, which your management doesn’t allow you to share yet (e.g. project getting closed, or department re-structured). Another scenario would be when you cannot share some information about one of the employees.

It is painful to watch your people’s efforts, knowing that they are not optimal (to say the least) considering the upcoming change, but the alternative of violating the rules is even worse. You’ll just need to learn how to cope with your own frustration, and how to maintain the trust of your team in such situations.

7. Can’t Be Liked By Everyone

If you are, you’re either a truly great leader, or a very bad one. It’s obvious that you can’t please everybody, and I don’t just mean your employees. A part of a leader’s job is to protect the team, and that will sometimes put you in a position of conflict with other parties (e.g. business stakeholders). Staying calm and explaining things patiently won’t always be enough – some people just tend to get emotional when things don’t go their way, and it may take some time before they understand your reasons.

8. Changing a Job

Good software developers usually don’t have problems when they decide to change a project or company. For leaders, the choice of truly interesting positions is much more limited. It may require a few months (rather than weeks) to find something that fits you really well, and that you’re a great fit for. Technical skills probably won’t be the deciding factor anymore.

In such role you’re also expected to stay longer at companies, showing that you can actually build something that lasts. Frequent job changes will make you much less trustworthy than in case of purely technical employees. Therefore, you should be much more careful when deciding to move, as well as choosing your next company.

Summary

I saw several people resign from a leader’s job after a few months because of the reasons listed above. For many they can be serious problems in the beginning, but I believe that once you accept them and learn how to deal with them, the role can become truly enjoyable for you. Feel free to share your own thoughts in the comments.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
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, Technical Leadership

3 Simple Code Review Guidelines

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

I have recently expressed my aversion to code review platforms. Assuming I managed to convince you, the next valid discussion point would be: if we’re not using a tool, how can we ensure the code reviews are effective and efficient? We could spend all night discussing the details of various approaches. While they always need to be aligned to a particular team and project, here is a shortlist of the main guidelines that proved to be beneficial in multiple projects for my teams.

Do it together. I’m a strong supporter of performing your code reviews in pairs. I believe you can get the most value with the least effort when both developers (code author and the reviewer) are looking at the same screen, talking to each other: asking questions, explaining, advising. The pairs should not be fixed, otherwise you will limit knowledge sharing and increase the risk of conflicts in the team.

Do it early. ‘Early’ meaning: as soon as your current task is coded, or even during its implementation (if it’s complex). The earlier you get a second opinion, the easier it is to change the code. While it might sound ‘unfair’ to ask an ‘innocent’ person to drop their work and review your code, my experience is that it actually improves the flow within the team. Try it and see for yourself.

Do it often. Daily code reviews can be very helpful in case of fast-moving teams that are building new systems. For maintenance-oriented teams you can adjust the period to fit the need. My preference is to keep the sessions under half an hour, so if they tend to overrun often, it may be a sign that they are not performed frequently enough.

FAQ

How can we ensure that code reviews are not missed in this approach?

Make them a part of your Definition of Done. If it’s enforced properly, developers will have to perform them before moving on to another task (the concept of Kanban WIP limits can be helpful here). A development task without a code review should never really be considered ‘Done’, as some reviews can result in significant changes to their implementation.

What if all code reviews are performed by the manager/ lead in our team?

If you’re that manager – stop it. You won’t keep up with doing it properly, and you’re taking other benefits off your team members. Coach your developers in reviewing each other’s code and offer your help whenever needed. Leading an inexperienced team can be more challenging of course and requires exploring additional techniques, but avoid putting yourself as the only reviewer – your goal should be to have a self-driven team, and that’s an important part of it.

What to do in case of distributed teams?

That’s simple nowadays – use a phone and screen sharing (yes, both audio and visuals – that’s very important). If your team is distributed, you should already have this figured out anyway. As with many other practices, avoid separate locations to be an excuse for limiting communication within the team. It’s not the same as with face to face reviews, but try getting as close to that as you can.

But we’re already doing pair programming…

In that case you should already be getting most of the benefits described here – assuming you’re applying the practice properly (I may write about it one day, too). I would still recommend to occasionally bring in a 3rd developer to have a fresh look at the critical pieces of the code, but in general your team is in a much better situation already.

Summary

At the end of the day, it’s important that you promote a culture of close collaboration and open discussion in the team, and the way code reviews are performed can have a significant impact on this matter. If people avoid discussing with each other and hide behind a tool, that’s going to cause more and more problems in the long-term. Instead, follow a light but strict approach of frequent, short reviews performed in pairs, giving an early and direct feedback about the code changes.

Please feel free to describe your approach to code reviews in the comments.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard