For many people, refactoring is a simple code transformation they click on in a context menu or via a keyboard shortcut. The widespread availability of automated refactoring should have made oversized classes and long-winded functions a thing of the past. But it hasn't.

Having a tool is only part of the solution: knowing what to do with it and how to use it well matters. In this talk, we'll revisit what refactoring is (and isn't) and emphasise the idea that refactoring should be considered a design process and not just a clean-up click.

Target Audience: Developers, Architects, Tech Leads
Prerequisites: Programming experience
Level: Advanced

Extended Abstract:
For many people, refactoring is a simple code transformation they click on in a context menu or via a keyboard shortcut. They can extract, inline, replace, move, rename, etc. at will. The widespread availability of automated refactoring should have made oversized classes and long-winded functions a thing of the past. But it hasn't.

Having a tool is only part of the solution: knowing what to do with it and how to use it well is what makes the bigger difference. Refactoring is often mentioned in the context of agile development, test-driven development and legacy code, but beyond saying that it should happen, there is often not much focus on how and why.

In this talk, we'll revisit what refactoring is (and isn't), examine what practical and social obstacles refactoring faces, explore the idea that refactoring should be considered a design process and not just a clean-up click, and that most interesting refactorings are not necessarily automated.

"The Leader must be [X]" is one of the most common sentences we read about leadership. But not all leaders are the same and when working with people context is king!

In this session we will instead analyse the metaphor of Host Leadership: a context-friendly and non-prescriptive way to frame how leadership in an organisation could work. It reuses many of the cultural elements of hosting, thus making it very intuitive and generative!

We will also look at and experiment with practical applications of the idea!

Target Audience: Manager, Leaders, Scrum Master, Agile Coaches
Prerequisites: Experience in a leadership role is a plus, though not required
Level: Basic

Additional Information:
Host Leadership is an idea by Mark McKergow, who analysed the tension between heroic and servant leadership and proposed that an actual effective leadership has elements of both: sometimes hero and sometimes servant. And always adapting according to the context.

When the Agile movement began, it started with the term “lightweight processes”. Lean was closely interwoven with some of the approaches and very often referred to in the general discussion – nowadays you hardly ever read about it.

If you really want to use “Agile” approaches for more than just pushing notes over the wall, or holding meetings as ceremonies, a look at Lean is not only helpful, but actually inevitable which we will present in this talk. We’ll also put them in the context of currently fashionable approaches.

Target Audience: All kinds of change agents – either by choice or by chance.
Prerequisites: Some working knowledge of agile software development techniques and practices
Level: Advanced 

Extended Abstract:
When the Agile movement began, it started with the term “lightweight processes”. Lean was closely interwoven with some of the approaches and very often referred to in the general discussion – nowadays you hardly ever read about it.

If you really want to use “Agile” approaches for more than just pushing notes over the wall, or holding meetings as ceremonies, a look at Lean is not only helpful, but actually inevitable. Straight from “ Lean“ come many approaches that are helpful in the agile realm like:

• Visual Management (as an approach to empowerment),
• the Improvement Kata (as a leadership method),
• the Jidoka concept (as an approach to deal with automation),
• and many other ideas for change and organization,

which we will present in this talk. We’ll also put them in the context of currently fashionable approaches (like the Kanban method, Scrum, SAFe, etc.).

A recipe for collaborative product ownership: Finding solutions to business problems that are feasible and sustainable.

Target Audience: Product Owners, Manager, Project Leader, Architects
Prerequisites: None
Level: Basic

Extended Abstract:
How do you translate Objectives and key results (OKR) back to a hypothesis that can be challenged by the various roles within a team? How do you ensure that the communication around initiatives is not hindered by conflicting terminology or by misinterpretation? In what ways can you involve business stakeholders in finding solutions that will help them understand the technical constraints that a team has to take into account? And how do you prevent tech teams building the wrong thing the right way?

**Imagine:**

• a way to visualize and clarify to the relationships between OKRs, hypothesis and the underlying technical constraints within the technical real-estate;
• a clear path from "user need" to the responsible "components";
• having a common language to talk about problems in context, removing ambiguity and confusion in the process;
• and finally, a way to collaboratively dive into the nitty gritty detail of the current landscape and the proposed solution;

