How I navigated a company merger that tested both my technical skills and professional resilience
Last year, I found myself in what I initially thought was a dream scenario: working on a multi-tenant healthcare management system that had grown from a small proof-of-concept to serving 78+ active tenants. As one of the original developers who built the system from the ground up, I felt proud of what we'd accomplished with our small but efficient team.
Then came the merger.
The Technical Foundation We Built
Our journey started when our team lead decided to use an existing clinic management system as the foundation for a new public health center management platform. While the base code wasn't perfect—PHP 7.4, some anti-patterns, and legacy decisions—it was workable. When our lead eventually moved on, our small team of three developers inherited both the codebase and the responsibility of scaling it.
What we got right:
- Implemented Redis for caching and session management
- Containerized the entire application with Docker
- Optimized the infrastructure for easier deployment
- Built a multi-tenant architecture that could scale horizontally
What became challenging:
- All VMs pointing to a single database (classic bottleneck)
- 32 tenants running on a single 32-core VM (performance issues)
- No load balancer implementation yet
- Monolithic Laravel application serving both API and views
The performance issues were real. When you have 32 active healthcare facilities hitting the same VM simultaneously, even 32 cores aren't enough without proper load distribution.
The Merger Storm
Then our parent company decided to "optimize for efficiency." Multiple subsidiaries were consolidated into a single office space, divided only by room partitions. What should have been a smooth organizational restructure turned into a masterclass in how not to manage change.
The communication breakdown:
- No clear announcement about the merger timeline
- Job descriptions remained undefined for weeks
- Reporting structures were unclear
- Working hours weren't standardized (our team worked 9-5, others 8-5)
- No transition planning or documentation
Suddenly, we found ourselves in a larger organization with three distinct divisions:
- Research & Development - The innovation team
- Product Development - Building core features (where I ended up)
- Project Support - Handling live implementations and customizations
Red Flags That Made Me Nervous
During one of the first all-hands meetings with our new technical leadership, I heard statements that immediately raised red flags:
"We're going to build systems with zero errors."
While I appreciate the ambition for quality, anyone with real-world development experience knows that "zero errors" is an unrealistic goal. What's achievable is robust error handling, comprehensive monitoring, and quick recovery mechanisms.
"We'll create a framework that works for all programming languages."
This statement revealed a fundamental misunderstanding of how different programming languages work. Each language has its own paradigms, runtime environments, and ecosystems. What you can create are consistent design patterns, API standards, and architectural guidelines that adapt to different languages.
These statements, combined with feedback from colleagues who had worked with the incoming team, painted a picture of technical leadership that prioritized buzzwords over practical solutions.
The Performance Challenge: A Learning Experience
While dealing with organizational chaos, I still had real technical problems to solve. Our main application was struggling under load, and I needed to identify and fix the bottlenecks.
The diagnosis process:
- Database analysis - Confirmed that having all VMs hit a single database was creating a chokepoint
- Resource monitoring - Discovered that CPU wasn't the only constraint; memory and I/O were also factors
- Application profiling - Found several N+1 query problems and inefficient caching strategies
The solution approach:
- Implemented proper database connection pooling
- Added read replicas for reporting queries
- Optimized the most frequently used queries
- Planned for horizontal scaling rather than just vertical scaling
Key lesson: Sometimes the obvious solution (add more CPU cores) isn't the right solution. Performance problems are often architectural, not just resource-based.
Lessons Learned: Technical and Professional
Technical Insights
Multi-tenancy requires careful planning - Don't just throw more resources at performance problems. Design for scale from the beginning.
Monitor everything - You can't optimize what you don't measure. Implement comprehensive logging and monitoring before you have problems.
Database design matters - In a multi-tenant system, your database architecture will make or break your performance.
Professional Insights
Document your achievements - When organizational changes happen, having clear documentation of your contributions becomes crucial.
Communication gaps are red flags - If leadership can't clearly communicate changes, question whether they can lead effectively.
Technical competence matters - Be wary of leaders who make technically impossible promises or use buzzwords without understanding.
Know when to escalate - Sometimes you need to speak up about unrealistic expectations or poor communication.
What I Wish I'd Done Earlier
Looking back, there are several things I would have handled differently:
Technical preparation:
- Implemented load balancing and database clustering before performance became critical
- Created more comprehensive monitoring and alerting
- Documented the architecture decisions more thoroughly
Professional preparation:
- Asked more direct questions about the merger timeline and expectations
- Requested formal documentation of role changes and reporting structures
- Been more proactive about setting technical standards and expectations
Moving Forward: Practical Advice
If you find yourself in a similar situation, here's what I'd recommend:
For Technical Challenges
- Start with monitoring - You need data before you can make informed decisions
- Plan for horizontal scaling - Vertical scaling has limits
- Design for failure - Systems will have errors; plan for graceful degradation
- Choose technologies that fit your team's expertise - Don't chase trends if they don't solve real problems
For Organizational Challenges
- Ask direct questions - Don't assume things will "work themselves out"
- Document everything - Keep records of decisions, achievements, and concerns
- Set clear expectations - Be explicit about what's realistic and what isn't
- Have a backup plan - Know your market value and keep your options open
The Ongoing Journey
Mergers and organizational changes are part of the software development landscape. The key is maintaining your technical standards while navigating the human and political challenges that come with change.
Six months later, I'm still working through these challenges. Some have been resolved through better communication and clearer role definitions. Others remain ongoing negotiations between technical reality and business expectations.
The most important lesson? Your technical skills will get you through the day-to-day work, but your ability to communicate, set boundaries, and manage relationships will determine your long-term success.
What's your experience with company mergers or organizational changes? How do you balance technical excellence with organizational pressures? Share your thoughts in the comments below.
Top comments (0)