AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Tag » Management

Please Be Quiet

Are you allowing your product or service to fail because someone else doesn't understand what it takes for you to succeed?

I’ve noticed lately that more companies are putting up signs in hallways and cube farms requesting that people avoid having conversations in these areas. While having a nice quiet work environment makes sense to me as a developer, doesn’t this completely void having people work beside each other? The ad hoc/hallway/water cooler/coffe machine conversations or ones overheard when cube mates are chatting about a new feature are one of the primary benefits of having people work in small open environments.

I haven’t done any sort of scientific study but it seems that these sort of “please be quiet” signs are more prevalent at larger companies. These are the same ones that are trying to mimic the small startup with agile development processes or open work spaces to compete in a fast moving SaaS marketplace. Imitating the actions without understanding the purpose or allowing old school corporate policies to overrule are surefire ways to tank the initiative.

A parallel to the “please be quiet” sign is allowing corporate IT to dictate the architecture of the SaaS offering based on a corporate standard that works for the ERP system. Running Oracle ERP on a 16-way system might be the vendor recommended, preferred approach but for scaling a SaaS offering this is a quick way to run up the costs and ensure lower availability. We often use the analogy of goldfish and thoroughbreds for comparing small, cheap 1U servers with large, expensive multi-processor boxes with lots of memory. The goldfish (small, cheap servers) are inexpensive to purchase and replaceable while the thoroughbred (large servers) are expensive to purchase/maintain and cause big impacts when they go down.

The take away to all of this is that if your part of a corporate initiative to run an internal startup or deliver a Software as a Service from inside a larger organization, don’t allow corporate policies to prevent your success. The differences in approaches, architectures, organizations, and offices have a purpose and should not be discounted as non-critical to the success of your initiative.


Why Can’t I Outsource Everything?

Our second article on outsourcing, which digs into the competitive considerations of outsourcing engineering and/or operations.

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.

1 comment

Outsourcing Engineering or Operations

A quick summary of AKF Partners' approach of what, why and how to outsource engineering efforts.

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.

1 comment

Speak in Terms of Objectives – Not Actions

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”.

Comments Off on Speak in Terms of Objectives – Not Actions

VP of Operations

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.

Comments Off on VP of Operations

The Financial Drivers of Security

Our last post, Top 4 Failures in Corporate Information Security, kicked off a 3 part series on security addressing some of the most common themes from our work with clients.  This post will cover the first 2 failures from our last post in greater detail.  The first section will focus on why financial concerns, and not fear, should drive your security decisions.  The last section focuses on the financial motivations of potential thieves and the ramifications to your security architecture and design.

Focus on Finance (or profits) and not Fear

Has your security team (or have you) ever presented a project justification that something has to be done “or else we will be horribly exposed?”  Or maybe the proposal was worded such that the project must be done or you risk “irreparably tarnishing our brand”.  Or how about “Our front doors are basically wide open, nearly anyone can walk in and take whatever they’d like”.  The problem with all of these statements is that not only are they difficult to prove or disprove, they are positioned to elicit a fear response for the purposes of attaining a goal.  How does one quantify fear and evaluate it against other business initiatives?  Our position is that one can’t and that one shouldn’t.

Our jobs as managers and executives are to make sound business decisions that maximize shareholder wealth.  The appropriate management of risk is an example of such a decision.  We spend money on risk management initiatives to offset potential future losses associated with the realization of that risk.  We might invest in fraud detection systems for instance to reduce future potential losses.  In doing so we pay the expense and capital of putting such a system in place, and potentially lose some revenue through the “false positive” identification of fraud within our revenue stream in order to significantly reduce the amount of real fraud going on within our systems.  Similarly, we might decide to put firewalls in certain places to reduce the probability of a penetration and associated brand damage at the expense of the labor to put those firewalls in place, the capital to purchase the firewalls, and the decrease in availability and scalability those firewalls might present.  Those firewalls also might slow our time to market for certain initiatives or increase the cost of those initiatives by adding steps in order to put new rules in place for new applications, etc.

On a project level, the point at which we should stop adjusting risk in any given area is the point at which the incremental cost of effort of risk adjustment exceeds the incremental value.  On a portfolio level, the cost and value of the risk adjustment above should be compared to all other capital and effort based projects.  Just because the project has a return, doesn’t mean it is the best use of our time and resources.  So, if we add a $10M fraud system that is only likely to return $8M in total benefits over 3 years have we made the right decision?  What if it returns $10M in 3 years?  The point here is that the initiative should be couched in business terms and compared appropriately against other business initiatives in terms of its financial benefit.  Don’t let fear motivate your decisions.

Bad Guys Like to Make Money Too

Sun Tzu is attributed with saying “If you know both yourself and your enemy, you can win a hundred battles without a single loss.”  How well do you know your enemy?  While some of your enemies are out to brag about their accomplishments , a majority of your enemies are out to make money.  The people who perpetrate technology crimes are generally skilled and intelligent (though morally bereft) people who see the perceived benefit of stealing your data as being significantly greater than the perceived cost.  It is this equation that we are going to address in this section.

