cto.coffee - Let's talk humans & tech

Leadership as an Individual Contributor

Mon, 11 Mar 2019 00:00:00 +0000

Leadership as an Individual Contributor

Or: How to lead if you’re not a manager

In the time of empowered and self-organizing teams, it feels like a given, that everyone should be taking on leadership. Not only the people in management positions. Some organizations even require their teams and senior developers to “be leaders”. Without giving them any kind of formal authority.

But, like many others I’ve asked myself already: What does leading mean? How do people, who don’t have explicit authority handed to them, show leadership?

So, when I discovered Tom Bartel’s post “How to Exhibit Leadership as an Individual Contributor”, I felt excited. It felt like “Finally someone answers this age-long question” to me.
In his article, Tom gives very good guidance on how to lead without formal authority. He lists several behaviours that all contribute to being a leader.

Yet, I find some leadership aspects are missing from his list. I’ll try to describe these in my opinion crucial aspects below.

Please be aware, when reading my points, that I’m not disagreeing with Tom. Some of my points are already contained in his list of behaviours. But it’s important for me to emphasize different aspects of them. All in all, I’d like you to understand the below list as a supplement to Tom’s list.

Put your team and its deliveries first

“Software is a team sport” or as Yulia said in the most recent cto.coffee episode: “Coding is predominantly a social activity”.

From this follows: The output of a team as a whole is always more important than the output of a single individual. No matter how experienced or productive that single individual might be. And as such, one can exhibit leadership, by putting their team’s output before their own.
So, measure yourself by your team’s output, not by your own output alone. And you sure are on the right track to show leadership.

But be aware, that depending on your team, this might result in your own work getting less recognition. Because you might do work, that’s not as tangible as code. Such as writing onboarding documentation for new developers. Or you might make a process explicit by writing it down. Or you do a pair programming session with a peer on your team and help them get better.

Be proactive and take ownership

Taking ownership is closely related to “Put your team and its deliveries first”. One might say, the one is even a subset of the other. Still, proactiveness is important enough to warrant standing on its own.

There are challenges and problems in every team. And you can show leadership, by addressing these challenges and acting on them.
Acting on problems and challenges can take many forms. It ranges from raising the issue with your manager or in a retrospective and following up on it. Or if you’re able to fix it yourself, make the time and do it.

Please be aware though, that not taking action on a problem you see, does not mean you don’t care or do not take ownership. Reasons for not acting on challenges you perceive can stem from various reasons.
But if you feel comfortable, have the means to address problems in your team and do it: Then you’re on the right path to demonstrating your ability to lead.

Have an eye on the big picture

It’s very common, that some members of a team slide into a kind of tunnel vision after a while. Especially individual contributors make this tunnel vision their own. After all, it’s considered as productivity, if they spend the largest part of their day in the details of code.
But it sure leads to problems, if nobody is having an eye on the bigger picture.

So, you can lead, by breaking out of this tunnel vision from time to time.
Do a check of the current position of your team, with regards to where it should be at and where it should be going.

Bonus points, if you see a deviation between the current state and the wished-for state, and you have suggestions on how to fix it. Yet, realizing there’s a gap is more important than coming up with ways to fix it on your own. More often than not, it’s good practice to involve your team in finding a solution. If only to avoid putting too much effort into an idea, only to not see it supported by your team.

Make sure everyone is heard

By now, it’s a given, that diverse teams are not only the right thing to do but also a smart thing to do.

So to make the best out of your team, you should make sure their knowledge and experience is used. After all, what good does it do, if you have smart people on the team, when they don’t contribute?

A good first step to do that is to make sure everyone on your team is heard. And I really mean everyone’s opinion should be heard. If the matter is relevant to them. You can exhibit this kind of leadership behaviour, especially in team meetings. Start by asking everyone around, before making a team decision.

Of course, this does not mean, everyone should have a say in the tiniest decisions. Rather, leaders ensure that everyone who is affected by a decision has a say in that decision. Leaders make sure no one is not drowned out by other, louder voices of the team.

Seek out differing opinions and solutions

One can exhibit leadership by seeking out opinions that are different from their own.
These differing opinions don’t necessarily have to be from people on the same team. Rather, they can come from all sorts of places.

