Experiments are part of everyone’s job, so this article and series are your blueprint to a viable career. I’ll let you in on a secret that I’ve been teaching in seminars for a couple of years now. Roles are transforming to keep up with a business that increasingly relies on technology for operations and revenue growth. Here’s the big picture that most aren’t seeing:
Marketing → marketing analytics → marketing engineering
Growth → growth analytics → growth engineering
Revenue operations → revenue analytics → revenue engineering
Finance → financial analysis → financial engineering
Operations → operations analysis → operations engineering
Product → product analytics → product engineering
Research → research analysis → research engineering
Content → content analytics → content engineering
Sales operations → sales analytics → revenue/sales systems engineering
Customer success → customer analytics → customer success engineering
In my seminar, I have a slide with 30 roles that have gone from nontechnical to analyst to engineer. The highest demand and salaries are given to people in the third category who have domain expertise, the ability to work with data, and engineering capabilities.
Strategy engineers are coming soon. If you think about it, that’s what C-level leaders do too, and they’re about to get support from emerging strategy engineers. It’s becoming the entry point into C-level leadership and becoming a founder.
A strategy engineer is a business scientist who helps build an algorithmic business through experimentation. Experiments transform the operating model one causal workflow at a time. They reveal entirely new business models with higher growth ceilings and faster growth rates.
Outcomes force a more rigorous methodology. That’s why F1 racing has some of the most reliable models. They see the results every race. It either works or it doesn’t, and those feedback loops build highly reliable models. It is the same in algorithmic trading, healthcare, and pharmaceuticals. You see a focus on outcomes in any industry that can’t spin the results, and that clear feedback is fuel for reliable models.
The patient got better, or they didn’t.
The trade made money, or it didn’t.
The drug was effective and made it to market, or it didn’t.
AI scales access to information, which makes complex outcomes easier to track. The app made money, or it didn’t. The ROI for code is easier to see. The business’s growth accelerated, or it didn’t. The ROI of strategy used to be opaque, but not anymore.
We’re all becoming outcomes engineers helping businesses compete in an outcomes economy. People with domain expertise, the ability to work with data, and engineering capabilities can run experiments that accelerate information flywheels. In part 3 of this series, I will provide an example of what those extreme experiments look like.
But more importantly, I’ll explain the vanilla experiments that pave the way.
I’ll start with value and work my way into architecture from here. Every engineering practice, design pattern, and architectural tenet must be financially viable. ROI is just as critical a constraint as any technical one.
As I explained in the last articles of the Causal Workflow Series, the recruiting and hiring workflow doesn’t create any value for the business until the employee delivers value to the business. You’d be surprised by how many jobs and workflows are like this. They don’t create value until after the end of the workflow.
Software engineering has a similar ugly ROI problem. No value is created by code, finished apps, or platforms until a customer pays for it.
No value is created by building and launching an ad campaign until a customer buys.
A hire, app, ad campaign, and even an AI strategy have potential value. The value is only realized after the workflow ends and the roles that own the workflow hand their artifact over. The workflow can succeed locally, and yet the global outcome will not be delivered.
This is a reality that most business units face. Their workflow ends before value creation begins, but organizational leaders don’t want to admit it because that structure makes them look like a cost center. Step 1 in fixing our big, ugly ROI problem is admitting we have one. That’s where the KPI game starts and why most businesses have low KPI maturity.
Most workflows only support a segment of the total value stream, so let’s start there and use software quality as an example. What is the ROI of a defect? We know that if all the defects shipped, no one would buy the product. We don’t really know that, so it’s a hypothesis with strong expert sentiment backing it up.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.