Showing posts with label business model. Show all posts
Showing posts with label business model. Show all posts

Wednesday, February 29, 2012

My two cents on failure

Dan North once said: "Fear leads to risk, risk leads to process, process leads to hate...and suffering and Gantt charts." I've worked for many companies (banks, financial institutions, and government) and most of them do not have the type of tolerance for failure. As a matter of fact, they encourage a "blame game" culture - people point the finger at the person who makes the failure. In these companies I was told that if you are the person that is given more bad news than good news to the boss, then you will be labeled as incompetent. The first thing out of my boss mouth when he noticed a problem/failure was, "Who did it? Who's responsible for that? Who's fault is it?" In these companies, if there was something wrong, people would fix it and didn't tell anyone. This created a nightmare when there were bugs on the system because no one would admit to the problem or how it happened. For the last five years, my career took a different turn. I joined a startup and eventually I end up in management, and I found a different paradigm, "failure is part of the business."

According to Harvarv Business Review, there are different type of failures:
  • Preventable: this is when it could have been prevented. For example, testing in production, deploying code before testing it, logged in as root and doing an "rm -rf /".
  • Complexity related: a large number of organizational failure are due to the inherent uncertainty of work: A particular combinations of needs, people, and problems may have never occurred before. Although serious failures can be averted
  • Intelligent: failure when experimentation is necessary. An example will be like "spike" in Agile.

Intelligent failures are normal in startups because you are trying something that hasn't been tried before. The company IDEO has the slogan:
Fail often in order to succeed sooner
This is something that not so many companies have. Entrepreneurs embrace failure and uncertainty. In startups, there is just too much uncertainty and as Steve Blank puts it,
In a startup no business plan ever survives first contact with customers.
So what happens if the original business plan fails? An entrepreneur adapts! He/she learns what went wrong, makes adjustments, and then monitors the new business plan. This means that failure is a natural part of doing business.

I am sure that all these previous businesses are aware of this issue. Obviously, they want to learn from their mistakes and avoid them in the future. But more often than not, bosses get irritated when a person presents them a problem. This is the difference between startups and stablished companies. As per HBR, companies can learn through three different activities:
  1. Detection: the should be to surface failure early.
  2. Analysis: find out what is the root-cause of the problem, or in agile terms: root-cause analysis (RCA).
  3. Experimentation: try to generate intelligent failure for the express purpose of learning and innovation.
It is rare for a business to be an overnight success. There are just a few FaceBook and YouTubes out there. It is going to be hard, and for many failure is the beginning of the journey. As per North, "uncertainty isn't just about expecting change, it's assuming that some unexpected bad thing will happen during the project and we can't even know about them when we start."

Friday, February 17, 2012

Implementing the "No Asshole Rule" at work

I'm usually the person that does the interviews when we have a programming position. There are three criteria that I look for when I interview potential candidates:
  1. Technically savvy - can the candidate do the job? Does he/she has a good foundation on computer science (data structures, algorithms, etc)
  2. Quick learner or persistent when it comes to finding a solution.
  3. Is he/she an asshole
As I mentioned before, my interviews are very technical. For the first criteria, I start with a phone interview and present problems that deal with algorithms and basic fundamentals of computer science. If the candidate does well, then I schedule a personal interview and give them a small project to bring to the company. In person, we do a code review of the project along with the team and then along with the candidate. This is simply a "creative criticism" and a way to find out more about the programming skills of the candidate.

The second criteria is hard to gauge. I usually try to give some questions and if I see them struggle, then I see how they handle it. I also ask questions like "what is the latest thing (programming language, framework, tool) that you learned?", "what do you do when you get stuck on a problem?", etc.

The third criteria is extremely important to the team and the hardest to catch. Everyone has worked for or with an asshole. Just so we are clear, I really liked the definition from Robert Sutton's "The No Asshole Rule":
THE DIRTY DOZEN
Common Everyday Actions That Assholes Use
1. Personal insults
2. Invading one’s 'personal territory'
3. Uninvited physical contact
4. Threats and intimidation, both verbal and nonverbal
5. 'Sarcastic jokes' and 'teasing' used as insult delivery
systems
6. Withering e-mail flames
7. Status slaps intended to humiliate their victims
8. Public shaming or 'status degradation' rituals
9. Rude interruptions
10. Two-faced attacks
11. Dirty looks
12. Treating people as if they are invisible
I usually call the candidate's references and asks some "what if" scenarios. Despite all of this, it is hard to identify an asshole.