When seeking out and receiving these opinions, one should also not only tolerate them. If anything, one should listen to them actively, and actually consider them.

The goal of this is to make better-informed decisions. Decisions that are based on more diverse opinions and viewpoints.

Bonus: Lead by example

Diligent readers will notice, that Tom’s list already lists “Leading by example”. So you would not be wrong to say, this is not an extra point to Tom’s list.

Nonetheless, this one is so important that I need to list it too. Plus, it’s kind of a multiplier to all the above-listed leadership traits.

That is, show any of the above traits in a way, that makes other people on your team want to behave in the same way. Then you have the strongest indicator, that you are a leader.

It’s hard to emphasize this enough. You don’t have a formal authority of an organization bestowed upon you? Yet, people follow what you do? Then you are a textbook definition of a leader!

Addendum

Also, I recommend the book “Manager’s Path” by Camille Fournier. It goes well beyond what I describe and does so with way more eloquence and depth.

Apart from that book, I assume there must be way more resources, be it books or blog posts, on this topic than only Tom’s post. The most I could find until now, where about explaining leadership in general. And not so much for individual contributors in software/operations teams.

So I’d appreciate it a lot if you send other resources in this space my way on Twitter or contact me.

Disclaimer

I’m aware that reality is messier and more complicated than the shiny, easy world of everyone being a leader. So please don’t understand the above list as any kind of checklist one needs to fulfil in order to get recognized as a leader.

Rather, be aware that systemic and unconscious biases affect how you perceive people.

Biases may result in you perceiving behaviours of some groups of people differently than the behaviours of people from the group that’s most common in your organization.

You might not perceive people from underrepresented groups as leaders. While they may actually be leading. So, consider sponsoring people from underrepresented groups, to compensate disadvantages these groups experience. Plus, consider looking into overcoming systemic and unconscious biases, and learning about related concepts such as the glass ceiling.

On the Structure of One on Ones

Wed, 09 Sep 2015 23:20:00 +0000

On the Structure of One on Ones

This article has been cross-posted from squeakyvessel.com

This is a continuation of my previous post, in which I covered the goals and purposes of One on One Meetings

Prepare - Choose a Theme
Listen
Status Update
Conclude with Something Actionable
Dream Big
How Long is a 1on1?
TL;DR

Over the course of those last two years, I found a structure for having 1on1 meetings that helps me a lot to get the most of these meetings, and which also helped to make 1on1s a deeply ingrained part of vaamo’s tech team culture.

Structure

All of the below elements, can be used on their own and you don’t necessarily have to do all of them in every meeting. But of course to some extent, used together they are stronger than each of them is on their own.

If you’re starting out doing 1on1s with your team, I suggest you start out with one element only and over time add more elements.
They’re ordered in a way that each element builds upon the previous ones and expands them in a sensible way.

Prepare - Choose a Theme

While some posit that 1on1s are the employee’s meeting and I’d generally agree with that statement, it’s your job as manager to have your team member’s back and make sure the 1on1 is useful in any case.

Photo under "CC BY 2.0 License" by Photo Monkey

By that I mean, you should at every point in the 1on1 be able to take the lead and steer the meeting into a direction that’s useful to you and your team member. Proper preparation can enable you do to that.

What worked very well for me, is to set a theme beforehand. Think of a theme that gives you both valuable insights.
Have you talked about how the team could improve lately? Do you know who your team member thinks is doing a great job on the team? Why? Do you know what they think of your management style? Do you know where they’d like to be supported more? Do they have a grasp on where they’re going with their career?

Having a regular direct line to your team via 1on1s is a powerful tool to get an intimate view into the opinions of your whole team. By setting a theme and asking everyone the same or a similar set of questions in their 1on1s, you can get a good picture of how your team feels about certain things.
In my recent experience, it was immensely helpful to know what made everyone on the team feel productive, by asking everyone in their respective 1on1 the same set of question, which was “Do you feel productive in your day to day work? What makes you feel productive?”. The answers enabled profound changes and increased happiness across the team, and event after quite some time now still prove very helpful in designing processes.

Jason Evanish has an exhaustive list of questions for 1on1s, so does Lara Hogan who has a great list of Questions for your first 1on1. Popforms even provides a service to deliver a set of matching inspirational questions to to your and your team member’s mailbox at a specified interval.

