Large portions of software development budgets are dedicated for testing code. A new component may take weeks to thoroughly test, and even then mistakes happen. If you consider software defects as security issues then the concern goes well beyond an application temporarily crashing. Although even minor bugs can cost companies a lot of time to locate the bug, resolve it, retest it in lower environments, then deploy it back to production.

Massive tomes have been written on engineering management, but I thought it might be helpful to take a brief minute to discuss setting up your Founding Engineers (FE) for success. For this post I define FEs as the first wave of engineers hired after the founding team. This round of hiring usually takes place after seed funding has been secured and some semblance of initial product/market fit has been achieved.

Speedscale ‘SpeedChat’ Episode 2: Shift-Left vs. Shift-Right Throwdown featuring Nate Lee (Founder, Speedscale), Ken Ahrens (Founder, Speedscale) and Jason English (Principal Analyst, Intellyx).

Speedscale ‘SpeedChat’ Episode 1: Discussing software product management, ‘dogfooding’ and scaling quickly for product/market fit without breaking things.

As a team we have spent many years troubleshooting performance problems in production systems. Applications have gotten so complex you need a standard methodology to understand performance. Fortunately right now there are a couple of common frameworks we can borrow from: Despite using different acronyms and terms, they fortunately are all different ways of describing the same thing.

One of the reasons we selected Sierra Ventures as one of our seed investors is because of their CXO Advisory Board. They have dozens of knowledgeable advisors across a wide variety of verticals: Healthcare, Consumer, Retail, Finance, Technology, Media and Telecom. Each year they conduct a broad survey of major trends. This kind of survey data is gold for Enterprise-focused startups.

When making changes to applications these days, it’s hard to understand and predict the impact of those changes before you deploy. API connections are multiplying, and with new cloud platforms such as containers/serverless, it only add to the complexity. Some people have trouble remembering whether they closed the garage door or turned off the coffee maker. Can you remember all the details of your latest API contract change? Let alone who would be impacted and needed to be notified?