But then I had the chance to play and see how much progress had been made in the models, agentic workflows and AI native IDEs since my last real checkin. I was genuinely mind-blown by the quality and speed improvements. This was the tipping point. I knew if teams don’t make the shift from side project dabbling to full engagement they would be lapped. I’ve been heads down in it every day since and came to the realization that the phrase “vibe coding” is being used to describe AI-driven development as if it were reckless improvisation.

Ironically, I think “vibe coding” better describes the last few decades of engineering than what’s emerging now.

There’s plenty of others writing about the hands on techniques, skills, latest apps and journeys to become a Principle Markdown Engineer, but I wanted to touch on the paradigm shift and what I’ve noticed is an increasingly obvious misnomer in “vibe coding”. Let’s compare paradigms between AI native and what was the prior most modern engineering practice, “Cloud Native”.

Best Practice Alignment

Cloud Native

Open up your multi-front war around continuous delivery, TDD, IaC, local dev vs integrated environments, strict vs passive conventions, who tests what, branch management, observability, blue green or canary, or God help us release trains, documentation, explainability, refactor vs rewrite, micro vs macro services vs monolith, to monorepo or not …

These are alignment meetings, brown bags, team all hands and then more realignment meetings. They are expressed at best as onboarding wikis and READMEs that you beg teams to align to, get frustrated when they don’t and watch the tech debt pile up if you actually want to ship software. You’re managing a constant flow of pragmatic compromise to keep the business moving forward and you do your best to manage the balance.

AI Native

Encode your engineering biases as executable context. Not slides. Not tribal norms. Not onboarding decks. Enforced context. Turn talk tracks into markdown, dead wikis into living enforced context.

This feels like therapy to a weary tech leader’s soul. “Best practice” finally has meaningful and sustainable weight, metaphorically and technically speaking, in your engineering system.

Tech Debt

Cloud Native

Tech debt is in the eye of the beholder, it’s felt mostly in implicit ways. Time to deliver changes to prod keeps rising, path to product pain drives angst, but the team says they can always fix that by taking an axe to the best practice alignment. The finger pointing starts and then ultimately the business is put into a hostage crisis, “if you really want this done right then I need to rebuild all of this”.

The cost to “fix” or more accurately re-finance tech debt is significant. It’s a running aggregation of each day’s compromise where any in isolation may have been the “right” call but now you are backed into a corner and you either double down, pay down or invest in the purist pay off plan.

But make no mistake you are armed with few scalable defenses against this dynamic from repeating over and over.

AI Native

Being able to bring explicitness to what was implicit and tribal should certainly be a welcomed technique change, but it’s a superpower because it scales. It scales because it’s not dependent on human capacity and non-deterministic application. In my article on the transformation triad I talk about how you must make the right thing the easy thing, then make the easy thing the habitual thing. Despite those points having “easy” in the phrasing, making that happen is anything but easy and that’s because humans are inherently complex and highly constrained.

Agents are only as difficult and complex as you define them and only theoretically constrained by the compute you feed them. That’s an operating primitive whose scale fundamentally changes what’s possible, over what time horizon and with what resources. We’ve never had any truly effective vehicle to solve coordination and motivation cost, we do now.

The CTO instinct of “what can I do with a team of a dozen” has turned into what could I accomplish with a team of 2 or 3.

Explainability

Cloud Native

The more shared understanding you want, the more human effort you must spend creating and consuming non-user facing value artifacts, effort diverted from building the product itself. So you inevitably make daily tradeoffs between this. Bias towards execution and you lean on those that already have the understanding and settle for imbalanced utilization and frustration from those on the sidelines watching or working on low value things. Bias towards shared understanding and you get more balanced utilization but sacrifice near term velocity and perhaps quality.

These are poor choices.

AI Native

Explainability is not limited by human cognitive load or tribal effort, instead it’s democratized through a durable and evolving instruction set in the codebase/filesystem itself. Humans are no longer the bottleneck of contribution or consumption. Use and interrogate the system to understand and ultimately contribute to the system.

In TDD we used to talk about the value of self documenting code and that tests were the best form of that. We’re now in a TDD renaissance.

