Over the course of the last year, we have seen several of our clients either start exploring or make plans to move their SaaS products to the “Cloud” or an IaaS provider. We thought we would share some of the misconceptions we sometimes see and our advice.

- I can finally focus on product development and software engineering and not worry about this infrastructure stuff.
The notion that IaaS providers like Amazon have eliminated your worries about infrastructure is only partially true. You may not need to understand everything about designing an infrastructure with bare metal but you need to make sure you understand how your virtual configuration in the Cloud will affect your product. IaaS helps us to quickly deploy infrastructure for our products but it doesn’t eliminate the need for good high availability and fault tolerance design. There are several levers you can pull within an IaaS console and design decisions that will impact your products performance. To ensure good design and configuration, its ultra important that your SaaS product engineering team is made up of talent that has expertise in distributed application architecture design, infrastructure, security, and networking. Having this knowledge will help you design a high performing, fault isolated product for your business.

- Going to the cloud pretty much guarantees me high availability because of auto scaling.
Going to the cloud will provide you with the ability to scale quickly as load increases but it will not provide you with high availability. For example, if you have a monolithic code base that you deployed and you are pushing to production on a regular basis, there is a pretty good chance you will introduce a defect at some point that impacts the availability of your entire service and business. We advise our clients to split their applications appropriately, deploy the services to separate instances, and, assuming you are using Amazon, configure them to run across multiple zones within a region at a minimum (preferably across regions). This allows you to focus dedicated teams to the individual services and reduce the likelihood of introducing a defect that takes down your system.

- The Cloud will be cheaper than a collocation or managed hosting provider.
There are several factors that need to be considered before you can confirm that is cost effective. You should look closely at load on your servers. If your servers are not serving traffic around the clock, it may be better from a cost perspective for you to buy and maintain your own infrastructure in a collocation or in an existing data center you may have. The economics of this decision is changing rapidly as IaaS pricing is declining due to the competition in the industry. A simple spreadsheet exercise will help determine if the move to Cloud would be cost effective for your business.

- The Cloud isn’t secure so we better not use it.
The cloud isn’t necessarily what makes or breaks security around your SaaS product. Many believe that public cloud services like Amazon’s EC2 service isn’t secure. First off, you are far more likely to experience a security breach because of an employee’s actions (either intentionally or unintentionally) than caused by an infrastructure provider. Secondly, Amazon likely has invested much more in security at various layers, including their physical data centers, than most companies we see who have their own data centers. Amazon has designed the infrastructure to isolate customer instances and you can also choose to take advantage of Amazon Virtual Private Cloud that can be configured to create an isolated network. There are various options for encrypting all of your data as well. This only touches the surface for security design options you have and they continue to be enhanced everyday. You can see why it’s important to staff your team with an engineer who has experience in this space.

If you are looking to move to Cloud, don’t rush into the decision. Do your homework and make sure it’s right for your business. Make sure you have the talent that has experience with the technology that will get you there and run your operations. Once you make the leap, you will have to live with it for a while.

Driving big changes can be difficult in an organization and it can be especially difficult for new managers. Change is necessary and we should never be happy with status quo as our competitors and the overall market is changing around us. The larger the organization, the harder change can be. We touched on this in an earlier blog titled Five Leadership Lessons From Former Bosses but decided to dive into a little more detail this time. As a former manager of engineers and other talented technologists, I recall in my early days how I simply wanted to identify where we were headed with my team without giving them time to collaborate and provide input. On one occasion, we were in the midst of changing our PDLC to Agile. Agile was fairly new at the time so many didn’t understand the basis of it and in turn were resistant to using it. That problem is easily solved, right? I could just tell the team this is where we are going and this is how we are going to do it, now make sure you execute. And in a couple weeks time, poof, the change would be made and life would be good. After all, that would have been easy, right?

Although I didn’t say the words “get onboard,” I might as well have. I can tell you this doesn’t work well. My team was zapped. At that point they were no longer empowered and didn’t have any ownership of the change and when that happens a team’s performance will be suboptimal. Yeah, I could use the excuse that my senior management dictated what they wanted and I could drum up a bunch of other excuses but the fact of the matter is I should have raised a flag with my leadership and encouraged better collaboration for input from the engineers, QA testers, product managers, and others.

