Originally published on August 26, 2022

In my last post, I described the arc most software companies follow—from chaotic startup to process-heavy bureaucracy. If you missed it, check it out here: An Evolution of a Software Company. Spoiler: there’s a pendulum, and it swings hard.

Today, we’re talking about what happens next—and how to stop the pendulum from turning your team into a JIRA-powered approval queue.

From Chaos to Control

By the time the dust settles, you’ve landed in a company that’s seen one too many outages and decided that the cure is process. Lots of it.

Checklists. Review gates. Sign-off spreadsheets. “Readiness assessments.” Release Thursdays.

In this world, the relationship between the business and the development team starts to resemble a parent-child dynamic. Developers must ask permission to ship, explain themselves when something breaks, and promise they’ll do better next time.

The result? Fear. Delay. And a team that’s so busy managing risk, they forget how to manage velocity.

So How Do You Swing Back?

There’s no one magic ceremony that resets this dynamic. But I’ve found it usually comes down to two core ingredients:

Communication.
Trust.

In that order. Because trust doesn’t show up because you asked for it. It shows up because you earned it.

Start With Communication (The Boring Kind That Works)

If your early product work came with a side of cut corners and late-night patching, your stakeholders are probably still flinching.

It’s your job now to reduce flinch. That means:

  • Engage stakeholders early and often (even when they’re busy)
  • Run short, frequent demos. No polish. Just working software.
  • Don’t hide behind JIRA. Explain what you’re building—and why
  • Be honest about trade-offs and technical debt

In a perfect world, you’d have a product owner sitting next to you. In the real one, you might get five minutes a week via Slack.

Use them well. Ask better questions. Show working code. Prove you’re solving the right problem.

Make Your Process Visible (and Sane)

When trust is low, people imagine the worst. So if you’re not communicating your internal practices, don’t be surprised when someone suggests mandatory change review boards.

Show your process before someone else writes one for you.

  • Walk through how your team plans, builds, tests, and releases
  • Keep it lean. Show where quality checks live
  • Demonstrate ownership over your own codebase and deploys

Your job isn’t to convince the business that nothing will ever go wrong again. Your job is to show them you’re acting like professionals, not unsupervised kids.

“We don’t need a 42-step release checklist because we already catch problems in CI, pair on risky changes, and deploy behind feature flags.”

That’s the kind of sentence that earns freedom.

Then Comes Trust (Slowly, Quietly)

You can’t force trust. But you can build it the long way.

Every time you release something safely, deliver what you said you would, or proactively flag an issue before it hits prod, trust grows.

Eventually, something shifts.

The business stops asking “Is this ready?” and starts asking “When can we have it?”

The relationship flips—from parent/child to partners. You’re not begging for approval anymore. You’re collaborating to make things better.

The Endgame: Autonomy with Accountability

At this point, you can stop asking for permission to deploy. You notify stakeholders after the release, not before. You keep them looped in—not looped over.

They trust you to do your job. You trust them to tell you what matters.

That’s when the pendulum finally stops swinging. And you can get back to what you were hired to do:

Build great software. Ship with confidence. Sleep at night.