It used to make little sense to me. Every year, when performance reviews were due, my organization evaluated everyone on several skills. Leadership was one of them.

I would wonder: “Leadership? Everyone? How can I score an individual contributor on leadership? It’s not their job to inspire, motivate, and guide others. Why don’t we only score the team leads and department leads on leadership?”

A woman explaining something to a colleague on her laptop screen

It was only later, when I had been a team lead myself for a while, that I began to understand why it makes sense to make leadership a part of performance evaluation. As a team lead, you become more consciously aware of certain things about your team that you, subconsciously, already knew.

One of these things is that you can let some people on the team just run, and they will get things done. Others need some monitoring and some guidance.

Then there are yet others who surprise you in curious ways. They remove obstacles and align with other teams before you know there were obstacles or that there was alignment needed. They step in when they see somebody going down a wrong path. They offer a workshop because they see that several team mates lack a crucial skill they can teach. They do the necessary research when they lack an answer. They deliver outstanding work that inspires others to reach the same level of quality.

These precious team members are not managers or team leads. They are individual contributors. And yet, they exhibit leadership. This taught me:

Leadership is not tied to a position. Leadership is a mindset.

This mindset separates good employees from excellent ones. Leadership-minded people proactively improve and develop their environment — their product, their codebase, their colleagues, their teams. Over time, these little improvements multiply and make a huge difference.

If you are an individual contributor, and you want to be in a leadership position, you can start today by exhibiting leadership in the following ways.

1. Leading by teaching

Teaching colleagues

A couple of weeks after he started, Patrick, a new colleague on the team, joined a discussion among some developers. Our build system was lacking, our JavaScript was getting out of hand, and we had to find a way to make the system more maintainable. Patrick suggested we use webpack, which, at the time, was still relatively unknown. He told us about its benefits and taught us how to use it. Together, we made a plan how to introduce it, and how to gradually adapt our technical processes to take advantage of its amazing code-splitting feature.

Patrick quickly became the authoritative source for all things webpack and JavaScript, because his expertise was simply greater than that of anybody else. He did become a team lead later on, but long before that, he was already a leader without a title.

Teaching is a great way to have a lot of impact, because you act as a multiplier. It is also a way to establish yourself as a leader. There are several kinds of leadership, and knowledge leadership is an important one of them — especially in technological fields, since they evolve so rapidly.

Now, if your current expertise does not dwarf that of your colleagues, don’t worry. That’s rarely the case, and it’s a good thing, because it would put quite a lot of stress on you.

However, I’m sure you can find some niche where knowledge is lacking on the team. In such a fast-evolving field as ours, new topics spring up all the time, and initially, nobody knows much about them. This is your opportunity to get one step ahead and take over the work of spreading that knowledge.

Give a workshop or a presentation in a guild meeting. Pass the knowledge on in a way that is filtered and tailored to your organization. Make the knowledge actionable. This way, you can save the others a lot of time, which increases the value you bring as a team member.

2. Leading by example

Rebecca’s team had a data integrity problem. It affected only a couple of dozen records, out of tens of thousands. It would have been easy to ignore the problem, because it seemed rather small, and there were more pressing things at hand.

However, Rebecca wanted them, as a team, to be thorough. She knew that this kind of symptom sometimes points to a larger problem that is looming underneath the surface, which can suddenly emerge and cause real trouble. Therefore, she did some investigation herself, and discussed her findings with the team. They came up with a solution, and scheduled its implementation for one of the following sprints.

By exhibiting the behaviour she wanted to see in the people around her, Rebecca influenced the agenda of the team, and showed them what is possible if you work thoroughly and go to the bottom of things. This is behaviour that others mimic if they see it consistently.

If you show hard work and passion, you will inspire the people around you to do the same. Show how important a task or project is to you by putting in your best work. If you want others to show up on time, show up on time yourself. If you want others to go the extra mile, go the extra mile yourself.

This is setting an example, and it is an effective form of leadership.

3. Leading by setting high standards

A pole vaulter crossing the bar

Marcus had already put a lot of time and effort into a task, but his solution was not working for some edge cases yet. He suggested that these edge cases were not that important, so he could neglect them. However, the edge cases happened frequently enough, so Katya, another developer on the team, did not think they could be skipped.

She asked him to find a solution and gave him some words of encouragement. She said it was good for his development as an engineer to deliver a complete solution, and she made the point that the edge case behaviour was confusing to our users.

So Marcus found a solution.

