Back From My Career Break

One of the hardest things I have ever done in my career is handing in my resignation to DellEMC.  I didn’t leave for another position but rather to hike the Appalachian Trail.  I departed work on April 6, 2018 to pursue an item on my bucket list.  I left behind a team that I adored.  They were vibrant, smart, motivated, and kind – best of all, they put up with me!  Saying goodbye on that team call was very emotional and heartfelt.  But, truly, I would do it all again.

I have been working for nearly 20 years in IT and have held positions with only two different companies.  I suppose it is four if you count being acquired – Genzyme by Sanofi and EMC by Dell.  In my experience, staying for long periods of time within organizations is rare in the technology industry.  Folks seem to move around a lot.  I stay put because I like to cultivate relationships.  The bonds of a team don’t form in a year or two and I believe that as a leader, you need to be in it for the long haul.  These relationships are what made leaving so difficult.  But it was something I needed to do.  I felt burnt out, stressed, and wasn’t able to give my best to the job anymore.  For a lot of reasons, a simple vacation wasn’t the answer.  I had tried that and couldn’t get the fire back.  I owed better to my team.  A change was needed and a drastic one at that.  I needed to take a break from working, a break without worrying about returning to a job.  I tried to get a Leave of Absence / Sabbatical but that didn’t work out.  At that point, I decided to resign.  For why I chose to hike the AT, you can check out this post on  Suffice to say, for the first time in my professional life, I was unemployed.

And now I am back.  I cut my hike short because being away from my family proved to be more painful than the joy hiking brought me.  I hiked the southern half of the Appalachian Trail from Georgia to the West Virginia / Maryland border.  I learned a lot about myself in those 1000+ miles.  I believe I have returned a better father, husband, and person.  Being free from the responsibilities of daily life, focusing only on one foot in front of the other, was amazing.  It is easy to get caught up in the frenetic energy that surrounds us – be it work, home, or whatever.  We are generally busy people and slowing down brings that chaos into focus.  It allowed me to put everything aside for 10 weeks and just walk.  All I had to worry about was food, water, and where I was going to pitch my tent that night.  I certainly found a lot of other things to worry about, but the simple essentials were what centered me.  I also learned to be grateful for what I had, for others lending me a hand, and for my family and friends for their support.  I didn’t realize the network of care that surrounded me until I had to rely completely upon it.  I learned to be extremely thankful.  All of this has made me more intentional about the balance in my life.

As I return to the workforce, I would like a role working toward an end that I believe in – helping people, solving problems, making a difference in a true and meaningful way.  A company churning out generic widgets to make a buck isn’t for me.  I need an employer that values a balance between work and home.  My family is hugely important to me and I am a devoted father.  I am also a loyal and passionate team member.  I want to bring my rediscovered energy back into my work.  I will run through walls for my team.  I’m hoping to find a role leading a smart group of people doing exciting work in technology.  I am confident in my abilities and know that I will make a positive impact on any organization that I join.  If you believe I might be a fit for a role you have, I would love to speak with you.

– Chris

Action over Discussion

One of the complaints that I hear over and over again from my team is that they spend far to much time in meetings.  They spend too much time talking about work so they have little time to actually do it.  It is usually coupled with the gripe that the meetings themselves don’t accomplish what they’re supposed to or don’t have a stated goal to begin with.  While I don’t always buy the venting as complete fact, I know that there is a lot of room for improvement in the meetings that I myself run.  But this post won’t be about how to run a meeting… there’s plenty of info on that topic here, here, and here.

As a leader, it is important that when a decision needs to be made, you make it.  Waffling, entering into analysis paralysis, or simply delaying because you’re unsure can quickly lead a team into the ground.  Timelines become extended, people have more idle cycles, and tend to lose focus.  Setting direction is a responsibility we all have as leaders.  Take the right inputs, analyze them, and decide as quickly as possible.  The cost of not acting in a timely fashion generally outweighs the greater degree of quality gained by further deliberation.  This is certainly an art more than a science but in general action should be favored over debate.  See this post on decision making in teams for some more info on the topic and how it applies in the technology space.

There is a fine line between acting too quickly and taking too long to act.  It is a skill that we must develop as leaders because straying too far to one side is detrimental to our teams.  Acting to quickly leads to a higher percentage of incorrect actions and more time spent cleaning up the mess you’ve created.  On the other hand, not acting quickly enough has opportunity cost and generally ends up accomplishing less in the long run, even if you’re correct more often.  But I guess it’s fairly obvious that one extreme or the other isn’t the way to run things.  Somewhere in the middle is likely the best course.  My belief is that on the continuum from brash action on the left to over-extended deliberation on the right, a little left of center is where I’d be.  Consider all the facts you can with a bias toward action.

I favor action over discussion in most cases because you can adjust course later on but you can’t go back in time to make a decision earlier.  No matter how much discussion / thought occurs, mistakes will be made.  If perfection could be obtained with enough thought, I might deliberate a lot more before acting.  Perfection won’t happen and I don’t believe a few percentage points of accuracy is worth tacking on extra time to every decision.  Making an incorrect choice can be corrected and being wrong isn’t something to fear.  Besides, I’ve learned a lot more from my mistakes than my successes.

To be or Not to be, A Manager

