Inside a High-Autonomy Engineering Culture (With 82% Gen Z)

A few months ago, a friend who runs engineering at a much larger company asked me how we were "handling the Gen Z problem."

I had to ask him what he meant.

He listed the usual things. Engineers leaving within a year. Refusing to come to the office. Pushing back on timelines. Asking why before doing what they were told. Wanting feedback constantly. Quitting over things that, in his words, "would not have even registered as issues ten years ago."

I told him 32 of our 39 engineers are Gen Z. Around 82% of the engineering team. He went quiet for a second, then asked the question I was expecting: How are you not bleeding people?

The honest answer took me a minute to put into words. The Gen Z workplace problem is real for most companies. We have just had less of it, and the reason is structural, not generational. The behaviours my friend described are not generational defects. They are responses to the environment those engineers are working inside. The system we built has absorbed most of the friction that was making him panic. Once you see it that way, the whole conversation flips.

The data backs that up better than the framing does. Our Gen Z attrition has dropped every year for four years running: 31.2% in 2023, 21.6% in 2024, 15.1% in 2025, and 2.9% in the first quarter of 2026.

For context, Randstad's 2025 Workplace Blueprint found that 22% of Gen Z workers globally have already left a job, nearly double the Millennial rate. Industry attrition for this generation is going up. Ours has gone the other way for four years, and it is getting steeper.

Why the Gen Z Workplace Problem Is Almost Always Mislabeled

The labels my friend used are everywhere. They show up in HR decks, leadership offsites, and LinkedIn posts about young employees, repeated so often nobody stops to question them.

But the framing is wrong. What gets called a generational trait is usually just a response to the environment. The same engineer who looks "disengaged" at one company quietly becomes the most reliable shipper at another. Nothing about them changed. The system around them did.

Deloitte's 2025 Gen Z and Millennial Survey found a clean version of this. 42% of Gen Z workers believe managers should foster a positive work culture. Only 22% feel that it is actually happening. The gap is not in what Gen Z wants. It is in what most systems deliver.

Across the engineering teams I have worked with and watched, Gen Z engineers do not struggle with work. They struggle with environments where decisions move slowly for no clear reason. Where it is unclear who actually decides what. Where impact is invisible.

If you have ever sat in a one-hour meeting that ended without a decision, only to find out later the decision happened in a separate one-on-one, you already know the feeling. This generation is just less willing to put up with it.

Most companies respond with surface-level fixes. Beanbags. Hybrid policies. Pulse surveys. A feedback Slack channel nobody reads. But none of it touches the actual problem.

Three Behaviours That Show Up in Young Engineers When the System Gets Out of the Way

When the system does its job, three things show up consistently.

Speed becomes native. Gen Z engineers default to action. They would rather ship something and iterate than wait for three rounds of alignment. In a slow company, that instinct gets called 'moving without alignment.' At Procedure, decisions are not bottlenecked at one or two senior people. Context is shared widely, coordination happens laterally as much as vertically, and feedback comes back fast. Engineers move work forward directly with each other because ownership is clear and decisions are visible. The same instinct now just looks like shipping.

Someone on the team notices something off in a Tuesday demo, files a fix instantly, and the change is live before the next hour. In most companies, the same thing would be released two cycles later.

Ownership is claimed, not assigned. In a lot of organizations, ownership is tied to tenure: a senior engineer owns the architecture, a junior one owns the ticket. That has not held up here. When engineers are in the room when problems get framed and can see what their work does in production, they do not wait to be handed responsibility. They take it.

What this looks like day to day: a  while back, we gave one of our junior engineers a dashboard for managing a client’s eSign templates. The brief was deliberately thin. He had a Figma file, some context, and enough room to figure out the rest.

Instead of guessing the parts he did not understand, he traced the system himself and kept asking senior engineers questions from day one until the flow made sense. He also caught gaps in the designs, sorted them out with the designer before building, and carried the feature through review and QA until it shipped.

Nobody handed him that ownership. The brief was small, the room was open, and he took everything in between.

Feedback becomes infrastructure. Most performance systems run on a quarterly or annual cycle, which is a bad cadence for engineers in general. They want feedback close to the work, not three months later in a review form. So we built feedback into how the work moves. Code reviews carry a 24-hour SLA. Post-mortems happen within a week of any incident, blameless by default.

"Don't shoot the messenger" is our mantra here. When someone raises a problem, the focus stays on the problem, not on the person who raised it. It is what lets feedback come from anyone on the team, regardless of seniority.

Modern Engineering Culture Is a Set of Operating Rules, Not a Values Page

'Open culture' shows up on most careers pages with no real behavior behind it. At Procedure, it is a small set of working rules. Engineers are in system-level discussions early, not after a decision is made.

