For the first personal post on this blog, I thought about what to write. I landed on this: a book I read while wrestling with questions about growth and agile at work, and the reflections it stirred up.
How satisfied are you with your life right now? Is today's routine the life you once dreamed of — richer and better than before?
For me, 2025 was a turning point. It was the year I seriously asked myself what kind of developer I want to be, and what kind of life I want to live.
After spending about four years at one company — shipping projects big and small, and even getting to try my hand at leading a team as a middle manager — something quietly nagged at me.
I was accumulating years as a mid-level developer, moving beyond being the junior who just executes assigned tasks, but there was always a subtle dissatisfaction in the back of my mind.
What would it be like to work inside a larger organization? If there were senior developers on the team, how could I absorb their insights and take the leap to become one myself? The company's product domain made it hard to encounter large-scale traffic or complex business scenarios — how could I fill that gap?
As these questions grew louder, I realized: I didn't want to be content with where I was. I wanted to keep growing.
That's when a book I'd received as a gift came back to mind. At the end of 2024, our dev team had a little event where we exchanged meaningful books at random.
The book: Growing Together: The Road to Agile by Kim Chang-jun (Insight, 2018).
One of the smartest team member I know — someone who'd read it back in university — recommended it wholeheartedly. I finally picked it up, and it hit me hard. I'm writing this so I can come back to it whenever I need to reset my mindset.
About the Book
Kim Chang-jun is the founder of Agile Consulting, widely known for bringing agile practices and coaching into Korean development organizations.
The subtitle says "The Road to Agile," but the book itself barely touches on frameworks like Scrum or Kanban. Instead, it spends the vast majority of its pages on something more fundamental: why agile is even necessary, and the deeper ideas beneath it — individual learning and organizational collaboration.
The book is divided into three parts:
- Growing — How does an individual grow?
- Together — How do you scale that growth across a team?
- Agile — Why does all of this converge on agile as a response to uncertainty?
Book Review
Part 1. Growing → Am I actually growing in an environment that lets me?
The author opens by dismantling a comfortable assumption: years of experience do not equal capability. Drawing on research, he shows that the gap between a new hire and a second-year developer is significant — but between a five-year and a ten-year developer, there's hardly any difference at all.
What matters isn't how long you've been doing it, but how varied and deep your experiences have been.
That landed like a punch to the gut. As a five-year developer, was I meaningfully ahead of a two or three-year developer? Had my experiences been truly dense and diverse? I had to look back honestly.
After finishing the book and revisiting my resume, I felt fairly confident that the volume of my experience wasn't lacking. But what stayed with me was this: time spent doesn't equal growth. What counts is the quality and depth of those experiences — and that's something to keep guarding.
The author's core concept for building a real skill gap is Deliberate Practice. Simply repeating tasks isn't enough. Growth requires short feedback loops and opportunities to correct mistakes. The key variable, he argues, is how well you match the difficulty of the task to your current skill level — and here he brings in psychologist Mihaly Csikszentmihalyi's Flow theory to make the point stick.
- If the work feels boring → restrict your tools to raise the difficulty (a1), or raise the bar by picking up a new language or harder goal (a2)
- If the work feels overwhelming → seek expert advice or try pair programming to level up your skills (b2), or start with a prototype to bring the difficulty down (b1)
To enter a state of flow, your skill level and the task's difficulty need to be in harmony. Too easy, and you feel boredom. Too hard, and anxiety takes over.
I'm someone who feels growth most vividly when I'm in flow — that sense of being fully absorbed and alive in the work. Looking back, I think I'd been unconsciously trying to trace that straight line of flow throughout my career.
Porting a system to a new language to break through its architectural limits, or tackling multiple bottlenecks one by one until microservice architecture was viable — those are real examples of reaching for a higher difficulty to stay in the zone.
But one problem never quite resolved itself: maintaining that flow on my own has a ceiling. I could pick up new languages, set higher personal goals — but inside a small dev team with no senior engineers to turn to, I couldn't shake the feeling that my perspective was getting narrow.
If someone had asked me to design a system capable of processing tens of millions of records in real time, or architect a more robust and systematic supporting service, I'd probably have been about as capable as a junior. My ability to self-generate difficulty had hit a wall.
That's how I arrived at this conclusion: to keep growing and staying in flow, individual effort alone isn't enough — sometimes you need to change the environment itself. Moving to a place where the scale of the problems I'm immersed in is simply different. That's what ultimately drove my decision to make a career move.
Part 2. Together → Building trust as infrastructure
Part 2 goes beyond individual growth to ask: how do you propagate that growth across an entire team?
The central keyword here is trust. The author explains that trust emerges from transparency, information sharing, and sustained mutual interaction. The concept that best captures this is osmotic communication — the idea that when people share the same space and context, the information they need seeps through naturally, without anyone having to push it deliberately.
Trust matters in every organization, but I believe it's especially critical in small ones — like startups. I've learned from experience that genuine collective intelligence, even with a lean team, only becomes possible when everyone shares the same context and keeps interacting consistently.
On the question of persuasion, the author offers a sharp warning: remember that objectivity is relative. No matter how logically correct your argument is, you'll fail to persuade if you haven't first made the effort to understand the other person.
He also punctures a common myth: the expert team trap. Gathering a room full of brilliant developers doesn't automatically make a great team. Research cited in the book shows that truly excellent developers consistently name collaboration with peers as a key factor in their success — while more average developers tend not to. Ultimately, what separates high-performing teams isn't individual talent but psychological safety and a culture of collaboration.
In the age of rapidly advancing AI, this idea of "collaboration" feels more universally important than ever. Just as effective AI collaboration requires structured context, well-configured tools like MCP, and deliberate prompt engineering — meaningful collaboration with teammates demands active communication, honest feedback, and genuine cooperation.
Part 3. Agile → What's the right posture in the face of uncertainty?
Only in Part 3 does the subtitle's "agile" step into the spotlight. The author's definition is disarmingly simple:
Agile is the approach you need when uncertainty is high.
If your goal and method are already clear, you don't need agile. A dense, well-executed plan works better. But when you're not even sure what you're building — when the problem itself is murky — you need frequent contact with users, shared code and knowledge, and tight feedback loops to keep course-correcting. That's why agile exists.
What the author guards against is what he calls doing agile in an anti-agile way — bolting the surface rituals of agile methodology (standups, sprints, retrospectives) onto work that's already clearly defined. Agile isn't a tool. It's more like an attitude — one that distills everything covered in Parts 1 and 2: learning and collaboration.
For about a year, I held a part lead and Scrum Master role on a team. I remember sitting with the uncertainty of half-formed ideas and vague requirements at the start of each sprint, trying to translate them into tasks clear enough for the team to act on. A company I'd worked at briefly before had a very different approach to running sprints — reading this book gave me a much clearer lens on what it means to actually operate in an agile way.
Closing
I received the book in late December 2024, but — with the usual excuses of being caught up in life — I didn't finish it until November 2025. I've been pulling it back off the shelf occasionally since then, whenever I need a motivation reset. It felt about time to put these thoughts into writing and share them.
If there's one line to distill Growing Together — The Road to Agile, I'd put it this way: "growing well" rests on three axes — difficulty (flow), trust (collaboration), and uncertainty (agile).
Deciding to acknowledge the ceiling of what I could do alone and change my environment, the time I spent trying to build trust within a team, the effort to strip away uncertainty at every sprint — looking back through this book, I can see that all of it was part of the same ongoing process: continuing to grow.
Revisiting these years through writing, I find myself both excited and a little nervous about how this next chapter will unfold — how much I'll grow in a new environment, and what shape that growth will take. It's a good kind of tension. And a reminder: don't lose this mindset. Keep growing — together.
Are you actively shaping the right level of difficulty for yourself to find flow? Are you moving into the future — agile, growing, together?
I recommend this book to anyone sitting with these same questions. We're all in it together — let's keep going.