In this blog post, we explore how one of our partners’ projects, which we have been collaborating on since 2016, successfully scaled communication as our team expanded from a small group to a large, distributed team of developers. These strategies offer valuable lessons for any software team navigating similar growth.
The Challenges of Scaling Communication in Distributed Software Teams
Our collaboration with this client started as a modest project with just a few developers from our team. Communication was straightforward, and roles were flexible. However, as the software gained traction, our team expanded from 2 developers to over 25, bringing new challenges, particularly in maintaining effective communication and defining clear roles within a growing, geographically dispersed team.
A recent report by GitLab shows that 84% of software developers believe clear communication is crucial for team success in a distributed environment. Our experience in the project reflects this, as the sudden increase in team size made it difficult to keep everyone aligned and informed.
Effective Strategies for Communication in Growing Teams
To address these challenges, our team rolled out some key strategies to scale communication effectively:
1. Dedicated Communication Channels
We set up new Slack channels to streamline discussions by topic and urgency. This helped team members focus on relevant conversations and avoid information overload.
2. Focused Meetings with a Facilitator
We refined our daily stand-ups to deliver quick, high-level updates, ensuring the whole team stayed informed. For critical tasks, we formed smaller, cross-functional groups that met regularly to dive deeper into the project’s most important aspects.
To keep these meetings efficient, we introduced the role of a facilitator—someone responsible for keeping discussions on track, making sure everyone has a chance to contribute, and clearly define follow-up actions. This approach was essential in keeping the team productive and communication flowing smoothly.
3. Travel Regularly for In-Person Meetings
Recognizing that nothing beats face-to-face interaction, we made it a priority to meet our partner and their team in person. We traveled to the United States to start our partnership in a healthy way, having the chance to dive deeper into their needs and aligning on project goals.
But it wasn’t all work and no play. These trips gave us the chance to bond after hours, sharing good times that helped build a strong team spirit rooted in trust. By closing the physical gap, we not only ensured a more productive collaboration but also made the process more enjoyable for everyone involved. After all, a team that works well together and has fun together is unstoppable!
Developing Roles and Maintaining Clarity in Distributed Teams
As the team grew, it became clear that the informal role distribution that had worked in the past was no longer sufficient. New responsibilities emerged, and specialized roles were necessary to handle them. However, assigning these roles and ensuring that team members were prepared for their new responsibilities required careful planning.
1. Natural Role Evolution
Roles on this project weren’t rigidly assigned. Instead, as new needs emerged, team members who showed both interest and aptitude naturally stepped into these roles. A key figure in this process was the Jedi Master, one of our principal engineers, who had been with the project since the beginning. The Jedi Master played a crucial role in mentoring team members, guiding them through their transitions, and ensuring they felt supported as they took on new responsibilities.
2. Progressive Responsibility
Under the Jedi Master’s guidance, team members gradually took on new roles. As they gained experience, Jedi’s involvement decreased, allowing the new leaders to fully embrace their responsibilities.
3. Structured Onboarding and Training
We implemented a comprehensive onboarding process for new team members, including a set of courses and tasks tailored to the project’s needs. Continuous feedback and opportunities for new members to suggest improvements helped them integrate smoothly and contribute effectively from the start.
Measuring Success: The Impact on SmartBorder
The strategies implemented at this project resulted in a well-coordinated, efficient team capable of handling the complexities of a large-scale software project. Communication became more streamlined, roles were clearly defined, and team members were well-prepared to meet the demands of their positions.
This approach not only maintained the quality of the codebase but also strengthened our team’s relationship with our partner. The quality of the product remained high, with functionalities behaving as expected, thanks to the effective communication and role management strategies in place.
Key Takeaways for Scaling Communication in Software Development
This experience highlights several key takeaways for managing a growing software development team:
Effective communication is vital at every stage of growth. As a team expands, it’s crucial to revisit and refine communication channels to ensure they remain efficient and effective.
Roles should evolve naturally but with guidance. Allow team members to grow into new roles, but provide the necessary mentorship to ensure they succeed.
Training and onboarding are ongoing processes. Continuous improvement in training programs helps new team members integrate smoothly and contribute effectively from the start.
Client relationships benefit from strong internal processes. A well-organized, communicative team translates into a smoother, more transparent relationship with the client, ultimately leading to a better final product.
Conclusion
Scaling a software development team is challenging, but with the right strategies in place, it’s possible to manage growth without sacrificing quality. Our experience with this project demonstrates the importance of evolving communication, defining roles carefully, and investing in team development to ensure long-term success.
In this blog post, we explore how one of our partners’ projects, which we have been collaborating on since 2016, successfully scaled communication as our team expanded from a small group to a large, distributed team of developers. These strategies offer valuable lessons for any software team navigating similar growth.
The Challenges of Scaling Communication in Distributed Software Teams
Our collaboration with this client started as a modest project with just a few developers from our team. Communication was straightforward, and roles were flexible. However, as the software gained traction, our team expanded from 2 developers to over 25, bringing new challenges, particularly in maintaining effective communication and defining clear roles within a growing, geographically dispersed team.
A recent report by GitLab shows that 84% of software developers believe clear communication is crucial for team success in a distributed environment. Our experience in the project reflects this, as the sudden increase in team size made it difficult to keep everyone aligned and informed.
Effective Strategies for Communication in Growing Teams
To address these challenges, our team rolled out some key strategies to scale communication effectively:
1. Dedicated Communication Channels
We set up new Slack channels to streamline discussions by topic and urgency. This helped team members focus on relevant conversations and avoid information overload.
2. Focused Meetings with a Facilitator
We refined our daily stand-ups to deliver quick, high-level updates, ensuring the whole team stayed informed. For critical tasks, we formed smaller, cross-functional groups that met regularly to dive deeper into the project’s most important aspects.
To keep these meetings efficient, we introduced the role of a facilitator—someone responsible for keeping discussions on track, making sure everyone has a chance to contribute, and clearly define follow-up actions. This approach was essential in keeping the team productive and communication flowing smoothly.
3. Travel Regularly for In-Person Meetings
Recognizing that nothing beats face-to-face interaction, we made it a priority to meet our partner and their team in person. We traveled to the United States to start our partnership in a healthy way, having the chance to dive deeper into their needs and aligning on project goals.
But it wasn’t all work and no play. These trips gave us the chance to bond after hours, sharing good times that helped build a strong team spirit rooted in trust. By closing the physical gap, we not only ensured a more productive collaboration but also made the process more enjoyable for everyone involved. After all, a team that works well together and has fun together is unstoppable!
Developing Roles and Maintaining Clarity in Distributed Teams
As the team grew, it became clear that the informal role distribution that had worked in the past was no longer sufficient. New responsibilities emerged, and specialized roles were necessary to handle them. However, assigning these roles and ensuring that team members were prepared for their new responsibilities required careful planning.
1. Natural Role Evolution
Roles on this project weren’t rigidly assigned. Instead, as new needs emerged, team members who showed both interest and aptitude naturally stepped into these roles. A key figure in this process was the Jedi Master, one of our principal engineers, who had been with the project since the beginning. The Jedi Master played a crucial role in mentoring team members, guiding them through their transitions, and ensuring they felt supported as they took on new responsibilities.
2. Progressive Responsibility
Under the Jedi Master’s guidance, team members gradually took on new roles. As they gained experience, Jedi’s involvement decreased, allowing the new leaders to fully embrace their responsibilities.
3. Structured Onboarding and Training
We implemented a comprehensive onboarding process for new team members, including a set of courses and tasks tailored to the project’s needs. Continuous feedback and opportunities for new members to suggest improvements helped them integrate smoothly and contribute effectively from the start.
Measuring Success: The Impact on SmartBorder
The strategies implemented at this project resulted in a well-coordinated, efficient team capable of handling the complexities of a large-scale software project. Communication became more streamlined, roles were clearly defined, and team members were well-prepared to meet the demands of their positions.
This approach not only maintained the quality of the codebase but also strengthened our team’s relationship with our partner. The quality of the product remained high, with functionalities behaving as expected, thanks to the effective communication and role management strategies in place.
Key Takeaways for Scaling Communication in Software Development
This experience highlights several key takeaways for managing a growing software development team:
Effective communication is vital at every stage of growth. As a team expands, it’s crucial to revisit and refine communication channels to ensure they remain efficient and effective.
Roles should evolve naturally but with guidance. Allow team members to grow into new roles, but provide the necessary mentorship to ensure they succeed.
Training and onboarding are ongoing processes. Continuous improvement in training programs helps new team members integrate smoothly and contribute effectively from the start.
Client relationships benefit from strong internal processes. A well-organized, communicative team translates into a smoother, more transparent relationship with the client, ultimately leading to a better final product.
Conclusion
Scaling a software development team is challenging, but with the right strategies in place, it’s possible to manage growth without sacrificing quality. Our experience with this project demonstrates the importance of evolving communication, defining roles carefully, and investing in team development to ensure long-term success.
Applying changes across microservices is difficult because business logic is distributed across multiple services, each with its own data, contracts, and responsibilities.
In our experiment at Kaizen Softworks, we tested whether an AI system could safely apply coordinated changes across a microservices architecture using only minimal input.
Short answer: Yes, but only when the AI has enough architectural context.
Why are coordinated changes in microservices so hard?
In distributed systems, a single business change rarely affects just one service.
It often requires:
Updating multiple microservices
Modifying message contracts
Keeping DTOs (Data Transfer Objects) consistent
Respecting domain boundaries defined by Domain-Driven Design (DDD)
Key entities in this system:
Microservice: An independently deployable service responsible for a specific domain
Aggregate (DDD): A cluster of domain objects treated as a single unit
DTO (Data Transfer Object): A structured format used to transfer data between services
Message/Event: A communication mechanism between services
The complexity is not in the code, it’s in the relationships between components.
The experiment: Can AI reason across services with minimal input?
We designed a controlled experiment to test whether an AI model could apply system-wide changes with limited information.
Input given to the AI:
Message definitions (events between services)
DTOs (data contracts)
Tasks the AI had to perform:
Identify affected aggregates
Determine service ownership
Apply coordinated changes across services
Maintain consistency in messages and DTOs
In other words, the AI had to behave like a software architect, not just a code generator.
What was the biggest obstacle?
The biggest challenge was not technical, it was contextual.
Problem: unclear service naming
Instead of descriptive names like:
order-service
billing-service
Our services were named:
john
sally
roger
This removed any semantic clues about responsibility.
Result: The AI could not infer which service owned which domain logic.
The missing piece: aggregate ownership mapping
To solve this, we introduced a simple but powerful structure:
Aggregate → Service mapping
Order → john
Shipment → sally
Invoice → roger
This created a clear relationship between domain concepts and system components.
Once ownership was explicit, the architecture became understandable.
How we used AI to generate architectural context
Instead of building this mapping manually, we used AI to analyze the codebase and extract:
Where each aggregate was defined
Which microservice implemented it
The relationship between domain and infrastructure
The result was a machine-readable architecture map.
In practice, we used AI to generate the context that AI itself needed.
Results: Can AI safely apply distributed changes?
With the architecture map in place, the AI was able to:
Trace message flows across services
Identify affected aggregates
Locate the correct microservices
Apply coordinated updates
Maintain consistency between DTOs and messages
While not perfect, the system worked reliably as a proof of concept.
What is the real limitation of AI in microservices?
The main limitation of AI is not code generation, it’s architectural understanding.
Without knowing:
Which components exist
How they relate
Who owns what
AI cannot safely modify a distributed system.
AI performance depends more on context quality than model capability.
When can AI safely modify microservices?
AI works well when:
Aggregate ownership is clearly defined
Message contracts are explicit
Architecture is structured and consistent
AI struggles when:
Naming is ambiguous
Relationships are implicit
Context is incomplete
Simple rule: If the architecture is clear, AI can reason. If not, it guesses.
Final thoughts
This experiment revealed something important:
AI doesn’t fail because it can’t write code. It fails because it can’t see the system.
As teams move toward AI-assisted development, the focus will likely shift from:
Writing better code to Designing better systems for machines to understand
At Kaizen Softworks, we see this as a foundational shift.
Because when AI can understand architecture, it doesn’t just generate code, it helps evolve systems.
There's a myth that in flat organizations, everyone decides on everything.
That's not how it works. At least not at Kaizen.
When people hear "no managers," they often picture one of two extremes: either total chaos where nobody is accountable, or endless meetings where 80 people vote on which coffee to buy. The reality is neither.
Not everyone decides on everything. Not everyone votes. What we do have is a clear set of decision-making methods that we choose based on context.
It depends on who's affected and how deep the impact goes
Before choosing how to decide, we ask ourselves a few questions:
Who is affected? A decision that only impacts one team doesn't need the whole company involved. A decision that affects everyone's daily work does.
How deep is the impact? Changing the office furniture is wide but shallow. Changing the salary model is deep and lasting.
Is it reversible? If we can easily undo it, we can move fast and just inform. If it's hard to reverse, we slow down and include more people.
How urgent is it? And here we're careful to distinguish real urgency from anxiety, the pressure to decide quickly because someone already has "the answer" in mind.
These dimensions help us pick the right method. Not every decision deserves the same process.
Our decision-making toolkit
Over the years, we've landed on a few methods that we use depending on the situation:
1. Role-based decisions
Some decisions belong to a specific role. If someone owns a responsibility, say, office logistics or hiring for a team, they decide within that domain. No committee needed. The key is that roles are transparent: everyone knows who owns what, and the scope of each role's authority is clear.
2. Advice Process
When a decision doesn't clearly belong to one role, or when it crosses boundaries, we use the advice process. Here's how it works:
Someone takes the initiative. They identify the problem and own the process.
They gather input from people who are affected and people with expertise.
They seek advice, real conversations, not rubber-stamping.
They make the decision and communicate it, including what advice they incorporated and what they didn't (and why).
The decision-maker is not a committee. It's one person (or a small group) who takes responsibility. But they don't decide in isolation, they bring in the perspectives that matter.
We sometimes call this "Team Advice" when a working group forms around an issue that doesn't naturally fall into anyone's area, and "Area Advice" when a team opens up a topic that exceeds their own scope.
3. Consent (not consensus)
Consent is not "everyone agrees." Consent means "no one has a strong enough objection to block this." We do use a poll, but not to count votes — we use a 1-to-5 scale to measure the level of agreement and surface objections, not to let the majority rule.
We use it in two flavors:
High-participation consent: For decisions with deep, company-wide impact. This is our most expensive and slowest method, which is exactly why we reserve it for high-impact decisions that affect many people. The Board sets the boundaries, for example, when we moved offices, they defined the monthly budget. Then a working group produced proposals, collected feedback, evolved them, and the whole company expressed their position for the final decision. Silence is not approval; we explicitly ask people to weigh in, even if it's just "I have no objection."
Lightweight consent: For decisions that are broad but not deep. Participation is optional, anyone who's interested can jump in. We share the proposal, open a window for objections, and if nobody opposes, we move forward. This gives us speed without sacrificing transparency. If nobody engages, that's a signal too, maybe the proposal doesn't add enough value, or we're using the wrong channel.
4. Inform, don't fake-consult
Not everything needs participation. When a decision has already been made through a legitimate process, the right move is to inform, not to fake-consult. One of the fastest ways to kill self-management is to ask for feedback and then ignore it. If you're not going to change course based on input, don't ask for it, just be transparent about the decision and the reasons behind it.
What we explicitly avoid
Decision by Voting. In a company context, majority rule creates losers. And losers become detractors, often generating more resistance than an autocratic decision would have. Instead of voting, we prefer to evolve a proposal through feedback until it's "good enough for now," and then introduce a review point to adjust later. If voting happens at all, it's the cherry on top, not the main course.
The "surprise" approach. Working behind closed doors and then unveiling a finished decision is a recipe for frustration. Adults don't need surprises. Adults need to feel like they're part of the process. The complaints that follow a surprise aren't about the decision itself, they're about not being included.
Why we work this way
We didn't adopt these methods because they're trendy. We adopted them because they solve real problems:
Better decisions. When you include affected people, you get information you wouldn't have had otherwise. Ideas emerge that no single person would have come up with alone.
Less resistance. A person who feels heard is far less likely to resist a decision, even one they wouldn't have made themselves.
Faster execution. It sounds counterintuitive, but participative decisions often execute faster because people already understand and support them. The time you "save" by deciding alone, you spend later managing pushback.
Distributed authority. When people can make decisions within their domain without escalating everything to a founder, the organization scales. The bottleneck disappears.
Resilience. If a shared decision fails, the group adjusts together. If a top-down decision fails, the blame falls on one person and the chances of proactive correction drop.
The real principle behind all of this
Transparency is the foundation. Every method we use, from role-based decisions to high-participation consent, works because information flows openly. People know what's being decided, who's deciding it, and how they can participate.
Horizontal doesn't mean structureless. It means fewer hierarchical levels, clearer roles, and intentional decision-making processes that match the weight of each decision.
Not everyone decides on everything. But everyone knows how things get decided.
.png)
