SaaSCo is six years old, heavily capitalized, and perpetually "6 months away from profitability". They have a decent product that's marketed well. Steve has overseen the growth of the product and engineering team from 3 to 30. The product lives on a monolith written in something mature and boring, like PHP, Python, or Ruby.

SaaSCo's product has a huge footprint. The important parts are mature and work well. There's a good deal of debt in the codebase. Ever since the front-end shifted to React a few years ago big parts of the legacy codebase are being deprecated.

The engineering team seems antsy. Deadlines are rarely hit. The product is just too big and complex. Changes often have unintended consequences. Somebody's always refactoring something, and internal documentation is essentially worthless.

Steve has heard the microservices success stories, and so have the engineering team. They're eager to try it. Many of them feel that the Python backend is boring, and they're itching to work with new technologies.

Steve decides to start the long and arduous process of converting the monolith to microservices. It'll be a big undertaking, but it'll all be worth it because of the increased velocity we'll have afterwards.

So SaaSCo engineering starts methodically breaking things out into microservices. First they remove image processing and replace it with an IMagick-based microservice. Then comes the Spamassassin service, and then the stats-processor service. This all goes pretty smoothly. Those services were already on the fringes of the monolith, and separated easily. Note that the team is now supporting four service deployments.

Next they try breaking authentication out into a microservice. This is tougher and scarier than planned, but it works out. Encouraged, they start breaking out more core services into microservices.

But then they hit a wall. They quickly discover that the microservices are all talking to each other constantly, and have hidden dependencies they didn't notice during planning. The legacy monolith is still running, albeit in a crippled mode, and has become a sort of service router for the app. Steve decides to pump the brakes on the aggressive microservice-ization in order to stabilize a bit. The solution is to build shared support libraries that help microservices interface with one another. There is also now a microservices style guide that specifies which languages and libraries should be used, in order for the majority of the team to be able to support the majority of the services. This, of course, makes the engineering team upset because a few of them really wanted to use Elixir in one of the services.

Steve now has a lot more problems than the monolith, which, by the way, never fully goes away. Instead of a monolith, Steve now has a dozen different services built by different people using a patchwork of different technologies, libraries, and API conventions.

The development velocity does not actually improve after shifting to microservices. Years go by in this state of microservices purgatory, and then with SaaSCo v4.0 the team proudly announces that they're going back to a monolithic model, except now with a new shiny framework!

I think the moral of the story goes something like this: Steve didn't have a services problem, he had a complexity problem. Moving to microservices does not necessarily solve complexity problems. Instead of focusing on the "DevOps" layer and topology, Steve should have started with an even more abstract view of what the system components are and where the complexities lie. The simple truth is that complex things are hard, and most successful business platforms are complex. And it turns out that teams of engineers are not typically experts at highly-complex system design, and so most will reach for solutions that sound right but don't actually address the root problem.

I'm not claiming that microservices aren't useful or a solid design patterm. I'm just saying that I've seen a lot of CTOs reach for the microservices hammer when they really needed a more subtle tool. In most cases I've observed personally, a much better approach is to reorganize your monolith into a shared-library model. Monoliths by themselves aren't evil. Microservices by themselves aren't good.

I would go even further and offer this rule of thumb: one should not convert a mature monolith to microservices. The move from monolith to microservices, for a sufficiently complex platform, is very expensive and fraught with peril. It's a large jump: microservices is not just one step away from monolith. The more complex a platform is, the more inertia it has, and the tougher it'll be to move that large distance towards a replatform. Moving straight to microservices in this case is like trying to stop a boulder in its path; whereas a subtle refactoring to a shared-library model is more like nudging the boulder so that it doesn't crash into the village below.

By the numbers: In my career I've personally observed maybe 20 examples of CTOs choosing microservices. Of the fresh, green-field platforms that choose microservices, 8 of 10 are successful. However, of the mature platforms that decided to rearchitect to microservices, I've only seen one company actually pull it off to completion. In other words, I've observed a 90% failure rate in large monoliths successfully and completely moving to microservices. The rest have ended up in a state of purgatory, or have rolled back their efforts.