There were two key learning points that I was able to take away from my experience. Technology leaders should ask themselves two simple questions before they start to drive change in their organizations.

1) How do I make sure that my team has input and ownership of the change we are about to make?

Sit down with the team and work with them on coming up with solutions and their recommended timing. Engineers love to problem solve and they are very good at it. Provide the team with the problem that needs solved and any constraints and let them determine the solution. For example, in the situation I described above, we needed to improve our time to market. Many products and features across the organization were being delivered late, payloads for deployments were too big, and the business was frustrated. As on overall company we decided that we would adopt Agile utilizing Scrum practices but there were still many problems that needed to be solved. Those included determining a branching strategy, determining a deployment strategy, identifying how to measure a sprints performance, and many others. By providing the context of why changes need to be made, the team will recognize the significance of their input and by allowing them to come up with solutions they will feel empowered and have ownership in the game. All of this will help you to create a higher performing engineering team.

2) What do I need to do as a leader to establish guardrails in my organization and sustain the change as my company grows?

Once the team has determined how to solve some of the problems, you will want to make sure that you sustain them in your organization. To do this, work with them to establish documented guardrails or principles that be used as the what. For example, the Agile Manifesto essentially identifies principles that you can use. One principle could be “Business people and developers must work together daily throughout the project.” This describes a behavior that’s needed but doesn’t identify how. The team can decide the specifics on how they will achieve the principle. We at AKF believe in establishing architectural and scaling principles that are essentially guardrails as well. (Visit our earlier blog on architectural principles for more details.) For example, Rule Number 39 – Ensure You Can Wire on and Off Functions in our book Scalability Rules identifies the need to have a framework where you can quickly disable and enable features to minimize impact to customers when a failure occurs. You can solve this many ways and your engineers can determine what the solution should be. Once your principles are established you should monitor them to make sure they are being upheld and reward results.

If you ask yourself these two simple questions before diving into a big change your road to success will be much easier. Now that you have empowered your team to determine how to solve the problem and you have documented your principles and guardrails, the team should be able to operate within them and make decisions on their own. In turn, you will find that they feel empowered and you will have helped to create and maintain a higher performing team.

We as engineers love to problem solve. In fact, we love to explore new technologies and debate with our colleagues as to what may be the best to use. Should we use Python? Should we use PHP? Should we use Java? Should we try Google’s App Engine and code in GO? Should we use Amazon Web Services exclusively for our product? What database technology should we use? All of these decisions are important and factors such as skillsets, security, performance, and cost should be considered. We love to code and see the product in action as it provides us with a sense of accomplishment. Once we are done with a project and its deployed in production we typically celebrate all of the hard work that went into the solution and we move on to the next project. Many times after diving deep into the technical aspect of the solution, for weeks and maybe even months, we wake up and we discover we are not in touch with the business like we should be. All of us have seen this in practice and many of our clients face this challenge.

What are some of the signs that you may not be aligned closely enough with the business and its performance and what should you do about it?

1) Not understanding feature impact – New features are introduced into your product without an understanding of the business impact.

You should never introduce new features without understanding the impact it is supposed to have on your business. In other words, establish a business goal for new features. For example, a new feature that allows for one click purchase is expected to improve conversion rates by 15% within 2 months. Remember all goals should be SMART goals (per chapter 1 in The Art of Scalability – Specific, Measurable, Attainable, Realistic, and Time constrained).

2) Celebrating launch and not success – Upon deployment of your product and confirmation that everything is working as expected, fireworks go off, confetti falls from the ceiling, and the gourmet lunch is ordered.

While recognizing your team for their efforts to launch a feature can be important, you really should celebrate when you have reached the business goal that is associated with that feature (see item #1 above). This might be achieving a revenue target, increasing the number of active accounts, or reaching a conversion target. If you deploy a feature or a product, and your business targets are not met as expected, you have more work to do. This should not be a surprise. Agile development’s basic premise is that we do not know what the final state of the feature and thus we must iterate.

3) No business metric monitoring – Your DevOps team is alerted that something is wrong with one of your services but you rely on your customer support or service desk to tell you if customers are impacted.

This is something that many of our clients struggle with. We believe its critical to detect a problem before you customers have to tell you or you have to ask them. You should be able determine if your business is being impacted without asking your customers.

