Weather Forecasting Doesn't Have To Be This Bad

Picture it - winter, somewhere in the northeastern US, two to three years from now. The National Weather Service is predicting a ‘historic’, ‘crippling’ blizzard. Snow accumulations are predicted to be over 18”, and coastal storm surges could top 4 feet, destroying homes and blocking evacuation.

Everyone sees all these warnings and thinks, “Yeah, right - just like that ‘crippling’ storm we had in January 2015, the one that dropped all of 8” of snow in NYC - the one that the National Weather Service actually apologized about.” Public officials, still stinging from accusations of overreacting with transit shutdowns and travel bans in 2015, decide to keep the roads open and mass transit running.  Residents in coastal communities decide against making storm preparations.

And then the unthinkable happens - the storm exceeds the forecasts. Snow accumulations top two feet. Storm surges crest at 6 feet, and high tide brings massive flooding from Atlantic City to Cape Cod. Thousands of people are stuck on stalled subways and trains for hours without power, in temperatures far below freezing. Others are trapped in their homes without power or adequate supplies. First responders are overwhelmed and can’t reach all those impacted by the storm, and the death toll climbs to over 50.

This is the devastating impact of bad weather forecasting - when people see a storm warning that doesn’t pan out, they are less likely to respond to the next storm warning. We see it in Gulf Coast communities that are frequently warned of impending hurricanes.

But it doesn’t have to be this bad. We have the technology, today, to make weather forecasting phenomenally better. There are two main avenues to better forecasting: better sensing data and added compute power for modeling.

Sensing data is the bedrock of setting the initial conditions for forecast models. The more data you have on initial conditions, the better your model will be. But the state of the art in sensing is still ridiculously close to what we did 30 years ago. Worldwide, there are about 800 weather balloons launched each day - meaning each balloon is responsible for covering about 200,000 square miles of ground area.  

If we really want to get great data on initial conditions, we need to make massive investments in weather-sensing drones - sensing platforms that can be deployed on demand and piloted into storm systems for detailed, fine-grained data on pressure and temperature. And we need to replace the costly system of oceanic weather buoys with autonomously-deployed sensing platforms, like those being developed by Liquid Robotics. Within five years, we could increase our sensing capacity by 10x simply through the cost reductions possible with autonomous deployment.

Once you have all this data, what are you going to do with it? The current approach of NOAA is to make massive investments in single-purpose computing platforms. Earlier this month, they announced that they are investing $45 million, with the goal of bringing their compute capacity for modeling up to 5 petaflops. It’s worth examining whether or not single-purpose computing is still the right approach in a world where massive amounts of cores are available on-demand.

On a sunny July day, 5 petaflops is probably vastly overpowered to create the forecast “sunny and mid-80s today”. But in the face of extreme weather, scaling up to twice that capacity could enable much more accurate forecasting - why not lease 600,000 cores from Google or Amazon for a day, run the severe weather model at 10 petaflops, and create a much more accurate model?

The bottom line is, it is within our technical capacity to end bad forecasts for severe weather in the next 5-10 years, but it is going to require some radical new approaches to sensing and computing.

(Technology) Startup = Growth (through Technology)

If you haven't already read Paul Graham's excellent essay Startup = Growth, please go away and do that now, then come back.

Ready? Good. When I read this essay, I was immediately reminded of Alex Payne's equally strong post from earlier this year, in which he asks the valid question, "What Is and Is Not A Technology Company?". The tl;dr version is that Alex argues for defining technology companies as follows:

You are a technology company if you are in the business of selling technology. That is to say, if your product – the thing you make money by selling – consists of applied scientific knowledge that solves concrete problems and enables other endeavors, you are a technology company.

Whether something is or is not a technology company is a useful question to answer. As Alex describes in some depth, there are a lot of new businesses that get plenty of coverage in TechCrunch, GigaOm, or Your Favorite Tech Startup Blog, but are not really technology startups. However, they are able to go constituencies like the public markets and say, "We use lots of software to run our business, that makes us a technology company, you should give us a multiple like a technology company would get." But we're starting to see how that turns out. There are similarly distorting effects when non-technology companies engage in hiring, compensation decisions, etc, as though they were in fact technology companies.

