Sebastian Gębski
My name’s Sebastian Gębski. I think of myself as an Agilista & practitioner of Lean (following the Kaizen path); hardened in fire of numerous software product delivery endeavors (since 2001), for both multi-national enterprises and ambitious start-ups as well; polyglot architect, not afraid of putting his own hands on code; zealot of Domain Driven Design. My job is to make things happen where others have failed, using common sense (that comes first), people (as this is not an individual sport) and technology (that usually is inevitable).
In the meantime, I share my standpoints on my blogs (https://no-kill-switch.ghost.io & https://anchor.fm/no-kill-switch) and maniacally read books (seriously!). The code I write these days is usually in Elixir (ask me about it!) or (less frequently) .NET. I belong to the Church of Emacs, I am allergic to Scrum disease & when I do stuff - it has to be meaningful, I don’t know how to do things half-heartedly.
Kaizen-Driven Development: Carve Your Own Path
In Shedul/Fresha: we’re not doing Scrum, we’re not using a commodity language / development platform, our architecture is neither a monolith nor micro-services, we don’t have HR / Recruitment dept or even formal “bosses”. We’re not following any hype or re-inventing everything from scratch either. And despite all these NOTs, we’re a serious engineering bunch on a continuously raising curve (for 4 years already), having a consistent exponential growth (business activity volume) month-to-month. How come?
Instead of copying unicorns, we’ve started with very simple solutions & are applying self-disciplined Continuous Improvement (Kaizen) to adjust them to our local needs, specifics & conditions. That’s how Triumvirate was born, that’s why we use Elixir, put our Architecture under Scalpel, follow the Bossless style of ownership, put everyone’s Skin in the Game, found our Hedgehog Concept, etc.
The purpose of this talk is to convince you that copying 1:1 what has worked for other companies does not make sense, neither does mindlessly following consultants’ “best practices”. What works much better is building high internal awareness of your work, measuring what matters & continuously learning (& improving!) via series of small, time-bound experiments. This thesis will be backed up with the series of “war-story” examples of how we’ve evolved something towards (usually) the better in a sometimes very un-obvious way :)
My name’s Sebastian Gębski. I think of myself as an Agilista & practitioner of Lean (following the Kaizen path); hardened in fire of numerous software product delivery endeavors (since 2001), for both multi-national enterprises and ambitious start-ups as well; polyglot architect, not afraid of putting his own hands on code; zealot of Domain Driven Design. My job is to make things happen where others have failed, using common sense (that comes first), people (as this is not an individual sport) and technology (that usually is inevitable).
In the meantime, I share my standpoints on my blogs (https://no-kill-switch.ghost.io & https://anchor.fm/no-kill-switch) and maniacally read books (seriously!). The code I write these days is usually in Elixir (ask me about it!) or (less frequently) .NET. I belong to the Church of Emacs, I am allergic to Scrum disease & when I do stuff - it has to be meaningful, I don’t know how to do things half-heartedly.
Kaizen-Driven Development: Carve Your Own Path
In Shedul/Fresha: we’re not doing Scrum, we’re not using a commodity language / development platform, our architecture is neither a monolith nor micro-services, we don’t have HR / Recruitment dept or even formal “bosses”. We’re not following any hype or re-inventing everything from scratch either. And despite all these NOTs, we’re a serious engineering bunch on a continuously raising curve (for 4 years already), having a consistent exponential growth (business activity volume) month-to-month. How come?
Instead of copying unicorns, we’ve started with very simple solutions & are applying self-disciplined Continuous Improvement (Kaizen) to adjust them to our local needs, specifics & conditions. That’s how Triumvirate was born, that’s why we use Elixir, put our Architecture under Scalpel, follow the Bossless style of ownership, put everyone’s Skin in the Game, found our Hedgehog Concept, etc.
The purpose of this talk is to convince you that copying 1:1 what has worked for other companies does not make sense, neither does mindlessly following consultants’ “best practices”. What works much better is building high internal awareness of your work, measuring what matters & continuously learning (& improving!) via series of small, time-bound experiments. This thesis will be backed up with the series of “war-story” examples of how we’ve evolved something towards (usually) the better in a sometimes very un-obvious way :)