What used to take a form of miraculous spiritual revival to get strong TDD adoption is a few lines in a markdown file. Entire test pyramid alignment a few more. Durable. Always enforced, executed and results honored.

My therapy bill is nose diving as a type.

The reward was the vibes we made along the way

Let’s not kid ourselves, we’ve been swimming in vibes for decades.

Vibes about code quality, testing discipline, architectural purity, what “good” was, what “done” was, who works well with whom, the codebase no dev wants to touch etc… I think in large part our defensiveness about those vibes is the root of skepticism about AI native workflows because it directly confronts the vibe reality.

Now to be fair, there’s a lot we’re discovering and learning about the AI native workflow, what works and what doesn’t, what’s fun, painful, scales or tanks. But the compounding pace of innovation and quality in this space is undeniable.

The right question every business should be asking themselves is not what are all the correct tooling/implementation choices to make today, it’s how do we urgently orient ourselves around a new engineering paradigm that puts us on the right curve. A curve where we can quickly pivot, ideate and learn, scale much more efficiently, massively shorten feedback loops and time to market.

The efficiency, velocity and scale gains to be had here for most businesses in many contexts are measured in orders of magnitude, not incremental. If you aren’t re-evaluating aged assumptions through this new paradigm, you’re doubling down on legacy thinking and while that may feel like maturity I think it’s more fundamentally a misplaced trust and defense of the “vibes” you’ve previously known.

It was clear from minute one how much growth the FinOps community has had over the past year. The main room was buzzing, completely sold out, the vendor floor was flooded, 200 something turned away, the venue itself here in San Diego a big step up from last year’s inaugural event in Austin. 11,000 community members strong now and the energy level matched the numbers. The IBM acquisition of Apptio for $4.6bil juiced the hallway convos and gave additional market validation of the ecosystem. You can tell when a community is feeling that confidence, riding momentum, cultural identity shining through and this year is that moment for FinOps.

Themes of the Day

“Shift left FinOps” - DevOps and FinOps community merge

Natalie Daley from HSBC gave a great high level walk through of their FinOps journey along with a slide that I give a 9.5/10 for richness.

Her examples of how certain capabilities, like power scheduling, matured over time to eventually land in the Run phase. On looking towards the future the talking points made me chuckle a bit with how communities can follow same evolutionary paths, talk around the same principles with slightly modified language and unfortunately all too often (re)learn all the same lessons.

I heard the same principles as years past in DevOps, PaaS/Platform Eng communities in some cases borrowed language in others just new: culture > tooling, shift left, feedback loops, waste elimination, value identification.

My quick warning to the FinOps community here as someone who’s traveled this road many times before, pathological behavior of organizations is a critical friction point. It’s easier to identify and reward fire fighters than forrest management. If you want to move left, you have to face this head on. Ignore incentive structures at your own peril.

Mike Fuller talked about getting “data in the path” for engineers which is a similar trajectory security engineering took with DevSecOps and FinOps inevitably must take to get in “golden paths”.

This left me pondering an idea that I think could be very valuable but certainly interesting. Imagine a community mashup conference between FinOps and DevOps communities. There is much more common ground than assumed and our time to value would shrink considerably if we just broke down the silos. We’d learn things like not everyone in FinOps community has an excel tattoo and a pocket calculator and turns out not everyone in DevOps community has social anxiety and loves mechanical keyboards. Well maybe the latter is true but let’s make it happen anyway!

Unit Cost moves from wish list to must have

Equifax, HERE Technologies and several others have been discussing what has been the white whale of FinOps for some time and that is unit cost visibility. It’s important for the community to have organizations starting to realize this because it moves FinOps closer to business value than just waste management. That’s starting to happen as more companies move into walk and run stages. Broader realization on this capability will help close the gap on FinOps participation and tangible benefits as revealed in the Real State of FinOps research.

FOCUS takes main stage

FOCUS is the FinOps Open Cost & Usage Specification which has recently hit v0.5 milestone and is rapidly picking up community interest. Udam Dewaraja and Mike Fuller’s breakout room on FOCUS was standing room only with massive interest from practitioners, SaaS vendors and CSPs alike(cough except AWS cough).

