JDD 2024: A Crash Course in Business Thinking for Engineers

### Overview In this talk presented at JDD 2024, the speaker addresses the persistent divide between engineering (IT) and business stakeholders. Drawing on 20 years of industry experience as a software developer, trainer, consultant, author, and startup founder, the speaker outlines common stereotypes, miscommunications, and mindset gaps that hinder effective collaboration. The goal is to provide software engineers with practical frameworks to understand business perspectives, align language, and transition from mere order-takers to trusted partners.

### Key Topics - **Client Perspective and Vulnerability**: Clients often feel intimidated when engaging with IT, similar to a patient visiting a doctor or a driver consulting an expensive auto mechanic. They may adopt industry buzzwords (e.g., business intelligence, microservices) without fully understanding them, simply to fit in. - **Uncovering True Business Needs**: Clients typically describe desired features or visual interfaces rather than their underlying business problems. Engineers must apply coaching techniques to uncover actual business outcomes, as clients pay for solved problems or business value rather than raw features. - **Scope Definition and the Shift-Left Principle**: Defining what is *out of scope* early in the process helps surface hidden assumptions and expectations before development begins. - **Differing Conceptions of Priority**: Business often views priorities (1, 2, 3) as a chronological schedule where everything eventually gets completed, whereas IT views priority strictly as a filter (1 is guaranteed, 2 is probable, 3 is tentative). Without upfront alignment, this mismatch creates cumulative backlogs. - **Avoiding Destructive Habits**: Overwhelming non-technical stakeholders with dozens of technical questions acts as perceived aggression. Similarly, reducing domain concepts to standard CRUD verbs ("skrudawianie czasowników") destroys rich domain rules and hurts system architecture. - **The Value of Adaptability**: As raw technical IQ has become globally commoditized, flexibility and domain empathy serve as the primary competitive advantage for modern software engineers.

### Technical Details - **Five Perspectives Framework (Slide 38)**: Value delivery can be viewed across five levels: *Inputs* (resources consumed), *Activities* (tasks performed), *Outputs* (items produced), *Outcomes* (measured value), and *Impacts* (market/behavioral change). IT typically communicates in technical terms (blue language), whereas business communicates in outcomes and financial impact (purple language). - **Translating Code Quality to Business Metrics**: The speaker cites a case study with Bank Nordea in Poland. When developers wanted to remove legacy code after operations ceased in Poland, the business initially refused a pure refactoring effort. By measuring Cyclomatic Complexity before and after hypothetical dead-code removal, the engineering team demonstrated a 15% reduction in complexity. They directly translated this technical metric into business terms: a 15% reduction in testing effort, saving approximately 30 tester person-days (man-days) per release, which secured business approval. - **TCP/IP Protocol Analogy for Communication**: Human communication mirrors network packet structure: establishing connection, agreeing on protocol, data transmission, and validation/compensation. Engineers often fail by jumping straight to transmission without first establishing connection and common protocol.

### Takeaways - Focus conversations on business problems and outcomes rather than technical implementation during early stakeholder meetings. - Preserve domain language and business verbs instead of reducing domain logic to generic CRUD operations. - Map technical engineering goals (e.g., refactoring, cyclomatic complexity) directly into measurable business outcomes, such as reduced testing overhead or cost savings. - Avoid aggressive technical interrogation and unprofessional jargon when communicating with non-technical business partners.