Maslow's Hierarchy of Employee Needs (with help from Gallup)

I previously talked through Zod's axioms, which form the cornerstone of my management philosophy.  However, they aren't the complete set as I've added a few things to how I think about management.  Consider this the second pillar of my overall management philosophy.

The Gallup organization surveys companies all over the world, and once they had amalgamated data from over 1,000,000 employees, they dug into their data and did some research.  Their goal was to distill management principles that were the most predictive of a successful company.  The result was Q12, a set of 12 questions that best predict company success based on the engagement of their employees.  While Gallup uses them as a measuring tool, it's interesting how many of them form a checklist to management to ensure they're creating the right environment.  I find these questions are something of a Maslow's hierarchy of needs for employees, ranging from the most basic necessities to some of the last few which I don't worry as much about.  The questions are all true/false and phrased as statements from the employee.

1. I know what is expected of me at work.
This is so basic and obvious that managers assume they have explained this already, and often haven't.  If an employee isn't 100% certain how he's being measured and what you expect of them, they have almost no chance of delivering against it.  Especially when someone is joining a new organization it may not be obvious what falls in their domain or not.  Is setting the schedule the engineering manager's job?  or the product manager's?  How about prioritizing the next 3 months? Is the current product critical and has been promised for customers?  Or a research project?

Regular reviews are critical for delivering on this statement.  New employees particularly should have quarterly reviews, and once they're got the rhythm you can probably fall back to semi-annual.  Reviews should cover clear goals of what you expect should be done, and evaluation of how they've done against those goals in the previous period.

2. I have the materials and equipment I need to do my work right.

If the first statement is water, this one is food. Knowing what you need to do and not having the tools to get it done is a recipe for frustration and resentment.  Again, it's so obvious as to be frequently overlooked.  Perhaps your Unix developers need a side windows box to read the Word file requirement documents.  Or Valgrind doesn't work on your platform so you need to find an alternate memory leak detection tool.  Your job as a manager is to remove obstacles for your stars, and providing the right tools is one of the simplest obstacles to overcome.

3. At work, I have the opportunity to do what I do best every day.
This statement echo's Zod's first Axiom that people don't change. Since people don't change, the job of a manager is to put people into a role that plays to their strengths, allowing them to do what they do best every day.  Take the person who is super anal, and put them in charge of a very complicated project management task with lots of details.  Give your creative person an open ended design problem to solve.  Not only will they do it well, but they'll love their work since everyone loves doing something they're good at.

The challenge here is that you have a set of work that needs to be done that usually doesn't match up 100% to the skills you've got on your team.  That's the art of management.  Understanding the principle that you want to assign roles based on what people are great at, you will also have to get people to do work that doesn't match up 100%.  The key to me is "every day" not "all day". There will always be work that doesn't match your interests, but you should have some time every day to work on something you are great at.

4. In the last seven days, I have received recognition or praise for doing good work. 
5. My supervisor, or someone at work, seems to care about me as a person. 
6. There is someone at work who encourages my development.
I lump these three together as the Maslow equivalent of "Love."  Does someone care about you and work to make you better.  #4 is so basic and easy, and one that I struggle with.  I'm just not a cheerleader and I assume that people know that I appreciate the work they're doing.  But it's so cheap and easy to tell someone "great job on that feature!" that there's no excuse not to.  #5 and #6 are reflections of Zod's axiom that you are only as good as your lieutenants. If you hope to develop and take on more responsibility, then you need to be encouraging your lieutenants to develop and care about them as people.

7. At work, my opinions seem to count.
This argues for a transparent decision making process where input is broadly solicited.  Oracle is well known for having a top down decision making process.  The top exec team decides on the priorities and strategies and maps those down through the organization.  Google, on the other hand, is known for a bottom up decision making process.  I've heard managers there complain that they can't even get their own team to work on something.  To ensure that people's opinions count, it's got to be clear where to express them to have an impact on the company.