By monitoring real time business metrics and comparing the actual data to a historical curve you can more quickly detect if there is a problem and avoid sifting trough alerting and monitoring white noise that your systems will inevitability produce. For more details on our preferred strategy, visit one of our earlier blogs. You can also read more about the Design To Be Monitored principle in our book Scalability Rules.

As you company grows, make sure that your product, your engineering team, and your technical operations are closely aligned with your business. We firmly believe that we as technologists must stay aligned with our business for success. In fact, we really are the business. Our solutions enable the company to earn revenue.

In our latest Newsletter, we wrote about the importance of aligning your agile teams to the architecture of the system and the trend we are seeing as our clients move towards PODS. We believe and teach that designing your architecture is only the first step in building an organization that can scale in support of your product. Remember, agile autonomous teams are able to act more efficiently which results in a speedier TTM. Ideally, they should almost be able to behave like mini-startups.

Aligning teams to swim lanes is pretty straightforward but what do you do with a team that’s central to multiple services?

We often see clients who have this challenge. They have a shared service or feature that the other clearly split autonomous teams depend on. For example, there are several sites that bring consumers together with businesses in their local area. These sites often have categories or verticals that need search functionality. Asking each team to design its own search functionality would be wasteful as you would end up with engineers designing redundant functionality which would exponentially cost more to operate. It is absolutely feasible to create a team that would focus on search and be used by other teams in this situation. We do recommend that you minimize the existence of these types of teams when possible, as there is always risk that they could slow down TTM.

Great! All of the other teams are going to bombard the shared service team with new development requests. So what do you do to mitigate the risk of over allocating your engineers with such a team?

This risk is real as the other teams will make requests for enhancements or functionality to support their services and they will want it quickly. To mitigate this risk we suggest thinking of the team almost like you would an open source project. That doesn’t mean you simply open up the search code base to all of your engineers and let them have at it. Rather, it means you put mechanisms in place to help control the quality and design for your business. An open source project often has its own repo and typically only allows trusted developers to commit. In our search example, you could designate a couple trusted and experienced engineers in the other PODS that can code and commit to the search repo. Engineers on the search team can be focused on making sure new functionality aligns with architectural and design principles that your company has established. This approach should help to mitigate the potential bottleneck such a team could create.

OK, now that you have spread out the development of search, who really owns it?

Remember, ownership by many is ownership by none. In our example, the search team ultimately owns the search feature and code base. As other developers commit new code to the repo, the search team should conduct code, design, and architectural reviews. Just as the other PODS will deploy new features to production, the search team will also own deployment of search. Overall, all of your teams should have objectives that align with a few key business success metrics.

Remember, whatever mechanisms you put in place, your shared service or tools team should be a gas pedal and not a break for TTM. Good luck scaling your architecture and your organization. We would love to hear about some of the experiences from those of you that have tried this or other approaches.

We spend a good portion of our time performing due diligence on companies that are either looking for financing or preparing to be acquired. We thought it would be interesting if we shared some of our observations on what makes the process go smoothly and what causes problems. In our experience and through working with our clients we believe it’s important that you consider the following:

1) Secret Sauce – First off, you need to figure out your secret sauce. Simply stating that you have the world’s largest online bicycle sharing service is only a start. While a service like bicycle sharing might be a great concept, there should also be an algorithm or business method that isn’t necessarily visible to you and I from the outside. For example, the company may have a pricing algorithm that factors in various demand variables for bicycle rentals on a given day and adjust prices accordingly. Look for something similar with your venture. Figuring out your secret sauce will help to raise your valuation.

2) Open Source – We’re a huge fan of open source tools but you need to be diligent about what you are using. Specifically, keep track of the open source products that you use and be aware of the license under which you are using it. There are many different licenses in use today. Below are a few of the most popular and our, non-attorney, interpretations of them. Note, that there is disagreement among much more erudite individuals than us on the terms of each of these so be sure to check with your legal representative before you use any of them.