Riffing on the ideas that Paul Graham put out, I want to offer a new definition for a technology startup. If we believe the premise that a startup is defined by growth, then it's a natural corollary that a technology startup is one in which the growth is driven by technology innovation and execution.

So what kinds of companies does this disqualify from being considered "technology startups"?

• If your startup's growth is driven by marketing deals with big brands and celebrity endorsements, that's a marketing startup (ex: ShoeDazzle)
• If your startup's growth is driven by a massive sales force, calling every local business in the US to get them to sign up, that's a sales startup (ex: Groupon)
• If your startup provides a site or service that grows primarily through users interacting with each other, and bringing new users in, that's a social startup (ex: Instagram)

It's important to accept here that something can be a great startup with fabulous growth prospects without having to be a technology startup. As demonstrated in the case of Instagram, this kind of company can created massive amounts of value without necessarily being a technology startup. I have to wonder if part of why so many companies aspire to the label "technology startup" is that they feel any other kind of startup is a second-class citizen.

The reason I think this definition is most useful is that it can really get to the cultural difference between a technology startup and a non-technology startup. I think there are a lot of good startup ideas out there where you can choose whether to focus on sales, marketing, or technology as the primary means of growth.

This is how you can have a company that sells a technology product as their main means of business, but is actually a sales company. This would be a technology company under Alex's definition, but not mine. For example, many companies providing software as a service to small and medium businesses are not what I would consider technology startups, because the growth vector is a matter of hiring more salespeople to contact more SMBs, not a matter of making the software more complex or feature-rich.

This definition can also be useful in understanding how the focus of a company is a reflection of the founders. I've heard it said that a company can't be a technology startup if none of the founders can code; it seems like this shouldn't have to be true, though in practice a founder is most likely to push growth along the direction that they're most familiar with. A founder who is well-versed in technology is likely to look at growth problems and see how new technology will lead to that growth, whereas a founder with a sales or marketing background is more likely to focus on those functions as the path to growth. What's interesting here is that, for some businesses, it's equally likely that the business could be built either as a technology company, or as a sales company, or as a marketing company, but the way it actually gets built is a reflection of the founders' backgrounds.

Perhaps one of the most telling indicators of what function is a driver for a company's growth is their hiring strategy. Companies that I would call technology startups have a clear sense on the growth  impact of adding an additional engineer, and, as such, are always hiring for good engineers. Sales-focused startups have a similar hiring strategy when it comes to salespeople. But the company that goes months at a time without hiring engineers has not found a way to convert an additional engineer into incremental growth.

In the end, I hope this is a useful rule of thumb for anyone trying to decide if that startup they're thinking of joining really is a technology startup, or just a sales company that uses a lot of software to keep the lights on. I'd love to hear any and all comments on this idea.

If You Want To Hire Me, Maybe You Should Buy Me A Drink First

While I was recently between gigs and looking for my next role, I had the chance to sit down with an old friend who was also going through the process at the time. My friend is a fairly senior engineering leader, has been in charge of big teams shipping lots of product, and generally fits the profile for a VP of Engineering or CTO kind of role in a startup, or perhaps a high-profile leadership role in a larger company.

As we compared notes on the hiring process, it turned out that our experiences had been eerily similar in one important regard. It seems that, all too frequently, the hiring process for senior engineering leaders goes like this:

1. A recruiter cold calls, cold emails, works their network every which way they can to get a candidate on a 15 minute call to pitch the company they're hiring for.
2. After the call, our candidate agrees to meet with the company for an initial discussion
3. The candidate is immediately routed through some arcane bureaucracy that throws up walls to keep them from having that discussion. Fun examples include:
• candidates being told they have to sign an NDA in order to talk with the CEO at all
• working with an admin who shows zero flexibility in making time on calendar for the meeting with the candidate
• dealing with an in-house recruiter who sets the candidate up for a full-day interview as the first step in the discussion.

I wish that, when I was a single guy, I could have dated this way. I would have hounded a bunch of women to go on dates with me, and then, as soon as they agreed to a date, I'd have said, "OK, I'm available from 7:15-8:45 pm Thursday night three weeks from now, but before I can go on a date with you, please fill out this ten page application for a relationship and submit it along your most recent GRE scores and STD test results."

