Some low-impact signs to watch out for: Teams that are only accountable for operational goals like velocity or number of features delivered Teams that reverse-engineer their goals from the work they already have planned Teams that broadly resist estimating impact because it’s “too complicated” or “involves too many things outside of our control”
Low-impact work creates more complicated products which, in turn, lead to more dependencies and conflicts to manage. Those dependencies and conflicts discourage teams from taking on work that touches on the product’s commercial core. Which, in turn, encourages more low-impact work.
The proliferation of one-size-fits-all “best practices,” of sanitized case studies from Silicon Valley darlings, of “best vs. the rest” narratives, has created an environment where just about everybody working within the real-world constraints of most companies’ business and funding models will never feel like their companies are doing things “the right way.”
So if I’m correct, then the future of build vs buy will be “yes to both.” Companies will continue to buy complex and valuable component services for important parts of their business, but these components will be designed to be accessed and controlled by both humans and software. Some of that software will be AI agents acting on our behalf, and some will be customer (or system integrator) defined workflows generated from gen AI tools.
