Over the last 10+ years I reviewed and negotiated all sorts of vendor agreements for technical operations. Companies that are starting to build out their production environments occasionally contact me looking for advice. Being on vacation (and having time to write), I decided to share some of the more common problems I see in vendor agreements.
In almost all cases you can (and should) get better terms on what are presented as these “standard” clauses.
The Service Level Agreement (SLA) is probably the most critical to the availability of your business. For vendors providing services like DNS or bandwidth, any vendor failure can result in failure of your business. In other words, your uptime is no better than their uptime. The SLA is typically expressed and a percentage of availability. If the SLA is 99.9% uptime, you are accepting 45 minutes of downtime per month. Failure to meet the SLA usually means reimbursement for the cost of the service, not for the cost of your lost revenue resulting from the failure. For example, if you pay a DNS service $31 per month and they are down for a full day, your reimbursement would be $1, not the revenue you lost during that full day. Also, when the failure begins is usually defined as your notification to the vendor, not by the actual beginning of the failure. In other words, if you didn’t report it, the problem never happened.
The availability percentages for an SLA are usually difficult to alter but there are a few things in that you can change to limit your liability. Most (all) services have occasional failures, but it’s how they fail that become problematic for your business. An occasional failure might be okay but if this is a pattern you want the option of moving to a new vendor. You can usually add a clause that allow a termination of the agreement if the vendor fails to provide service more than N times in a 1-month period. Also, you can usually require that SLA failure begin at the time of the actual failure (when it is detected by either party) rather than your notification to the vendor.
Term and Renewal
Automatic renewals are also common in agreements, in which the duration of the agreement is automatically extended by the length of the initial term. Typically these require you to opt-out of the renewal by providing written notice within a narrow window of time. For example, your initial duration is a 1-year after which the contract will automatically renews under the same terms for an additional year unless notice is provided in writing 30 – 45 days prior to the automatic renewal. Vendors generally don’t contact you to remind you that your opt-out window is approaching and that you might want to negotiate a better deal while you can.
In most cases you want to avoid this simply because the prices for the service are almost always cheaper at the end of the initial term. This is especially true for things like CDN and bandwidth. If you’re not good at remembering to do things 11 months in the future, you may find yourself stuck in an agreement with the least favorable pricing.
The initial duration of the agreement is usually a requirement, or at least a requirement for favorable pricing. However, you should be able to change the automatic renewal to transition into a month-to-month agreement instead of the initial term. This will provide a better negotiation position when the agreement is up for renewal and will allow you flexibility in the timing.
Change of Terms
It is not uncommon to have a clause in the agreement that sates something to the effect of, “these terms are subject to change” with a link to the vendor website with the current terms. In effect, this says “you agree to whatever we decide to publish on our website”. I find these clauses ridiculous… I would love to respond with a clause stating, “our payment terms are subject to change subject to the amount I decide to write on the check”.
In these cases I find it useful to add a clause that requires notification (in writing) of any changes with a short period allowing an opt-out if the changes are seen as a material change. If you are unable to get a clause to allow termination of the agreement you should be able to get the option to stick with the original terms.
It’s worth noting that with any change to an agreement, a vendor may not have systems helping them enforce or react to the change. For example, if you are the only customer requiring written notice of changes, this may require manual work that they forgot shortly after signing the contract. You should consider this and word your changes in a way where a failure on the part of the vendor does not put you at a disadvantage.
I just read Google’s Quest to Build a Better Boss, describing “Project Oxygen”, which analyzed Google’s performance and review data to determine which characteristics are most important to being a successful manager at Google. This was summarized into eight key success behaviors and three common pitfalls. The big surprise? Google “…found that technical expertise — the ability, say, to write computer code in your sleep — ranked dead last among Google’s big eight.”
This is not a surprise to me and supports what I have come to believe after years of engineering management – being a great engineer does not necessarily prepare you for being a good manager. This is not to say that great engineers can’t also be great managers, but the process many companies use of taking their best engineers and “promoting” them to management is flawed. In many cases, it leads to a company losing a great engineer and gaining an ineffective (or worse, harmful) manager. Many companies compound this problem by creating career ladders that effectively force engineers to choose between a career ceiling and a management path.
There are many characteristics that I see in successful managers. First and foremost, good managers have to always be working to ensure the success of the team and their individual reports. Success goes beyond just getting projects and tasks done – it also means helping their individual reports understand their strengths and opportunities for growth. It requires taking a real interest in where each person wants to go in their career and creating opportunities for them to reach their goals. Good managers need a lot of block and tackle type skills to unblock people and ensure they have an environment that helps them remain productive. Good managers encourage growth for their employees by giving direction when needed but empowering them to try (and sometimes fail) in the interest of helping them learn and improve. Of course, good managers must also be proactive about confronting tough issues and addressing performance problems to maintain a high-quality team.
Those characteristics are not necessarily the same characteristics necessary to be a great engineer. It is not uncommon to see great engineers also be really great mentors and solve problems (beyond just engineering) in creative ways, but it is not typically their focus. Also, the way they work is typically different. Most managers have a tremendous amount of context switching during their day and need to make themselves available and interruptible to unblock others – this can be highly detrimental to an engineer that typically pays a high cost for context switching and getting back into the flow.
Another critical characteristic good managers is knowing how to get problems solved. This is very different than knowing the solution to a problem. The manager adds value by unblocking their report, not by being smarter than their report. Many times I see very technical employees go to a much less technical manager with a technical problem. While the manager may not be able to solve the problem directly, they can usually identify the steps (and people) required to get a solution. This is where I see many organizations make mistakes when looking for managers – they assume that a manager can’t manage engineers if she is less technical that the engineers in the organization. As an example of how this can manifest itself, at my company we were looking for an additional engineering manager and the bar was set pretty high based on the performance and 360 feedback of our existing manager – engineers thought he was great. The engineers interviewing the candidate used the exact same very technical questions we use to identify great engineers. The candidate did not do well. In the wrap-up meeting I asked if they had ever needed their great manager to to answer these types of technical problems and the response was, “no – we have really solid tech leads for that”. We quickly adjusted the engineering manager candidate questions to stop looking for successful engineer skills and instead identify manager skills that make other engineers successful.
For most of my life I have had the privilege of working with some truly exceptional programmers (far better than myself). It did not take long for me to realize that the value I could create for each company as an engineer was much less significant than the value I could create by ensuring that other (better) engineers were effective and successful. However, some companies make management the only option for career progression, which encourages great engineers that are passionate about coding to switch to a role for which they are less passionate and probably less capable (yes this is a generalization and I apologize to the truly amazing individuals that are both deeply technical and exceptional managers). More companies should have parallel career ladders that allow engineers to remain with their hands on the keyboard and heads in the code while obtaining a career level as high (or higher) than management positions.
On a side note, one of the things I really liked about Project Oxygen is the approach of using data to analyze business processes. I find that many companies that are data driven and have a deep understanding of their customer metrics many times don’t have the same understanding of how they work and what make them (in)effective. We regularly collect data at my company and use it as an input to redefine how we work and constantly benefit from that evaluation.
Here is a summary of Google’s findings from Project Oxygen:
Here are the 8 top behaviors of managers in order of importance:
- Be a good coach
- Empower your team and don’t micromanage
- Express interest in team members’ success and personal well-being
- Don’t be a sissy: Be productive and results-oriented
- Be a good communicator and listen to your team
- Help your employees with career development
- Have a clear vision and strategy for the team
- Have key technical skills so you can help advise the team
Here are an additional 3 manager pitfalls:
- Have trouble making a transition to the team
- Lack a consistent approach to performance management and career development
- Spend too little time managing and communicating
I recently got rid of my old ice cream maker. It was electric but it still required filling (and re-filling) with ice and salt, which does not seem like that big of a deal but it proved to be a barrier to wanting to make ice cream, so it came out of its box about once per year. Instead I got the KitchenAid Ice Cream Maker Attachment for my stand mixer. It has a bowl you keep in the freezer for about 15 hours and then you just add your ice cream mixture and 20 minutes later you have ice cream. Setup and cleanup are about 20 minutes total and as a result, I have been making ice cream about every other week. Good for tasty treats, bad for my recent attempts to lose my girlish figure.
Since it is now easy to make ice cream, I started to experiment. The first success is my “Simple Chai Tea Gelato Recipe” which would probably be best with Indian food but it isn’t too sweet and has a light enough flavor to be pretty versatile.
2 cups of milk (I used 1%)
2 cups of heavy whipping cream
3/4 cup granulated sugar
4 tea bags of chai tea (I used Tazo brand)
Heat the milk until it is just about to boil, stirring frequently. Slightly reduce the heat, add the tea bags and continue stirring for 5 minutes. Turn off the heat and remove the tea bags, squeezing them to extract the remaining milk before discarding. Stir in the heavy whipping cream and chill in the refrigerator for a few hours until cold.
When freezing the mixture (in an ice cream maker), it will not have as much of an increase in volume as a typical ice cream – this produces a denser consistency more like gelato. Immediately move the frozen mixture to the freezer for 3-4 hours to harden.
This makes about 8 servings and if you are counting calories, it works out to 206 calories per serving.
As summer approaches and people look for cool, refreshing beverages to serve, I thought I would do some promotion of a few cocktails that I don’t see getting enough attention. I’m not going to advocate any particular recipe over another (use your favorite search engine to find hundreds of recipes), but I do recommend you use only fresh ingredients (get out your citrus juicer) and quality alcohol. If you are doing anything with a plastic bottle you have probably gone down the wrong path.
The best part is you don’t need much to make these cocktails – each requires only three ingredients!
The caipirinha is a Brazilian drink made with limes, sugar (or simple syrup) and cachaça, a liquor made from sugarcane that is sometimes compared to rum (but they are different, so don’t substitute). It is important to note that you don’t use only lime juice, you use limes and you muddle them. The oils released from the skin of the lime add a tremendous amount of flavor to the drink. I have had recipes made with sugar (typically a coarse, large grain) and with simple syrup and both are tasty, although I have heard what seem like religious arguments from caipirinha aficionados so be careful if you are serving at a Capoeira tournament.
I have tried a few brands of cachaça,and some bottles that were from roadside distillers. I found the cheap brands were a bit too harsh so spending a little more is probably worthwhile. If you are new to cachaça and unsure what to get, try Leblon – it seems to be of decent quality and makes a good drink. Some of the roadside cachaça I had was actually pretty good, although I was too stressed about possibly going blind or getting poisoned to enjoy it fully.
This is a simple variant of the Sidecar in which the brandy is replaced with bourbon. The ingredients are bourbon, orange liquor and lemon juice. Cointreau or Grand Marnier are both good options for the orange liquor and a generic Triple Sec will do in a pinch (okay, technically Cointreau and Grand Marnier are name brands of Triple Sec). As for the lemon juice, I prefer a more tangy lemon over the sweeter varieties like the Meyer lemon. Use a good bourbon… if you are new to bourbon and need an introduction, try Maker’s Mark - its widely available, won’t offend anybody and it has a fancy seal on the bottle.
In my opinion this is a drink that does well when it is vigorously shaken… its perfect when you strain it into a glass and see a very thin layer of ice floating across the top.
This cocktail happens to be my test for whether a bartender knows their stuff. Go into a bar, order a daiquiri cocktail and see if you get the response “we don’t have a blender” (or worse, you hear a blender start whirring). I am not talking about the horrible abomination that is a frozen daiquiri, I am talking about the original, pure, simple cocktail enjoyed in excess by Ernest Hemingway. The daiquiri is simply light rum, lime juice and a sweetener, typically simple syrup. So you may be saying, “hey, isn’t that the same thing as the caipirinha but with rum, that you just told me not to use”? Not at all.. this is lime juice, not limes and the flavor is completely different.
Oh, if you need an excuse to try this drink, supposedly July 19 is National Daiquiri Day.
I don’t spend a lot of time back East so maybe this drink gets the attention it deserves, at Kentucky Derby time if no other. I find that it is not uncommon for a bartender to mess-up this drink because they think it is a mojito with rum as a substitute for the bourbon. It’s sort of close, but the mint julep does not have lime, so this mistake leads to a pretty nasty tasting drink. The ingredients of a mint julep are sugar, bourbon, mint and water (okay, that’s four ingredients but I am counting ice and water as the same thing). When you muddle the mint, make sure you simply crush it to release the essence… you are not trying to grind it into a pulp. I have also had the mint julep using simple syrup instead of sugar and it makes the flavor more consistent by distributing the sweetness equally, but it is not as fun as drinking the sugar from the bottom of the glass with a straw and adjusting the sweetness in real-time. Traditionally the mint julep is served in a pewter or silver cup but it tastes just as good in glass.
Note: The original source of this posting is http://engineering.imvu.com/2010/04/30/imvu’s-startup-lessons-learned-conference-presentation/
IMVU presented at the Startup Lessons Learned Conference in San Francisco on April 23rd, 2010. The event highlighted several companies that are being built using the “Lean Startup” framework created by Eric Ries, IMVU’s former CTO, largely based on his experiences at IMVU.
The conference was great and I had the opportunity to meet many smart entrepreneurs trying to build businesses out of great ideas. I heard many stories about the challenges early startups encounter and could remember when IMVU was in that stage. I also talked to some people from companies that are now considered “big and successful” and heard a few comments along the lines of “been there, barely survived that”.
At the conference I had the realization that IMVU as a business is not exactly a “startup” anymore. The goal of an early startup is discovering the right product and achieving a sustainable business model. IMVU has been successful at this and is now all about building a growing, enduring business that is a high value for our customers and employees. Though we still feel like a startup in many ways and hold onto the lean principles that proved to be so valuable, we now have new challenges to address that are typically not considered startup challenges.
A successful startup grows into a bigger business. At IMVU, we heavily invest in our company so we can get more people working on features that delight our customers and build up the business. With more people many of the ways you used to work don’t work anymore. For example, frequent meetings to get feedback from everybody in the company can work when you have fewer than 15 people… when you get to 50+ people this becomes a very expensive meeting. The overhead of making sure everyone in the meeting has background data and context to make an informed decision simply does not scale. Joel Spolsky explained this well and provides good examples in his article, “A Little Less Conversation”.
There are a whole range of challenges in these transitions, from process to culture and all have to be accommodated as a company grows. At the conference I was approached by several people that had gone through the same experience, some successfully, some not. I hope that some of what IMVU shared will help others to learn from our experience and allow more people to fall into the successful category.
Check out IMVU’s video presentation available at http://bit.ly/bBpUcm
If you just want to review the slides without audio, they are here: http://bit.ly/aGXqcY.