Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • Portfolio Kanban: Why Should I Care?

    It’s an interesting observation for me: people keep asking me to speak about Portfolio Kanban. London, Krakow, Chicago… it seems that for me Portfolio Kanban is going to be the topic to speak about this year.

    When I started with Portfolio Kanban it was an experiment – a tool I wanted to play with to see whether it is useful at all. When you start speaking publicly about such things though, there is one important question you have to answer: why should anyone care?

    After all, unless the question is answered Portfolio Kanban is just a toy.

    So… why?

    When I look at work that is happening in lean and agile communities I see a lot happening on a team level. Scrum is a framework designed for a team level. When you look at Kanban implementations, vast majority of them are on the same level too. Now, should we be worried? Is it wrong? No! It’s perfectly OK. Well, sort of.

    Let me start with this:

    A system of local optima is not an optimal system at all; it is a very suboptimal system

    Eli Goldratt

    Focusing on a team level and a team level only we are optimizing parts as rarely a single team is a whole. I’m far from the orthodox view that we should focus on optimizing the whole and the whole only, as most of us don’t have enough influence to work on such a level.

    It doesn’t mean though that we should cease any responsibility for optimizing the whole system, no matter what sphere of influence we have.

    This is basically why improvements on a portfolio level are so crucial. They don’t have to be done instead of improvements of a team level or prior to them. In fact, a holistic approach is probably the best option.

    If you aim your efforts on a team level only you likely become more efficient, but the question is: efficient at building what?

    Processing the waste more effectively is cheaper, neater, faster waste.

    Stephen Parry

    If the wrong decisions are made on a portfolio level, efficiency on a team level doesn’t really help. What’s more, it can even be harmful because we just produce waste more efficiently. I can think about a number of wasteful activities imposed on teams on a portfolio level, but two are the biggest pains in the neck.

    One is starting projects or products that shouldn’t be started at all in the first place. There is dumb notion that people shouldn’t be idle, so whenever individuals or teams have some spare time it is tightly filled with all sorts of crazy ideas that simply aim at keeping people 100% utilized. That’s just plain stupid.

    Usually, even when people are busy, they get this kind of work anyway, as “they will cope with that somehow.” After some time not only do we run lots of projects or initiatives of questionable value but we have to spend additional effort to finish and maintain them.

    Another pain point is multitasking. All these filler projects are obviously of lower priority than regular work. So what people end up with is they keep switching between projects whenever higher priority tasks calls. The problem is that a context switch between two projects is even more painful than a context switch between two similar tasks within the same general context. Oh, and have I already mentioned that once you’ve finished those filler projects you keep switching back to them to do maintenance?

    So basically what you get is very low value work at cost of huge context switching tax. Congratulations!

    Oh, is it that bad? It’s even worse.

    If you are doing the wrong thing you can’t learn, you will only be trying to do the wrong thing righter.

    John Seddon

    If the organization starts all the fires on a portfolio level, teams end up trying to cope with that mess. If they care, they will make the wrong thing a bit better. Does it help? Not at all. The sad thing is realization what could have been happening instead, which is basically learning.

    The organization could have been learning what work really adds value. The teams could have been learning how to work better. On all levels there would have been opportunities to improve thanks to occasional slack time.

    And, by the way, the organization would have been operating more efficiently too, thanks to less context switching.

    This is basically why you should focus more on organizing your project / product portfolio.

    Why Kanban in this application then?

    I guess I already gave the answer between lines. Visualization, as always, enables harvesting low-hanging fruits. I mean, unless we see how screwed up we are, we often don’t even realize the fact. Visualization also helps to substitute everyday project-related wild-ass guesses with everyday project-related informed decisions. Sounds better, doesn’t it?

    Then there are WIP limits that enable conversations about what projects get started, how we staff the teams and how we react in all sorts of special case situations. In fact, without that bit changes introduced by Portfolio Kanban will be rather shallow.

    Finally, if you are aiming for improvements, Portfolio Kanban gives you a change mechanism that is very similar to what you know from team level Kanban implementations.

    The best part though, is how easily you can start your journey with Portfolio Kanban. Even though it tackles the part of the organization that is usually highly formalized and full of politics, Portfolio Kanban doesn’t require, at least at the beginning, to have everyone signed up for the idea. A single person can use Portfolio Kanban as a disruptive weapon and see what it brings.

    Seriously, it’s enough to have only one person willing to work consistently on Portfolio Kanban board to see the first yield of the improvements. And one doesn’t have to wait very long until the first meaningful discussions around projects start. Then you know something has already changed.

    Even when no one really realized you used Kanban to achieve that.

    If you liked the article you may like my Portfolio Kanban Story too.

  • Brickell Key Award Nomination

    I’m on cloud nine. I was nominated to this year’s Brickell Key Award. For those of you who don’t know what that is, Brickell Key Award is the way of honoring people that have shown leadership and contributions in Lean Kanban community. I wouldn’t fancy the award that much if not the list of people who won it during previous years: Jim Benson, David Joyce, Arne Roock, Russel Healy, Richard Hensley and Alisson Vale

    There’s another part of the story. I’m simply honored to be in the company of Jabe Bloom, Yuval Yeret, Hakan Forss, Chris Shinkle and Troy Magennis as the nominees. In fact, my humility suggests me to question whether I even belong to this splendid pack.

    I’ve never been a part of Lean Kanban community for material gains as I still (happily) sit on practitioner’s side of the fence and use occasional consulting gigs mainly as a way of sharpening the saw. It gives me comfort of straight talking, as I’m not trying to sell anything to anyone. Probably if you read my writings, heard me speaking at events or simply talked with me you know what attitude I’m taking about. After all whenever learning something new last thing you want is a rosy picture.

    My hope would be that my efforts helped you and your teams understand what Kanban is and how to implement it successfully. If it was so and you want to share some of the love this is the right time let know the selection committee (or simply leave a comment under the post which is awesome too).

    By the way, if you want to share some hate because I misled you or something, that is fine too. I love critical feedback, and it’s definitely helpful for the selection committee as well.

  • Why I Don’t Limit WIP (On Occasions)

    As much as I love visualization as a technique that gives pretty much any team handful of quick wins, I do consider limiting work in progress the bit that makes or breaks team’s long-term ability to improve. Introducing, fine tuning and maintaining WIP limits is arguably the most difficult part of Kanban implementation, yet the one that pays of big time in a longer run.

    Shouldn’t limiting WIP be a no-brainer then?

    No, not really.

    Introducing work in progress limits is an investment. A long-term one. If a team isn’t ready to make long-term commitment to limit WIP it may not be their time yet. I mean, would you expect that a pretty much chaotic team would understand their process, let alone shape the process using WIP limits? They have quite a few prerequisite steps to make so let them start with that.

    OK, but this is the case of teams I often dub immature. But then there are teams that I’m working with and that most definitely are mature enough and we still don’t introduce WIP limits.

    Why?

    Introducing work in progress limits is an investment. A long-term one. Have I already said that? Oh… Anyway, if we are talking about sort of temporary team working on short-term arrangements investment into making WIP limits work may not be worthwhile.

    Let me give you an example. One of my recent project lasted 7 weeks, including first couple of weeks to get things running. Over the course of the project team setup has changed twice. Our environment was far from stability.

    Instead of setting up explicit WIP limits we just paid attention to what was happening on the board and were reacting whenever needed, using a couple rules of thumbs:

    • Whatever is closer to completion (further down the flow) it has priority over stuff that is on earlier stages.
    • We finish what we’ve started before moving on to another task, unless we encounter a blocker.

    Thanks to that we naturally limited work in progress and context switching despite lack of work in progress limits. Probably it wasn’t that strict and aggressive as it would be with explicit WIP limits, but I still think we’ve done decent job.

    The interesting thing is that I doubt we’d be able to fine-tune the WIP limits before the end of the project, even knowing everything we know once we are done. The situation was evolving very rapidly; bottlenecks were in 4 different places throughout these few weeks. We’ve made a couple of gut calls deciding who should do what, like developers helping with testing or design. In fact, we didn’t need explicit WIP limits to make these calls, although definitely understanding how the work was done was a crucial bit.

    If the project was supposed to last a few more weeks we would already have WIP limits on our board. But now the situation has changed; people are working in different setup, so limiting work in progress has to start from scratch.

    There are two lessons in the story. One is about WIP limits – they are a long-term investment and every team adopting WIP limits should understand that before they start. Another one is that even if you don’t have explicit WIP limits understanding how the work is done and reducing how much work is started helps. In some way it is limiting work in progress too.

    You don’t have to use fancy techniques to limit WIP. As I often repeat: read the board from right to left and start with the stuff that is more to the right. To be precise, this should be: read the board from where the flow ends to where the flow starts, as there are many non-standard board designs, but the idea is basically the same.

    You don’t have to work hard to start more stuff – it happens almost without any conscious effort. You have to work hard to finish more stuff. And this is what WIP limits help you with.

  • Making Use of Estimates

    I’m not a fan of estimation. I try to avoid it when I can. However, I’m not orthodox. I won’t be telling everyone that refusing to estimate is the way to go.

    I admit that I’m now in a comfortable land of time and material contracts that give more flexibility to the clients and more safety to the vendors at the price of mutual trust. At the same time Lunar Logic is the first of my jobs that works this way, so I’m more than familiar with fixed everything sort of contracts too. In that world estimate is a king. A lousy king though.

    Despite the fact, that fixed price projects are a nightmare from my past life, we can’t forget about estimation at all. Even those awesome folks we started working with recently started with asking us to deliver estimate in story points or other abstract measure of our choice.

    I intended to track progress in the project with Cumulative Flow Diagram (CFD) that counts only a number of tasks completed. However, having individual estimates for all the stories in backlog it’s easy to have two CFDs: one tracking a number of stories and tasks and the other that refers to initial estimates.

    One might suppose that it would be basically the same data on both charts. And one would be wrong.

    Let’s start with the charts. Here’s standard CFD for the first few weeks.

    CFD

    And here’s CFD that bases on estimates in story points.

    CFD

    What’s the difference? In fact, there are quite a few of them.

    For the starters, the scope changed only on the first chart. What does it mean? Simply that despite no change in total points there were new tasks. In this case almost all of them were non-functional tasks like setting up the environment, design pre-processing and adjustments in existing code that enables integration with the new part of an application.

    There was also a split of one of stories to a couple of them for the convenience. The total estimate didn’t change although there was a new story to build.

    Another thing you may notice is that on the second chart we’ve finished anything pretty late in the project, while the standard CFD shows completion of a couple of features early. Again it is connected with non-value-adding and non-functional features that had to be completed to get the team running.

    Finally, and most interestingly, try to judge amount of work in progress and size of stories in progress looking at the charts. A hint: you will find the answer to the former in the first and to the latter on the second chart.

    Standard CFD tells you that we care about limiting WIP and avoid starting too much. The story point-driven chart shares a different story. Steepness of the coding curve indicates that we’ve started with heavy features. In this case heaviness was mostly driven by risks – the heaviest features were most risky ones. We decided to start with them to address risks pretty early in the process so if there’s a screw up on the way we know it as soon as possible.

    By the way, I don’t focus here on the data that you specifically get from CFD. You could draw exactly the same conclusions if you used burnup charts, which are gateway drug to Cumulative Flow Diagrams.

    Obviously, CFD can tell you a bit more, e.g. about the awesomeness of the client, as they don’t ever have anything stacked in approval. Whatever is ready it gets verified and accepted.

    Anyway, the point is that despite I don’t feel that detailed estimates in this project really pushed us further (maybe despite building trust relationship, but that’s a different story) we can still use the work invested in estimation to learn something.

    And, as you see, you can learn quite a bit using very simple tools.

  • No Authenticity, No Leadership

    There’s one thing about me that virtually every boss I’ve had so far has tried to correct. If you look at me all my emotions are painted on my face. You just can’t fail guessing whether I’m happy, worried, tired, excited, etc. I’ve heard so many times that I should do something about that since having people see my negative emotions definitely isn’t a good thing.

    You know, they see you worried so they instantly start worrying too and you don’t want to have worried people.

    I think I’ve even tried to change that. Fortunately, I’ve failed. Not that I don’t see how leader’s emotions can influence team’s behaviors. I do. And I know that sometimes I’m not helping, sorry for that.

    On the other hand, I’m honest and transparent this way. I’m all for honesty. I believe that transparency is a crucial ingredient for building a healthy team or a strong organization. In the worst case this attitude is a mixed blessing.

    But that’s not why I won’t try to change the behavior any more. I won’t do it because it’s who I am.

    One doesn’t have to like it. Such attitude doesn’t fit every organizational culture (and I learned it the hard way). But you aren’t a leader if you aren’t authentic.

    I was reminded that recently by Gwyn Teatro with her story about what leadership is. One bit I really loved:

    The man was successful because he did not pretend to be anyone else. His communication style included fun, laughter and humility. It worked for him simply because it is who he is.

    More than about anything else it’s about authenticity. People catch false tones sooner than you think. Then, they start guessing what really happens under the mask. It’s likely that their guesses are worse than the truth that one tries to hide. After all we are a creative bunch, aren’t we? It soon becomes worse: they don’t listen to the truth, even when it bites their butts. They just know better thanks to the gossips and far-fetched hunches. Their “leader” hasn’t been authentic so what’s the point of trusting him?

    So no, I’m not trading my authenticity for anything. Not worth it.

  • Retrospectives Reloaded

    I’ve read and heard a lot advice on running better retrospectives. I’d even go that far to say that if you speak at agile event and you want an instant hit “how to run a good retro” should be very high on your list of potential topics.

    After all, this whole “getting better” thing seems really important to everyone and improvement is almost always a struggle for teams. A retrospective is a nice package; it’s pretty self-explanatory, it has a good name and it’s open-ended enough that you can adjust it to your needs.

    It’s not a new concept though. I was doing post mortems back then when agile was just a word in a dictionary. Same goal, different package. Well, maybe not that sexy, and that’s exactly why you should rather jump on a retro bandwagon to win the crowds.

    Anyway, the problem with vast majority of stuff I’ve heard or seen about running better retrospectives is simple: they are all recipes. You may apply them and they either work or not. Even if you’re lucky and they happen to work once, they quickly wear out. After all, how many times do we laugh at the same old gig?

    Then, we’re back to the square one. How to revive the next retro one more time?

    It’s because we get the wrong advice on retrospectives over and over again. It shouldn’t be “try this” or “try that.” The real magic happens when the thing you do during a retro is fresh and everyone gets involved.

    Both things are often surprisingly easy. You can count on people’s engagement when you don’t push them out of their comfort zones too far, e.g. I would say that singing in front of the team probably isn’t the best choice you might make. But all sorts of drawing are usually safe.

    And being fresh? Just think about all these funny ideas you discuss by the water-cooler. Playing an act, recording own version of movie classics, a concert, a cooking event, or cleaning a randomly chosen car on a parking lot are all such concepts. People were enthusiastic to sign up for such things. Wouldn’t they be so if it was a part of a retro?

    However, if you’re going to use a cooking event as an awesome idea for the next retro you understood nothing. Go, read the post again from the beginning. I don’t want to give you any recipe. I’m going to simply point the fact that every goddamn team on the planet Earth has a ton of fresh ideas for their next retro. It’s enough if you retrieve a single one of them.

    In fact, it’s even better. If you use one of those crazy ideas your team discussed a couple of days ago during lunch, odds are they will eagerly sign up for it.

    This is why I’m not going to be stunned with the next “better retros” session. Because, you know, I have such a session a few times a week. I just pay attention.

  • Emergent Explicit Policies

    One of Kanban practices is introducing explicit policies. It is the policy that probably gets least publicity. I mean I could talk hours about visualization and don’t even let me started with WIP limits thing. Managing flow gives me a great starting point for the whole debate on measuring work and using the data to learn how the work is done. Finally, continuous improvement is the axis that the whole thing spins around and a link place to all sorts of beyond Kanban discussions.

    Note; I put introducing feedback loops aside for the sake of this discussion as it is still new kid on the block and thus it isn’t covered that well in different sources.

    On this background explicit policies look like a poor relative of the other Kanban practices. Seriously, I sometimes wonder why David Anderson put it on the original list back then when he was defining what Kanban method is. Not that explicit policies are unimportant, but their power is somewhat obscure.

    After all what does it mean that we have explicit policies? What does it take to have such a thing? When I’m training or coaching I like to use this example: if I take any member of the team ask what random things on Kanban board mean they should all answer the same. I ask about things like, what exactly is represented by a sticky in a specific place of the board or what the meaning of a specific visual signal is, e.g. pins, magnets, different marks on stickies etc.

    I don’t subscribe to a common advice that you have to write policies down and stick them to the board to make them explicit. I mean, this usually helps but it is hardly enough to start. Explicit policies are all about common understanding of how the work is done.

    And this is where real fun starts. If we are talking about common understanding we should rather talk about discovery process and not compliancy enforcement. If it is about discovery process we may safely assume two things:

    1. It has to be a common effort of the whole team. One person, a leader or not, just won’t know everything, as it is about how everyone works.
    2. It’s not one time effort. As the team approaches new situations they are essentially introducing new behaviors and new rules.

    This is a real challenge with explicit policies. Unless you get the whole team involved and make it a continuous process you’re doing suboptimal job with policies.

    What you aim for is to have emergent explicit policies. Any time that a team encounters a new situation that calls for a new rule you can add it to the list of policies you follow.

    By the way, this is where having policies written down proves useful. I would, however, argue that printed sheet rather discourages people to add something, while a set of handwritten sticky notes or a hand writing on a whiteboard does the opposite. This is why you may want to use more sketchy method of storing the list of explicit policies.

    Another thing is what should make it to the list. As a rule of thumb: the fewer, the better. I mean, who would read, and remember, a wall of text. Personally I would put there things which either prove to be repeatedly problematic or those that are especially important for the team.

    After all, your policies are emergent so if you missed something the team would add it soon, right? In fact, this is another thing to remember. The last thing a leader might want is to be considered the only person who is allowed to change the list of policies. Personally, I couldn’t be happier when I saw a new policy on the board that was scribbled there by someone else. It is a signal that people understand the whole thing. Not only do they understand, but they do give a damn too.

    Without this your policies are going to be like all those corporate rules, like a mission statement or a company vision or a quality policy. You know, all that meaningless crap introduced by company leaders, that has no impact whatsoever on how people really work.

    You wouldn’t like this to happen in your team, would you?

  • Flying Office

    I’ve been working as a manager for the vast majority of my career. Teams I led consisted between a couple to 150 people, most of them being bigger than 20. Throughout that time I’ve had my own office once. And I don’t think it’s been a good idea.

    I decided to move to the office as I didn’t really see any reasonable setup that would work with a team spread across 40 rooms. It was then, when I first thought about the idea of sitting with one team for a week or two before moving to another office to join another team. I didn’t decide to pursue the idea though.

    The thing that kept me from doing that was the organizational culture. I was a parachute boss for everyone and the division hadn’t existed before as a single entity, thus there was very little to no trust to me, or between teams.

    If I’d popped one day in a random office stating that I’d been planning to sit in for a couple of weeks it would have been interpreted as spying on the team (or some other, more sophisticated form of repression).

    Fortunately, this time the situation is different. The organizational culture in Lunar Logic is way more open. No one assumes that the boss has bad intentions. In fact, I’ve had first discussions with people being concerned about my actions just a couple of weeks after I joined.

    It takes courage to go to your new boss and interrogate them about their plans and intentions. Such an attitude means that people voluntarily become vulnerable. It also sets up a completely different environment a leader acts in.

    So this time I’m not going to have a private office, not a chance. After just a few weeks spent in a neutral place I fetched myself a flying office. What’s that? A bean bag, a laptop table and a cardboard box.

    Flying office

    A bean bag works extremely well as a sitting device. It is extra-comfortable for short periods of time. On the other hand it would be painful, and unhealthy, to sit there for 8 hours. The latter reminds me that leader’s place isn’t on their butt but on their feet – running around, removing obstacles and solving problems.

    A laptop table solves a problem with keeping a laptop on, well, you lap, which, despite its name, isn’t the most convenient way of working.

    And I use a recycled cardboard box to store all my office belongings, which is simply a handful of sticky notes and a couple of pens and markers.

    This way I can grab my flying office to my hands and move it to the place where I’m needed or I feel like I can be helpful. I need just a bit of space in a corner or by the wall and done – a new office set up.

    Surprisingly, sitting in the corner and almost on the floor has a few unexpected advantages . First, you need very little physical space, which means you will fit to almost any room (unless it is already packed beyond any healthy limits). Second, this way you become almost invisible, which definitely helps if your goal is to understand how the team functions, and not just scratch the surface.

    Third, and arguably most importantly, you strip yourself from status symbols. Instead of a huge desk dubbed by your colleagues as the airstrip, a leather armchair and a locker just the simplest set that does the job.

    All in all, you’re way more accessible and much less intimidating. Isn’t that something every single leader should strive for?

    The flying office isn’t only very mobile; it also renders quite a few barriers that leaders often face irrelevant. Bringing oneself to a floor level is a challenge for ego though, but I’d say it is a good thing too.

    All you need to start it is just a bit of trust.

    Honestly, I regret I didn’t try it, despite the odds, when the only other option was a private office. I can hardly think of a different setup now, that I potentially have half a dozen more common solutions.

    How about you? Given that your team doesn’t work in a single room, are you courageous enough to try?

  • Gemba Walk Is Not Enough

    I’ve always had a love-hate relationship with Gemba walk. On one hand I just love the idea to go and see. In fact, whenever I have an issue to solve or a question to ask I prefer to move my butt and go meet someone instead of writing an email, chatting on IM or calling. I just use any pretext I have to meet people face to face.

    On the other hand, the idea of the Gemba walk, in its roots, goes way beyond simply solving issues. Just think about all those stories where leaders had their epiphanies when they randomly walked through a factory floor. Gemba walk isn’t just supposed to be an issue solving tool. Its main function is issue discovery, whatever an issue might mean.

    And this is where the hate part of my love-hate relationship starts. My previous professional life was leading 150 people. It meant that most of the time I was alienated. In a situation like that, you just don’t go into a team’s room as if nothing happened as almost certainly the observer effect kicks in and you experience something more like a play than reality.

    Not to mention that if you happen to be an introvert the whole activity can be insanely difficult for you.

    Obviously, it may be a very different experience if the organizational culture of a company is open and people generally trust each other. One, it isn’t that painful. Two, there is less acting and more honest and open discussions.

    It is still only halfway through though. As long as someone is willing to become vulnerable and open themselves you will learn something new. There is, however, the whole black mass of issues no one is really aware of so chances that you learn about them during a discussion are non-existent.

    In a plant you might spot something just by watching how stuff is arranged on a factory floor. In software development you don’t get even that. And, by the way, even if you brought your Gemba to the level of looking at things, e.g. code review, you still miss the point.

    No matter what the problem is, it’s always a people problem.

    ~Gerald M. Weinberg

    Following this advice, you shouldn’t look at things; you should look at people, their characters, behaviors and interactions. That’s where Gemba walk fails.

    You can’t make meaningful observations in the meantime, while you walk around and ask about everyone’s wellbeing spending just a while here before going there and then coming back to your own stuff. You can’t make meaningful observations of team dynamics during a chat with everyone.

    You have to be there. You have to breath the same air, share the same stories and see the same everyday routine. You have to become familiar and friendly enough that they stop playing. Or be there long enough so they get tired playing and become real.

    It doesn’t happen in fifteen minutes. It takes days. Weeks maybe. On the other hand you may expect a few low hanging fruits, which you spot pretty quickly, e.g. the way people address themselves in a discussion. Either way it doesn’t happen when Mr. Leader enters a room for his whatever-he-calls-it thing. It happens when a leader becomes almost invisible, sitting there in a corner, minding their own business and using those occasional bursts of action to learn something about their team.

    And this is why Gemba walk isn’t enough. It’s just scratching the surface hoping for luck.

  • Price versus Quality

    “Price has no meaning without a measure of the quality being purchased.”

    ~W. Edwards Deming

    It always fascinated me how price was the main axis of the game of closing software development deals. Unfortunately, in the vast majority of cases, pricing is used in total isolation from any other criteria, especially quality.

    It was like this when I worked on off-the-shelf ERP software. In this case it was, to some point, understandable. You can’t universally define functionality-to-price and quality-to-price factors if you sell the same product to thousands customers. It will be different in many cases.

    In such a case the question is what you deliver for the price you put on the tag attached to your product. Is it of high quality? And more importantly: do you keep, or even improve, the quality consistently?

    As a matter of fact, we didn’t. We didn’t think in such terms. It was more of a chase for more functionality to satisfy new customers than a conscious effort to keep the quality of software stable. You may guess how that affected the quality. Let me just say I’m not proud of the end result.

    It was still much better than what I experienced later, which was building custom projects for big clients. As a leader of software development and project management divisions I was often involved in the sales process. I was always asked how much time and people we need to build a thing. I was often asked about features the thing had or was going to have. I was never, ever, asked about the quality of the product or the tools we’d had in place to ensure this quality. Ever. Not a single time.

    It isn’t an industry-specific observation. I went through a few industries, including banking, insurance and telecommunications, and it was always the same.

    I’m compassionate for these poor chaps that were the decision makers. They followed their fears represented by the “nobody ever got fired for buying IBM” attitude. They just played it safe. In fact, I blame the system.

    I blame the system that disconnects the price from the quality of purchased goods or services. In such a case price is almost meaningless, yet it is almost always used as a deciding factor.

    The question I often wanted to ask the decision makers was: if they were buying the product with their own money would they be choosing the same? Obviously not. In fact, when we refer to our everyday lives, which I like doing, we never forget the relationship between quality and price.

    When I buy sticky notes to use on whiteboards I choose 3M even though they are pretty expensive when compared to alternatives. Actually, given a choice, I take 3M Super Stickies, which are even more expensive. It’s just the quality I need and I’m willing to pay for.

    When you think about the slow food movement being more and more popular over the course of the past 20 years, it follows the same pattern. Most of the premium products exploit the same behavior. Heck, how many of you, my dear readers, bought one of those overpriced smartphones or tablets? Apple fans, anyone? What is it if not paying for quality? And how do you choose a new car I wonder? By price tag only?

    So why, the hell, do you become Mr. Hydes when you return to your workplace and you choose a vendor? Oh, the system, I forgot.

    The system is, in fact, bigger than just an organization choosing a vendor. It spreads across most, if not all, of the vendors, too. A good picture of this would be a story my friend told me about the tender process in Romania in which he was involved as a representative of one of the bidders.

    When all the offers were formally submitted, the client organized a meeting with all the potential vendors, announced what the lowest bid was and asked everyone to reconsider their offers giving them half an hour to resubmit proposals with new pricing.

    When they had all the discounted bids re-submitted they did it again.

    It’s just spreading a sick behavior throughout the whole ecosystem. Optimizing solely for price means cutting corners on quality. Heavy price optimizations mean painful quality tradeoffs.

    And we know that low quality means a lot of rework and, as a result, higher overall cost.

    Now, that I’ve changed jobs, I’m more directly involved in the sales process. And I couldn’t be happier to learn that we don’t take part in this game. We are (relatively) expensive. Don’t expect the lowest bid from us. We understand what it takes to build high quality software and are ready to walk away if someone expects us to drive the price down to the point when we compromise the quality.

    Because, at the end of the day, low price is costly for both: a client and a vendor.

    You just can’t consider price in isolation from quality.