Listen

This is somewhat an antithesis to the previous structuring element, but nevertheless very if not more important.

Photo under "CC BY 2.0 License" by Matthew G

You, as a manager, should spend most of the time listening to what your team member has to say. And by listening I mean to really try to understand what the other person is saying, by putting your own definitions and opinions into the background.

Look out for moments where you’re waiting to release an already prepared answer to whatever your counterpart is saying at the moment, while they’re still speaking. In those moments you think you know what the other person is saying. But really all you’re doing is reacting to your pre-defined notion you have about the other person.

Status Update

An important purpose of 1on1s is to get to know your team members’ views and feelings about various things. And among “those various things” are also, let’s be honest, current projects and tasks.

Photo under "CC BY 2.0 License" by Pedro Ribeiro Simões

Everybody says “don’t use 1on1s for status updates”. But sometimes that status is the thing that’s on everyone’s mind. So it’s simply not practical to not exchange that update.

The most sensible thing you can do, is to make that update useful. Which in my experience is done by limiting the time you spent with this update and by getting the unique perspective of your counterpart on the subject. Make sure you don’t spend time on defining and discussing concrete actions about the current work, that should be postponed to be done later, even if directly after the 1on1.

So, don’t be too dogmatic on your definition of 1on1s but rather make sure it’s useful for everybody.

Conclude with Something Actionable

The temptation is high to end the meeting, when you both feel there’s nothing left to say. You possibly exchanged your views, at least you listened and deepened your understanding of some area. You’re feeling all fuzzy, because everything’s great. You’re awesome, your team member is awesome. And that’s it.

No! Don’t do that.

Photo under "CC BY 2.0 License" by Steve Slater

Take those extra 5 minutes if you will and decide together what the next action for each or both of you should be. How can each of you make the next minor step to improve one of the possibly many topics that was touched upon in that specific 1on1?

Ending the 1on1 with some concrete actions, something that you can both be held accountable to, is super important. Because it will bring constant progress into your relationship with your team member. It will be one of the most natural things for both of you, that over time you keep on making things better for both of you.

But the rhythm of constant smaller actions, is also a great tool for building trust. By constantly “showing up”, delivering on the agreed actionables, trust will become a natural part of your relationship with your team member.

Dream Big

Having 1on1s and with this a regular point of contact, you and your team member have a venue for working towards a larger, possibly far away personal and/or career goal.

Photo under "CC BY 2.0 License" by Kai Lehmann

In most circumstances the product and what the company wants to do and achieve is more or less well taken care of and worked towards. But when a single team members personal development and career goals (or at least a direction in which someone wants to go), it’s hard to place it somewhere it receives continuous progress. And the rhythm allows you to chip away at this far-away looming mountain of work. One step at a time.

Hot Topic: How long is a 1on1?

One of the minor but constantly asked-first questions about 1on1s is about the length of the meeting. “How much time should we spend on the 1on1?”

Photo under "CC BY 2.0 License" by valentin.d

Obviously the only right answer is a “depends”.

I’ve read a lot of articles over time, where people mention 30min per 1on1 with a weekly or bi-weekly schedule.

Personally I prefer longer but slightly less-frequent 1on1s, and currently my 1on1s are 1h long and we do them bi-weekly. I prefer this schedule, as I feel that some topics, especially the hard ones, need time. The really interesting stuff always happens sometime into the meeting, when people become more relaxed. But that may very well be related to my personality, as I’m more the kind of person who likes to take it’s time with hard topics.

TL;DR

If you’re not doing 1on1s yet with your team, I strongly encourage you to start doing so. And if you’re not sure yet, take a look at the why behind 1on1s.

When starting out, begin with only a few practices outlined above and extend over time. Time is on your side when doing 1on1s. If you stick with them, you’ll have lots of iterations soon and can expand and play with the format sooner than you think.

On the Purpose of One on Ones

Thu, 21 May 2015 11:38:00 +0000

On the Purpose of One on Ones

This article has been cross-posted from squeakyvessel.com

I’ve been leading teams for little over seven years now. Almost right from the beginning of that time I reserved timeslots, to sit regularly & privately with each of my team members. My motivation back then was to give every team member a regular opportunity to tell me what’s bothering them.

