januszew.ski

  • Polski

Category: article

  • Politeness as a premium good?

    Politeness as a premium good?

    Not long ago my friend, a pilot by profession, told me: “These are budget airlines. If you want politeness, take a business jet”

    This sentence stopped me for a while. Because have we really reached a point in today’s world where politeness becomes a premium good? Where basic courtesy requires an extra fee?

    Anatomy of budget airlines

    The business model of budget carriers is essentially the art of precise cost cutting. Every service gets sliced into atomic parts, from which the customer composes their own package. Want to choose your seat? Extra fee. Want a sandwich? Extra fee. Want your suitcase to fly with you, not on the next flight? Extra fee.

    In this savings factory, the crew got hit the hardest. Time pressure, multiple flights per day, minimal breaks – all this makes the flight attendant’s smile start to cost money. And not just literally (in terms of personnel costs), but also mentally. It’s hard to be polite when you’re working at the edge of endurance.

    And passengers? Well, cheap often means nervous. Add delays, cramped conditions and the fact that everyone saved on their ticket, so every complication hurts twice as much. This creates a recipe for conflict where politeness becomes the first casualty.

    The economics of a smile

    Does politeness really cost money? At first glance, it seems like it doesn’t. After all, it’s just a way of communicating, right? But when we look deeper, it turns out that courtesy requires resources:

    • Time – longer conversations, explanations, patience
    • Mental energy – emotional control, empathy, positive attitude
    • Training – customer service is a skill that needs to be developed
    • Safety buffer – a polite employee cannot be overloaded

    In a world where every minute is counted and every penny weighed, these “soft” costs become very real. Politeness requires slack in the system, and there’s no slack in maximum efficiency models.

    Premium as usual

    In business or first class, the story looks completely different. Here the service has time, there are fewer passengers, everyone is (theoretically) less stressed. Politeness becomes part of the product that the customer consciously pays for.

    This leads to a paradoxical situation: the more someone pays, the nicer treatment they can expect. A two-tier politeness system emerges, where basic human decency is reserved for those who can afford it.

    Is it just airlines?

    Of course not. Let’s look at:

    • Call centers – basic plan: automated system and 20 minutes of waiting; premium: instant connection to a living person
    • Banking – basic account: harsh online form; premium account: personal advisor who remembers your name
    • E-commerce – regular service: standard responses; premium: personalized solutions

    Everywhere we see the same pattern: politeness as a differentiating element, additional value for those who can afford more.

    Can this be avoided?

    Here we get to the heart of the matter. Does politeness have to cost money? Can’t you really be nice while maintaining efficiency?

    I think you can – but it requires a change in business philosophy. Instead of treating courtesy as a cost, you need to start seeing it as an investment. A satisfied customer returns, recommends, doesn’t generate conflicts. That also has its value.

    Some companies understand this. Models are emerging where politeness is part of the organization’s DNA, not a luxury for the chosen few. But they require courage – the courage not to compete only on price, but on value.

    Questions at the end

    Do we agree to a world where basic decency is a premium good? Where a smile requires an extra fee, and courtesy is a privilege of the wealthy?

    Or maybe there’s a third way – one where politeness is neither a cost nor a luxury, but a basic standard? Where a company can be efficient and human at the same time?

    These are questions that each of us – as a consumer, employee, or entrepreneur – must answer for themselves. Because in the end, we decide what world we build. And what world we buy.

  • “I Don’t Like Being Changed” – Stories from the Transformation Front Lines

    “I Don’t Like Being Changed” – Stories from the Transformation Front Lines

    When I was thirteen years old, my mother decided it was time to change the furniture in my room. She didn’t ask for my opinion – one day I simply came home from school to find strangers carrying out my favorite desk. “It’s for your own good,” I heard when I started to protest. Twenty years later, working as an agile consultant in a financial services corporation, I heard almost identical words: “This transformation is for the good of the entire organization.”

    Peter Senge was right: People don’t resist change; they resist being changed. And the difference is fundamental.

    Anatomy of Resistance – When Good Change Meets Poor Communication

    In that financial corporation, I encountered a situation that perfectly illustrates the mechanism of resistance. The organization employed over 3,000 IT specialists, most of whom had worked in the waterfall model for years. The board made a strategic decision to transition to agile methodologies – and rightly so, because today’s financial market demands the speed of response that waterfall simply cannot guarantee.

    The problem was that the change was announced, not introduced. During one of the first meetings, the development manager told me directly: “We got an email saying that starting next month we’re working in scrum. Where’s the room for our opinion?”

    That was the moment I realized I wasn’t fighting resistance to agile. I was fighting resistance to being changed without participation in the change process.

    When “They” Become “Us” – The Psychology of Ownership

    The human psyche has one fascinating feature: what we create automatically becomes part of our identity. That’s why the best changes are those in which people feel like co-creators, not passive recipients.

    In that corporation, I decided to apply a strategy I call “infiltration from within”. Instead of imposing ready-made solutions, I started with questions:

    • What problems do teams encounter in the current work model?
    • Where do they waste the most time?
    • What frustrates them most in daily processes?

    It turned out that people know perfectly well what doesn’t work. After three weeks of workshops, one of the senior developers said: “You know what, our daily standups are basically daily scrum, just nobody called it that.”

    Bingo. I wasn’t introducing something foreign – I was helping to name and structure what already existed.

    “Not Invented Here” Syndrome

    Every organization has its cultural DNA, its way of thinking about itself. In financial corporations, that DNA often sounds like: “we’re unique, our processes are complicated, no external methodology will understand our specificity.”

    This uniqueness syndrome is one of the strongest defensive mechanisms2. People don’t reject change per se – they reject change that ignores their context, their knowledge, their experience.

    Therefore, a key moment in my work was showing that agile isn’t a ready-made suit you have to put on, but rather fabric from which you can tailor a custom suit. Instead of saying “this is how you do scrum,” I said “let’s see how we could adapt these practices to your needs.”

    Influence as Medicine for Resistance

    The most effective medicine for resistance is a sense of influence. When people feel they have real influence on the shape of change, resistance transforms into engagement3. This isn’t motivational theory – it’s basic human psychology.

    In that organization, the breakthrough was when teams began proposing modifications to standard agile practices themselves. The Product Owner from the mortgage department suggested that in their context, sprint review should be held in two parts: technical demo for IT and business demo for stakeholders. “Otherwise,” he explained, “half the people get bored, and half understand nothing.”

    That was brilliant. And more importantly – it was their idea.

    Change as Journey, Not Moving

    We think about organizational change like moving house: you pack old things, transport them to a new place, unpack. Meanwhile, change is rather gradual metamorphosis – a process where old and new coexist for some time, and people have space for adaptation4.

    In practice, this meant I didn’t impose total revolution. Instead, we introduced changes iteratively (how agile, right?). We started with daily standups in three pilot teams. Then we added retrospectives. Sprint planning came only after a month. Each element was tested, adjusted, familiarized.

    Communication as the Glue of Change

    One of the biggest mistakes in change management is assuming that information equals communication2.Information is “what is changing.” Communication is “why it’s changing, how it will affect me, and what I can do about it.”

    In that corporation, the first step was creating a transparent communication channel. Not another newsletter from management, but a real place for information exchange. We created an internal agile community where people could ask questions, share concerns, propose solutions.

    The most interesting were questions like: “What will happen to my project manager role?” or “Is scrum master a promotion or demotion for a team lead?” These questions showed where the real source of resistance lay – in fear of losing position, competence, professional identity.

    Error Culture vs. Fear Culture

    In organizations with strong control culture, people learn that error is a threat3. Therefore, any change that introduces uncertainty meets with resistance. Agile assumes experimentation, learning from mistakes, adaptation – everything that in traditional corporations is perceived as risk.

    Breaking this paradox required reprogramming the way of thinking about errors. Instead of talking about “failures,” we started talking about “lessons.” Instead of “problems” – “improvement opportunities.” This may sound like PR newspeak, but it has a real impact on team psychology.

    When Resistance Becomes an Ally

    Paradoxically, at some point resistance became our greatest ally. People who were initially most skeptical, after being convinced of the change, became its best ambassadors. Why? Because they went through the full cycle: from resistance, through understanding, to internalization5.

    The senior developer who initially said “another project management methodology,” after three months of working in scrum, organized an internal agile conference. “I want other teams to try this too,” he said. “But on their own terms, not because someone tells them to.”

    Lessons from the Front Lines

    After six months of work in that organization, when I look back at the entire transformation, I see several key truths about resistance in organizations:

    Resistance is not the enemy of change – it’s a natural defensive mechanism that protects the organization from chaotic, ill-conceived decisions4. Intelligent change management uses resistance as feedback, not fighting it as an obstacle.

    People aren’t afraid of change – they’re afraid of losing control over their work environment. Give them a sense of influence on the shape of change, and resistance will transform into engagement.

    The best change is one that people feel as their own – even if the original impulse came from above. The art lies in transforming external mandate into internal motivation.

    And finally: Peter Senge was right. People really don’t resist change – they resist being changed. The difference is fundamental and has enormous practical consequences.

    In the end, organizational change isn’t moving furniture. It’s more like moving to a new apartment – you can take with you what’s valuable, but you must be ready for a new environment. And it’s best if that decision is yours.

  • Sprint Thumbology

    Sprint Thumbology

    How One Finger Changes the Entire Daily

    What’s It All About?

    I’ve been introducing this micro-technique for years across different teams, and every time I see the same surprised faces: “Really? It’s that simple?” Yes, it’s that simple. And that simplicity is where all the power lies.

    The question: “How confident are we that we’ll deliver the sprint goal?”
    The answer: thumbs up 👍 or thumbs down 👎.

    Zero discussion, zero nuances – pure binary. After one minute, we know whether we have a green or red light. There’s no “maybe,” “probably,” “it depends on…” There’s certainty or lack thereof. There’s a team that feels comfortable with the current state of affairs, or a team that signals concern.

    This isn’t a democratic vote – it’s the team’s temperature. One thumb down in a five-person team is already a signal that it’s worth stopping and talking. Three thumbs down is a signal that the sprint has a serious problem.

    Why Does This Work? (Benefits)

    Lightning-Fast Team Diagnosis

    In 5 seconds, you see the sprint’s temperature – a project thermometer without diving into the Jira labyrinth. You don’t need to analyze burn-down charts, count story points, or check how many tasks are in the “In Progress” column. You look at the thumbs and immediately know whether the team feels confident or has doubts.

    This diagnostic speed isn’t just about efficiency – it’s also psychological. From the first second of the Daily, the team knows they’ll have a chance to express their concerns in a safe way. They don’t have to wait until the end, they don’t have to interrupt someone’s story about their tasks.

    Psychological Ice-Breaker

    Fingers warmed up, tongues too – it’s easier to start concrete conversations after a symbolic gesture. There’s something ritualistic about it, something playful, but also something communal. Everyone makes the same gesture at the same moment. This builds a sense that we’re one team, not a collection of individual performers.

    I’ve noticed that after introducing this technique, people smile more often at the beginning of Daily meetings. Maybe it’s because of the gamification element, or maybe because they know – they have a safe space to express doubts.

    Shared Responsibility for the Goal

    Every thumb is a voice, “we” deliver the goal, not “those backend guys” or “frontend is falling behind again.” This is a very subtle but powerful shift in thinking. When the whole team shows thumbs down, nobody looks for someone to blame – everyone feels responsible for finding a solution.

    Early Warning System

    The first 👎 often appears several days earlier than the first red graph in Sonar or the first delay in the schedule. It’s like canaries in a coal mine – the team senses problems intuitively before they appear in metrics1.

    Through years of observation, I’ve noticed that experienced developers have incredible intuition about whether a sprint will be successful. Often they can’t rationally explain it, but they feel something is wrong. The thumb down is a channel for this intuition.

    Cure for “Daily-Sleepy-Syndrome”

    Movement and micro-gamification raise the meeting’s pulse. Instead of sleepy mumbling “yesterday I did this, today I’ll do that,” we have a moment of activity, a moment when everyone simultaneously must think about the sprint’s state and express their opinion.

    Where Do Thumbs Down Come From? (Reasons)

    Unclear Requirements

    “We still don’t know what fields the PDF report should have… and we’re already halfway through the sprint.” This is a classic – the user story seemed clear during planning, but during implementation, it turns out to hide dozens of details nobody thought of.

    Symptoms: Developers ask more and more questions, the Product Owner responds “I’ll check and get back to you,” and tasks hang in “In Progress” without progress.

    Technical Blockers

    The test environment got up on the wrong VM side again, the external provider’s API works “sometimes,” and the test database has data from the Stone Age. Technical obstacles that paralyze the team’s work.

    Symptoms: People sit in front of screens but can’t do their work. Slack fills up with messages “it’s not working for me either” and “did someone already report this to IT?”

    Excessive Scope

    Classic: the Product Owner added “just a small fix” the size of Godzilla. Or it turned out that a “simple” task requires refactoring half the application. Scope creep in its purest form.

    Symptoms: Tasks that were supposed to be “small” grow like yeast. Estimates turn out to be ridiculously low. The team feels like the sprint is “spilling over.”

    Key Person Unavailability

    DevOps is on vacation, and we’re without merges like without coffee. The architect got sick at a crucial moment. The Product Owner went to a conference just when we need their decisions.

    Symptoms: Decisions aren’t being made, work stops, people improvise solutions that may not be optimal.

    Overly Optimistic Estimates

    Yesterday’s weather? Yesterday the sun was probably shining on Mars. The team underestimated complexity, didn’t account for all dependencies, forgot about tests, or didn’t anticipate integration complications.

    Symptoms: The burn-down chart looks more like “burn-up,” people work overtime, and yet tasks don’t get closed.

    Thumb Down? What Next? (Scenarios)

    When you see a thumb down – or several thumbs down – don’t panic. This isn’t a verdict. It’s an invitation to conversation.

    The first reaction should be simple: “Why?”

    Not “who’s to blame,” not “what did we do wrong,” just simply: why do you feel we might not deliver the sprint goal? This question should be asked in a safe atmosphere, without accusations or pressure. Every thumb down is a valuable signal, not a reason for shame.

    Phase One: Understanding

    Give the team space to express concerns. Sometimes it turns out to be just a vague unease – “something doesn’t feel right, but I don’t know what.” Sometimes it’s a concrete problem – “the API hasn’t been working since yesterday.” Sometimes it’s intuition – “I have a feeling this task is bigger than we thought.”

    All these signals are valuable. Even vague unease often turns out to be well-justified when the team analyzes it together.

    Phase Two: Seeking Solutions

    After understanding the problem comes time for the second key question: “What can we do?”

    Not “what should we do” – that sounds like a commandment from above. Not “what must we do” – that sounds like punishment. Only “what can we do” – that sounds like an invitation to collaborate.

    In this phase, various solutions may emerge:

    • Reducing sprint scope
    • Moving some tasks to the next sprint
    • Asking other teams for help
    • Changing the technical approach
    • Escalating the blocker to management
    • Clarifying requirements with the Product Owner

    Phase Three: Another Thumb

    After discussing problems and potential solutions, ask the question again: “How do you feel about the sprint goal now?”

    This isn’t a formality – it’s checking whether the team really feels better after the conversation. Sometimes it turns out the discussion helped and thumbs go up. Sometimes it turns out the problems are deeper and we still have thumbs down.

    Both scenarios are okay. What’s important is that we have real information about the team’s state, not illusory certainty.

    When Thumbs Are Still Down

    If after conversation and seeking solutions the team still shows thumbs down, it may mean that:

    • The problem is more serious than initially thought
    • We need more time to implement the solution
    • The sprint goal is indeed threatened

    And that’s also valuable information. Better to know this at the beginning of the week than on Friday afternoon.

    How to Introduce This Trick Without Getting Fingers Caught in Doors?

    1. Tell a Story

    People are more convinced by anecdotes than slides2. Instead of theorizing about benefits, tell about a specific team that avoided a sprint catastrophe thanks to this technique. Or about how one developer’s thumb down saved an entire release.

    2. Start with Yourself

    Be the first to raise your thumb (or lower it, if necessary). Show that it’s normal for a Scrum Master to have doubts too. If the team sees you’re not afraid to show uncertainty, it will be easier for them to do the same.

    3. Don’t Interpret Individual Thumbs Publicly

    Red finger ≠ red Dev. Don’t say “I see that Michael has doubts.” Focus on the overall picture: “I see several thumbs down, let’s talk about the team’s concerns.”

    4. Maintain Psychological Safety

    A finger down is a gift, not shame. Emphasize that signaling problems is every team member’s responsibility. Thank them for honesty, don’t criticize for “pessimism.”

    5. Track the Trend, Not the Point

    Three consecutive green sprints? You can loosen your belt. Three red ones? Time for more serious changes. One thumb down is information, a trend of thumbs down is a signal for action.

    6. Adapt to Team Culture

    In some teams, five fingers (from 1 to 5) work better, in others colors (green/yellow/red)13. What matters is the idea – quick, visual, safe communication about sprint status.

    Summary

    In an era of advanced dashboards, AI predictors, and other technological wonders, a small thumb can still work miracles. This isn’t another framework or methodology – it’s simply a tool for quick communication. Simple, effective, human.

    Try it tomorrow at your Daily. Ask the question, see the thumbs, talk about what you see. At worst… you’ll show me a thumb down – and that will be good too, because we’ll learn something. 😉

    Remember: the goal isn’t green thumbs at all costs. The goal is real information about the sprint’s state and a team that feels comfortable telling the truth. A thumb down isn’t failure – it’s a starting point for a better sprint.

    Here’s to healthy sprints – and your fingers!

  • Workshop: Team User Manual

    Workshop: Team User Manual

    Abstract

    This document describes the principles of conducting a team-building exercise that involves creating self-presentations in the form of user manuals. While writing this document, I’m thinking about an Agile team led by a Scrum Master, but it can be applied to any teams – from corporate to startup, from remote to traditional office-based.

    What is the purpose of the exercise?

    The goal is as simple as building a hammer: better understanding of yourself and your team. Sounds like a truism? Maybe a bit, but in practice it turns out that most of us work side by side with people we know as much about as our neighbors – practically nothing except that they exist and sometimes speak up.

    The exercise aims to:

    • Breaking communication barriers – it’s easier to talk to someone you know a little
    • Understanding collaboration preferences – some like silence, others brainstorming, others need coffee every hour
    • Discovering hidden talents – maybe it turns out that your IT colleague plays guitar great, and your HR colleague has a patent for calming upset customers
    • Creating an atmosphere of trust – when people know you can “go crazy” after three failed deployments, it’s easier to help you
    • Increasing team empathy – understanding that everyone has their strengths and weaknesses

    What effects can be expected?

    The effects work like a Swiss watch – provided the team approaches the matter with openness greater than a window on a summer day.

    Short-term effects (visible immediately):

    • Relaxed atmosphere – people laugh, joke, it turns out that work is not just deadlines and stress
    • Better understanding of roles – everyone knows who is responsible for what and how they can help
    • Increased communication comfort – it’s easier to ask for help when you know the other person likes to help
    • Discovery of common interests – maybe you’ll find fans of the same book, movie or game

    Medium-term effects (after a few weeks):

    • Improved communication quality – people know how to address each other to be understood
    • Increased collaboration effectiveness – fewer misunderstandings, more synergy
    • Better conflict resolution – easier to understand the other party’s point of view
    • Increased engagement – people are more willing to collaborate with those they know

    Long-term effects (after months):

    • Stronger team bonds – the team becomes more than the sum of its parts
    • Higher productivity – less time explaining, more time acting
    • Better stress management – people know how to support each other
    • Increased retention – people stay where they feel good

    Assumptions

    Before we get to the specifics, let’s establish the rules of the game – because without them it’s like playing football without goals:

    • The exercise involves a moderator and team – the moderator is the one who makes sure no one runs away from the room
    • The team can participate both locally and remotely – the pandemic taught us that many things can be done through a screen
    • The session has no person limit – it works from 3 to 30 people, although with larger groups the moderator needs more patience
    • The exercise is conducted in the form of light fun – no corporate pathos, just ease and laughter
    • No consequences will be drawn from the exercise – this is not a performance review, just getting to know each other
    • Instructions will not be developed outside the team – they are written by the team and for the team, period

    Session Flow

    The session has its choreography – not as complicated as ballet, but it has structure:

    Introduction (10-15 minutes)

    • Moderator explains the purpose of the exercise – better understanding of yourself and the team, without corporate gibberish
    • Moderator presents assumptions – so everyone knows what they’re signing up for
    • Moderator shows example instruction and proposed template – because without a pattern it’s like cooking without a recipe
    • Moderator stimulates discussion about the exercise – encourages active participation, but doesn’t force like a vacuum cleaner salesman

    Main Exercise (30-45 minutes)

    • Exercise begins with selection – “So who wants to be a washing machine?” – and here usually falls the first series of laughter
    • Everyone writes their instruction – can be individually, in pairs or small groups
    • Moderator circulates and supports – answers questions, gives encouragement, keeps time

    Presentation and Discussion (20-30 minutes)

    • Team reads instructions – everyone presents their own or group presents shared one
    • Discussing conclusions – without deep analysis, but in the form of fun
    • Comments and questions – “Ah, so that’s why you always ask for everything by email!”

    Closing (5-10 minutes)

    • All instructions are archived in the team – you can return to them sometimes, especially when a new person joins
    • Summary – short, positive, without speeches

    Recommendations

    To avoid falling into corporate traps, it’s worth remembering a few things:

    • The session should be announced in advance, and participation should be voluntary – no one likes surprises, especially at work
    • The moderator should have a prepared instruction – to set the level, show lightness and expectations from the task
    • Having an instruction doesn’t exempt the moderator from writing – if you want others to open up, you must set an example yourself
    • Don’t impose the method of execution – it can be individual, in pairs or groups, although individual is most expected
    • The moderator should provide samples – printed equipment user manuals or at least photos
    • Instructions should be diverse – washing machine, TV, smartphone, coffee machine – the more variety, the better
    • A new person on the team can supplement the set – a great way to integrate newcomers

    Sample Instruction Template

    Device Name: Roman 2000 Full-Stack
    Model: Universal programmer with debugging function
    Energy Class: A+ (after coffee), C (before morning caffeine dose)

    1. Purpose of the “device”

    Roman 2000 Full-Stack is an advanced programmer model adapted to handle projects from frontend to backend. Perfect for working in Agile teams where flexibility and quick switching between different technologies is required. It has a built-in problem-solving module and automatic upset customer calming function.

    2. “Installation” rules

    Before first use:

    • Ensure access to high-quality coffee (minimum 2 cups daily)
    • Prepare workstation with two monitors (third monitor increases efficiency by 30%)
    • Install Slack, but limit notifications to urgent matters
    • Place in room with natural light sources
    • Ensure internet access (device without internet is like washing machine without water)

    Initial configuration:

    • On the first day, show where the best coffee in the office is
    • Introduce the team and their specializations
    • Share project documentation
    • Set up 1:1 meeting with direct supervisor

    3. Description of functions and capabilities

    Basic functions:

    • Programming in JavaScript, Python, Java
    • Code debugging (own and others’)
    • Code review with constructive comments
    • System architecture from scratch

    Additional functions:

    • Translating business requirements into technical language
    • Calming upset PMs
    • Automatic detection of potential code problems
    • Junior mentoring function (activates after 2 years of experience)

    Work modes:

    • Deep focus mode – highest productivity, do not disturb
    • Collaboration mode – available for discussion and pair programming
    • Creative mode – generates innovative solutions
    • Emergency mode – activates automatically during critical bugs

    4. Usage conditions

    Optimal working conditions:

    • Temperature: 20-22°C (can work in wider range, but complains)
    • Humidity: not critical, but dry air may cause electrification when touching keyboard
    • Lighting: natural light + desk lamp
    • Noise level: maximum medium (noise cancellation headphones included)

    Working hours:

    • Peak performance: 9:00-12:00 and 14:00-17:00
    • Slow-start mode: 8:00-9:00 (coffee required)
    • Emergency mode: available after hours in critical situations

    Communication method:

    • Slack for quick questions
    • Email for formal matters
    • Face-to-face conversation for complex problems
    • Jira card for tasks to be performed

    5. Problem detection

    Warning signals:

    • Excessive use of words “refactor” and “this needs to be rewritten”
    • Increased coffee consumption (above 4 cups daily)
    • Mumbling while reading someone else’s code
    • Spontaneous drawing of diagrams on paper/board
    • Frequent checking of Stack Overflow

    Error messages:

    • “This won’t work” – means need to discuss solution
    • “Hmm, interesting…” – detected potential problem, requires further analysis
    • “Maybe let’s try differently” – current approach requires change
    • Silence longer than 10 minutes – probably entered deep debugging mode

    6. Warranty conditions

    Warranty will be lost in case of:

    • Forced use of Internet Explorer for testing
    • Code changes without code review
    • Meetings longer than 1 hour without specific purpose
    • Interrupting in deep focus mode without important reason
    • Lack of documentation updates for extended period

    Recommended maintenance:

    • Weekly 1:1 meetings with supervisor
    • Monthly team retrospectives
    • Quarterly code and architecture reviews
    • Annual training in new technologies

    Updates:

    • Automatic downloading of latest library versions
    • Regular reading of tech blogs and documentation
    • Participation in programming conferences
    • Experimenting with new technologies in free time

    Warnings:

    • Do not expose to prolonged contact with legacy code without proper protection
    • Avoid working in continuous crunch time mode – may lead to burnout
    • Do not leave unsupervised with access to production database

    Other Information

    Concept distinction – because precision is fundamental:

    • Exercise – the entirety of activity from announcement through execution to consuming effects
    • Session – specific meeting where instructions are created

    Alternative approach – if the team prefers a more serious form, you can apply the approach described by Dominik Juszczyk, which contains elements:

    • When I am the best version of myself – conditions that allow me to develop
    • Value I bring to the team – my strengths and skills
    • I need from you – what will help me in work and collaboration
    • You can count on me – what I gladly and effectively help with
    • Worth knowing about me – additional information, curiosities, hobbies

    Summary

    Team user manual is not another corporate invention, but a practical tool for getting to know each other. Like any tool – it works when you use it, not when you keep it in a closet. The most important thing is to remember that behind every “device” in the team stands a person with their own needs, preferences and way of working.

    And maybe the most important discovery will be that your colleague from the department next door also doesn’t like Monday meetings at 8:00 AM. Sometimes it’s exactly these small things that build the strongest team bonds.

  • Motivation is a matter between you and you

    Motivation is a matter between you and you

    Don’t wait for a boss to motivate you – take care of yourself. This sounds like advice from a motivational calendar, but it makes more sense than it might seem.

    We usually talk about motivation problems in the context of leaders who should pay attention to the needs and motivators of the people and teams they help.

    Yes, this is important.
    Yes, this is true.
    Yes, companies don’t take enough care of this, but…
    …every employee, every specialist can also take care of themselves and it’s profitable. For everyone.

    The secret: bosses, managers, colleagues and even most so-called leaders:
    – don’t know themselves,
    – don’t know,
    – don’t have the skills,
    – don’t have time,
    – …and if they know, they often forget after some time.

    how to motivate you

    Working with specialists “one on one,” phrases such as: satisfaction, being happy, hard work, work, results, raises and promotions often come up.

    It turns out they can be connected by one non-obvious phrase: motivation.

    Warning, this article is long. If you're bored reading, skip the dialogue and jump to the end to the ideas my clients usually come up with.

    Here’s one such conversation:

    Mike: What makes you feel motivated at work?

    Sebastian: Hmm… I think when I know why I’m doing what I’m doing. And when I can influence how I do it. I don’t like when someone tells me exactly step by step what to do.

    M: When did you last feel truly engaged?

    S: It was about half a year ago. I was working on this new project (…) and the Tribe Leader said what the business goal should be, we had a lot of space to work out the architecture and build a good solution. Plus I got feedback on an ongoing basis, I didn’t have to wait a month for evaluation.

    M: What else was important in that situation?

    S: That I knew it made sense. That users really needed it. And that we could transition to new technology and clean up the architecture.

    M: And now? How does your motivation look in the current project?

    S: sighs Well, exactly… Now I get tasks without context. “Do this and that.” I don’t know why I’m doing it. The boss checks every hour what stage I’m at. And I’m mainly fixing old bugs, no new knowledge.

    M: Sounds frustrating. What would happen if you told your boss what you need to be motivated?

    S: pause I don’t know… Maybe he’d think I’m picky? Or that I don’t want to work?

    M: What do you think – does your boss want you to be motivated and effective?

    S: Well, probably yes… After all, the project’s success depends on it.

    M: So if you told him (wait, let me summarize what I wrote down from what you said): “I’m most motivated when I know why I’m doing a task, I can influence how it’s done, and I get ongoing feedback” – does that sound like a problem or a solution?

    S: moment of thought Like a solution. But… isn’t it weird that I have to tell him how to manage me?

    M: Isn’t it weird that you expect him to guess what motivates you?

    S: laugh Right. So it’s like… an instruction manual?

    M: Exactly. What else could you tell him about what demotivates you?

    S: That micromanagement kills me. That working only on bugs for months is a nightmare. And that when I don’t know if what I’m doing makes sense, I lose energy.

    M: What if you wrote all this down and discussed it with your boss?

    S: I think… he might understand it. After all, he was once a programmer and architect himself. Maybe he just doesn’t know it’s important to me.

    M: What else could you do to take care of your motivation?

    S: I can also talk to the team. Maybe others have similar needs. And I can ask for specific things – for example, to get one day a week to learn new technologies.

    M: Sounds like a plan. What will be your first step?

    S: I’ll write myself a list of what motivates me and what demotivates me. Then I’ll schedule a meeting with my boss. I need to tell them how to motivate me and make sure they stick to it.

    Research confirms intuition

    Research shows that intrinsic motivation has a huge impact on effectiveness. A team of psychologists (Dr. Christopher P. Cerasoli, Prof. Jessica M. Nicklin, and Prof. Michael T. Ford from University) conducted a solid meta-analysis based on 40 years of research on the relationship between motivation and effectiveness. The results are clear: Intrinsic motivation proved to be moderately to strongly correlated with performance (correlation coefficient ρ = 0.21-0.45). What’s particularly important – this correlation remains stable regardless of the presence of external incentives.

    This means that if you find a way to like what you do, you’ll work much more efficiently than when someone tries to motivate you only with a bonus or raise.

    Additionally, research indicates that the occurrence and development of intrinsic motivation are influenced by, among other things: sense of work meaning, sense of responsibility, and knowledge of work results. These are things you have direct influence over!

    Concrete self-motivation methods

    “Instruction Manual” Method

    Write literally an instruction manual for yourself. It may sound weird, but it works. Here’s an example:

    “I am motivated when:

    • I know why I’m doing a specific task (business goal)
    • I can influence how the task is executed
    • I get feedback during work, not just at the end
    • I work on things that make sense to users
    • I have time to learn new things”

    “I am demotivated when:

    • I get tasks without context
    • Someone micromanages my every step
    • I don’t know if what I’m doing makes any sense
    • I work only on bugfixes for months”

    “Proactive Conversation” Method

    Instead of waiting for an annual review, schedule coffee with your boss and say:
    “I’d like to talk with you about how I can be more effective. I’ve noticed I’m most motivated when… And I lose energy when… Can we try to direct my tasks in a way that uses what drives me?”

    “Small Experiments” Method

    If you don’t know what motivates you, experiment. For a week, try working differently:
    Change the time when you do the hardest tasks
    Ask for feedback at the beginning and middle of a task instead of at the end
    Suggest a different approach to the problem
    Find a way to measure the impact of your work
    Observe when you feel more energetic and engaged.

    Why this works

    When we’re motivated, everything falls into place. Research confirms that intrinsic motivation is linked to a sense of work meaning, responsibility, and knowledge of results. When these elements are in place, we naturally achieve better results.

    And better results aren’t just personal satisfaction and happiness. They’re also concrete benefits: raises, promotions, more interesting projects, better team relationships.

    It spins like a flywheel:
    -> the more motivated you are,
    -> the better you work,
    -> the more you get,
    -> the more motivated you are.

    Courage at work

    Such discovery awakens fear: What if they use this against me?

    Nothing will happen. It won’t get worse.

    Achieving results/recognition/money/promotion at work (I don’t know what motivates you specifically) and consequently feeling happy requires a lot of courage:

    • Courage to tell your boss what you need.
    • Courage to experiment with new ways of working.
    • Courage to admit that some things demotivate you.

    But the alternative is sitting for years in a job that drains your energy, complaining about a boss who “doesn’t know how to motivate” and waiting for some miracle that will suddenly make you love Mondays.

    When we’re motivated, everything falls into place. Let’s take care of ourselves. It’s worth acting – because no one will do it for us, and happiness at work isn’t a luxury, but a basic need for anyone who spends 8 hours a day at work.

  • Team-Based Recruitment – How to Stop Guessing Who Fits In

    Team-Based Recruitment – How to Stop Guessing Who Fits In

    Imagine this: HR introduces you to a new colleague with the message, “Here’s your new team member. Their CV is great, and they passed all recruitment stages.” And you look at them and think, “Okay, but will I be able to work with this person for the next two years?” Sounds familiar?

    The Problem with Traditional Recruitment

    Classic recruitment is a bit like buying shoes online – they look great in the picture, but only when you put them on do you realize they pinch your toes. HR checks the skills, the manager checks the experience, and the team? The team finds out about the new member on Monday morning.

    The result? The new person might be a brilliant specialist, but if their communication style resembles a telegram from the 1920s, and the team loves chatting about everything and nothing during Daily – we have a problem. Or vice versa – someone who needs silence like a monk in a monastery joins a team that discusses every piece of code like football experts on TV.

    Team-Based Recruitment – How Does It Work?

    In several companies, I managed to convince people to try a completely different approach. The process looks like this:

    Step 0: Recruiters present candidates (optional)
    The classic CV screening. Nothing new here.

    Step 1: Short technical interview
    One of the team’s specialists talks to the candidate for 30-45 minutes. The goal? To check the level of knowledge and experience. No deep dives into bubble sort implementation or questions like “how much does an elephant weigh in Java.” Just: does this person know what we’re talking about?

    Step 2: Interview with the whole team
    And here’s where the magic happens. The candidate meets the entire team they’ll be working with. Everyone asks questions, everyone observes, everyone makes the decision. It’s not an interrogation – it’s getting to know each other.

    Step 3: Salary talk
    The line manager discusses financial terms. That’s it, signature on the contract.

    Why Does This Make Sense?

    When I introduced this system, I always asked candidates at the end of the interview: “How would you feel if the next stage was a meeting with the team?” And I presented the arguments:

    • You’re going to be part of the team – so let the team check if your character fits what you say about yourself
    • You’re supposed to bring value to the team – maybe let the team decide if they see that value
    • If the team says ‘Yes’ – you’ll have support from day one
    • If the team says ‘No’ – well, there’s no point in forcing it

    Reactions? Always positive. “I’ve never had such an interview, but I see the point.” Some expressed concerns, but said it was worth trying.

    Real-Life Examples

    Case one: Senior Developer with communication issues
    The candidate had a great CV – 8 years of experience, knew all the frameworks by heart. During the technical interview, he shone. But when he met the team, it turned out his communication style was a series of monologues. The team worked in a mode of constant consultation and collaboration. Verdict? “Great specialist, but not for us.”

    Case two: Junior with potential
    A young programmer, one year of experience, a modest CV. But during the team meeting, she asked great questions, listened carefully, and her energy was contagious. The team said: “We’ll teach her everything, but we want her with us.” A year later, she was one of the best in the team.

    Case three: Expert who didn’t fit culturally
    A candidate with 15 years of experience, a guru in his field. But during the team interview, it turned out his approach was “I know better, you all learn from me.” The team valued equality and mutual learning. Despite his skills – he didn’t make it.

    What Does the Team Check During Such an Interview?

    Team chemistry
    Will this person fit our way of talking, joking, solving conflicts? This isn’t about skills – it’s about whether we’ll like each other for the next few years.

    Work approach
    One team loves long discussions about architecture, another prefers quick decisions and iterations. One values precision, another experimentation. The candidate can be brilliant, but if their work style is the opposite of the team’s – there will be suffering.

    Motivation and values
    Does this person want to develop in the same direction as the team? Do they have a similar approach to code quality, testing, documentation? Will they push the team forward, or hold it back?

    Benefits for Everyone

    For the team:

    • They have a say in who joins them
    • They take responsibility for integrating the new person
    • They feel co-responsible for recruitment success

    For the candidate:

    • They know who they’ll work with
    • They can assess if the team suits them
    • They start with the support of the whole group

    For the company:

    • Lower risk of a bad hire
    • Faster integration of new people
    • Better cultural fit

    When Doesn’t It Work?

    This system only makes sense in teams that actually collaborate. If people sit in their caves and only contact each other via Slack, team-based recruitment is a waste of time. But if you work together, plan together, solve problems together – the team knows best who they need.

    Summary

    The team knows best, is self-governing, makes decisions, and takes responsibility. Whoever tried this approach never went back to classic recruitment. Why guess, when you can ask the people who’ll work with the new person every day?

    As I always say – you can build teams by force, or you can let them build themselves. The second option is simply smarter.

  • The Power of Trust: Key to Breakthrough Leadership in the Era of Uncertainty

    The Power of Trust: Key to Breakthrough Leadership in the Era of Uncertainty

    Those who have worked with me know that I often address the topics of trust, courage, and sensitivity.

    Now I’m gathering my thoughts, structuring them, and I wanted to invite you to think about these topics with me. There won’t be many of these thoughts – fewer than six, a bit more than four, about five.

    Thought #1: Trust is not weakness – it’s an investment that brings unexpected returns

    Imagine you’re the captain of a ship. You can either stand by each crew member and control their every move, or trust their competencies and focus on setting the course. Which strategy will take you further? The answer may be surprising for those who believe in micromanagement.

    Research clearly indicates that teams with high levels of trust are up to 50% more productive than those where mistrust and control reign. This isn’t opinion – it’s hard data. Stephen Covey didn’t call his groundbreaking book “Speed of Trust” without reason. Because that’s exactly what it’s about – trust accelerates everything.

    Innovations aren’t born in an atmosphere of suspicion

    When the mind is trapped in a spiral of suspicion, its creative powers become drastically limited. It’s like trying to compose a symphony whilst someone constantly looks over your shoulder and questions every note. Amy Edmondson’s research from 1999 showed that psychological safety and trust in teams increase innovation by as much as 30%. Imagine – one-third more breakthrough ideas, solutions, and improvements simply because people aren’t afraid to share their concepts!

    In practice, I’ve seen this countless times. A team that feels it can safely experiment generates solutions that no one had even dreamed of before. And a team where every failure is cause for shame and blame? There innovations die in the bud.

    Authentic business relationships as a catalyst for success

    Harvard Business Review published a study in 2018 that was a real shock for many managers: authentic business relationships can accelerate project completion by as much as 40%. Imagine – the same project, the same people, the same resources, but completed almost half as quickly. How is this possible?

    The answer lies in the time and energy we devote to protecting ourselves against potential disappointment. How many times have you written a long email to “have everything in writing”? How many meetings have you spent establishing who is responsible for exactly what (read: whom we’ll blame when something goes wrong)? This “transactional caution” eats up time that could be devoted to actual work.

    Sleep, trust and efficiency – an unexpected connection

    And now something that may seem unrelated, but has a deep connection to our topic. The National Sleep Foundation conducted research in 2020 that showed better sleep quality improves cognitive functions and decision-making by 20-30%. What does this have to do with trust?

    When you don’t trust your colleagues, your brain works at increased speed even during rest. It analyses, calculates risk, plans emergency scenarios. It’s exhausting – both physically and mentally. The result? Worse sleep, less mental clarity, weaker decisions.

    The paradox is that we prefer to lose energy on control instead of investing it in development. Imagine how much you could achieve if you redirected the same energy you devote to mistrust towards creative problem-solving? Gallup showed in 2017 that leaders who build trust not only achieve better results but also attract the best talent, reducing employee turnover by as much as 25%.

    Trust as a business strategy

    We’re talking here not about warm, soft feelings, but about hard business strategy. Every pound invested in building trust returns threefold – through faster processes, greater innovation, and higher talent retention.

    This is how it works: Trust unleashes the creative potential of the entire team. When we stop being afraid, we start creating breakthrough solutions. It’s a simple mechanism that is still undervalued in many organisations.

    Practical application: from theory to practice

    So how do you build a culture of trust in practice? Here are several strategies I’ve tested:

    1. Start with yourself – show your vulnerability and admit to mistakes. Nothing builds trust like a leader’s authenticity.
    2. Celebrate failures as lessons – a team that knows it can safely make mistakes will make bolder decisions.
    3. Eliminate “office politics” – clear rules for promotions and recognition eliminate the need for “games” and build trust in the system.
    4. Practice “radical transparency” – share information that was traditionally reserved for a narrow circle.
    5. Invest in relationships – find time to get to know your team as people, not just as resources.
    Thought-provoking question: Do you have examples of great business benefits achieved through trusting others?

    Thought #2: Trust is an equation where credibility is a variable we can control

    I’m an engineer by education, so forgive me the mathematical approach to the topic. But what if trust can be presented as an equation? What if there’s a formula that will help us understand how to build and strengthen trust in our organisations?

    Research by Mayer, Davis and Schoorman from 1995 proposes a fascinating formula:

    The higher the credibility, reliability and level of openness, the higher the trust. The greater the focus on one’s own interests, the lower the trust.

    The mathematics of interpersonal relationships

    Let’s look at this equation closely. Credibility is our expertise and competencies – what we know and can do. Reliability is consistency in action – keeping promises and deadlines. Intimacy is the level of openness and honesty in the relationship. And self-orientation? That’s the degree to which we focus on our own benefits at the expense of others.

    Interestingly, we multiply the first three elements together, which means that if any of them is close to zero, the entire trust drops drastically. On the other hand, self-orientation is in the denominator – the greater it is, the less trust there is.

    Kouzes and Posner in their research from 2012 confirmed that we build credibility through consistent actions and decisions. It’s not one-off gestures or grand declarations that build trust, but daily consistency between words and deeds.

    The business paradox of control

    Here appears a fascinating business paradox: why do companies invest millions in control instead of in building credibility? Think about it: how much does your organisation cost in monitoring systems, security procedures, multi-level approvals? And how much does it invest in developing the credibility of its leaders and employees?

    It’s like building an ever-higher fence instead of ensuring that no one wants to escape. I’ve seen organisations that spend fortunes on control systems whilst ignoring the basic fact: we cannot force others to trust. But we can systematically build our own credibility.

    Project Aristotle – scientific confirmation of the power of trust

    In 2015, Google conducted one of the most fascinating organisational studies of our time, called “Project Aristotle”. For two years, hundreds of variables affecting team effectiveness were analysed. The results? The most effective teams weren’t those composed of the greatest geniuses or best-paid specialists. The key factor turned out to be psychological safety – the feeling that one can take risks without being exposed to shame or punishment.

    In other words, trust was the foundation of efficiency. In teams with high levels of psychological safety, people were more willing to share ideas, admit to mistakes, and collaborate on solutions. The effect? Faster product development, better customer service, and greater innovation.

    Building credibility as a business strategy

    So how do you build credibility in practice? Here are several proven strategies:

    1. Consistency in small things – keep promises, even small ones. Punctuality at meetings, responding to emails, fulfilling commitments – these are the building blocks of credibility.
    2. Transparency in failures – when something goes wrong, don’t hide it. Admit the mistake, draw conclusions, move forward.
    3. Share knowledge – expertise builds credibility, but only if it’s visible and accessible to others.
    4. Consistency of values and actions – ensure your decisions reflect the values you declare.
    5. Appreciate others publicly – credible leaders aren’t afraid to give credit to the team.

    Exponential growth of trust

    What’s fascinating about organisational trust is its exponential character. Research shows that trust in an organisation grows exponentially with the level of leaders’ credibility. One credible leader can change the culture of an entire department, and several such leaders can transform an entire company.

    The future belongs to organisations that understand this equation: team credibility × mutual trust = business success. In a world where more and more work requires creativity, innovation, and collaboration, organisations based on control will lose to those building trust.

    Thought-provoking questions:
