There was a study by Viswanath Venkatesh and Michael G. Morris “Why Don’t Men Ever Stop to Ask for Directions? Gender, Social Influence, and Their Role in Technology Acceptance and Usage Behavior” that looked at 342 workers over five months to observer usage and adoption of technology. The researchers’ results were that men considered perceived usefulness to a greater extent than women in making decisions about the use of new technology. On the other hand, perceived ease of use was more important to women compared to men even after initial training. What’s perhaps even more interesting was that men’s view of ease of use was that it went up after using the system while women’s view remained unchanged. Additionally subject norms were considered much more by women than men. What this suggests is that women are much more balanced in their technology decisions with regards to perceived usefulness, ease of use, and subject norms.

Another study by Fiona Lee “When the Going Gets Tough, Do the Tough Ask for Help? Help Seeking and Power Motivation in Organizations” revealed that individuals do not seek help, even when it is needed and available, because doing so implies incompetence, dependence, and powerlessness.  There is even a whimsical study from insurer Sheilas’ Wheels that claims that the average male drives around lost 276 miles each year costing over $3,000 in fuel.

Our experience with hundreds of clients has been that technologist in general hate to ask for help but would much rather struggle in an attempt to solve the problem themselves. Unfortunately they do so even at the risk of being very inefficient and wasting organizational resources. Whether the reason is genetic or fear of being seen as incompetent the problem is costly to organizations.

Asking for help or advice from someone who has been down the road you’re traveling in my opinion is not only the fastest way to get there but also shows great courage and confidence. You have to be completely comfortable with what you know in order to admit in front of peers or bosses what you don’t know. Some of this confidence comes from experience but some of it also comes from the culture of the organization. If you’ve built or inherited an organizational culture where everyone pretends to know everything and is afraid to ask for help, you’re guaranteed to be very inefficient. If you find yourself faced with this situation be the leader and step forward to show people how to ask for help. Start by calling this issue out at your next all hands meeting or staff meeting. Then show people it’s more important to be unbelievably curious and passionate about your craft than to appear like you know everything.

If you are a technology organization within a Software as a Service (SaaS) company, there is no such thing as an “internal customer”.  We often see this anachronistic IT phrase thrown around in web X.0 companies by executives and engineers who simply have not adopted the new SaaS mindset.  Do you think you’ll hear the left offensive tackle of an NFL team refer to the quarterback as his “internal customer”?  The quarterback consumes services (energy to block opponents) of the left tackle – so why wouldn’t he be a customer?  The answer is simple – because the notion of a customer relationship is different than the notion of a relationship within teammates.

The first reason why your teammate isn’t your customer is because he or she is, well, your TEAMMATE.  Customers are someone for whom you produce a service or product and teammates are someone with whom you work to accomplish a goal.  The difference between working FOR someone and working WITH someone is HUGE.  This difference creates a contextually activated identity that forces you to think about customers in a different light than you would a teammate.  Very often, as we’ve written before, this can result in affective (role based or bad) conflict between teams.  Affective conflict is bad and it destroys shareholder value.  Working as a team is important and customers aren’t part of your team.

The next reason that your teammate isn’t your customer is that the customer is always right.  Your teammate isn’t always right.  You need to debate certain points as a team to come to better solutions.  This isn’t affective conflict, it is cognitive conflict and if handled properly it is good and helps to create shareholder value.

The most important reason there isn’t a customer relationship here is that your teammate isn’t paying!   “Servicing” your teammate (uggh…that’s an ugly term) doesn’t create shareholder value.  Working as  a team to delivery a service or product to your  “real” customer is what creates shareholder value.  One design, one approach, one ruthless drive as a team to get across the goal line is what is necessary to thrive and succeed.

So stop using the ugly “internal” C word in your SaaS company.  It doesn’t have a place there.  Let the old world, internal IT folks continue to provide services to their internal customers.  Start acting like a team, designing and building services rather than software.

Most of the time the individuals that we interact with during engagements are intelligent, intellectually curious, and open to suggestions for improving their service offering’s scalability and availability.  On rare occasions, however, we run into an individual who either argues just for the sake of arguing or thinks he/she can’t learn anything from anyone. While these people might be brilliant they are likely going to ultimately fail and in doing so negatively impact the company. A rule to live by is that an architecture designed by one person is much poorer than one designed by a diverse group of individuals with different skill sets. This is one of the driving principles behind the JAD and ARB.