In this session Marijn Huizendveld will take you through the process of leveraging your existing OKRs to clarify what needs to be done to all stakeholders and members of a team.

Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/stefan.roock

Alignment ist der aktuelle Hype. Alle sollen an einem Strang ziehen. So wichtig das Thema ist, so oberflächlich und voller Plattitüden wird es diskutiert.

Den Beteiligten muss klar sein, was erreicht werden soll. Das und wie man das tut, ist seit mindestens 1954 bekannt. Allerdings entsteht das Alignment, das wir meinen, nur, wenn die Menschen im Unternehmen wissen, was sie tun müssen, ohne ständig alles Mögliche abstimmen und koordinieren zu müssen.

Mission Command und OKRs sind Ansätze, um genau das zu erreichen.

Zielpublikum: Manager, Entscheider:innen, Product Owner, Scrum Master, Projektleiter:innen
Voraussetzungen: Grundkenntnisse Agilität
Schwierigkeitsgrad: Anfänger 

Extended Abstract:
Alignment ist der aktuelle Hype. Alle sollen an einem Strang ziehen. So wichtig das Thema ist, so oberflächlich und voller Plattitüden wird es diskutiert.

Offensichtlich muss den Beteiligten klar sein, was erreicht werden soll. Das und wie man das tut, ist seit mindestens 1954 bekannt. Es reicht offensichtlich nicht aus. Schließlich entsteht das Alignment, das wir meinen, nur, wenn die Menschen im Unternehmen wissen, was sie tun müssen, ohne ständig alles Mögliche mit allen möglichen Leuten abstimmen und koordinieren zu müssen.

Die Alignment-Mechanismen reichen von der Rücknahme agiler Arbeitsweisen über OKRs (Objectives and Key Results) bis hin zu Anleihen aus der Militärtaktik wie z. B. Mission Command. Der Vortrag betrachtet verschiedene Methoden in der historischen Entwicklung und vergleicht einzelne Ansätze kritisch bzgl. ihrer Eignung.

Anschließend stellt er wiederkehrende Muster für die erfolgreiche Umsetzung in der Praxis vor.

Nach dem Vortrag kennen die Teilnehmenden die wichtigsten Konzepte zum Thema Alignment & Autonomie und können so fundiert entscheiden, welcher Ansatz in ihrem Kontext besonders nützlich sein kann.

AI is being used every day to power sustainability efforts. We will look at a few areas where we have direct experience working with agriculture, oil and gas, and transportation companies to reduce their carbon footprint and their energy consumption, as well as their risk of systemic failure. We will also talk about the inherent risks of using AI in the sustainability domain, where human-machine interactions are the strongest. We will review some Responsible AI best practices that we have used.

Target Audience: Architects, Developers, Project Leader, Manager, Decision Makers
Prerequisites: None
Level: Advanced 

"We use Clean Code, TDD and Agile (Scrum)". Most new projects I see start with this assertion. It seems nearly impossible to escape these practices. But I have to ask myself. Why? Does 'Uncle Bobs' Clean Code actually work?

In this talk, I demonstrate you why I think Clean Code is a bad idea by applying Clean Code to a simple example. Following this, we will test if this new code holds up under changing requirements and compare it to an alternative approach.

Agility is vital for any organization that doesn’t want just to adopt the Agile terminology but start changing itself, its core, and its way of thinking and operating.

With our thinking tool, the Adaptivity Map, we have discovered different topologies of organizational design. The org topologies are created in the context of a perfection goal of full adaptivity. By doing this, we discovered the organizational changes and paradigm shifts required to move from one type to another.

Target Audience: CEO, Agile Coaches, Project Leader, Manager, Decision Makers
Prerequisites: Basic knowledge of agile frameworks
Level: Advanced

Extended Abstract:
Many organizations struggle to adopt "agile" in a way that delivers on its promise to make the company fast, flexible and efficient. Global consultancy firms have great pitches on how to adopt different so-called “Agile frameworks”. The marketing is great, but are the results too? We see how our clients get stuck in adopting a framework – forming “agile teams”, appointing “product owners” and then clustering all this into “tribes”. Thus creating robust structures that make further organizational improvements and adaptability difficult, slow, and expensive.

For more details visit www.orgtopologies.com

Key Outcome:

