Scaling and Leading Tech Teams in Startup vs. Enterprise Organizations — Open Source CXO Ep. 8 | Active Logic
In the first of two episodes with Shahzad Zafar, CTO at Trualta, the conversation covers one of the most consequential challenges in technology leadership: how to scale and lead engineering teams across fundamentally different organizational contexts. Shahzad brings a rare perspective — his career spans Cerner (a healthcare technology enterprise with thousands of engineers), Rx Savings Solutions (a high-growth startup), and now Trualta (an early-stage healthcare technology company). He’s led teams at every scale and has direct experience with the trade-offs that each stage demands.
This isn’t a theoretical discussion about organizational design. It’s a practical conversation about what changes when you go from leading a team of five to leading an organization of hundreds — and what stays the same. Shahzad is candid about the mistakes he’s made, the assumptions he carried from one context to another that didn’t apply, and the leadership adaptations that made the biggest difference at each stage of growth.
The episode also covers Shahzad’s experience in healthcare technology specifically, including the unique constraints that regulated industries impose on engineering teams, hiring philosophy across different company sizes, and how remote work culture has evolved in his experience from enterprise to startup contexts.
Key Insight: The Fundamental Differences Between Startup and Enterprise Engineering
The gap between startup and enterprise engineering isn’t just about team size — it’s about fundamentally different operating constraints, decision-making velocities, and risk tolerances. Shahzad has operated at both ends of the spectrum and describes the differences with specificity.
At Cerner, engineering decisions were made within a complex organizational context. Every technical choice had downstream implications for compliance, integration, security, and cross-team dependencies. Decision-making was necessarily slower because the blast radius of mistakes was enormous — a bad architectural choice could affect thousands of healthcare providers and millions of patient records. Process existed not because leadership loved bureaucracy, but because the cost of errors demanded structured risk management.
At Trualta, the operating reality is entirely different. Speed matters more than process. The engineering team is small enough that communication happens naturally rather than through formal channels. Technical decisions can be made and reversed quickly because the system is small enough to hold in your head. But the constraints are real in a different way — limited resources mean every engineering hour must count, and there’s no large organization to absorb mistakes.
Shahzad’s key observation: the leaders who struggle most are those who try to apply enterprise processes to startups (creating suffocating bureaucracy) or startup speed to enterprises (creating dangerous chaos). The skill that matters most is reading the organizational context accurately and adapting your leadership approach accordingly. For organizations evaluating their software development approach, understanding where you fall on this spectrum directly shapes what kind of engineering leadership you need.
Key Insight: Scaling Teams Without Losing Engineering Culture
The transition from small team to larger organization is where many engineering cultures break. Shahzad describes the dynamics he’s observed and the strategies that preserve what matters during growth.
In small teams, culture is implicit. Everyone knows each other, shares context naturally, and cultural norms are transmitted through daily interaction. There’s no need for a formal engineering culture document when the entire team eats lunch together. But as teams grow past certain thresholds — Shahzad identifies the transitions from roughly five to fifteen, fifteen to fifty, and fifty to one hundred as the critical inflection points — implicit culture stops working. New hires can’t absorb norms through osmosis because they interact with a small subset of the organization. Sub-teams develop their own micro-cultures that may diverge from the original.
The solution isn’t to bureaucratize culture with heavy-handed policies. It’s to make the important parts explicit while preserving the autonomy that makes engineering cultures effective. Shahzad describes specific practices: documenting engineering principles (not rules, principles), establishing code review norms that reinforce quality standards through practice, and creating onboarding experiences that convey culture through meaningful work rather than slideshow presentations.
For teams building web applications or complex cloud infrastructure, the cultural foundation directly affects technical outcomes. Teams with strong engineering cultures produce better code, catch more problems in review, and make more thoughtful architectural decisions. Preserving that culture through growth is a leadership responsibility, not something that happens automatically.
Key Insight: Healthcare Technology and Regulated Industry Constraints
Shahzad’s career has been heavily concentrated in healthcare technology, and he describes the specific ways that regulatory constraints shape engineering practice. This isn’t abstract compliance talk — it’s practical reality for any technology leader building software in regulated environments.
Healthcare technology operates under constraints that don’t exist in most consumer or enterprise software: HIPAA requirements, clinical safety considerations, audit trails, and integration requirements with legacy healthcare systems. These constraints affect everything from how databases are designed to how deployments are managed to how bugs are prioritized. A data exposure that would be an embarrassment in consumer software could be a federal violation in healthcare technology.
Shahzad discusses how these constraints influence hiring decisions, architecture choices, and development workflows at Trualta. Engineers in healthcare technology need to understand not just how to write good code, but how to write good code within a regulatory framework. This changes the talent profile — you’re looking for engineers who are comfortable with constraints and see regulatory compliance as a design parameter rather than an obstacle.
The conversation also covers the opportunity in healthcare technology. Despite being heavily regulated, the industry is significantly behind in technology adoption compared to other sectors. This creates space for companies like Trualta to build solutions that would be table stakes in other industries but represent genuine innovation in healthcare. For engineering leaders, this means working in a space where the technical challenges are interesting, the impact is meaningful, and the market opportunity is substantial.
Key Insight: Hiring Philosophy Across Company Sizes
How you hire engineers should change as your organization grows, and Shahzad is explicit about the differences in hiring philosophy at each stage.
At the startup stage, you need generalists who can work across the entire stack, tolerate ambiguity, and make decisions with incomplete information. Technical depth in a single area is less important than the ability to learn quickly and deliver across multiple domains. Shahzad describes hiring at Trualta as looking for engineers who are “comfortable being uncomfortable” — people who can own a problem from definition to deployment without waiting for detailed specifications or architectural guidance.
At the enterprise stage, the hiring profile shifts toward specialists who bring deep expertise in specific areas. When you have a large engineering organization, you need people who are genuinely world-class at database performance, security architecture, AI and machine learning, or distributed systems. The organizational structure provides the breadth — individual engineers provide the depth.
The transition between these hiring philosophies is where many growing companies stumble. Early employees who thrived as generalists may struggle as the organization demands specialization. And specialized hires who were highly effective in enterprise roles may flounder in startup environments where their deep expertise applies to only a fraction of the work that needs to be done. Shahzad discusses how he manages these transitions, including honest conversations about role evolution and ensuring that early employees aren’t inadvertently punished for the growth they helped create.
Key Insight: Remote Work Culture From Enterprise to Startup
Shahzad has experienced remote work at both enterprise and startup scale, and his perspective cuts through the simplistic narratives that dominate the remote work debate.
At Cerner, the transition to remote work during COVID was a massive logistical undertaking affecting thousands of engineers. The infrastructure challenges were significant — VPN capacity, security implications, and collaboration tooling all had to scale rapidly. But the cultural challenges were harder. Enterprise engineering culture at Cerner was built around physical presence: war rooms for incidents, whiteboard sessions for architecture, and hallway conversations for the informal knowledge transfer that keeps large organizations functioning.
At Trualta, remote work is the default operating mode. The team is distributed by design, and the cultural norms are built around asynchronous communication and digital collaboration from the ground up. There’s no legacy of in-person culture to maintain or mourn. This has advantages — the talent pool is wider, overhead costs are lower, and the team has developed communication habits that work for distributed collaboration.
But Shahzad is honest about the trade-offs. Building team cohesion remotely requires more deliberate effort. New employee integration takes longer when there’s no office to absorb into. And certain kinds of collaborative work — particularly early-stage brainstorming and complex problem-solving — lose something in translation when they happen entirely through screens. His approach is pragmatic: default to remote for the productivity and talent advantages, invest deliberately in connection and relationship-building, and bring people together periodically for the work that genuinely benefits from physical proximity.
Takeaways
- Don’t transplant processes across organizational contexts. What works at enterprise scale creates bureaucracy in startups, and startup speed creates chaos in enterprises.
- Make engineering culture explicit before you need to. Implicit culture breaks as teams grow past fifteen to twenty people.
- Adjust your hiring philosophy as you scale. Startups need generalists; enterprises need specialists. The transition between them requires honest conversations.
- Regulated industries demand engineers who embrace constraints. Compliance isn’t an obstacle — it’s a design parameter that shapes every technical decision.
- Remote work advantages are real, but so are the costs. Invest deliberately in connection and choose your synchronous collaboration moments strategically.
