Early bet, or wrong bet?
Your AI bet is struggling, and nobody inside the argument can tell you whether it needs more time or was a bad call.
You made a real bet on AI: tools, rewrites, workflows, agents. Now it's stuck. Half the team says push through, the other half says pull back, and both have evidence. The call you actually need is the one nobody inside the argument can make: is this hard because it's early, or hard because it's wrong?
How we'd handle it
We've carried bets like this from both seats, the one placing the bet and the one living with it. By getting into the work itself, we can separate the friction that's immaturity from the friction that's mismatch, and give you a straight call. Sometimes that's doubling down. Other times it's reshaping the bet, or knowing when to fold.
Where we've done this
At Redis I bet on Rust years before it was widespread, to modernize aging components. This became the precedent the company drew on when it wanted to rebuild its cluster manager.
Enigma's core engine moved off C++ onto Rust while the language itself was still unstable, so shipping on it was the bet. I carried that decision far enough into the code to bring the team with me, writing the macro layer and the WebAssembly work myself.
I spent years at IBM on the Rhapsody Action Language, a bet that had to keep working inside a product customers were already shipping. Month one gave no proof it would pay off. It shipped, and it is still in the field.
Recognize this on your team?
Let's talk