In this session, the participants will receive a hands-on thinking tool – Adaptivity Map, that allows participants to design a tailored, long-lasting roadmap to grow their organization's adaptivity towards perfection.

Description:

We believe that every organization needs to discover its own Agile adoption goal, and then lay down a path to it. Agility is vital for any organization that doesn’t want just to adopt the Agile terminology but start changing itself, its core, and its way of thinking and operating.

With our thinking tool, the Adaptivity Map, we have discovered different topologies of organizational design. The org topologies are created in the context of a perfection goal of full adaptivity. By doing this, we discovered the organizational changes and paradigm shifts required to move from one type to another.

This session:

In this session, we propose a context-driven approach to find the level of adaptivity that fits in your organization. You will learn a new way of looking at organizational transformation towards high adaptivity. We will offer a realistic palette of corporate transformation strategies using archetypical organization topologies.

Decision-makers attending this session will get familiar with this model and will be able to evaluate their ongoing Agile adoption (if any). They will be able to see their next horizon, and understand what options are available and what difficulties need to be overcome. Attendees will be able to assess their Agile transformation roadmap.

Participants of this session will learn:

• Understand how Agile adoptions are a journey and the adoption of any scaling framework is not an end-state.
• Understand the prevalent org topologies (archetypes of Agile organization design) and what a starting point of minimal agility is.
• Identify which org topology matches their current Agile adoption.
• Learn how to navigate Agile transformations using the Adaptivity Map to improve the Agile adoption journey.
• Learn to see the organizational changes and paradigm shifts that are required to navigate towards a more adaptive organization.

Can you relate to that ambiguous desire to “actually DO something” while – at the very same time – feeling an irresistible urge to “just hide under a blanket until 'this' all is over”?

I can!

In uncertainty, we humans all too often oscillate somewhere between ‘numbing’ and ‘over-action’. Yet, crises always bear something new, something that wants to be uncovered and tended – besides all the easily visible “unwanted” things.

Join us, in (my) search of sustain-ability.

But: be prepared to be surprised.

Target Audience: All curious human beings (including Developers, Architects, Managers, Project Leads)
Prerequisites: Curiosity and openness for different ways of thinking (and behaviour)
Level: Advanced

Extended Abstract:

Oh crap! Another crisis!

Or at least: another challenging, changing situation.

What can I do? What can WE do – as change supporters, as leaders, as human beings in business?

"What can I do?" is one question I asked myself A LOT of times “just for work” with teams in organisations. Now in times of pandemic, wars & climate change this question got a whole different scope and magnitude for many of us beyond work contexts.

I will take you on a little journey, sharing some of my own experiences… what worked, what didn’t… and most important: what I learned in times of crises.

You will leave that session with digestible psychological science (around Relational Frame Theory (RFT), S. Hayes et al) and most important: with tangible tools to try out yourself. At work and beyond.

The world we live in is event-driven, and event-driven architecture (EDA) is the way modern enterprises integrate their applications and microservices across hybrid and multi cloud environments.  EDA offers many advantages, but implementing across organizations introduces challenges related to transparency within the message flow, and scalability of consumers and producers.  Ben will explain how to overcome these challenges by using an "event portal" to design, build and govern applications. He'll demonstrate new concepts which help you build transparent and scalable microservices based on EDA to get your services on the next level.

This talk is inspired by the BOSSA nova book from Jutta Eckstein and John Buck on company-wide agility, based on Beyond Budgeting, Open Space, Sociocracy and Agile.

This workshop gives a short introduction to BOSSA nova, but is mainly very interactive, supported by Liberating Structures. It helps the participants to identify and refine their biggest challenges in the agile transformation in their organization and provides a structure in which they can create and improve an experiment that they can start with when back in office.

Target Audience: Agile Coaches, Scrum Masters, Leaders, Managers
Prerequisites: None
Level: Advanced

Extended Abstract:
In the VUCA world that we are in, companies are expected to be flexible and both rapidly responsive and resilient to change, which basically asks them to be agile.

But, the agile toolbox is not enough to cover all aspects that create a true agile organization.

We do a brief overview of the additional principles and practices of Beyond Budgeting, Open Space and Sociocracy that Jutta Eckstein and John Buck added to Agile in their book BOSSA nova on company-wide agility. What is it, why is it needed and how it does fit in.

