What Happens When Your Dev Team Has No Process or Docs?

The last few days I've been thinking a lot about processes: the things teams do and don't do inside their organizations, and how that quietly impacts them. One situation I see over and over is a struggling team that's simply told "do this," with no real organization behind the ask. No structure, no processes, no documentation. Just "we need to move this along, but we're not willing to commit to it."

That's a dangerous position for a company, and most companies don't recognize it right away. The costs show up later, and they show up in ways that are hard to trace back to the real cause. So I want to walk through what actually happens, using a project I lived through, and what I'd tell any owner or manager to do about it.

---

What does working without documentation actually look like?

Years ago I was thrown into a project with instructions that amounted to: here's the idea, here's what we need done, you have nine months, good luck.

It was a mobile front-end project, a complete redesign of an existing app, moving it from Xamarin to React Native. There was no documentation for the application. None for the API or backend work either. I had no guide for what the app needed to be, and no real picture of what it was supposed to look like beyond "take the Xamarin app and rebuild it."

So before I could build anything, I had to figure out what the application even did. I had a high-level overview, but every individual screen had its own feature, if not several. Some screens opened into whole additional flows, so what looked like five tabs with five features turned out to be five screens, each with features, each with their own sub-features that had to be understood and accounted for.

The app I was handed versus the app that was actually there. Without documentation, the real scope only reveals itself one screen at a time.

Here's the part that mattered and that nobody saw at the time: without that documentation, I couldn't tell which parts of the app were important. I ended up spending early effort on things that weren't as relevant, simply because I had no way to know better. The cost of missing docs wasn't just my reverse-engineering time. It was months of slightly wrong priorities.

If you want the technical side of how a migration like that should be run, I wrote a full Xamarin to React Native migration playbook. This post is about the organizational failure underneath, because that failure isn't specific to migrations.

Why does documentation matter more than you think?

Companies quietly operate on the hope that their people will stay forever. They won't. Developers, managers, product owners, they all leave, and in today's market most of them leave for better salaries. Even the ones who stay a long time only do so because they truly believe in the company's vision; someone who doesn't connect with your culture will leave much sooner. If your company can't handle a departure, that's not the employee's failure to stay, that's your failure to prepare.

Preparing means one unglamorous thing: when a team builds a new feature, fixes bugs, or updates a process, it gets documented. There's no way around it. And the timing matters more than people realize, because the longer you put off writing down why something was done, the harder it becomes for anyone to remember the exact reasons.

Here's how the failure sounds in practice. I've joined teams, asked why something is done a certain way, and gotten "because that's the way we've always done it." Okay: who implemented it? I'd genuinely like to know what they were thinking, because maybe they understood something I don't before I go changing their process. "No idea, that person doesn't work here anymore."

"Why do we do it this way?" is a fork in the road. Documentation is what decides which branch you're on.

At that point "it's always been done this way" isn't a justification, it's an admission. The reasoning walked out the door with the person. When the why is written down, you can iterate on a process, which is dramatically easier and safer than ripping it out and starting over because nobody knows what it was protecting against.

Why do teams resist better processes?

Change is hard, and development teams are no strangers to that. I've brought new processes to teams that flat-out didn't want them, either because they didn't like the idea or because they were so accustomed to their existing systems that they wanted to keep them. And honestly, their systems worked, in the sense that things got done.

But okay is not good enough, and it should never be good enough, whether the person defending it is the newest junior dev or the CTO. Teams should always be pushing toward better processes and better opportunities in their applications and their code. That's my stance, and I hold it strongly: settling for "it works" is how a team stops improving.

Should a process ever be permanent?

No, and this cuts against something I catch myself doing. I'll come into a team with no process at all, put one in place, and present it like it's forever. It isn't. As I get acclimated to the team, as things evolve, which they will in any company, the process should be able to change too.

A process exists because there was a problem and this was the solution. That's its whole claim to authority. If the problem changes, iterate. If it needs to change slowly, fine; if it needs to change quickly, make that happen with the least disruption possible to the team and the application. What a process should never be is a monument.

What about leaders who won't get on board?

This is the uncomfortable part, and I'll say it plainly: if you have a leader who is unwilling to document, unwilling to accept process, unwilling to have their approach questioned, you need to move them out of that position quickly. Keeping them around is a huge detriment to the team.

And it runs the other direction too. If your whole team is aligned on what the best process is, and one person above them, a CTO, a director, a manager, is the lone voice insisting otherwise, that's worth taking seriously. Don't get me wrong: a lot of directors and CTOs genuinely have the vision, and much of what they say deserves attention. But they're not always directly involved with the team's day-to-day, and throwing in a mandate without explaining why, or how it benefits the team, is its own process failure. If a process just needs fine-tuning, have that conversation instead of decreeing a replacement.

You can't walk in saying "this is what we're going to do" and hope for the best. That's the same "we need to move this along but we're not willing to commit to it" posture from the top. The commitment is the conversation: explain the reasoning, write it down, and leave room for the team to iterate. Companies need to keep building processes and documenting them, and teams need to be genuinely willing to take them on.

These are working thoughts from a couple of decades of being dropped into teams at every level of process maturity, and some of it is opinionated; where you draw the line on a resistant leader is a judgment call I can't make for you. But the core of it I'm confident in: document as you go, treat every process as a solution rather than a monument, and never let "that's how we've always done it" stand in for a reason. I think that's more true than not.