This project to me represents the next cycle of FinOps growth and opportunity to impact the broader cloud industry in a significant way.

If we can normalize cost and usage data across CSPs, SaaS and in house data that will drive a few streams:

1. Multi-cloud: generally thought to be at worst foolish waste and at best a necessary evil/pain, we’d now be able to actually make intelligent workload placement choices and have a chance at making multi-cloud a true value add to our businesses.

2. Fully loaded unit cost: It’s impossible to over state how painful it is to stack fully loaded costs(licensing, observability, CI/CD, cloud hosting, shared costs, humans etc…). Everyone draws their own good enough line, but FOCUS would significantly lower the burden and raise the ceiling of what’s possible.

3. Community leverage vs bespoke execution: We’ve all been solving this our own way and making very little progress as an industry. FOCUS would represent a massive step forward industry wise that puts everyone on a different velocity curve for success.

I’m very excited for FOCUS and can’t wait to get more directly involved with that project, hope you do as well.

A seasoned leader knows how difficult momentum is to build and how easy it is to disrupt. It takes collective commitment to disciplines that combat both the inherent entropy that exists in organizations as well as the bad actors that derail progress. If you can’t map practices that reinforce the positive behavior to combat the negative behaviors that are discovered, then you are watching the inevitable decline of your team and org. The larger the org the longer the corrective turns take, the more important it is to have quick feedback loops.

One metaphor I use to explain how to build momentum in software delivery is to look at the inchworm. It has two staged motion, the starting loop position(sync) where hind and head are together is the foundation for the forward movement when the head is able to extend forward(stretch). The rhythm in the sync and stretch motions are what create momentum for the inchworm.

Sync - adoption and alignment

The org has to have a handle on current business and product scope. The head and hind have to be close enough so that there isn’t paralyzing confusion, solution fragmentation, firefighting, etc… to even give you the opportunity to extend forward with another appropriately disruptive innovation cycle. This sync motion is where you drive and incentivize adoption and alignment.

In my organization this will frequently be driven through communities of practice(COP) where a new convention has proven valuable and we want to see that get adoption in all of our teams. We will set shared goals for those teams to adopt the pattern and allocate in people that can help them implement/adopt where needed.

Here are some signals you need to improve your adoption and alignment:

• Long lead time to value across org when new convention/pattern emerges

• Large disparity across team health and outcomes

• Large gap in latest versions of services or patterns made available(provider) and what’s being consumed or implemented against by teams(consumer)

Stretch - innovation movement

If your latest patterns are reasonably well adopted and there’s strong alignment between teams, then you need to start the next stretch, the next innovation movement. Waiting until there’s full adoption or no alignment challenges will keep you paralyzed, look for 80/20 strong majority conditions and introduce the next stretch.

Every team needs to innovate in their space. That innovation pressure will be from external and internal forces. It may be driving toil out of day 2, it may be making the path to prod simpler, it may be updating dependencies, it may be adding a new customer facing capability.

Here are some signals you need to improve your innovation movement:

• DORA metric outliers, not keeping pace

• Disproportionate security toil (often due to aging dependency chain)

• Toil burnout in the team and difficulty finding new talent

Disembodied Innovation

If your movements are out of sync, if you stretch too early prior to a strong sync stage you will get disembodied innovation. The team doing the innovation will leave behind the rest of the org and instead of organizational momentum you get organizational outliers that the rest of the org views as a unicorn instead of a model of what’s to come. This is somewhat by design for companies with “labs” style teams, I won’t address my challenges with that model here, rather I’ll just say

Be like the inchworm, focus on bringing your sync and stretch into harmony and observe how you build sustainable momentum and meaningful forward progression.

When the systemic problems spring up it’s often easier for people to just find a new job rather than do the hard transformative work inside a complex ecosystem. But I’m writing for those of you who stay, who are inspired(or incentivized enough) to, as Jason Warner puts it, “change the slope” of your organization.

