This video was left by a colleague (thanks Sudhir!) as a comment on my last post. I love this line from it, “People don’t buy what you do, they buy why you do it.” A great talk by Simon Sinek on leaders that inspire – please take a look.
Continued proof that there are a lot smarter people than I discussing the topic of leadership. Even so, I’ve still got lots to add to the conversation.
-Chris
In my opinion, there is nothing more important to the leadership of a team than the trust that develops between the team members and its leader. This is true across many industries and careers so, in that sense, this post won’t be dedicated to pulling out the distinctions for technical teams. I believe most of what I intend to discuss is almost universally applicable. To begin the topic, I’d like to reference a historical text that has been used to provide guidance on leadership. In The Prince, Machiavelli famously stated that, “It is far safer to be feared than loved if you cannot be both.” I mention the quote not to debate the main points of the book (that has been done endlessly) but to outline some possible aims of leadership. I hope you will indulge the comparison. In the context of leading organizations, I would modify Machiavelli and state that it is better to be trusted than it is to be feared or loved. Leading out of fear simply gains followers based on a threat. Leading as someone who is loved is too personal for the business environment. Managing as someone who is trusted to act fairly and to do the right thing is, I believe, critical to the success of leadership.
Perhaps the comparison to Machiavelli is unfair based on context but I would like to investigate the three leadership styles in play to illustrate my thesis (apologies to Niccolò). The first style of leadership, one based on fear, is one that I have seen (although not too often) in technical teams. Leaders of this type tend to introduce fires, what-ifs, and other situations to drive a sense of urgency on the team. While this may be effective for a short period of time, over the long run, it exhausts a group. One cannot be expected to jump from crisis to crisis continually without tiring. Not everything is a P0 and when the team wises up to that fact, the leader has lost all sway. A leader that continually cries wolf will end up with a slaughtered flock when an actual crisis crops up and no one picks up their cell phone. While I use the metaphor, this is not contained merely to the operational realm. Setting false deadlines on projects, introducing new must-have deliverables that are really nice-to-haves, and casually mentioning performance reviews are all examples of this style. In the business world, this is certainly not outwardly aggressive (that would be an HR issue) but is instead passive, meant to instill uncertainty and in it’s most insidious form, fear of termination. From my description, it’s obvious I don’t approve, but I know there may be some that say I’m not giving this style a fair shake – please feel free to comment!
If not leading out of fear, what about being loved? I’m planning an entire post on personal relationships in the technology team space so I won’t dive into that here. I’d like instead to contain the discussion to the idea of being liked by everyone on your team. Early in my career, this was a priority, and if I’m being honest, still lingers to this day. I’ve come to accept that there are those that simply won’t get along with you and that is OK. Some leaders however, do not accept this limitation and strive to be well liked by everyone in their group. While this is good from an influence perspective, I believe it is fraught with risk. The biggest issue I have with this style is the inability to have difficult conversations. People are, in general, conflict averse and having hard conversations around performance is not something many people do effectively. Take a look at your last performance review and try to find a place where your manager decided to be overtly critical. Find a place where needed improvement was mentioned without a softening compliment soon after. It is hard to be critical of each other, especially when we want to be well liked. As leaders, this is extremely difficult because while we should all strive to grow our teams through constructive feedback, a negative reaction to criticism is a real probability. Those that desire to be loved shy away from that tense situation and in the end, let their teams down. Some practical examples may be a failure to deal with an under-performing employee, promoting someone based on tenure, or bowing to a more aggressive team member. All of these examples may be well-intentioned but do not serve the team in the end. I suppose that I prefer this style to being feared but they both fall behind trust.
Leading through trust involves a lot of things but most key in my mind is transparency. Honesty with your team is critical. This means conveying information you’re at liberty to, being open about your expectations, providing timely feedback, admitting your own mistakes, and being open to feedback from your team.
As managers, we are privy to large amounts of information prior to our teams. Some of this information can be shared and some cannot. Knowing where that boundary lies is critical to developing trust with your team (and in some cases, keeping your job). It is important that you share relevant information with your team as quickly as possible. A well informed team will make good decisions without the need to consult you. This is empowering and creates and environment of constant communication – something good for any organization. From a practical perspective, I convey this information in 1:1s, at team meetings, project meetings, and where ever else seems appropriate. I try to focus on getting the right information to the right people at the right time. This can be hard to accomplish and problematic if you accidentally exclude someone but is something I work at constantly. In technical fields, as in other occupations, information is key and holding back or delaying is detrimental to the team overall and can hurt relationships if people feel intentionally left out. While this may seem obvious, I have had interaction with leaders who have intentionally held back information so as not to “muddy the waters” but ended up being counterproductive.
Communication of expectations is also important in establishing trust not only with your team but among team members. One practical example of this concerns annual reviews. Whether the giver or receiver, the worst possible outcome is to be completely misaligned when it comes to someone’s performance. If, as a manager, your employee disagrees completely with what you have written in a review, you’ve failed. Performance, and expectations around it, should be a constant dialogue with your team. Whether it is around something as large as an annual assessment or as small as the next project task, it is critical to be clear on what needs to be done and when it needs to be done by. Team members will return this transparency of expectations by making commitments and hitting them (something I’ve mentioned in a past post). This results in a completely above-board and trusting work environment. And no surprises when it comes to performance.
Feedback between a team and its leader is the final part of trust that I want to address. It is important to provide feedback to your individual team members in a timely manner. Positive or negative, waiting a week to mention something from the meeting you just held isn’t very useful. Be up front if someone does something that doesn’t meet your expectations but let them know in private. If someone does something great, let them know as well – and do it publicly if appropriate. As leaders we must also be open to feedback from our teams. Do not wait for people to speak up, search it out. Just as important as hearing criticism is acting on it. You need to let the team know that you’ve heard where they’d like you to improve and are taking steps to do so. Admit your mistakes and report out on your progress in rectifying them. Nothing is worse than getting up the courage to talk to your manager around something that is bothering you and being blown off. Constructive criticism is a two way trust relationship. The person raising the issue needs to trust the recipient to hear, respond to, and take steps to resolve problems (as opposed to flipping out and storming off). Likewise, the recipient of criticism must trust that the source is not trying to be a jerk and has an honest concern. I think a mark of high performing teams is when team members can challenge each other to be better in an open and honest manner and that this feedback is received in an open and healthy manner. No better place for this behavior to start than with the manager.
-Chris
This may seem like an odd topic for a leadership blog but I think encouraging work / life balance is an important (and very difficult) thing to do within technology teams. High performing teams are typically made up of individuals who enjoy what they’re doing for work. It would be odd to see a team that functioned well if some or all hated their jobs. For people that enjoy their jobs, the lines between work time and leisure time can become blurred. As technology is so rapidly changing, technologists may use their free time researching to stay current or working in their home lab. It is difficult as a leader to, on the one hand, drive the team to meet deadlines while on the other, tell people it’s time for a break. While certain past experiences (read, burn out) have forced me pay mind to this balance in my own life, I have found it difficult to force those on my teams to do the same. I suppose vacations cannot be dictated but I believe there are other ways to push people away from work, if only for a short time. As leaders, this skill is essential to protect the team against overwork, low morale, or even, in the extreme, outright mutiny (that never ends well for the captain).
I believe that technology fields off two unique challenges to the balance between work and home. The first I’ve already alluded to – it changes so rapidly. It is necessary to learn outside of normal working hours (as companies usually don’t allow enough time for training) because an outdated technologist is not going to be successful. Those of us in technology also like to learn and understand the bleeding edge because it is new and exciting. So while others may surf the latest entertainment blogs or sports sites, we figure out how to write that piece of code or find out if the bug we’ve run into is fixed in the next beta release. I’m not saying this is true for everyone of us but I believe that, for technologists, a lot of our down time is closer to work than other fields. This presents challenges for balancing work and home as the line between the two becomes foggy.
The other unique hurdle for technologists (at least those in any sort of operations role) is the idea of being on-call. While most occupations have set hours with some expected overflow, I have slept next to my phone ever since I joined this profession. It can ring at any time and it is expected that I answer it. I’m not putting technology jobs above others, just saying that “carrying the pager” makes technologists different. We are certainly well compensated as a result but this does however force the lines of work and home to become more vague. Unless I’m on vacation, I don’t shut my phone off or leave it at home. Maybe that’s just me and others are better but it makes me anxious to be without that little communication device. And when I carry the phone, I tend to check and respond to email and thus my workday extends. The benefits my company gets for shelling out for the device and monthly plan are enormous.
So with these things in mind, how do leaders prevent their team members from tipping the balance in their lives too far toward their job? This is a huge issue in the US (where success is judged primarily by economic status) and is something I face on a daily basis. There are a couple of methods I use – one direct and one more indirect – to combat this.
I’ll start with the more indirect of the two. This idea is around managing expectations and while that may seem a little odd to connect to work / life balance, I promise I’ll get there. I have a simple rule that I employ with my teams: make commitments and hit them. If you are unable to meet the expectation on delivery, let me know as soon as possible. This does a couple things for me. It makes planning simpler as I generally know when to expect deliverables and if they slip, I know as soon as possible. As a manager, it is important to deal with misses in a rational way. Delays will happen, that is a fact. When they do, reacting with anger or insane disappointment is out of line. If you do, your team won’t trust you and will let you know of delays only as a last resort. That only gives you less time to re-plan, reset expectations, and adds tension – not a positive outcome. Your team must trust in your response and know that you are on their side. It also helps to guide your team on setting expectations. If you are forgiving without being a doormat, people will add less padding to their work estimates, ending up with more accuracy. Reiterating the importance of making and meeting commitments along the way serves to solidify this. All of this serves to make work more predictable and reduces the chaos of the multiple workstreams / projects / skunk works efforts that are common in a technical environment. This helps work / life balance tremendously as it fundamentally changes the way the team works. Rather than jumping from rushed deadline to rushed deadline, the team can plan and when a day to catch your breath is necessary, you can take it rather than having it domino a ton of efforts out of control. The work itself “slows” and the team knows that their leader has their back and understands that sh*t happens.
The other part of this indirect method is to hone your skill at managing up. Just as your team will set expectations with you, you must set expectations above. As you develop trust with your team and get better and better work estimates and flow, your ability to be predictable to upper management will improve. Ideally, this predictability brings trust and with it, some calm. Unfortunately, that may not always be the case and many of us have dealt with management that never seems satisfied or appreciative. In these cases, it is important to remember that, as leaders, we must act as buffers to our teams. Be honest with them as to the pressure you’re facing and never toss them under the bus to your management. It is our job as leaders to own that responsibility and manage expectations. Doing so is critical for both the sanity of the team and your own well being.
The more direct method of dealing with work / life balance concerns being in good communication with your team. It is important to know how the individuals on your team are doing, both within and outside of the workplace. You don’t need to be friends with everyone (that’s a personal decision and a different post) but as leaders, it is important to know the pressures facing your team, no matter the source. The ability to sense work overload or other sources of stress is a critical leadership skill. In a perfect world work would be stress free and while it can be managed, work is never free of stress. There are times when as leaders, we must react and do so in support of our team, potentially at a cost to a project. In the long run, the team will appreciate it and the business will benefit through increased morale and work output.
A couple of examples to illustrate the point… you might have an employee who suddenly changes his or her performance. Normally she is great and enthusiastic but lately has been quiet and might have missed some commitments. Don’t delay addressing this as it may compound with time. Faced with an under-performing employee, some managers will make the conversation simply about that and simply send the “pick it up” message. That isn’t my approach. If you have someone that is traditionally a good performer, the benefit of the doubt should be given 100% of the time. I start these types of conversations with, “Are you OK?” I mention that I’ve seen a change and want to know how she’s doing. I do this because I truly care and also because I want to know what I can do to help. Employees will share to varying degrees based on their personality and level of comfort with you. Regardless of the degree of disclosure, it is important that your team knows that you care. Just asking and sensing tone or if in person, body language, can give you insight. Once you have it, it is important to act. If you sense someone is over-stressed, pick a day, call her up and tell her to take the afternoon off. If pressed, it is a reward for a job well done. These small acts may have more of a positive effect then you know and only come at the cost of a few hours.
Another situation you might run into is an employee who comes to you with a personal concern. It might be that a parent is ill or they have an auto repair that they need to get done but haven’t been able to find the time. Given this type of situation, I immediately offer time away from work. Family has been and always will be more important than the job and as a leader, it is important that you reinforce this to your team. The belief that one might be viewed as under-performing if we need to ask for time only serves to compound personal stressers and can dissuade us from requesting it. As a leader, offer it. It takes a lot of pressure off folks if they know you’re supportive and won’t respond with, “That’s nice, now back to work.” These situations won’t always be as obvious as I’ve presented here so it is important to build your skill in reading your team. It takes time but putting the balance of work and home front of mind for yourself and your team will go a very long way. It is critical to our development as leaders.
-Chris
When folks read the title of my blog, I’m guessing the first thought that comes to mind is management. A manager leads the team and the team members follow. While that is certainly my current role, being a manager doesn’t qualify you as a leader, nor does it fully define what it means to lead. Leadership can happen at all levels of an organization and in all functions. This is especially true in technology where most teams are not staffed to their full compliment and individuals are often expected to operate with a fair degree of independence. Leadership opportunities arise within projects, through subject matter expertise, and even through attitude and mindset. Simple acts can make you a leader and it is in these moments that I see leadership.
I’d like to define leadership by describing some qualities that make a good leader. These can be applied no matter your position, you just need to find the right opportunities. I’ll also get into some examples of poor leadership techniques that we all can fall into. Understanding and correcting improper tendencies as as important if not more so than demonstrating good qualities. I’m going to describe what I feel makes a good leader in many different posts because I believe that each quality is nuanced enough to warrant a lengthy discussion. I don’t think there’s any Top 10 list that applies universally so I’ll tackle them over time.
One quality that I feel is critical is the ability of a leader to listen to his or her team. Leaders like to talk. Generally speaking, those that gravitate to leadership roles are expressive and willing to share their thoughts and opinions with others. While this is certainly a positive trait, good leaders also know when to keep silent. The ability to listen and respond thoughtfully to your team is critical. People want to be heard and respected. If you are constantly talking through, over, or around people, you’re not leading, you’re babbling. Opening your ears comes in handy in many situations. Listening to a peer vent, discussing career aspirations with a report, or understanding the amount of risk in a project timeline as a team member are all examples. Too much can be missed when your mouth is moving.
I struggled with this early in my career and still do today to a certain extent. Too often I wanted to make sure that I was heard and didn’t take the time to truly hear others. I had many a manager, project manager, or peer pull me aside and tell me that I was too brash or came on too strong. Normally they respected my opinion but didn’t appreciate how I had conveyed it. It took quite some time for the advice to sink in (and I’m no master of it now) but I’d like to think I have grown a little from that young man right out of college who knew everything about everything.
The practical applications of this trait are numerous but I’d like to focus on a few techniques that I have found effective. As a manger, I schedule 1:1’s with nearly everyone in my organization that wants one (and even with some that I’m sure don’t). The frequency isn’t too high but I treat it as the other person’s meeting. It is his or her time on my calendar and I set that expectation right up front. If I control the conversation, I believe I’ve failed. I want to hear how that person is doing, how their work is going, how they’re enjoying it, what they want to be doing more of, what they can’t stand, and most importantly, what I can do to help. I want to understand “the pulse” so to speak. I’m very transparent about the process, telling the individual that this is their opportunity to tell me what’s going well and what isn’t. Not everyone engages and that is fine – the fact that they have the opportunity is the point. Too often, managers simply dictate because there is too much work and too little time to check in and see how the team is doing. This can lead to low morale and in the worst case, attrition. Too often in large corporations (which is the entirety of my professional experience), that fact that we work with human beings is lost amongst the huge machine that surrounds us. While changing corporate culture is beyond my skills, I try to humanize my small space within it as much as possible.
Another technique I use is a round table at the end of every team meeting that I hold. I leave time in the agenda for open items that anyone can raise. It can be a question for someone else on the team, an accolade for a peer, a concern someone has, a question from an earlier portion of the meeting, anything at all really. It is a time where each team member has the opportunity to take the floor and be heard. Sometimes it causes the meeting to run over, other times there’s complete silence. In the latter case, I will sometime ask someone who I know is comfortable with the spotlight if he or she has anything to bring up. Be careful about who you do this with as folks with more reserved personalities can feel very put off by it. This can get the discussion rolling but doesn’t always, and that’s OK. The result doesn’t matter as much as the fact that the chance to speak is there and that I, as the leader, am stepping back and letting other dictate the conversation.
The first two approaches can be applied broadly across industries but the third I’d like to discuss is applicable directly to a technical environment. As a manger, there is a tendency to move away from the day to day of your organization. This is especially true the higher that you go in the food chain. It is a fact of the managerial career path that you lose your technical depth. It is a decision we all need to make in our careers. In general, management (if they are focusing on managing) can’t stay up to date with all the newest technology that their team employs. While this can be disappointing for some, I embrace it and am very transparent with my team that I rely on them for the technical knowledge. I don’t have the answers and need them to lead me to the best technical decisions. In this spirit, I periodically take the time to attend deep technical meetings (the ones the team has without stakeholders so they can actually be productive). I use it as an opportunity to educate myself and to switch roles with my team members. They become the leaders and I the follower (a certain Star Wars quote comes to mind here). I ask questions, not to challenge the ideas being presented, but to truly understand the topic being discussed. I take note of the participation of each team member and may follow up if I sense someone was drowned out by louder voices. For me, this achieves two things. I stay in touch with the technology to a depth that is required and I also get to hear the thoughts, ideas, and interactions of members on my team. Some may argue the point over the technical knowledge required to be a good manager of a technical team (I’ve got a post about that in the hopper so I’m not going to dig into it here) but reading manuals and configuration guides is something I gave up long ago. For my purposes, gaining technical information is secondary to listening to the team.
While I’ve described these practices in a managerial context, they can be applied generally. I openly encourage my team members to hold 1:1s with each other, especially if they have frequent interaction. If both parties go into that meeting wanting to hear the other, great communication and collaboration will happen. Similarly, PMs, technical leads, or anyone facilitating a discussion can leave room for the table to be heard. Take the time in the agenda to allow for it – don’t skimp. And finally, anyone can take the opportunity to expand their knowledge in a new technical arena. Ask to attend a technical discussion outside of your comfort zone. Ask questions and learn from your peers. This may not seem like leadership but letting someone know that you are interested in what he’s doing and want to better understand it is very powerful. You will earn respect and trust – two things critical to being a good leader.
-Chris
Decision making in any team can be difficult. There are a number of factors that can make it more arduous. The size of the team has a direct influence. The more voices, the longer it takes for harmony to emerge. Geography also affects the speed of decision making. Teams that cannot be in the same room on a regular basis are naturally isolated and coming to agreement is a challenge. Personalities also play into it. Too many (or too few) strong voices can can extend the decision making process. I’m certain there are others to be mentioned but I’ll leave it at that because I want to discuss how we, as technology leaders, can facilitate this process. The outcome I strive for is the highest quality decision possible in the shortest amount of time. There is a cost/benefit that we must calculate as we watch the dialogue progress. Have we taken the time to hear all sides of the discussion? Have we heard a couple of the sides over and over and over again? A balance must be struck. There’s no formula to follow here – it is a gut sense that is developed over time.
I firmly believe in decision making by consensus. The best decisions come when the entire team is given the opportunity to speak up on the topic. This may not always lead to the quickest decision but will be the best for the team. Granted, certain decisions, such as tactical actions in the course of a major system outage, don’t lend themselves to this approach but on whole, I find it works.
Group consensus is valuable for a number of reasons. It gives each team member the right and the opportunity to be heard. It also gives each member the right and the opportunity to listen to the discussion. This is very empowering to the individual. Those that have an opinion, can share it and be heard in a safe space by their peers. Those that don’t have an opinion have the opportunity to listen and form one or perhaps ask questions to better understand a certain perspective. It is important that, as leaders, we moderate this discussion. Two individuals simply arguing is not a team discussion and should be avoided and stopped when it occurs. People are passionate about what they believe and that is a good thing. A team of passionate people will do great things! But passion gets the best of us all at times and when you sense that occurring within the team, diffuse it. It isn’t productive when two people dominate the conversation – that isn’t consensus decision making. This is especially true in the technology space where I’ve found a certain religious-like devotion to certain opinions. (Just try to convince me that there’s a Microsoft product that I won’t immediately loathe!) A good indicator that this is happening is when each opinion is defined by what is disliked about the other rather than stating the benefits of the position. I tend to use questions to focus the dialogue. Ask, “Why do you believe xyz can help us?” or “What’s the main drawback to your suggestion?” When you force people to critique their own ideas, the tone of a conversation quickly changes.
In addition to our convictions, technologists also tend to be very detail oriented. As leaders, we have to avoid the proverbial rat hole. Technology focused teams will dive down into minutiae so quickly because those details are important. A switch on a command line or a certain check box can make a huge difference. The key is that these things aren’t normally important to a decision that rises to a team discussion. That may occur on occasion but for the most part team discussions will be focused on higher level items. When you sense a rat hole, don’t immediately react. In many cases, cutting off an individual once will make him or her reticent to speak up so it must be done with care. Let the discussion go a bit and sense the “pulse” of the conversation. Are only a couple people talking? Has someone that was vocal suddenly shut down? Do you catch folks multitasking? These can be signs of disinterest and it’s important to pull the conversation out of the weeds. Do it gently… “I know there is value in the discussion but I’d like to refocus on xyz, are you cool with that, Chris?” Make sure the team knows that you’ve heard the dialogue, value it, but need to move on. I’ve found that people generally wont belabor a point if they know the group isn’t engaged and by asking to move on, you give people permission to enter into a new line of thinking (or return to the original purpose).
Another important technique to combat rat holing is to introduce strategic goals that may influence the discussion at hand. I recently participated in a discussion around a certain technology where the team was divided into two camps. There wasn’t anyone willing to budge and while I could have simply dictated, I generally don’t like to do that (more on that in a bit). Instead I raised a strategic point around a direction the team had agreed on. I asked the team to consider the question only in that strategic light and consensus was quickly reached. The point here is that it may not have been the correct technical solution for the particular situation at hand but it was the right decision in the long run. Technologists tend to focus on details and particulars. Bringing the wider context into the discussion is important.
As I alluded to earlier, unilateral decision making is an anathema to me. I do it only when absolutely necessary and generally because of time constraints – there simply isn’t enough time to gather the thoughts of my team. I know I’m not the smartest guy in the room. I don’t know all the details and won’t consider all perspectives on a given topic. To proceed an simply tee off with bold direction setting seems arrogant to me. Ask your team to help. That’s what they’re there for. That said, there are times when as leaders we must make a call. When this is necessary, it is important to explain to your team how you arrived at the decision and why they were not involved. No one should be above explaining their decisions to the team.
To make consensus decision making work, it is important that you stress a couple rules to the team around this process. The discussions should be kept respectful at all times. Just because you disagree with someone doesn’t mean you can belittle them. This may seem like common sense but if you’re a third party in a heated conversation, pause to listen to the tone. Are people debating ideas or being combative? As I mentioned before, it’s important to end an unproductive conversation. Finally, consensus is consensus and the team should agree to follow the direction decided. Even if an individual disagreed with it, s/he should fall in line once the team agrees. Continuing to raise the disagreement after the fact is counter-productive and can frustrate a team. Reiterating these “rules” to your team on a frequent basis keeps them front of mind and the instances where people become overly passionate tend to decline. Mutual respect and trust develops. I respect that you will hear and honestly consider my opinion and you trust that I will hear any critique and honestly consider it. That is a great place to be!
I believe that involving the team in decisions, large and small, is critical to a high performing team. People who know they have a voice will participate in the process and feel empowered. This is a great thing in my opinion. You must learn to balance the time a discussion takes vs the quality of the decision reached. Goldilocks applies here – aim for “just right”. Experience is the best teacher.
-Chris
Introductory posts for a new blog are hard to craft. There is so much to cover and I like to be able to do that without boring the reader to tears. This post will give you a little background on me and why I think you’ll be interested in the comments / ideas / information I want to focus on in this blog. My intended audience is folks that work in the technology field (which is wide and varied) but isn’t intended to be a technology blog. There are plenty of those and quite frankly, I’m not quite smart enough or detail-oriented enough to participate in a cutting edge tech dialogue. Instead, I’ll be focusing on leading and participating in technology teams. Through my 15 or so years in the industry, I’ve come across quite a few styles of leadership and I’d like to share what I’ve learned with the wider community – or at least those that have stuck around long enough to read this far! There is plenty of information on leading teams but I believe there are things about technology teams that make them unique and thus generic leadership information doesn’t always apply or simply put, YMMV.
Leading Tech Teams 