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
Links

Leadership Links Mashup #4

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

A selection of the most interesting leadership resources that I have recently encountered (both general and IT-related). Feel free to submit your own proposals in the comments.

18bbdcca6181b9b695db396d_640_manager

General Leadership links

IT Leadership links

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

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
Links

Leadership Links Mashup #3

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

A selection of the most interesting leadership resources that I have recently encountered. Feel free to submit your own proposals in the comments.

manager photo

General Leadership links

IT Leadership links

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Management

The Power of Small Actions

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

It often takes a lot of effort to improve one’s results. You have to overcome large obstacles, gain vast knowledge in a new area, or spend a long time working really hard. However, it’s not the only way to grow. One should never underestimate the power of repeated small actions or decisions, accumulating over a long period of time. I believe it’s one of the things that differentiate solid performers from great achievers. And it applies to management, too.

mountain water photo

Imagine that you can find just a few minutes per day to read 5 pages of a book. That’s 150 pages per month, translating to at least one extra book per quarter – or 4 books per year. Quite a bit of knowledge for such a small investment, don’t you think? And it can give you a significant advantage over people who prefer to spend those 5 minutes procrastinating.

Consider the below examples of small extra actions that can make a difference when performed frequently:

  • Making just one more phone call, to check if your project’s dependency is on track.
  • Asking just one more question at a meeting, to ensure somebody takes ownership of a particular action item.
  • Staying a few minutes longer at the office, to push forward a non-urgent improvement.
  • Mentioning that too-simple-to-be-true solution for your employee’s problem, just in case nobody actually tried it.
  • Reading a single article from your professional area while commuting or waiting in line.
  • Sending a quick reminder to someone who committed to help you, to avoid a bad surprise at the last minute.
  • Writing down that idea wandering around your head, so that you won’t ignore or forget it.
  • Giving one more bit of feedback to your employee, to make them aware that their behavior (good or bad) was noticed.

As you can see, many of the above don’t really require you to invest time, they rather rely on your consistent commitment, preference of clear and explicit agreements, avoiding open-ended topics, and so on. Of course these activities won’t replace your everyday hard work, or any of the other success factors. Such approach is just an addition – yet a very powerful one.

I wonder what are your own ideas for such small extra efforts? Please share them in the comments.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Management

3 Wrong Reasons For Moving Into Management

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Following my post about reasons to become a technical leader, let’s now examine the most commonly wrong reasons that make some software developers chase the management path and inevitably fail not long thereafter.

Money

You expected this, didn’t you? There’s nothing wrong with an urge to earn more money, but if it’s your main goal then you will most probably fail. Managers can typically have a much higher salary than developers, but not all of them do! Poor leaders can lose their job or get stuck at the basic management level, while good developers gain more technical skills and experience, eventually landing more profitable projects or jobs.

sports car photo

If you have a true passion for programming and you dream of a long technical career, you should look for other ways to make more money as a developer. It may not be easy, but trust me – being a manager is even harder when it’s not really your calling.

Power

Having the authority to make decisions for your team can seem tempting to some people. However, by now you should have realized that in a market economy, especially in industries such as IT, this type of power is an illusion. Good developers – and that’s the only kind you want on your team – will not hesitate much before leaving their bosses when they don’t feel respected. You can be sure they will have plenty of offers, and you won’t compensate for a bad job with higher salary or other benefits in the long-term. Also, what is the meaning of such power if you don’t have any followers?

Respect

Are you kidding me? Nobody respects their boss just because of their position, it always trails their actions. Your employees may fake it for some time to avoid trouble, but if you’re not good at this job they will consider you as an obstacle on their projects. You won’t be respected until you change your attitude, and adding ‘Team Leader’ on your business card certainly won’t make that happen.

Summary

The reality is that many of us care about the above aspects – we want to earn more money, be respected, and so on. There’s nothing wrong with that. However, these should not be the main forces steering your career, otherwise you may wake up one day feeling that you wasted a few years of your life doing something that you hated, and were not even good at. As a result you could be hurting yourself and your co-workers. Think these through, no matter what decision you make, or path you follow.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Links

Leadership Links Mashup #2

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

A selection of the most interesting leadership resources that I have recently encountered (both general and IT-related). Feel free to submit your own proposals in the comments.

leadership links

General

IT

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