The dating metaphor is mostly a joke, but it does hold some merit. Entering into an employment relationship is a big commitment for everyone involved, particularly in startups, and it requires that everyone have the opportunity to get to know each other and feel very comfortable working together. More importantly, the simple fact is that selling needs to happen in two directions - just as the candidate needs to convince the company that they can do the job, the company needs to convince the candidate that the company is a good place to work.

This should be completely unremarkable common sense, but anecdotal evidence from the NY startup scene indicates otherwise. For example, I was once able to win a coveted recruit away from a much larger, more successful, startup because I told the recruit in detail what was special about him that would make him so important to our team; the other startup had told him, "We want you to come here to write code, we think you will be good at writing code." In dating terms, this is like the pickup line, "I am male and my observations indicate you to be female. This indicates we should be a compatible match. Shall we intercourse?" 

Often times I've seen companies make the opposite kind of dating mistake - jumping to a commitment way too early. On one occasion a few years ago, I met with a startup CEO for a first conversation and walked away thinking, "Hey, good meeting, definitely going to have a follow-up conversation with that company." The next day, the CEO called me with his offer. In dating terms, this is like going out for coffee on a blind first date, getting a handshake goodbye, and running out to buy an engagement ring.

Taking the dating metaphor to the offer stage, one of my favorite pieces of recruiting advice is "Extending an offer is like asking someone to marry you - you shouldn't ask until you know the answer is going to be yes." When I'm hiring, I've found this to be incredibly useful as a way to drive the end-stage recruiting conversation. Think of it this way - most people, when deciding to get married, spend a lot of time discussing their values, their dreams, their aspirations, what makes them who they are, and then, when they feel like there is a match, they start shopping for engagement rings. If you're making an offer before you've talked through ever key issue about working together, you're basically buying an engagement ring before you know if the other person feels the same way that you do about having kids. In practice, the way I make this work in recruiting conversations is to let candidates know that, once we both feel great about the fit, we can find an offer that will work, but first let's make sure everything else has been covered.

Alright, enough ranting. Let's summarize why it's useful to think of recruiting for startups like dating:

• Both sides need to be selling throughout the entire process. Just because you don't have evidence that a candidate is qualified doesn't mean it's too early to start selling them.
• You need to convince the candidate that there's some special reason to enter into the working relationship; hiring someone to be yet another generic cog in your machine is a no-win proposition.
• You wouldn't ask someone to marry you if you weren't sure they were going to say yes; the same approach works very well with job offers.

Hopefully this is all obvious but, again, anecdotal evidence indicates otherwise. I'd love to hear any other examples of the dating/recruiting parallels (or even some counterpoints!).

The Attrition Funnel

My post on the Recruitment Anti-Funnel touched on the idea that one of the worst things you can do for hiring is to lose good people. The downside of losing good people should be obvious, but let’s state it explicitly in terms of recruiting - when you lose someone good, you suffer multiple losses for your recruiting efforts:

• you’re short one person (obviously) - however many people you were trying to hire before, now you need one more. Depending on how your funnel converts, this could require adding a few hundred more people to the top of the funnel.
• you risk having someone out there in the market telling your potential recruits that your company is not a good place to work
• more likely, even if that person isn’t telling people that your company is not a good place to work, LinkedIn makes it clear that they left; in the absence of information about why someone left, outsiders will assume the worst, taking any attrition as a sign that your company is not a good place to work.

Of course, this ignores all the other negative effects to your team and your company that come with losing good people, this is just how losing good people makes recruiting harder for you.

As with bad recruitment practices, I have spent enough time with startups over the past few years to see a number of common bad habits that lead to attrition among engineers - let’s call this your Attrition Funnel, the gradual sequence of steps you take to move people from “great employee” to “former employee”.

You’re managing down to people. Engineers in today’s market are less like traditional employees and more like free-agent entrepreneurs; each day they are making a conscious choice about whether to keep working at your startup, whether to return the phone call from the recruiter who has been hounding them, whether to IM a friend at a cooler startup to line up a new job, or whether to just quit and finally figure out doing their own thing.

