Pawel Brodzinski on Leadership in Technology

Whatever it takes to lead a team, build a product, and run a business

Author: Pawel Brodzinski

  • Embrace Failure

    I failed. It wasn’t very spectacular. Well, if I asked people around they wouldn’t even say it was a failure, but for me it was below-average performance. Thus failure.

    Did I feel bad? I did. I couldn’t help. I knew I shouldn’t but after all I’m just a human. But then I consider it as much better thing which happened to me than just another success. Why?

    Because we don’t learn from successes. We learn from failures.

    When we achieve success it’s like someone was telling us “you’re great, no need to change.” And there is a need to improve. Always. The thing is we usually don’t see it unless we fail.

    The trick is to embrace failure. Welcome it warmly. It is your ticket to another learning session. Yes, you will fill badly for a while, but in the long run it is more valuable than success.

    Failure is an eye-opener. Suddenly you see what you were doing wrong and you don’t understand how blind you’d been not to spot it earlier.

    Failure is a kick in the butt. You feel bad so you know you have to do something to avoid this unpleasant feeling next time. Unless you’re a masochist and you like to feel bad.

    Failure is a helping hand. You get some guidance what you should improve or what you should avoid.

    We are told we should embrace change. I see no reason why we shouldn’t embrace failure.

  • So You Promoted Wrong People to Management, What Now?

    It seems recently I’m telling you a lot stuff about people management and managers in general. If describing the role of manager wasn’t enough you could also read a rant about screwed promotions which we see so often. This all stuff is good (yes, such a shameless self-promotion), but it assumes one optimistic thing: you can still make decisions who will be promoted to management.

    However sometimes we don’t choose who is promoted to managerial positions. These decisions have already been made and they’ve been made wrong. If your task is to deal with that you’ll need to follow a three-step scenario.

    1. Coach

    OK, great engineer doesn’t make a candidate for a great manager. But it doesn’t make you can’t make a good manager out of great engineer. The trick is to raise awareness that someone doesn’t perform well as a manager and coach them to improve their people skills. Help them to change their focus from engineering to people management. However this effort can’t be unlimited. If someone isn’t willing to change you won’t force them. Then it’s time to move to the point number 2.

    2. Find a better place

    If someone excelled as an engineer and you can’t make a good manager out of them you might try to move them back to some engineering-related role. Maybe design, maybe architecture, maybe even project management would be a good place. It all depends on an individual case. Of course it is tricky – what you basically do is you move someone back from management to engineering, so you better have pretty prestigious engineering roles. And do it if, and only if, you believe the person would perform well in a new role. If you can’t find such role or leaving management isn’t really an option all you’re left with is a solution number 3.

    3. Let them go

    If you can deal with an issue other way you should let wrong people go. And yes, this means you’re losing a great engineer, who unfortunately became poor manager and is unwilling to switch back to the role which he performed well at. What you’re left with at that point is either to keep someone who do crappy job, which also affects their team, or to let them go and find possibly a better candidate. Well, if we discuss someone who failed at points 1 and 2 of the plan I’d let him go. As harsh as it sounds it is a good decision for both of you and for the discussed team.

    Keeping poor managers is much worse than admitting you’ve made wrong decision promoting them in the first place.

    And if you want to see more stuff about being a good manager you will appreciate my recent presentation titled Good Manager, True Leader, which I delivered at our internal company conference.

    Good Manager, True Leader

  • How to maintain backlog?

    In one of recent postings I asked you how big your backlog is. My argument was that trying to enforce small backlog size is counterproductive. Although small backlog is easier to manage throwing things away from it just to keep it small isn’t the best idea.

    However that doesn’t mean you shouldn’t do some backlog maintenance from time to time. What more, applying a few simple rules can help you to manage backlog easily despite its pretty big size.

    Keep epics, split late

    Sometimes we add to our product a big story. An epic. It is actually pretty interesting example in terms of sizing backlog. Why? Well, no matter if you split the epic into a list of smaller stories, i.e. sized similarly to your typical features, or keep it big you add a huge piece of work. A piece, which usually makes sense as long as it is completed as a whole. So yes, you need quite a capacity to add the feature, no matter which approach you choose. What do you do if your backlog is limited?

    Anyway, my advice is to keep epics in backlog as long as possible and split them in the last responsible moment. It is aligned with agile late design approach but that’s not why I advise you so. Actually as long as you don’t start working on the epic there’s no reason to keep a dozen of sticky notes on the board instead of a single one. It’s enough for you to look at epic to know roughly what is to be done. You will need more details when you start development of first epic-related feature so no need to worry at the moment.

    It is easier to reprioritize the epic over and over again if it’s in one piece. And reprioritizing is the most common task when it comes to managing backlog.

    Groom from time to time

    If you have spacious backlog you will face this situation on occasions: you will find out that one or more features waiting in the backlog are no longer relevant. Maybe you’ve changed the goal of your app or you abandoned industry which was addressed with the feature or you just don’t have a faintest idea why you wanted to build the damn thing in the first place. Either way it’s time to forget about it.

    Grooming backlog is a great occasion to do that. What exactly grooming is? A simple process of reviewing all features in backlog to verify their relevancy. Yes, if your backlog is big it takes time. But after all this is the way to make it at least a bit smaller, thus more manageable. And you don’t do it every week as you don’t change general plans for your product that often.

    Group features

    There’s an observation which can be helpful as well. Unless we work on maintenance project where priorities are usually set by the client we tend to build groups of similar features and not randomly choose one from here and another from there. Grouping features which are similar or features which touch the same parts of code can be helpful in terms of prioritizing work. Once done you can just throw in another feature from the group instead of scanning through the whole backlog to look for a relevant task to put in todo queue. That is as long as your general priorities don’t change.

    Grouping features also helps in prioritizing whole backlog. Instead of considering each and every feature separately you decide on a group which means you use the same time to judge a dozen of tasks you’d use to judge a single task otherwise.

    Dealing with big backlog isn’t that hard after all. All you need is some order and a few rules which help you to organize a long list of tasks somehow.

  • Implementing Change

    The other day I was asked to discuss how we can improve the way one of our software development teams works. Well, actually it was rather something like “Pawel, help us to implement Kanban” but, as it soon appeared, it wasn’t that simple.

    A typical discussion about implementing Kanban

    Me: So where do we start?

    Colleague: Um, I’m not really sure if Kanban is really for us. Convince me.

    Me: I don’t want to. If something doesn’t suit your team I’ll be the last person to convince you to implement it.

    Colleague: So where do we start?

    Me: Maybe with problems you and the team have. I guess there are some otherwise we wouldn’t be talking now.

    It isn’t about applying recipes

    The discussion changed its course. We immediately switched from discussing Kanban to talking about issues and looking for a solution which would be suitable in each and every individual case. If one of problems is people don’t want to have yet another place to do task management, and they can’t abandon either of current systems, introducing Kanban board may not be as great idea as it initially appears.

    If you start discussion with the conclusion already fixed in your head you will not only miss opportunities to improve but you also risk applying the wrong cure and making the situation worse.

    It is OK if you just don’t know

    A couple of times through the discussion I came up to the point where I had no idea what the right solution might be. And this is perfectly OK. It’s not about playing knowledgeable person. It’s about giving the good advice or not giving any advice at all.

    What more, admitting that you don’t know the answer is just a starting point for digging deeper. Each of these moments triggered some changes in our analysis. If we can’t go further here, maybe we should try there. Let’s stop talking about techniques which may or may not work and make a fast-paced Q&A session about potential issues the team may face. Or maybe let’s do mental walkthrough of processes the team covers.

    As it appeared each time we admitted that we don’t know helped us with coming up with a reasonable conclusions at the very end.

    Adjust tools for people, not the other way around

    When you know some method or approach and it works fine for you, you are always tempted to apply it in other environments too. The problem is other environment means other people. As a result your approach may not be so great anymore.

    But who said you can’t change the approach? Are methods we use some kind of dogma? Actually choosing a subset of techniques or practices from any given methodology is usually better than not using them at all. And if you choose wisely even a couple of small changes may yield significant improvements. So yes, do adjust methods before applying them.

    That doesn’t mean people shouldn’t change ever. Of course they should. But motivation to change should be intrinsic and not enforced from outside, i.e. because manager told so.

    A funny thing is that with this approach you can end with similar conclusion to the one you started with. The difference is now you are more likely to succeed as, even though you aim at the same target, you will choose different way to get there.

    And in case you were curious, yes, we eventually came back to Kanban.

  • One Measure to Appraise Them All

    Once your organization start talking about performance reviews you usually hear about some formal system with the same structure for everyone involved. That doesn’t really sound like a good idea, right? Why companies are using this approach then?

    If you have like a couple hundred people on board C-level exec can’t really say anything reasonable about vast majority of people in the organization. However leaders have to make some decisions basing on employees value, like firing rotten apples or promoting best candidates for managers.

    This is the point where management is tempted to build an appraisal system which makes it possible to compare people easily, so all these decision can be made basing on hard data. The system ends up as stiff and structured checklist which produces grades in the same categories for each employer.

    And this is utterly wrong.

    Actually I believe you can hardly do worse. This approach not only makes an illusion of producing comparable results but also harms relations between managers and their subordinates since performance reviews following this pattern just suck.

    Do a simple exercise: take a description of a few requirements and send them out to a bunch of managers working in software development teams. Now ask them to judge each feature in a few categories in a scale from 1 to 5. Let them judge difficulty, work consumption, innovativeness and business value. Grab these numbers from managers and compare them.

    You will see that someone hit average of 3,5 and another barely 2,5. You will see how differently people look as specific categories. You will see how vague one-word category definitions are. Basically, you will learn what subjectivity means.

    Now, I have a message for you: people are hell lot more complex than software requirements.

    If you used the same system for people what you would get is a set of top marks for a handful of organization’s gurus, handful of worst grades for a bunch of incompetent slackers and like 90% of random results for the rest of people.

    In uniform appraisal system this is taken as reasonable data which decides on a number of things, starting with promotions and money and ending with general respect. These numbers make or break careers. And yes, I’ve just called this data random.

    But that’s not the worst thing which is introduced by uniform appraisal system. Yes, it can be worse.

    Formalized, homogenous appraisal system degrades performance review to simple mark trade instead of making it an occasion to exchange feedback.

    You get what you measure. If you measure few criteria, and these criteria are uniformed among the organization, you create incentive to fight about better marks, so people would get more money, have better chances for promotion and would be able to boast in front of their colleagues how cool their marks were on the last review.

    There is a side-effect too. This approach creates an incentive for managers to run crappy reviews. Instead of focusing on two-way communication, learning what motivates their people, they just go through a simple script: programming three, communicativeness two, quality four, team work two, creativity five, next please. Hey, this is what the system expects from us, doesn’t it?

    Running performance reviews is pretty damn hard job. I always feel stressed when I’m going to talk about one’s performance, no matter how official or unofficial it is. Yes, it is easier to just go through a number of marks and call it a day, but that’s not the option which works for reviewed people. Unfortunately not everyone understands that, so we should build systems which create incentives for positive behaviors, not the negative ones.

    So while I don’t agree that performance reviews are evil in general, we can hardly think about worse approach in this area than a formalized, homogenous appraisal system which unifies measures among all employees. That’s just not going to work.

  • The Kanban Story: Small Tricks Do the Job

    On my AgileCE presentation on Kaban I said that if your Kanban board doesn’t evolve over time you should treat it as a warning sign. It possibly means you don’t improve workflow. And since there’s no by-the-book implementation of Kanban you should experiment all the time.

    So what has changed on our board recently?

    I can start with things which remain the same – this time we didn’t change structure of workflow. Columns are exactly the same. Limits stand still. But you shouldn’t consider at Kanban board being just a list of stations with appropriate limits attached. Kanban board is a single most important tool you use in Kanban. You look at the board a number of times daily. The more you see there the better is the board. This doesn’t mean we should make our boards completely cluttered. After all, if there’s too much in one place you stop seeing anything but clutter.

    OK, you already know we added something to the board. A few things actually.

    • Different sticky note colors. At the beginning we were working mainly on a single project. Recently we forked our efforts and now we work on 3 different applications. Getting separate color of sticky notes for each project was no-brainer.
    • Blocker flag. Visual mark of blocked feature is a small red sticky note attached to the main card. This is another obvious trick. We added it when we faced the first issue being blocked by external source.
    • Color magnets. We use whiteboard as our board. To make it visible who actually works on specific feature we put color magnets on sticky notes. Each team member has their own color. (Mine is white since I’m such an innocent guy.) Magnets give us quick information about load of each of us at any given moment. Besides, they keep cards from falling down.
    • Dates. We write two dates down on sticky notes. First when we start working on feature and another when we’re finished with the task. We keep forgetting about these dates, since this is pretty fresh idea, but that’s not a problem to fill them after a couple of days when we still remember well when we started/finished work on MMF. This trick helps me to report retroactively cycle time. Earlier I had to dig for information in task management system.
    • Numbers. Each sticky note has its own unique number. This makes it easy to link anything with MMF. A bug? We start with a number and everyone instantly knows which feature is defective. A task? We start with a number and we know which development tasks are related with MMF so we can tell how much work is remaining. We even use them in discussions: “Have you finished ninety seven yet?”
    • Excel sheet as backup. One day I thought what would happen if our cleaning lady would, well, cleaned our board. Man, we would be doomed. So I made simple sheet where I add information about every sticky note, which makes its way to the board. It is also a place where I store information about cycle time etc so it serves as reporting tool too.

    None of these improvements is significant. A few are pretty obvious. Yet when we were starting with Kanban we didn’t use any of these small tricks. They emerged as tiny improvements of the board and the process. And these small tricks do the job. Even though neither of them brings much value on its own they add up and make the board significantly better.

    As additional reading learn how our Kanban board evolved. Check out the whole Kanban Story too.

  • The Role of Manager

    I took part in a very interesting discussion today. We were talking about criteria we should use to appraise leaders and managers in the organization. The most surprising part, at least for me, was discussion about notion of line manager among disputants.

    It came out that we considered average functional manager as anything between pure-manager to person who does 90% of engineering work mixed with 10% of managerial tasks. That’s a variety of options, isn’t it? As you may guess I supported rather the former than the latter.

    Well, if I’m such an opponent of letting people do what they used to do before they were promoted to management, likely coding if we talk about software teams, what I think they should do all day long? In other words what is, or should be, the role of manager.

    Leader

    This vague term describes first and most important trait most managers should have and only few have. If I’m a team member I expect my manager will show leadership and charisma. I want to be ignited to follow his ideas. I need to be sure he knows why and where we are heading. I have to see him around when problems arise. I eager to be managed by someone I’d like to follow even if no one told me so. A good manager is also a good leader but these two are not the same. What a pity it isn’t common mixture.

    Coach

    Help newcomers with learning the organization. Help inexperienced with gaining experience. Help everyone with growing. Help those with problems with fixing them. Easy? No, not at all. First, you need to know who needs what. Then, you need to know how to reach people so your helping hand won’t be rejected. Finally, you need to work carefully and patiently sharing your knowledge in experience in a way which doesn’t frustrate or dishearten people. Repeat when finished.

    Shield

    As a line manager you have some senior management over your head. This is a bad news. Actually there’s usually a lot of crap flying over there and, because of the gravity, it’s going to land down on heads of your team. There will be blame games. There will be pointing fingers. It is your time. Be a shield. Take enough bullets on your chest for the team. You’ll earn respect. You’ll earn a bunch of loyal followers. And that’s how you earn your spurs.

    Advocate

    As a manager you’re also an advocate. Devil’s advocate to be precise. You have to present and defend different decisions made up there, in the place where only C-level execs are allowed. Sometimes these decisions you won’t like. But for your people you’re still the face of the company so don’t play the angry boy and act like a man. We don’t always do what we want. After all, they pay you for this, remember?

    Motivator

    Sometimes everyone needs a kick in the butt to get back to work at full speed. It would be quite a pleasant task but unfortunately kicking butts is used as a metaphor here. It’s all about motivation. And I have a bad news here, there’s no easy answer for a question what motivates people. You have to learn each of your people individually. Oh, forgot to mention, it takes quite a lot of time to learn what drives all these people.

    Adviser

    Yes, an adviser. Not a decision-maker. At least not unless you really have to make a decision by yourself. People will come to you asking different things. Well, they will if they think your opinion may add some value and you’re capable to understand what the hell they are talking about. Of course you can guess or shoot or use magic 8 ball but you better learn (oh no! more learning) what the problem really is and help your team to solve it. Note: it is different than solving it for them, even if you know the answer. If an association which comes to your mind is delegation I must praise your reasoning.

    Now if you are done with those and still have enough time to keep up your outstanding engineering skills, please do Mr. Anderson. Unfortunately chances are good it is enough to fill more than a full working day so you’d have to choose between focusing on your management or technical skills.

    And if you happen to spend two third of your day coding, well, I dare to say you aren’t a manager I’d like to work for. Your people would say the same, but you don’t talk with them so you don’t even know. After all there’s no time to chit chat, you have to code, right?

  • Performance Reviews Are Dead, Long Live Performance Reviews

    Recent NPR story about (lack of) value in performance reviews caused a stir. Esther Derby reminded her long-time hate relationship with performance appraisals pointing that not only employees but also a lot of managers hate them. What more reviews are tied to merit pay which is also evil.

    Well, I think it is oversimplification. We think performance review and we see corporate environment with multiple levels of management, constant fight for budgets, tough negotiations about rises and likely yearly appraisals which are so outdated that hardly bear any value for employers. If we discuss this kind of reviews, then agreed, they suck. They should be banned and people enforcing them should be forbidden to manage teams for at least 5 years.

    Now, tell me I’m lucky but I had probably just a couple of these crappy appraisals. And hopefully I have performed none of those by myself. By the way if I did it to you, feel free to kick my butt if spot me somewhere.

    Actually I tend to agree more with Scott Berkun who says that it is better not to do performance reviews at all if, and only if, they are done badly. It basically means most of the time we shouldn’t run performance appraisals but I boldly state I can to do better.

    So this is the time I should answer simple question: “How the hell do you do this damned thing?”

    Don’t make it all about money

    To some point I agree with Esther. If performance appraisal is reduced to a discussion about merit bonus or raise it is fruitless at best. Money-related negotiations always suck and this isn’t an exception. If you follow some formalized process you likely have to talk about money too, but then make it as short as possible. It is no fun for both of you so make it quick and move on to more pleasant parts of the ceremony.

    It is your goddamn duty to listen

    I am a chatty guy so this one I should tattoo this on my forehead to remind it to myself every morning when I look into the mirror. Performance review is one of the best occasions to listen what your team mate has to say. Let me guess, you, as a manager, don’t have a lot of one-on-ones with folks from your team. And even if you have, there are people down there who are always omitted. By accident of course. When you run performance reviews you suddenly have to meet every single one of them, so don’t miss this chance. Learn what they want to tell you. Let them talk. Listen. Not everyone will be open but at least give them opportunity to talk.

    Make it more a chit chat than a formal meeting

    One thing I learned during my early years as a manager is that when people are stressed they won’t tell you much. Yeah, that’s an epiphany, isn’t it? The most valuable things I learned about people, about teams and about me as a leader I heard during informal chit chat which I often turn my performance appraisals into. When we have the hard part (money-related) done we can talk more openly. Actually we may discuss your last holidays for an hour if you like. If nothing else I will know that you love hiking next time we meet in the kitchen. But we may also discuss situations when I screwed up as a boss or new technologies you’d like to learn.

    Let them set the rules

    You have different people in the team. There are those who don’t really care. Performance review is something you both have to get through but they don’t give a damn. The money doesn’t matter. Your opinion doesn’t matter. A discussion doesn’t matter either. What then? Don’t waste time of both of you. Say what you have to say and get back to work. But there are also people who want to talk. Let them talk. Listen. Learn. There are people who need a discussion about different things. Be a partner in this discussion. There are people who look for information. Share it. Besides the small part you have to go through, it’s not you who should write the agenda.

    Be open, be transparent

    If you are about to say a bit more than on weekly team meeting would there be a better chance than during one-on-one? If you are about to show your human face would there a better time? If you are about to discuss your motives standing behind tough decisions would you wait for another occasion? Yes, we managers are scared to shit when we share our secrets (or things we think are our secrets). But believe me; we should do it more often. As one of the best game strategies of all time says, if you play fair you will get the same in return. Be honest, be open and you will get exactly the same from your team. Isn’t that a fair deal?

    With these few simple rules I believe I’m able to run performance reviews which people don’t hate. Actually the last performance appraisal I’ve run I’ve started saying “As you already know no bonus money this time, so we can skip the formal part. Now, let’s talk.”

    I think it was pretty good appraisal. And yes, I’ve learned a lot. I’ve learned a lot despite I know the guy pretty long time already.

  • The Kanban Story: When and Why We Abuse Limits

    We have limits on our Kanban board. This isn’t really a news. Sometimes we abuse them. Since Kanban doesn’t force you to stick to the limits always-and-by-all-means it shouldn’t surprise you much either. However the interesting thing is when, why, how and how often we do it.

    I think I should start with stating that our limits are rather loose. It is technically possible to have as many as 15 MMFs in progress across the board. It never happened and it won’t ever happen, but still it is technically feasible. That’s crazy huge workload for 5-person team.

    But we happen to have limits like that and it’s not without a reason. If you recall our pseudo-iterations triggered by VCS issues you know we ship our software in packages of few (typically 2 or 3, sometimes 4) features. This means we sometimes move a group of 4 features across the board. For example it happens after deployment when we move features from testing complete to live stage. OK, enough of introduction about our limits.

    When do we abuse limits?

    It sometimes happens we change content of our deployment package on the fly. For example we have a package of 4 features in testing (either ongoing or completed) and then our crazy product owner (aka me) comes with an idea to add another tiny but super-important and super-urgent feature. Of course we could wait till another pseudo-iteration is deployed but sometimes it just makes more sense to add it to the old package instead of waiting another 13 days for another deployment package.

    We also had a painful MMF blocked for long weeks by our subcontractor. This practically reduced our limit in development by 1 for a longer time. It happened once that we decided to break this reduced limit acknowledging the fact we can do nothing more about blocked feature.

    Why do we abuse limits?

    Two words: common sense. If it is more reasonable to break the limit than to adjust whole work to our board we don’t try to perform some artificial actions just to be compliant with the process.

    We aren’t here for the board. The board is here for us.

    How do we abuse limits?

    First we all discuss the decision. Breaking the limit shouldn’t be treated as a normal thing. It is an extraordinary situation. So we collectively decide whether in this very situation breaking the limit is a better solution or we should rather stick to our constraints.

    This serves two purposes: one, we make this decision very consciously and two, we stress that it isn’t a typical and easy-to-accept situation.

    It happened once when I found the board with a broken limit with no discussion whatsoever about the fact. I fired two third of the team and burned whole office… Well, maybe not really, but man, I wasn’t happy. I wasn’t happy at all.

    How often do we abuse limits?

    This is the question you were waiting for, weren’t you? Pretty rarely I’d say – thrice a year. Well, describing it as an average result is a bit of abuse itself since it was our first year with Kanban. But you can see this is an extraordinary situation.

    To summarize, limits on our Kanban board aren’t a sacred cow. We break them if it does make sense and we decide it is a better solution than sticking to them at all cost. On the other hand we try to make breaking the limit an uncomfortable situation (you know, all this discussion, talking with each other… yikes) so we aren’t tempted to do this very often.

    So far it works pretty well.

    Read the rest of the Kanban Story.

  • Why I Prefer to Hire Women

    I have a news for you: IT industry is dominated by men.

    – Pawel, why don’t you tell us something we don’t know?

    There should be more women in the industry.

    Which part of “something we don’t know” you haven’t understood?

    Fine, you get the message. I just wonder why you don’t hire more women.

    I confess in my current team there is round number of women. Zero. I worked with a few teams like this. And every time one of my goals was to bring a few women to the team. Why? There are a few reasons. I will generalize here and I’m going to do it on purpose. After an hour or so of interview you can’t really say what kind of personality you deal with, so you have to go with your biases and prejudices anyway.

    • Women bring different soft skills to team talent pool. They’re usually more open and emotional than men. Do a simple test and recall your last retrospective or check the record from it. Can you see how different arguments were pointed by women than by men?
    • Women bring more culture. Pure-men groups tend to change into something like herd of hogs. Bringing a woman on board magically improves everyone’s manners and language. I mean hogs are nice but I wouldn’t like to work with them.
    • Women are more responsible. This may be one of my prejudices but I find women more responsible than men. I can hardly recall any woman who came to work having heavy hangover while I have no problems to name a long list on men who did.
    • Women are more accountable. It is connected with the previous point. Women tend to treat their duties very seriously. Even when it is something they didn’t personally commit to but rather something their boss expects from them their commitment is usually stronger. And I think here about these unrealistic expectations many poor managers set against their teams too.
    • After all, there aren’t many women in the industry so don’t make it even worse.

    Having said that, I’m not going to hire woman over man just because of sex. If there’s a significant difference between two candidates I will always choose a better one, however I understand “better” at the time. But at the same time every woman entering an interview with me has a small plus for free at the beginning. I guess I could put it as one of recruitment tips but changing your sex isn’t a great tip, is it?

    On the other hand I’ve seen enough prejudices working against women to throw my two cents. And I have a question for you: having two similar candidates which one would you choose?