It is very hard to build a cohesive team, but when you have one...it's amazing. The team works like well-greased machine. Introducing an asshole is almost like throwing a monkey wrench to the machine. As Jim Collin's mentioned in his famous book "Good To Great:"
If you have the wrong people, it doesn’t matter whether you discover the right
direction—you still won’t have a great company. Great vision without great people is
irrelevant
Managers, if you have an asshole, you need to handle them right away! You need to let them know that this type of behavior is simply unacceptable and if it continue, they will be terminated. It is simply not fair for the team or to the company. Simply put, assholes will bring down production and cohesiveness to the team. Worse, you can potentially loose some great resources.

Questions:
How do you find people that are quick learners?
How do you handle or filter assholes?

Tuesday, February 14, 2012

IT and productivity - what does that mean?

Today I was reading Wall Street & Technology and I stumbled into an interesting article by Howard Rubin, "How to Assess IT Productivity". It looked very interesting, but when I finished reading it, I had more questions than answers. The author makes a good point
Defining an accurate (an universally agreed-to) measure of information technology productivity is perhaps the 'holy grail' of IT measurement.
That's absolutely correct. If you're a manager, or have been a manager, then you know that is true. He composed a list of "6 Core Assessment Areas for Measuring IT Productivity":
  1. Computer Technology Measures of Processor Economic Efficiency
  2. Supply-Side Measures of Reduce Economic Efficiency and Productivity
  3. Demand-Side Measures of Economic Efficiency And Productivity
  4. IT Portfolio Measures of "Run the Business" vs. "Change the Business"
  5. IT Budget Agility Measures of Fixed vs. Variable Costs
  6. Operational Leverage Measures
This is where I started doubting the article. The truth is that there is really not a right answer for "IT productivity." It is one of those subjective questions where you get many answers and probably all are correct. The answers will vary depending on the companies and/or its department. In other words, its all about context and domain. But, what if we go back to basics. How about the following measurements:
  • Release cycles: how often we make deployments of new features or fixes
  • How many bugs were introduced on the release/deployment
  • Turn-around time on bug fixes: how fast do we find them?
  • Performance and scalability of application: how fast is our application? How much can it handle?
  • Hight Availability measurements. For example, what is the turn-around time for an event failure (going from primary to secondary)
These might not be "productivity" per se, but they are value added to our customer, and they should be monitored. You might even considered them as quality rather than productivity. But one might argue that they go hand-by-hand. Quality has a tremendous impact on productivity. In my industry (financial trading) we always go back to the 2010 Flash Crash which plunged the Dow Jones Industrial Average to about 1000 points due to an error on a high-frequency trading.

I really like what I read in Net Objectives:
Creating software is about delivering business value. Without some measure of business value, it's hard to determine whether the software has any.
Here are some examples of business Values:
  • Increased revenue (sales, royalties, fees)
  • Decreased expenses
  • Using less resources
  • More efficient use of resources
  • Customer satisfaction
  • Product promoters / satisfiers/ detractors
  • Staying in business
  • Avoiding risk
  • Innovate!
I like what Jonathan Rasmusson said in The Agile Samurai when wondering whether you are doing things the "agile way", instead ask yourself two questions:
  • Are you delivering something of value every week?
  • Are you striving to continuously improve?
At the end of the day, IT and productivity means what you and your company thinks it means.

Wednesday, July 28, 2010

Keep your pulse on your business model

A friend told me about an anecdote of a start-up that was obviously heading in the wrong path. The company was quickly loosing money and yet the market was huge. The CEO fired the head of sales and marketing and decided to manage the department. Luckily, they had one thing in their favor, a lot of data. After some analysis and data mining, they realized that the B2C business model was no sustainable. Worse, there were signs of this about a year ago (sales plummeted). They did a small market research and talked with the customers. At the end, they found out the following based on their analysis:
  1. Accounts receivables were taking a nose dive
  2. There were several disruptive technologies and the market had changed
  3. Customers were unhappy with the current business model (the payable from our customers were lower than 70%)
  4. The B2C product had become a commodity and the only way to compete was through money (lower profits)
  5. Customers were looking into a more enterprise product

