Bringing It Back to the 'Why' of Your Business — Open Source CXO Ep. 17 | Active Logic
It’s easy to lose sight of why your organization exists when you’re buried in sprint planning, code reviews, and infrastructure fires. In this first of two episodes with Sebastian Kline, VP of Engineering at Nelnet Community Engagement, the conversation centers on a deceptively simple question: how do engineering leaders keep their teams connected to the business purpose that gives their work meaning?
Sebastian’s journey from Aware3 (a startup focused on community engagement technology) through its acquisition by Nelnet provides a real-world laboratory for this question. When your small, mission-driven startup becomes part of a large corporation, maintaining that sense of purpose requires deliberate effort.
Key Insight: The Purpose Problem in Engineering Teams
Engineering teams are naturally drawn to technical challenges — optimizing performance, adopting new frameworks, reducing technical debt. These are important, but they can become disconnected from the reason the software exists in the first place.
Sebastian describes the symptoms: engineers who can explain their current sprint tasks in detail but can’t articulate how those tasks connect to a customer outcome. Teams that optimize for code quality metrics without considering whether they’re building features customers actually need.
The fix isn’t motivational speeches. It’s structural — creating regular touchpoints between engineering and customers, sharing customer feedback directly with developers, and framing technical decisions in business terms. “We’re reducing page load time” becomes “we’re reducing page load time because 40% of users on mobile connections abandon after 3 seconds, and those users represent our fastest-growing segment.”
Key Insight: Navigating the Startup-to-Enterprise Transition
The Aware3-to-Nelnet transition gives Sebastian firsthand experience with one of the most challenging organizational shifts in technology: preserving startup culture inside a corporate parent. The patterns he describes are common:
- Decision speed drops. What used to be a conversation between three people now requires cross-functional alignment across multiple departments.
- Process increases. Compliance requirements, approval workflows, and documentation standards that didn’t exist at startup scale become mandatory.
- Identity blurs. Team members who joined a startup with a clear mission now work for a corporation with a broader (and vaguer) mandate.
Sebastian’s approach: maintain the small-team identity within the larger org. Keep the direct communication channels that worked at startup scale. Advocate for the engineering practices that made the team effective. And be honest with the team about what changes and what doesn’t.
Key Insight: Managing Globally Distributed Engineering Teams
The conversation addresses the practical challenges of managing engineering teams across multiple countries and time zones. Sebastian shares both the benefits (access to talent, cost optimization) and the costs (communication overhead, cultural differences, time zone coordination).
The key insight: distributed teams work when you design for distribution from the start. Clear documentation, asynchronous communication norms, well-defined interfaces between teams, and deliberate overlap hours for synchronous collaboration. Teams that were co-located and then went distributed often struggle because their processes assumed proximity.
For organizations building development teams, the location model should match the work. Tightly coupled systems need tightly coupled teams (ideally co-located). Loosely coupled systems can be built by loosely coupled teams (distributed works).
Key Insight: Technical Debt as a Strategic Decision
Sebastian reframes technical debt from a purely engineering concern to a strategic business decision. Every piece of technical debt is a trade-off that was (or should have been) made deliberately: we’re shipping faster now in exchange for maintenance cost later.
The problem isn’t technical debt itself — it’s unmanaged technical debt. Debt that accumulates unconsciously, without tracking or prioritization, eventually cripples development velocity. Sebastian advocates for making technical debt visible: track it, estimate its cost, and present it alongside feature work so business stakeholders can make informed prioritization decisions.
This is particularly relevant during acquisitions and integrations, where inherited codebases often carry significant undocumented technical debt. Understanding the debt load is essential for realistic planning.
Key Insight: Customer-Centric Engineering Culture
The thread that connects the entire conversation is customer-centricity — building an engineering culture where understanding customer needs is everyone’s responsibility, not just product management’s.
Sebastian describes practices that work: rotating engineers through support channels, sharing customer feedback in stand-ups, inviting customers to sprint demos, and measuring engineering success in customer outcomes rather than story points delivered.
For custom software development, this principle is foundational. The best software isn’t built by teams that execute specifications perfectly — it’s built by teams that understand what the customer is trying to accomplish and can make intelligent trade-offs along the way.
Takeaways
- Connect every task to a customer outcome. If engineers can’t explain why their work matters to users, the purpose has been lost.
- Preserve small-team identity through acquisitions. Culture doesn’t survive organizational change by accident — it requires active maintenance.
- Design for distribution from the start. Retrofitting co-located processes for distributed teams always creates friction.
- Make technical debt visible. Track it, cost it, and present it alongside feature work for informed prioritization.
- Build customer empathy into engineering processes. The best engineers understand the problem, not just the specification.
