Collective bargaining and cargo cults.
Well, here we are.
Ash:Sorry. You you caught me out with that one. Well, here we are. We've decided to start a podcast for many reasons, but the primary reason is that myself and Ian, we come together to talk about things quite a lot in the course of our of our freelancing lives. We thought it would be worth trying to capture a few of these things because maybe some of it is is of some value to someone somewhere.
Ash:So let's look at all the things that we find and then pick a thing and then talk about a thing.
Ian:And of course, there are a lot of things.
Ash:There are a lot of things, which characterizes the world of technology in which we both work quite a lot. There's so many things to look at, and choosing a thing is really difficult for a person or a team or an organization. So this is our way of expressing some of those things.
Ian:Frankly, choosing a thing is perfectly hard for me. I never mind a large organization. Yeah. So we're gonna give this a try. We're gonna record what we think is an interesting conversation.
Ian:Hopefully, it actually will be, and you'll agree if you're listening. If you're listening, thank you, by the way.
Ash:Yes. Indeed. Thank you very much. Nice to meet you.
Ian:Taking a taking a punt on us. So how are we gonna do this? Well, we've both come up with a thing, and we're gonna talk about Ash's one first
Ash:My thing.
Ian:And then mine. We seem to be suffering from children's media overload here. So thing one and thing two, obviously, straight out of the cat in the hat. And what a lot of things straight out of the clangers. So we're grown up.
Ian:Honest.
Ash:Mhmm. Oh, that doesn't describe freelancing life to me, being grown up. No. It feels like I've regressed quite significantly.
Ian:Regression isn't always bad. Sometimes you need to look at things with a young mind.
Ash:A young mind.
Ian:I keep telling myself anyway.
Ash:Okay. Not sensible.
Ian:So what's your thing?
Ash:So out of all the things that I've seen this week, the one that really stood out to me was, around the the concept of collective bargaining and software development or essentially unionizing as it were Because, on Twitter, I saw, Liz Fong Jones, Liz the Grey. She's an ex Googler and, currently works for, Honeycomb. I talked about this quite a lot over a sustained period of time. And after a little while of it appearing in my Twitter feed, it kind of piqued my interest quite a lot, mainly in the context of me wondering why it hasn't happened as the tech industry has grown bigger and bigger and lots more people have joined that particular industry. So we talk about death marches in tech projects where, you know, we're routinely exposed to lengthy periods of mental and physical stress, working tons of hours in the gaming industry especially, with the crunch at the end.
Ash:And then we're also asked to to build really shitty or exploitative software that we that we know will either harm us or others, which I've often struggled with in the past in my, time in the gambling industry. And then there's also, like, routine discrimination against older people, younger people, non white people, non male identifying people, or what whichever bias is, you know, at at work, which might be powerful for us to organize against. But, this really hasn't happened on in any great numbers in the past. So I thought, well, let's dig a little bit deeper into it. After not thinking about it for many years and thinking that it was something that coal miners did, I sort of checked my own privilege and and read up on it a bit.
Ash:So I saw that the Googlers had been on strike against forced arbor forced arbitration, which is essentially you sign away your rights to transparent representation in any dispute with the company that they work in. And Google had actually, backed down to a to a certain extent on this practice. And then, subsequently, Amazon and GitHub employees have been working against, their own organization about some, government contracts, particularly for ICE in The US, which is the immigration one. So which I found really, really intriguing. So I'm a person who probably leans more in favor of labor than capital.
Ash:I think it's probably fair to say.
Ian:Fair enough.
Ash:But also someone who's worked in the gambling industry. So I thought it would be good for us to discuss, so what might be the benefits of organizing ourselves around, you know, software development as a as a discipline or however we want to do it. So what do you think here?
Ian:Well, it's interesting because the new thing that sort of struck me while you were just talking then was about you sort of look at the the whole thing of Maslow's hierarchy of needs.
Ash:Mhmm.
Ian:Because actually, traditional kind of unions and collective bargaining has been about giving people the right to basically have the lower levels of that, to have somewhere to live, to have, enough money to be able to, you know, exist and eat reasonably decent food and generally be, be happy. There are kind of lower levels of that. Yeah. In some of your examples, it's sort of stretching beyond that to the famous self actualization, but really about using collective bargaining not just to sort of help the situation of workers in a particular scenario, but to actually change the behaviour of their employers towards others, which is maybe a slightly different thing. Or or is it a slightly different thing?
Ash:Yeah. Maybe there's there's two strands to it. So essentially I think I approached it from does my, does my work allow me to meet my own moral needs and code if you like? And then there's also the ability to collectively bargain for better conditions. So I think those those are probably, like, the two strands that I that I came up with this.
Ian:Because even just the long hours and stress thing. So I've been fascinated about this because I've been in the industry for going on three decades, which I really should try not to say that often because it's a bit alarming. But in that time, I've seen projects that were unrealistically estimated, perhaps undeliverable, moving goalposts during the the their duration and the sort of waterfall delivery structure in those projects. And you've got to remember that agile started to emerge in the late nineties, early '2 thousands. And before that, really, the waterfall was very, very prevalent and, you know, for a long time after it as well and still going in some quarters.
Ian:And it's when you have that kind of project structure where you're trying to deliver something that's not really deliverable in the time, and everyone's working sixty hour weeks and still not cutting it and still not having any feeling of success. And when you get into ops and infrastructure management, that feeling can just stretch out to forever for the Yeah. People in those roles. Yeah. And when you've got the separation between the running of a system and the building of it and people are performing context free tasks where it's impossible for them to understand why that's important Yeah.
Ian:To someone, why they're doing it and they just get abuse back. Yeah. I feel a really strong desire to find a way to help those people but the thing that always I think about is when you look at a modern project or or work stream, you know, employing the techniques of agile and and dev ops, although I don't like to say the the word, but having fast feedback loops all the way through
Ash:Yeah.
Ian:Accountability, delivery of value often. People who work in those projects, I feel, are much like more like to be happy Yeah. Than the people in the death marches. And so, I mean, my first question before organising is why don't people just leave and go work somewhere where?
Ash:Yeah. I think that probably speaks to one of the reasons why why we don't as technology people is because it is relatively easy in the industry, depending on who you are and what context you're coming from, of course, to go and get another role, but that's not true for everybody. No. I think, again, it was about, like, sort of checking when looking into this, it really made me think about, like, my own privilege because I personally let's just say I've not had too many knockbacks in my career.
Ian:Sure.
Ash:Yeah? Which, I would love to think is all down to my fabulous competence, but I really don't think that it is. So sometimes it's like, for the people who have the power, it's too easy just to, like, say move on, get something else, and leave the bad behind. So I think it's kind of multifaceted in that way in that we're looking at working conditions plus meeting, you know, what we see as our moral obligations to ourselves and to others. So I think sometimes we we have community meetups, for example.
Ash:Yeah. So I think sometimes we go towards organizing ourselves into into groups, whether it be be by discipline for testers or, you know, by domain or or whatever the the the split is. So we have these community meetups, but we don't go further and organize ourselves in in a collective way to to bargain with. So have you got any thoughts on why you think that is?
Ian:In many ways, they're quite different things. I mean, I lived through the, you know, all the miner's strikes, the Margaret Thatcher versus the unions in in in this country. And it just I suppose for many years, it has just seemed like something it it was something with very deep and established roots in The UK. Yeah. And it didn't seem like maybe there was room for the more the newer industries to to participate.
Ian:I don't know. I don't really know where I'm going with that.
Ash:No. I think there's such a fixed mindset around unions and especially in The UK. So as soon as I thought about this, my my brain always jumps to coal miners. So, maybe it doesn't have to be the same as it was. It can be something different, but we just don't know what that is yet.
Ian:Well, I think it's it's got to be because, I mean, the unions really, really helped in the first part of the, twentieth century. You know, the union movement helped bring workers, you know, coal miners, steel workers, those those kind of sectors out of a terrible, terrible sort of world, went into a a better world where at least they were getting paid reasonably. And, you know, they had some means of protesting if collectively if something was not safe and was endangering their lives. Yeah. And then later on, it it started to seem as though it was also being used to protect people who weren't very good at their jobs or protect people from the, you know, disciplinary processes, which I'm not saying those can't be abused, but it seemed as though the balance of power had gone the other way.
Ash:Yeah.
Ian:I think you're right that we need for this to work, we need some more modern approach to it. I'm not sure what that is, though.
Ash:So, yeah, for example, I'm involved in a in a conference called the Leeds Testing Atelier, which is held at a workers' cooperative.
Ian:Most excellent conference as well. Most excellent. I recommend you attend it if you're anywhere near Leeds or even if you're not.
Ash:So again, a cooperative is a slightly different, obviously, beast to a union, but enables people to share experiences and and gather support from each other. So it's I I guess that could be one of the structures that you can use there, but how much influence that has on individual organizations is is obviously slightly different as well. But I just found it a really, really interesting story in terms of thinking about my own career and thinking about some of the things that I've built and I've done, and really, really looking at it from the point of view of different groups within software development and how my own experience with in my career compares to theirs and how much value there might be in something more collective happening within the industry.
Ian:I don't really know how to get from here to the answer, but I would say if you're listening to this and you've got an idea, then you should definitely tweet to us or something like that. Yeah. And, I'll try and find a way of insert we need to create a Twitter account and then insert it in here somewhere so that people can know what it is. But get in touch with us and let us know what you think.
Ash:Yeah. Absolutely. Okay?
Ian:So I guess it might be time for thing two then.
Ash:Thing two. So, Ian, what's your thing?
Ian:This week, this first week, it's cargo culting, which I was at Agile in Ilkley a few weeks ago. And, we're doing this kind of thing of the ABC of agile. So we spent some time going through less of the alphabet and thinking of an agile related thing to put against that letter. And a did not stand for agile.
Ash:Yay. Big a.
Ian:But if you want to know more, you can you can Google for agile in Ilkley and take a look. But c was cargo culting, and that was kind of a surprise to me. And I sort of thought, oh, okay. Well, I have heard vague things about the cargo cult. The Melanesians, according to Wikipedia Yeah.
Ian:Who in the late nineteenth and early twentieth century were benefiting from Western technology and and goods arriving on on aeroplanes and and the like. And they were doing things like building a runway in order to cause the aeroplanes to come. So they kind of had it a bit backwards. And dictionary has a definition, an approach that copies an existing successful approach without properly analysing and understanding it. And I thought that was very interesting Mhmm.
Ian:Because I think we see this a lot. And to me, it's a bugbear of methods. So methods are brilliant because they give you a framework where somebody's thought about something already. And it gives you a massive head start in deciding how to run your project or or how to build your right architecture or whatever it might be. That's great.
Ian:But you get this scenario where people adopt them without really understanding. So you get people, creating some new meetings in their schedule called stand up and retrospective, but not really deeply grasping what those things are for and how to do them. And just almost by renaming some meetings, they feel like they're, oh, I'm agile now. Yeah. I think it kind of comes with this idea of people liking things to be simple.
Ian:There's a great quote that's attributed to Albert Einstein but isn't, which I used to have in my email for a long time ago, because I just thought it was brilliant. Everything should be made as simple as possible but not simpler.
Ash:Right.
Ian:And I I just think cargo culting is about making things simpler than they possibly can be and still be effective.
Ash:Yeah. I've seen this quite a lot, I I would say. And I think it has, like, two sides to it. Mhmm. So I think early in my career, I would probably accuse organizations of this relatively often.
Ash:But I think as I've evolved in my career, I'm kind of a bit more understanding of why this happens. And I think sometimes it is used sometimes I think it's kind of weaponized a little bit to to beat upon organizations, which probably doesn't help them that much. It probably just sort of entrenches that behavior.
Ian:Well, definitely. Yeah.
Ash:There's definitely, like, a an urge to adopt a framework. There's often phrases like scrum is like training wheels. So, you know, you need to take them off eventually and come up with your own way of doing things which suits your organizations. Now, I don't know if that's true, and I don't know. I think that would probably lead to cargo culting because stand ups and retrospectives are just names for things which have a greater purpose.
Ash:Yeah?
Ian:Absolutely.
Ash:So stand ups are for synchronization, and retrospectives are for continuous improvement. If you've got no idea how to do these things, or you don't have cultures of synchronization, of teamwork on what you're gonna work on and retrospectives to continuously or continuous improvement in your organization, then having them initially might be okay. But evolving from there is the key thing, but that doesn't often happen. I think cargo cooling has a bit of a, like, a time delay on it. I think sometimes we'll start initially doing those, ceremonies, and they'll have some purpose and some urgency around them.
Ash:And then eventually, they will peter out into just repeating the same thing over and over again and hoping for some results, because a lot of underlying cultural aspects of that organization haven't changed when you've introduced the ceremonies.
Ian:Yeah. I'm wondering about this thinking that there's there's a lot in what you've said, actually. So the the I think the first thing is this idea of using this as a stick to beat organizations with. I think I actually think it's almost never helpful to use anything as a stick to be to beat organisations with, and it does. I think you're absolutely right to say it would entrench the behaviour.
Ian:But one thing that I guess has occurred to me is that actually you can do almost anything provided you have a genuine feedback loop where you improve it. Yeah. So you very regularly or often and regularly, not just regularly. Every two years wouldn't be enough. But often and regularly.
Ian:Blimey. It's saying this much too much now. Okay. Rewind. Rewind.
Ian:Adopted.
Ash:Frequently. Regularly. And oftenly.
Ian:God. I can't even remember what I said before it, so it was really done. A feedback loop that is regularly executed, which genuinely can change the direction of and the content of what's being done. In fact, that can that does engender genuine continuous improvement. That, I think, can fix almost any misunderstood or bad process because you can look at it.
Ian:You say, what are the outcomes of what I just did? How can those outcomes have been better? Let's change the following things. Yeah. And it's impossible to genuinely do that and do cargo culting at the same time because to do that, honestly, you really need to understand, at least in the end, why the things that you're doing existed and why they were proposed and put into that, whatever that method is.
Ash:Yeah. So a project manager that I used to work with, at this particular organization, we're using something called, DSDM.
Ian:Oh, yes. Remember it well.
Ash:Like a variant sort of prince two slash scrum framework. This particular project manager executed DSTM to the letter with great enthusiasm. And I don't know whether it was through force of will or or whatever it was, but the the projects that that certainly that that person was on, even though they relatively sort of wrotely went through just, you know, each part of the guide Mhmm. And answered that question for that particular project and that particular need, were actually pretty successful. Mhmm.
Ash:So you could accuse you you know, you could have accused that person of of cargo culting. But, actually, by sticking with the playbook, if you like, their projects were still markedly more successful than the rest of the projects around the organization as I perceived it. So how do you feel about that?
Ian:I wonder what else was going on. Yeah. Maybe there was something in that playbook that caused the success.
Ash:Mhmm.
Ian:But equally, it could have been that there was some other behaviour around that diligence and attention to detail that was clearly going on that might have caused it to succeed. I mean, if that project manager had deeply understood DSDM, deeply understood why all the bits of it were there and what to use them for and how to use them successfully, then it wasn't cargo culting anyway.
Ash:I would say that on occasion, we we we did things where it was like, this obviously doesn't apply to this piece of work, but we did it anyway for completeness. But I've just always found that a really interesting, like, counterexample to cargo culting. It's like, well, actually, by running through the playbook, it might have taken longer and ignored context a lot, but the outcomes were generally better. I mean, it's an isolated example, so it's kinda hard to say.
Ian:I feel as though people don't write down methods out of nothing. So the people who write down methods generally have very good reasons. And, you know, there are some very clever people quite often. And the problem actually is germ is is often not I don't think it's inherent to methods. It's inherent to execution of those methods by people that don't understand them and don't really get what the things are, what they mean, what their intended purpose is.
Ian:And I think a very well documented method, Maybe maybe you can get away with it. Mhmm. But I guess you'd be lucky. My general opinion about this and about most things is that it's very nice if you don't have to think, but actually you always do.
Ash:Yeah. Yeah. I think that's, I think that's fair. So I think in terms of, solutions, should we go there? Yeah.
Ash:Yeah. The feedback loops is obviously one. And then going back to first principles is a great thinking aid as well.
Ian:And that's good with agile because you've got the agile manifesto. So, I heard the term scrumdamentalist recently. But, you know, you can always debate with a person who's trying to mindlessly force adherence to a method to say, particularly, well, in the case of an agile method, well, let's go back to the agile principles, people over process.
Ash:Yeah. And I think also some of the tools in the Kanban space are really useful there in terms of respecting current roles and finding out visualizing what you currently do, is that I always find is a is a missing step because I think it's too tempting to go with scrum, DSTM, dad, save less, whatever, without finding out what you do right now and Yeah. What the current roles are. Because, you know, it's really hard to get people on board with more agile ways of working if you just disrespect their current role. So I guess, specifically, as a tester, I think this will probably resonate with a lot of people in that particular discipline because there's often these small testers that, you know, they're still in the same habits.
Ash:They still wanna test everything, and they're still doing too much, you know, manual poking of user interfaces. And it's like, well, but if you don't respect the current role structures and how things are done, how do you expect to bring people on that journey with you? And then I think cargo calling comes from that as well because it's like, well, for a quiet life, I'll go to the stand up and I'll go to the retrospective, but I won't really contribute anything. And I'll just try and keep things the same underneath just with a set of new new ceremonies. So I think you do need to visualize what you currently do and respect the current and respect the current role and find out where you need to change and find out genuinely where your bottlenecks are instead of just saying we're testing the bottleneck.
Ash:It never is.
Ian:Well, there are very few green fields Mhmm. In our industry. Almost all of the the work is on preexisting estate unless you're starting a new start up. Yeah. Which always sounds fun,
Ash:but Yeah. Absolutely.
Ian:Has its own problems.
Ash:So I think we're, you know, going from a requirement and design based culture to an outcome focused culture really helps as well. Yeah. So rather than just thinking about, well, you know, what does that purse what does, you know, the highest paid person in the room want?
Ian:Uh-huh.
Ash:And think, well, what's the outcome of this? And what's the simplest thing we can do in order to try and meet that need rather than building on, trying to build gigantic solutions because someone's gonna get a bonus at the end of it, which is unfortunately the organizational truth sometimes. Yeah. And again, those organizational dynamics often lead you to cargo culting as well because it's like, well, what's my motivation for this? Don't know about you, but I've worked on stuff where it's like, well, I don't understand the motivation for this, and I don't count myself to be a stupid person.
Ash:But I know that I'm gonna be working on this for the next year on this contract, and I don't know why I'm doing it, which again, leads you pushes you towards your Yeah. Cargo culting behaviors.
Ian:Yeah. I think that's right. So, yeah. I mean, there's a question, I guess, about how you how you address and and change that
Ash:Mhmm.
Ian:Behavior if you see it. And I guess, you know, we talked about the feedback loops and first principle questioning everything.
Ash:Sometimes that gets you into loads of trouble, though.
Ian:Well, yeah. Yeah. And, you know, if that's happening, then maybe we will go back to collective bargaining at this point.
Ash:But So So do we need to collectively bargain to be able to ask questions?
Ian:Well, yeah. Almost fairly fundamentally. Yeah. I'd like to come up with a pithy summary at this point, but I don't really have one.
Ash:Pithy summary. So brief pause. So that's both of our things. So my thing was around collective bargaining in in technology and how to how we might want to organize organize ourselves. A bit about what that might look like in the future because the collective bargaining of the past might not be effective in the technology industry.
Ian:And my thing was about cargo culting and using approaches and methods without proper understanding and how that might happen and what we might do about it. So I think that's our our things. Now I just have to edit the, two hour conversation down to, down to the twenty minutes that we feel should be the length of this.
Ash:Yeah. Put the put some coffee shop and pub sounds in the background to make us sound cool.
Ian:Yeah. I think I'm gonna need more than that and not sound cool. Is there anything else we should say?
Ash:For more information about us and the show notes that we've been we've been using for this as well, check out the description or whatever it's called. We might have to do that again because I don't know what it's called in the tool that we're gonna be using. So so basically okay. So a brief pause. To find out more about what we've talked about, check out the show notes for links and further information and our notes on what we've been talking about today and contact information and more about myself and Ian.
Ian:Great. Okay. Well, thank you very much, Ash.
Ash:Thank you too, Ian. It's been a pleasure.
Creators and Guests