So this is my caution against microservices: if Steve's story feels all-too-familiar to you, please think twice before trying to step in front of the boulder.

Lots of considerations factor in to the debate, but those are out-of-scope for this article. For now, let's assume you've decided to buy. What's the best way to proceed?

I claim that the most common pattern is actually an anti-pattern. It goes like this:

Manager: I've researched 10 options for the best Widget, and found that WidgetizerX is the best tool. I'll buy it now. Please implement it into the product.

Engineering Team: [Implements WidgetizerX into the product]

On the upside, this process is fast and does achieve the product goal. Unfortunately, it introduces tremendous technical debt. The implementation introduces a tight coupling between a third party service and your product.

If WidgetizerX goes out of business, or a better option appears in the future, or the decision to bring the functionality in-house is eventually made, the engineering team will either have to clear the technical debt first (by decoupling the implementation) or re-finance the debt (by way of a drop-in replacement) potentially at less favorable terms.

Here's the way it should go:

Manager: I've researched 10 options for the best Widget and decided on WidgetizerX. My next two choices were Windowmuxer and Panelista. I am most interested in features X, Y, and Z.

Engineering Team: [Researches APIs for all three, designs a lightweight abstraction layer for the functionality, implements a WidgetizerX driver]

Yes, this does slightly increase the cost of implementation. One could argue that the decision to buy was made in order to achieve the lowest possible implementation cost, and so spending the extra time to design an abstraction layer is stupid. My rebuttal is that a little bit of extra capital can eliminate a long-term interest-accruing debt.

Besides, it's comparatively cheap to do this. If an in-house implementation would take 3 months, and a drop-in implementation would only take a day, it's not that big a deal to spend two days on a driver- or adapter- based implementation. You've still saved 3 months in either case.

The adapter layer doesn't need to be complex; it just needs to support the common functionality of the different backends. If we're talking third party APIs, this layer might be as simple as an interface that defines authorization methods and the hooks and events that your application will tie into. Then you write an adapter around WidgetizerX and implement that.

My favorite software design principle is that of appropriate abstractions – "put things where they belong". When you buy a technology, it simply doesn't belong in a place where your product or business closely relies on it. It belongs a degree of abstraction away – behind a driver or adapter layer or something similar. Not implementing it that way will therefore accrue debt or cause other problems down the line.

I find that using this approach is worthwhile most of the time – that is, in most real-life cases, probably 80% of 'buy' technologies need to be replaced over the long term. Functionality moves in-house, or a different vendor is chosen, or the need to support multiple vendors arises. Sometimes you never need to use your adapter layer – maybe you stay on AWS S3 for file storage forever – but most of the time it pays off. Sometimes you get the adapter layer wrong and that introduces a different kind of debt, but teams get better at this with practice.

So if you do decide to buy, the best advice I can give you is to buy like you'd build: with research, a design step, and an implementation at the appropriate degree of abstraction.

Here's a piece of startup founder advice that's sure to be controversial: don't overinvest in engineering.

I find myself giving this advice more and more often, especially as available capital in the NYC startup market has grown substantially over the last decade or so.

I'm a CTO, an engineer, and a founder, and I love investing in engineering. So I want to be clear: I'm not saying not to invest in engineering. I'm just saying don't over-invest in engineering.

Put another way: you must invest in engineering. But I've seen too many good companies and good founders fail because they've over-invested in engineering.

I'm sure you can come up with dozens of counterexamples and ways this advice can fail you. As long as this article gets you really thinking critically about how much your company in your circumstances should be investing in engineering, I'm happy.

If you build it, they won't come.

I've seen many founders wait until their v1.0/prototype/MVP is launched before starting to hit the pavement and sell. The 1.0 launch is seen as an inflection point: "Time to start selling!". But if you weren't selling beforehand, how do you know what to build? And how do you know how to sell it?