An engineer in this mindset isn’t focused solely on the technical challenges that are directly required of them in their role - they are constantly evaluating every aspect of the company to assess whether the company is headed in the right direction. They are reviewing every metric they can get their hands on (which, by virtue of their access to internal datastores, is much more than someone non-technical might expect). They are asking questions about marketing strategy, product priorities, and sales compensation schemes.

In that environment, I am always flat-out gobstopped when a CEO asks me, “How do I get engineers to just stay focused on the technology problems instead of the always poking around the rest of the company?” In the pathological case, this comes out more like “No, I am not going to explain the company strategy to the engineering team, their job is to write more code and let me worry about the strategy!” 

For an executive dealing with engineers, this phenomenon is perhaps exacerbated because it is a behavior somewhat unique to engineers. I’ve rarely seen an individual contributor salesperson ask a CEO challenging questions about technology strategy, for example. This may be a matter of engineers flexing their market power (eg, “I need to know this to assess whether I can be at a company with better prospects”), or it could be a matter of a different perspective on the part of engineers, I can’t say. For executives in non-technical parts of the company, the glaring difference in behavior between engineers and non-engineers can lead to the conclusion that somehow the engineers at your company are just exceptionally difficult to deal with and intent on learning about areas you think they shouldn’t be concerned with. Trust me, engineers at every startup want answers from the executive team about every aspect of the business.

In any event, leaders in startups need to be prepared to handle the challenging questions that come from their engineers, regardless of the topic. Failure to address the questions from your engineers will make them feel like you are treating them with less respect and transparency than they are entitled to; this is a shortcut to stripping them of a sense of empowerment, and makes it very easy for another startup to recruit them away with promises of real impact and access to the executive team.

You’re churning on strategy. It’s become very trendy in the past twenty-four months or so to pivot, to make a radical change in strategy that redefines a company. Pivoting shows that you’re lean! You’re always learning! You’re nimble! Still, there are a lot of ways a pivot can work against you in terms of attrition. Sometimes, a pivot is really just flailing, as Steve Blank describes well here. 

I don’t want to get into the debate about how to avoid bad pivots, so, for sake of this discussion, let’s assume that every pivot you’re considering is a stroke of strategic genius that will set your company up to double growth rates, triple revenue, and give everyone a unicorn.

Even in the case of the perfect pivot, a strategy change can have a big impact on employee morale and hence, attrition. A large part of the decision to join startup, much more so than a big company, is subscribing to a vision of where that startup is heading and how it is going to change the world. When the strategy changes, employees can be left feeling like they were misled or, in worst case, lied to, about the prospects of the original vision.

In some sense, this issue is a concrete case of managing down to your engineering team - they want the opportunity to evaluate a new strategy, understand all the factors that went into it, give their input, and decide whether they are signed up for this new vision. In the best case, the CEO or their designee should take the time to meet with the engineering team as a group or individually and really sell them on the pivot. The pathological case I have witnessed too many times is the CEO who says, “This is the new strategy I’ve figured out, this is what we’re doing. Anyone who isn’t ready to sign up for this right now is just not a team player.”

You’re not paying market rates. This is the easiest mistake to avoid and the one that pains me the most to see. I’m on the record that I think engineering compensation has gotten out of control, but for the foreseeable future, at least, as you’re budgeting for your startup, you have to plan for the fact that engineers are expensive. If your financial plan depends on people being willing to work for you at a salary 20-30% below what they can make at a similar-stage startup, you are going to be in trouble.

I intentionally did not highlight this issue in the post on recruiting, because I have found that many great engineers are willing to take a below-market pay rate when joining a new startup, even as compared to similar startups. As such, paying below market doesn’t always hurt your recruiting efforts. This is a good thing for everyone involved - you hire new engineers, give them big equity packages, and incent them to make their equity worth gobs and gobs of money. In my experience, this situation can usually last for 12-18 months without issue. After that, if there’s no market confirmation that the equity is increasing in value, people naturally want to see an increase in their salary. If you’re not ready to bring salaries up to market rates, you can count on people starting to look around.

Figuring out how to assess the appropriate market rate can be a challenge, as good data on comparable startups is generally difficult to find. The recently-released Wealthtfront tool is the most credible and useful way I’ve seen to get a quick gauge for what you should expect to pay people.