This is not to say that all conflict is bad. As Marty mentioned in his post on Team Conflict, cognitive conflict is desired. It is the affective conflict that is not good for the team. An easy way to think about the difference between cognitive (good) and affective (bad) is that arguing over “what” to do is good, arguing over “who” should do it (territorial) or “how” it should be done (micromanagement) can be harmful if not carefully kept in check. Once an someone has been assigned as the “R” (see Chapter 2 in The Art of Scalability) let them own the project.

We’ve posted a lot on our blog about hiring A players, tending your team like a garden, and building high performance teams. Allowing someone who displays an attitude of arrogance and superiority in a leadership position is more than just annoying but harmful to the team. Junior engineers will not push back on this person’s decisions for fear of humiliation, younger leaders are being taught to act this way in order to succeed, and the experiential chasm between this person and other executives is only widening.  No matter how brilliant this person is, they are causing more problems than they are solving. Take steps today to remove them from the organization as quickly as possible.

13 Bankers, by Johnson and Kwak, is an interesting but at times text-bookish read on the history, successes and failures of banks in the US from the time of the founding fathers to the recent mortgage induced meltdown.  The book makes a compelling point that effective bank regulation cannot happen while former bankers are so tightly tied to American politics (witness Paulson, Geithner and several other former bankers as recent Secretaries of the Treasury).  Given the size and influence of the remaining 6 large banks, the authors argue that the banks have effectively created an oligarchy.  The authors defend their position through recent events; even after one of the worst financial meltdowns of all time we have yet to reign in the level of risk taking of these modern goliaths.  Banker compensation is at a near all time high, high risk financial products continue to be developed with little or no oversight and the taxpayer has funded all of this with below market loans in the form of TARP.  In every other meltdown in US banking history, we have swung to tightly regulate and control the banks while in this one we simply loaned them money and went back to business as usual.  The authors implicitly argue that Jefferson’s (who was against a central bank for fear of it having too great an influence over government) worst fears have been realized.

The book is informative, and it got me to think about governance overall – especially over technology functions within companies.  Just as the existing board structures in coordination with the government seem to be ill equipped to properly govern and regulate modern banks, so too are too many product companies ill equipped to govern their technology efforts.   CEOs often do not have a deep technical background and while we’ve written that they do not necessarily need to be technical, we’ve also stated that they should ensure that they have the appropriate internal technical talent and outside technical governance.  I’m not talking about the tired old topic of internal IT governance here, though that is still important.   This is about ensuring that the governance of the company is correct and representative of shareholder interests.

Looking at the boards of most companies private and public companies, you will not find many successful technologists as directors.  These boards are likely to have former CEOs, CFOs and CMOs but precious few of them will have former CTOs and CIOs.  Given the level of spend within technology companies, what could be more important than ensuring that spending and focus is appropriate to the needs and the direction of the company?  Given that the product is what creates shareholder wealth, what could be more important than having someone with relevant technical product experience on the board of directors?

A lack of understanding of the risk of certain financial products (especially in the case of debt derivatives like CDOs) on the part of boards of directors and regulators is at least partially to blame for the most recent financial failures.   If former bankers sitting on these boards of directors can’t understand the firm’s financial products, how can a board devoid of technologists have a chance of understanding the ins and outs of developing the company’s products?

While clearly not of the magnitude of our current bank governance problem, it is at least a problem that should be solved as technology continues to play a larger role in each of our lives, our companies and our futures.

Somewhere in the mix of my father, the United States Military Academy and the Army I learned two important self tests for leadership: the “Man in the Mirror” test and the “Would I” test.  While I am human and have failed these tests and their exacting standards from time to time, I think they have on balance served me well.

The Man in the Mirror test is:  Can you look yourself in the eye (in the mirror) after you’ve made this decision?  The question is profound and very powerful.  It alone, if asked at the appropriate time, might keep you from making otherwise foolish ethical choices and poor leadership decisions.  Would it have kept Lay and Skilling, Maddoff or Kozlowski  from  violating their fiduciary responsibilities?  While I can’t answer this question, I do believe that if a person is “on balance good” and hasn’t succumbed to greed induced sociopathic behaviors, then this test will help keep them straight if asked at the appropriate times.  As we’ve written before, building tests such as these into your daily routine can help you from taking the long journey of small steps towards unethical behavior.