I've also seen many companies build their initial product and engineering team long before they even think of building a sales team. Just as your engineering team is using these early days to learn how to work together and develop the initial product and organizational framework, you should have some semblance of a sales team learning how to do the same.

Many early stage startups will have a CTO and an engineer or two building the prototype, while the CEO is going out and selling solo. The problem here is that it takes time and effort for a sales team to build their materials and relationships, so the company will end up with a full quarter or two where the sales team just hasn't hit their stride enough in order to provide the crucial early product and sales feedback.

At a four-person startup: instead of CTO + 2 engineers and a CEO solo, try CTO + 1 engineer and CEO + 1 salesperson.

Your engineering team, while necessary, simply won't bring you customers, users, or revenue at any scale necessary to build a lasting company. Your product won't magically get customers because of its virtues.

You don't actually need strong technical foundations.

Your early technical foundations may be valuable in some regards, but not nearly as valuable as figuring out a) who your target market actually is, b) learning how to sell to them c) figuring out what pivots are necessary to the product.

Your early technical foundations may even end up being not valuable at all, depending on what you learn in the early days and if you end up piviting your product.

What you need is a strong sales foundation. Yes, even at an early stage. Don't wait for a v1.0 to start getting salespeople in front of customers. Learn what your customers' needs are, learn how to find them, learn how to pitch to them, learn how to close sales.

The engineering team doesn't do that work: the sales and marketing team does. Odds are your early technology is going to be totally unrecognizable in a year or two anyway!

Don't overengineer the technology. You most likely don't need strong technical foundations. You need strong sales and marketing foundations.

You don't need to build a great, award-winning, delightful product.

The best way to burn your entire budget is to try and design the best possible product. A lot of product teams believe that their product needs to deliver a "delightful experience", that it needs to outclass its competitors in every regard, and that no compromises can be made.

If you can afford to build a best-in-class product, that's great. No early-stage startups can afford that, however. Your goal should be much more attainable: your product simply needs to deliver on its promises. That's it. Do not (yet) strive to "exceed expectations". Just strive to meet them.

There was a massive study done on the performance of customer service teams in the book "The Effortless Experience". One of the study's conclusions is that "exceeding expectations" is a) generally unattainable for 90% of companies and b) has no actual impact on customer loyalty, the metric that matters. They found that there is no difference in loyalty between simply meeting expectations
versus exceeding them.

It's true that the above study applies to customer service experience and not product experience, but I'm extrapolating to product just the same.

Build a product that simply delivers on its promises. No more, no less.

A larger engineering team will only do more engineering.

A larger product and engineering team won't necessarily build a better product -- in the eyes of your customers.

They'll build a bigger product, more features, and more technology. They'll build to a higher degree of tolerance. They'll do more engineering. They might build a better product by every internal measure. Those things sound great, but are actually another trap.

Similar to the "exceeding expectations" trap, a larger product and engineering team will only build a better product -- in the eyes of customers -- 10% of the time. Don't invest in those odds.

Most well-staffed engineering teams want to build the software equivalent of a McLaren F1: a beautiful, finely tuned, handcrafted vehicle. Every piece custom built and machined. But if you build a McLaren, it'll cost a million dollars to produce and you'll only sell 100 of them. What you really want to build is a Toyota -- something that meets expectations and reliably delivers on its promises. Just that modest goal is incredibly difficult to achieve, so start there!

Another apropos example is the Juicero juicer. The device was overengineered to the nth degree, and the company almost certainly lost hundreds of dollars on every unit sold.

Because your engineering department is a cost center, you should fund it only to the level that it needs to build a product that meets expectations.

Founders should not run teams in proportion to their ownership.

I think another easy trap to fall into is brought on by the two-founder CEO/CTO model. When two founders split ownership equally it's tempting to feel that each founder should run roughly equivalently sized teams. The company ends up being a 50/50 split of sales/ops and product/engineering, and I've even see this happen at companies with 30+ employees.