At the end, the company decided that a new product was needed. A product focused on B2B. With a small pilot they were able to "test the waters" and provide a successful use case. They are now selling the product and making sure that the same mistake doesn't happen again.

I've seem this type of behavior in current businesses. I'm a believer that when you get encountered with this type of issues, departments try to tackled it by using "brute force". I don't believe that this company's sales and marketing department were oblivious of the problem. Instead, I believe that they were just sticking to their strategy. They were too caught up with the every day details of trying to maintain their quota and get more customers. But, they didn't have the pulse on the market. In other words, no one checked if the business model was working.

A few weeks ago, I sat down with a founder of a company which I respect very much. The company was founded by three individuals. He was the COO, another founder became the head of sales, and the last one was a series entrepreneur. He explained that most of their success was mostly due to the management style of the sales manager (company started about 4 years ago and it was worth above $44 million). They called it, "One Hundred Days". Senior management would come up with a goal for the entire company that needed to be executed in the next 100 days. Then, whatever decision, customer, sales had to answered the following questions:

  • Is this according to the plan?
  • Would this get us closer to the plan?
  • Lets check the plan again.

I really like the idea. However, I would add a check and balance approach. You can easily loose focus in the every day task just like the head of marketing and sales in my friend's company. It is what Eric Ries calls "the pivot point".
Pivot is the ability to change direction in response to failure. Within every failure is a good idea waiting for the right circumstance or application. Pivot is an incremental and "zig-zagging path" towards the right market fit. The faster the pivot, the more likely a startup will find success before running out of money.
Ries contends that startups must be "built to learn", meaning validated learning about what customers want has to be the unit of measurement for company success. Turning ideas into products, and testing those ideas against reality, allows the company to pivot effectively, enabling customer-centered testing to be done by the dozen, or even, by the hundred.

A few months ago, I read a blog You're in a Museum by Steve Woodruff. He explained, the fact that there is always room for improvement and we should constantly try to seek for better solutions. He proposed to start thinking in different direction by asking the following questions:
  1. What is actually not working?
  2. What is missing and should be created?
  3. How could this be better?
  4. What new connections can be made?
  5. What do I want to leave behind as a legacy?
  6. How can ideal become real?
  7. What would I REALLY want to make happen if there were no limits?
  8. Why? And, while we're at it - why not?
In other words - question the status quo. We need to know when to change course or when our strategy is no longer working.

Wednesday, May 26, 2010

STARS - transition management

The STARS model is a great guide for a transition strategy. It's hard to know when you need to make a transition in your company, but a greater challenge is to know what type of strategy to use when making the transition. I found a very interesting article in the Harvard Business Review (January 2009) by Michael D. Watkins named "Picking the Right Transition Strategy". The article's emphasis is with the "state" of the company.
Once you understand the state of the organization or initiative you've heading up, you can more effectively apply certain fundamental principles (several of them listed here) to ease your transition and increase your odds of long-term success. Your business situation should shape how you apply those principles.
Using the author's STARS model, leaders can figure out which state the company is in and, more important, how to tailor their strategies for organizational and personal change accordingly.

The STARS model stands for the five different states of a company:
  • Start-Up
  • Turnaround
  • Accelerated Growth
  • Realignment
  • Sustaining Success

Start-UpTurnaroundAccelerated GrowthRealignmentSustaining Success
State:
Assembling the capabilities (people, financing, and technology) to get a new business or initiative off the ground
Saving a business or initiative widely acknowledge to be in serious troubleManaging a rapidly expanding businessReenergizing a previously successful organization that now faces problemsComing in on the heels of a highly regarded leader with a stellar record of accomplishment
Challenges
Building the strategy, structure, and systems from scratch without a clear framework or boundaries

Recruiting and welding together a high-performing team

Making do with limited resources
Reenergizing demoralized employees and other stakeholders

Making effective decisions under time pressure

Going deep enough with painful cuts and difficult personnel choices
Putting in place structure and systems to permit scaling

Integrating many new employees
Convincing employees that change is necessary

Carefully restructuring the top team and refocusing the organization
Living in the shadow of the former leader and managing the team he or she created

Playing good defense before embarking on too many new initiatives

Finding ways to take the business to the next level
Opportunities
You can do things right from the beginning.

People are energized by the possibilities.

There are no rigid preconceptions.
Everyone recognizes that change is necessary

Affected constituencies offer significant external support

A little success goes a long way
The potential for growth helps to motivate people

