1. 3

tl,dr; green exec has the mental model of developers as machines in a factory. How to correct?

Longer version:

Exec in question is part of a young startup and is still wet-behind-the-ears.

In discussion about why they want continuous delivery (don’t ask), they insisted that having open PRs not merged was like having machinary paid for sitting idle–and didn’t seem to grok the point that a more appropriate analogy would include the idea that those machines, if activated, would occasionally explode and set the factory floor on fire if not done carefully.

They had previously asserted that more developers meant faster progress, and when asked if they’d read The Mythical Man Month, said “I don’t really see how that applies here”.

Anyways, this led to a deeper reflection on my part about how to explain to green execs what the true economics of developers are? What do we think the economics are? Are we just machines? Is most business software just assembly-line work?

Failing that, feel free to use this as a thread to vent and bitch about clueless management. Clack those claws in protest! V.v.V

  1.  

  2. 3

    This is why many managers make poor leaders - managing is for objects, leading is what makes great managers, and to lead well you need to serve those you lead. If you don’t understand the value of your team - how can you maximise that value?

    The best analogies for this are sports teams - in the best teams the managers and coaches develop the group of players to act as one machine, using the strength and weaknesses of individual players to make the whole team more effective. To be more specific, in soccer having 11 goalies or 11 strikers in the team will not make you the best team, in addition buying the 11 best players in the world and sticking them a team would not make them the best team without the work of the managers and coaches developing those 11 players into a single effective team, managing the ego’s of such a team would be a Herculean task in itself.

    Good luck with the educating task - and remember when you are leading your horse to water that you salt its oats first…

    1. 3

      I have a more negative view. I don’t think that corporate management is clueless. I think that it’s malignant, for the most part. Sure, there are individual counterexamples. Not every corporate executive is a raging asshole, but it’s probably at least a third of them, and closer to two-thirds at upper levels.

      Some of us are really good at writing code. Others are very good at exploiting human systems and organizations for personal benefit. Guess who ends up calling the shots in the business world? That second type. They’re not good at much else, but they’re good at what the corporate world rewards.

      What do we think the economics are?

      The older I get, the less convinced that I am that anyone has any idea. I can come up with a convincing argument that a decent developer is worth $1 million per year. I’m not talking about John Carmack either; I’m talking about people like us who are probably in the top 5%, but not top 0.005%, of developers. Certainly, the successes of (the few) engineer-driven companies validate that… but what about the failures? Most of us don’t have the stomach (or wallet) for startup levels of volatility.

      Obviously, no engineer can simply go get $500 per hour based on his talents alone. In practice, we have to link up with people (managers and recruiters and rain-makers and other assorted pimps) who are good at managing human systems and capturing value, and they usually end up taking advantage of us. However, we seem to be helpless without these people, so what can I say?

      Perhaps we need an agent model. If I linked up with someone with good social skills and connections, I could easily go independent, get $500 per hour, and have more work than I’d know what to do with. That’s a lot of money for me. I’d be happy to give him 15 percent. I’m not willing to give him 90% just because he was born into the right caste.

      In truth, I think that the need for “pimps” or agents will never go away. People who are good at doing work are terrible at selling it, and vice versa, and that seems to be an inflexible law of nature.

      So what is a programmer actually worth? I can make a case for “quite a lot” but the market has a different view of things. And, to be honest about it, I think that the average corporate developer is significantly overpaid. Research-grade programmers might arguably be worth 6 or 7 figures, but the business-grade programmers for whom Agile Scrum exists are probably not worth more than any other white-collar office worker.

      Is most business software just assembly-line work?

      In practice, yes. Corporate programming is ticket-shop piece-rate work. I’ve tried to fight this and, in my experience, it doesn’t end well. Engineers who protect their specialties and try to keep their minds sharp get cut down for the appearance of thinking themselves “too good” for regular Jira-driven work. Savvy people realize that it’s easier to get a management job and be able to delegate the ugly work than to try to fight for something better than the status quo. There’s very little upside in the corporate world to fighting for excellence and there’s a severe downside, which is that you’ll probably get fired.

      We can argue about whether businesses “need” technical excellence, but they’ve decided that they don’t, and that’s largely because individual managers don’t. Engineers view it as a mark of pride to build a system that’s still in use 10 years later. Managers view it as catastrophic failure to be in the same job (rather than two or three levels up, and promoted away from any messes) within 5 years, let alone 10. So there’s just a conflict of interest. We want stability, and they want quick brag points so they can get lifted into something better and higher-paid. They will always want the quick, sloppy approach to technical work, and they will win.

      I used to think that the short-term mentality of contemporary business was a case of ignorance and misunderstanding, but now that I’m older, I think that it’s mostly malevolent. I think that certain people are very good at setting up “heads, I win; tails, you lose” events with just enough plausible deniability that they get away from the consequences: “whoops, I never thought that that could happen.” If you take a frenetic, short-term focus, you force more of those events to happen and, while you’re generating volatility that hurts the organization, you can externalize blame and cost while taking the upside– and move up the ranks faster. As applies to technology, I think that it’s also worth noting that most technical failures aren’t catastrophic ones like rockets blowing up, but gradual declines in performance that take months or years. This gives the business sociopath who cuts jobs and externalizes costs into the long term, in practice, plenty of time to figure out whom to blame and how.

      1. 2

        I don’t believe that this is something that can be taught. If an executive has never had the experience of working creatively as part of a team, he or she is simply not going to understand why “the codes” take so long, why certain ideas are bad ones, and so forth. Non-technical management pictures all of it as rote memorization.

        1. 1

          Things like TOGAF make a pretty good blueprint for delivering software and can be used by a clueless (but studious) exec to deliver software without ever having to understand why the codes take so long, and without ever having the ability to evaluate which ideas are bad and so on. Rote memorisation can work, but it’s hard work, and someone who talks like this doesn’t sound like they’re accustomed to hard work.

          What happens all the more often, is someone is “in charge” of a successful software deliver and then thinks they had something to do with it. You might feel the need to have a “come to jesus” moment with them (or their boss) and make them understand you, but while management can accept we pay programmers to code, it is much harder for them to accept we pay programmers for not-code as well, and it doesn’t help that much of this remains a matter of taste (and there are all-too-many tasteless software people poisoning the well for us).

          May I suggest instead, proposing a project to design the “continuous whatever” project as an actual fact-finding development project. Tell him about R&D and maybe suggest there could be some R&D tax credits he can go after as well. This is unsolved territory, and when we have a good (and fast) change management process for our products, we can go really fast.