• GPL – GNU Public License – You are allowed to use, redistribute and change the software, but any changes you make must also be licensed under the GPL. So that means you have to give everyone else the same rights as you got.
• LGPL – Lesser General Public License – If you modify the software, you still have to give back the source code, but you are allowed to link to it (compile with it) without giving the source code to everything you built back.
• BSD license – Berkley Software Distribution – You can take the code and turn it into a proprietary application and you don’t have to give it back.
• Apache license – Allows the use, modification, and distribution of the software for any purpose but does not require modified versions of the software to be distributed using the same license.

3) Patents – One method of demonstrating value and uniqueness is to build up a patent portfolio. To be valid, your patent must be new, useful, non-obvious, and of a subject matter defined as patentable. Machines, processes, methods, and compositions of matter are examples of patentable ideas. Algorithms and laws of nature (e.g. E=mc2) are examples of subject matter than cannot be patented.

Remember your secret sauce? You should not file a patent on this because as soon as you do it becomes publicly disclosed. Instead this is a trade secret which is information that derives independent economic value from not being generally known. A trade secret can be an algorithm that you have developed and resides in your codebase. In our bicycle example, the renting pricing algorithm is a trade secret.

4) Patent Trolls – As soon as you announce an acquisition or any other news that indicates your company is highly valued, someone is likely to file a lawsuit for patent infringement. Facebook was sued five times in the first two months alone after announcing they were going public. Microsoft recently introduced the “Live Tiles” feature as part of Windows 8. They are being sued by a small operating system company for allegedly stealing the patent on “tiles.” Such a lawsuit will tie up resources in your organization and run up legal fees. Make sure you prepare for this inevitable cost of doing business.

Obviously, none of this guarantees success with fund raising or getting acquired but these are items that we often see stop a process or delay it. Make sure you discuss all of this with your advisers, directors, and attorneys.

Over the past 16 years I have had a chance to work for more than 12 different bosses. While some have been better leaders than others I’ve tried to learn from each of them. Below are five leadership lessons that I’ve picked up from them and subsequently been able to use with my teams.

• Retain Talent – Go out of your way to retain your good people. Make it personal and include the family when possible. One of my star players shared with me that she had dinner plans with her husband for their anniversary. I called ahead to the restaurant and bought them a bottle of wine with the message “Happy Anniversary and thanks for all of your hard work.”
• Success Metrics – Use team success metrics to motivate your team and create a strong culture of driving to success rather than some arbitrary stopping point like a release. As we’ve written about before don’t confuse product releases with success. Identify and start to measure business metrics that the team can understand and rally around. Determine what to measure based on the drivers of revenue and cost of your business. Share these metrics with your organization and celebrate success and dig into areas where you are falling short to identify a get-well plan.
• Guiding Principles – Empower your team with guiding principles that help them to make day-to-day decisions. Similar to architectural principles, guiding principles empower your team or organization to make decisions on their own. Have the team help develop them and make them visible. Revisit them on a regular basis. This especially helps during times when you need to drive mindset change. You will be surprised at the questions and conversations that come up as you drive to calibrate on mindset shift.
• Poor Performers – Do not ignore your poor performers. Use these three axes to evaluate employees performance. If the problem is performance, attempt to help the employee by coaching and mentoring. If the problem is behavioral or if they don’t respond to coaching, you need to manage them out quickly. Depending on your organization, it may be difficult to manage poor performers out but this is not an excuse to ignore it. Poor performers can be a drag on the team, poor behaviors can be cancerous. And don’t forget they are a reflection of your work as well.
• Feedback – Give feedback to your team members frequently and in real time. Don’t wait until the annual review to give feedback. Gen Y and Millenniums are more accustomed to instant feedback and communication. That means you may have to adjust your style as you work to coach and guide your direct reports. Utilize all available communication medium to praise. Send them an email recognizing them for their actions and tie it to the positive impact it had on the business or the team. Leave them a voice mail. And of course the good old fashioned in person or one by one conversation works well. You will soon seen the positive motivation you inject into your team.
• Business Knowledge – Understand the business. The only way for you to be successful is to be able to speak and work with other business executives, which means you need to make the effort to understand their roles. Block off your calendar to sit with peers to see what they do on a day-to-day basis. The path to a CIO/CTO role is by being a great partner to the business.

Hopefully you can use some of these with your teams or at least make you aware that you should periodically look back for lessons learned. Often these lessons learned make great one-on-one topics for junior managers interested in improving their leadership.