This is an excerpt from my recently published book, Own Your Tech Career. It’s pretty representative of the book as a whole, in terms of offering perspective and action items to help you put everything into your own context. For a limited time, you can take 35% off Own Your Tech Career by entering fccjones11 into the discount code box at checkout at manning.com. And Ampere Club members get weekly content like this, along with access to virtual events, 1:1 career coaching, and lots more.
A lot of technology professionals shy away from moving into management or leadership, and this is a shame. While managing and leading certainly isn’t for everyone, it can be a highlight of a career—and it gives you an opportunity to positively impact others’ careers, provided you’re good at it.
The decision to lead
A lot of my friends in the tech world have been very clear with me: they have no interest in management. If I ask why not, they give a variety of reasons, but a few common themes emerge, and they often boil down to this: they’ve had a poor experience with managers in their own lives, and they don’t want to become “that person.”
I’ve had some terrible experiences with managers, and some wonderful experiences with truly gifted leaders. At some point in my career, I looked back at how much I’d been helped along by the excellent leaders in my life, and decided, “I want to do that, too.” I suddenly wanted to help make the decisions that guided the organization, and I wanted the opportunity to positively impact other people’s careers. I’m glad I came to that realization, because it’s been incredibly rewarding.
Management and leadership aren’t part of everyone’s careers, and that’s fine. However, that’s not a decision you should make without reading this chapter. And if management or leadership is part of your path to success, I hope this chapter will provide some tips toward making you happier and more effective at it.
Leadership vs. management
I want to nit-pick some words here. The definitions I’m about to offer are by no means universal, but within this article I will use them to distinguish between some very different sets of responsibilities and behaviors.
Let’s start with supervisor, just so we can put the term aside. In this article, a supervisor is someone who watches over a group of people to make sure they’re doing what they’re supposed to be doing. I understand that some people might not be attracted to that role, because they see it as not much more than babysitting in some regards. But supervisory roles can also be a way to “dip your toe” into management. You take on some greater responsibilities, and you start to explore what management and leadership mean in practice. If you’ve ever been on a team that had a “team lead,” such as a lead software engineer, then you may have seen a great kind of supervisor in action—even if they weren’t called that.
Next up my hierarchy is manager. Sometimes, a manager is much like a supervisor, making sure people show up to work on time, disciplining people who break the rules, and so on. But really good managers are people who are given a set of resources and one or more outcomes to achieve, and who work to deploy those resources to accomplish those outcomes. A manager can be someone on a team, as opposed to someone at the head of a team. For example, a “lead software engineer” working on a team of other software engineers might well have some managerial duties.
A leader is something entirely different, and it’s what I’ll focus on in this article. A leader is the person out in front. They’re the one who shows everyone else what the destination is, who outlines the path to success, and shows everyone the path that will lead them there. The leader is the one who helps everyone understand the mission. A great leader will help remove obstacles from the team’s way, to ensure the team can focus and get their jobs done. The leader is not the one who gets all the work done, and in a lot of cases they might not even know everything that needs to be done. But they’re the ones who create the vision for the team, and they’re the ones who help everyone else understand how they can personally contribute to the mission.
Leaders are also the ones who take responsibility for the members of their team, treating those team members as people rather than just “resources.” They worry about their team’s state of mind, and they help guide their team’s professional development. Leaders are the ones who build new leaders, helping people rise to whatever level their career requires. Leaders are the ones who recognize when someone on the team is no longer on the same journey as the rest of the team, and leaders are the ones who wish that person “good luck” when they head off to wherever their career takes them next.
Notably, a job title doesn’t necessarily tell you whether someone is a leader. A “Manager of Network Operations” can be a leader, if they’re exhibiting the characteristics of one. A “mere” supervisor can be a leader, as well: it’s all about how you operate, more so than the scope of your authority or your place in the org chart.
You may have worked for someone who called themselves a leader but didn’t exhibit these behaviors. If so, they weren’t what I consider a real leader. Don’t let that person’s approach stop you from taking on a leadership role, if becoming a leader is what will help your career move you to your success.
The leader’s path
Leadership is straightforward, in that there’s a pretty short list of things you have to do. But leadership is hard, in that you have to show up every single day committed to that short list, and prepared to help your team recommit to the mission you’re leading them on.
First, you create a vision. This is a description of where you see your team in the future. If you’re leading an entire company, that might be a few years off; if you’re leading a smaller team, it might be just a year or less.
Your vision needs to set some specific and measurable goals that anyone with access to the right data could look at and say, “yes, you hit it” or “no, you missed.” But you’re not looking at small, week-to-week goals; you’re looking at the primary overall goals for the team: the “big picture,” in other words. These overall goals might include a description of the activities of the team itself, as well as specific achievements the team will accomplish. Your vision needs to be attainable, too, and your estimation of what’s attainable needs to come from your own experience, your research, and your data. If you can say, “look, we got close to something similar in my last job before I left, and I know how it’s done,” that’s a fine indicator of attainability.. Or maybe your confidence in attainability comes from this thought: “every other company who does what we do has achieved, or is achieving this, and I have all the data points to confirm it.” That works, too. But your vision can’t be pure fantasy or gut instinct: it needs to be backed by some evidence that shows it is a realistic, attainable vision.
Let’s examine a vision statement to see how to make it effective, and how a leader uses it to lead.
Our team will become a diverse group of world-class Agile practitioners, and we will routinely deliver more, and more defect-free, builds across all of our projects.
That’s a poor vision statement. It definitely implies that there are some goals, and some areas where the team maybe isn’t hitting what it needs to hit, but it does not provide enough precise, unambiguous information for a leader to use to guide the working of a team. This statement is not objective, and it is not measurable. What exactly is “world-class,” and how will we know if we get there? What does “more” mean, specifically? What about “diverse”—what does that mean in quantifiable terms? A true vision might look like this:
In four years, our team will consist entirely of certified Agile practitioners who work in defined, 4-6 week sprints. We will deliver 10-12 builds per year from those sprints, and we will maintain a defect rate of under 5 blocking issues per build. At least 40% of our team will be from traditionally underrepresented groups.
That’s a well-constructed vision statement. It provides a timeline of four years (and in reality, you’d probably update this every couple of years, always looking four years out, if that’s the timeframe that works for you). The goals are presumably “stretch” goals, meaning that the team isn’t currently exhibiting these milestones, and isn’t close to reaching them. The goals are measurable: the length of development sprints, the builds per year that result from those, and a defect goal to try and beat.
This is a good vision statement because you can start to look at where you are now, look at where you need to be for the vision, and start constructing a path between the two. As a leader, you might decide that:
- I need to have two members of the team become Agile-certified every quarter. I’ll stagger them, so that I can assign people time to prepare without taking the whole team offline.
- We currently work in one-year “sprints;” I’m going to build our next sprint around a smaller set of deliverables and try to hit three months for that sprint.
- We’re going to do monthly Agile reviews, so that we can better reinforce Agile principles and make sure we’re learning from our missteps.
- When new positions open, I’m going to commit to interviewing a diverse set of candidates both internally and externally. I will always hire the best person for the job, but I recognize that bringing a new perspective to the team is one of the criteria for “best.”
- We will aggressively commit to unit testing as a way of life, in an effort to reduce our per-build defect rate. I will need to put everyone through the right training, and we will monitor a trend line on our improvement.
Those are actual, actionable, visible things that the team can do. As a leader, you can show that list to your team. Putting on your manager hat, you’ll see that there are some resources you’ll need to juggle, and you may need to do some negotiating up the org chart to get those resources. You might go to your boss and say, “You know how you said you wanted more, smaller builds that were more reliable? Well, this is what I’m going to need to get that done. We need to make some minor investments in the team and our processes, and so you’re going to get smaller builds as I carve off some of their time to do that.”
Negotiating up the org chartOne important responsibility of any good leader is to manage up.
We often think of management solely as managing the people who report to you, but another behavior of a leader is to manage the people they report to. I’ll offer two examples.
My own boss came to me one day and explained some shifts in the company’s priorities, and asked that I realign my team’s activities to support those. I looked at what was being asked, and explained that I’d need to add at least one more software engineer to make it happen. “There’s no extra headcount,” I was told. “Okay,” I said, “but I need to take these two items that you’ve asked for and make them optional. We’ll try to get them done, but I can’t commit to it.” I worked for a company that was very supportive of that kind of negotiation, because the company recognized my greater ability—given that I was closer to the actual work—to understand what was possible.
In another instance, my team had lost a couple of people and not been able to backfill them—meaning we were short two team members. That put our outcomes in jeopardy. Rather than going to my own leader to explain the problem, I went back with three possible solutions. “I can’t deliver what we originally agreed to,” I explained, “but I’ve come up with three scenarios I feel we can achieve, given where we’re at right now.” We used those as the basis for a negotiation: my leader helped me understand the company’s priorities at the time, and I helped her understand what the team could physically accomplish.
“Negotiating up the org chart” is a powerful skill, and it’s one that a well-run company will understand to be a valuable part of the overall business.
That kind of up-the-org-chart statement is part of what makes a good leader. The organization tells you it wants something, such as adopting an Agile approach or increasing productivity, and you, as a leader, have create a solid vision of it, as well as a path to get there. Nothing is free, and resources are finite, so you figure out what this vision will cost the organization–in equipment, time, people, and money. As the leader, you are accountable for that investment creating the return that you’ve established, and you should, welcome being held accountable for it.”
With a good vision statement in place, and a plan that takes you there, you start showing your team where they fit. With a truly clear plan, it’ll often be obvious where everyone fits. One team member might see that she needs to start studying for that Agile certification, another might say, “I guess I’d better start reading up on unit testing.”
From there, your job as a leader is keeping everyone on track. It’s easy, in the day-to-day chaos of life, to lose track of the vision; your goal is to keep it in sight.
Disagreements over the vision
A couple months along the path of putting the vision into action, a team member approaches you, saying, “We really need to add this one extra feature, because people have been calling the help desk about it a lot.”
But the team is currently two weeks into the sprint. If you added that feature now, you would break your Agile principles and jeopardize the sprint itself. You refer back to the vision statement to decide what to do. “Is adding this feature at this point going to help us achieve our vision?” And you decide that no, the vision is bigger than this one feature, and the team needs to stay committed to the vision.”
You explain your thinking to the team, but they’re skeptical; they still think it would be best to add the feature right now.
What do you do if your team members disagree with you? How do you handle that disagreement, along with the many other disagreements, arguments, misunderstandings, and fights that naturally crop up in the work environment?
You handle it by getting into your team members’ heads. By getting into their context.
Getting in their context
A microprocessor can execute code in one of two spaces: kernel space and user space. Kernel space is a very protected environment, designed for sensitive, operating system-level code that keeps the whole computer running. User space is for regular applications. The two spaces are separated so that a single app can’t easily crash the entire computer.
The microprocessor cannot execute user space code and kernel space code at the same time. Doing so would allow one to impact the other, which would defeat the point of separating them. And so the microprocessor must execute a context switch to change from one to the other. This is a deliberate action that actually consumes time, and it lets the process “shift its thinking.” “Okay,” it can say to itself, “I’m in kernel context now. I need to behave a little differently, and certain actions are going to be allowed that weren’t allowed when I was in user context. Deep breath. Here we go.”
As a leader, you need to become a little bit like a microprocessor, and develop the ability to change contexts more or less on demand.
When you get done reading this paragraph, I’d like you to sit back for a minute and close your eyes. Just kind of float around in your own mind, and observe your internal monologue. What do you think about when you’re not thinking about anything?
I just did it and I found myself thinking about our friend, who’s driving up to visit this weekend. We’ve not seen him for a while, and I’m looking forward to hauling out a nice bottle of wine and catching up. I’m also worried about the raccoons that have been knocking things over on the deck every night, and what we’re going to have to do to put an end to it. Oh, I need to take the trash out, too. I could use a glass of iced tea. My jaw kind of hurts, I must have slept on my face wrong or something. Or I’ve been clenching my jaw again. Ugh, I haven’t been to the dentist in like nine months.
That was my internal monologue for a moment of the day. That was my context. It’s where I’m at in my head. It’s why, when my beloved spouse just asked me if I’d checked on the chimney sweep, I snapped, “no!” I’ve already got a lot of house stuff on my mind, and this is just one more thing. Combined with the pain in my jaw, it’s just not what I needed to hear, and not how I needed to hear it.
Then we had a fight, of course, because I snapped. The thing is, my darling spouse is in another context altogether different from mine. My in-laws have been going through some difficult financial decisions, and I know it’s impacting my wife and her siblings, creating a lot of worry. My spouse’s context was trying to make sure this chimney sweep got taken care of, because there’s so much else going on with the family that it’d be easy to let it drop. And here I am, snapping for no reason.
Well, not for no reason, right? In my head, what I did made sense. In my spouse’s head, what she did made sense.
We’re all operating in different contexts. We’ve got different thoughts that are top of mind, different concerns that are worrying us, and different perspectives on what’s going on in any situation. Those differences are what create strife. As a leader, it’s your job to put yourself into other people’s context so you can understand what’s happening. It is not their job just to “suck it up and get the job done;” it is your job to lead. In order to lead, you need to know a bit about the people you expect to follow you. People aren’t going to follow you if they think you’re headed someplace stupid; you need to understand what they think is smart and stupid, and help them understand, in their terms, why this is the smart direction to go.
Team members: “Agile is stupid. You can’t get anything done in six weeks.”
Team leader: “Well, smart or stupid, what the company needs from us is to be more responsive. We don’t have to use brand-name Agile if we don’t want to, but I do want to look at the principles and start shifting toward more, smaller releases.”
Team members: “That’s just another dumb change. We do this every two years, change our approach for no good reason.”
Team leader: “Hey… there’s obviously something here you’re worried about. Tell me what you’re thinking.”
Team member: “It won’t matter, you’ll just do what you want.”
Team leader: “Maybe I won’t. Forget what I think about this for a minute, if I’m wrong I’m wrong and I’ll admit it. Tell me what you’re thinking. You’re definitely a little upset, so tell me why. If my plan is a dumb, I don’t want to do it. Just tell me what’s up with you right now.”
To get the context of someone else, you need to ask questions. I understand that being “touchy-feely” isn’t comfortable for everyone. It’s not comfortable for me. I’m a sarcastic, engineer-brained computer nerd who’d be more comfortable assembling a server than talking about feelings. But when I’m in a leadership role, it’s my job to understand where my team is, mentally and emotionally. If I’m going to convince them to follow me, I need to understand what matters to them, what their priorities are, what they care about. I need to find a way to align them to what I need us to do together, and to do that, I must ask them a lot of questions about themselves. It’s those questions–and answers–that will get me into their context. Because you know what? Maybe I am wrong and they’re right, and they’re just not good at expressing themselves in a way I understand. It’s my job to shift so that I can understand their perspective.
So why can’t you just expect your team to “suck it up” and do their job? Because they’re people. People don’t suck things up. They may try to ignore their feelings and act like everything is fine. But when you encourage or allow them to do this, you’re not creating a healthy team. You’re not creating a team that will follow you.
Being a true leader is not a right that you’re handed along with a new job title and a pay raise. It’s a privilege that you have to earn. Remember, as the leader, you’re probably least able to get things done of anyone on your team. It’s your team members who are doing the work. Your job is to earn their followership and help them get to the outcomes everyone wants.
I acknowledge that not everyone is going to be the perfect team member. If you present your vision and they think the entire vision is absolutely wrong, then they might not be a great fit for your team. “This is where we’re going,” you might say. “And you obviously aren’t required to come along. But this is where we’re going, and if you don’t want to come, then we need to work on finding you a team that’s going in a direction you’ll be interested in.”
This isn’t a “my way or the highway” approach: if the vision you’ve laid out, and the path you’ve created, are the ones that will achieve what the company needs to achieve, then the team needs to eventually be on board with that. You would certainly ask your team for feedback, and you might ask for their help in designing the right path to the vision. If you’re truly collaborating and helping them understand the outcomes, and why those outcomes matter to the company, then a good team will rally with you and work to get it done. But there will be times—although I hope they’re few—when a current team member just isn’t interested in the new journey. It’s your job, in those cases, to help them find a journey they do want to be on.
I’ve worked for more than a few so-called leaders who try too hard to make themselves “one of the pack.” Anytime they’re asked to do something they know will be unpopular, they try to commiserate and put the blame elsewhere.
“Look, upper management says we’re going to have to put in whatever hours it takes to get the server migrated. I know, I know—I told them we’d been trying for a week already, but they’re just not listening to me.”
That’s not leading. And it’s not managing. I’m not sure what it is, except a little annoying. Remember: leaders have a vision. That vision creates outcomes that the organization needs. Leaders develop a path to that vision, and they work to inspire their teams to stay on that path. They help remove obstacles between their team and the vision. And leaders take accountability.
Whenever you, as a leader, start from a place of negativity, you sabotage your own path to your own vision. When you’re negative, the entire team is entitled to be negative. That will reduce their productivity, impact their own mental health and happiness, and lower their desire to actually follow your lead.
“Folks, it’s come down to it. We all know Sales needs this server migrated before the new campaign launches, and that’s now next week. We’ve spent a week fighting this thing, and you’re telling me that we’ve got the last hurdles out of the way. Tomorrow’s the drop-dead date we gave them, and so we need to make this happen. I know that’s going to mean us working all night, and I’ll be here with you, but this is what we said we’d get done, and we need to get it done. Other people are relying on us. From what I’m seeing we don’t need all six of you here all night. Do you want to break this down into shifts?”
Leading positively doesn’t mean you have to put a smiley face on every situation. Bad news will come, and bad times will occur. Leading positively means being able to say, “I know this isn’t great, but we need to get through it. How can we do that?” It’s looking forward to the vision. It’s reminding everyone of the personal role they play in bringing the vision to life. And it’s letting them know that you’ll pull your weight, just as you are asking them to do. If you’ve created an attainable vision, and you’ve outlined a clear path to get there, then all that’s left is to do the work.
Mistakes leaders make
We all make mistakes. The point of having experiences is to learn from them. And the point of teaching, as I’m trying to do with my book, is to share experiences so others can try to avoid the mistakes you’ve made. With that in mind, here are some mistakes that leaders can make:
- Being dishonest. If your organization is doing something stupid, you don’t have to paint a pretty face on it. But you also don’t need to commiserate about it with your team members. Refocus your team on the vision. Re-work the path to that vision, if you need to. Re-show everyone what their role is.
- Blaming others. Leaders are accountable, period. Yes, your team members might make mistakes, and in some unfortunate cases you may even have to take formal disciplinary action in response to those mistakes. But make sure you’re looking at ways to, as a leader, keep those mistakes from happening. Micromanaging isn’t the answer; making sure everyone knows their role, and has objective metrics with which they can determine their success, is the way to minimize those mistakes.
- Stifling ideas. Most technology professionals are passionate, creative people who want to improve the world they’re in. Don’t stifle that. Let people express their ideas, and listen to those ideas. Accept that your team might be a lot smarter than you, and rely on them to help you construct the path toward the vision.
- Letting mistakes go. Mistakes provide an opportunity to learn. To make the most of mistakes, discuss them as a team, and decide on a new way forward to prevent that mistake. It’s also important to document mistakes in project notes and records because. Create an environment of fearlessness, where people are comfortable being accountable, because they know failure will be treated as a learning experience, not followed up with a punishment.
- Talking too much. “Talk less, smile more,” as the Hamilton lyric goes. As a leader, your job is to help your team see the vision and then support them in getting there. You can’t support people unless you’re listening to their ideas and their needs.
- Communicating poorly. Your written and verbal communication skills are critical to your success as a leader. Remember, for instance, that not everybody reads an emoticon 😛 the same way. Work to communicate in as unambiguous a way as possible, and be aware that your communications may be received in a way other than you intended. Listen, learn, and adjust.
- Forgetting. You’ve had bad leaders in your life. Don’t forget them, and don’t be them.
Leadership beyond leading
One final task of a truly effective leader is taking care of your people. While this obviously includes protecting them, when you can, from upstream “static” and helping them stay focused on the mission, it also means trying to take care of your team, both as people and as professionals.
Take an interest in your team’s own individual definitions of success. Ask them what kind of life they’re hoping to lead, and what they’ve defined as the kind of career that will get it for them. Ask how you can help create that kind of career for them—by offering advice, if nothing else. When you see something in their career definition that you know you can help with, offer to do so. Maybe you can help by coaching them to become leaders themselves, or maybe you can help them to understand more about the company so that they can better align their current job to their career goals.
I’ve been fortunate in that I’ve almost always had leaders who wanted me to grow into whatever kind of role I wanted. One of my first jobs was working part-time as a retail sales associate for a computer software retailer (Game ‘n’ Gadgets, if you’ve ever heard of them). Most retail outlets have a manager and an assistant manager, and often one or more keyholders. Those keyholders literally have a key to the shop, and are permitted to open and close the store, including counting down the till and doing opening or closing paperwork. My manager didn’t care for the keyholder concept: in her eyes, everyone should know how to do everything. And although I worked a scant 12 hours a week there, I quickly learned everything. I could do most of her job, and when an opening came for an assistant manager at a nearby store, I got hired easily. I’ve never forgotten her attitude.
Even today, I make sure everyone on my team knows how to do my job, even if they don’t have the authority—yet—to actually do it all. One day, there’ll be an opportunity for them to move up, and it’ll be an easy decision–for them, and for the company. Of course, this all depends on whether or not they want to move up in this direction. I’ve been careful to ask about their own goals and values, so I don’t push them in the wrong direction. In some cases, I’ve suggested they focus on a particular aspect of their job for growth, and we’ve discussed how that could help move them into a job that’s more closely aligned with their goals than the job they currently have. I hope that the new job will still be with my company, but if it isn’t, I’m happy that they’re doing what’s right for them.
Before moving into leadership
As I’ve spent much of this article defining leadership and outlining what it can look like, I want to take a moment to argue against a move into leadership.
I moved into my first leadership role well before I was ready, and wound up leaving the company to move back to an individual contributor role. It was over a decade later that I finally—hesitantly—agreed to move back into leadership, and I found myself much better prepared. While writing this book, I had some colleagues—one from my own team—go through the similar step-into-leadership-and-step-right-back-out experience, so I think it’s well worth questioning a leadership opportunity if it comes your way. Do you know what the day-to-day work in this leadership position entails? Is that the kind of work you like? Do you have all the skills and experience you need to do well in that position?
Never accept a leadership position solely for the title or the money. Management is often seen as “the only way up,” and in many organizations that’s true in terms of salary. But moving solely for salary can backfire. Instead, move into leadership because you want to lead, and because you want to excel at it. Leadership is a skill just like any skill, and while it’s a skill I think anyone can master, it’s a type of work that not everyone will enjoy. That work differs across organizations, as well, so make sure to gather information and analyze what you’re getting into.
Don’t get promoted to your level of incompetence
In the classic book The Peter Principle, first published in 1968, Laurence J. Peter proposed a concept that’s relative to our discussion on whether or not to move into leadership. Broadly, it states that people in a hierarchical organization tend to get promoted to their “level of incompetence.”
It goes something like this: Let’s say you’re a great entry-level software developer. You do well, and you eventually get promoted into a mid-range developer role. You struggle a bit at first with the additional job duties, but then you master them, and start to really succeed. After a time, you end up in a senior developer role. This adds some team-coaching responsibilities, and again you struggle a bit at first, but eventually you find your groove and start to do well. Next, you’re promoted into a full leadership role as a Software Development Manager. You’re no longer working on code, and are instead responsible for leading entire teams of your former peers. The pay is great, and it feels good to have the company’s trust. You struggle a bit at first, because it’s an all-new kind of work, but eventually…
You keep struggling. And struggling. And it never gets better, because you’ve been promoted to your level of incompetence. And because you’re not succeeding, it’s unlikely you’ll go further. And it’s not even your fault, really—you’ve just been put into a job where you don’t have the right skills. Your amazing abilities as a developer did not translate to amazing leadership skills. Another way of looking at it is that you landed a job you’re not qualified for. It’d be like a Unix systems administrator somehow landing a job as a data analytics architect—the pay would be great, and the job might seem interesting, but your old skills didn’t in any way line you up to be successful.
Try to avoid getting promoted to your level of incompetence. If you want to be promoted into leadership positions, learn what those positions entail, and what skills you need to do well at them.
Leadership skills can be learned. The process is similar to learning a new technical skill, right? You learn a bit, you practice a bit, and you take on small roles to prepare yourself for larger ones. Here are a few ways to learn and practice leadership skills so you can ease into a leadership role when and if the time is right:
- Establish a mentoring relationship with an existing leader in your organization. I enthusiastically recommend this as a way to find out what the job is really like, including all the ugly parts (like having to fire people or lay them off, or have uncomfortable discussions about job performance, for example).
- Take on a “tech lead”position if your organization offers this option. In a tech-lead role, a skilled technology practitioner informally picks up some leadership-assistance duties, often in exchange for a small salary supplement. This is a way for the organization to spread out the leadership workload somewhat, and it’s a way for someone to have a trial run at a leadership-lite position.
- Volunteer for organizations with leadership opportunities. Ideally, you’d start at a small scale, leading a team or a project, to gain experience and see if you like being a leader.
Measuring your own success
As an individual contributor, it’s often easy to measure the success of your days. Perhaps you got a server up and running, or finished a module of code, or got a data visualization working, or something like that. You produced something, in other words. As a leader, it can be much harder to tell if your day went well. You’ll often sit in more meetings, for example, and while you might be conveying marching orders to your team, they’re the ones getting the marching done, not you. So leaders have to be able to find new ways of deciding if they had a good day at work or not. And if you aspire to be a leader, you have to be comfortable with those ways, if you find them.
As a leader, I’ve tried to shift my focus to, “did I have a good week” instead of evaluating day by day. I do this because sometimes my job just does not result in a daily “win.” So I make a special effort to write down things that went well, as well as things I feel I could have improved on. Then, at the end of the week, I review that list, and usually save my lists for several months. This is sometimes the only way to remind myself, amidst the chaos of everyday management life, that I did get a “win” in here and there.
- Brave Leadership: Unleash Your Most Confident, Powerful, and Authentic Self to Get the Results You Need, Kimberly Davis
- The World’s Most Powerful Leadership Principle: How to Become a Servant Leader, James C. Hunter
- Powerful Leadership Through Coaching: Principles, Practices, and Tools for Leaders and Managers at Every Level, Michael K. Simpson
For this article, I’d like you to take some time and consider leaders that you’ve found effective and enjoyed working for, and consider some of the attributes they exhibit.
❏ Which leaders have communicated a vision to you that you understand, and that you can see your place in? How did they do that?
❏ How have your best leaders inspired you to help make their vision come to life?
❏ How have leaders you’ve worked with tried to understand your context, so that they can better help you understand what they needed from you?