For reasons that I’m not entirely sure, I’ve made a career out of this, or maybe more accurately, transformation ended up making my career. It can be both deeply frustrating but also an incredibly rewarding journey when you pour years of effort out to see a group of people reach a level they never thought possible. Each journey is its own steeplechase complete with diverse sets of obstacles that teach you new ways to motivate, reward, inspire and perhaps most importantly persevere. While there is no formula to apply, there are patterns I’ve discovered that I believe are helpful as a guiding light as you navigate the intricacies of your context.

1. Stop doing deathly dumb things

Awareness

Before you start pouring yourself into investment strategies, training opportunities and re-org plans, or even before you refresh pitch decks with today’s hawt hot memes that will dazzle the forever near retirement exec who’s stifling all change, you have to deal with what’s killing the team today. It’s the oddly elusive but certainly deadly cultural instincts that the organization is addicted to, that to any outsider reeks of death, but to most of the proverbial frogs in the pot, it’s just another day and the water is imperceptibly warmer than yesterday.

There’s almost certainly good reasons for how the team arrived where they are, why the deadly behavior is now the instinct, and while that may have bearing on how you communicate a necessary change, it can’t prevent you from doing what’s right no matter how much inertia exists.

Be curious and follow the smells.

Be observant and follow the pain.

Be decisive and follow through.

You have to have the guts to be wrong. When you come into an org and wonder how the heck they arrived there, when you see what in any healthy environment would be considered insane yet has somehow become a cultural norm, often times the answer lies right here. It’s far easier to observe than to object, to coddle rather than change.

Examples: “pathological” org structures, hero making, “single throat to choke”, pushing pain downstream, misdirection, change approval boards, poisonous cultural elements(the 10x a$$hole) & transformational detractors

2. Make the right thing the easy thing

Enablement

At this point you’ve stopped the bleeding from mortal self inflicted wounds, you’ve raised awareness through vision decks and which may have even been positively received but positive momentum is still a far way off. In order to get lift you must find a way to create a foothold by demystifying the brave, but alien new world you’ve been describing as the promised land. There’s no one right way to choose where to start but there are a collection of factors you should consider:

• Where is the greatest felt pain in the org and how does that map to business impact?

• Where does that pain intersect with relatively few dependencies either organizationally or technically?

• Is there a new project where you want to start on a new paradigm and create a “lighthouse model”?

• Where do you have change agents and where are the detractors?

As you weigh those factors you want to plot a course for early wins that create a foothold you can leverage for more change in order to develop momentum.

I strongly caution against storming the castle to slay the dragon with your first draw of the sword, there is a trail of failure awaiting you on that path. Instead, focus on building cultural momentum that stays aligned completely to the vision, inclusive of dragon slaying, while piling up small, meaningful win after win.

That gives the team confidence, their own learnings, ownership of the journey and solution and creates the benevolent organizational beast that can take on that dragon through positive inertia.

Examples: CI/CD paths all the way to prod, increased empowerment in teams, better tooling and observability, more direct communication/escalation paths, paved paths

3. Make the easy thing the habitual thing

Culture

One of the definitions of culture I find most helpful in this context is the subconscious reflexes of an organization. It’s what people and teams do instinctively. When an org has bad or unhealthy instincts it’s easy to become impatient and unreasonably direct with the correction.

It’s important to remember that cultural turnarounds are not simply a matter of philosophical principle alignment, rather they are the result of thousands of corrections to those principles executed consistently over years all the while effectively enabling the teams(see point #2) so these corrections are actionable.

It takes that type of consistency before you start seeing the instincts change and the cultural current shift directions. I can’t stress this enough, adjust your measurement window to years not months.

The more you can leverage platform patterns and paved paths in your enablement the more positive behaviors your teams consume without democratizing every micro-pattern under the sun. When teams are feasting on a steady diet of “right” and “easy” things, changes to appetites, behavior and instincts will follow.

For corrections that require more challenging or staged adoption, I coach teams in what I call the inchworm adoption pattern upon which I’ll expand in a separate article.

If you found this helpful at all please share and subscribe.

Share

Subscribe now