If I'm not going to change something, I'd rather not talk or give opinions.
Related: https://strangestloop.io/essays/things-that-arent-doing-the-...
It’s like we’re moving chopped wood from the forest to the village and I suggest building a wheelbarrow but the boss says what we don’t have time for that we gotta move all this chopped wood. It’s crushing to have a job that could be very interesting but the tooling and processes sap all of that out.
Talking at the right place at the right time on the right topic is.
It seems like a matter of knowing who to talk to about what. I don't think the solution is to stop talking to everyone.
Presenting a rationale for something worthy of addressing (need/problem/opportunity) needs to be communicated somehow, and convincingly. In person, in writing, or a simple business case.
From my non-tech background, priorities are fluid, and things that are rationalized as urgent and important are given resources and attention.
If there is someone like the author spinning wheels in frustration, then maybe there's a problem with the organization aligning everyone on goals/objectives/outcomes -> leading to misaligned solutions being raised, and deaf ears. Or, maybe there's no opportunity to raise solutions with the right people.
But I’m not going to stick my neck out and be “the problem”. I will definitely speak up about misgivings over ideas where my manager has some authority to change something. But that’s about it.
But in my experience, line level managers are useless. They have no organizational weight or authority.
When someone reaches out to me about a job where they wanted me to lead strategic organizational changes or initiatives, the first thing I tease out is whether I will be reporting directly to someone who has real authority - in a smaller company someone with C* as their title. In a larger company a director.
Usually the push back from making changes is larger structural changes you need to get buy in for - not minor bug fixes.
Does it take away from your assigned work?
I’m putting myself in the position of a journeyman “pull tickers from Jira board mid level developer”. Not my real position over the last decade of having a more strategic position. But I still know which way the wind is blowing and know when to shut up.
Sometimes not speaking up is the best thing for future situations. Other times, it's too costly to not speak up, and what should follow is the speaker making right by their words: action.
Who deserves praise?
What spark here deserves to grow?
What new thing am I trying myself?
Who left today better because I showed up?
What's something I (personally) could have improved?
What mistake or new facts have I learned from/ widened by view?Yes. And? If the actionable steps and evidence you prepared are getting shot down, i.e. not getting the outcome you desire, then you are doing something wrong (and wasting your time). You can't control other people's actions, only your own. You can sometimes influence others, but if that is your goal the current approach is clearly not working and you require a different one.
A big problem I see constantly is the mindset that it's "wisdom". It's audible in the voice every speaker that thinks it true. No matter when it's said, no matter how many self-aware disclaimers precede it, it comes out annoying as hell (e.g. Lex Fridman). Some people, even when they know they're are doing it, can't stop themselves.
I noticed a glaring problem and pushed to refactor a product to fix it, and kept pushing, and kept pushing. In this case, there was a critical need to fix the product, and I was rewarded for it. It lead to a nice tenure for me for almost a decade. (And, I got to stay long enough to get bored.)
More recently, I noticed a glaring problem, and pushed up to the CEO because he frequently complains about the consequences of the glaring problem. The difference is that I can't fix the problem in a few months. There's a lot more coordination and working around other business needs. But again, as long as I'm persistent, I'll have a nice tenure for a decade or more. (And, the work is large enough that I don't think I'll get bored for a long time.)
There's always way more work to do and those key enhancements or research stories that could improve everything get deprioritized.
> Tech Debt Thursdays
Yes, "Fix it Fridays" is another alliteration.
Have you ever heard the phrase "man your battle stations"? Turns out in the US Navy there is also "cleaning stations" and there is a call for all hands to cleaning stations on the regular. I have proposed something similar on a few teams I've been on. Daily won't work and quarterly is too long. The problem is the sprawl that comes from cleaning up things that have unintended side effects. But yes, paying the interest on the tech debt needs to be normalized across our industry.
https://www.navy.mil/Press-Office/News-Stories/display-news/...
Fiscal debt is a one-dimensional number that becomes higher or lower from some offset, but it can't change direction. There's no "complex numbers debt."
But software engineering is only one-dimensional if your problem domain is so constrained that the only roadblock to execution is time-at-keyboard, and that's rarely the case in most software (especially startups and hacking). I've too often seen that debt just "evaporates" when the company pivots or the entire system is replaced by another system or rendered completely irrelevant to continue accepting the notion that debt works as a metaphor. Even in the small, too often I've seen things flagged as, for example: "debt - we should consolidate these two pipelines on top of a smaller set of helpers" only to see the use of the pipelines diverge over time such that it turned out to be a great first step to keep them separate and duplicated.
Sometimes things to be improved / cleaned up are obvious, but cleanup assumes taking disorder and making order out of it, and that requires us to know what order even looks like.
Until the desired outcome is defined and documented, holding off on solutions and effort would benefit both parties.
(Although, it's worth noting that in this era of more remote work, perhaps a little more read-in and context is useful to avoid burning time on back-and-forths that used to take minutes in front of someone's desk but can now take hours over Slack).
if they do, there's an equal chance that you either didn't understand the situation to begin with, or you work in a team with poor leadership and strategy. learn from the former, leave the latter.
“The avalanche has already started. It is too late for the pebbles to vote.”
The last time I worked for a product company was as at a startup where I was the second technical hire by the then new CTO who was building up the technical staff internally. The founders bootstrapped the company through an outside consulting company.
There I had a relationship with the CTO where I could just say “that’s a really bad idea” and he would listen.
Fast forward a few years and I was working for a shitty consulting company, I kept my head down for a year, let them fail after I was sure they wouldn’t listen to me and started interviewing and only stayed a year.
My career progression isn’t dependent on the job I have at the moment.
So much that. No one likes "drive-by advice" - if you want something to be fixed, there should be a person responsible for that. Maybe it's you doing all the work, or you convincing management, or management who is asking for an advice... But if you are just saying "we should fix FOO by doing this and that" with no plans as to whom those "we" are, it's only annoying.
There are times and places and reasons to hold your tongue, of course. None of which are covered by the author.