- What actions in your organisation most influence building credibility?
- Do you see a connection between the level of trust and team effectiveness in your organisation?

    Thought #3: I start with a full sheet (100% trust credit), not an empty one

    I’m someone who notoriously forgets his notebook at meetings. So I often borrow a sheet from other participants. Consider this – would you prefer to receive a clean sheet or one with another person’s notes? Most would choose the clean one. We prefer to start from zero, have empty space to fill.

    With trust, it’s exactly the opposite. Or at least it should be.

    Reversing traditional thinking

    Conventional wisdom says: “Trust must be built”. We start from zero and gradually, through successive proofs of credibility, build trust capital. But what if this approach is fundamentally wrong? What if a much more effective strategy is to start with full trust – from 100% credit?

    Research by Lewicki and Bunker from 1996 showed a fascinating pattern: teams that start with high levels of mutual trust achieve better results and faster cohesion. Why? Because from day one they can focus all their energy on the task instead of proving their worth.

    Trust as a self-fulfilling prophecy

    Psychologist Julian Rotter noted as early as 1980 that trust works like a self-fulfilling prophecy. When you give people trust credit, they feel obliged to deserve it. This isn’t naivety – it’s a psychological mechanism that uses our natural tendency to reciprocate positive expectations.

    An example from life: in one of the technology companies I worked with, the new CEO introduced a policy of unlimited holiday days. Traditional thinking predicted chaos and abuse. What happened? Employees started taking FEWER days off than before and planned them with greater consideration. Why? Because they felt trusted and wanted to show they deserved it.

    The risk of lack of trust

    What if the greatest risk isn’t excessive trust but its absence? Dirks and Ferrin in their research from 2002 showed that lack of trust leads to increased control costs and reduced innovation. Organisations with low levels of trust spend more on monitoring, control systems, and security procedures – all of this absorbs resources that could be allocated to development and innovation.

    Think about it this way: if you assume everyone might deceive you, how much time do you spend protecting yourself? How much energy that could go towards creating value goes towards protection against potential fraud?

    Practical application: 100% trust credit

    How does this work for me? When I start working with a new team or person, I give them full trust credit. I assume their competencies, good intentions, and commitment. This doesn’t mean lack of structure or clear expectations – quite the opposite. But within those expectations, I give maximum freedom and autonomy.

    Do I sometimes get disappointed? Of course. But I treat this as an operational cost, not a system failure. Statistically, the gains from trust outweigh the losses – and significantly. It’s like investments – individual losses are inevitable, but the long-term strategy brings profits.

    Belief in people as a driver of development

    What’s fascinating is how your belief in people often becomes their motivation to develop. When you express trust in someone’s skills and character, you create space where they can grow. It’s like giving someone bigger shoes – at first they might stumble, but over time they’ll grow into them.

    I’ve seen this many times in coaching practice – leaders who trust their teams are often surprised by how people exceed their expectations. Not because they suddenly became more competent, but because trust unlocked potential that was already in them.

    Trust as the currency of the future

    In the digital economy, where cooperation and innovation are key, trust becomes a currency of growing value. By spending it generously, paradoxically, you increase its value. It’s the only currency whose value grows when you spend it.

    PS. This approach changes not only relationships but entire organisations – teams with high levels of initial trust achieve results faster and operate more efficiently.

    Thought-provoking question: When did you last give someone 100% trust credit from day one and how did it affect your relationship?

    Thought #4: Rebuilding trust is a process – but it doesn’t have to mean either naivety or revenge

    We’ve all experienced betrayal of trust. Perhaps a business partner didn’t keep their word, maybe a colleague took credit for your idea, or perhaps a supervisor didn’t stand up for you when you needed it. What then? How do you rebuild damaged trust without falling into two extremes: naivety (“nothing happened”) or revenge (“I’ll never trust anyone again”)?

    The third way: boundaries without walls

    Between blind trust and complete isolation exists a third way – setting boundaries without building walls. Research by Mayer and his team from 1995 shows that rebuilding trust requires both boundaries and openness. Boundaries protect us from further harm, whilst openness gives a chance for healing the relationship.

    Imagine trust is like a bridge between two shores. When the bridge gets damaged, you have three options: you can try to cross it as if nothing happened (naivety), you can completely demolish it (revenge), or you can repair it whilst building a temporary crossing in a safer place (wise boundaries).

    Lesson, not a life sentence

    Fisher and Ury in their study from 1981 suggested a fascinating perspective: treating betrayal as a lesson rather than a life sentence significantly improves psychological resilience. When we perceive painful experiences as a source of knowledge rather than proof of the world’s malice, we’re able to recover faster and act more wisely in the future.

    I often hear: “I’ll never trust anyone again”. But isn’t that like closing all doors because one slammed shut? It’s like saying: “I once burnt myself with hot tea, so I’ll never drink anything again”. Moving away from a person who betrayed you isn’t isolation from the world. It’s wise self-protection whilst maintaining the ability to trust others.

    Balance between caution and openness

    Daniel Goleman, creator of the concept of emotional intelligence, in his research from 1998 emphasised that maintaining balance between caution and openness leads to healthier relationships. Too much caution and we become cynical, cut off from others. Too much openness and we expose ourselves to constant hurt.

    How do you find this balance? For me, the model of “open heart, alert mind” is helpful. I remain open to new relationships and experiences whilst being aware of potential threats. I don’t assume bad intentions, but I don’t ignore warning signals either.

    People are fundamentally good

    Additionally: People are fundamentally good and their bad behaviour is caused by something. It does me good to understand a person and then limit trust in them. Complete separation wouldn’t allow me to learn.

    This perspective allows me to maintain faith in humanity even when a specific person disappoints me. I separate the specific person from all humanity – one betrayal doesn’t define everyone. Trust is a skill – you can develop and perfect it. Choose conscious openness instead of blind trust or total isolation.

    Practical strategies for rebuilding trust

    How do you practically rebuild trust after difficult experiences? Here are several proven strategies:

    1. Precisely name what happened – instead of generalities (“you always disappoint me”), name the specific behaviour that violated trust.
    2. Express your feelings without accusations – “I felt betrayed when…” instead of “You betrayed me when…”.
    3. Establish clear expectations for the future – what do you need to start rebuilding trust?
    4. Start with small steps – rebuilding trust is a process that begins with small but consistent actions.
    5. Appreciate progress – notice and appreciate every step in the right direction.

    My ability to trust is too precious a gift to let one person take it away. Therefore, even after painful experiences, I consciously choose trust – wiser, more aware, but still open to the beauty and potential of interpersonal relationships.

    Thought-provoking question: How have you managed to maintain a healthy balance between caution and openness after difficult experiences?

    Thought #5: Trust is not weakness – it’s a superpower that transforms life

    Superpowers are super because they give power and are super. There’s just one problem: It’s terrifying, dangerous, difficult, and unnatural to trust like that… or so it seems.

    Stephen M.R. Covey in his book from 2006 called trust “a superpower that unlocks creativity and cooperation”. Is this an exaggeration? My experience says no. Trust really has transformational power – both in personal and professional life.

    The paradox of control and energy

    The more we defend ourselves against hurt, the more energy we lose on control. It’s a fascinating paradox: trying to secure ourselves against all possible threats, we exhaust psychological resources that could be used for development and creativity.

    Brené Brown in her research from 2012 showed that letting go of control reduces stress and increases mental clarity. When we stop obsessively monitoring every aspect of our life and work, we free enormous reserves of energy. It’s like switching a car from brake to accelerator – suddenly you can move forward instead of fighting to maintain position.

    Trust as a conscious choice

    Schoorman and his team in research from 2007 emphasised that trust is a conscious choice, not naivety. This is a key difference – naivety ignores risk, whilst conscious trust recognises it but decides to act despite it.

    When did you last trust someone completely and allow yourself authenticity? How often do you hold back from trusting because you’re afraid of disappointment? These are questions I regularly ask myself and others. The answers often show how much we lose due to fear of being hurt.

    Practical application: trust in everyday life

    How this works very simply: Trust frees the mind from constantly calculating risk. When we stop being afraid, we start creating. In practice, this means:

    1. Delegating without micromanagement – pass on a task and trust it will be done well.
    2. Sharing sensitive information – openness builds mutual trust.
    3. Admitting ignorance – paradoxically, showing one’s limitations increases credibility.
    4. Giving second chances – disappointments are part of the process, treat them as lessons, not failures.
    5. Showing trust publicly – express trust in others in the team’s presence.

    Peace of mind instead of illusion of control

    One of the greatest benefits of choosing trust is peace of mind. The illusion of control is exactly that – an illusion. We can never control everything. However, we can choose what we focus our attention and energy on.

    Would you rather spend your limited resources on building walls or creating bridges? On protecting yourself against potential betrayal or building valuable relationships? On controlling others or supporting their development?

    Life is too short for us to spend it behind a wall of mistrust. Being open to people quickly reveals that most of them deserve your trust.

    Thought-provoking question: What superpower did you discover when you dared to trust in a situation that seemed risky?
  • Kanbanosis Acute: When Kanban and Scrum Create a Toxic Relationship

    Kanbanosis Acute: When Kanban and Scrum Create a Toxic Relationship

    Have you ever seen a Scrum team proudly presenting their Kanban board with dozens of columns and sticky notes wandering from person to person? I have. And each time I feel like I’m watching a slow-motion disaster – something I call “Kanbanosis Acute.” It’s like watching someone trying to ride a bicycle while playing an accordion – theoretically possible, but why torture yourself like that?

    Tech Lead: “I’m afraid you’ve got Kanbanosis Acute.”
    Junior Dev: “Is it serious?”
    Tech Lead: “You’ve started organizing your unit tests, coffee orders, and emotions into To Do, Doing, and Done.”

    Combining Kanban with Scrum is one of those ideas that seems sensible at first glance. After all, both approaches belong to the Agile family, right? The problem is that it often leads to more confusion than benefits, and in extreme cases, can be one of the reasons for the collapse of Scrum teams and the retreat from Agile in organizations.

    Why Kanban and Scrum Form a Toxic Marriage?

    Scrum was inherently created to deliver value when solving complicated and complex problems. Kanban, on the contrary – for simple and repetitive tasks.

    Sprint vs Flow – a Fundamental Conflict

    Scrum is based on sprints, which by design start “clean” (no work in progress) and end “clean” (everything planned is completed). It’s like preparing meals for the entire week on Sunday – clean refrigerator at the beginning, full of food containers at the end.

    Meanwhile, Kanban is a continuous flow, where tasks flow through the system like water through a pipe. When we try to force Kanban flow into sprint frameworks, we lose the main advantage of Kanban – the ability to measure flow consistency. It’s like trying to measure river flow, but only during specific weeks of the year – the data will be incomplete and not very useful.

    Flow Stabilization at the Cost of Inspection and Adaptation

    The desire to stabilize flow in Kanban often leads teams to extend sprints. “Hey, maybe let’s do three-week sprints instead of two-week ones to better manage flow?” – I’ve heard this many times. The problem is that longer sprints mean fewer opportunities for inspection and adaptation – fundamental elements of Scrum.

    It’s like less frequent doctor visits – you might feel better because you hear bad news less often, but it doesn’t mean you’re healthier.

    Team as a Unit vs Individual Columns

    In Scrum, the team should be treated as one entity with shared responsibility. Everyone wins or loses together. Meanwhile, Kanban, especially in its traditional form, encourages creating columns corresponding to different stages of work, often assigned to specific people or roles.

    “Analysis,” “Development,” “Testing,” “Deployment” – each column is a potential silo, and tasks are passed between them like a hot potato. Handover of work in the context of one team simply makes no sense – it’s like passing a ball between your left and right hand.

    Specialization vs Cross-functionality

    Building columns and assigning people to them makes it difficult for the entire team to collaborate. When we have a “Testing” column assigned to testers, developers naturally focus only on the “Development” column. This leads to specialization, which is the opposite of cross-functionality that we strive for in Scrum.

    It’s like having someone at home responsible solely for vacuuming, and another only for washing dishes. They might be experts in their narrow fields, but what happens when one of them gets sick?

    Most Common Mistakes When Using Kanban in Scrum

    Too Many Columns

    The simplest and most common mistake: creating too many columns. I’ve seen boards with columns such as “To Do,” “Analysis,” “Design,” “Development,” “Code Review,” “Testing,” “Documentation,” “Deployment,” “Done.” This isn’t a Kanban board, it’s a subway map!

    In most cases, three columns are enough: “To Do,” “In Progress,” “Done.” Anything beyond that often introduces artificial divisions and encourages handovers instead of collaboration.

    Obsession with Flow Metrics

    Kanban offers many metrics: lead time, cycle time, throughput… Teams often focus on these metrics at the expense of what really matters – delivering value.

    “Our cycle time decreased by 15%!” – great, but are customers happy with the product? Are we solving the right problems? Metrics are like a thermometer – useful for diagnosis, but they don’t cure the disease by themselves.

    Push Instead of Pull

    In true Kanban, tasks are “pulled” through the system, not “pushed.” However, in practice, I often see developers finishing their task and immediately moving it to the “Testing” column, even if testers are already overloaded with work.

    It’s like throwing more dishes into the sink even though it’s already full – instead of helping with washing. Real Kanban requires discipline and respect for work-in-progress (WIP) limits, which are often ignored.

    When Not to Use Kanban

    Complicated Tasks

    Kanban works great in predictable, repetitive processes. Software development is rarely like that. Each task may encounter unexpected problems, require deeper understanding, or a change in approach during implementation.

    It’s like using a recipe for experimenting with new dishes – you might have a list of ingredients and steps, but the real magic happens when you deviate from the recipe and improvise.

    Tasks Requiring Collaboration of Multiple Specialties

    If your team doesn’t consist exclusively of “full stacks” (100% fullstack-QA-SEC-OPS), Kanban can lead to silos and delays in handovers. Modern software development requires close collaboration between different specialties, not sequential handover of work.

    Pursuing Goals Instead of Tasks

    User Stories, Epics, and Features are not tasks, they are user goals. Kanban is great for managing tasks, but not goals. When we try to force user goals into Kanban frameworks, we often lose sight of the real objective – delivering value.

    When to Use Kanban

    Repetitive Tasks

    Kanban was born in Toyota factories, where processes are repetitive and predictable. It works great in service operations, industrial production, or other scenarios where tasks are similar and well understood.

    Simple Tasks in Large Quantities

    If you have hundreds of simple, similar tasks (like flipping a coin or assembling boxes), Kanban can help manage flow and identify bottlenecks.

    Tasks Executable by Any Team Member

    Kanban works best when any task can be taken up by any person on the team. Otherwise, bottlenecks form and tasks wait for specific people, which negates the benefits of smooth flow.

    Sum of Compliance with the Above Criteria

    Kanban is worth using only when 100% of the tasks meet the above criteria. Otherwise, we risk creating a system that works well for part of the work but hinders the rest.

    Additional Reasons to Avoid Kanban in Scrum

    Dilution of Team Responsibility

    Kanban can lead to thinking “it’s not my task,” where everyone is only responsible for their column. This undermines the fundamental principle of Scrum about the team’s shared responsibility for delivering value.

    Loss of Sprint Transparency

    Sprints in Scrum provide a clear timeframe and scope of work, which facilitates planning and managing expectations. Caring about flow causes work to be transferred between sprints and final stages to overlap with the beginning of the next sprint. This in turn destroys team predictability and can slowly degrade business trust in development.

    How to Avoid Kanbanosis Acute?

    The best is… don’t do it, but if you must use elements of Kanban in Scrum, here are a few tips:

    1. Keep the board simple – three columns are often all you need.
    2. Maintain team collaboration – avoid assigning columns to specific people.
    3. Respect WIP limits – this is a fundamental principle of Kanban, without which it loses meaning.
    4. Don’t abandon Scrum ceremonies – Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective are still key.
    5. Remember the goal – delivering value is more important than beautiful flow charts.

    Summary

    I am a huge fan of Kanban – really! It’s a powerful tool that revolutionized industrial production and can be extremely effective in appropriate contexts. However, in software development with an Agile approach, where collaboration is required, not handover, Kanban often introduces more problems than solutions.

    Instead of blindly combining Kanban with Scrum, consider what you really want to achieve. If your goal is better work visualization, perhaps a simple board with three columns is enough. If you want to improve flow, maybe it’s worth focusing on reducing the size of User Stories and better team collaboration.

    Remember that methodologies are tools, not religion. Use them wisely, adapting to your needs, but don’t forget the fundamental principles behind them. For Scrum, these are transparency, inspection, and adaptation. For Kanban – visualization, limiting work in progress, and flow management.

    And if you ever notice symptoms of Kanbanosis Acute in yourself or your team – excessive multiplication of columns, obsession with flow at the expense of value, or handover of tasks instead of collaboration – know that there is a cure. Sometimes the best solution is to return to basics and remind yourself why we use these methodologies in the first place.

    Because ultimately, it’s not about whether you use Kanban, Scrum, or any other methodology. It’s about whether you effectively deliver value to your customers. And that requires collaboration, adaptation, and continuous learning – regardless of what you call your process.

  • Facilitation Without a Stiff Collar – When the Plan Falls Apart and Participants Look for Another Way

    Facilitation Without a Stiff Collar – When the Plan Falls Apart and Participants Look for Another Way

    I was talking with a colleague yesterday about facilitating a meeting she’s organizing. It was a typical “brainstorming about brainstorming” – bouncing ideas to check if we’re thinking correctly. And you know what? We discovered that this case might face an interesting threat I call “over-facilitation.“Sounds a bit like a traffic violation, doesn’t it? “Excessive facilitation carries a penalty of one failed meeting and two penalty points on your professional reputation.”

    But jokes aside. Over-facilitation is a situation where the facilitator falls so in love with their carefully prepared plan, tools, and structure that they become blind and deaf to the actual needs of the group. This leads to one of two mishaps: either the facilitator completely misses that participants want to go in a different direction and stubbornly pushes forward with their plan (like a GPS driver who tells you to turn right even though the road is closed), or they realize their structure isn’t working but don’t have a plan B, C, or even Z in their pocket (like a chef who can only cook one dish and panics when the ingredients run out).

    In both cases, the result is similar – the meeting doesn’t achieve its goal, participants feel frustrated, and the facilitator looks like someone who came to a costume party in a business suit.

    Mindfulness – The Facilitator’s Superpowers

    How to prevent this? One of the key elements is a state of mindfulness, or simply put, being fully present “here and now” during meeting facilitation. This isn’t about esoteric practices (though meditation actually helps), but about the ordinary (or rather extraordinary) ability to notice what’s really happening in the room.

    A mindful facilitator:

    • Observes participants’ body language (whether they’re dozing off or leaning forward with interest)
    • Catches changes in group energy (sudden animation or drop in engagement)
    • Notices when discussion spontaneously turns in a different direction than planned
    • Recognizes “aha!” moments and knows how to use them
    • Senses tensions and conflicts before they become visible to everyone

    Being mindful is like having a radar that constantly scans the meeting space, catching signals that say: “Hey, something important is happening here!” or “Warning, we’re approaching a wall, we need to change course!”

    In practice, this means you must have divided attention. Part of your brain tracks the process and time, while part is completely immersed in what participants are saying and doing. It’s a bit like driving a car while having an interesting conversation – it can be done, but requires practice.

    Active Listening – More Than Two Ears

    A sister skill to mindfulness is active listening. And no, I’m not talking about nodding and inserting “mhm” every few seconds, though that’s also part of the puzzle.

    Active listening in the context of facilitation is:

    • Listening not only to words but also to emotions and intentions behind them
    • Catching themes and threads that appear in different people’s statements
    • Understanding what’s really important to participants (often not the same as what was written in the agenda)
    • Asking questions that truly explore the topic, rather than leading to predetermined answers
    • Paraphrasing and summarizing to ensure you’ve understood the group’s intentions and needs correctly

    A good facilitator listens as if their life depended on it – because the life of the meeting actually does depend on it!

    One of the key signals that participants need a different meeting flow is when discussion starts circling around a topic that wasn’t planned but clearly generates interest and energy in the group. Or when a prepared exercise meets resistance or lack of engagement. In such moments, you need to be able to say: “I see this topic is important to you. Would you like us to spend more time on it, even at the expense of other agenda items?”

    The Facilitator’s Arsenal, or Why One Hammer Is Not Enough

    We come to a crucial point – the necessity of having multiple tools, techniques, and approaches in your facilitation repertoire. Imagine you’re an electrician who comes to repair an installation with only a screwdriver. Or a doctor who prescribes the same medicine for every ailment. That’s what a facilitator who knows only one method of running meetings looks like.

    In my “facilitator’s backpack,” I always carry several alternative scenarios and tools for each meeting. If the planned brainstorming isn’t working, I can quickly switch to the Six Thinking Hats technique. If discussion in the whole group isn’t yielding results, I divide participants into smaller teams. If digital tools fail, I always have analog alternatives at hand.

    Building such an arsenal is a process that takes years, but it’s worth starting with a few solid, universal tools that work in various contexts. Over time, you’ll add more specialized ones, adapted to specific situations and groups.

    Experience – You Can’t Download This from the Internet

    Knowing when to change course is one thing. Knowing WHAT to change course to is quite another. And this is where experience comes in.

    An experienced facilitator has seen dozens, if not hundreds of meetings. They’ve seen what works and what doesn’t. They’ve seen how groups respond to different techniques and approaches. They’ve seen how to save a meeting heading for disaster and how to leverage unexpected opportunities that arise during the process.

    This kind of knowledge can’t easily be conveyed in an article or book – you have to gain it through practice. But I can tell you that every meeting I’ve facilitated, even those that didn’t go as planned, was a valuable lesson that enriched my toolkit.

    Improvisation – Jazz in the World of Facilitation

    Finally, we come to the skill that combines all the previous ones – improvisation. Experienced facilitators are virtuosos of improvisation who can smoothly adapt to changing conditions, using their arsenal of tools and techniques.

    Improvisation in facilitation is not the same as lack of preparation. On the contrary – it’s precisely solid preparation and a rich repertoire that allow for free improvisation. Just as a jazz musician must know music theory and master their instrument to improvise, a facilitator must thoroughly understand group processes and master various techniques to be able to fluidly modify and adapt them to the group’s needs.

    In practice, improvisation can mean:

    • Changing the order of agenda items when the group has more energy for a difficult topic than anticipated
    • Modifying a planned exercise when it turns out it doesn’t fit the current group composition
    • Completely changing the approach when the original plan doesn’t bring expected results
    • Picking up and developing an unplanned thread that might lead to valuable discoveries

    Summary – Flexible Excellence

    In summary, a good facilitator is not one who perfectly sticks to the plan, but one who excellently achieves the meeting’s goal – even if the path to that goal turns out to be completely different than assumed.

    Mindfulness and active listening allow them to recognize when to change course. A rich arsenal of tools and techniques gives them the ability to choose an alternative path. Experience helps them choose the best option. And the ability to improvise allows them to smoothly guide the group through this unplanned journey.

    Is it difficult? Yes. Is it possible to learn? Absolutely! After all, no one is born a facilitator – it’s a craft that can be learned and continuously perfected.

    So if you’re ready to enrich your facilitator’s toolkit with elements of mindfulness, flexibility, and improvisation, or you’re looking for an expert who will help your organization conduct effective meetings and workshops – let me know. I’ll be happy to share my experience and help you achieve mastery in facilitation without a stiff collar.

  • Is Scrum Master necessary?

    Is Scrum Master necessary?

    Many people often ask me about my opinion on the constant presence of Scrum Master in a team. In this article, I try to convey my views, emphasizing that this is only my personal opinion, and I do not claim the right to the only truth.

    Let’s start with the genesis of the Scrum Master role. In the original idea, this role is described as a person who introduces scrum. This means that he teaches/coaches a team in self-organization, responsibility for achieving the goal, understanding the scrum pillars, values and rules. After introducing everyone to the knowledge starting and stabilizing the team, he will be able to go to the next team. According to the assumptions, it was supposed to last three to six months.

    When is a Scrum Master necessary?
    What happened to the original assumption?
    Why doesn’t it work like that?

    Of course, it works, but only if a different requirement is met, i.e. environmental stability is ensured. A changing environment always creates confusion that affects the work of the team. This can be clearly seen in the Velocity chart, which begins to wave over time, resulting in a loss of production predictability.

    Introducing scrum

    The introduction of scrum itself is a revolution in development. Most often, new teams are created and test automation is introduced. Additionally, teams are smaller, have new, strange meetings, and familiar, simple status meetings disappear. As intended by the authors of Scrum Guide, the role of the Scrum Master is necessary for the correct, permanent and safe introduction of these changes.

    • The correctness of the introduced scrum is crucial because scrum as a framework will not be durable, safe and effective if it is not implemented fully. An attempt to bypass certain elements distorts and, as a result, deforms the entire development. It is visible when we start to demand greater efficiency and performance of the team. Sometimes I compare it with the mechanism of clock gears: if we remove something, it will spin, but we will have no predictability of the results, it will not spin smoothly, and if you try to spin it faster, everything will fall apart.
    • The durability of the change in the agile approach should be of key importance. It is not enough to do scrum training and a one-sprint test to check if everyone understands the rules. After the Scrum Master’s exit, the work mode and roles should be kept permanently and should not go beyond scrum.
    • I understand the safety of introducing scrum as securing the planned production so that this change does not cause the deterioration or collapse of the project or the entire business. The Scrum Master must make changes in such a way that the performance fluctuations remain within an acceptable range and the release dates remain the same, otherwise, the modifications should be agreed and approved.

    Changes in the team

    Personnel shifts are a big change for the team and have a huge impact on the way they work. It happens that “the new one” fits quickly and efficiently into a functioning system, but more often his joining and adaptation causes destabilization. Even more serious consequences can be caused by the leave of an important member of the team.

    Scrum Master’s support reduces the turbulence and shortens their duration which means that the effect of his presence is necessary and profitable. It is especially important to ensure the longest possible time from the first communication about the personnel shift to the actual change of the team members. This allows the Scrum Master and the team to prepare for it and smoothly enter a new situation.

    Changes in technology

    Technology changes very quickly and these changes require constant replenishment of competencies. This necessitates continuous and planned development. Problems start when a technological revolution is unplanned and the team has to cope with changing requirements without being prepared to develop using the new technology.

    The team in its role of product development naturally focuses on the technical aspects of changes in technology. The Product Owner is interested in the new opportunities that the change can bring to the customer/user. The Scrum Master is solely responsible to focus on changes in the way the team works. Most often, he perceives the threats to work stability caused by a change in technology. Competence development, cross-team or external dependencies, methods of solving problems by supporting new solutions will affect the velocity and predictability of work. Careful preparation of changes in certain technology allows the organisation to smoothly change the way it works and reduce the negative effects.

    Changes in scale

    Adding another team to the project is not costless and not only will the velocity be disturbed, but it also will probably not return to its reached level. Bigger project and more teams mean more dependencies, more complexity and bigger problems.

    The problem is very common because managers’ lack of understanding of development problems leads to the conclusion: “It’s going too slow, let’s have more teams doing the work.” There is no disturbance in the team itself, but the bigger number of teams affects the way of planning the work, additional cross-team dependencies during production, the way of testing, integrating the increments in one product or even the way of conducting scrum meetings. Often, business expectations that the work will scale linearly, i.e. 3 teams will deliver the product 3 times faster, are most often unrealistic and, as a result, lead to disappointment.

    Changes in business

    Changes in the market situation, in the organizational structure and, finally, a change of the Product Owner are the most acute factors influencing the understanding of the work planned by the team. This causes increasing team’s uncertainty and great confusion in the way of working, and as a result, critical changes for the team’s performance. That situation usually requires the presence of a Scrum Master, as the scrum team should not be involved in re-adapting the business environment to scrum work rules.

    Constant changes in business positions result in the willingness to introduce a new order. “I am new to this position, but I am great, I will show you how to do it because it is clear that my predecessor did it all wrong”. The team then faces the need to resist changes that may affect its work. Exaggerated planning, reports creating an illusory atmosphere of control, mechanical comparison of teams performance and individual developers performance — those are management actions that a team has to deal with without a Scrum Master or Agile Coach.

    The Scrum Master is designed to support the team in introducing changes that this team is unable to cope with on its own. The presence of a Scrum Master reduces the negative effects of them. The most important thing is for the business to understand that it is profitable to ensure the stability of the development environment. The developers are intelligent — they can cope with everything if they are independent.