Once a company has more than a handful of employees, however, that 50/50 ratio doesn't make much sense. Sales, marketing, operations, and customer support (ie, the "non-tech" side) should begin to outgrow the technical side (product and engineering) relatively early on.

Equal founders want to feel like they have an equal level of responsibility within the company, and often see the number of employees under management as a measure of that responsibility. It isn't.

If you're a founder/CTO, don't forget: you're a founder first. Yes, the bulk of your focus will be on product and engineering, but don't let that be all of your focus. Figure out how you can use your skills to enable the sales, marketing, ops, and support teams. If you're a founder first, you should be doing what the company needs most, not necessarily what you like doing best. Your value and responsibilities don't come from simply managing a headcount, so don't use that as a vanity metric.

Your most important job as a CTO is to figure out how to run a lean team successfully.

Figuring out how to achieve your product's goals with the minimum resources necessary is your biggest responsibility, and your biggest challenge. You should be doing everything in your power to allow your company to invest as much as it possibly can in developing sales, marketing, customer relationships, and customer loyalty: the profit centers of your company.

Get your company to profitability, and then revisit your organizational goals. If, after profitability, you still want growth, then keep investing in sales. If you want polish, then invest a little more in engineering. But until you've reached financial stability, keep your cost centers in check, and make sure not to overinvest in engineering.

I'm well aware the advice above will be controversial to some degree. But I've seen dozens of companies fail because of misallocated team investment. I know many really great product-focused founders who have had to close shop because they didn't invest enough in profit centers, and many of them have told me point-blank that they wished they had invested more in their sales organization. Meanwhile, I know many technical founders who admit they can achieve their product and customer goals with much less. So please, take this opportunity to think critically about how you're allocating your team, and adjust accordingly!

Bad things happen, and sometimes crises are unavoidable. I've spent time as an automotive engineer, a software engineer, a CTO and a startup founder, so I've had lots of opportunities to deal with crises. I've discovered that crisis management is a learnable and teachable skill, and I'd like to share my crisis management philosophy and procedure with you.

In my daily life I deal mostly with software/product/business crises. But I'm writing this article the morning after my wife hit her head really hard and started bleeding profusely (she's ok!), so I'll be demonstrating this general technique's applicability to both software and personal injury crises.

This approach is a general crisis management technique. Its philosophy is centered around dealing with your own mental state during a crisis, and developing the understanding of which mental faculties you have while under duress or in periods of high stress.

In teaching this technique to others I've found that the "a-ha!" moment is my treatment of the concepts of duress and intuition. Loosely defined, I use "duress" to mean "high stress, high stakes, high urgency, threatening situation", and "intuition" to mean "the ability to use both sides of the brain in parallel to tap into previous experiences and solve problems semi-subconsciously".

A caveat: this is not medical advice. If in doubt, call 911. They're the experts, not you. But keep in mind that facial and scalp injuries can cause a lot of bleeding, and often the bark is much much worse than the bite.

Step 1: Determine if you're under duress.

Most crises lead to a state of duress. I've found it important to spend a second or five at the beginning of a crisis to determine whether I'm under duress or not. Ask yourself the following questions: am I stressed or panicked? Do I feel the pressure of time viscerally? Is my heart rate elevated? Does this feel high-stakes?

This is an important step in crisis management because your brain chemistry changes when you're in a state of panic or duress. Adrenaline and cortisol enter your system, and while they can help your physical response time to stimuli, they hinder your creative problem solving skills, and most importantly, they hinder your intuition. The stress hormones refocus your body and mind towards dealing with lower-level, evolutionary, animal brain issues (fight or flight), and so you lose some higher level function, in particular the ability to multitask and work in parallel.

Recognizing that your intuition is no longer useful is the tentpole of my crisis management technique. Put another way: most crises are unintuitive. If the problem were intuitive, it probably would not have become a full-blown crisis in the first place! Or at very least you'd know what the solution is early on and wouldn't need to fall into crisis management mode.

