Posts Tagged ‘Management’

Why Can’t I Outsource Everything?

Wednesday, May 26th, 2010

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.

Outsourcing Engineering or Operations

Monday, April 26th, 2010

Our clients very often have questions over Why, What and How to outsource software development efforts, infrastructure, hosting, etc.  Readers of our book or frequent readers of our blog will notice that the questions are similar to those we ask in our “Build v. Buy” analysis.   The decision of what to outsource isn’t significantly different than determining when to buy rather than build.

Why outsource?  There are three very good and common reasons to outsource engineering efforts.

1)      You want to reduce your average cost of engineering and outsourcing may provide a way to do that (especially “offshoring”).  The right kind of outsourcing can reduce your unit cost of labor for engineering efforts.  But before you outsource, you should understand the full cost per unit developed of your engineering efforts so that you can measure and validate your cost benefit.

2)      You have near term capacity needs to increase engineering capacity that you cannot meet with current hiring practices.  If you need to 3x the size of your engineering team in 2 months, you probably need outside help.

3)      You fear that the engineering capacity need will be short lived and do not want the risk of hiring W2 employees.  Sometimes (2) and (3) are bundled together.  If you don’t have follow on work for some new system or product, you probably don’t want to hire and then fire employees.

The “What you should outsource” is very often mistaken as “why one should not outsource”.  There are almost always things you can outsource, and very often there are things you absolutely should not outsource.   We typically discuss 4 areas with our clients to help them understand what can and what should not be outsourced.

1)      Don’t outsource things that create strategic competitive differentiation for your company.  Having a third party develop the thing that differentiates you from your competitors is giving away the secret sauce.  It’s hard enough to protect intellectual property – if you simply give it to someone else you might as well just give it away.  Now probably not everything you do differentiates you from competitors.  For instance, if you run an ecommerce site you might determine that your product proposal system is a differentiator while search is not.  Outsource search, keep the development of your product proposal and analytics system in house.

2)      Don’t outsource product definition.  If you are in a product business, you really can’t outsource the definition of the product that makes you money.  We’ve seen customers try and it’s not pretty.

3)      Don’t outsource your architecture or standards.  Tightly coupled with product definition is the need to set the standards and architecture by which the platform abides.   You may believe that the beauty is in the idea or the specification of the product but if it takes off it will need to scale.  Few outsourcers are adept at defining scalable platforms because the largest and best companies simply don’t outsource that – ever.

4)      Don’t outsource areas where you need rapid response and flexibility.  These things might not be competitive differentiators – but if you expect a turn on a dime response in specific areas you aren’t likely to get those with a contractual relationship.

Finally we come to “How you should outsource”.  Here again, we have three common rules for our clients.

1)      Manage the outsourcer.  That means that you need to add employees to manage the outsourcer and the projects, which in turn means that the actual cost of outsourcing is higher than what the outsourcer has quoted.  Keep this in mind when considering outsourcing to dollar average costs down.

2)      Expect conflict.  Rarely do we see outsourced projects that don’t have conflict between internal engineering teams and the outsourced team.  Expect it and be prepared to manage it quickly.

3)      Deliver standards with specifications.  If you expect something to be 99.99% available, scale to 10x the current volume and deliver new functionality be very specific and demand proof.  We’ve even helped negotiate contracts where payment happens after proof in the production environment rather than delivery.

Summary:  Look to outsource when you want to manage the risk of growth or contraction and to lower your engineering costs.  Always expect that you will have to aggressively manage your outsourcer and always deliver specific standards of operation with your product specifications.  Never outsource areas that strategically differentiate your company or product offering or where you need strategic or tactical flexibility.

Speak in Terms of Objectives – Not Actions

Thursday, January 14th, 2010

Have you ever been in a position where a project you were managing was late or over budget? Have you ever supported an application that had a customer impacting service outage? How did your boss respond to these issues? Did she say something like “I want a review of our quality strategy” or “I’d like to see our application rollout strategy”? Maybe they asked for something even more nebulous and less connected to the issue at hand like “Show me our site and product integration strategy”. Huh? What does that mean?

