Tag: leadership

  • 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.

  • 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
    • 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?
  • “Experience measured in years” == bullshit.

    “Experience measured in years” == bullshit.

    “minimum 2 years of experience as a Scrum Master”

    “5+ experiences as Agile Coach”

    Should experience be measured in years? Does it make sense?

    Many times I have encountered the phenomenon of Scrum Master with several years of experience who is as dumb as an ox. He works schematically, he does not understand what he is doing, and the only thing he can do is implement Zombie-Scrum by imposing his will on the team like Project Manager.

    On the other hand, I know many cases where someone with several months of experience as a Scrum Master has a natural talent for this role. He works with sensitivity and a coaching attitude, forcing the team to reflect on its way of acting. He works for the team and with the team to improve it in working more and more efficiently for the product.

    Since the quality of a Scrum Master does not depend on years of experience, why do recruiters use a non-working measure? If the recruiter is not a specialist in a given field, such a measure is the only way for him to compare the candidates. Is it wrong? No, if the comparison is made with the awareness of its flaws.

    Why shouldn’t experience be measured by years? First of all, because just experiencing a situation does not conclude the future. Where does experience come from?

    1. undergo — we are in some situation
    2. go thru — we go through it
    3. reflection — we analyze it and draw conclusions

    Reflection builds experience.

    The speed of gaining experience depends on the possibility of carrying out conscious analysis and reflection on events. From this point of view, we will quickly come to the most interesting conclusion: an interview with a Scrum Master with a short experience is worth doing. If he is developed despite his limited seniority, it means that he can reflect effectively on what he is doing. Isn’t this the quality that we are most looking for in Scrum Masters to be suitable to work with the team?

    What’s more: since reflection gives us experience, analytical skills allow us to build experience even from other people’s experiences. This is why Scrum Masters carry out so many additional activities outside of work.

    Recruiters: Don’t turn people off because of the short time working on their resumes. Talk to them. It’s worth it. They are often the best.

  • MEASURE OR NOT TO MEASURE – THAT IS THE QUESTION!

    MEASURE OR NOT TO MEASURE – THAT IS THE QUESTION!

    … i.e. KPI in SCRUM.

    I was inspired to write this text by a three-hour (recruitment) interview with the Scrum Master. Half of that time we spent on one topic — KPI (Key Performance Indicators). The conversation began with the question:

    How to recognize a good Scrum Master from his/her results? How to show to the management which SM is better and which carries out its tasks worse?

    My professional life has always been embedded in business and IT. For several years I took turns in the roles of PM and analyst in which measuring progress and drawing indexes was obvious to me from the very first project. From the very beginning of my work in scrum, I have been serious about tracking work and progress and … today I think it was a mistake. I believed the results too much.

    In my first project, a detailed progress tracking distracted me from key issues: customer satisfaction surveys and team enthusiasm check. After all, everything looked fine on paper, so why should the client be dissatisfied? It was only thanks to the reaction of a more experienced Scrum Master that I was able to direct the project to the right path.

    In the next project, the team accidentally caused an even bigger problem. They gradually changed their approach to estimations, slightly raising them. It was not visible, and even if we started a conversation on this topic, neither the Scrum Master nor the Product Owner has the right to press the team for changing the estimations. As a result, at constant capacity, the team delivered less, more time was devoted to the individual stories, there were fewer bugs, increased predictability, but after some time, customer satisfaction decreased. Note that all KPIs (except for customer satisfaction) were rising or remaining at the same level but the project was going to collapse. Value in a single sprint decreased, but it is natural since the most valuable work was done at the beginning. The only things that changed were the early estimations in the backlog that grew as they were refined and the Burn Down Chart of the product that stretched. Pulling ourselves together came only when the client announced that he was tired, that he had expected the next release to be completed a few weeks earlier, that he could see the team working well, but the results disappointed him. The team sped up, the estimations returned to original, and high quality remained.

    I learned my lessons from both situations:

    • not to blindly believe KPIs, because they are just numbers,
    • the most important thing is customer satisfaction because he decides to pay for increments,
    • the charts can only give a clue as to where the problem might be located, but they do not convey specific information.

    In this way, I didn’t use to blindly believe in measures depending on:

    • velocity (dependent on Product Backlog Item estimation),
    • yesterday’s weather (depending on previous PBI estimations),
    • capacity (dependent on PBI estimation),
    • RPI (depending on identified PBI problems).

    Indicators showing the quality of the product depend on time allocated to the PBIs (i.e. defects per release or technical debt). They also can indirectly depend on the estimation of individual PBIs. Of course, they indicate the state of the product, but not the quality of the Scrum Master’s work as such. Thus, the answer to the posed question How to evaluate the work of a Scrum Master based on the results? is Not based on KPIs, because they can show nonsense results.

    At the same time, I leave at the top of the list those measures that should never be underestimated, i.e. customer satisfaction, team enthusiasm, and time to learn, meaning the agility of the entire organization, about which I will write another time.

  • Capabilities over Skills

    Capabilities over Skills

    … that is what I pay attention to when building teams.

    This text may be universal, but I put it in my professional environment, i.e. teams implementing IT projects in the Agile culture. I will focus on three main values ranked by me in order of importance:

    • possibilities (abilities),
    • commitment (willingness),
    • and skills (knowledge).

    Many people (PM, HR) find this order strange because they focus primarily on the skills and experience. This approach is caused by the knowledge assessment system built into us since primary school. The second reason is the short-sighted politics of the here-and-now company’s needs. However, transferring this approach to team building can reduce the potential value of the product. A unique person’s talents may be missed.

    The reasons for the proposed criteria and their order are obvious:

    • a capable and willing person will learn quickly (especially in a scrum project),
    • a skilled but less capable person is less able to adapt (which is particularly important in Agile),
    • a skilled person with abilities but without commitment is passive and this is a problem for the rest of the team and the Scrum Master.

    I write about it in both contexts: building the existing team and expanding with new members. When entering an existing team, cracks are visible at first sight. One of the strongest cracks is noob vs. senior. This is the ideal situation if the noob has great potential. If it is possible in terms of chemistry, just try to pair them up. This creates an atmosphere of improvement and instantly boosts morale. It’s a well-known move and probably many of you use it. In this way, we will build an incredibly lasting relationship like a “master with padawan”. This is a great way to build a long-lasting team relationship that will remain longer than one project.

    However, few Scrum Masters reach HR departments with this message before the recruitment finalization. The most common situation is the HR department operating in an uncoordinated manner throwing in the new ones “because this is what we were told to do”. I support the recruitment carried out by the team itself because it is the team’s competencies that “the new guy” is to fulfill. The recruitment process conducted by HR in consultation with the team gives much better results. Also, it often progresses faster, because the automatic rejection of candidates due to the lack of the required experience, supported by years of work, is pointless in many situations — it misses talents.

    PS. Never, ever do this, if you don’t have at least one really strong developer in the team.