The “Would I” test is much more focused on the concept of “Leadership by Example” that we discuss in The Art of Scalability.  This test is also simple.  You just ask yourself “Would I be willing to do what I am asking this person to do?”  Maybe you are asking someone to work during their anniversary.  Perhaps you are asking someone to skip a child’s sporting or school event.  Maybe you’ve just given them some last minute assignment that will cause them to work all night, like completing a presentation for you to give at a conference tomorrow.  “Would I” is not an excuse to be lenient on people, or not to hold people to aggressive standards.  Rather, it is a test to determine if you are truly meeting the expectations that you hold of those around you.

In one respect, the “Man in the Mirror” and “Would I” tests fly in the face of concepts such as Strengths Based Leadership.   They exist to keep us from failing due to shortsightedness, a lack of introspection and aggressive or excessive egoism.  They are rooted in the concept that we sometimes fail because we fail to see how our actions will be perceived or acted upon by others.  Leaders are humans, and leaders make mistakes.  The “Man in the Mirror”, if employed often, helps us to avoid dangerous ethical pitfalls and the “Would I” test helps us avoid burning out our teams.

Since writing our view on outsourcing, we’ve received a number of questions.  While most people indicate that the article was useful, the most common question is “Why can’t I just outsource everything?”  Here’s your answer:

You absolutely CAN outsource (or even purchase) everything.  The consideration of whether or not to outsource, as we’ve indicated earlier, is roughly the same as whether or not you should buy something.  The two differences are cost and the ease with which someone else can do the same thing you do.  “Buying” something (I mean off the shelf, packaged software, software as a service, etc) means that it’s available to just about everyone today – potentially with some small modifications to fit their business needs.  As such it usually costs less than outsourcing but is also more easily accessible and implementable by your potential competition.  “Outsourcing” something means that you are going to have someone else implement (code) your idea or run your servers (in a hosted rather than a SaaS model), which usually implies higher cost and a bit more difficulty in transferring technology.

In either scenario, you must be willing to say that you are willing to be like “everyone else”.  In other words, you are willing to give up the competitive differentiation that a homegrown solution might offer such as creating a higher barrier to entry, lower barriers to exit, switching costs, etc.  If an outsourcer can develop your code they will take that experience and apply it to someone else.  They may not use the actual code they write for you, but they simply can’t help but use the past experience.  This means that the job to copy you just got a little easier, which in turn means that you lowered the barrier to entry for competition.  And of course if you purchase a solution, then you are also making a decision that you will not differentiate yourself in that particular area.

None of this is bad.  In fact, there are many cases where you SHOULD outsource or purchase software or services.  Most companies and organizations tend towards isomorphism, which means that over time they all look (or should look) to leverage the best known practices to increase efficiencies and reduce costs.  It’s hard to imagine that you are going to differentiate yourself in your accounting systems, customer support systems, sales lead systems, etc.  You might add a unique set of routing rules, etc – but these systems are so standard that the best practices are built in to most pieces of software.

From a product perspective, if your business objective is to be a “low price leader” rather than to compete on technology or to simply “run with the pack” and use standard features while maintaining good margins then it also makes sense to buy or outsource.

But what if you want to have the world’s best product, stock, or media recommendation engine?  By definition you can’t “buy” that as everyone else would have the same thing.  If you outsource it, everyone else might not have your code but the firm that develops it for you can’t help but add it to their experience; they might not copy it but it certainly will influence their future activities.

As we’ve described before – don’t outsource or buy those things that you feel should or will differentiate your business.

I’m a cancer survivor.  Not the kind of biological cancer that took my mother and some of my friends, but the evil and malicious cancer that mutates and destroys the people and performance within an organization.  I’ve learned through my personal battles with “org-cancer” that you have to act quickly and decisively to excise these “org-tumors” the minute they are detected.  Early detection and treatment are the only way to keep these beasts from destroying your organization, your product and your company.  Here are the four most common types we find in our practice:

The Information Hoarder – This nasty cancerous employee believes that information is power; the more he has relative to everyone else, the more powerful he is.  These cancers don’t like to share information unless it makes them look good. Information that makes them look bad gets secreted away, allowing problems to fester and destroy your product or customer relations.  This employee will provide or expose information only when it meets his or her own needs.  This is an engineer who might not want to share knowledge about a codebase, an executive who only shares metrics that show stellar results and hides those that show problems, or a sales person who refuses to share how he or she has been so successful.  Solution:  Remove this cancer before it grows.  Do not promote this individual and do not allow others in the organization to believe this behavior is acceptable.  As a CEO, this cancer is very dangerous for a board of directors.

The Bragging Hero – As Fish has written before, you should be creating a culture that embraces those who keep problems from becoming crises.  That said, nearly every business has a crisis from time to time and typically there are a number of heroes who help solve them.  You want the type of hero who corrects a situation and moves on without fanfare.  Be wary of the hero who repeatedly trumpets his or her accomplishments.  Often this person can be seen hanging around the Information Hoarders and sometimes they are the same person; an information hoarder who brags about his or her heroic accomplishments.  Solution:  Sometimes this cancer can be “treated”.  Explain the need to reduce self publicity and if you are unsuccessful, excise.

The Gossiper – With all the talk about how much time a company should spend on new products vs maintaining old products, who has the time to invest in morale destroying gossip?   Time spent gossiping by definition steals away from both new product or maintenance time.  This cancer often greets people with “Did you hear about John’s affair?” or “Have you heard about Jeanette’s new boyfriend?”  Let’s be honest – most of us indulge in this behavior from time to time – but I’ve seen people spend an hour plus a day discussing the latest gossip.  You can spot this person because they think they know something about everyone and they aren’t afraid to share it.  Baseless, third hand rumors can destroy the lives of good employees.   This type of cancer shows up in more extroverted professions like project management.  Solution:  You can try to treat this cancer by explaining the effects of their actions on the lives of others.  Most likely you will be unsuccessful and you will need to excise the mass.

The Passive Aggressive Seditionist – This is the cancer upon which the phrase “grin-f&#$er” was based.  This person will say “yes” and make you believe he or she is on your side and “fighting the good fight” all while spreading rumors about you and maybe even making up some stories of his or her own.  They are often seen in the company of Gossipers and sometimes will be the rare but extremely deadly combination of Passive Aggressive Gossiping Seditionist.  Whether of the merged mutant variety or the base type, there is no treating this cancer.  It must be irradiated, chemo’d and excised with extreme urgency.

Make no mistake about it, you have no obligation to continue to employ these mutated employees.  Very often these employees get a lot done, but as we’ve explained in the past it is critically important to evaluate both behaviors AND performance when building a culture of excellence.  “Treating” (counseling) or removing them is the right thing to do, and you can never act too quickly.

In business we all have good days and bad days, victories and defeats. We’ve written about the manic/depressive nature of CEO’s of startups and I hear probably once a month from someone with the exact same experience. How gracious we are during the good times is important. Being humble and showing respect for all the team member’s contributions is important. Even more important than how we behave during victories is how we react during the bad times, after being defeated.

The Battle of Shiloh fought April 6–7, 1862, in southwestern Tennessee, was by the bloodiest battle in US history up to that time.  Below is a summary of the battle’s first day from HistoryNet:

On the western bank of the river, at Pittsburg Landing, an angry, confused and terrified mob of Union skulkers sought shelter alongside the bluffs that overlooked the river. That morning, many of these same troops had been routed from their campgrounds near the primitive Methodist meeting house called Shiloh, 2 1/2 miles southwest of the landing, by onrushing Confederate troops led by General Albert Sidney Johnston’s onrushing Confederate troops, who were seeking to drive the Union invaders from their stronghold in southwestern Tennessee.

The ensuing battle, the bloodiest single day of fighting yet experienced on the North American continent, had settled by nightfall into an exhausted stalemate, with troops on both sides hunkering down for the night in the vine-choked gullies and brambles that gutted the battlefield. By then, Johnston himself was dead, having bled to death from a bullet wound to the knee, and the badly rattled Confederate high command was unsure what to do next. Some argued for an immediate retreat before the enemy could be reinforced; others wanted to renew the battle at dawn.