In our equation Perceived Benefit (PB) > Perceived Cost (PC) the word “perceived” is very important.  We need elements in our security architecture that decrease the perceived benefit of a potential security breach.  This might be one-way encryption of sensitive data such that it can’t be used by someone stealing it, or it might be hiding our data and valuables so that “passers-by” don’t ever perceive any value in attacking you.  Maybe you can develop marking technologies for your data or “beacons” such that the data can be tracked if used.

Elements of perceived cost include the perceived cost of obtaining the data and the perceived cost of getting caught.  This implies that not everything need to have the same “actual” cost of protection as it makes little sense to spend money protecting something that has little perceived value.  The perceived cost of getting caught is at least partially influenced by your track record with catching would-be thieves as well as how well you publicize your successes.  If I am choosing between attacking site A and site B, each of them equivalently physically protected and of equivalent value to me, I will likely choose the site that appears to me to be the least likely to catch or prosecute me.

In our next post, we will discuss who should make security decisions and why firewalls aren’t always a good thing.

Comments Off on The Financial Drivers of Security

Resonant or Competent?

What type of boss or employee would you rather have, one who is in tune with the team or a competent one? While we usually don’t have to make that extreme of a choice it is often the case that we are faced the decision of keeping or letting go a manager or employee who is technically excellent but difficult to work with. Sometimes this is our boss and we have to decide as an employee whether to stay or not. Two theories on leadership that I’ve come across recently have me debating this question. The first is Extremis Leadership from Colonel Thomas Kolditz who is a professor at West Point. The second is Resonant Leadership by Richard Boyatzis and Annie McKee. Dr. Boyatzis is a professor at Case Western Reserve University, Dr. Annie McKee is the founder of the Teleos Leadership Institute, and both are co-authors with Daniel Goleman of the bestselling book Primal Leadership.

A simple blog post cannot fully explain either one of these leadership theories and while they do offer generally different perspectives on leadership there is also a great amount for which they complement each other. I encourage you do investigate and read each book but I will provide a quick positional overview that can spark our discussion. Extremis Leadership essentially states that in crisis situations three characteristics of leaders stand out, competence, trust, and loyalty, in that order. And that competency is by far the most important when people feel their lives are on the line. This is to such an extreme that competency can supersede the individual’s rank, which as you can imagine in the military is pretty strong words. There is a promotional video on his site that shows some of the principles that he espouses put into action as Col. Kolditz takes someone through their first parachute jump. The term Resonant Leader, was first introduced in Primal Leadership and refers to a person who is in tune with him or herself, and the people they work with. They create a sense of resonance in the workplace, so great work can be accomplished. Resonant Leadership explains that mindfulness, compassion, and hope are the key elements to enabling renewal and sustaining resonance in leaders that produce quantifiably better results. Additionally they prevent the leader from burning up and becoming dissonant.

An easy way to compare these theories is using our 2×2 matrix that we usually use to explain our “Seed, Feed, and Weed” approach to leadership. In case you haven’t gotten a chance to checkout the rough cuts version of the book we have an expanded section on this concept of identifying the right team members to reward, coach, or encourage to pursue other job opportunities. Below you see how we have overlayed the theories on the axis that they most strongly relate to. Obviously both strive for the upper left quadrant as their goal but each has a dominant axis in which they utilize to get to the upper left.


Having been a part of many crisis situations, including some where people’s lives were on the line I can see how competency can momentarily trump all other characteristics. However, a leader who has produced dissonance in the organization over many weeks, months, or years before the crisis can and probably will be ignored exactly when they are the most useful in spite of perhaps having the best plan.

I would put up with a boss or employee who was extremely competent but difficult to work with for a short period of time to get through a crisis. But having to work with someone for any extended period of time would cause me to discount the value of their competency and remove them from the organization. To me there is an inflated impact rate over time. For every day I have to put up with a person, rather than enjoy their resonance within the team, the value of their competency gets diminished.

As much as I’ve pointed out the differences between the two theories there are many overlaps. For instance, the Resonant Leader is required to display competency but additionally must be able to foster resonance with themselves and their teams. The Extremis Leader displays trust and loyalty among their team in addition to their unflagging competency. I think the answer for all leaders is yes to both. From what used to be the Army’s eleven Leadership Principles, notice the first two:

  • Be tactically and technically proficient
  • Know yourself and seek self-improvement
  • Know your soldiers and look out for their welfare
  • Keep your soldiers informed
  • Set the example
  • Ensure the task is understood, supervised and accomplished
  • Train your soldiers as a team
  • Make sound and timely decisions
  • Develop a sense of responsibility in your subordinates
  • Employ your unit in accordance with its capabilities
  • Seek responsibility and take responsibility for your actions

1 comment