Most people want to deliver high-quality work. However, under high workload and time pressure, many will be tempted take shortcuts and compromise on quality. They think that people rather expect them to finish quickly than to deliver a high-quality solution. In these cases, it helps when they have somebody to hold them accountable, to encourage them and to remind them that they can do better than that.

No matter the job title, this somebody acts as a leader by reminding their colleague of the high standards the team should aspire to. In the story above, Katya exhibits leadership. So can anybody, so can you.

Careful, though: You will only be able to hold other people accountable to high standards if you hold yourself at least to the same standards. Otherwise, you will not be credible. In this sense, Leading by setting high standards and Leading by example are two sides of the same medal.

4. Leading by communication

A woman explaining something to her colleagues

There are some roles that are excellent for exhibiting leadership by communication. For example, product managers are in such a position. They are the central hub that connects stakeholders, developers, designers, QA, business intelligence, and potentially others. They aggregate an overview of what is happening where at what time, and make sure everyone has the information they need.

This could mean ensuring that the development team understands the big picture and the long-term vision. They will produce better work if they know how their part fits in with the system as a whole, so this is important information.

Or, when a new feature is started, the Product Manager demonstrates why it is important, and how it fits in the current strategy.

Or, when developers do not know how their software is used, the PM should connect them with the stakeholders and promote exchange between the two groups.

In these situations, communication makes all the difference. In groups and organizations — and this can start with as little as 10 or 15 people — many things go wrong because the teams who should talk to each other don’t talk to each other.

Sometimes, this is because there are no clear responsibilities.

Whose job is it to talk to the Marketing people about the campaign they want to launch, promoting our feature that has just become more complicated, and will therefore be delayed?

Whose job is it to talk to operations because the technology they want to introduce will not give us what we need?

In a lot of cases, the answer is “everybody’s job”, which is pretty much equivalent to “nobody’s job”. This is a great opportunity for you to fill the gap and demonstrate leadership.

But it is not only as a product manager that you can exhibit leadership by communication. If you are a developer, the same principle applies. When there is no dedicated communication spokesperson, you can create a lot of value by helping critical information reach those who need it.

Once in a while, ask yourself if your team’s activities might impact other teams so that they should get a heads-up. If yes, pick somebody from that team and politely ask them if they are interested in information about your team’s plans.

Vice versa, try to imagine which activities outside your team might affect you, then try to find out more about those activities by talking to people. Many developers are too comfortable or shy to do this, or they simply think it should not be their job. Therefore, this is a great opportunity for you to create a lot of value, and to set yourself apart.

5. Leading by giving credit

Two persons shaking hands

Yelena had just finished the rewrite of a major feature within two weeks, an achievement that nobody had thought was possible. However, the colleagues were all busy with their own things, so nobody made a big deal out of it. Yelena is rather quiet and does not like to self-promote, so her big win went largely unnoticed.

Except that Carl saw what she had done, and was deeply impressed. He approached Yelena and congratulated her for her achievement. Moreover, he made their manager aware and suggested that he write a thank-you email, and to mention her achievement during the next team meeting.

The American businesswoman Mary Kay Ash once said:

“There are two things people want more than sex and money… recognition and praise.”

In the workplace, there is often too little of this recognition and praise. Managers take their people’s achievements for granted, or are too busy with other things to notice. Some think they would spoil their team by being “too liberal” with praise. Among peers, colleagues sometimes feel awkward praising each other, or do not think it’s necessary.

We’re all professionals here, right? No need for this touchy-feely stuff.


Everybody needs acknowledgement, and there is nobody stopping you from giving it, no matter if you are a manager or not.

If you make it a habit acknowledging behaviour you like to see in your colleagues, you can contribute a lot to an appreciative and positive team culture, where individual wins are celebrated as team wins.

Don’t know where to start? Here are some ideas for things that deserve acknowledgement:

  • Cleaning something up without having been told to do so
  • Having the courage to take over the moderation of a meeting for the first time (in general, when was the last time you thanked your meeting facilitator for a good moderation?)
  • Writing documentation that was long missing
  • Organizing a team event
  • Making the team aware of a critical change in a dependency
  • Checking out a new library and assessing if it is useful for your team
  • Maybe the most common one: Doing good work

People do one of these every day, so there are lots of opportunities to give credit. If you start doing it, you will set in motion an upward spiral as other people will mimic your behaviour, and people will be much more willing to do their best.

6. Leading through code reviews