8. The mission/purpose of my company makes me feel that my job is important.
This simple sentence really needs it's own post.  It's super important for every person on the team to know how what they're working on maps to the short term projects, and how those map to the companies strategy, and how that maps to the overall mission of the company. 



9.  My associates are committed to doing quality work
While not immediately obvious, this is a corollary to Zod's not being a communist in compensation.  Your job as a manager is to build a high performing organization, and it's critical to highly reward the high performers, and to get rid of the low performers.  Jack Welch talk's extensively about 20%/70%/10% and the culture of rewarding high performers and getting rid of the bottom 10% each year.  While it may seem a little harsh, letting the low performer remain in your org will lead to people thinking their peers aren't committed to doing quality work, and thus they don't need to work as hard.  It's a cancer in your organization that will spread if you don't get rid of it.

10. I have a best friend at work

11. In the last six months, someone at work has talked to me about your progress.
12. In the last year I have had opportunities at work to learn and grow
The rest of the list.  11 and 12 are a little redundant with 4-6.  10 is something that comes about when the culture is excellent, but I see it as more akin to self actualization than driving actions for the management team.

I use this list as a checklist, particularly at review time.  I run through the list and try to answer for all of my directs, and for the key people in their orgs.  Any areas that I find I don't have good answers to create a clear list of actions I need to take.

Doing incentives right