If you recognize that you're under duress, you must also recognize that you can't trust your intuition. Relying on your intuition in these cases typically leads to paralysis, which compounds the duress issue. I've seen engineers in a state of duress just sort of "poke" at the problem, looking at the same pieces over and over again, hoping that the lightbulb will light up, and it rarely does. They're trying to use their everyday intuition--which is excellent and typically correct in a relaxed setting--in an unintuitive, high stress situation. It rarely works.

If intuition fails, you must fall back to procedure. Spend only a few seconds on this step. All you need to do is say to yourself "I'm under duress, let me switch to methodical procedure."

Step 2: Collect Information

Problem solving under duress, without the help of your intuition and creative skills, is different from solving problems in a relaxed state. In a relaxed state you'll often work in parallel to collect information while simultaneously forming hypotheses or conclusions. Don't try to do this in a crisis.

Instead, collect information as quickly and calmly as you can. Don't try to process the information yet; you don't have the mental bandwidth. Serialize and linearize the problem, don't parallelize it.

Collect the most valuable information you can as quickly as you can before moving on to step three. If you're a software engineer and your site is down, collect information like: what are the actual symptoms? Is the whole site down or is it just one page? What are the environmental factors? What are the exact error messages? What is the hierarchy of the application? Where are the relevant files?

If you're treating a friend or loved one that has just been injured, ask yourself: what are the patient's symptoms? What are their behaviors? Where is the injury? Did they lose consciousness? Are they losing blood? Are they speaking in coherent sentences? Are they in shock? Are they behaving congruently with their personality?

It'll be easier for you to solve the problem once you have a well-rounded factual picture of the situation, and batching your information collection up-front will save precious time. Anecdotally, I've found that your short term memory recall is not hindered by a state of duress, however the stress hormone cortisol seems to inhibit recall of older memories, which is a possible explanation for the loss of intuition. It may be tempting to try to solve the problem while collecting information, but don't. Doing so increases the risk that you'll follow an unnecessary rabbit hole and waste time. Get the information first. Parse it next.

Spend "a few minutes" on this step. In software applications this can take ten minutes, but if you're dealing with a injured friend you want to do this as quickly as possible, within two or three minutes.

Step 3: Identify and fix the single most urgent issue.

Once you've collected your information, switch into critical thinking and problem solving mode. You still have this mode of thinking available to you; what's gone is not your problem solving ability but rather your ability to multitask and your ability to solve issues intuitively.

Unintuitive crises normally involve multiple issues all at once, and not all issues are created equal. Identify the single most urgent issue--the issue that is causing your state of duress--and fix that first. If you fix the cause of your duress early on, you'll buy yourself mental clarity and bandwidth to solve the problem more completely in the next steps.

If you're dealing with a crashed website, and your information gathering has determined that a single widget on the page caused a cascading failure, remove that widget first and bring the page back up without it, restoring the basic functionality and silencing the alerts. There's still the problem of reduced functionality and a broken widget, but you'll fix those issues later when you're no longer under duress.

If you're dealing with a friend or loved one that just got hit in the head and is bleeding but is still conscious and coherent, the thing that's causing the most duress is not knowing how urgent the problem is: "there's a lot of bleeding and I don't know how bad the wound is; is this an ER situation, do they need stitches, or does it look worse than it is because there's a lot of blood and it's painful?". There are still other issues like "where's the closest emergency room", "does my friend have a concussion or other traumatic brain injury", and "is there a skull fracture". Solve the bleeding first. Grab a towel and apply pressure for a couple of minutes. If the bleeding stops on its own, you've just relieved your state of duress and can now start thinking about the other issues. (If there's loss of consciousness, slurred speech, spasms, etc, call 911 -- the above scenario applies to a conscious and speaking person).

Spend around 10 minutes on this step. If you fix the most urgent issue first, by definition, the next issue is less time sensitive than the first. As your issues get less time sensitive, your state of duress decreases.

Step 4: Repeat the procedure for the next issue(s).