Participants will be engaged and supported to identify their biggest impediments in their agile transformation. From there participants will learn how to cope with these impediments by setting up an experiment to validate a small change, inspired by the BOSSA nova toolbox.

Participants will help each other to refine and improve their safe to fail experiment that they can start running when back in office.

Is your organization perfect? Or do you wish some things could be different? You may be stuck – so you scratch your head, brainstorm a bit, and grumble a bit more. This session will help you get unstuck. You will be introduced to Fearless Change strategies and participate in a Fearless Journey game that can help you and your team begin to move from the present situation to where you want to be. Get ready for some fun and you'll take away some strategies you can start to use on Monday morning!

Target Audience: Anyone who sees problems in their organization and would like to help make change happen
Prerequisites: A desire to learn (and have some fun while you do)
Level: Basic

Extended Abstract:

This workshop is for anyone who wants to learn how to start to make change happen, even if it's as big as increasing sustainability in your organization. As an attendee you will:

• Learn some strategies you can use to begin to get people so interested and involved that they want to change
• Participate in a "game" that will help you begin to get from the present situation to where you want to be
• Take away change leadership strategies you can begin to use right away

Do you have a good idea? You want to introduce a change into your organization, whether it be agile methods or sustainability practices, or anything you believe will be valuable. But other people do not see the value and they are standing in your way. Skeptics are often all around us. You must continually recognize them if you want a change to be sustainable. Who are they and why are they resisting? How can you understand and persuade them? (Hint: the answer is not to simply give them more information.) This presentation will provide some practical tips for identifying and working with resistance on your team, in your organization, and in your personal life too.

Many have suggested using DDD to help define the functional scope of microservices. But how to apply this idea in practice is not clear to everyone. This talk will cover basic DDD concepts, and we'll discuss why and how DDD can help to create microservices with better autonomy, scalability, and reliability. Using examples, we'll navigate from a domain model to the design of both synchronous (REST-based) and asynchronous (reactive) microservices.

Target Audience: Architects, Developers, PM's, QA
Prerequisites: Understanding of Microservices and DDD is useful
Level: Advanced

Extended Abstract:
Many have suggested that DDD modeling techniques can help define the functional scope of microservices. But how to apply this idea *in practice* is not clear to everyone. DDD is NOT an approach to microservice design. However, DDD can help with some aspects of microservice design. DDD has had a resurgence with the advent of Microservices, specifically as it can help you design the right-sized microservices modeled around the domain.

This talk will examine how to take the results of domain modeling (specifically Domain-Driven Design) and map them to a microservices implementation for systems with better availability, scalability, reliability, and modifiability. This will include examples for the design of both synchronous (REST-based) and asynchronous (reactive) microservices. I will also explore various microservice design scenarios around DDD concepts such as aggregates (with entities and value objects), bounded contexts, domain events, anti-corruption layer, and various strategies for Bounded Context interactions.

At a big town hall, a manager mentions DevOps, how that can help our company, and that it is necessary to switch to DevOps as our leading culture/process. Simple, yes? But what often gets forgotten is what needs to be changed to succeed in that culture switch and the expectation that it is a journey. I will show you two teams in the same company with the same presentation and how they went completely different directions. What we have learned from that and what I can give you as advice.

Target Audience: Developers, Managers, Team Leads, Ops, Decision Makers, Project Leader
Prerequisites: Basic knowledge of what DevOps is about
Level: Advanced

Extended Abstract:
Why is it so hard to move to a DevOps culture? This a common question from managers as they already talked about the advantages and got positive feedback from the team. On the other hand, developers now think they must be full-stack developers and ops specialists but still earn a developer salary. Then there is the Ops team, who struggles with the outcome of the development teams and their new role in the process. Everybody else is confused by the word DevOps and starts to think it is a new position in the company (well, you find DevOps team leads and specialists on job platforms).

Changing a company to follow a DevOps-oriented culture is a big project and should be planned accordingly. You will have setbacks; the bigger the company, the longer it will take. If you understand that this is a journey and that you cannot simply copy another company's culture, then you are at the right starting point.

Mehr Inhalte dieses Speakers? Kein Problem, schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/henning.schwentner

Misunderstandings between developers and the business are a plague. Bad communication makes projects fail. This talk presents a remedy (including a practical demonstration with auditorium participation).

