Pawel Brodzinski on Leadership in Technology

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

Tag: productivity

  • Fundamental Flaw of Hustle Culture

    Fundamental Flaw of Hustle Culture

    It’s all over the news. AI companies force their engineers to permanent crunch mode. Expectation for working long hours is like a badge of honor in Lovable job ads. Google defined a 60-hour work week (at the office) as a productivity sweet spot.

    But in the spirit of one-upmanship, everyone was beaten by Scott Wu, Cognition CEO. He announced 6-day work at the office, 80-hour weeks as the new norm.

    “We don’t believe in work-life balance—building the future of software engineering is a mission we all care so deeply about that we couldn’t possibly separate the two”
    Scott Wu, Cognition CEO

    You see? All it takes to suck twice as many hours from every engineer is to stop believing in work-life balance. Voila!

    Why All the Hustle?

    The visible reasons for all that hustle are obvious. Everyone understands that, at the end of the day, there will only be a very few winners of the AI race.

    They will get rich. Everyone else will go bust.

    To make things worse, the bubble has been pumped to its limits. If you want to get a prediction that AGI is just around the corner, there’s no shortage of optimists.

    However, notably, after GPT-5’s lackluster premiere, Sam Altman mentioned that AGI is not a very useful term. Whoa! That’s new! One would wonder what might have triggered such a twist in the official messaging.

    Anyway, seemingly, the rest of the AI crowd is yet to catch up. The extreme hustle culture they install in their companies clearly suggests that they believe AGI is around the corner.

    Otherwise, how would we explain 60/70/80-hour workweeks?

    I mean, these are smart people. They do realize such work is not sustainable, right? Right?

    Cynicism

    OK, I’m not naive. There’s a ton of cynicism behind the hustle culture. The top leaders do it because everyone else does it, too. So they can get away with it. And people fall for this trap.

    Given all the hype, it’s easy to promise mountains of gold to everyone. If. You. Hustle. Just. A. Little. Bit. More.

    People will rationalize it by asking themselves a question: Am I fine coping with that toil for a couple of years and then walk away with $10M?

    Seems like an acceptable tradeoff, doesn’t it? CEOs of AI companies prey on that.

    However, I believe that they know the correct question should be: Am I fine shortening my life for 1-2 years because of the toil when someone dangles $10M in front of me?

    The answers to these questions might be different. But if you expect prominent AI figures suggesting such an alternative vantage point, well, don’t hold your breath.

    They will cynically exploit the opportunity even if it improves their odds of succeeding only marginally. After all, everyone else is doing the same.

    The Cost of Extreme Hustle Culture

    What’s fascinating is that it’s a herd behavior. No one seems to stop and validate whether hustle culture even works. Not even companies historically known to be data-driven, like Google.

    It’s as if a simple linear approximation was all they could conceive: twice as many hours, twice as much work done.

    Any team lead with even meager experience would disagree. It’s kinda obvious that the last hour of continuous work would be less productive than the first, when we’ve been well-rested.

    So, how about adding a few more hours each day? And then replacing one rest day with another workday?

    If you need to spell it out for you, here it is. It means more mistakes, more rework, more context switching tax. And even more toil. Which generates rework of the rework. A vicious cycle.

    At some point, and rather quickly, each additional hour has diminishing returns. Then, at some point, each additional hour has a negative return, i.e., it decreases the total output delivered.

    If you wonder why Henry Ford introduced a 5-day, 40-hour workweek in 1926, while keeping a 6-day pay, it’s not because he was an altruist. He wanted better overall productivity. And, surprise, surprise, he got what he wanted.

    Economics of Crunch Mode

    Sure, a factory floor in 1926 is an entirely different environment from an engineering office a century later. Yet Ford’s was hardly the only such experiment.

    Across many examples, it’s extremely hard to find any argument that supports the hustle culture.

    “We have omitted from this list countless other studies that have shown [dcreased productivity] across the board in a great number of fields. Furthermore, although they may exist, we have not been able to find any studies showing that extended overtime (i.e., more than 50 hours of work per week for months on end) yielded higher total output in any field.”

    Note, it’s about total output, not output per hour.

    Now, when dozens of research papers from different contexts tell the same thing, I tend to listen. So when it comes to the most recent trend for crunch mode in AI startups, there are two potential explanations.

    1. Extreme hustle culture and extended crunch don’t work. Thus, AI startups are harming themselves.
    2. AI startups are so completely different that they operate under a different set of rules.

    Because they surely employ human beings similar to you and me.

    At a risk of oversimplifying matters, these companies do software engineering. A fancy and cutting-edge flavor, I give them that, but software engineering nonetheless. They are not that different.

    Well, put two and two together.

    Data-Driven? Data-Driven My Arse

    If either of them, celebrity CEOs, had actually looked at the data, they might have realized that they’re harming their businesses.

    Of course, they’re harming their people, too. Yet I wouldn’t expect enough empathy or reflection from Sam Altmans of this world to make it a viable point in a discussion.

    If they want cutting-edge and speed, they’d be better off going against the tide and sticking to healthy work conditions. Ultimately, these companies have no shortage of investment money, and if AGI is, indeed, just months ahead, they could burn through some of those dollars by hiring more.

    Even more so, given that raising funds for these startups is easier than ever. These days, you don’t even need to tell what you’re working on, let alone release anything, to get billions. That is, given that you properly market your idea as AI.

    That is true, of course, only unless AGI is not even remotely close and the AI startups CEOs know it all along (but won’t say, as then it would be harder to attract investors’ dollars).

    Extended Crunch Mode Story

    There are industries known for crunch mode (I’m looking at you, game dev), and there’s no shortage of stories about how extended hustle was behind well-known disasters.

    I had a chance to listen to a creative director from CD Projekt RED speaking about their engineering culture just weeks before the launch of Cyberpunk 2077. During Q&A, inevitably, he was asked whether they would release on an announced date (which had already been moved a couple of times).

    “There’s no other option,” was his answer.

    We know how it ended. “Buggy as hell” was the reviewers’ consensus. The game was pulled from sale on PlayStation. And shareholders filed a class action lawsuit over the share price drop. A hell of a launch party, if you ask me.

    CD Projekt RED has extended crunch mode to thank for all that fun stuff. In an interesting twist, after they dropped the hustle and started working in a more sustainable way, they were able to recover from the initial disaster.

    Unsustainability of Hustle Culture

    The camel’s back is already broken, but I’ll add one more straw anyway.

    People will burn out working under such a regime. Some of them will last months, some quarters, some may even last years. But break they will.

    Again, I don’t expect empathy from the celebrity CEOs, but the consideration of their bottom lines is what they’re paid for, isn’t it? So, what’s the cost of replacing an expert engineer specialized in AI? Given the outrageous poaching offers we see, it’s absurdly high.

    And I don’t even mention all the time lost before a company manages to hire a replacement. Yes, precisely the time that seems to be precious enough to make CEOs force their engineering teams to toil for 6 days and 80 hours a week.

    It. Is. Not. Sustainable.

    Never has been. Never will be.

    If similar topics are interesting, I cover anything related to early-stage product development (and, inevitably, AI) on the Pre-Pre-Seed Substack.

  • Empathy and Respect: What Makes Teams Great

    I’ve been known to bring up research on collective intelligence in many situations, e.g. here, here, or here. In my personal case, the research findings heavily influenced my perception of how to build teams and design organizations. The crucial lesson was that social perceptiveness and having everyone being heard in discussions were key to achieve high collective intelligence. This, in turn, translates to high effectiveness of a team in pretty much any flavor of knowledge work.

    Since the original work was published, the research has been repeated and findings were confirmed. Nevertheless, in software industry we tend to think we are special (even though we are not) and thus I often hear an argument that trading technical skills for social perceptiveness is not worth it. The reasoning is that technical skills easily translate to better effectiveness in what is our bread and butter—building software. At the same time fuzzy things, like e.g. empathy, do not.

    The research, indeed, was run on people from all walks of life. At the same time every niche has some specific prerequisites that enable any productivity. I don’t deny that there is specific set of technical skills that is required to get someone contributing to work a team tires to accomplish. That’s likely true in an industry and software development is no different.

    As a matter of fact, enough fluency with engineering is something we validate first when we hire at Lunar Logic. The way we define it, though, is “good enough”. We want to make sure that a new team member won’t hamper a team they join. Beyond that, we don’t care too much. It resonates with a simple realization that it is much easier to learn how to code than it is to develop empathy or social perceptiveness in general.

    The whole approach is based on an assumption that findings on collective intelligence hold true in our context. Now, do they?

    Google is known to be on their quest to find what’s the perfect team for years. Some time ago they shared what they learned in a few year-long research that involved 180 Google teams. It seems they confirmed pretty much everything that has been in the original Anita Woolley’s team work.

    It’s not the technical excellence that lands teams in the group of accomplishers. By the way, neither is management style—it was orthogonal to how well teams were doing. The patterns that were vividly seen were caring about other team members and equal access to discussion time.

    What’s more, the teams which did well against one goal seemed to do well against other goals as well. Conversely, teams that were below average seemed to be so in a consistent manner. The secret sauce seemed to work fairly universally against different challenges.

    What a surprise! After all, we are not as special as we tend to think we are.

    I could leave it here, as one of those “You see? I was right all that time!” kind of posts. There is more to learn from the Google story, though. Aspects that are mentioned often in the research are norms, either explicit or implicit. This refers to specific behaviors that are allowed and supported and, as a result, to organizational culture.

    When we are talking about teams, we talk about culture pockets as teams, especially in a big organization, may differ quite a bit one from another.

    It seems that even slight changes, such as attitude in group discussions, can boost collective effectiveness significantly. If we look deeper at what drives such behaviors we’ll find two keywords.

    Empathy and respect.

    Empathy is the enabler of social perceptiveness. It is this magic powder that makes people see and care for others. It pays off because empathic person would likely make everyone around better. Note: I’m using a very broad definition of empathy here, as there is a whole discussion how empathy is defined and decomposed.

    Then, we have respect that results in psychological safety, as people are neither embarrassed nor rejected for sharing their thoughts. This, in turn, means that everyone has equal access to ongoing conversations and they are heard. Simply put, everyone contributes. Interestingly enough, it is often perceived as a nice-to-have trait in organizations but rarely as the core capability, which every team needs to demonstrate.

    Corollary to that is an observation that both respect and care for others are deep down in the iceberg model of organizational culture. It means that we can roughly sense what are capabilities of an organization when it comes to collective intelligence. It’s enough to look at the execs and most senior managers. How much are they caring for others? How respectful are they? Since the organizational culture spreads very much in a top-down manner it is a good organizational climate metric.

    I would risk a bold hypothesis that, statistically speaking, successful organizations have leaders who act in respectful and empathic way. I have no proof to support the claim, and of course there’s anecdotal evidence how disrespectful Steve Jobs or Bill Gates were. That’s why I add “statistically speaking” to this hypothesis. Does anyone have a relevant research on that?

    Finally, there is something that I reluctantly admit since I’m not a believer in “fake it till you make it approach”. It seems that some rules and rituals can actually drive collective intelligence up. There are techniques to take turns in discussions. On one hand it creates equal access to conversation time. On the other if fakes respect in this context. It challenges ego-driven extroverts and, eventually, may trigger emergence of true respect.

    Similarly, we can learn to focus on perception of others so that we see better how they may feel. It fakes empathy but, yet again, it may trigger the right reactions and, eventually, help to develop the actual trait.

    In other words we are not doomed to fail even if so far we paid attention to technical skills only and we ended up with an environment that is far too nerdy.

    However, we’d be so much better off if we built our teams bearing in mind that empathy and respect for others are the most important traits for candidates. Yes, for software developers too.

  • Hyperproductivity Myth

    If you are in broadly understood context of Agile you eventually has had to hear about being hyperproductive. Sources reporting a few hundred, or even as much as more than a thousand, percent productivity improvement aren’t unusual. In fact, 200% improvement seems to be “guaranteed” by some.

    That’s great! Good for them! They’re going to get hyperproductivity badge or something. Yay!

    What Hyperproductivity Is

    Let’s start with the basics though. What is this whole thing? When a team becomes hyperproductive? How much do they have to improve? Oh, and by the way, if a super-crappy team improves three times and guys that were already great only by 20% would that mean that hyperproductivity was reached by the former, the latter, or both?

    The most common metric I hear about in the context of hyperproductivity is velocity. Actually, I consider using velocity to measure productivity evil or dumb. How much should my team improve? By the factor of three? Nothing easier. Oh, and by the way, we don’t use our estimation poker card worth 1 that often anymore.

    Note: I don’t deny teams improve. I merely point that stating so purely on a basis of velocity improvement is naive at best. There are so many potential dysfunctions of such approach that I don’t even know where to start. How the scope of work is split into individual tasks? What is a distribution of point estimates? How has it changed over time? What do we understand as a task in the first place? How do we account for rework?

    In other words without understanding a specific context mentioning hyperproductivity is meaningless. Just a marketing fad, which it might have been in the first place.

    Efficiency As a Goal

    Even if we agreed on a reasonable proxy for measuring productivity there’s a bigger problem ahead. We are not in a business of writing most code, delivering most features or achieving best velocity. If you think you are, go talk to your clients, but this time try to actually listen to them.

    If you spend about 5 minutes looking for sources pointing how notorious software industry is in not building the right stuff you may change your mind. Is a half of the stuff we build utterly useless? How about two third? Oh, and by the way the rise of the methods that are literally aimed to avoid building things unless we know we’re going to need them tells a story as well.

    So yeah, focus purely on productivity and you’re going to achieve your goal:

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

    Stephen Parry

    The most painful problem of software industry is not efficiency. If it was, we’d already be in haven, given how much easier it is to build a software app these days than it was a couple decades ago. The problem is we are building wrong stuff.

    We may as well be efficient, but unless we are effective in the first place, i.e. doing the right thing, there’s no glory waiting for us.

    How We Create Value

    This brings me to the utter failure of pursuing hyperproductivity. Let’s (safely) assume that our goal is to deliver value to our clients. We do that by building stuff. Except the value almost never is clearly defined. In almost every case software development is a knowledge discovery process.

    This has some serious consequences. If we go by this assumption we may take all the functional specifications with a tongue in a cheek. It’s just a sketch of a map and most of the time not even an accurate sketch. This also means that amount of artifacts, like code, features, etc., we produce is not nearly as important as figuring out where exactly the value is, which bits and pieces we should build and which should be ignored.

    This happens when we discuss the features, look for solutions, research options, prototype, A/B test, change stuff back and forth to see what works. This happens when we don’t score on velocity or any other productivity metric.

    But wait, to become hyperproductive we should rather avoid that…

    That’s exactly why I don’t give a damn about hyperproductivity.

    I use to say software development is a happiness industry. We thrive only as long as our clients are continuously happy. We don’t make them happy by delivering more stuff. We make them happy by delivering stuff that has value for them and their customers.

  • Hyper-Productivity Is Not an Issue

    These days wherever you move you hear a lot of buzz words. People manager, are you? There’s one for you. Oh, you are more into leading projects, I understand. Try with hyper-productivity. You will definitely hear it here and there. Well, maybe it is a way to go?

    For the sake of this discussion let’s consider there are no well-grounded doubts about figures standing behind the idea. Let’s consider hyper-productivity was never called bullshit. Let’s consider you can make your team hyper-productive, whatever this might mean. But before we come to this I have a question.

    Why, the hell, won’t you make your team just productive in the first place?

    The problem I see over and over again isn’t with teams which are performing very well and struggle to improve even more. The problem is an average team can hardly be called productive. Just productive.

    We keep wasting our time because we organize our work poorly. We face way more interruptions than it is necessary. We don’t really care about making our estimates a bit better to avoid panic (and counterproductive) rescue actions at the end of the project. We hire, and then keep, people who don’t give a damn about learning. We promote wrong people who are living proofs of Peter’s principle. We keep making stupid lists of examples just to prove the point which everyone agrees with from the very beginning (well, that might have been wrong example).

    No, hyper-productivity isn’t an issue. If we were able to make average team just productive we’d see hyper-productivity paradise. If you want to optimize system performance you don’t make champions even better – you work to get average majority to another level.

    So don’t tell me how to make my distributed team hyper-productive. Give me an advice how to make a bit more fun out of our mundane tasks or help me improve my recruitment skills instead.

    Hyper-productivity shouldn’t really bother us, even if it isn’t just a buzz word.