People will be inclined to stretch themselves and those who work form them
The organization has significant pockets of strength

People want to continue to see themselves as successful
A strong team may already be in place

People are motivated to continue their history of success

A foundation for continued success (such as long product pipeline) may be in place

Monday, November 9, 2009

Motivating programmers

Dan Pink had an extraordinary presentation in TED regarding the disconnect on traditional reward system. We have learned over and over about the power of incentives and how they should improved motivation. However, science has proven that for complex problem this does not work. Instead, it could dull thinking and it slows creativity. It was impressive that for the past forty years what science has proven the business has not noticed.

Contingent motivator (cause and effect) it's a good approach for 20th century tasks for simple set of rules (narrow our focus), but for most jobs/problems (specially programmers/software engineers) extrinsic motivators are better because we need to see the entire context (work with our left and right brain). He explained it extremely well using the "candle problem".

I can watch this presentation over and over, and always find something useful. Highly recommend it.

Thursday, September 24, 2009

Metaphors, valuable assets in conversations.

The company is in negotiations on selling one of my source code to one of our competitors. I was asked by the CEO to talk to the CFO regarding the risks and to come up with a price. The conversation was going nowhere. The CFO was totally lost regarding the source code. It was obvious that he did not understand the context of the conversation. Finally, I told him to think as the source code as a recipe. "Think of us as Coca-Cola (the company) and we have the recipe, the "secret formula", and now some other competitor like Pepsi wants to purchase it."

After that, we were both engaged on the conversations. The CFO was asking questions such as:
  • if we give them the recipe, they (competitors) can make as many cokes as they please.
  • how long did it take your team to create the recipe (in terms of hours, and most of all money).
All these questions contributed to a really good conversation. Afterwards, the CFO and I talked to the CEO and discussed our assessment.

In the book, Pragmatic Thinking and Learning, Andy Hunt explains methaphors and software as the following:
The idea is that any software system should be able to be guided by an appropriate metaphor

I couldn't agree more with him.

Sunday, August 2, 2009

Twitter Business Model?

I have been reading a couple of articles about Twitter, simple because I believe that it is a disruptive technology to the SMS.

Two articles that really got my attention:
Both articles where really impressive and very insightful, but by the end of the day I came up with one question, how in the world are they paying for all those BILLION messages? How come companies such as Facebook or Twitter who have over 400 - 500 million users aren't profitable? Everyone is saying that they are waiting for an IPO, but I'm not sure if that's going to happen any time soon. I mean, I doubt that anyone will be OK by getting an ad on their phone.

Time's provided a great example on how Twitter is changing the way we established conversations:
Injecting Twitter into that conversation fundamentally changed the rules of engagement. It added a second layer of discussion and brought a wider audience into what would have been a private exchange. And it gave the event an afterlife on the Web. Yes, it was built entirely out of 140-character messages, but the sum total of those tweets added up to something truly substantive, like a suspension bridge made of pebbles.

Understood, but wait...someone is paying for all these standard rate messages. You see, I'm in the business of monetizing from these type of messages. I provide what people called Premium Short Messages (PSMS). Indeed, the market that controls all that downloadable content such as ringtones, wallpaper, subscriptions, etc has paid my bill. I don't hate Twitter, is a matter of fact I think is the future, just like I think the "Free" business model that Chris Anderson talked in his book is the 21st century model. However, it seems crazy to me to have such a financial hemorrhaging (the cost of short-codes, and standard rate messages is quiet high).

The Economist's article caught my attention on the amount of money that the founders have gained,
... a hacker recently leaked documents after gaining access to the private e-mail accounts of a Twitter employee and the wife of one of its founders, the blogosphere was abuzz. The haul included a spreadsheet showing revenues reaching $140m by the end of 2010, up from $4.4m this year.
Later it mentioned about the most-likely case scenario for Twitter:
Embedding advertisements in “tweets”, short text messages that can be up to 140 characters long, is unlikely to appeal to users. A better bet would be for the firm to charge corporate users for premium services. For example, it could pocket a fee from businesses for verifying their Twitter accounts, so that users following their postings would know the firms’ tweets are genuine. It could also develop a statistical toolkit that measures the effectiveness of tweets in generating sales.

Tuesday, June 16, 2009

IT Project Kill Switch