The Union Commander, Major General Ulysses S. Grant tried to catch a few hours’ sleep in the shelter of an oak tree but was unable to because of the rain and an injured ankle. He relocated to a log cabin on the bluff above the river but surgeons had taken over the cabin and the screams of the wounded were too much. “The sight was more unendurable than encountering the enemy’s fire,” Grant recalled in his memoirs, “and I returned to my tree in the rain.” It was there that his second-in-command, Major General William Tecumseh Sherman, found him chewing on a cigar. “Well, Grant,” said Sherman, “we’ve had the devil’s own day, haven’t we?”

How did Grant reply? Did he blame his lieutenants for not leading properly or question the bravery of his soldiers? How would you have reacted? It’s tempting when suffering from a major defeat to give into your own sorrow and think about yourself. No doubt as business leaders we still have families and obligations outside of the business that we have to think about. These pull on us to not remain stoic for our troops, not to be the inspiration most needed at this time.

To Sherman’s “we’ve had the devil’s own day, haven’t we?”, “Yes,” Grant replied “lick ‘em tomorrow, though.”

I was on a flight the other day. Which airline doesn’t matter because this story applies to any of them. The flight was scheduled to depart at 1:30pm. The aircraft was an Embraer ERJ-145 which only holds about 50 passengers. At the request of the flight attendant we hurriedly boarded and shut down our electronic devices so at 1:29pm the door was shut and the jetway was pulled back from the plane. Thus chalking up another “on time departure” for this airline’s metrics. We then sat there for 20 minutes while the pilots recalculated their weight and balance. At one point they reattached the jetway in order to deplane an airline employee who was jump seating. After a few more calculations, they reconsidered and allowed him to re-board. Just as a side note, if we’re voting and the choice is between an extra 200lbs of fuel and allowing an airline employee to jump seat, my vote is on the fuel. After modest delay of about 25 minutes we were on our way.

The thing that irked me was that while they technically might have “departed” on time, from a customer’s perspective they didn’t come anywhere close to that. Teams fall prey to this all the time. The first thing an operations team puts in place is something like Nagios to monitor the CPU, memory, and disk of all the servers. As we discuss in our post Monitoring Strategies, the first measurement to put in place should be something to measure from the customer’s perspective and answer the question “Is there a problem?” The most important thing to know is are my customers being impacted and how. The answer to that will determine who gets paged, how you should react, etc. After answering that then you need to figure out “Where is the problem?”, “What is the problem?”, and “Why is there a problem?”.

Failure to heed this and you’re at risk of falling into the airline metrics trap. You’ll be satisfied that you’ve kept all the servers up and running 99.99% of the time but your customers may have only been able to access the site 95% of the time because of software, networking, database contention, etc. The result is unhappy customers despite you meeting all your stated performance metrics.

It’s annual review season again and lots of you managers are probably swamped trying to write pages of feedback, both positive and negative, for your employees. My advice for the coming year is to stop doing annual reviews. Workers today, millennials especially, don’t want to wait for a review or feedback once per year. This cycle was fine back when employees worked for a company for 30 years and could take twelve months to work on last year’s deficiencies. Today’s world is one of instant updates (Twitter, Facebook, etc) and a career comprised of stops at many different employers.

A BLS news release published in June 2008 looked at the number of jobs that people between the ages of 18 and 42 held. On average, men held 10.7 jobs and women held 10.3 jobs. Both men and women held more jobs on average in their late teens and early twenties than they held in their mid thirties. Holding 11 jobs over 24 years averages to holding each job slightly over 2 years each. If you wait for an annual review to provide feedback the employee is likely half done with their tenure at the company.

We argued in a recent post Lower your standards and build a better team that the standards for hiring should be lowered. The reason is that we are unable to predict future success based on past performance in a different environment (different employer, different culture, etc) and academic prowess isn’t likely to be a good indicator of job performance. A couple hour interview doesn’t net a better result. Said more simply, we should hire more people but make the cuts way faster. This is especially true when employees, great or poor performers, are likely to leave in 2 years.

Give feedback and rewards quickly. Why should salary increases occur only once per year? When someone performs well or takes on additional responsibility, give them positive feedback and reward them. Today’s employment environment calls for fast hires, fast feedback, and fast cuts.