Pawel Brodzinski on Leadership in Technology

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

Author: Pawel Brodzinski

  • Decision Making Process

    I’m a strong proponent of participatory leadership model where everyone takes part in leading a team or even an organization. A part of leading is making decisions. After all if all decisions still have to be made, or at least approved, by a manager it isn’t much of participatory leadership.

    (Benevolent) Dictatorship

    The most typical starting point is that someone with power makes all decisions. As a result commonly seen hierarchies are just complicated structures of dictatorships. As a manager within my small kingdom I can do what I want as long as I don’t cross the line drawn by my overlord.

    Of course there are managers who invite the whole team to share their input or even distribute particular decisions to team members. There are leaders who use their power for the good of their people. It may be benevolent dictatorship. It is still dictatorship though.

    This model works fairly well as long as we have good leaders. Indecisiveness isn’t a super-common issue and if it is there’s at least one person who clearly is responsible. Often leaders have fair experience in their roles thus they are well-suited to make the calls they make.

    The model isn’t ideal form a perspective of promoting participatory leadership. If we want more people to be more involved in leading a team or an organization we want them to make decisions. And I mean truly make decisions. Not as in “I propose to do this but I ask you, dear manager, to approve this so that responsibility is, in fact, on you.” I mean situations when team members make their calls and feel accountable for them.

    I’d go even further and propose that in truly participatory leadership model team members acting as leaders would make calls that their managers wouldn’t.

    This isn’t going to happen with a classic decision making process.

    Consensus

    A natural alternative is a consensus-driven decision making process. A situation where we look for a solution that everyone agrees on.

    This one definitely allows escaping dictatorship model caveats. It doesn’t come for free though.

    Looking for consensus doesn’t mean looking for the best option, but rather looking for the least controversial option. These two are very rarely synonymous. Another issue is the tiredness effect. After a long discussion people switch to “I don’t care anymore, let someone make that decision finally and move on.”

    Not to mention that the whole decision making process suddenly gets really time-consuming for many people.

    While in theory consensus solves accountability problem – everyone agreed to a decision – in practice the picture isn’t that rosy. If I didn’t take active part in the discussion or my objections were ignored I don’t feel like it’s my decision. Also if the decision was made by a group I will likely feel that responsibility is distributed and thus diluted.

    One interesting flavor of consensus-driven decision making is when people really care about the decision even though it is controversial. It’s not that they want to avoid participation or even responsibility. It’s just consensus is unlikely, if even possible.

    Such a discussion may turn into an unproductive shit storm, which doesn’t help in reaching any common solution and yet it is emotionally taxing.

    Advisory Process

    There is a very interesting middle ground.

    My pursuit of participatory leadership decision making became a major obstacle. I declined to use my dictatorship power on many occasions encouraging people to make their own calls. The answer for a question starting with “Can I…” would simply be “Well, can you?” That worked up to some point.

    It builds the right attitude, it helps to participate in leading and it makes people feel accountable. The problem starts when such a decision would affect many people. In such a case we tend to retreat back to one of the previous models: we either seek consensus or look for a dictator to make that call for us.

    Not a particularly good choice.

    I found the solution while looking at how no management companies deal with that challenge. Basically, everyone acts as they had dictatorship power (within constraints). However, before anyone makes their call they are obliged to consult with people who have expert knowledge on the subject as well as with those who will be affected by the

    This is called advisory process. We look for an advice from those who can provide us valuable insight either because they know more about the subject or because their stakes are in play. Ultimately, a decision is made by a single person though. Interestingly enough, a decision-maker doesn’t have to take all the insight from advisory process into account. Sometimes it is not even possible.

    Accountability is clearly there. Healthy level of discussion about the decisions is there as well.

    Constraints

    The key part of going with such decision making scheme is a clear definition of constraints. Basically, a dictator, whoever that is in a given context, gives up power for specific types of decisions.

    The moment a team member makes a call that is vetoed the whole mechanism is pretty much rendered irrelevant. It suggests that people can make the decisions only as long as a manager likes them. This isn’t just a form of dictatorship but a malicious one.

    These constraints may be defined in any sort of way, e.g. just a set of specific decisions or decisions that don’t incur cost beyond some limit, etc. Clarity is important as misunderstanding on that account can have exactly the same outcomes as ignoring the rules. After all if I believe I could have made a decision and it turns are not to be true I will be disappointed and disengaged. It doesn’t matter what exactly was the root cause.

    Setting constraints is also a mechanism that allows smooth transition from benevolent dictatorship to a participatory model. One super difficult challenge is to learn that I, as a manager, lost control and some decisions will be made differently than I’d make them. It’s better to test how it works with safe to fail experiments before applying the new model to serious stuff.

    It also addresses a potential threat of someone willing to exploit the system for their own gain.

    Learning the ropes is surprisingly simple. It doesn’t force people to go too far out of their comfort zones and yet it builds a sense of leadership across the board. Finally it provides a nice option for transition from the old decision making scheme.

    And the best thing of all – it is applicable on any level of organization. It can be at the very top of the company, which is what no management organizations do, but it can be done just within a team by its manager.

  • Economic Value of Slack Time

    I ranted on 100% utilization a few years ago already. Let me add another thread to that discussion. We have a ton of everyday stories that show how brain-dead the idea of maximizing utilization is. Sometimes we can figure out how it translates to work organization as well. Interestingly, what Don Reinertsen teaches us is that queuing theory says exactly the same.

    As we go up with utilization lead time or wait time goes up as well. Except the latter grows exponentially. It looks roughly like that.

    Cost of high utilization

    But wait, does it mean that we should strive to have as low utilization as possible? I mean, after all that’s where lead times are the shortest. This doesn’t sound sensible, right?

    And it doesn’t make sense indeed. Cost of waiting is only one part of this equation. The other part is cost of idle capacity. We have people doing nothing thus they don’t produce value yet they cost something. From that perspective we have two cost components: delay cost related to long lead time and cost of idle capacity related to low utilization.

    Cost of high utilization

    Of course the steepness of the curves would differ depending on the context. The thing is that the most interesting part of the chart is the sum of the costs which, naturally, is optimal at neither end of scale.

    Cost of high utilization

    There is some sort of economic optimum for how much a system should be utilized to work most cost efficiently. There’s very good news for us though. The cost curve is the U-curve with flat bottom. That means that we don’t need to find the ideal utilization as a few percent here or there doesn’t make a huge difference.

    We’d naturally think that the optimum is rather toward the more utilized part of the scale. That’s where the interesting part of the discussion starts.

    Economically optimal utilization

    We have pretty damn good idea how much idle time or slack time costs us. This part is easy. Now, the tricky question: how much is shorter lead time worth?

    Imagine yourself as a Product Owner in a funded startup providing an online service. Your competitor adds a new feature that generates quite a lot of buzz on social media. How long are you willing to wait to provide the same feature in your app? Would keeping an idle team all the time just in case you need to build something super-quickly be justified?

    Now imagine that your house is on fire. How long are you willing to wait for a fire brigade? Would keeping an idle fire brigade just in case be justified?

    Clearly, there are scenarios where slight differences in lead time are of huge consequences. We don’t want our emergency calls to be queued for a couple of weeks because a fire brigade or an ambulance service is heavily utilized. In other words steepness of one of the curves varies a lot.

    Let’s look how different scenarios change the picture.

    Economically optimal utilizationEconomically optimal utilization

    This sets the economically optimal utilization at very different levels. There are contexts where a lot of slack is perfectly justified. The ultimate example I can come up with are most of armies. We don’t expect them to be fully engaged in wars all the time. In fact the more slack armies have the better. Somehow we don’t come up with an idea that if an army has no war to run we better find them one.

    Of course it does matter how they use their slack time, but that’s another story.

    We don’t have that drastic examples of value of slack in software industry. However, we also deal with very different steepness of delay cost curve. Even if we don’t expect instant delivery we need to move quicker and quicker as everyone else does the same.

    The bottom line is that our intuition about what is the cost of wait time (delay cost) is often flawed. This means that even if we are able to go beyond the myth of 100% utilization we still tend to overload our teams too much.

    Oh, and if you wondered, at Lunar Logic our goal is to keep team’s utilization between 80% and 90%.

  • On Feedback (Again)

    I’ve heard that question quite a few times after I shared my feedback with somebody: “What am I supposed to do with such feedback?”

    The question may imply that feedback e.g. wasn’t “actionable” or something. Anyway, I have an answer for that. It goes:

    “Whatever the hell you want.”

    Yup. Exactly that. In fact this is precisely what I’d love you to do.

    As the opposite to: getting defensive, explaining yourself, finding excuses, bringing other interpretations, and so on and so forth.

    Feedback is not an attack. You don’t need to defend yourself. It isn’t an interrogation either. You don’t need to explain yourself. And most of all it isn’t a goddamn appraisal. You don’t need to maximize the score.

    It is feedback. I’m sharing some observations and opinions that somehow relate to your work, actions, behaviors, attitude, etc.

    I don’t intend to change you. I want to provide you with more information so that your decisions about your further course of action are informed better. You can disagree with the part or the whole of the message you get. You can interpret it in a vastly different way. You can confront that with other feedback that is contrary to mine. That is all just perfect. You can ignore it altogether and I’m still fine with that.

    Remember? Whatever the hell you want.

    The reason is I know it is subjective. No matter how much I try to make it factual it is always about interpreting facts. And I don’t try to make it purely factual. In fact, the system in knowledge work is built of people and interactions between these people. How objective can “facts” about interpersonal relationships be? Is there even an objective truth there? Or is it rather a combination of interpretations that can be more or less aligned one with the other?

    So no, I’m not trying to convince you that my point is even valid. It’s how I perceive specific situation and how I feel. Oh, it isn’t factual, someone would say. Well, the fact is that I perceive and I feel so and so. Do you want to discuss with such a fact? Didn’t think so.

    I am well aware that my perceptions and my feelings aren’t universal truths. That’s why it is you who decide what to do with the feedback or whether to do anything at all.

    There is the other part of the story. I sometimes receive feedback and I’m like “Thank you. I’m not going to change that.” What I see as a reaction is that someone is either discouraged or even pissed off with my reaction.

    I mean, they did expect me to comply with what they shared with me. I don’t differentiate here feedback on work I do from feedback on my behaviors. It’s just, for whatever reasons, I decide that I don’t want to change that specific thing.

    That doesn’t make me any less grateful for feedback I got by the way.

    It’s just that now we turned the tables. Now it’s: Whatever the hell I want.

    If you want to make me compliant with whatever just make it explicit. At least we’ll have common understanding.

    Feedback’s role, the way I perceive it, is not compliance. It is providing information about one’s behaviors, actions and attitudes and their impact. It is, as its name suggests, about feeding one back with information, not about changing one or making them doing what somebody else want them to do.

    If you give me feedback with a clear intention to change me or even worse to make me do what you want you are likely to end up being disappointed.

    It will happen despite the fact that I treat that feedback as factual and fair. It is factual since fact is that you think and feel whatever you think and feel. It is fair for the very same reason.

    At the same time it is subjective. Objective feedback, as long as it touches interactions between people, is a mirage. Or an oxymoron. Stop pursuing objectivity. To make it clear: it doesn’t make such feedback any less valuable.

    Once we understand that it enables the whole new level of discussing feedback both ways.

    Ultimately it’s: “I share that with you. Do whatever the hell you want with this.”

    And: “Thank you for sharing. I will do whatever the hell I want with this, indeed.”

    Only then it truly is valuable feedback.

  • Minimal Indispensable Feature Set

    Minimal Viable Product (MVP) is such a nice idea. Let’s build something that is as small as possible and at the same time viable, which translates to “provides value and thus make sense to build it.” Two adjectives in a mix where one counterbalances the other and vice versa.

    Since I currently run a web software house I hear the term MVP very frequently. Or to be precise I hear the term MVP being abused very frequently. On some occasion the viable part would be ignored. Much more frequently though the way people understand MVP has virtually nothing to do with the minimal part.

    During the early discussions about products our potential clients want to build I would typically ask about a business case behind a project or an app. It’s not about what it is that someone wants to build. It’s about why it is worth building that thing in the first place.

    Note, I’m not judgmental. We contributed to better or worse ideas but I don’t reserve the right to know what’s worth building and what’s not. In fact, my questions have a very different purpose. What I want to achieve is to learn the value behind the app so that we can have a meaningful discussion about stuff in a backlog.

    Now, this is the part where typically I’d really like to have people read Lean Startup before they are even allowed to talk to any software shop about building their product. And then, read it once again to understand what they are reading in depth.

    The reason is that most of the time I can instantly come up with a batch of work that is one third, one fifth or one tenth of what was labelled an Minimal Viable Product by a potential client and it would still validate a business hypothesis behind a product. It likely means that with a bit of effort and better understanding of the context our clients would be able to cut it down way further than that. It may mean that they’d be even able to validate the basic idea without writing any software at all.

    These so called “MVPs” wouldn’t recognize a real Minimal Viable Product even if it kicked them in the butt.

    A sad part is that most of the time discussion around what really is minimal is futile. While I can provide my insight and encourage to learn more about the topic an argument often boils down to “we really need to build it all because, well, we don’t believe anything short of that would work.”

    The long story short, I believe that MVP is in the top 5 most abused terms in our industry. By now referring to MVP is mostly meaningless unless you ask a series of questions to understand what one means by that. We could have skipped he MVP part, have the same discussion and we’d save a little bit of time.

    That’s why I believe we need another frame for discussing what the initial increment of a product is.

    What I caught myself on a number of times was proposing our clients a different constraint. Let’s step aside from discussing what is minimal and what is viable. Let’s figure out which features will be the part of the product in every single, even most crazy, scenario that we can think of. And I really mean every single one of them.

    What I try to achieve with this discussion is to find the set of features that is a common denominator for all the options of building the product. There’s always something like that. A core process that the app support. A basic idea that the app is built upon. An ultimate issue that the app attempts to solve.

    What I don’t expect is to see the full solution, even the most basic one. It would be an MVP on its own and we’d be back to the square one. What I expect is just a bunch of bits and pieces that are required to eventually build the app.

    It is neither minimal nor viable.

    It is indispensable though.

    There are a couple of reasons to do that. The first one is that it reframes how both parties, the client and us, think of a product. We don’t try to settle on what is viable and what is minimal. We simply go with something that we know will be useful.

    The other one is that it addresses the huge challenge of building a relationship. In fact this part goes really deep. It typically starts with a question how much building something would take. Some sort of an estimate. Well, it’s another thread. I’m not fundamentally against the estimates and see value in understanding generally how much something would take. At the same time I acknowledge that humans are simply not well equipped to estimate as we can’t learn to assess stuff in abstract measures. At the end of the day though, the smaller the batch size of work the smaller the potential risk and the smaller the estimation mistake.

    In other words the smaller the initial batch of work the easier it is to start working.

    It is true from another perspective as well. The most important modifiers of the cost of building a product in a client-vendor scenario isn’t anything related to the product itself. It is the quality of collaboration. It’s about both parties feeling like they’re the part of the same team. It’s about short feedback loops. It’s about working together toward the goal.

    Unless it is about lack of transparency, distrust, and exploiting the other party.

    The tricky part here is that you don’t know where at this spectrum you are until you start working. Building the smallest possible batch of work together pretty much gives you all the knowledge you needed. Seriously, you don’t need more than just few weeks to get a good feeling where collaboration part is going.

    That’s why this the idea of Minimal Indispensable Feature Set is so useful whenever more than a single party is involved in building a product.

    Minimal Indispensable Feature Set is perfectly aligned with building an MVP. In fact it is a subset of an MVP. At the same time it addresses the part of the setup that goes way beyond simply defining of what product is.

    We live in a world where more and more frequently the building part is outsourced to another party. Getting the collaboration right at least as critical as getting the product idea right.

  • Happiness Index as Team Sustainability Metric

    One of the discussions that happened during Don Reinertsen’s product development workshop was the one about absorbing turbulence. Absorbing turbulence is a metaphor for how well a team deals with unplanned variability of the process. These would be situations like arrival of a bigger batch of features to build, or especially complex work items, etc.

    Normally, every team is suitable to absorb some turbulence. Beyond that point this capability will not be sufficient and the situation would quickly escalate. A good example may be that the team would gracefully deal with some additional features but above certain threshold we’ll quickly the situation escalating to a high queue state. This would result in long lead times, long feedback loops and generally decreased responsiveness of a team.

    These all result in lower efficiency too.

    If such a situation persists over longer period of time it can take a heavy toll on people as we are running at risk of burning people out.

    I really like the analogy that Don uses in his work: when a human body is losing blood, interestingly enough, blood pressure doesn’t go down. What our body is designed for is to pump enough blood to the brain so it can operate normally.

    To compensate for losing blood the heart rate keeps going up. It goes up to the point where this mechanism is no longer sufficient and the organism crashes over a very short period of time.

    A similar thing happens when we overload our teams. For some time they deal with the overload just fine introducing their own coping mechanism. They’d likely work overtime, introduce additional multitasking, etc. A problem is that, similarly to the situation when a human body loses blood, there’s a price to be paid for that.

    Eventually people end up burned out and leave an organization. From that perspective a good question would be: what kind of early signals we get so that we can address the problem early.

    One answer would be careful monitoring of work. How much work in progress we have. How our queues in backlog change. This kind of stuff. While obviously that would provide us some signal, that wouldn’t really be a proxy measure if we want to consider people first, not the process first.

    What strikes me is that we at Lunar Logic already use a nice signaling mechanism that would give us an early warning. The mechanism is a happiness chart. Despite the fact that a happiness chart is a super simple, super low-tech tool it works on a few levels.

    On one level we have individuals. When I see a deviation from the norm in the chart of one person it likely means that something’s going wrong. It may be related to the work, it may be related to a personal life. Whatever the case is it does affect the work.

    If the case is individual it will unlikely be related to the whole project.

    Another context is the one of the whole company. If things were going generally wrong I’d expect to see a strong signal across the whole board. “Generally wrong” may mean either mediocre business results, or a cultural problem, or a strong source of frustration, or a bunch of different things.

    In such situation the signal would be broader than just a single project or product team.

    There’s another scenario, which would be a bunch of people recording worse than typical mood and the correlation would be around a common project. Process-related parameters of that project may look OK: a backlog queue wouldn’t grow, throughput would go up, etc. Is there anything wrong then?

    In this case happiness chart would serve as blood pressure – it would be a countermeasure pointing that something is going not exactly OK and if we keep doing that we may end up crashing.

    The rule for our happiness chart is that the color translates to the mood. Green means happy, blue means so-so, and red means not happy. Once the chart for a project team gets more bluish or even reddish that’s a very strong indicator that we are not absorbing turbulence in that team gracefully.

    The interesting part is that a happiness chart would provide such an information no matter whether a root cause is overloading a team with tasks, interpersonal conflicts that affect collaboration or anything else. The alarm would go off in either case. That’s actually perfect as we want to react to dangerous turbulence early in any situation.

    From that perspective the outcome of happiness chart isn’t a leading indicator per se – when the change is triggered it means that there’s already something happening. It isn’t a lagging one either. We can correlate it with other parameters or even check with people to figure out what is happening. We would know that we’re not coping with turbulence well enough much earlier than when we are on the verge of crashing.

    The reason why I think this strategy is so valuable is because it allows to merge the data from two different universes. On one hand we have all the process metrics that tell us how we are doing from efficiency perspective. On the other we get a social metric that tell a lot whether the current state is sustainable.

    It is exactly like a combination of a blood pressure and a heart rate. The former translate to efficient work of our steering center – the brain. The latter tells a little bit how sustainable current conditions are.

  • Two Rules of Autonomy

    One thing that we are doing at Lunar Logic is we evolve toward no management model of leadership. This means a lot of small changes that all happen with the same attitude at heart: to distribute more and more decision-making power across the whole company. This by the way also means systematically stripping down the management from that power.

    The latter is easy in our case as the management is limited to me and I kind of launched the whole process. I would have to be either a hypocrite or a schizophrenic to resist the changes. Luckily enough I believe I’m neither. (Unless that other me has something else to say, that is.)

    I don’t say it’s easy. One challenge in each step toward participatory leadership is that we, humans, don’t like to give up on power. I’m no different. I like that warm feeling that I can make a call and it shall be as I say. It’s not only that. Sometimes I simply know which option is good and the temptation to intervene and tell people what’s the best choice is strong. It would mean, however, taking a step back on a path toward democratizing leadership. So I keep my mouth shut.

    On other occasions I just feel like we are going too far from my comfort zone and I slow down the process.

    Giving up on power is a prerequisite to go further. While I don’t say it will go as easy in every case it isn’t enough to get that part working. In fact, despite being vocal how much I don’t want to make all sorts of decisions and how much I appreciate autonomy I still get loads of the questions that start with “Can I…”

    If I’m lucky enough to suppress my System 1 reaction that would be either of: yes, yes but, no, no but answers I’d reply with “Can you?” The ball is back in your court and as long as you take responsibility for the call you make I’m OK with that.

    The interesting thing is why these questions are popping up over and over again though. Despite the fact that on a conscious level we promote autonomy our natural behaviors means retreating back to the old pattern of asking for permission.

    We simply don’t claim autonomy even if it slaps us in the face.

    Besides years of programming our brains by education and work system that make it hard to act differently there’s another reason for that. Most of us want to be good citizens and we don’t want to use our autonomy to do stuff other wouldn’t like or even would be against. So we back up to the ultimate decision-making authority who is supposed to know what everyone in an organization likes or approves or more likely who doesn’t give a damn what anyone thinks – a manager.

    The interesting thing is that the fear sometimes is well-grounded. We have different sensitivity toward different things. Behaviors that we consider positive or neutral may have negative connotation for others. If I’m a manager and I use my ultimate decision-making power and I don’t give a damn then, well, I don’t give a damn. But what if I’m just a team member who cares?

    The idea we came up with is a set of two very simple rules.

    1. The Nike Way
    If you want to do something just do it.

    2. Speak Up
    If you don’t like what someone else is doing speak up.

    Yes, that’s it. There’s one underlying principle, which is mutual respect. We don’t need to love each other. We need to respect our autonomy and our right to have different views on stuff.

    The nice thing about this setup is that it is a self-balancing mechanism. It takes only one person try something new. It doesn’t require permission or even extensive up-front discussion. Pretty much the opposite, as a default we assume that every initiative would be awesome and everyone would love it or at least have nothing against.

    The Nike Way is verbalizing the attitude described by famous Grace Hopper’s words: It’s easier to ask forgiveness than it is to get permission.

    What we do know is that despite best intentions it won’t be true all the time. Occasionally, OK more often than occasionally, someone would do something that somebody else is not OK with. Then we have Speak Up rule that triggers a conscious and meaningful discussion (sometimes dubbed a shit storm) that provides additional insight for both sides and most likely some sort of consensus.

    Speak Up rule was designed with a positive scenario in mind, i.e. someone unintentionally stepped on someone else’s toe. It works however in malicious cases as well. When someone intentionally crosses the line or pulls an organization in an unwanted direction someone else will speak up too.

    The best part is that the same way it takes only one person to just do it, you need only one person to speak up.

    One might point that there’s a risk that it would end up in indecisiveness. So far I don’t see that happening. First, speaking up doesn’t mean the ultimate veto power. It simply triggers a discussion. Second, the respect bit that is a hard prerequisite keeps the discussion civilized.

    There’s a little more sophistication to balance that. Naturally extroverts would have an upper hand in unstructured discussion. That’s where empathy plays its role as helps to facilitate these weaker signals. On a basic level there are just these two simple rules: The Nike Way and Speak Up rule.

  • Portfolio Kanban and Doing the Right Thing

    There’s an ongoing discussion that I occasionally refresh with Markus Andrezak on usefulness of applying Kanban to manage portfolio and generally to the process of figuring out which products should be built.

    What is Portfolio

    One obvious thing that we can start with is focusing on a specific context. After all portfolio is a pretty loaded word and it is used in all sorts of situations. While my goal isn’t to boil down portfolio discussion to only few available options I see at least three distinctively different cases.

    There are organizations that ore focused on project work. A typical gig they run would be a distinct initiative that is different form all the other initiatives they run. What’s even more important the revenue from that work would be connected to delivering work. This would be a project portfolio case. A classic example would be an offshore web software shop.

    Then we have organizations that, similarly to the previous example, focus on building multiple concurrent and independent initiatives yet they would operate them as products by themselves. In other words they earn money by directly selling their software, or services provided by that software, to the end users. There’s no simple definition when the work is done. This would be a product portfolio case. A classic example would be a game development studio.

    Then there is an alternative version of product portfolio where the whole company is focused on building a single product. In such a case the overarching initiative that everyone contributes to is obvious as there is only a single one. The discussion would happen between either specific goals to achieve or specific big scale functionalities to build. This would frequently be labeled a product portfolio too although for the sake of this discussion I’d go with a feature portfolio label, even if it isn’t precise especially for big organizations. A classic example would be a startup building what they believe is the next world-changing product.

    Of course we can think of a mix of any of these scenarios and rarely only one of them will be pursued by an organization exclusively. What’s more we could go further with a differentiation within these scenarios. We’d see a completely different dynamics of project portfolio in a company that works under time and material terms than from one that build fixed price projects. A very different feature portfolio will be in a startup at an early phase which is still figuring out product-market fit that in an established company focusing on leveraging their user base or staying ahead of competition.

    Where is the Problem

    The discussion about applicability of Portfolio Kanban boils down to defining what is the most painful problem on a portfolio level in a given context. From that perspective there is a clear distinction between project portfolios and the other two scenarios. The difference is in the way revenues are generated.

    In project work the more projects we finish the more revenues we can expect. With product or feature portfolio building software is only an intermediate step in order to generate revenues. In other words we know much more up front about return on investment in project portfolio scenario than we do in other two.

    That doesn’t completely change the bottom line. In each case the choice on endeavors an organization works on is crucial for its long-term health. In each case overcommitment and too much work in progress on portfolio level can decimate the value of any ongoing work, no matter how carefully chosen. There are commonly mentioned reasons for that: long lead times mean long feedback loops and a lot of work in progress results in inefficient work.

    There’s one more dimension that from my experience is at least equally, if not more, important. The constraints provided by work in progress limits change the dynamics of the discussion about starting new stuff, be it projects, products or major features.

    Typically the discussion about economic feasibility of starting a new product or a project happens in isolation. If the ultimate problem that we are trying to solve is choosing the right initiatives to work on it should never happen in isolation. After all most of ideas we come up with make sense… in some context. An interesting question would be whether we are in such a context.

    We may have a bunch of projects that we expect to be profitable. But which of them provide us most monetary and non-monetary value? How starting another one affects the ones that are already ongoing? Given a business hypothesis which we want to validate, which out of all possible experiments would generate most valuable information? Would starting another concurrent experiment obfuscate the outcomes of ongoing ones?

    Of course we can say that each project will provide some value and each experiment will provide some learning opportunities. We don’t have infinite capabilities thus we need to choose.

    Role of Portfolio Kanban

    The way I look at Portfolio Kanban is that is addresses a very common issue of overburden at portfolio level and as a result it drives the discussion about what are the right endeavors to pursue. The latter starts happening when, thanks to WIP limits, we start saying no to new initiatives. What WIP limits create is they underscore available capabilities as a scarce resource. The next step typically is more careful consideration how these capabilities are put in the best use, which ultimately means a discussion about what is the right thing to build.

    Obviously this dynamics is not true in all environments. Startups, especially at the early stages, will likely focus on figuring out what is the right thing to build without any external incentive. Organizations built around a single product, at least to a certain size, will naturally maintain discipline in strategy planning that will provide an answer what are the crucial product goals for them.

    Beyond that it all gets fuzzy. If an organization gets big enough it has capacity to build multiple initiatives concurrently. Each product that grew far enough has a number of potential development paths it can follow and each of them can be promising on its own. If we talk about multiple product organization a temptation to follow a bunch of new goals at the same time is even stronger. And with projects it’s like an everyday issue.

    Of course I don’t say that it’s not possible to start the other way around: nailing down the ultimate purpose, which may mean answering the Spice Girls question, and following up with defining what are the right features, products or projects that serve the purpose. This would likely mean that the number of concurrent initiatives will be limited as majority of activities would be optimized toward pursuing the purpose.

    The problem is few organizations are ready to make this step just like that. And even when they are, there are still a lot of risks along the way. First, depending on how the ultimate goal is defined it doesn’t have to limit the options for what constitutes an attractive endeavor and we’re back to the square one. Second, even if the purpose provides enough focus there’s typically still plenty of options how to pursue the goal and thus overburdening portfolio is still a viable option. Third, and most importantly, in bigger organizations defining a single purpose may be impossible because office politics kicks in or there isn’t enough strategic leadership present.

    In either of these cases as well as in the most common situation where there isn’t enough awareness to even start the discussion about the purpose Portfolio Kanban may serve as a facilitation tool. On the top of efficiency gains, similar to those seen in other applications of Kanban, it would catalyze the discussion about what is the right thing.

    This is, in fact, the most important outcome of introducing Portfolio Kanban that I’ve seen.

    What Portfolio Kanban Is Not

    An argument I’ve heard a couple of times is that Portfolio Kanban doesn’t help to define what is the right thing to build or what is the ultimate purpose. I completely agree with this one. That answer simply isn’t there. Portfolio Kanban, pretty much alike any Kanban application, is a meta method. One shouldn’t expect to get context-specific answers.

    If an organization is ready to look for these answers that’s great. Depending on specific context Lean Startup, Lean UX or other modern product management approaches may be relevant. That’s where awesome guys like Will Evans or Markus Andrezak kicks in with their expertise. That’s where Stephen Bungay’s work will prove invaluable, which Jimdo guys will happily confirm. That’s where Don Reinertsen would provide outstanding guidance for decision making.

    In such cases, usefulness of Portfolio Kanban will indeed be limited. It will be mostly process improvement and efficiency stuff.

    A common case wouldn’t be even remotely as rosy though. That’s why value provided by Portfolio Kanban typically go beyond the process stuff. It would still stop at introducing pressure to start important and difficult discussions. It wouldn’t provide guidance for that conversation. A good thing is that there would be more pressure the more screwed up the situation is. We can expect this catalyzing mechanism to exist continuously till we either solve the problem or give up on limiting work in progress on portfolio level.

    If someone claims that Portfolio Kanban is supposed to provide more than that in terms of defining what is the right thing, well, we may be talking about different things.

  • Lean Kanban Central Europe Leadership Track

    There’s a question I get asked pretty frequently: which conference I would recommend to attend. Of course the answer is always contextual but surprisingly often after some further inquiry I recommend Lean Kanban Central Europe.

    On one hand it’s the content. Even today I remember all the keynotes from the first LKCE three years ago. That’s how much that stuck. Since then the program was only getting better. Then, there is exposure to new ideas. Lean Kanban series of conferences are surprisingly consistent when it comes to bringing to the mix new concepts, models and methods. One can bet that that thing which sounds so fresh on one of big Agile events was covered in extent a few years ago at Lean Kanban tour.

    Then of course there is networking. With three hundred people networking is of very different quality than at the events that attract a thousand people or more. Everyone is more accessible and it’s not an ultimate challenge to track down someone who you really want to chat with.

    The post wasn’t meant as a just an infomercial of LKCE. The conference, as every good event, evolves. One change that we introduced this year are consistent tracks and track chairs. This means that there’s always someone who made final decisions for the part of the program. This also means that there’s even more space for radical ideas as we as the program board aren’t driven by the consensus that much.

    The track I’m honored to lead is the leadership track. One thing I didn’t want to do with it was just to throw a bunch of great speakers and just let them do their magic. What we’ll have instead is a theme and different ideas on leadership evolving around the same theme. Of course we still have a bunch of awesome speakers in the first place.

    This approach means that everyone who will choose to stay throughout the whole track will get a consistent experience, while being exposed to different ideas. In fact, when working on the track I was thinking of it as of a mini-conference on its own.

    The underlying theme for the track is broadening understanding of what leadership is and what approaches and tools we may use to let it emerge in our organizations. Esther Derby will kick off the track explaining that leadership at all levels isn’t just a nice theoretical concept or wishful thinking. At the same time the challenge is that there are no recipes that allow us to easily build such an environment. If there was such a thing as a track keynote it would be this one and I can hardly think of a better candidate than Esther to deliver it.

    With no recipes we aren’t left alone in the wild though. We do have models and methods that, if understood correctly and used mindfully, can help us to shape the organization to steer emergence of leadership. When I think about people who easily mix different models and methods applying them contextually to provide most value Liz Keogh is on the top of my list. That’s why I asked her to cover that part. At least a bit of exposure to systems thinking and complex adaptive systems seems inevitable.

    By that point the balance of the track will have swung toward more systemic approach to leadership. In that context however we can’t forget that at the end of the day it all boils down to people dynamics. That’s where Marc Burgauer will kick in with his message about how trust, connections, blame and fear of shame play pivotal role in building leadership across organization. Marc does an awesome job bringing people perspective into discussion.

    The only missing bit in that mix is a practical story that shows how one may use all these building blocks to create a culture where leadership emerges and thrives. I tasked myself with that. On one hand at that point my job will be super easy as Esther, Liz and Marc will have covered the important parts and I’ll just build the connection between my story and earlier sessions. On the other, matching such a lineup of speakers is a challenge by itself. I guess my inner speaker now hates my inner track chair.

    Of course leadership track will be competing for attendees attention with other awesome tracks. It was never our goal for LKCE to make choice between sessions even remotely close to easy. I do hope though that there will be some people who will choose to stay with us through all the leadership sessions. Especially that it is the shortest track of the event. As you can see though there was a lot thought invested to provide additional value for those who would be at all sessions.

    The track is more than a sum of its sessions, it’s a product of interactions between its parts.

    Have I just brought systems thinking again to the discussion? Oh well…

    I hope this is one more argument to join LKCE this year. I’d love to see you there and I’d love to get feedback about the final outcome.

  • Practices, Principles, Values

    I was never a fan of recipes. Even less so when I heard that I have to apply them by the book. What I found over years was that books rarely, if ever, describe a context that is close enough to mine. This means that specific solutions wouldn’t be applicable in the same way as described in the original source.

    This is why I typically look for more abstracted knowledge and treat more context-dependent advice as rather inspiration that a real advice.

    From what I see that’s not a common attitude. I am surprised how frequently at conferences I would hear an argument that the sessions weren’t practical enough only because there was no recipe included. This is only a symptom though.

    A root cause for that is more general way of thinking and approaching problems. Something that we see over and over again when we’re looking at all sorts of transformations and change programs.

    People copy the most visible, obvious, and frequently least important practices.

    Jeffrey Pfeffer & Robert Sutton

    Our bias toward practices is there not without a reason. After all, we’ve heard success stories. What Toyota were doing to take over the lead in automotive industry. The early successes of companies adopting Agile methods. There were plenty of recipes in the stories. After all that’s what we first see when we are looking at the organizations.

    Iceberg

    The tricky part is that practices, techniques, tools and methods are just a tip of the iceberg. On one hand this is exactly what we see when we look at the sea. On the other there’s this ten times bigger part that is below the waterline. The underwater part is there and it is exactly what keep the tip above the water.

    In other words if we took just the visible tip of the iceberg and put it back to water the result wouldn’t be nearly as impressive.

    Practices, Principles, Values

    This metaphor is very relevant to how organizational changes happen. The thing we keep hearing about in experience reports and success stories is just a small part of the whole context. Unless we understand what’s hidden below the waterline copying the visible part doesn’t make any sense.

    Principles

    A thing beyond any practice is a principle. If we are talking about visualization we are implicitly talking about providing transparency and improving understanding of work too. Providing transparency is not a practice. It is a principle that can be embodied by a whole lot of practices.

    The interesting part is that there are principles behind practices but there are also principles that are embraced by an organization. If these two sets aren’t aligned applying a specific practice won’t work.

    Let me illustrate that with a story. There was a team of software architects in a company where Kanban was being rolled out across multiple teams. In that specific team there was a huge resistance even at the earliest stages, which is simply visualizing work.

    What was happening under the hood was that transparency provided by visualization was a threat for people working on the team. They were simply accomplishing very little. Most of the time they would spend time on meetings, discussions, etc. Transparency was a threat for their sense of safety, thus the resistance.

    Without understanding a deeper context though one would wonder what the heck was happening and why a method wouldn’t yield similar results as in another environment.

    Values

    The part that goes even deeper are values. When talking about values there’s one thing that typically comes to mind, which is all sorts of visions and mission statements, etc. This is where we will find values a company cares about. To be more precise: what an organization claims to care about.

    The problem with these is that very commonly there is a huge authenticity gap between the pretense and everyday behaviors of leaders and people in an organization.

    One value that would be mentioned pretty much universally is quality. Every single organization cares about high quality, right? Well, so they say, at least.

    A good question is what values are expressed by everyday behaviors. If a developer hears that there’s no time to write unit tests and they’re supposed to build ore features or no one really cares whether a build is green or red, what does that tell you about real values of a company?

    In fact, the pretense almost doesn’t matter at all. It plays its role only to build up frustration of people who see inauthenticity of the message. The values that matter would be those illustrated by behaviors. In many cases we would realize that it would mean utilization optimization, disrespecting people, lack of transparency, etc.

    Again, this is important because we can find values behind practices. If we take Kanban as an example we can use Mike Burrows’ take on Kanban values. Now, an interesting question would be how these values are aligned with values embraced by an organization.

    If they are not the impact of introducing the method would either be very limited, or non-existent or even negative. This is true for any method or practice out there.

    Mindfulness

    The bottom line of that is we need to be mindful in applying practices, tools and methods. It goes really far as not only does it mean initial deep understanding of the tools we use but also understanding of our own organization.

    This is against “fake it till you make it” attitude that I frequently see. In fact, in a specific context “making it” may not even be possible and without understanding the lower part of the iceberg we won’t be able to figure out what’s going wrong and why our efforts are futile.

    Paying attention to principles and values also enables learning. Without that we will simply copy the same tools we already know, no matter how applicable they are in a specific context. This is by the way what many agile coaches do.

    Mindful use of practice leads to learning; mindless use of practice leads to cargo cult.

  • There Is No Shortage of Leaders

    I like the way Jerry Weinberg defines leadership.

    Leadership is a process of creating an environment where people become empowered.

    Empowerment

    I don’t really like the word empowerment as it is frequently used in the context of making people empowered. The way I understand empowerment such thing can’t even be done. You can’t empower me to do something.

    What you can do is give me enough positional power and possibly encourage me to do something. I can still cease to do it because of a number of reasons. I may not see value or sense in doing that. It may move me too far outside of my comfort zone. I may be afraid of peer reaction. Finally, potential consequences of failure may drive my decision.

    The way I think of empowerment is that it is intrinsic. I can feel empowered to do something. What others can do is they can create conditions that would enable that. It means anything from creating experiments that are safe to fail to shaping the environment so it supports and not discourages me to act.

    Only such way of interpreting empowerment makes Jerry Weinberg’s definition of leadership reasonable.

    Process

    What Jerry Weinberg talks about is a process. That’s unusual as typically when we think about leadership we think about individual context. How to become a leader or how to become a better leader.

    What “a process of creating an environment” communicates is that a discussion about leadership should happen in a different context. Instead of wondering how to help an individual to become a better leader we should discuss how to build an environment, or a system if you will, that supports emergence of new leaders and further development of existing ones.

    This inevitably brings to a context of system thinking.

    If we consider an organization a system there are many of its properties that influence whether, how and when people can lead.

    One of the most obvious ones would be a formal hierarchy. How rigid it is and how many levels it is built of. A hierarchy is important as it often linearly translates to power distribution. Most often it would be managers who make most decisions and influence environment around in extent.

    Then we have all the rules that people are supposed to follow. What is allowed and what is not. What stuff I have to comply to before I can do things I want. And most importantly whether everything is allowed unless rules state otherwise or the opposite: nothing is allowed unless rules state otherwise.

    Thinking of an organization as of a system from a perspective of enabling leadership is important because the system defines constraints. Normally, one can’t go beyond these constraints without risking dire consequences.

    In other words structures and rules define how much potentially is possible in terms of catalyzing leadership. It doesn’t automatically mean that fairly flat hierarchy and few rules is enough to see emergence of leadership throughout a company.

    Environment

    The bit that enables fulfilling potential created by rules and structures is organizational culture. We define organizational culture as a sum of behaviors of people being part of an organization. It’s not only abut behaviors though. It’s also about what drives them: values, principles, norms, beliefs, etc.

    Organizational culture constitutes what is an environment we work in. This is what steers how far we would go within existing structures and rules. In fact, it may even let us break the rules. It may be perfectly acceptable to for an organization to go against the existing constraints as long as it means doing the right things and is aligned with organization’s values and principles.

    What’s more, for companies that aim for good leadership distribution across the board will likely encourage such behaviors as it is a crucial condition for evolving the system and the culture.

    The hard part about organization culture is that we can’t mandate its change the same way as we can mandate for example rules change. We can’t do it as the culture is a derivative of behaviors of many people.

    What’s more we can’t mandate the change of behaviors in a sustainable manner either. We can introduce a policeman who would make sure people behave the way we want them to, but the moment the policeman is gone people would retreat back to the old status quo.

    So what can we do with the culture? We can work on constraints. This is in fact aligned with a system thinking view of an organization.

    A Process of Creating an Environment

    The bottom line of this is that most of the time when I hear complaints about not enough good leaders it is because environment is designed in a way that doesn’t let them emerge, let alone thrive.

    A litmus test that I use to quickly asses what climate there is for potential leaders would be bringing up famous Grace Hopper’s words:

    It’s easier to ask forgiveness than it is to get permission.

    The question to ask is how much of that attitude is present in an organization. An interesting observation is that the more people exercise that attitude the less they actually need to ask forgiveness.

    The core of it though is empowerment. On one hand it translates to taking the rules into account and then doing the right thing even it means going beyond the rules occasionally. On the other it means that an organization accepts and supports such behaviors. It requires involvement of both parties.

    It requires continuous effort to adjust rules and structures and evolve an organizational culture to reach such stage. It requires a lot of discipline across management on all levels not to break such attitude once it is present as it is fragile.

    That’s why it’s a process and not a thing. Good news is that the better you do that the more leaders would get involved and the more self-sustaining the process will become.

    At the end of the day, there’s no shortage of leaders, only a shortage of companies that let leadership emerge.