Hello, colleagues!
Today, I want to share a story that might sound familiar to some of you. This isn't a guide filled with textbook advice — it's an honest reflection on how I, someone with experience in IT but no deep background in development, tried to keep a team afloat as it tripled in size in just six months. Spoiler: it was painful, scary, but incredibly exciting.
Where It All Began: "Let’s Just Build an MVP!"
In 2019, a friend and now business partner asked me to lead a project for a Swedish logistics startup. I had no idea that managing development meant more than deadlines and meetings. Our team was tiny: two backend developers, one frontend dev, and a tester. The client seemed to know exactly what they wanted: “We need something simple, but it has to work.”
We started with hybrid Scrum — which is to say, no Scrum at all. Sprints? Retros? Backlogs? Never heard of them. We just built features on demand like mushrooms after rain. A year later, the MVP was ready. We launched. And then...
“Congrats, You Have Clients! Now Do Everything Faster.”
Loyal users quickly became demanding stakeholders. Feature requests snowballed. A three-person team couldn’t keep up. I was told, “We need to scale. Yesterday.”
First Pain Point: “Why Didn’t You Document Anything?”
Imagine hiring a new developer who looks at the code and asks, “Where’s the architecture documentation?” You point silently to a Google Drive folder with files like Feature_1_kinda.txt and Do_Not_Delete.xlsx.
That’s when my personal hell began. New hires spent weeks trying to understand the system. Lead developers, instead of coding, spent their days explaining the basics. I once found our team lead sketching a system diagram on a napkin — that was the “technical doc” for the newbie.
What saved us: We locked ourselves in for two weeks and built a knowledge base — not perfect, but unified. It included:
- A newbie guide: “How Not to Lose Your Mind in the First Days”
- Jira usage rules (turns out, “take a task into work” isn’t just a fairy tale phrase)
- Contact list of people who can help (from the tester to the guy who once wrote a UPS integration script)
It felt like assembling a 1000-piece puzzle in the dark. But once the documentation worked, I slept through the night for the first time in a month.
Second Drama: “We’re Waiting for Tasks. Where Are You?”
Before, I personally talked to the client, turned their “wants” into tasks, and tossed them to the devs. But as the team grew, chaos ensued. One day, everyone was busy. The next — silence. Developers looked at me like students whose teacher forgot the homework.
Turns out I was trying to be analyst, manager, and therapist all at once — and failing. I remember a frontend dev asking in a meeting: “What should we do after this task?” I replied, “Uhm… how about lunch?”
Our fix: We brought in a business analyst. Obvious in hindsight? Sure. Back then, I saw it as “extra costs.” It turned out to be salvation. Now, requirements came in well-structured, not just “build a button that solves everything.”
We also finally separated the “what” from the “how.” I stopped being a one-man band and focused on keeping the project together.
Act Three: “Why Does Your Code Look Like My School Notes?”
With two devs, coding styles can be aligned over lunch. With eight — every merge request became a battle of opinions. “Why spaces, not tabs?”, “Why use this pattern?” — I heard these even in my dreams.
One day, two seniors argued over variable naming. The tester went for a smoke and didn’t come back until the end of the day. I sat there thinking, “Are we really going to fail because of whitespace?”
What we did:
- Created an “Architecture Council” of three senior devs — our own Supreme Court for tech disputes. Every Friday, we met (with pizza and cookies) to resolve debates.
- Automated the boring stuff:
- Implemented ESLint and Prettier so code looked consistent — even if written by a robot;
- Set up automated checks — no more stuck PRs;
- Introduced the rule: “If no review after 24 hours — it’s auto-approved.”
It wasn’t perfect, but it worked. Fewer conflicts. The tester stopped hiding in the smoking area.
Fourth Lesson: “Why Doesn’t Anyone Read My Process Updates?”
We thought the worst was over — documentation done, analyst hired, code wars tamed. But then came the wild ride of process updates. We changed everything: meeting formats, Git rules, and more. It felt like trying to repaint a moving car.
What went wrong:
- Devs got confused: “Yesterday we wrote tests before code, today after. Tomorrow — maybe no tests at all?”
- A sense of helplessness: the team didn’t know how to raise issues. One backend dev once said, “I’ve wanted to tell you our CI/CD is broken for a month but didn’t know where to shout.”
We kept making changes like firefighters in a soap opera — solving one issue only to start three new ones. Processes buckled. I started thinking: “Maybe we should go back to the chaos?”
Our solution:
We stopped being “process dictators” and built a proposal system. Anyone — from interns to testers — could drop ideas in a special Slack channel: “Let’s do retros every two weeks,” or “Why haven’t we automated deployment yet?”
Once a month, we held a “Process Evolution Council” (we called it “PEC” and laughed). We reviewed the ideas, argued, drank coffee with cookies, and voted. Approved changes went into Confluence — no more verbal “until the next oops” agreements.
What changed:
- Devs stopped being afraid to say: “This isn’t working.”
- Processes became flexible but predictable — no more rules written midair;
- A tester once proposed API test automation — it cut bugs by 30%.
Epilogue: “Well, Duh!”
Now, re-reading my old notes, I laugh at how we overcomplicated things. It’s wild that we missed what now seems obvious:
- Processes are agreements, not laws. You can change them like a GPS route when the road’s blocked.
- The best ideas come from the trenches. The tester who silently endured a broken CI/CD was right: automating deployment saved us hundreds of hours.
- People are not resources. When a dev says, “I don’t think this works,” they’re not sabotaging — they’re trying to save the project.
I used to think a manager had to know everything. Now I know: their role is to create conditions where the team finds answers on their own.
What I Learned:
- Document everything, even if it seems obvious. I once spent a week explaining a script written by “that one Senior who quit.” Now we have a rule: if it’s done twice — it goes into the knowledge base.
- Don’t be afraid to delegate. That business analyst I thought was a “waste of money” became my right hand. And the Architecture Council saved us from endless style wars.
- Automate the boring stuff. ESLint, auto tests, CI/CD — these aren’t technical fancies, they’re your free time. And yes, devs will stop hating you for endless reviews.
- Change processes with the team. Our “PEC” with pizza and votes wasn’t just a meeting — it made everyone feel like: “My voice shapes the rules.”
The Most Important Thing:
Management is not about control — it’s about trust.
I used to think everything would collapse without my oversight. But it turned out: give people the tools, the docs, and a voice — and they’ll do even more than you expect.
Yes, we made mistakes. Yes, our processes changed five times a day. But it was this chaos that taught me the most important thing — flexibility. Now, when starting a new project, I don’t try to predict everything. Instead, I ask the team: “How do you want to work?”
And you know what? They always find an answer.
P.S.
If you're in a similar situation right now — take a deep breath. No one is born knowing how to scale a team. Start small: today, document one task. Tomorrow, ask the team what’s bothering them.
As my colleague used to say:
"People are like code. If you don’t break them, they can do wonders."
Hold on, and may your growth journey be full of not just challenges — but those moments when you suddenly realize:
“Damn, we’ve become a real team.”
Andrei Gorlov