Even the Wealthfront data is pretty broad though, making it tough to assess how your compensation compares to your immediate peers. The most pragmatic way I know to assess where you stand relative to the rest of the market is to collect data through the hiring process. When negotiating offers with engineers, many people are willing to disclose the details of their competing offers. Every competing offer you can learn about is a concrete piece of evidence showing how your offer compares to your peer companies for the same employee. Over time, enough data can help paint a pretty clear picture of the comp structure at your peer companies.

Of course, there are innumerable other ways to build a strong Attrition Funnel. The spirit here is not to be exhaustive, but these are the mistakes I have seen startup leaders making over and over again that are most easily avoided and most likely to build a strong path of good engineers walking out the door for better opportunities.

The Engineering Recruitment Anti-Funnel

I learned yesterday that the referral bonuses for engineers at some NYC startups are starting to get huge - one prominent NYC startup is now offering its employees $10,000 for each successful referral. This is a classic “throw money at the problem” solution to attracting engineers, and, while economic incentives certainly do impact behavior, I doubt it’s going to help enough.

Hiring engineers is hard, hiring great engineers is harder, and hiring great engineers at scale is impossible if you insist on doing it wrong. Still, I don’t want to write Yet Another Blog Post On Hiring Engineers, so today let’s talk about what I’m going to call the Recruitment Anti-Funnel.

So much of hiring these days is focused on the funnel - increasing a referral bonus, for example, is meant to increase the number of applicants at the top of the funnel, using external recruiters is meant to be a way to get a higher-quality funnel, faster turnaround time from interview to offer is meant to reduce leakage from the funnel, etc. The thing that I see these days is that so many startups are doing so many things outside of the funnel that just broadcast the message “Good engineers should not work here,” and I don’t think they have any clue that they’re doing it.

In no particular order, here are the Anti-Funnel patterns I see over and over again.

You’re churning through the good engineers you already have. This is an oft-overlooked factor, but many big startups in NYC have burned through a number of great engineers, people who have moved for any number of reasons, usually along the lines of unhappiness with the company, the product, or the team. Every time you lose a good engineer, you’re putting someone out into the marketplace who is willing to tell other engineers to avoid your company. This message transmits over drinks, at meetups, in IM conversations - “Oh, you’re talking to X? Ryan worked at X for 8 months and said they have no clue, I’d stay away from there.” There really is a guild of software (and it exists outside the valley!), and the members will warn each other off of joining a company that’s burning through good people.

Really great technology startups fight tooth and nail to keep their good people. If a good person is unhappy, that is more likely a problem with the company than a problem with the person.

You’ve hired an engineering team of “band-aids”. Many non-technical founders, stuck between the rock of “can’t find any good engineers” and the hard place of “have to ship product to keep the board happy”, take the cheap way out and fill seats with any engineer who can string together three lines of PHP. You can convince yourself that this is just a band-aid, something to get you through until you can start to find some stronger people.

Hiring for band-aids is like choosing the Dark Side of the Force: it’s quicker, easier, more seductive, and once you start down that path, forever will it dominate your destiny. It’s a well-known startup adage that B players hire C players, but we less often consider the inverse; I’ve never met an A player or even a B player who wants to join a team of C players. Your band-aid hires become the strongest factor in discouraging strong people from joining your team.

Great talent attracts great talent; bad talent repels great talent.

You’re broadcasting your complete lack of understanding for how hard it is to build software. I am constantly meeting with entrepreneurs who show me a development roadmap that should take two years to build, then tell me that if they can hire two or three great people it should all be done in six months. No one pushes as hard as I do to get more things done more quickly, but the practical reality is that software is hard, and until you’ve been through the cycle of building big systems, you really can’t appreciate how hard it is.

This pattern is particularly poignant in early stage startups, when the founders are not technical and don’t have good help in hiring for engineers. When you demonstrate to engineers that you have unrealistically ambitious goals for what they should be able to do, you’re advertising  to them that coming to work for you means endless nights and weekends trying to live up to ludicrous schedules.