Decisions are documented as they happen, so disagreements get worked through where the next person can see them. Early versions are fine, sometimes encouraged, because shipping something rough beats waiting for perfect.

Anyone who joins figures out quickly that taking initiative gets rewarded, asking why is welcome, and surfacing a problem early is safer than hiding it. These are not values reserved for one generation. They are how the place works, and most of our Gen Z engineers were already operating this way before they joined.

How We Manage Gen Z Engineers: Direction, Not Control

Halfway through my friend's list, I realized what he was actually describing. When people say a Gen Z team is 'hard to manage,' what they usually mean is that the team does not defer easily. Engineers ask why. They push back on bad decisions. They do not just nod and execute.

That is not a management problem. That is a control problem. And in our experience, those are very different things.

Managing a team is about giving it direction, removing what gets in its way, and making sure people know what good looks like. Controlling a team is about deciding everything for them. Gen Z engineers respond to the first. They quietly leave the second.

In a company built around control, this team would look chaotic. In a company built around direction, the same team just looks productive. We follow up less because engineers are already chasing the next thing. Decisions move faster because more people can make them without waiting for approval. Work gets done without anyone supervising every step.

Overall, what works well is closer to calibration than supervision. Set direction, remove friction, share context, step back.

What Older and Younger Engineers Get Wrong About Each Other (and Why It Has Not Bitten Us)

In a lot of engineering organizations, the senior-junior dynamic costs the team real time. Both sides arrive with assumptions about each other, and those assumptions are usually wrong in predictable ways. We have not seen much of this at Procedure, where older and younger engineers tend to gel well, both at work and outside of it.

What older engineers tend to get wrong: they assume pushback means the junior engineer does not understand the constraints. More often, the junior engineer does understand and disagrees anyway. Treating disagreement as ignorance is one of the fastest ways to lose a strong young engineer. They will not argue with you. They will just stop bringing things up.

What younger engineers tend to get wrong: they assume process exists because nobody questioned it, and conflate 'this is slow' with 'this is broken.' More often, the process is absorbing a category of failure nobody on the team has personally experienced. The senior engineer who insists on a deployment checklist usually has a story behind it.

The teams that work well are the ones where the senior engineers are willing to say, "I do not know, let us try it", and the junior engineers are willing to say, "Tell me what broke last time." That conversation does not happen by accident. It happens when nobody is afraid of being wrong in front of the other.

The Trade-Offs of Running a High-Autonomy Engineering Team

This setup is not free, and it would be dishonest to pretend it is. Without enough structure, the same things that make this team fast can also break things.

Depth gets traded for speed. Context switching becomes a habit. When priorities change, mismatches surface faster than they would on a more deferential team.

We have not solved all of this. What we have built is the engineering discipline around it: 'done' is a written criterion, not a vibe, code reviews go after depth, not just style, and 'we shipped it too fast' is allowed to be the answer in a post-mortem if it is the right one.

What We Look For in Early-Career Engineers Instead of Resumes

Culture starts at the door, with what you select for. We have moved away from filtering on pedigree, years of experience, or brand-name companies. None of those signals tells us much about how someone will perform here.

What we look for instead: can the candidate explain their work clearly, do they have a bias toward action or only analyze, and how do they think when the problem is messy, and the answer is not obvious.

Those filters tend to surface people who do well in high-autonomy environments, and the age distribution that follows is a side effect, not the goal. This matters in India specifically. The World Economic Forum reports youth unemployment in India at around 17%, more than double the overall rate.

The market is full of strong candidates that brand-name filters miss. Some of our best engineers came from colleges no recruiter has heard of, from bootcamps, from self-taught GitHub trails. The filter that worked for Procedure 9 years ago does not work now, and the companies still using it are leaving real talent on the table.

How to Retain Gen Z Engineers Without Bending the Org Around Them

All of this circles back to the question my friend asked. That 82% is not a vanity metric, and not a recruiting flex. We did not set out to build a Gen Z-heavy team. We set out to build a place where engineers could ship without supervision, claim ownership without waiting for tenure, and learn fast enough for growth to compound.

The four-year drop in attrition is the part of that story I can put numbers on. The rest is what the place feels like to work inside.

Most retention strategies focus on keeping someone in the same role for longer. We have not had luck with that. What seems to work is making sure there is always a next interesting problem an engineer can move toward, whether that means a different part of the codebase, a different product surface, or a hard problem nobody on the team has tackled before.

A strong engineer's question is rarely 'should I leave,' it is 'what is next that will teach me something.' Companies that cannot answer that question lose people regardless of compensation.

The companies losing Gen Z engineers fastest are not losing them to compensation, or remote work, or TikTok. They are losing them to environments that have not been examined in years. If you are an engineer who would rather be calibrated than supervised, who wants to be in the room when problems get framed, we are probably looking for you.