Looking back, that motivation was deeply rooted in the most common emotion I had in my job at the time, and which I assumed all others had too: Frustration.

I assumed what people needed most was a place to vent (thanks rands, for that nice word) and the feeling of being heard. It took me some time to realize I wasn’t using that private time with my team members to it’s fullest potential.

Since I started working at my current role two years ago, I started to give the purpose and structure of those private meetings more thought. You could say, I started doing 1on1s according to a currently predominant definition¹.

Below, and in a follow-up post, I’ll share what set of goals and which structure for 1on1s worked well for me.

Purpose

Ask a manager what they think are the goals of 1on1s and you get a different answer everytime. This one is probably no different.

For me the purposes of 1on1s are manifold, but they all revolve around: Create trust! Between you and your team member.

Build a relationship

Trust can only exist in a relationship. So, the first step towards building trust is building a real relationship with your team member. One where you’re really interested in the opinions and feelings of the other person, and not the least the person itself.

Actually, in the beginning I thought 1on1s were about having a deeper, real, human relationship with the members of your team.

And while of course this is not wrong, it’s not the whole story. After a while, I realized, that the purpose of having this relationship is to put you, both yourself and your team member, into a position where you can trust each other.

Provide a safe space

Over time, trusting each other will turn into something really beautiful: Your 1on1s will become a safe space. Again, for both of you.

This safe space will enable both of you to bring up every topic you chose. It will enable you to sometimes give the inevitable not-so-positive feedback that your team member should hear. And it enables your team member to do the same. To tell you when they think some things aren’t the way they should be.

Having this safe space, puts you in a position to fix problems when they’re still small. Instead of having to fight those big fires that can bring on a lot of trouble.

Long-term Goals and Career Development

Having a safe space and trusting each other is the perfect foundation to talk about the long-term goals and the ways your team member wishes to develop their career.

And you should use that foundation. It is a powerful building block of making your team member happier, making sure they feel they make progress toward something that’s meaningful for them in the long run.

In the end, also towards retaining them as a member of your team.

Continuous Improvement

Once you care about the long-term and career development of your team members, you’ll need to make progress on it.

Not only, because of the Progress Principle:

By supporting progress in meaningful work, managers improve employees’ inner work lives and the organization’s performance.

There’s nothing that boosts your team members’ happiness and productivity more then perceived progress, no matter how minor.

This means, one goal of your 1on1s should be to enable continuous improvement and progress. Your 1on1s can be the rhythm that will make progress and improvement come almost naturally.

Give Feedback

I’ve stated it above already, but this deserves to stand on it’s own.

One goal of your 1on1s should be to give honest feedback to your team member. Simple as that.

Why in a 1on1 and not during your normal working day? Because there are more than enough reasons and circumstances where it’s not appropriate to give feedback right away. Be it, that your team member might feel embarassed by the feedback, or that you simply don’t feel there’s enough time right at this moment to give the feedback fully and properly.

Structure

I’ll share a structure of 1on1s in my next post. You could say, my way of doing 1on1s.

… to be continued.

Possible definitions, even if they’re not meant as definitions, are such as “Manager’s Guide: How to start one on ones with your team” on getlighthouse.com and “The best 30 minutes you’ll spend this week: how to do a one-on-one that really counts” from popforms.com. ↩

Mature Developers

Tue, 12 May 2015 21:28:00 +0000

Mature Developers

This article is cross-posted from squeakyvessel.com

Some time ago, as I started to spend more time on growing our tech team at vaamo again, I realized that I had put off one thing for much too long already: Putting down my definition of maturity and technical leadership in software teams.

In order to get this finally sorted out, I’ll lay out the aspects that together make up a mature developer.

What Defines a Mature Developer?

A developer’s maturity is mainly defined by their soft-skills, less so by their technical abilities and knowledge.

The assumption underlying this postulate being, that it’s very unlikely for a person to combine most of the below mentioned maturity traits without going through some years of working in teams, in which the technical skills will likely get sorted out one way or another.

But what actually are those characteristics, soft-skills that make up mature developers?

Mindfulness

Mindfulness is a simple practice that can be described as paying attention to what is going on in the moment, without judgment.

