From premature optimization to over-engineering solutions for your product, it\u2019s easy to get caught up in making technology decisions that slow you down instead of speeding you up.<\/p>\n
So when it comes to building your technical strategy, you need to assess each component in relation to what success will look like for your business.<\/p>\n
This post is an adaptation of a talk I recently gave at the Amazon Web Services (AWS) community day<\/a> event in Dublin about the technical strategies I\u2019ve experienced that don\u2019t work and the ones that have helped us to grow and scale at Intercom.<\/p>\n Many of these approaches are intended as reasonable defaults; they are my opinions, they aren’t rules, and they certainly won\u2019t fit every situation.<\/p>\n They\u2019re based on my experiences working in technology, the practical application of methods in varied use cases, and speaking with peers about their strategies and successes. Although they may seem like strong opinions, many of these tips echo the main tenets of software engineering: work with what you\u2019ve got, design solutions as needed, don\u2019t repeat yourself, and keep it simple, stupid! If you\u2019ve been paying attention to any loud marketing efforts over the last few years, you have definitely heard about multi-cloud. If you\u2019re unfamiliar with the term \u201cmulti-cloud<\/a>,\u201d it means deploying your application to a heterogeneous cloud-based platform spread across multiple cloud providers.<\/p>\n While that doesn\u2019t sound very bad, according to Corey Quinn, the world\u2019s most notorious Cloud Economist, it goes against best practices or “sensible defaults” and is \u201cthe worst practice to be avoided by default<\/a>.\u201d Corey works with his customers on reducing their AWS bills, and he\u2019s seen large numbers of cloud architectures in practice, so I think he\u2019s a pretty good source on this.<\/p>\n Even thinking about implementing a multi-cloud architecture is prematurely optimizing for practically all businesses \u2013 especially startups \u2013 and not a trap you want to fall into. Your company probably has enough problems worth solving that are far more valuable than any of the mythical benefits of multi-cloud deployment.<\/p>\n A common misconception is that a multi-cloud strategy will help you avoid vendor lock-in<\/a>, but this is mostly an illusion stemming from vague future business needs. It can also be a drain on resources, as abstracting away the value of any particular cloud provider is time-consuming and will hinder your ability to leverage the cloud for your business.<\/p>\n Look, there are situations where a multi-cloud strategy will be of benefit to you. Maybe you\u2019re Netflix or Apple<\/a> and own a large percentage of the total traffic of the internet? But for the rest of us? Pick one cloud provider and don\u2019t even think about moving workloads between them. Going all-in on one cloud provider is where the magic of cloud platforms comes to life: that is, ease of use, simplicity of the platform, and efficiency.<\/p>\n Don\u2019t use the best tools for the job. Sounds counterintuitive, right? In AWS, the best tool for a highly available key-value data access store is probably DynamoDB<\/a>, and the best tool for a bunch of time-series data is probably Timestream<\/a>. However, if you already have a fully operational MySQL Aurora installation in place, can\u2019t you just put the data there instead?<\/p>\n “You should optimize globally, and that means using the tools you\u2019re already using”<\/p><\/blockquote>\n Even in the cloud, adding new technology to your stack can be a distraction. You should optimize globally, and that means using the tools you\u2019re already using<\/a>. Don\u2019t add to your stack unless you\u2019re certain that your use case will not be satisfied by existing software.<\/p>\n At Intercom, we call this \u201cRun Less Software<\/a>,\u201d and it\u2019s part of our technical strategy of being technically conservative. We think it works for us, it\u2019s helped us avoid building and maintaining a lot of stuff that would have slowed us down over time.<\/p>\n Day one of your startup is probably not the time to be learning Kubernetes<\/a>. Maybe it is if you have a multi-year runway and significant infrastructure to build, or if you\u2019re in the infrastructure space selling to Kubernetes users. But unless you are already quite proficient at Kubernetes, the quickest way to get a service up and running is to use the most simple, flexible, and common building blocks available, such as a bunch of EC2 hosts in an autoscaling group behind a load-balancer.<\/p>\n At Intercom, we\u2019ve found success running Lambda<\/a> as glue code between AWS services. I think Lambda is an amazing piece of technology, but it has its place. It\u2019s great at performing simple tasks triggered by events, such as resizing images uploaded into an S3 bucket. I like to think of them as stored procedures for the cloud. But I would not like to run a large, complex application using Lambda as the limitations are significant, and areas like observability still don’t feel fully mature.<\/p>\n Written by a couple of ex-AWS engineers, the book The Good Parts of AWS <\/em><\/a>by Daniel Vassallo and Josh Pschorr is highly opinionated about which parts of AWS to use and includes a good discussion of Lambda. “We think Lambda is great\u2014definitely one of the good parts of AWS\u2014as long as you treat it as the simple code runner that it is. A problem we often see is that people If you think it\u2019s the right addition for your stack, use it for what it\u2019s good for \u2013 it\u2019s not, yet, a general-purpose computing platform, but it does work really well with many parts of the rest of the AWS ecosystem, and Lambda team are adding great features all the time.<\/p>\n Similar to Kubernetes, unless your team already has a lot of experience with microservices, most startups shouldn\u2019t go near them. Using microservices adds complexity, increases the things that can go wrong, and it\u2019s a lot more work to get many services set up well compared to one or two.<\/p>\n “Our teams wanted to build products, not maintain services”<\/p><\/blockquote>\n About 6 years ago at Intercom, we thought it was inevitable that significant new functionality should be developed as a standalone service. So we built new features like our webhook and event processing as small services that talked back to our Ruby on Rails monolith. But over time, we noticed that teams hated working on these services.<\/p>\n There was so much overhead and undifferentiated heavy lifting involved in maintaining these services, and adding new functionality seemed to take longer, compared to doing similar work in our majestic monolith<\/a>. Our teams wanted to build products, not maintain services. In the last few years, we\u2019ve been folding services back into our Ruby on Rails monolith. I suspect a similar experience could apply to many other service-orientated architectures.<\/p>\n I regret almost every time I configure something in the AWS Console. \u201cClick ops\u201d can be fast and effective, but the advantage of having a version-controlled, peer-reviewed definition of your infrastructure is significant. It doesn\u2019t matter much if you\u2019re using Cloudformation, Terraform, or higher level tools like AWS Cloud Development Toolkit. Anything is better than clicking around the AWS Console.<\/p>\n Most of the time, infrastructure defined in code or configuration is easier to maintain. Having infrastructure defined in code doesn\u2019t mean you need to make it complex though. Abstractions here using modules can be very powerful but can cause unexpected side effects, so I prefer to avoid DRYing<\/a> (Don\u2019t repeat yourself) things in favor of simple declarative instructions.<\/p>\n The cloud is a great place to build for scale<\/a>, but that doesn\u2019t mean you have to. In his 1968 book, The Art of Computer Programming<\/em><\/a>,<\/em> Donald Knuth noted that, \u201cPremature optimization is the root of all evil.\u201d<\/p>\n “Adding extreme scalability before it\u2019s really necessary easily leads you down the road of technical debt and other inefficiencies”<\/p><\/blockquote>\n Sure you get unfathomable scale at your fingertips by using the likes of S3, Amazon Simple Queue Service (SQS), and DynamoDB, and these days computers are really fast. But, as co-founder of Extreme Programme<\/a>, Ron Jeffries, <\/a>observed back in the days of XP, there\u2019s a high chance that, \u201cYou aren\u2019t gonna need it.\u201d Adding extreme scalability before it\u2019s really necessary easily leads you down the road of technical debt and other inefficiencies. You really can do a lot these days with a very small number of computers talking to a single database<\/a>.<\/p>\n Speaking of premature optimization: nobody likes to waste money, and there sure are many ways to waste money in the cloud. AWS billing and optimization is a hard problem, though it\u2019s getting easier thanks to vastly improved native tooling and new ways of purchasing capacity, like Savings Plans<\/a>.<\/p>\n I think it\u2019s best to be reactive with costs. Ship whatever it is you\u2019re building, then set a calendar reminder to check the costs later on down the line. It can be hard to predict exactly what something costs \u2013 like if you\u2019re building an entirely new service, how much effort is it going to take to figure out the related bandwidth charges, Aurora Storage IO, and Amazon Simple Queue Service (SQS) costs? These are not always easy to estimate.<\/p>\n I also find it\u2019s easy to \u201csnack\u201d on cost reduction projects. Removing a few unused Elastic IPs or EBS volumes can save a good few dollars per month, and it\u2019s so satisfying to clean things up. But will it really change the future outcome of your business? I sometimes try to justify these cleanups as making our infrastructure easier to understand, which can be a problem when you have a 9-year-old AWS account. But, most of the time, it\u2019s better to focus on big picture problems rather than snacking on small cost reductions.<\/p>\n Having said that, I do actually spend a good bit of my time optimizing costs at Intercom. For a mature business with a significant AWS spend and clear business requirements here, this is work that is definitely worth doing, with real business impacting outcomes. We’re certainly not alone in having achieved significant<\/a> improvements<\/a> in our bill through cost optimization.<\/p>\n Reading the engineering blogs of hugely successful companies that used to be startups, like Netflix, Uber, or Airbnb, is a great way to get completely distracted and over-engineer solutions to problems you probably don\u2019t yet have. Also, the information you really need from these successful companies typically isn\u2019t revealed in a blog or a conference talk. These things are usually artifacts of some engineer’s Objectives and Key Results (OKRs). Instead, look to peer relationships with engineers at similarly sized startups. In my experience, this can be really effective.<\/p>\n It\u2019s great to take inspiration from successful startups, but you absolutely should not be looking at enormous cloud providers like Amazon, Google, and Microsoft. Some companies may benefit from a monorepo, five-nines availability, microservices, or site reliability engineering (SRE). But these are mostly solving problems that huge organizations have. Instead of a startup worrying about, say, their chaos engineering strategy, it\u2019s best to build entirely on a small set of well-understood managed services with great redundancy built in, where somebody else is worrying about how to use chaos engineering to improve their managed service.<\/p>\n One surefire terrible technical strategy for your startup is to do whatever you hear at a conference. Only you can understand your business context and technical challenges. The differences between core competencies and undifferentiated heavy lifting isn\u2019t always clear cut. There are myriad human factors to take into account when defining and implementing a technical strategy. So don\u2019t blindly do any of these things. They\u2019re just my honest opinions, and they\u2019re what work for me in my current role. Now that we\u2019ve reviewed the bad, and the downright ugly of technical strategies, it\u2019s time to turn our attention to the good. Here are five effective best practices that can create long-term positive impacts:<\/p>\n Security is job number zero of, well, anything on the internet these days. Not only are consumer expectations higher than ever, regulations like GDPR<\/a> require a reasonable level of security built into your product.<\/p>\n “Burning customers through security problems is a sure way to lose customer confidence”<\/p><\/blockquote>\n Burning customers through security problems is a sure way to lose customer confidence. I\u2019ve been on both sides of this and it is real. Building security in every product and feature you build from day zero is way easier than adding it afterwards. As your startup moves upmarket, the conversations with larger purchasers will become more detailed and require more rigor in your product. Thankfully this is easier than ever to do with good secure options in the cloud, and constant improvements like those around S3 bucket configuration that can prevent you from running into classic problems while using the cloud.<\/p>\n At Intercom, we say that \u201cShipping is your company\u2019s heartbeat<\/a>.\u201d I don\u2019t think it\u2019s a coincidence that companies that focus on shipping are successful. In fact, this has been shown to be the case with a great deal of rigor.<\/p>\n I consider Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations<\/a> <\/em>by Nicole Forsgren, Jez Humble, and Gene Kim to be the bible of high-performance technology organizations. The authors applied research methods to discovering best practices used in real companies to be successful. If you care about your organization\u2019s success, no matter what the industry, the knowledge in this book will help you a lot.<\/p>\n Ideally, you\u2019ll aim to hire generalists who really want to grow. The growth mindset alone encourages growth, and boy are you going to need it in a fast-growing environment. SMEs or specialists offer seductive productivity, but ultimately they might turn into silos that can slow you down, limiting advantages of collaboration and team-owned problems.<\/p>\n “If you do hire people with deep expertise, you should ensure they are set up to share that expertise to help develop your team”<\/p><\/blockquote>\n<\/blockquote>\n You won\u2019t get the best solution if the entire team can\u2019t work on your biggest problems. You want people to grow towards owning and deeply understanding your organization\u2019s main problems \u2013 rather than being siloed by gatekeepers. If you do hire people with deep expertise<\/a>, you should ensure they are set up to share that expertise to help develop your team.<\/p>\n As I\u2019ve mentioned, it\u2019s wise to pick a small number of well-understood services to use. Elasticache, SQS, and Amazon Relational Database Service (RDS) are far better defaults to use instead of using your own Memcached, RabbitMQ, or self-run clustered MySQL setup.<\/p>\n Similarly, I think some of the managed cloud security and AI\/ML services are looking really great, and I\u2019d kick the tyres of them before building something along the same lines. When you do need to solve some problems that go beyond your current tech stack, I\u2019d recommend that you first avoid building anything and simply use something that\u2019s available in your existing cloud provider.<\/p>\n Is this a clich\u00e9? No \u2013 if you actually put this into practice, this means world-class observability, monitoring, operational best practices, good uptime, performance, and solid security.<\/p>\n I think Jeff Bezos was on the right track when he talked about always working backwards<\/a> from the customer. I first learned this while working at Amazon, and it\u2019s truer than ever working at Intercom. If you don\u2019t know what your customers are doing, experiencing, and thinking, you are not focused on them. Great tools like Intercom<\/a> and Honeycomb<\/a> can definitely help you out a lot to understand your customers.<\/p>\n\n","protected":false},"excerpt":{"rendered":" From premature optimization to over-engineering solutions for your product, it\u2019s easy to get caught up making technology decisions that slow you down instead of speeding you up.<\/p>\n","protected":false},"author":105,"featured_media":25202,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"category":[12898],"tags":[644,335,146,524,251],"coauthors":[399],"class_list":["post-25200","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-engineering","tag-aws","tag-engineering","tag-recruitment","tag-scaling","tag-software-development"],"yoast_head":"\n
\n<\/a><\/p>\nThe top ten technical strategies to avoid<\/span><\/h2>\n
1. Multi-cloud architectures<\/h3>\n
2. Adopting the \u201cbest tools\u201d<\/h3>\n
3. Containers vs. serverless host environments<\/h3>\n
\nsometimes mistake Lambda for a general-purpose application host.”<\/p>\n4. Microservices cause undifferentiated heavy lifting<\/h3>\n
5. Configuring the AWS Console<\/h3>\n
6. Building for scale<\/h3>\n
7. Optimizing costs<\/h3>\n
8. Copying hugely successful companies<\/h3>\n
9. Copying hyperscalers<\/h3>\n
10. Listening to me<\/h3>\n
\n<\/a><\/p>\nTop 5 technical strategies to follow<\/h2>\n
1. Build in security<\/h3>\n
2. Ship, a lot<\/h3>\n
3. Hire for potential<\/h3>\n
\n
4. Bias towards high-level services<\/h3>\n
5. Focus on the customer<\/h3>\n
![The Art of Computer Programming<\/em><\/a>,<\/em> Donald Knuth noted that, \u201cPremature optimization is the root of all evil.\u201d<\/p>\n“Adding extreme scalability before it\u2019s really necessary easily leads you down the road of technical debt and other inefficiencies”<\/p><\/blockquote>\nSure you get unfathomable scale at your fingertips by using the likes of S3, Amazon Simple Queue Service (SQS), and DynamoDB, and these days computers are really fast. But, as co-founder of Extreme Programme<\/a>, Ron Jeffries, <\/a>observed back in the days of XP, there\u2019s a high chance that, \u201cYou aren\u2019t gonna need it.\u201d Adding extreme scalability before it\u2019s really necessary easily leads you down the road of technical debt and other inefficiencies. You really can do a lot these days with a very small number of computers talking to a single database<\/a>.<\/p>\n7. Optimizing costs<\/h3>\nSpeaking of premature optimization: nobody likes to waste money, and there sure are many ways to waste money in the cloud. AWS billing and optimization is a hard problem, though it\u2019s getting easier thanks to vastly improved native tooling and new ways of purchasing capacity, like Savings Plans<\/a>.<\/p>\nI think it\u2019s best to be reactive with costs. Ship whatever it is you\u2019re building, then set a calendar reminder to check the costs later on down the line. It can be hard to predict exactly what something costs \u2013 like if you\u2019re building an entirely new service, how much effort is it going to take to figure out the related bandwidth charges, Aurora Storage IO, and Amazon Simple Queue Service (SQS) costs? These are not always easy to estimate.<\/p>\nI also find it\u2019s easy to \u201csnack\u201d on cost reduction projects. Removing a few unused Elastic IPs or EBS volumes can save a good few dollars per month, and it\u2019s so satisfying to clean things up. But will it really change the future outcome of your business? I sometimes try to justify these cleanups as making our infrastructure easier to understand, which can be a problem when you have a 9-year-old AWS account. But, most of the time, it\u2019s better to focus on big picture problems rather than snacking on small cost reductions.<\/p>\nHaving said that, I do actually spend a good bit of my time optimizing costs at Intercom. For a mature business with a significant AWS spend and clear business requirements here, this is work that is definitely worth doing, with real business impacting outcomes. We’re certainly not alone in having achieved significant<\/a> improvements<\/a> in our bill through cost optimization.<\/p>\n8. Copying hugely successful companies<\/h3>\nReading the engineering blogs of hugely successful companies that used to be startups, like Netflix, Uber, or Airbnb, is a great way to get completely distracted and over-engineer solutions to problems you probably don\u2019t yet have. Also, the information you really need from these successful companies typically isn\u2019t revealed in a blog or a conference talk. These things are usually artifacts of some engineer’s Objectives and Key Results (OKRs). Instead, look to peer relationships with engineers at similarly sized startups. In my experience, this can be really effective.<\/p>\n9. Copying hyperscalers<\/h3>\nIt\u2019s great to take inspiration from successful startups, but you absolutely should not be looking at enormous cloud providers like Amazon, Google, and Microsoft. Some companies may benefit from a monorepo, five-nines availability, microservices, or site reliability engineering (SRE). But these are mostly solving problems that huge organizations have. Instead of a startup worrying about, say, their chaos engineering strategy, it\u2019s best to build entirely on a small set of well-understood managed services with great redundancy built in, where somebody else is worrying about how to use chaos engineering to improve their managed service.<\/p>\n10. Listening to me<\/h3>\nOne surefire terrible technical strategy for your startup is to do whatever you hear at a conference. Only you can understand your business context and technical challenges. The differences between core competencies and undifferentiated heavy lifting isn\u2019t always clear cut. There are myriad human factors to take into account when defining and implementing a technical strategy. So don\u2019t blindly do any of these things. They\u2019re just my honest opinions, and they\u2019re what work for me in my current role.\n<\/a><\/p>\nTop 5 technical strategies to follow<\/h2>\nNow that we\u2019ve reviewed the bad, and the downright ugly of technical strategies, it\u2019s time to turn our attention to the good. Here are five effective best practices that can create long-term positive impacts:<\/p>\n1. Build in security<\/h3>\nSecurity is job number zero of, well, anything on the internet these days. Not only are consumer expectations higher than ever, regulations like GDPR<\/a> require a reasonable level of security built into your product.<\/p>\n“Burning customers through security problems is a sure way to lose customer confidence”<\/p><\/blockquote>\nBurning customers through security problems is a sure way to lose customer confidence. I\u2019ve been on both sides of this and it is real. Building security in every product and feature you build from day zero is way easier than adding it afterwards. As your startup moves upmarket, the conversations with larger purchasers will become more detailed and require more rigor in your product. Thankfully this is easier than ever to do with good secure options in the cloud, and constant improvements like those around S3 bucket configuration that can prevent you from running into classic problems while using the cloud.<\/p>\n2. Ship, a lot<\/h3>\nAt Intercom, we say that \u201cShipping is your company\u2019s heartbeat<\/a>.\u201d I don\u2019t think it\u2019s a coincidence that companies that focus on shipping are successful. In fact, this has been shown to be the case with a great deal of rigor.<\/p>\nI consider Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations<\/a> <\/em>by Nicole Forsgren, Jez Humble, and Gene Kim to be the bible of high-performance technology organizations. The authors applied research methods to discovering best practices used in real companies to be successful. If you care about your organization\u2019s success, no matter what the industry, the knowledge in this book will help you a lot.<\/p>\n3. Hire for potential<\/h3>\nIdeally, you\u2019ll aim to hire generalists who really want to grow. The growth mindset alone encourages growth, and boy are you going to need it in a fast-growing environment. SMEs or specialists offer seductive productivity, but ultimately they might turn into silos that can slow you down, limiting advantages of collaboration and team-owned problems.<\/p>\n\n“If you do hire people with deep expertise, you should ensure they are set up to share that expertise to help develop your team”<\/p><\/blockquote>\n<\/blockquote>\nYou won\u2019t get the best solution if the entire team can\u2019t work on your biggest problems. You want people to grow towards owning and deeply understanding your organization\u2019s main problems \u2013 rather than being siloed by gatekeepers. If you do hire people with deep expertise<\/a>, you should ensure they are set up to share that expertise to help develop your team.<\/p>\n4. Bias towards high-level services<\/h3>\nAs I\u2019ve mentioned, it\u2019s wise to pick a small number of well-understood services to use. Elasticache, SQS, and Amazon Relational Database Service (RDS) are far better defaults to use instead of using your own Memcached, RabbitMQ, or self-run clustered MySQL setup.<\/p>\nSimilarly, I think some of the managed cloud security and AI\/ML services are looking really great, and I\u2019d kick the tyres of them before building something along the same lines. When you do need to solve some problems that go beyond your current tech stack, I\u2019d recommend that you first avoid building anything and simply use something that\u2019s available in your existing cloud provider.<\/p>\n5. Focus on the customer<\/h3>\nIs this a clich\u00e9? No \u2013 if you actually put this into practice, this means world-class observability, monitoring, operational best practices, good uptime, performance, and solid security.<\/p>\nI think Jeff Bezos was on the right track when he talked about always working backwards<\/a> from the customer. I first learned this while working at Amazon, and it\u2019s truer than ever working at Intercom. If you don\u2019t know what your customers are doing, experiencing, and thinking, you are not focused on them. Great tools like Intercom<\/a> and Honeycomb<\/a> can definitely help you out a lot to understand your customers.<\/p>\n\n","protected":false},"excerpt":{"rendered":"From premature optimization to over-engineering solutions for your product, it\u2019s easy to get caught up making technology decisions that slow you down instead of speeding you up.<\/p>\n","protected":false},"author":105,"featured_media":25202,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"category":[12898],"tags":[644,335,146,524,251],"coauthors":[399],"class_list":["post-25200","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-engineering","tag-aws","tag-engineering","tag-recruitment","tag-scaling","tag-software-development"],"yoast_head":"\n10 technical strategies to avoid when scaling your startup (and 5 to embrace) - The Intercom Blog<\/title>\n<meta name=\"description\" content=\"When building your technical strategy, you need to assess each component in relation to what success will look like for your business.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"10 technical strategies to avoid when scaling your startup (and 5 to embrace)\" \/>\n<meta property=\"og:description\" content=\"When building your technical strategy, you need to assess each component in relation to what success will look like for your business.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/\" \/>\n<meta property=\"og:site_name\" content=\"The Intercom Blog\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/intercominc\" \/>\n<meta property=\"article:published_time\" content=\"2021-01-12T15:09:48+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-12-01T22:19:27+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/Final_Bad_Tech_Strategies_BIG_shrinkn-scaled.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"2560\" \/>\n\t<meta property=\"og:image:height\" content=\"1198\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Brian Scanlan\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@brian_scanlan\" \/>\n<meta name=\"twitter:site\" content=\"@intercom\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Brian Scanlan\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"12 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\\\/\"},\"author\":{\"name\":\"Brian Scanlan\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#\\\/schema\\\/person\\\/b1709ce5dd599e9a343f018820261df2\"},\"headline\":\"10 technical strategies to avoid when scaling your startup (and 5 to embrace)\",\"datePublished\":\"2021-01-12T15:09:48+00:00\",\"dateModified\":\"2023-12-01T22:19:27+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\\\/\"},\"wordCount\":2708,\"publisher\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2021\\\/01\\\/Final_Bad_Tech_Strategies_BIG_shrinkn-scaled.jpg\",\"keywords\":[\"AWS\",\"Engineering\",\"recruitment\",\"scaling\",\"software development\"],\"articleSection\":[\"Engineering\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\\\/\",\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\\\/\",\"name\":\"10 technical strategies to avoid when scaling your startup (and 5 to embrace) - The Intercom Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2021\\\/01\\\/Final_Bad_Tech_Strategies_BIG_shrinkn-scaled.jpg\",\"datePublished\":\"2021-01-12T15:09:48+00:00\",\"dateModified\":\"2023-12-01T22:19:27+00:00\",\"description\":\"When building your technical strategy, you need to assess each component in relation to what success will look like for your business.\",\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.intercom.com\\\/blog\\\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2021\\\/01\\\/Final_Bad_Tech_Strategies_BIG_shrinkn-scaled.jpg\",\"contentUrl\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2021\\\/01\\\/Final_Bad_Tech_Strategies_BIG_shrinkn-scaled.jpg\",\"width\":2560,\"height\":1198,\"caption\":\"Ten bad technical strategies and five ones to embrace\"},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/\",\"name\":\"The Intercom Blog\",\"description\":\"Articles and Podcasts on Customer Service, AI and Automation, Product, and more\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#organization\",\"name\":\"The Intercom Blog\",\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/08\\\/Intercom-logo-sq-black-trans.png\",\"contentUrl\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/wp-content\\\/uploads\\\/2019\\\/08\\\/Intercom-logo-sq-black-trans.png\",\"width\":1000,\"height\":1000,\"caption\":\"The Intercom Blog\"},\"image\":{\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/intercominc\",\"https:\\\/\\\/x.com\\\/intercom\",\"https:\\\/\\\/www.instagram.com\\\/intercom\\\/\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/2491343\",\"https:\\\/\\\/www.pinterest.ie\\\/intercom\\\/\",\"https:\\\/\\\/www.youtube.com\\\/channel\\\/UCJG0MvLP03kyzzAkD-w98aQ\",\"https:\\\/\\\/en.wikipedia.org\\\/wiki\\\/Intercom_(company)\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/#\\\/schema\\\/person\\\/b1709ce5dd599e9a343f018820261df2\",\"name\":\"Brian Scanlan\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/557ac9be8a2b4e8abd5ff0d77470ded5591d3b056dedb68cbde898233ef5170e?s=96&d=mm&r=pg97554399c095ae58633cba361b67ea03\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/557ac9be8a2b4e8abd5ff0d77470ded5591d3b056dedb68cbde898233ef5170e?s=96&d=mm&r=pg\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/557ac9be8a2b4e8abd5ff0d77470ded5591d3b056dedb68cbde898233ef5170e?s=96&d=mm&r=pg\",\"caption\":\"Brian Scanlan\"},\"description\":\"Brian leads Intercom's developer infrastructure efforts, helping teams make products resilient to failure and scalable to customers' needs. Formerly with HEAnet and Amazon.\",\"sameAs\":[\"https:\\\/\\\/www.linkedin.com\\\/in\\\/scanlanb\\\/\",\"https:\\\/\\\/x.com\\\/brian_scanlan\"],\"url\":\"https:\\\/\\\/www.intercom.com\\\/blog\\\/author\\\/brian_scanlan\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"10 technical strategies to avoid when scaling your startup (and 5 to embrace) - The Intercom Blog","description":"When building your technical strategy, you need to assess each component in relation to what success will look like for your business.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/","og_locale":"en_US","og_type":"article","og_title":"10 technical strategies to avoid when scaling your startup (and 5 to embrace)","og_description":"When building your technical strategy, you need to assess each component in relation to what success will look like for your business.","og_url":"https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/","og_site_name":"The Intercom Blog","article_publisher":"https:\/\/www.facebook.com\/intercominc","article_published_time":"2021-01-12T15:09:48+00:00","article_modified_time":"2023-12-01T22:19:27+00:00","og_image":[{"width":2560,"height":1198,"url":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/Final_Bad_Tech_Strategies_BIG_shrinkn-scaled.jpg","type":"image\/jpeg"}],"author":"Brian Scanlan","twitter_card":"summary_large_image","twitter_creator":"@brian_scanlan","twitter_site":"@intercom","twitter_misc":{"Written by":"Brian Scanlan","Est. reading time":"12 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/#article","isPartOf":{"@id":"https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/"},"author":{"name":"Brian Scanlan","@id":"https:\/\/www.intercom.com\/blog\/#\/schema\/person\/b1709ce5dd599e9a343f018820261df2"},"headline":"10 technical strategies to avoid when scaling your startup (and 5 to embrace)","datePublished":"2021-01-12T15:09:48+00:00","dateModified":"2023-12-01T22:19:27+00:00","mainEntityOfPage":{"@id":"https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/"},"wordCount":2708,"publisher":{"@id":"https:\/\/www.intercom.com\/blog\/#organization"},"image":{"@id":"https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/#primaryimage"},"thumbnailUrl":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/Final_Bad_Tech_Strategies_BIG_shrinkn-scaled.jpg","keywords":["AWS","Engineering","recruitment","scaling","software development"],"articleSection":["Engineering"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/","url":"https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/","name":"10 technical strategies to avoid when scaling your startup (and 5 to embrace) - The Intercom Blog","isPartOf":{"@id":"https:\/\/www.intercom.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/#primaryimage"},"image":{"@id":"https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/#primaryimage"},"thumbnailUrl":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/Final_Bad_Tech_Strategies_BIG_shrinkn-scaled.jpg","datePublished":"2021-01-12T15:09:48+00:00","dateModified":"2023-12-01T22:19:27+00:00","description":"When building your technical strategy, you need to assess each component in relation to what success will look like for your business.","inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.intercom.com\/blog\/ten-technical-strategies-to-avoid-when-scaling-your-startup-and-five-to-embrace\/#primaryimage","url":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/Final_Bad_Tech_Strategies_BIG_shrinkn-scaled.jpg","contentUrl":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/Final_Bad_Tech_Strategies_BIG_shrinkn-scaled.jpg","width":2560,"height":1198,"caption":"Ten bad technical strategies and five ones to embrace"},{"@type":"WebSite","@id":"https:\/\/www.intercom.com\/blog\/#website","url":"https:\/\/www.intercom.com\/blog\/","name":"The Intercom Blog","description":"Articles and Podcasts on Customer Service, AI and Automation, Product, and more","publisher":{"@id":"https:\/\/www.intercom.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.intercom.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.intercom.com\/blog\/#organization","name":"The Intercom Blog","url":"https:\/\/www.intercom.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.intercom.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2019\/08\/Intercom-logo-sq-black-trans.png","contentUrl":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2019\/08\/Intercom-logo-sq-black-trans.png","width":1000,"height":1000,"caption":"The Intercom Blog"},"image":{"@id":"https:\/\/www.intercom.com\/blog\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/intercominc","https:\/\/x.com\/intercom","https:\/\/www.instagram.com\/intercom\/","https:\/\/www.linkedin.com\/company\/2491343","https:\/\/www.pinterest.ie\/intercom\/","https:\/\/www.youtube.com\/channel\/UCJG0MvLP03kyzzAkD-w98aQ","https:\/\/en.wikipedia.org\/wiki\/Intercom_(company)"]},{"@type":"Person","@id":"https:\/\/www.intercom.com\/blog\/#\/schema\/person\/b1709ce5dd599e9a343f018820261df2","name":"Brian Scanlan","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/557ac9be8a2b4e8abd5ff0d77470ded5591d3b056dedb68cbde898233ef5170e?s=96&d=mm&r=pg97554399c095ae58633cba361b67ea03","url":"https:\/\/secure.gravatar.com\/avatar\/557ac9be8a2b4e8abd5ff0d77470ded5591d3b056dedb68cbde898233ef5170e?s=96&d=mm&r=pg","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/557ac9be8a2b4e8abd5ff0d77470ded5591d3b056dedb68cbde898233ef5170e?s=96&d=mm&r=pg","caption":"Brian Scanlan"},"description":"Brian leads Intercom's developer infrastructure efforts, helping teams make products resilient to failure and scalable to customers' needs. Formerly with HEAnet and Amazon.","sameAs":["https:\/\/www.linkedin.com\/in\/scanlanb\/","https:\/\/x.com\/brian_scanlan"],"url":"https:\/\/www.intercom.com\/blog\/author\/brian_scanlan\/"}]}},"jetpack_featured_media_url":"https:\/\/www.intercom.com\/blog\/wp-content\/uploads\/2021\/01\/Final_Bad_Tech_Strategies_BIG_shrinkn-scaled.jpg","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/posts\/25200","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/users\/105"}],"replies":[{"embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/comments?post=25200"}],"version-history":[{"count":0,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/posts\/25200\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/media\/25202"}],"wp:attachment":[{"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/media?parent=25200"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/category?post=25200"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/tags?post=25200"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.intercom.com\/blog\/wp-json\/wp\/v2\/coauthors?post=25200"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}](\"https:\/\/en.wikipedia.org\/wiki\/File:ArtOfComputerProgramming.jpg\"){kind=link}