One size fits all! Not at all!

A new understanding of disruptive change is just one of many lessons we have learned over the past five years. A hard one that has left us disoriented, but open to improvement. We live in an ever-changing world with IT challenges that are growing in both size and complexity.
Meeting these challenges and turning them into opportunities requires a creative, adaptable and effectively distributed team.

Understanding the underlying differences in diverse teams, such as differences in functional background, education or personality, can facilitate creativity or group problem solving - but only if a group process is well defined.

In this presentation we will explore the idea of group process and diversity beyond race/ethnicity, gender or age. What are the specific needs, requirements or strategies that need to be in place to create cohesive teams?

In this session I will present several books, studies, white papers and other materials to show how we can use and understand better team dynamics, personality and leadership structures.

- The Mix That Matters. Innovation Through Diversity by Rocío Lorenzo, Nicole Voigt
- The Secrets of Great Teamwork by Martine Haas and Mark Mortensen
- 
The Effectiveness of Teamwork Training on Teamwork Behaviors and Team Performance: A Systematic Review and Meta-Analysis of Controlled Interventions by Desmond McEwan
- An Experimental Study of Team Size and Performance on a Complex Task by Andrew Mao
- Team Effectiveness in Software Development. Human and Cooperative Aspects in Team Effectiveness Models and Priorities for Future Studies by Torgeir Dingsøyr
- The Feedback Fallacy by Marcus Buckingham and Ashley Goodall
- Supporting the productivity and wellbeing of remote workers:
 Lessons from COVID-19 by Thomas J. George, Leanne E. Atwater
- Role of empathy, emotional intelligence, transformational leadership of the project success by Rusan Nadiia, Kozyr Boris
- Psychological Empowerment and Project Success: The Role of Knowledge Sharing by Jabran Khan , Basharat Javed
- Employees’ perceptions of relational communication in full-time remote work in the public sector by Rasa Jamsena,
- Vicious circles of gender bias, lower positions, and lower performance: Gender differences in scholarly productivity and impact by Peter van den Besselaar, Ulf Sandstro

Building Secure Software(Panel) : Practical Strategies for Developers

This panel discussion will provide developers with practical strategies to integrate security practices into every stage of the software development lifecycle. Our expert panel will offer practical tips and techniques to immediately improve your security position, going beyond theoretical concepts.

Software development has come to depend increasingly on the comprehensive integration of security practices throughout the entire lifecycle. Practical techniques will be provided to prevent vulnerabilities and maintain software integrity, including the use of SBOMs.

Attend this practical and engaging session to gain the knowledge and tools to create a more secure and reliable software.

Please find below the seed questions.
The following points will be discussed with the panelist: their areas of expertise and the latest trends.
What are the most significant current threats to software security?
Could you please specify the three or five most important points you would like developers to take away from the session?
Could you please outline some of the most critical security topics you have encountered in your experience, which you believe would be valuable for developers to know?

Failure is not an option. It's a fact

Failure is an inevitable part of success. As an engineer, failure is not a question of if, but when. Failure in the context of innovation efforts has helped thousands of start-up companies succeed, but in the context of a known execution process it can damage results or reputation or create undue risk.
In software development we are at the intersection of innovation and known processes, so how do we benefit from failure and achieve success?
Understanding the types of failure is the key to harnessing the power behind them! This is a session for everyone because failure comes in many different forms and has several different types! We can only benefit from failure if we know how to recognise the type of failure we are facing and how to deal with it.
In this session we will explore several studies and best practices from successful companies that have embraced both.

I present multiple studies, books, white papers to showcase HOW to make it possible to leverage FAILURE and what types of failure should be address with an open strategy and which ones should be avoided

My top resources on this topics are:

HBR The special issue on failure. April 2011
HBR: Increase Your Return on Failure by Julian Birkinshaw and Martine Haas
The Failure Files perspectives on failure. Edited by David Hillson
Learning from Design Failure, Collaboratively by Shulong Yan and Marcela Borge
Learning from Success and Failure by Robert I. Sutton
Strategies for Learning from Failure by Amy C. Edmondson
The Real Reason Why Your Brain Is so Scared of Failure Failure doesn't scare you. Not knowing does By Mithu Storoni
The Skills You Need To Make Failure Productive by Vivian Giang
When We Learn From Failure (and When We Don’t) by Gretchen Gavett
The Tipping Point Between Failure and Success by Dashun Wang

CRA security deadlines loom: What senior engineers must know and do by December 2027

CRA, NIS2, DORA Does it ring a bell? By December 2027, the EU Cyber Resilience Act (CRA) will require Software Bills of Materials (SBOMs) for almost all software products placed on the European market. For teams working with Java, this is a significant compliance task, given their work with deep dependency trees, complex build systems and layered deployment models. This is an architectural and operational deadline that demands immediate attention.
The purpose of this session is to provide a clear and technical overview of what Java engineers, architects and DevOps teams must understand in order to meet CRA expectations and to avoid risk under NIS2 and DORA. These two initiatives increasingly treat SBOMs as evidence of supply-chain control. In this session, we provide a comprehensive explanation of the essential elements that an SBOM must capture in a Java ecosystem, including transitive dependencies, shaded JAR contents, BOM-managed versions, container layers, embedded services, and runtime components.
Attendees will learn how to integrate SBOM generation into Maven and Gradle pipelines with CycloneDX, how to supplement artefact SBOMs with container-image inventories, and how to implement them using Dependency-Track for vulnerability and license visibility. We also outline the minimal governance and workflow changes needed to ensure SBOMs stay correct throughout releases and updates without slowing developers down.
The objective is clear: to provide senior Java practitioners with the clarity, urgency, and practical guidance required to make their systems SBOM-ready before CRA enforcement begins, while enhancing overall software quality and supply-chain resilience.

All about dependencies

Modern software is built on dependencies. They accelerate delivery, extend capabilities, and allow teams to focus on differentiation. But every import is an architectural decision with long term consequences. Beneath the convenience of package managers lie transitive vulnerabilities, maintenance risks, hidden operational costs, license exposure, performance trade offs, and ecosystem fragility.
The real cost of adopting a dependency is the probability of failure multiplied by its impact. What seems efficient today can become technical debt tomorrow when maintainers disappear, APIs shift unexpectedly, governance models change, or security flaws surface deep in transitive trees. Systems that must live for years inherit not just functionality but assumptions about threading, memory, serialization, and lifecycle management.
In regulated environments shaped by the EU Cyber Resilience Act, dependency decisions intersect with secure by design and secure by default obligations, SBOM transparency, and supply chain accountability. However, dependency risk is not merely an infrastructure or compliance problem. It is a core software engineering concern. Architectural boundaries, upgrade strategies, abstraction choices, and test isolation determine whether a dependency can be replaced, patched, or contained when it fails. These are design decisions made in code, not policies written in audit documents.
This session reframes dependency management as strategic engineering rather than administrative hygiene. We examine how to evaluate long term sustainability, assess project health beyond popularity metrics, manage upgrade fatigue, design for replaceability, and build systems that remain adaptable as ecosystems evolve.
Dependencies are not downloads. They are commitments that shape system behavior, resilience, and long term ownership. This talk equips teams to choose them deliberately, responsibly, and with sustained engineering stewardship in mind.

Elevator Pitch
Every dependency you introduce is an architectural commitment that shapes your system’s risk, resilience, and long term maintainability.
This session shows why dependency management is a core software engineering discipline and how to treat external code as a deliberate, auditable design decision rather than a convenience.