After fixing the most urgent issue, revisit step one and determine whether you're still under duress or if you've calmed down. If you're calm and you no longer feel any urgency or time sensitivity, continue working the problem with your normal set of problem solving skills, and allow intuition to come back into your thinking.

Odds are, however, you're still in an elevated state of excitement. If so, go back to step two and collect information again, targeting the next most urgent issue. Then move on to step three and solve that issue. Once that's solved, hit step four and repeat the loop until the urgency has subsided.

As the urgency of each subsequent problem decreases, you can afford more time to solve each one. In our software example, you're now afforded more time and more mental capacity to investigate fix the root cause of the problem, and once that's done you'll have time and clarity to deal with any fallout from the crisis. You can now spend an hour on fixing your broken widget.

In the personal injury example, this is the time to inspect the wound more closely, determine whether or not you need to go to the ER, pull up directions to the closest urgent care center, check WebMD for warning signs you may not have known about, and determine your course of action.

If the patient's bleeding has stopped and they're coherent, the next most urgent issue is determining whether you need to go to the ER. Because you addressed the most urgent issue first (profuse bleeding), you now have some more time that you can use to: ask them questions about their day to test memory and recall, take a closer look at the wound to see what further treatment it might need (again, if in doubt, call 911 or go to the ER), and you can spend some time comforting your injured friend while observing them. Maybe the wound is just a cut that bled a lot and doesn't warrant an ER trip. With that problem solved, you can spend some time cleaning and dressing the injury. Or maybe you'll notice slurred speech and forgetfulness once the shock has worn off. In either case you can spend some time on this (ie, observe for 30-60 minutes) now that the bleeding is stemmed and taken care of, and you'll have the wherewithal and calmness to drive safely to the hospital.

Step 5: Follow-up

Once the urgency and sense of duress is gone, allow yourself to go back to your normal problem solving mode. Figure out your plan for the next 3 hours, 12 hours, 24 hours, and 48 hours.

In the software case, plan out the fixes, patches, procedures and communication you'll need to take care of in those time periods. In the injury case, if you didn't go to the hospital, plan out observation, clean-up, follow-up, and treatment (Tylenol and bandages) for those time periods. For instance, if the injury happened at night, let your friend go to sleep but plan to wake them up and have a short conversation to check for mental acuity in 3 hours. Then follow up on making sure there are no other warning signs and that the situation is improving in 12, 24, and 48 hours, otherwise go to the hospital.

Don't avoid crises; learn to deal with them.

This stuff happens. Crisis prevention is obviously important and the best-case scenario. It's always good to avoid high risk behaviors. But unintuitive problems can happen no matter how thorough your preparation is. My advice is to get good at both sides: be good at preventing problems before they happen, but also make sure you're comfortable dealing with urgent unintuitive issues.

The most important takeaway from this article is that intuition is unreliable in a crisis, so you will need a pre-memorized and practiced procedure to fall back on. Using procedure instead of intuition clears up mental bandwidth and reduces stress for the crisis manager.

NASA, for instance, takes the same approach: they rely on preparation and procedure in the most urgent situations, and they've designed and practiced those procedures with the understanding that human intuition is powerful when available but perilous when under duress.

My procedure above isn't the only crisis management procedure out there. It's simply one that I've developed over the years dealing with crises. It has the advantage of being simple, generalizable, and easy to recall and implement when under high stress: remind yourself that your intuition is unreliable, collect information without interpretation, then interpret information with the goal of removing the biggest stressor as quickly as possible.

If you don't have your own crisis management procedure that works for you, feel free to use the one above. I've taught it to all my engineers over the years and can anecdotally report that it works for everyone I've taught it to, greatly improves time to resolution, and reduces the stress of crises.

If you do already have a procedure you use, my advice is to simply reflect on how your procedure treats the concept of intuition, and perhaps introduce the concepts of duress and loss of intuition into your model. I'd also love to hear about your crisis management techniques in the comments below.