Last week I wrote about the inevitable chaos that comes when we make everyone a full-stack builder. One of the solutions I proposed to reigning in some of that chaos is to build a deployment path that allowed these newly minted builders to deploy through a compliant process in hours assuming everything they’ve created checks the right boxes. I urged readers to partner with your engineering partners to define and build this deployment path to ensure that the code that does see the light of day and was NOT created by an engineer stands the best chance of success in production. If a designer-turned-builder can build something in hours, she should be able to deploy it in a similar timeframe or receive feedback on why it can’t ship right now. The builder is the user. The deployment process is the product. How well they pass through that process are your outcomes. The deployment path is a product. 

The deployment process was deliberately designed to be slow

Today’s deployment processes weren’t meant to be bureaucratic. They are the filter that catches weak ideas and poor code before customers do. AI made everyone a builder (or not quite yet but…). It did not remove the reasons for the gates. I’m not suggesting we have fewer gates. The checks that are there today are likely valid regardless of who wrote the code. I am suggesting that teams can move more quickly through them. 

What’s interesting is that, because of their subject matter expertise, engineers have imposed these deployment processes on teams in the past. With roles flattening and organizations looking for even more throughput (I have many strong opinions about this), it’s time for a cross-functional, collaborative redesign of the deployment process. If we’re going to give designers and product managers the right to deploy they should have a say in the shape of the path to production. 

What should deployment SLAs look like in the AI / builder era? 

The goal of a redesigned deployment process, especially one that serves PMs, designers and full-stack builders should be two-pronged. Compliant code should clear all necessary reviews in hours. Non-compliant changes to the code should receive actionable feedback in minutes. Nothing should sit in a queue waiting for a human to notice it, review it and then write up feedback to the builder. 

Both of these time-based metrics are highly important. Getting a compliant feature through the deployment gate in hours rather than days or weeks ensures the gate actually gets used. It’s not seen as a hindrance but rather the easiest way to get something into customer hands. The rejection timeline turns a non-compliant idea into a learning moment rather than disappointment, resentment and frustration at an opaque process owned by “another department.” 

What should a “compliant” feature have?

The checks that an AI-ready deployment process should include, at the very least, are:

1. Every feature ships with a valid hypothesis, human-centric success criteria, a named owner and date when the deployment will be reviewed for performance success, learnings and kill/pivot/persevere decision.
   
2. The builder makes clear what level of exposure the deployment is requesting. They should specify if this is going to a prototype testing cohort, an internal cohort, general deployment, etc).
   
3. Engineering has specified the technical minimums each feature should meet. I’m exceeding my expertise here a bit but at the very least we’d want to see that all tests pass, security scans come back clean, no new unowned dependencies have shown up, etc. 

If a builder knows these are the checks they’ll have to pass to get to production, they’ll also know, before trying to ship, if they’re compliant or not. 

What does actionable feedback mean if my deployment failed?

Actionable feedback should make it clear to the builder what they need to do next to get their feature into compliance. “Needs more work”, “doesn’t match the roadmap”, “I don’t like it” or just straight up silence is not actionable feedback. It’s not clear where the builder should go next to get unstuck. 

Instead, the deployment process should make it clear to the builder if they’ve passed the engineering requirements listed above. This can be automated in most cases because these compliance rules are clear and deterministic. The hypothesis and exposure criteria should, however, be reserved for human review. Those humans, in all likelihood other product managers or leaders on the team, tasked with reviewing these compliance gates need to have the capacity to do so within the SLA agreed upon when the new process is designed. 

Which parts of the deployment process does engineering own? And which do the PMs own?

Perhaps it seems obvious but let’s say it. Engineering should own the technical compliance rules and gates. They should create the tooling that checks a builder’s code for security, performance, dependencies, et al and make it easy for the builder to use. Product managers are going to own the hypothesis, evidence and review gates. They also own generating and delivering the feedback either in writing or face to face to the person who submitted the feature. The entire team owns the time-to-feedback targets. This is how the team will measure the success of their new AI-ready delivery process. 

What metrics should an AI-ready deployment path measure?

As I’ve written about in many previous posts on OKRs and human-centric goal setting, the key question to ask is, “What will people be doing differently when we launch the new deployment path?” 

So, in this case we should at least look at:

• Time to first feedback
• Time to clear compliant changes
• Percent of submissions rejected more than once for the same reason
• Percent of builders who use / don’t use the new submission process

And there are likely many others that will tell us if this is working as designed or not. 

Scale this to the size of your organization

A 5000-person company will have more compliance rules than a 100-person company. It doesn’t matter because the SLA will be specific to each company. The humans involved in the deployment path should commit, in writing, to these turnaround times and do their best to stick to them. If speed is the goal, this is a big step towards it. But there’s one more benefit to this type of deployment approach. It teaches builders what good looks like so that, hopefully, every subsequent submission gets increasingly more compliant and customer-centric. If it fails to do this, gets burdensome or is seen as a series of meaningless boxes to check, your teams will just work around it ensuring the real QA will happen with your customers in production. And no one wants that.