There came a time for me, relatively early in my professional life, when I saw saw two distinct paths I could take with my career.  I could continue in the technical track and aspire to a consultant level role, demonstrating mastery in a particular technical arena.  Or I could pursue a role in management, leading teams and organizations and putting them in the best position to be successful.  I chose the latter based on a number of factors not the least of which was that reading manuals and configurations guides isn’t something that grabs me.  I believe that individual contributors that show leadership ability will (or at least should) eventually be faced with this choice.  Neither path is the de facto correct one – it is based on each individual’s situation and aspirations.  I’m going to address some of the forces at work in this decision, using my own situation as an example throughout.

Owning one’s career path is something every should feel empowered (and responsible) to do.  No one will advocate on your behalf if you don’t step up to the plate.  With this in mind, the choice between a technical role and a management role should be carefully considered.  Some will argue that there are positions that split the difference – often these are called “technical manager” or “working manager”.  While I don’t dismiss the idea out of hand, I do question its validity.  In small organizations, I can certainly see it.  Small team, not a ton of funding, small scope – plausible for someone to manage the team as well as participate in the day to day responsibilities of the group.  As you move into larger organizations, however, “working manager” sounds more like “We know we need a manager but we don’t have the headcount so can you do two jobs at once?”  I believe this is an awful place to put someone and while some may see it as a stepping stone, I fear that this type of role splits time such that to succeed in one set of responsibilities, one must give up on the other.  Or simply commit the necessary hours to be successful at both (bye bye work/life balance).  I’ve laid this out as black and white and I know gray exists.  I’m always wary of job descriptions of this kind.

Assuming you’re faced with a choice between a technical role or a managerial role, what factors should you consider in deciding which road to take?  The primary question here is always a simple one in my mind – “What do you enjoy doing?”  At it’s core, this should really be the driver for your career.  There are other factors that certainly come into play but if you’re not happy doing what you spend 40, 60, 80 hours a week doing, it weighs on you.  While this is certainly a subjective factor, I believe it should come first in the conversation and not lower down the list.  The decision between a technical role or managerial role becomes clarified when viewed in this light.  You’re in a technical field because you like technology – that is a given.  Do you like working directly on technology, developing solutions or do you prefer leadership and growing people?  Do you prefer working in Visio or working in PowerPoint?  These roles have fundamentally different sets of responsibilities which translates to a different “day in the life” and a good indication of which will make you more satisfied at work.  I don’t want to oversimplify this decision as it a difficult one but first and foremost ask yourself, “What is going to make me happy?”

In an ideal world, personal happiness would be the only driver and we wouldn’t have to consider anything else.  But this is reality and of course, there are other pressures.  The first factor that comes to many people’s mind is salary.  Generally speaking, the ceiling for a management track is higher in terms of salary but for lower level management, the scale is usually tipped toward the technologist side.  This changes as one rises up the management career path but generally, you don’t become a Director overnight.  In my own personal experience, becoming a manger didn’t accelerate my salary as quickly as I thought it would.  Of course I was completely ignorant of the facts at the time!  I was lucky in that I also knew what would satisfy me professionally so my personal happiness and financial goals aligned.  If financial pressure outweighs personal happiness and you are leaning toward pursuing the higher ceiling rather than your own fulfillment, I’d caution against chasing the paycheck.  In the end, I don’t think it outweighs going to work with a smile on your face coming home the same way.

Opportunity will also often play into this decision.  If you have been career planning with your manager and have indicated a desire to consider a management role, know that they do not come along often in organizations.  If an opportunity does arise, you need to make the decision one way or the other and know that you are probably making it for at least the medium term.  There is opportunity cost of another type as well.  I’ve often heard sentiment that, “They only knock on the door once, you’d better answer.”  That is unfortunately, for many environments, accurate.  If you are offered a role and turn it down, it likely won’t come around again for a while.  That said, if you have a good relationship with you boss, this isn’t insurmountable.  If a management role is what you want, but you have concerns with the role being offered or your preparedness, be open with you boss.  Look to understand the support you can expect.  Transparency is key in this discussion.  Don’t be overconfident only to flame out.  If you’re worried about losing you technical edge, discuss that too and ways in which you can maintain it.  Management roles provide a constantly changing set of issues and puzzles, akin to the changing technology landscape that technical individual contributors have to deal with.  The skill sets required to tackle each are certainly different but both are challenging.  If you decide to go after a management role, keep the dialogue open with your boss constantly.  That way, when an opportunity arises, you be able to assess it accurately and discuss your concerns openly.

The final factor in this decision doesn’t apply universally but I believe occurs frequently enough to discuss.  Many times, if an organization is inclined to promote from within, you may find yourself in the position of managing people who were once your peers.  While this can be a tough situation, I would not let it dissuade you from taking a role.  If people have issue with reporting to you because you once shared a metaphorical cube, that is their issue and not something your are responsible for.  Open communication is key but do not feel bad if someone doesn’t adjust well.

If your decision is still muddy, there are certainly roles that strike a balance between technology and management.  These roles have titles like technical program manager or team lead or technical lead.  They certainly vary by organization but in general these are roles with some good technical depth but that also layer in the leadership that many find appealing about management (and without the paperwork!)  These jobs are never all technical or all management so if you are unsure about where you career should take you, these are options to help you test the leadership waters without diving in.  They will all help to develop skills necessary in management without committing you to a pure management role.

I have great respect for both career paths I’ve discussed here and while my decision was fairly simple, I know that many struggle with it.  The pressures of personal happiness, finances, opportunity all play into this choice.  Nothing is wrong with either option – you have to pick the one that is right for you.

Why Trust is Critical to Leadership

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.


The Importance of Listening to Your Team

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.


Decision Making… Democracy Except When It Isn’t

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.