Like I said, there’s no good way to learn how hard it is to build software until you’ve built software. If you want to at least get a feel for it, I highly recommend the book Dreaming in Code - it’s a great non-technical account of how Mitch Kapor, the creator of Lotus 1-2-3, set out to build a new open source software product with a stellar team and tremendous backing, and, for all intents and purposes, failed.

If you don’t understand anything about building software, you can’t attract people who are going to build software.

You have shitty office space. This Anti-Funnel pattern is certainly not as lofty than the others, but it’s pragmatic and it’s real. Working conditions matter a lot to good people, and when they come in to interview, they are evaluating your space as somewhere that they will spend 9 to 12 hours a day. No one is saying you have to have offices like Google, but many great startups have great office space. It is expensive, and, if you’re looking at a straight P&L, it looks like a waste of money, but it is a lot cheaper than $10,000 referral bonuses.

Good office space is expensive when viewed as an administrative cost, it’s super cheap when viewed as a recruiting cost.

Now of course, to build a great engineering team, you need to optimize your hiring funnel - you’ll get no argument from me about that. My point here is that you could have a perfect hiring funnel, but if you’re following these Anti-Funnel habits, the biggest referral bonuses in the world won’t be enough to help you build the team you need.

Leadership Mechanics: Handling Challenges From Your Team

If you've been an undergraduate at Carnegie Mellon any time in the last twenty or thirty years, you've been impacted by Michael Murphy. You might not have known about Michael at the time, but he has held a variety of roles in Student Affairs in that time, so to some extent, much of what happened to you outside of a classroom was under Michael's influence.

When I was at CMU in the mid-to-late 90's, Michael was Dean of Student Affairs, a vast role that included responsibilities for things like housing, dining, and student activities. I could say a lot about great leadership traits I saw Michael exhibit at that time, but one of the things that stood out to me was the way he'd handle students challenging him about various choices made by the administration. I remember one instance as clearly as if it were yesterday.

As a bit of background, at the time, the campus had two dining venues that accepted our meal plan, and they were both awful. Just terrible. For most of my second semester freshman year, dinner each night was cheese fries, because they were so hard to get wrong.

Anyhow, at some point Michael was doing an open Q&A with students, and someone asked, "Why can't we have a McDonald's or a Taco Bell on campus?"

Michael's response was not so much an answer as it was a full treatise defining the pros and cons of having a franchise fast food restaurant on campus. He acknowledged the appeal of having something familiar and consistent, he conceded that it was an option that had been raised and considered on multiple prior occasions, and then proceeded to recite a set of reasons why the idea had been rejected in the past. Fast food menus don't vary, at all, meaning it is easy to get bored very quickly with what's available. Large corporations don't have much flexibility in how an individual franchise works, so the school would have little influence on the operation. It's not clear that the economics of having a franchise on campus would appeal to a major fast food corporation. Putting such a franchise on campus could draw in people from outside the campus community, which is not certain to be the right choice.

Michael was under no obligation to give a thorough explanation of the reasoning behind the choice not to have a fast food franchise on campus. Given his position, he could have simply said, "We've looked at that idea, it wouldn't work, we're not going to do it." I think though, that his goals as a leader were better served by going through the detailed explanation. In particular:

• He showed the entire audience that he respected their input and responded to it thoughtfully. When you think about it, a group of entitled undergraduates probably didn't deserve that level of respect from a high-level university administrator, and yet he showed the respect anyway. 
• He demonstrated that he had a command of all aspects of the issue. There's tremendous power in simply demonstrating that, as the leader responsible for such choices, he had given it far more thought than his original questioner had. 
• He worked to persuade the audience that the solution they had in mind wasn't as simple as they thought. Whether or not Michael convinced anyone about the right choice to make, he made sure everyone walked away understanding that the choice was not black and white. I think this was particularly valuable because Michael treated the audience in a manner appropriate to their intelligence - this wasn't a matter of communicating to them a decision that had already been set in stone, as much as it was a matter of bringing the audience into a nuanced dialog with no clear best solution.

What leader hasn't had the experience of being challenged, particularly in public, by someone on their team who wants to see things done differently, or who is questioning a decision, or just wants to sound off about something that's annoying them? The anti-pattern that happens all too often is for a leader to shoot off something like "It's more complicated than you understand, but what we're doing is the right way," or, even worse, when the leader responds by directly attacking the questioner - a response that usually comes from a place of feeling disrespected.