Domain Storytelling is a technique to transform domain knowledge into effective business software. It brings together domain experts and development teams.

We let domain experts tell us stories about their tasks. While listening, we record the stories using an easy-to-understand pictographic language.

Target Audience: Everyone involved or interested in software development, including non-technical people
Prerequisites: Curiosity
Level: Basic

Extended Abstract:
Misunderstandings between developers and the business are a plague. Bad communication makes projects fail. This talk presents a remedy (including a practical demonstration with auditorium participation).

Domain Storytelling is a technique to transform domain knowledge into effective business software. It brings together domain experts and development teams to: (a) understand the domain of a software system, (b) find microservices boundaries, and (c) talk about requirements.

We let domain experts tell us stories about their tasks. While listening, we record the stories using an easy-to-understand pictographic language.

The domain experts can see immediately whether we understand their story correctly. After very few stories, we are able to talk about the people, processes, and events in that domain.

The talk is aimed at everyone involved or interested in software development, including non-technical people.

Wer einmal in die IT-Branche eintaucht, wird sie nie wieder los - die Buzzwords. Inflationär wird mit Begriffen um sich geworfen, um seine eigenen Produkte möglichst fancy oder revolutionär erscheinen zu lassen. Gerade auf Manager- und Marketing-Ebene sind hier die Augen oft größer als das Verständnis der benutzten Begriffe. Doch was versteckt sich hinter Begriffen wie „Deep Learning“ und “Serverless“ ? Was ist der Unterschied zwischen Artificial Intelligence und Machine Learning? Und wo finde ich eigentlich diese Cloud? Am Edge des Big Data Lakes?

Wir wollen uns in einer fiktiven Produktentwicklung durch die Welt der Schlagwörter bewegen und hinter die Begriffe schauen, um herauszufinden, was eigentlich dran ist an dieser Industry 4.0. Oder 5.0? 

To understand and impact a large-scale environment (a team, an enterprise, a society), we need effective modeling. Over the years Domain-Driven Design (DDD) has gained a visible foothold in software-centric corporate change agendas.

In my work as a DDD evangelist and sociotechnical architect in large organizations, I’ve lived and breathed DDD to decouple domains and systems, to kickoff greenfield initiatives, to deploy brownfield modernization, and to design reteaming using the Inverse Conway Maneuvre and Team Topologies.

All that hard work has brought me many a pat on the shoulder. But time after time I’ve been surprised by how I/we could make things worse by attempting to make things better. I’ve been frustrated to witness bubbly energy and DDD enthusiasm from event storming workshops and alike evaporate like a deflated balloon. Improvements remained temporary and local. New practices failed to gain widespread adoption. I have to admit with absolute candor that it is so very hard to make lasting impact with DDD, or whatever else technology or tooling du jour.

In this talk, I will share my observations through the systems thinking lens, of what happened in a large change initiative in a big bank, where DDD played a central role. You will hear examples of sociotechnical systems dynamics and episodes about shifting dominance of competing feedback loops. You will be invited to partake in a postmortem forensic of what could have happened, what unfortunately didn’t happen, and the many what-if’s of alternate realities, or pasts. For people new to systems thinking, a positive side benefit can be a sneak peak into systems modeling building blocks and systems archetypes.

As a community, we’ve come a long way modeling software-centric systems, thanks to practice like DDD, architecture and Team Topologies. But what about the runtime dynamics of large human systems in our working environment, especially when such systems are full of fixes that don’t work? As software professionals, can we just tell jokes about SAFe, about policy makers in our company who can copy the Spotify Model, but not paste it? Or should we give the usual shrug – “it’s the system’s fault”?

From a systems standpoint, we are part of the same mess. If we can become better at seeing and naming the elephants in the room, not as random events, but as systemic patterns described through a consistent systems language, then the current messy reality is no longer our enemy but our ally. It can become a generative force for us to identify leverage and sustain influence in large organizational spaces.

I hope this talk will spark interest in system dynamics modeling. It is a call to action for boundary spanners and design-oriented change agents to explore abstractions, heuristics, modeling and visualization techniques to articulate and reason about dynamic system behavior.

How can we architect shared experiences to surface mental models so they can be challenged, improved and no longer stand in the way of change? With the rising initiative fatigue in large enterprises, how do we collectively discover leverage points, design and deploy systemic interventions with long lasting impacts?

