Pawel Brodzinski on Leadership in Technology

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

Tag: culture

  • Respect (and How It Makes or Breaks Culture)

    Respect (and How It Makes or Breaks Culture)

    It seems my Milk Kanban article has made a stir. I kinda expected some backlash along the “it’s not really Kanban” lines. However, when the post hit Hacker News, I got a swath of remarks attacking it from a different angle.

    The problem is, as the comments go, that someone’s job is outsourced to random colleagues. In this case, it would be Kasia (our office manager) outsourcing her job (ensuring that the office is supplied with milk) to macchiato drinkers who can’t be bothered because they have more important stuff to do.

    Oh boy, where do I start?

    Get Out of Your Cave

    It took me quite a while to grasp that some commenters perceived managing the milk supply as a priority job for an office manager.

    Yes, I know our context so much better; we’re a small company, and everyone wears multiple hats. But even in big organizations, I’d be shocked if such a matter was anyone’s top priority.

    For Kasia, it’s like the 100th thing on the list of stuff she takes care of.

    But again, even if we consider a generic example, it would be so easy to figure out how many things, big and small, an office manager takes care of. Then, there’s probably twice as much of stuff that’s not visible on the surface.

    I mean, any developer, whose primary task is working with code that’s inherently invisible, should grok that concept.

    Effectiveness versus Efficiency

    However, then things only get more interesting. Even when people considered doing something to help, they’d instantly play the efficiency card.

    “I can’t be bothered to let someone know that we’re running out of milk because I’m doing this important work, and me being a 10x developer requires absolute focus.”

    Weird that they have time for a coffee break then, but what would I know?

    But yes, having someone do 30 seconds of work, which may save someone else 10 minutes, is a sensible tradeoff. Even if the latter is paid less. Even if that half a minute wouldn’t be efficient.

    That’s the most basic effectiveness versus efficiency consideration. I can be efficient as hell, but unless we, as the whole team, can reliably deliver value, it doesn’t matter.

    It’s the equivalent of a developer whose coding pace would be fabulous, except there would be no one to code review or test their features. They may feel like they were being productive. The team, however, would be so.

    In fact, the amount of work in progress they’d introduce would make the team less efficient. It would introduce more multitasking, more rework, and more context loss.

    One has to wonder whether people showing such a lack of understanding of how the whole organization delivers value should really be valued as highly.

    A narrow focus on efficiency, especially in an isolated context, is typically detrimental to the effectiveness of the whole process.

    Respect

    However, if anything in that discussion makes me sad, it’s the lack of respect.

    “If checking the milk reserves once a day is too much of a pain for a person hired as an office manager, the person should self-reflect on his/her choice to take the job.”

    And that comes from developers, a group that is notoriously crappy at filling time tracking data, even when companies rely on that data to bill clients.

    However, my beef here is with a lack of respect for another job. Yes, this job is not paid as well. But I’m sure as hell that as much as an average office manager would fail miserably if they were to do software engineering, an average developer wouldn’t fare better in an office manager’s shoes.

    In our case, just as an example, we’re yet to have a single foreigner who wouldn’t be deeply grateful to Kasia for help with all the formal stuff related to employment papers, work permits, etc.

    In fact, it would be easier for us to lose a couple of our best engineers than to lose Kasia.

    The point is, though, that it doesn’t even matter whether we really understand someone else’s job. It matters whether we respect it as a part of the bigger whole.

    If not, it’s easy to boil it down to “I want my goddamn coffee to have milk, and someone better make sure I have it.” It’s easy to subordinate everyone else’s work only to whatever I might need of them. Then, of course, people won’t be willing to spend half a minute helping anyone with anything. Even if that someone makes sure that the milk is in the cupboard.

    I understand that in many companies, this is the norm. People are not respected, and, in turn, they don’t respect others. They won’t be willing to help with anything that’s not explicitly their assignment.

    It’s not a Milk Kanban problem. It’s a (lack of) respect problem.

    Now, establishing respect as a part of organizational culture is so much harder than making the milk supply work effectively.

    Wrap Up

    I understand the specific context of these comments. The software industry made us, in a significant part, spoiled kids. It’s still easy to sustain a lucrative career by focusing only on one’s technical skills, individual tasks, and not much more.

    I’m not necessarily surprised by how the comments disregarded the work of others, the broader context, and common goals. The sentiments, though, are not unique to software developers. I see a lot of similar attitudes in management.

    And the ways of dealing with the issue will be similar. Understand others’ roles and jobs. Understand the difference between group effectiveness and individual efficiency. Most importantly, respect others and their contributions.

    Milk Kanban or not, it’s easy to get enough milk in a cupboard. Building a culture of respect, on the other hand, is damn hard.

    And it starts with the very people who have disproportional leverage on the organization. Yes, the same folks who tend to earn more and fill the most prestigious roles.

  • Don’t Mess with Culture

    When I’m writing these words I’m on my way home from Lean Agile Scotland. While summarizing the event Chris McDermott mentioned a few themes, two of them being organizational culture and experimentation.

    Experimentation is definitely my thing. I am into organizational culture too. I should be happy when Chris righteously pointed both as the themes of the event. At the same at that very moment time alarm lights went off in my head.

    We refer a lot to safe to fail experiments. We talk about antifragile or resilient environments. And then we quickly turn into organizational culture.

    The term culture hacking pops up frequently.

    And I’m scared.

    The reason is that in most cases there is no safe to fail experiment when we talk about an organizational culture. The culture is an outcome of everyone’s behaviors. It is ultimately about people. In other words an experiment on the culture, or a culture hack if you will, means changing people behaviors.

    If you mess it up, more often than not, there’s no coming back. We may introduce a new factor that would influence how people behave. However, removing that factor does not bring the old behaviors back. Not only that though. Often there’s no simple way to introduce another factor that would bring back the old status quo.

    There’s a study which showed that introducing a fine for popping up late at a daycare to pick up a child resulted in in more parents being late, as they felt excused for their behavior. This was quite an unexpected outcome of the experiment. However, even more interesting part is that removing the fine did not affect parents’ behaviors at all – they kept popping up late more frequently than before the experiment.

    It’s natural. Our behaviors are outcome of the constraints of the environment and our experience, knowledge and wisdom.

    We will affect behaviors by changing the constraints. The change is not mechanistic though. We can’t exactly predict what’s going to happen. At the same time the change affects our experience, knowledge and wisdom and thus irreversibly changes the bottom line.

    I can give you a simple example. When we decided to go transparent with salaries at Lunar Logic it was a huge cultural experiment. What I knew from the very beginning though was there was no coming back. Ultimately, we can make salaries “non-transparent” again. Would that change what people learned about everyone’s salary? No. Would that change that they do look at each other through the perspective of that knowledge?

    It might have affect the way they look at the company in a negative way, as suddenly some of the authority that they’d had was taken away. In other words, even from that perspective they’d have been better if such an experiment hadn’t been run at all than if it was tried and rolled back.

    I’m all for experimentation. I definitely do prefer safe to fail experiments. I am however aware that there are whole areas where such experiments are impossible most of the time, if not all of the time.

    The culture is one such area. It doesn’t mean that we shouldn’t be experimenting with the culture. It’s just that we should be aware of the stakes. If you’re just flailing around with your culture hacks there will be casualties. Having experimentation mindset is a lousy excuse.

    I guess the part of my pet peeve with understanding the tools and the methods is exactly this. When we introduce a new constraint, and a method or a tool is a constraint, we invariably change the environment and thus influence the culture. Sometimes irreversibly.

    It get even trickier when the direct goal of the experiment is to change the culture. Without understanding what we’re doing it’s highly likely that such a culture hack will backfire. Each time I run an experiment on a culture I like to think that the change will be irreversible and then I ask myself once again: do I really want to run it?

    If not I simply don’t mess with the culture.