Why the Business is my Business

There's A LOT to learn and hold in your head as a Software Engineer, especially after industry trends made our job extra bloated with the fictional need to use and work with technologies and patterns copy/pasted from Netflix, Google and other big Tech Companies who worked at massive scale and over-hired when productivity didn't matter.

When this artificial over-bloating of tech companies is going away, we need to fine tune our technical direction and actions to solve real business needs and become viable with the resources at hand.

This is why an adequate Engineering Strategy is more important than it has been for the last 10 years and sets the difference between a tech company achieving nothing versus having a chance for success.

What's an Engineering Strategy

It's the continuous analysis, direction and implementation of engineering solutions to business problems.

Gauges for a "bad" Strategy

It's difficult and uncommon to be good at both engineering AND business, so we usually fall into this common pit.
They have these common traits:

• Don't start with the business need they're tackling.
• Use architectural solutions to problems they don't have.
• Don't include a continuous customer validation cycle.
• Focus on infrastructure and implementing patterns instead of behavior.

Some examples:

Example 1:

We're an established business, we know our customers well but we're starting to have performance issues because some areas of our monolith have a really high demand

• Rewrite everything from scratch in parallel, while our under-performing, error-prone monolith is still live and some engineers spend their time firefighting issues while others build software in a green-field project in isolation for months without real customers using it.

⚠️Chances are the new software will never be live and working.
💭A more appropriate approach is to start by measuring user journeys and their results to then extract areas of the existing code into services, rolling out the services in phases, making sure your metrics don't get worse.

Example 2:

We're an established business and want to modernize, we want to build a web version of our massive business desktop app in a short time.

• Hire a team in another country to reduce costs, and ask them to rebuild the modernized web version, setting an aggressive deadline and encouraging to cut corners in testing.

⚠️Chances are the software will be so bad it'll damage the business more than using the old version of the software.

💭A more appropriate approach would be finding out what's the slice of the product that could potentially benefit more from modernizing (by bringing more revenue for example) and aim for building and releasing this to a small cohort. If possible with an in-house team but if not, have a good technical leader driving delivery and working with the consultancy.

Example 3:

We're a startup with no customers, one of our most high-stake problem is to find customers and get ahead of our competitors.

• Use a microservice architecture and split the domain into n-services that will communicate through APIs and Pub/Sub before we have any functionality in place.
• Build for all platforms, any mobile and web.

⚠️Chances are, by the time the product is live, the market has changed so much it will no longer have the same Key Differentiator it initially intended to have.

💭 A startup needs quick development and rapid changes to adapt when learning about the product fit. Microservices require n-times more work to get something done. You need to be able to prototype and make sure the decisions you're making when building the product are valid. Unless the business can only run via mobile app, a web app is much quicker to develop and deploy and you could even use a PWA.

These examples are still lacking information about the type of product a business needs, sometimes the technology is much less relevant than people might think and it's more about understanding well who the user is, what they need and having metrics that you're able to influence. As engineers, being unaware of these dimensions is quite common, as you already have a lot to know about (and many technology trends to catch up with).

Gauges for a sensible Strategy

The way to detect a sensible technical strategy is by checking it's appropriately responding to business problems to a low level of detail, this means you need to make the business be your business 😱. If you're past junior, you can't keep doing tech in your corner of the company and you need to ask questions and understand where are the key business problems and how to best solve them with tech.

Shot of a brave engineer getting out of the cocoon and peeking into 

the executive leaders meeting

Aleix Morgadas has written this specific blog post on How To Understand The Business to Design a GOOD Engineering Strategy.  👈 READ IT AND BOOKMARK IT 

Small note: I really don't like war analogies with strategy, there's no need to think in terms of enemies and destruction, I'd rather use analogies of environmental adaptation.

Here's a really complete talk about how to design and execute an Engineering Strategy using a detailed real example. It's both fun and didactic to watch (jump to 15:40 for the fun part and then watch the intro):