Two women going through source code together

In the busy-ness of the office, our first reaction to being added as a reviewer of a pull request might not always be pure joy. Another box to tick, another task to discharge ourselves of. Another distraction when we already have enough work to do.

However, we should think twice when it comes to code reviews. This is where our engineering culture manifests itself. If you want to influence how engineering is done in your organization, code reviews are a great place to start.

They offer an opportunity to encourage people to follow best practices, or to be more thorough.

They are a place where you can praise and reinforce good work — code reviews are not only for critical feedback.

They are a place where you can share your knowledge, and where you can learn from others.

They are a place where alignment starts, and company-specific best practices crystallize.

That said, good code reviews take time. It’s not about “the indentation on line 7 is wrong”, or “there should be a space before the parenthesis”. That’s what Prettier is for.

No, code reviews are about how well the new code fits with the existing application structure, about problem break-down, about interface design, about clarity of function names, about re-use of existing functionality, etc. They are done to preserve the health of your code base. If code review is done sloppily, your code base will deteriorate more and more. That’s why it takes leaders like you to take this job seriously.

Even if it takes time, the time is well spent. More than once, I have seen a new feature go live that was practically legacy code from day one. That was because the subteam who built the feature reviewed each other’s code, and they all had the same way of writing code. Therefore, there was never much argument or objection around those pull requests, when there should have been.

Tread with care, though, if you decide to become more active in code reviews: People can react in sensitive ways if you do not communicate very deliberately (and sometimes, even if you do). Therefore, follow the best practices for code reviews.

Try to understand the reason why something was done a certain way. Was it intention or a lack of knowledge?

If you criticize, stay very concrete and give reasons why you think a certain solution is not ideal. Share your point of view (“I think this is not the best solution because …“) instead of using absolutes (“The way you do this is just wrong!”).

Give suggestions how to improve, but don’t solve the problem for them.

Criticize the work, not the person.

Maybe most importantly, be willing to be proven wrong. Usually, people have thought about their code more than you have, so they might see aspects to the problem that have not occurred to you yet.

7. Leading by going into hard conversations

Two people having a serious conversation

James was giving a presentation. Melanie knew that he had put a lot of work into it, and that what he was presenting was important to him. She also noticed that Bob, their manager, was not paying much attention. He had his laptop open, and was busily typing.

Melanie knew that James noticed. She was unsure: Should she talk to Bob or not? She was a bit afraid the conversation might be tense and awkward. After all, he was the manager. However, she also had a rather good relationship with Bob. In the end, she decided to do it anyway.

She told Bob what she had observed during the presentation, and that his behaviour had come across to her as disinterested. She told him how much effort James had put into this presentation. Bob thanked her for her feedback. He was not aware that people would take it as disinterest, or even disrespect. He said he would leave his laptop closed next time, and his phone put away.

In this example, Melanie acts like a leader. She observes damaging behaviour, as most people in the room probably do. Most people, however, leave it at that. They talk to each other about it, rant about how disrespectfully Bob was behaving, and either tacitly assume he is aware of this and does not care, or that telling him would not make a difference, anyway.

Melanie acts differently.

She makes sure a critical piece of feedback reaches the right person. She is aware that the conversation might be difficult, but she decides to have it anyway. She knows that if she does not do it, probably nobody will, and Bob will remain unaware of the detrimental effect of his behaviour.

Melanie takes responsibility for the team atmosphere, for team etiquette, and for how teammates interact with each other. If you will, this is the communication version of “Leading by setting high standards”: She encourages Bob to show better communication and meeting discipline.


Some management gurus demand that everybody in an organization be a leader. I have never felt quite comfortable with that idea, because I think true leadership — defining the vision, inventing the future, communicating this vision to everyone and getting them on board — is a full-time job. If everybody was doing that, nobody would be left to do the day-to-day work, and we would end up with a lot of contradicting visions.

However, if we look at these seven different ways to exhibit leadership in everyday situations, we can interpret the management gurus’ vision in a more useful and more realistic way: Everybody should find some way to exhibit leadership, and cultivate this until it becomes a habit and they naturally do it.

My guess is: If you pick one area in which you feel most comfortable to show leadership behaviour, and you push yourself to improve in that area, sooner or later you will also start leading in other areas — maybe even in areas that you did not expect.

Therefore, starting with just one area — and there are many more possibilities than I have illustrated here — is a great way to go down a path toward a “real” leadership position.

Take the first step!