I joined a group of my friends in a 90 day body fat challenge starting this January 1st.  We each pay $100 into the pot, and there are monthly winners and the overall 90 day winner takes the bulk of the money.  We're two weeks in and I'm pretty impressed with the group average being 3% weight loss, and 13% body fat loss (that's percentage of a percentage, so 22% body fat down to 20% body fat).

We'll see how it goes, but I am fascinated by this graph.  It's the Google Trend graph of "fitness" with a two week spike coming each January as people make their New Years resolutions.  If that's any predictor, then most of the people in my contest should start dropping out over the next couple weeks.  I suspect, however, that the money component people paid in should change the outcome significantly, as I suspect people will be motivated to try harder.  Further, I think the weekly public spreadsheet we're keeping of everyone's progress will also better motivate people.

It's about setting the incentives properly.  Behavioral economists have long said that if you design the incentives properly, you can get people to do anything.  I even think the incentives in our contest are poorly designed.  I expect in a few weeks a small group of people will be way out in front, leaving the rest of the pack with little to no chance to catch them.  People will then see their money in as a sunk cost, and essentially drop out of the contest.  I proposed that instead of an entry fee and prize, that we go to a tax model.  For each person, if they lose 20% of their body fat, then they pay nothing.  If they lose 15%, then they pay $25, 10% pays $50, 5% pays $75 and 0% pays $100.  That way, even if you were losing late in the game, you still have an incentive to continue dieting and exercising.

Incentive design is a tremendous problem in the workplace.  I'll run through just a couple examples that are fairly well known:

Empire Building
In reviewing promotions within the management ranks, one of the first things that is reviewed is the size of a manager's organization.  HR will regularly say that org size isn't an important criteria in getting promoted, but the truth of the matter is that it is a very quick gut check on how much span of responsibility a person can handle.  Someone who is succeeding with a 200 person team can likely handle more span of responsibility than someone who is succeeding with a 20 person team.  However, as soon as this gets recognized within the ranks of an organization, you can count on the following behaviors:

• Turf wars as people compete to keep all parts of their organization, regardless if they make sense or not.
• Low performing orgs.  This isn't as obvious as managing out low performers typically results in the manager getting a backfill to upgrade.  But if you have high performers, you need fewer of them to do the same work, so perversely, you're incenting low performing orgs.
• Refusal to do anything new without additional headcount.  New projects are typically the only time when new heads are given to teams, so teams routinely cost out a new project, but say that they can't get it done within their own team.

I've seen all these and more.

Management by metrics

Many management guru's have preached the value of metrics with one liners like "Inspect what you Expect!"  I couldn't agree more with the practice as metrics focus you on the areas you really care about, and give you a yardstick by which to measure your progress.  The problem with most metrics is that they are imperfect and can be gamed.  In the early days at Yahoo, one of the most important metrics we reported to wall street was page views.  Gaming this metric is trivial because you can design a flow that has extra steps in it.  Logging into mail takes 4 clicks to get to your inbox instead of 3.  This metric improvement comes at the expense of your user, but if this is the system you set up to reward (either directly, or what wall street sets up), then you can bet the incentives are in place to drive this behavior.  This line of reasoning makes me very suspicious about the current search share war that the press is focused on with Bing and Google.  In search, doing fewer searches is usually indicative of a better product (you found what you were looking for).  Too much focus on metrics can eventually doom them.

Sales targets

Sales people are usually given a quota and given a bonus based on how well they do on a quarterly basis at achieving that quota.  Typically they have a target bonus for hitting 100% of their quota, and then a scale for missing or going over.  Sell 50% of quota, get 0% bonus.  75% of quota, get 50% bonus.  150% of quota, get 300% of bonus, etc.  Since the top and bottom of the incentives are usually capped at 50% and 150%, this can lead to incenting tom strange behavior.  If a salesperson is having a great quarter and has already hit the 150%, then they have no incentive to sell more this quarter, and instead have an incentive to delay sales to next quarter.  Or if a sales person has sold 95% of their quota, they may call their accounts to get them to move next quarter's order into this quarter to get to the 100% bonus.  Or if they're selling terribly, they may decide to take a bath on this quarter and come in below 50% and delay all pending sales to next quarter.

The key lesson to take away from here is that the incentives you set up for your employees are what they will work towards.  Even if they're trustworthy and high integrity people, there have been many many studies showing people will always shade towards their own self interest when incented to do so.  So be very careful designing your incentives.  Going back to the body fat loss challenge, the biggest concern I have is that it's on the honor system, and measuring body fat is an inexact science.  The method we're using is based on measuring your girth in several places.  I suspect that come March, those tape measures start squeezing bellies in a bit more than they did on Jan 1st.

That said, if the $100 I paid continues to motivate me as much as it has for the past two weeks, then it will have been money well spent.

Thoughts on the power of founders

In response to the Google decision on China, Fred Wilson writes about the Founder Factor and how that leads to bolder decisions.  While certainly not on the same scale as Google's decision to potentially pull out of China, I thought I'd relate that to a few of the experiences I had at Mochi Media.

On Monday of this week, Mochi announced that it was being acquired by Shanda for 80MM.  This is a fantastic outcome for the company, and I'm super excited for the team there.  I wanted to review two critical decisions that were made in the past year that led Mochi to this acquisition as opposed to alternative paths that they could have taken.  For the record, I was on the wrong side of both of these decisions but fortunately for the company the founders pushed for and got the right decisions made.

A little background, Mochi Media is a company that provides tools for flash game developers, and in particular, tools to embed ads directly into the flash game.  A game developer would write a game in flash, and then come to Mochi for a couple lines of code to insert into the game to add advertising to it.  Publishers would come to Mochi, where they were able to get tens of thousands of games for free to use as fantastic content on their game portal or other site.   There are many examples of Mochi powered games, and the format of pre-loading video ads works particularly well for advertisers.  I joined in April of 2008 to head up the engineering team there.

1. Picking the right new market
Around December '08/January '09 Mochi was thinking through how it wanted to expand its business and was considering a couple of new areas to enter into.  One possibility would be to create a new virtual currency and make it easy for our game developers to integrate with it.  Virtual currencies were quickly becoming all the rage, and companies like Zynga and Playfish were making tens or even hundreds of millions of dollars from them.  This model would be very aligned with Mochi's traditional flash tools model where we are an infrastructure provider and the developers would still be responsible for creating the content that would be critical to our success.

Several other alternatives were discussed in detail, and a few prototypes were built as well.  I won't go into too much detail on what they were, but one of the key differences was that it didn't play to our strengths as an infrastructure provider nearly as well as Coins did.  But we had started moving down that path, and were preparing to jump in with both feet when Jamseon, one of our founders, started pushing hard for us to drop the alternatives and move into Coins.  There was a lot of internal discussion, and I personally wanted to continue down some of the other options we were exploring since we hadn't seen them to their conclusion and would be making a big bet the company decision and throwing that other work away.  The key questions up for debate were:

• How much should we focus on playing to strengths we already had (building infrastructure) vs getting into areas that we'd probably need to hire new people for.  Anything from SEO to customer service that we simply didn't have expertise in.
  
• How could we protect the ecosystem of developers and publishers and advertisers we'd worked so hard to cultivate..
• Finally, there was a fundamental debate about the potential upside of coins vs our other options.

We discussed extensively internally with the entire company, and certainly over my objections, we made the choice to pull the plug on our other project and deploy all of our resources into building out Coins.


In hindsight, it was absolutely the right choice.  As soon as we started down that path, interest from potential acquirers heated up because Coins added so much more strategic value, whereas other options added none.   And our developers made many fantastic Coins enabled games.  As for the financial value, all I'll say is that I've heard it's doing quite well.

2. Picking the right acquirer
As I mentioned, after we released Coins, we had interest from a number of strategic acquirers.  We got pretty far down the road with one of them, and some of the outcome of that was covered on Techcrunch.  While the battle that Techcrunch portrays is way overblown, there was a legitimate difference of opinion, and Jameson and Bob under pressure from me to do otherwise made the courageous decision to stay independent.

That's the point where I left Mochi.  I left on good terms and keep in touch with the people there, but having been on the wrong side of two decisions that were very strategic for the company, it became clear to me that I didn't have the same vision for the company that the founders did.  And now several months later, I'm happy to see that Jameson and Bob got to a fantastic outcome, much better than the one discussed earlier.

Without the Founders there to make courageous and bold decisions, bucking the convential "wisdom," Mochi would have wound up in a much different, and in my opinion, much worse position.  So I heartily congratulate Jameson and Bob.  They stuck to their guns and made tough bold decisions as only Founders can, and Mochi is better for it.

Zod's Axioms: 10 Principles of Engineering Management

Years ago when I was just starting to figure out how to manage, Zod Nazem, the CTO of Yahoo, held an engineering management summit and at the end of it he presented his 10 management axioms. Background for those who don't know Zod, he's absolutely brilliant, tough as nails and one of the best leaders I've ever seen or worked for, but he's not the strongest public speaker. This day was the exception, people were blown away with his axioms.

That hour had a profound impact on the way I manage (and I expect much of the Yahoo engineering leadership in attendance that day). I've been meaning to write this blog post for years but instead kept spreading this philosophy byword of mouth.  Finally I've gotten them down and I want to thank Zod for looking over it to make sure I stay true to his original intent.  These are all short and pithy sayings, and all of them seem like common sense, but as I've stated, you need to go beyond knowing your principles and master them.

Without further ado, here are Zod's axioms.

1. People don't change.
2. People can learn to become better "actors"
3. Under stress people revert back to their true self

I put the first three together because I think 2 and 3 are corollaries of #1 and they all refer to the intrinsic nature of people. I had an employee who was a terribly long winded communicator.  It just wasn't possible for him to get to the point in less than 30 minutes (and he always cornered me as I was headed to my car).  I worked with him on being more concise for years, and over time when he focused on it he was able to "act" as someone who was a better communicator.  But when the pressure was on and a big decision confronted us, the old habits came out and all the work we did was out the window.  Fortunately, he was a brilliant coder and concise communication wasn't a large part of his job.  Often times, the brilliant coder who communicates poorly is pushed (or pushes) to move into a management role where communication is a critical skill.  Had I done that with this guy it would have been a disaster.  I want to draw a distinction between intrinsic characteristics and skills.  Any good programmer can learn a new programming language as that's simply a new skill.  But people come pretty hard wired on their underlying intrinsic characteristics, and many a manger has foolishly tried to change people when they need to accept that they can't.  People are intrinsically organized or not, prompt or not, lazy or not, high energy or not.  Needing someone to change on a dimension like that is a recipe for failure. 

4. Make quick decisions knowing you will make mistakes
One of the best ones on the list.  Your job as a manager is to make decisions.  You will never have complete information, and in fact part of the skill of your job is making strong decisions in the face of ambiguous information.  Time estimation, Promotions, Strategy calls, Architecture decisions.  You'll get some wrong, and fix them quickly, but the best managers make decisions quickly.

5. When it comes to compensation, don't be a communist.
Your best employee at a given level performs 5-10x better than your worst employee at a given level.  I call them 10xers.  But that best employee is still only paid 10-20% better.  Almost no company has the compensation practices to deal with that (Netflix claims they do (slide 97), and from what I've seen, they might).  So when the company 3% raise pool comes to you, don't be a communist and spread that evenly to all of your people, give almost all the money to your stars and give no raise to your bottom 30-40%.  Will that hurt their morale?  Perhaps, but it's so critical to keep your stars happy, and you really don't have enough cash to give them, so you've got to take it from somewhere.


6. Spend all your time removing roadblocks from your stars
So many new managers think they can fix their bad employees.  They spend hours with them coaching, pushing and trying to make them better.  That's a mistake.  First and foremost, I think it's the employee's responsibility to figure out how to excel in the company, the manager is supposed to define his responsibilities, give him the tools and opportunity to be successful and hold him accountable.  Further, at best you'll make  your poor performer a bottom of the barrel acceptable performer, but investing the same effort in your stars you can move them from a 5xer to a 10xer by helping remove the obstacles.  Get approvals for them, software/hardware they need, decisions made, cross org support, etc. etc.  If there's something blocking a star, that's your top priority. 


7. You are only as good as your lieutenants
You're probably a fantastic developer/architect and you can probably do the work of your team better than they can.  But you can't scale, you will always only be able to get one person's work done.  It may be 10x as productive as low performers, but you'll never get the work of 100 people done.  So you need to have lieutenants who can take the direction and skill you've got and apply it more broadly than you can.  And if you have great lieutenants, they'll push you up and take over work that you had been doing allowing you to focus on the next bigger problem.  And if they're bad, then they'll pull you down to do their job for them.  And when you're doing the job of your lieutenants, you have no capacity to take on more and scale further, so you're stuck.  Once you really start to embrace this, you'll start hiring people who are better than you, an intimidating but tremendously important step to make.

8. If you are not failing, you are not trying hard enough.
I tend to reword this to "You'll do your best work when your uncomfortable with your situation."  I'm a skier, and when I was learning to ski, I fell all the time.  That's the only way to get better, you have to push yourself into a situation that you aren't comfortable handling and do your best with it.  You'll screw up, make mistakes and hopefully learn from them.  So if in your professional life, you don't ever fail, that means you're being too conservative and not putting yourself into the uncomfortable situation.



9. If you are behind the competition, change the game.
Back in 1998 Goto.com was an also-ran search engine that was way behind Yahoo, AOL, Altavista etc. (pre Google).  They were overrun with spam and generally a pretty poor service.  They changed their model from trying to have the best search results to ranking results based on how much each bidder paid.  This was the creation of the paid search market which Google now earns billions from each year.  Goto morphed into Overture and got bought by Yahoo.  But instead of trying to beat the established players at algorithmic search, they decided to play a different game that they could position themselves to win in and then everyone was playing catch up to their game.


10. Don't pass your garbage to your neighbor.
If you have a low performer on your team, you are not allowed to transfer them to another team.  You must fix your own problems, either by performance managing them until they perform better, or by working them out.  It's so easy to just let a poor performer transfer, and big companies do this all the time, but it's death.  Before 2006, a poor performing teacher in San Francisco could jump to the top of the line above qualified candidates to transfer into a different schools.  So Principal's were left shuffling the "lemon" teachers around until the law was passed.  And we wonder why so few people want to send their kids to San Francisco schools...

And that's it.  10 pithy rules to manage by.  I've added a few others to my list (another post) but this is a pretty good basic starting point on how I try to operate.

Blackjack and engineering management

My 15 minutes of fame are up.  I was on the MIT blackjack team, and they made a book and a movie about us.  So many people I talk to are absolutely fascinated by the blackjack stories and they all want to know how we're so smart that we can remember every card in a 6 deck shoe.

We can't.  Well, at least I can't.

Counting cards is really simple.  So simple that I can explain it to you in 5 minutes (see bottom of post if you want to know how).  The math isn't harder than division of fractions.  Once some people realize this, they set off determined to go to the casino and win lots of money.  And that's foolish.  Because even though they know how to count cards, to do it successfully, it has to be so ingrained it's second nature.  I always compare it to driving.  Driving a car is a really complex action, and most of us do it so often, that we don't even think about it.  We can hold a conversation, play with our ipods, send text messages (don't do that) all while performing a really complicated task.

Jeff Ma, Me and Jim Sturgess

Counting cards has to be at that level.  We would practice so much that I never had to think about what to do, it was 2nd nature.  Basic strategy was automatic and non-thinking.  I'd hit or stand without even realizing I'd done it.   I'd talk to the dealers about the big fight the next day while calculating ((17 / 3.33) - 1) * 800 = 3300.  And that was critical because the distractions that happen in the pressure of a real casino require counting to be a background task.  I'm 100% focused on the pit person I'm talking to and convincing them that I'm a half drunk partying rich guy, and making sure they're not calling upstairs or saying anything about me.  Oh yeah, and I've also got to count and play blackjack. 

I find management to be the same as counting cards.  My management principles are so simple as to seem like common sense.  I can certainly explain them to you in 5 minutes (a future post), and many newly minted managers think it's all so obvious that they know exactly what to do.  It's why I find all those management classes companies offer so terrible.  They tend to focus on a lesson like "Make sure your employees know what they're expected to do."  Duh.  Do we really need to take a class on that?

What we really need is the practice that makes it 2nd nature.  It's hard enough to get a project on track and team members motivated and delivering that you need 100% of your energy focused there.  So the performance management, career planning, making sure you've got the right people in place, making sure people know what's expected of them, etc.  That's all got to be subconscious.  And until we're there, we need to make time every day to review the list and make sure we're on top of all of them.

It's the difference between having learned something and having mastered it.

P.S. So how do you count cards? When the shoe starts, start a running count in your head at zero. Every time you see a 2-6 (low card) add 1 to your count. Every time you see a 10-A (high card) subtract 1 from your count. Ignore 7-9.

At the end of the round, you need to figure out what to bet. First calculate the "True" by normalizing the count by the number of decks remaining. Divide your running count by your estimate of how many decks you have left to play.

Then bet True - 1 units.

For example. After playing through 1 deck of a 6 deck shoe, lets say your running count is 15. That means you've seen 15 more low cards than high ones. You divide by the 5 remaining decks and get a True count of 3. That means for each deck reamining, you expect to see 3 extra high cards. Then subtract 1 (since the casino has an advantage off the top). Bet 2 units. If your unit is $100, bet $200.

This is a decent more detailed explanation.

How to reduce testing time and still improve quality

This is the conversation I've had the most frequently since joining Microsoft a few months ago.  The sides of the debate are framed like this:

People who have had experience in the world of online services will say that release time frames need to be short to remain competitive.  They'll cite agile methods with lightweight planning, and generally very light test plans.  People who have come from the packaged software (windows/office) side say that you end up cutting the corner on quality and by having longer releases can get more work at higher quality done.

Today I'll focus on the quality angle.  I argue that rapidly released software can be higher quality with a lower QA cost.  You can have your cake and eat it too.  To think through this, we need a measure of software quality.  That's an elusive problem, but for my purposes, we don't actually need to be perfect.  I propose:

• Software Bugginess = Sum of cost of all bugs (that seems obvious)
  
• Cost of a bug = Severity of bug * number of user sessions encountering it.
  
• Severity is loosely defined as the amount of pain a bug causes to a user (and the part that is hard to quantify).
  

Now in the packaged software world, once the software is burned onto DVDs or pre-loaded on new computers for purchase, it's effectively frozen.  Oh yes, there are patches that get released, but those come with a fairly intrusive cost to users and are never 100% applied to all your customers.  So as a software development manager, to reduce the bugginess of your software you have to focus on getting rid of all high severity bugs.
 

Now I have no science to back this up, but I'm pretty sure most QA processes lead to a graph similar to the one at left.  Most of the bugs are ferreted out in the early phase of testing, but to getting rid of all high severity bugs becomes a decreasing return on investment.  So packaged software development managers must insist on a long test cycle to ensure high quality in their software.

Online services, however, have the beautiful property that you can update the software for all of your users by simply updating the server.  While that isn't always a trivial process, it is completely in the software development manager's control.  So now, instead of focusing on getting rid of every last high severity bug, we can focus on the other side of that equation; reducing the number of user sessions experiencing it.  That is a huge win because we can just do the first part of the QA curve where we find most of the bugs without paying the long price to get near 100% of the bugs out.  Further, there are lots of techniques for reducing the number of user sessions experiencing a bug, from rolling out the release slowly to a subset of servers, to doing daily bugfix releases to fix the bug you created yesterday.

But here's where most people screw it up.  People hear about agile and moving fast, and decide that they too must move fast to be competitive.  And they get excited about lowering their quality bar since it's easy to fix the bugs the next day.  And they hire only developers since all small companies should require developers to be testers (a subject of a future post).  And the developers rush out code they've barely tested at 7pm on Friday.  Then they go home, and are startled to get the SMS at 4am that their new code has broken.  So they resolve to fix it, and test it more carefully, and getting the fix and the test out takes until next Wednesday.
I see lots of places where they lower the quality bar, but don't take the next step of fixing problems quickly and generally release crap.  And thus was born the idea that agile development processes tend to be low quality.

But it doesn't have to be this way.  To release often and have a lower QA bar to release you must do several things:

1. Have a simple and automated release process.  You plan to release often, but if it's cumbersome or manual, you will fail at this and spend too many resources doing releases.
   
2. Have a simple and automated rollback process.  You're making a decision to roll out software that hasn't been rigorously tested.  You're definitely going to make mistakes and you'll need to fix them quickly.  Making sure that rollback works should be a part of your release to the staging environment before you release to production.
3. Have a segment of your production site that you can release new software too without having to release to everyone.
4. Have a source control environment that 100% replicates your production code, and is separate from your bleeding edge development environment.
   
5. Plan to release regularly, and insist on fixing bugs the same day or next day they're discovered.
6. Measure the number of days in production you've had for your various severities of bugs.  If you don't measure it, you will never fix it.
   

It's a culture and a mentality to do these things, but they're basics and really 101 level fundamentals on running a fast moving development organization.  But doing them, and focusing on the number of days in production for severe bugs, you can actually achieve higher quality systems than packaged software that has undergone a 6 month testing cycle.

We don't need another blog!

Rational Self: Really?  You're going to start a blog?  Aren't you 5+ years behind that trend?
Me: So what?  I've got important things to say.
Rational Self: Important?  Things that nobody else has already said 100 times before?
Me: Well, the other people saying them weren't me.

Yeah, I get it, the last thing the world needs is another technology blogger.  And Lord knows I don't really have the time to keep this up to date.  But I've got some ideas I want to get down on paper.  Ideas I find myself regularly regurgitating to people, and I think it'd be simpler to point them to a good write up of it.  And since "Writing is Thinking" it'll allow me to better coordinate my thoughts.