It’s easy for managers to react to incidents and problems by requesting that certain actions be taken by a person or team. The problem with such an approach is that it feels like a punitive action to the people from whom the action is being requested. Maybe the group or person needs to receive performance feedback, but by asking them to take an action you are not really giving them feedback. If your goal is to both provide feedback and ensure the underlying issue is corrected then provide candid performance feedback and explain the desired goal of the corrective action.

Great leaders understand intuitively that they should speak in terms of desired end states and then ask for plans to achieve those end goals or states. Another approach is to use the Socratic Method and ask your team what an appropriate end goal should be, whether they’ve achieved it and how they should correct their approach to achieve that goal. The first is probably the best approach when the team is overwhelmed or you are in the middle of a crisis. The latter approach is best for higher performing teams who have simply hit a “bump in the road”.

VP of Operations

Monday, November 16th, 2009

One of the most common questions we get from individuals is “what is the path to becoming a CTO?” We posted about this before and focused on the skill sets required as opposed to the path to get there.  We highlighted 1) good knowledge of business in general 2) great technical experience 3) great leadership 4) great manager 4) great communicator and 5) willing to let go.  This time we’re going to one of the jobs that is often a stepping stone to the CTO job.

The VP of Operations is the person who leads the Technology Operations or Production Operations team.  This team has responsibility for running the hardware and software systems of the company. For SaaS or Web2.0 companies this is the revenue generating systems. For corporate IT this is the ERP, CRM, HRM, etc. This team is often comprised of project managers, operations managers, and technical leads. As the head of the Operations team the VP of Operations has responsibility for monitoring, escalating, managing issues, and reporting on availability, capacity, and utilization. Incident and problem management as well as root cause analysis (postmortem) are some of the most important jobs that their team accomplishes. In order to perform this role well the VP of Operations must have good process skills, a strong leadership presence, able to remain calm under fire, and goof overal knowledge of the system.

The VP of Operations is often also responsible for the Infrastructure team. This team is usually comprised of system administrators, database administrators, and network engineers. This team procures, deploys, maintains, and retires systems. As the head of this team the VP of Operations has requirements for budgeting, balancing time between longer term projects and daily operations on the systems. This team understands the system holistically and are often the most useful when performing scalability summits. In order to perform this role well, the VP of Operations must have a good understanding of each of the technical roles that this team is responsible for, including the databases, operating systems, and the network. This doesn’t mean in order to succeed in this role a person must be able do each of these jobs but they do need a good, solid understanding in order to converse, brainstorm, debate, and make decisions in each of these technical realms.

If you compare this list of skills that we mentioned at the top of this post with those mentioned as necessary to succeed as the VP of Operations you’ll see they overlap a good deal. Great technical experience, great leadership, and great management skills will serve you well as the head of operations and will also go a long way to developing most of the skills you will need as a CTO.

We’re approaching the end of the year, a time that many people and organizations use to reflect on what they have accomplished and what they want to accomplish next year.  A good idea as part of your personal growth is to use the list above and score yourself as honestly as possible in terms of skills.  If you’re missing some of them make sure you have some goals in place that help you acquire a few more of these each year. Do this and not only will succeed one of the important jobs that lead to the CTO job but when you do arrive at the CTO position you will be one of the successful ones.

The Art of Scalability Update

Thursday, October 1st, 2009

Our book is still on track for an early to mid January 2010 hard launch.  We have completed roughly 1/3d of the copy editing process, having gone through the final round of editing on 11 chapters so far.  The book is available for pre-order at Amazon, Barnes and Noble and Borders.  You can also pre-order the book from the publisher, Addison-Wesley as well as get early web-access or pdf access to the pre-copy edited book.

Fish and I are discussing different options for signing books that clients and readers of our blog and newsletter purchase.  If you are interested, simply comment/respond to this post and we’ll work on logistics.

The Art of Scalability