And I strongly believe there’s a meaningful correlation between one’s ability and willingness to pay attention, to self-reflect and their ability to improve themselves and those around them.

So one of the first and most important qualities of mature developers is they’re more often than not paying attention to what is going on around them. They’re deliberately taking their time to observe before proceeding (put succinctly as STOP; Stop, Take a breath, Observe, Proceed).

Mature developers are being mindful about themselves and their surrounding, in order to be able to always keep improving their own work and approaches, and of those around them.

Mindfulness sooner or later leads mature developers to become aware of, learn about cognitive biases and find ways to handle them.

Curiousity

Technology work is creative work. And I simply can’t imagine someone being good at it, by any measure, without being curious. Curious about the surrounding technology, about how things work, about why things are the way they are etc etc.

And this curiousity should not diminish over time. Rather it should always grow alongside maturity, as one is exposed to more problems, technologies and people over time.

And it’s also important that this curiousity is not limited to technical topics only. Mature developers are curious about people, how they tick, what’s interesting to them and much more.

Pragmatism

The necessary counter-balance for curiousity is pragmatism. As one is curious about almost anything, they usually need to choose quickly about what’s important and when it’s important.

More generally, a pragmatic developer weighs possible options in terms of long-term impact and costs vs short-term benefits.

However, what’s hard about this skill, is that it’s very much driven by intuition. After some amount of experience, one has a basis to which current decisions can compared, in order to decide for outcomes that are less likely to work vs those that have a higher chance of success.

Pro-Activeness

Personally my first and still trusted indicator of a good developer is pro-activeness.

Someone who is pro-active communicates early & often. When discovering new information, learning something new they think about who this new information affects and act on it.

Furthermore pro-active developers seek out risks, they see chances way before they are obvious for others, which can help a team succeed much faster and more easily.

Where should the systems that people are working on lead to? How do you know it’s a success? What’s there to do, beyond the obvious stuff, that’s needed to get features out the door in the next three months and beyond and what’s the thinking and reasoning behind those visionary aspects?

Not the least part of having this technical vision is then also to actually share it with relevant people. Ideally with anybody who is even remotely involved in working with or shaping the system in the future. This means people like product managers etc should also know about the vision.

Sharing the vision with other involved parties not only serves as a perfect opportunity for practicing one’s skills to explain deeply technical terms and circumstances with non-technical people. It also serves the purpose to validate the vision in terms of relevance to business value and other aspects.

Understanding Business Value

Mature developers know and understand at every turn, that everything they do serves the purpose of providing value to someone else, most of the times some kind of business and with that, some kind of customer.

They’re able to put everything they do into a greater context of their business and understand how their current and future actions play out into this context.

Because of that they can empathize much better with non-technical people. Which in turn enables them to communicate and explain their actions and motivations more easily and usually concisely to non-technical people, and reduces friction when working with non-technical people.

Reasonable Risk-taking & Decisiveness

Putting their actions and plans into a bigger, non-technical context also enables mature developers to better assess risks. For example, does the risk of introducing a new technology possibly outweigh the business benefits that are to be expected?

Assessing and understanding risks better puts them into a position where it’s also more likely they’ll actually take risks. Risks which, without the knowledge about business value and the bigger context, may look too big to be worthwhile. But not for mature developers who are able to see beyond the obvious risks and include more aspects into their judgement.

Reasonable risk-taking furthermore involves excellent communications because assumptions must be made about the intended outcome of risk taken, and incomplete data leading to the decision for taking a risk must be accompanied by another set of assumptions. Mature developers, know that both kinds of assumptions must be communicated to others in order to raise the chance for the risk-taking to be worthwhile.

Lastly the ability to take reasonable risks requires a certain amount of determination, of decisiveness. Because while it’s all nice & easy to theorize about decisions that involve risks, at some point decisions need to be made on incomplete data, on assumptions. And mature developers must be comfortable with that. Mature developers have to like making decisions.

Empathy

Empathy is noticing, and better even knowing, the situation another person is in.

And it’s really is one of my favourite words and concepts. Without empathy you cannot be effective or even successful in working together with others.

You need to be empathic to resolve more conflicts than you create and therefore providing value to and with others. So empathy is an absolutely required skill for mature developers.