Target Audience: Architects, Developers, Product Owners, Agile Coaches, Decision Makers at all levels
Prerequisites: Understanding of agile, architecture, domain-driven design
Level: Expert

Good design of software systems, much like good product design, requires immersive knowledge of the problem space. And yet we often optimize solution architecture primarily for execution, making crucial decisions about structure and technology upfront, when we still know little about the problems they are supposed to solve.
This talk will present an alternative: An incremental, evolutionary approach to building complex systems, grown holistically from the inside out, starting with the business, and optimized for fast feedback and learning.

Target Audience: Architects, Developers, Heads of IT
Prerequisites: Knowledge of design patterns and DDD basics recommended
Level: Advanced

Extended Abstract:
When we design systems from scratch, especially complex distributed systems, we tend to make far reaching decisions at a very early stage – at a time, when we have the least knowledge about the underlying business problem. But some issues are impossible to solve just by assumption, and even with great experience, it's quite common to get the first design at least partially wrong.
Unfortunately, the first design is also often the one that ends up being implemented.
On a technical level, this has immediate consequences: If we assume boundaries in the wrong place, or forget or omit important aspects of communication, we can end up with brittle services, performance issues, and needlessly coupled modules and components, which are painful to maintain and deploy.
On an organisational level, misplaced boundaries and unfortunate design decisions often lead to entire team structures and workflows in all the wrong places, thus creating immense communication overhead, or worse: active prevention of learning and improvement for the rest of the project lifetime.
One way to mitigate the impact of those decisions, and to verify our initial assumptions, is to start implementation not with a complete solution architecture in mind, but rather with the smallest possible footprint: A plain, but fully operational prototype of the domain model, which we can stress, observe, and explore – and change easily, if we run into problems. This way, we can actually _see_ our design work, and gain valuable insights.
As a side-effect, we can also deliver customer value much earlier, by using the raw domain model to power UX/UI prototypes – replacing fakes and click-dummies with a working application.
As a team, we can learn and improve together, making important decisions when they are needed, adding layer by layer of additional (technical) complexity in small, incremental steps, until we are truly ready to scale out.
By combining UX prototyping, Domain Driven Design, and making use of the fractal nature of large-scale systems, we can highlight difficult or problematic choices early, improve fundamental architecture decisions with low risk, and ultimately develop not only to better solutions, but also to a better and more sustainable software development process.

EasyJet Test Manager Laveena Ramchandani as she shares the skills and strategies needed to be successful in Test/QA leadership. Drawing from her own experiences and from those with varying backgrounds, she offers actionable guidance for those aiming to become, or just starting to work as, a Test Manager.

Explore how to choose and deploy the right processes, tools, and team members to meet your quality mandate. Learn how to create a culture that values feedback. Understand why growing and retaining your best people is critical in uncertain economic times.

Target Audience: All
Prerequisites: None
Level: Advanced 

Extended Abstract:
EasyJet Test Manager Laveena Ramchandani as she shares the skills and strategies needed to be successful in Test/QA leadership. Drawing from her own experiences and from those with varying backgrounds, she offers actionable guidance for those aiming to become, or just starting to work as, a Test Manager.

Explore how to choose and deploy the right processes, tools, and team members to meet your quality mandate. Learn how to create a culture that values feedback. Understand why growing and retaining your best people is critical in uncertain economic times.

Key takeaways:

• Traits to cultivate
• Being a people manager
• Tools and techniques: How to choose what’s best for your team
• Giving and receiving feedback
• Working smart

The demand for software development has (finally) resulted in increased investments into developer tools. While more and more startups and enterprises have started building tools, distributing and selling them is still painful and difficult.
We share our story of how we started to serve developers by building a UML tool based on the open-source Eclipse IDE. From the enthusiasm of early product development to facing major legal, licensing, marketing and enterprise sales challenges.
This talk provides insights about…
All the steps and building blocks you need to market and sell your product to a developer end user
The pitfalls of integrating third-party solutions and payment
The challenges of market entry and finding product-market fit
Optimizing your online sales when marketing to developers
User acquisition costs and conversion rates for our own developer tools
This talk may be interesting for everyone who wants to…
Build, market and sell software to developers
Understand the user journey and sales funnel for developer tools
Gain insights into B2B2X ecommerce