On the shoulders of counterculture

counterculture and personal experience
a movie still from V for Vendetta from 2005
V for Vendetta, 2005 (film)

Tech organisations are often seeking for improvement or “change” and will go to great lengths to “advertise” culture shifts or “winning-move” cultures.

A few of us who have lived some time in the industry have learned to distinguish the “weeds from the wheat”. We’ve met in one way or the other the usual “modern” suspects:

“The curse” of the previous lines of thought being, they’re often fiercely and unknowingly advocated as part of “culture” and “best-practices” incentivized by folks in organizations with a lot of decision power but very little “skin in the game”.

The other side of the coin being that more often than not, in order to solve actual problems, those with a lot of skin in the game have to go about themselves like folks “belonging to a counterculture movement” in order to do what’s best for the organisation’s projects and for them to thrive (or survive).

“Results may vary”

Sure enough, this isn’t the same for everyone.

There are organisations where good culture is brewed from bottom to top. In these the focus is on good outcomes and not on the generation of “mumbo jumbo processes”.

What are for some other organisations considered “revolutationary feats of guerrilla counterculture”, for others are cherished treasures. Treasures as simple as the active act of discouraging dangers like bureaucracy, red tape, and unrestrained personal (evil) ambition.

So how do we distinguish “change” between organisations? Here’s some of the stuff I personally use to discern if it’s culture (or feats of counterculture) that makes up the impactful portion of an organisation:

Scale

The scale and type of teams and products that make up the organisations matters of course.

It’s quite different to have 100 people all working “for the same goal” in X-weeks cycles, compared to say, multiple 1000-people teams working for different goals over a more extended period of time trying to “please” different parties whose interests might not coincide.

Are we using “scale” as an excuse in itself to not get “the job” done though?

With that said, scaling up (or down) should never be an excuse to entertain the interests of folks with little skin in the game.

Direction

Does everyone know, and respect, what everyone is promising to deliver?

I’m not talking about centralised spreadsheets of “goals” or “missions” or “deliverables”, I mean, do you know your own mission in your organisation? Do your other colleagues in other teams know their own mission? Are the missions done out of blind personal ambition of some parties, or are they done for the good of your consumers?

Do you really know who your consumers are?

“Glue”

Are the “glue-folks” (for example Producers, Product Owners, Agile “something”, Delivery “something”)… are they like actually doing their jobs?

Meaning, are they making the life of creatives/creators easier?

Are they needlessly overcomplicating stuff?

Note: I don’t mean “glue” in a derogatory way, there’s a lot of unsung heroes whose job it is of being “the glue” that holds teams and projects together and headed in a good and critical direction.

Stress

What are the “Tempos” of your organisation? Are you working on meticulously and calculated new features and risks, or by default, you’re spread all over?

Are you filling your plate with unnecessary stuff?

When you’re making a delivery promise, are you shooting for “perfect enough” (which is already a lot of stress in itself) or you’re unrealistically leaking beyond that constantly?

Values

Are people encouraged to “speak out”? Do individuals have a voice in technical matters or is that reserved for some in-house gurus?

Are people-processes (hiring, onboarding, progression, retention, personal and team happiness, …) by default guided by “culture-add” as opposed to “culture-fit”?

On the operations side, is a “firefighting spirit” encouraged or folks incentivize the opposite, say, by placing a lot of monitoring into everything, alerts and logs and building stuff so it will self recover (or make it easy for on-call folks to fix it)?

Do people prefer to throw a circus show, and design their software architecture into a big spaghetti, overdependent on some vendors, with a lot of moving flaky blocks and dumb points of failure… or are people attracted by simplicity and ease of use and “democratization of tech” (e.g. you don’t need to be an expert to be able to safely use a tool)?

Is the development process of each team sane, and prone to good sense-making? Notice I’m not writing, “is the dev process the same/standardized for all the teams”.

Do the tech folks in charge value that kind of culture of “building useful software” as a definition of done, and “Done” also meaning “when it is being happily used with few failures”?

Wrapping up

I think a lot tech organisations are somewhat lost and don’t recognise their true unspoken culture, which is sometimes toxic and ugly and filled with smoke and mirrors.

I personally believe that these also don’t recognize that, in effect, their success or survival is intimately related to (a handful of) folks that are in effect countering that toxic culture. When good culture is always counterculture, “change” is an illusion. Don’t leave it up to others, it’s up to each of us to do actual change. It always has been.

Thank you for reading. Feel free to reach out to me with comments, ideas, grammar errors, and suggestions via any of my social media. Until next time, take care! If you are up for it, you can also buy me a coffee ☕