Empathy enables understanding others’ goals. But before that, one must have a real interest in getting to know their peers. What is it that motivates them? What do they get passionate about? What makes them happy? What frustrates them? Knowing those things about someone actually means having a somewhat real relationship with that person. And that is the basis for empathizing with them.

Without a relationship with that other person, you can still try to know about someone else’s situation, but you’re making assumptions at best if you don’t know the other person. And your assumptions will be wrong. Probably more often than not.

Another aspect which makes empathy an easy concept in theory but more complex in reality is, that it can and is easily mistaken with sympathy. Sympathy is empathy plus actually feeling the other person’s feelings. Which is not always helpful. It may even be confusing, because it may reinforce your belief that your assumptions about another person’s situation are correct. (h/t to Oren Ellenbogen for making this distinction clear to me)

Excellent Communicator

I’ve touched on mature developers being good communicators earlier already, but of course this deserves to stand on it’s own.

Mature developers communicate excellently by always taking the context of their communicating peers into account. They know or at least have a sense about their counterpart’s goals, their state of mind, sometimes maybe even the mood they’re in, and how their peers usually communicate.

This allows them to consciously choose the way they communicate with others. Does my counterpart need a direct and quick answer, or do they want to understand the surrounding details? Do they want a short answer now, but more info later on? Is it useful for my and my counterpart’s goals to take a more defensive stance right now, in order to relax a situation?

Put simply: Always know what your counterparts need and want to know. And deliver it.

When taking into account the context of your communicating peer and the situation you both share, one important detail often gets overlooked: Assumptions.

Making your own assumptions explicit towards your counterpart, asking for the other’s assumption usually makes communicating so much clearer. Not only faster by reducing possible misunderstandings, but also less of an effort and possibly less stressful, because with assumptions laid out the communication can focus on what’s to be done, and less about establishing a common understanding first.

Other Opinions

As with most things, many people have come before me and shared their view and they influenced my thinking or helped me shape my own way.

And rather than thinking my definition above is new or novel, you can view it as a prioritized extract and sometimes slight rewording of those originals. So when describing my own understanding in the above paragraphs I haven’t pointed to the exact references anymore. I’ll leave it to the interested reader as an exercise to find out where exactly I copied from.

The most comprehensive and absolute must-read on the topic is John Allspaw’s “On being a Senior Engineer”. It’s not only a testament to an amazing amount of clear thinking on behalf of the author, but is amazingly comprehensive and already a timeless classic. And I owe John Allspaw’s writing a lot, in that it broadened my horizon and gave words to a lot of things that were only unconscious before.

Some much more recent pieces on the topic of Tech Leads such as “Good Tech Lead, Bad Tech Lead”, “No Tech Lead”, a lot of stuff by Pat Kua and the ever-excellent “Leading Snowflakes” by Oren Ellenbogen they all provided loads of inspiration.
As well lots of very good reads from Kate Madsudeira as well her timeless talk on leveling up your engineering and operations role.

Of course, many more opinions, such as talking with my colleague Timo, with members of the local Softwerkskammer and at many a SoCraTes conferences, influenced my thinking, but those are the most prominent ones.

cto.coffee - Let's talk humans & tech

Leadership as an Individual Contributor

Leadership as an Individual Contributor

Put your team and its deliveries first

Be proactive and take ownership

Have an eye on the big picture

Make sure everyone is heard

Seek out differing opinions and solutions

Bonus: Lead by example

Addendum

Disclaimer

On the Structure of One on Ones

On the Structure of One on Ones

Table of Contents

Structure

Prepare - Choose a Theme

Listen

Status Update

Conclude with Something Actionable

Dream Big

Hot Topic: How long is a 1on1?

TL;DR

On the Purpose of One on Ones

On the Purpose of One on Ones

Purpose

Build a relationship

Provide a safe space

Long-term Goals and Career Development

Continuous Improvement

Give Feedback

Structure

Mature Developers

Mature Developers

What Defines a Mature Developer?

Mindfulness

Curiousity

Pragmatism

Pro-Activeness

Having and Sharing a Technical Vision

Understanding Business Value

Reasonable Risk-taking & Decisiveness

Empathy

Excellent Communicator

Other Opinions