Here's why this really matters: the leader who shuts down challenges from their team leads that team to abdicate all responsibility for change - what member of a team tries to push the group in a new direction if their input isn't respected by the leader? The ultimate outcome is a team where the leader is the only one ever creating change, because the rest of the team has seen that their own attempts are never treated fairly.

As a leader, it takes a tremendous amount of self-confidence to hear a challenging question, listen to the intent of the person asking it, and respond in a spirit of mutual respect and productive discussion. At the core, I have found that leading in this kind of situation requires the humility to accept that sometime someone will make such a challenge and I will have to say, "There are plusses and minuses to what you're saying, but yes, on the whole I think you have a better way, let's figure out a way to make that happen."

Those experiences have always created positive outcomes for me on teams I have led, which is why I think careful and considerate response to challenges from your team is a critical one of our Leadership Mechanics.

Leadership Mechanics: Staying Above the Fray

In college, I was in a fraternity, but not just any fraternity - I was part of a group of incredible men who founded a new fraternity on campus. I don't really know what it's like to be a fraternity that has been around for decades and has established protocols, but I know that in my fraternity, we spent most of the first two years of our existence by arguing about The Way Things Should Be Done.

What should the minimum GPA be? What about the minimum GPA for elected officers? What should we do about brothers hosting keg parties off campus? What about on-campus but not in the house? When do we hold elections? Can we spend money on paintball during rush? Should we be allowed to eat in meetings? I'm not kidding, these are the things we argued about.

The house generally divided into two groups, which, in the interests of fairness to all involved, I'll call the drunkards and the uptight assholes. For any given question, there were usually two takes on it, and it was always the same set of people arguing the same predictable positions.

We had a pretty open policy toward discussion in those meetings - if a brother had something to say, he would always get the chance to say it. This is why my Sunday evenings in those days were completely unproductive - house meeting would start at 8 and go until 11 quite frequently.

Among all the debating and arguing about the finer points of fraternity management, we had one very important brother, Jeff. Jeff was a basketball player and electrical engineering major, and usually a very quiet guy. When we were debating some of these "issues", Jeff usually sat silently and listened.

But after about six months, a very interesting pattern emerged. After endless debate on some minuscule topic, Jeff would slowly raise one giant basketball-player hand, never higher than his chest, and wait for his turn to speak. And whenever he did, he would calmly summarize both sides of the issue and propose a solution. But here's the really crazy thing: without fail, everyone would all hear it and say, "Yeah, he's right, let's do that."

It was uncanny. It got to the point where, if we were having a debate and Jeff raised his hand, someone in the room would say "Shut up guys, Jeff wants to say something". He was like our own personal Messiah of mediation.

To this day I can't figure out exactly how Jeff was able to create immediate consensus between two groups that had been yelling at each other moments earlier. But I can point to one key tactic he employed - Jeff never spoke up until he thought he could find a suitable middle ground, he just waited patiently. He stayed above the fray.

If he had spoken up earlier, he would be perceived as having "taken a side", and all further comments would be colored by that perception. Instead, it was as though he was the one person in the room who could speak directly to all stakeholders, showing them that there was a balanced approach suitable to everyone.

Staying above the fray is useful in any group dynamic, but it's critical when you're in the position of leadership - nothing can kill a productive debate more quickly than a leader indicating a preference for a particular outcome. In the common case, the leader's comments have the effect of silencing all counter-arguments, thereby ending the discussion before it can be fully explored.

In my own career, I work very hard to employ a similar tactic every chance I get. If two people in a meeting are arguing about some point, I try not to dive in right away and pick a side, but I wait until I think I've heard what each of them have to say, and then try to point out underlying motivations or shared interests that can build toward consensus.

As a leader, it's critical to me that I not be perceived as playing favorites or not letting everyone have a fair say in a debate. More often than not, a good group of people can come to a great answer without the intervention of a leader, but when it is required, that intervention comes best from someone who has obviously listened to all input and is focused not on a personal preference but the solution that is best for everyone - in other words, the person who has stayed above the fray.