Pawel Brodzinski on Leadership in Technology

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

Tag: lean

  • Value for Money

    There’s one observation that I pretty much always bring to the table when I discuss the rates for our work at Lunar Logic. The following is true whenever we are buying anything, but when it comes to buying services the effect is magnified. A discussion about the price in isolation is a wrong discussion to have.

    What we should be discussing instead is value for money. How much value I get for what I pay. In a product development context, the discussion is interesting because value is not provided simply by adding more features. If it was true, if the following dynamics worked—the more features the better the product—we could distill the discussion down to efficient development.

    For anyone with just a little bit of experience in product development such an approach would sound utterly dumb.

    Customers who will use a product don’t want to have more features or more lines of code but they want their problem to be solved. The ultimate value is in understanding the problem and providing solutions that effectively address it.

    Less is more mantra has been heard for years. But it’s not necessarily about minimalism, but more about understanding the business hypothesis, the context, the customer and the problem and proposing a solution that works. Sometimes it will be “less is more”. Sometimes the outcome will be quite stuffed. Almost always the best solution will be different that the one envisioned at the beginning.

    I sometimes use a very simple, and not completely made up, example. Let’s assume you talk to a team that is twice as expensive as your reference team. They will, however, guide you through the product development process, so that they’ll end up building only one third of the initial scope. It will be enough to validate, or more likely invalidate, your initial business hypothesis. Which team is ultimately cheaper?

    They first team is not cheaper if you take into account the cost of developing an average feature. Feature development is, however, neither the only nor the most important outcome they produce. Looking from that perspective the whole equation looks very differently, doesn’t it?

    This is a way of showing that in every deal we trade different currencies. Most typically, but not necessarily so, one of these currencies is money. We already touched two more: functionality or features and validation of business hypothesis. We could go further: code quality, maintainability, scalability, and so on and so forth.

    Now, it doesn’t mean that all these currencies are equally important. In fact, to stick with the example I already used, rapid validation of business hypothesis can be of little value for a client who just needs to replace an old app with a new one, that is based on the same, proven business model.

    In other words in different situation different currencies will bear different value for a purchasing party.

    The same is true for the other side of the deal. It may cost us differently to provide a client scalable application than to build a high quality code. This would be a function of skills and experience that we have available at the company.

    The analogy goes even further than that. We can pick any currency and look how much each party values that currency. The perception of value will be different. It will be different even if we are talking about the meta currency—money.

    If you are an unfunded startup money is a scarce resource for you. If at the same time we are close to our ideal utilization (which is between 80% and 90%) additional money we’d get may not even be a good compensation for lost options and thus we’d value money much less than you do.

    On the other hand, if your startup just signed round B funding abundance of available money will make you value it much less. And if we just finished two big projects and have nothing queued up and plenty developers are slacking then we value money more than you do.

    This is obviously related to current availability of money and its reserves (put simply: wealth) in a given context. Dan Kahneman described it with a simple experiment. If you have ten thousand dollars and you get a hundred dollars that’s pretty much meh. If you have a hundred dollars and you get a hundred dollars, well, you value that hundred much, much more.

    Those two situations create a very different perception of the offer one party provides to the other. They also define two very different business environments. In one it is highly unlikely that the collaboration would be satisfying for both parties, even if it happens. In the other, odds are that both sides will be happy.

    This observation creates a very interesting dynamics. The most successful deals will be those when each party trades currency that is low-valued for the one that is valued highly.

    In fact, it makes a lot of sense to be patient and look for the deals where there is a good match on this account than to jump on anything that seems remotely attractive.

    Such an attitude requires a lot of organizational self-consciousness on both sides. At Lunar Logic we think of ourselves as of product developers. It’s not about software development or adding features. It’s about finding ways to build products effectively. It requires broader skills set and different attitude. At the same time we expect at least a bit of Lean Thinking on account of our clients. We want to share understanding that “more code” is pretty much never the answer.

    Only then we will be trading the currencies in a way that makes it a good deal for parties.

    And that’s exactly the pattern that I look for whenever I say “value for money.”

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

  • Why Your Change Program Will Fail

    Most change initiatives fail. How many of them? Well, let’s see.

    In 1995, John Kotter published research that revealed only 30 percent of change programs are successful. Fast forward to 2008. A recent McKinsey & Company survey of business executives indicates that the percent of change programs that are a success today is… still 30%

    This is from a McKinsey report. How about different sources?

    According to international management consultants Bain & Co, 70 to 90 per cent of organizational change initiatives fail.

    Now, obviously these statistics receive some criticism. After all, what is a change initiative? What is a success? My point is that what we see is that in different context we suck big time at improving how we work.

    What’s more we are not improving really. Over the course of past 15 years we’ve seen a huge rise of the methods and approaches that are specifically aimed toward driving the change management.

    Agile proposed a neat value container quickly filled with specific methods that should change and improve the way we work. Lean offered a thinking pattern focused on continuous improvements. Both are more and more frequently considered table stakes than game changers. Why nothing is changing then?

    First, let me make a bold observation: neither Agile nor Lean seem to be making a difference. In fact, that’s not only my observation. Daniel Mezick points that:

    If current approaches actually worked well, then by now, thousands of organizations would have reached a state of self-sustaining, “freestanding” agility.

    We have to be doing something wrong. Dave Nicolette offers some ideas what that might be. Anyway with such a wild popularity of Agile and Lean we should expect to do better than that. The problem is that most of the time we don’t even try to understand what made them work in the first place.

    That’s a sad observation, but most of the time when I hear an Agile or Lean experience report it simply covers methods, practices and tools. The problem is that neither of these is pivotal in any change initiative. Basically, adopting practices and tools is simply a cargo cult. That’s not going to work unless there’s something more, the same way as it didn’t work for the Pacific tribes after the World War II.

    In agile context we often mention values as the missing bit. I sort of agree with that. Sort of because the way Agile Manifesto is formulated it creates false dichotomies, yet it points us the right direction.

    There’s a problem with values though. You don’t introduce values simply stating that you have them. You don’t incept them through mission statements and stuff. By the way, do any of you know value statement of your org by heart? Values are derivative of everyone’s behaviors and attitudes, thus they are a result of organizational culture.

    There’s one more layer to that. Values can’t be inconsistent with the culture. Otherwise authenticity is gone and your claims about values have little to do with reality.

    In other words a company can’t adopt Agile Manifesto simply by stating so. Not a surprise that change initiatives around Agile so frequently boil down to methods and tools. Not a surprise they fail at a high rate.

    We see the same story with Lean as well. The bits that get traction are tools and techniques. It is so often when I see teams acting like limiting work in process, doing Gemba walks and having Kaizen boards was everything there was to improve continuously.

    It’s not going to fly, sorry. We are back to organizational culture and everyone’s everyday behaviors. What do people do when they see an issue? Do they feel empowered to do whatever the hell they believe is the right thing to do to fix that issue? Do they even know what is the ultimate value they produce so they get good guidance on what is an issue in the first place?

    These behaviors tell a lot about the culture. Unfortunately most of the time answers for the questions above suggest that there’s no freaking chance to make the tools work the way we intend them to. Typically we see over-constrained, siloed organizations where one neither knows what is the right thing to do nor has courage to go beyond the constraints.

    I keep getting flak for bringing this up over and over again but I will do it once more.

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

    Grace Hopper

    Grace Hopper’s famous words are, in my opinion, the essence of the bit we are missing when introducing Lean or Agile to our organizations. That very bit is responsible for the appalling rate of success of change initiatives.

    You can have all the hot tools and practices in place but when your people are driven by fear of consequences of their actions nothing will change. “Fear” may sound harsh but that’s what it is. It doesn’t mean that changing status quo by a tiny bit scares the crap out of me. It’s enough that I start thinking about potential consequences, what my bosses would think about that and whether they would even be happy. This is fear too.

    When I think about the situation from a perspective of my experience as a manager I’m not surprised. I mean, really, promoting this whole “don’t ask permission” attitude is going to backfire on you on occasions. What’s more it means giving up control. Even worse, it assumes trust. It assumes trust to everyone, not only to few trusted people. Now, this is a huge leap of faith management has to take.

    If you are thinking about continuous improvement or making your change initiatives work start with this leap of faith. If you can’t make it work don’t bother with all the tools, methods, practices and stuff. It’ll be just a waste of time. And the best part is that to make this work leaders have to start with themselves.

    Only then you can dream of influencing culture so that it supports the everyday acts of leadership on all levels. If you got it right you may actually start thinking about all the helpful stuff you can introduce to keep the changes running. In fact, it’s pretty likely that you won’t need so much guidance as lots of them will emerge.

    Oh, and if you wonder whether that change among leaders and managers is easy, well, it involves lots of pain and suffering. It is against of what we’ve been (wrongfully) taught for years. Sorry.

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