Waldo Moreira pointed me to the article How to Make Profit which brings an important lesson for IT and project decisions. The article is based on a decision made by the CEO of Rakspace Managed Hosting, Graham Weston, when he passed on a $20 million deal with Morgan Stanley. His decision was based on the fact that the deal was not profitable enough. To be more precise, it was 5% less than the original 15% profit margin for Rakspace.

The article explains that many companies lack the discipline of true profit or economic value added,
...Lots of big corporations don't make a true profit. That is equally true of small businesses, which can be so desperate to close deals early on that they neglect to really look at the numbers. As a result, line managers are clueless about the cost of capital and the returns — or the lack thereof — they are generating.

Jim Collins wrote in his master piece Good to Great how leaders "Confront the Brutal Facts". The great leaders had the following patterns: all of the them gather data before making a decission, then make excellent use of it, and finally use it to confront their decisions head-on. This is what Weston end up doing. After analyzing the venture with Morgan Stanley, he noticed that Rakspace was going to make 10% profit, 5% less than the original 15% profit margin. In his new book, How The Mighty Falls, Jim Collins talks about the five steps that companies take before failing. The second step is called "Undisciplined Pursued of More",
...More scale, more growth, more acclaim, more of whatever those in power seem as success...Although complacency and resistance to change remains dangers to any successful enterprise, overreaching better capture how the mighty falls.
There has to be some type of threshold that allows senior management to take the bold step and say "no" to specific projects. Senior management need to look beyond the numbers. In the HBR essay, The Truths About IT Cost, Susan Cramm writes about what drives up IT costs. She identified seven such truths. Perhaps the most interesting is "Project Failures are too High". Being an IT director, I'm faced with different "wish list" of projects from marketing, sales, and senior management. IT should not be the one to define whether or not a project should launch. As Cramm explains,
Managing these truth is tricky. IT can't do it alone, because simply saying no to business partners harms relationships with them.
Senior Manager should provide a threshold, a magic number, like the 15% of Weston and IT should raise the flag when a project is going down the wrong path. As Cramm says,
Establish a "kill switch" rules for projects.
If a project is out of the initial budget and has been modified twice and beta deployment still not occurred, KILL IT!

Tuesday, June 9, 2009

Boxing Business Model - HBR did it!

They said that Latinos have three sports: football (soccer), baseball, and boxing. I love boxing! Being a Nicaraguan and married to a Mexican, I watch boxing and follow most of the light weight fighters. At the moment, my favorite fighter is Manny Pacquiao. I can't get enough of this guy! He is awesome! You can learn so much from boxing. I wondered if anyone made a business model out of this sport. Finally, I found out that Donald Sull made one, Thrive in Turbulent Markets. In here he shows the memorable fight of Mohammed Ali vs. George Foreman "Rumble in the Jungle". Not my favorite fight, but definitely in my top 5. Here he explain how to be Agile like Mohammed Ali to quickly spot and exploit market changes. Also explains how to use an absorption model like Foreman to weather unexpected threats.

PSMS beware of Twitter


I believe that a disruptive technology for the PSMS might be Twitter. It's free!! In the book, What Would Google Do? they explain how free is a business model.
Free is impossible to compete against. The most efficient marketplace is a free marketplace. Money gets in the way. It costs money to market and to acquire customers so you can sell things to them.
This is contrary to the concept of PSMS, specially for subscription. Why would anyone subscribe to a "joke" subscription where you get charged $6.99 monthly, when anyone can follow George Lopez, Dane Cook, Dave Chapelle, or even your funniest friend on Twitter for a standard rate (zero, zip, nada)? I encouraged my company to move away from subscriptions, and to start thinking on this business model, even if we currently have a "cash cow".

Another reason of considering Twitter as a disruptive technology is its simplicity. It's so simple to tweet. Even TV shows as Meet The Press, whose average viewers are not your average techie, can be follow on Twitter. Christensen's The Innovator's Dilemma explains that,
Two additional important characteristics of disruptive technologies consistently affects product life cycles and competitive dynamics: First, the attributes that make disruptive products worthless in mainstream markets typically become their strongest selling points in emerging markets; and second, disruptive technologies products tend to be simpler, cheaper, and more reliable and convenient than establish products.

It is obvious that this disruptive technology is coming - and it's coming down hard. I personally thing is going to be a good thing. The users will be getting better service, and will be more in control. We are looking forward to Twitter specially for Latin America.