NetSuite is a never ending money pit with varying results. I dealt with a very similar situation, in which a project manager("VP") talked our owner into using NS, but it was over $100k/year and commitments were 2 years per seat at something like $5k. He ALSO wanted to do the roll out himself. 6 months later, it was still not functional.

I got pulled onto the team to help. We made _some_ progress and I hired and managed 4 remote programmers to write all the plugins and customizations we would need to make it work with our model (multi-channel e-commerce, multiple warehouses/locations). It was a nightmare all-around and completely unnecessary. PM/VP left the company because he couldn't do the job and we were stuck with a half-assed implementation at that point.

It's been around 4 years since the first day, I am no longer with that company, and I am sure they are still struggling with NS and employing multiple developers to keep things going. Good for the devs, bad for biz. I am willing to bet it's never returned a single dollar on the investment and cost them far more than they wanted to spend. If you can't see the light at the end of the tunnel at this point, cut your loses, and don't get another "solution-in-a-box".

But I guess the fundamental problem hasn't changed: executives want to believe in magic solutions that give them all the feelings of control with none of the actual work. With no regard for actual operational efficiency, and no need to hold themselves to the ROI standards they'd demand of others.

Corollary: R&D wants to believe they can build magical solutions that solve all the problems--solutions that will scale better and cost less to keep up than off-the-shelf ones made by people with extensive domain expertise--in a week or two, promise.

As with most things, the problem is complicated, deeply human, and answers lie somewhere in the middle.

And often the features you need are much easier to implement than you might have expected and, due to the generalisation complexity, hacking on the off-the-shelf product often much more difficult.

--

I've been struggling to articulate a thesis, for way too long. But here it goes.

Complexity catastrophe occurs when cost of change outweighs benefit. Or simply can't be done in time to make a difference.

Whereas databasization makes processes inflexible, humans are relatively more flexible. Like being able to make notes on forms, or quickly modify a form and make more copies to use.

--

I'm heavily influenced by process and methodology ideas. Deming, Drucker, TPS, etc.

As well as their critics. Postman, Norman, etc, and most recently David Graeber.

Graeber's notions about bullshit jobs and bureaucracy have articulated many of my misgivings as well as made me feel stupid for my hubris.

--

Both database and paper mediated systems have pros and cons. In defense of younger self, we were not fully aware of the costs and limitations of databases, so couldn't properly weigh the options. Worse, my entire career, I tried to mitigate, engineer workarounds to databases, not willing to accept the problems are intrinsic and not just artifacts of suboptimal implementations. Basically, clap louder and Tinkerbell will fly. Embarrassing.

--

My notion of "complexity catastrophe" comes from Design Rules: The Power of Modularity.

I may have just coined "databasization". I've long accepted the difference between digitization and automation. Moving processes from paper to computer mediated vs removing judgement (aka process reengineering). But have never found a succinct way to explain it. Maybe "databasizition" makes the distinction more clear.

--

Thanks for listening.

For the applications that I designed so far, that meant that I always made room for intentional loopholes like free-form comments or ways to override hardcoded processes. It is not 100% perfect and foolproof, but it made using these applications a lot less painful in practice.

A wholesale return to paper is like trying to put the genie back into the bottle. It is really about how rigid a process can become without becoming a barrier or burden.

And then there is Mannheim, a city with no street names. This was originally a planned city where the city center has rectangular blocks numbered in a letter-number scheme. So there is e.g. a block L5. This refers to one side of the 4 adjacent streets. The other side of these streets is addreseed with L3, L5, etc... what his means is that you have addresss like O7 6 - a single letter and two numbers in a row. I bet that a lot if input validators for addresses trip over something like that.

I had to rediscover the "INSERT only, no UPDATEs" trick on my own. Changed from separate truth and historical tables to a single table which is groomed over time. Major simplification. A few extra benefits: like scaling, testing and auditing.

And my peers absolutely lost their minds. A senior VP rolled back my architecture the moment he could. (We were acquihired, so this meant major upheaval of systems which had be in use for over 3 years.) My solution was just too weird looking, too unorthodox.

So while there's lots of things we can do to mitigate databasization and buy ourselves some head room, we don't.

Square peg, round hole?

My radical (unoriginal) thought is the problem is the people, not the tools.

Real world is messy, evolving. Schemas and programming languages encourage rigidity, but can be more flexible. So while we can design and use adaptable systems, we don't.

An additional theory I have is that the people drawn to our type of work have rigid views and strive to make the world more ordered, through their systems, rather than accommodate the chaos. Aspirationally. Not in truth. Because I regard most of our efforts to be rather chaotic.

Fowler's Event Sourcing [2005] https://martinfowler.com/eaaDev/EventSourcing.html

Published after I stumbled onto my solution.

What's your definition?

"you also didn’t list any pros or cons of either."

Thank you. You're right; I should do that. Long overdue.

Alas, I don't know how to do that.

The best I can do, at this time, is list examples of digital, paper, and hybrids which succeeded and failed. Try to divine RCAs. Then see if there are patterns.

I do have some initial guesses about best use of paper.

1- Organizational boundaries.

Like mediating communication between entities. (It slays me that scripts and referrals are done by fax, which might as well be black boxes, because the communication can fail silently.)

2- Legal stuff.

IDs, cash, voting (ballots), titles (property).

3- Short lived communication (semaphores), coordination, collaboration.

Lo-fi tools for brain storming, designing. Visible tools, like resource planning white boards.

"what do i do with my daily receipts?"

You say that like it's obvious. Of course we should design (engineer) away data entry.

Yet SAP Concur is still a thing, with wide adoption.

JIRA, ServiceNow, PagerDuty are crimes against humanity. Bending the work towards computers, instead of empowering humans.

I've gotten so much shit (from the larger orgs) the times I've moved my teams from heavy weight, labor intensive, error prone tools to lightweight lo-fi tools.

One stupid example: For weekly triage, we'd just print the bug list, and everyone (everyone) could vote, then cc copies of the list as needed. Voila, instant priorities.

The majority of push back is the style documented by Neil Postman's Technopoly. Some people can't wrap their heads around not using computers for everything. It's like the debate between ontologies and folksonomies. People who can't accept ambiguity vs people who can accept "good enough". (Just one over simplification of the psychology. I did pre-caveat by admitting my thinking is muddy.)

###

I've long dreamed of a technical solution.

Some kind of hybrid of HyperCard & wikis backed by version control.

New instances of a CRUD form (both UI and backing data) would just be cloned, a la prototype based classes. Every instance can be customized, a la live editing. Imprint both schemas and forms with a version token, so the system can support multiple variations, so that orgs and evolve processes incrementally (instead of outright cut-overs).

I recently made some progress on bridging the gap between persistence and UIs. I'm trying to reorient my life to resume work.

This argument applies to open and close sourced software alike (ever try to migrate from MantisBT to Jira?)

The insinuation was that trying to buy and customize SAP to your business was a fools errand.

IMHO, this describes any Oracle product. Usually what happens is a great little enterprise software company that gets a lot of happy customers gets bought by Oracle and then they start sucking the money out of everyone through nickel and dimeing on absolutely everything and make moving off the platform impossible and integrating with it difficult.

I guess it's normal for enterprise software vendors to be absolute trash.

I'm not sure to what degree this corporate disdain for quality of work environment is intentional or simply inability to grasp how other people may have different experiences using something, but I'm even more unsure how to solve it. What do we do when attempts to explain how shit sucks fall on deaf ears? Bring back pistol dueling?

You may find the term "managerialism" handy. It's the belief that managers and execs are the central story of a company, that everything must flow through them, especially key decisions. And of course, that as the special people, they deserve outsized rewards. It's the dominant philosophy of US business, and although it seems eternal to us, it was invented in the 1950s and 1960s, along with the MBA that became a vital qualifier to join the managerial class. And it is definitely a class system; note who flies in "business class", for example.

It took me a long time to be able to see it, but once I did I see it all over the place. It was sort of the same struggle when I learned functional programming: I had never really thought about the rest of programming, its philosophy and value system. I was soaking in it, so I didn't need to.

The book that got me going was "Confronting Managerialism", but I'm sure there's a fair bit more out there these days: https://www.amazon.com/Confronting-Managerialism-Business-Ec...

Yes, it's "feudalism", but it's a specific part of feudalism, that deserves to be called out separately—the idea that "everything must flow" through the org chart in a literal sense, with each node on the org-chart entirely encapsulating everything below it on the chart from the view of those above, such that the knight's liege-lord really doesn't know how they're getting the job done, just that they are or aren't; and has no actual capacity to micro-manage the HR decisions of the knight, with the lord's only controls on their knight being to change their budget, or to fire them.

In a way, it's less like what we're doing today in bigcorps, and more like what you get on the other end, when everyone is an individual, atomized contractor selling their services to everyone else. You can't see "through" a contractor-client relationship to the contractor's employees and/or subcontractors; you can only fire the contractor, or renegotiate their rate.

IMHO, while this paradigm might seem inefficient in ways, it still seems like a better "organizational architecture" than managerialism. Perhaps because, given the encapsulation, a punishment coming from your boss's boss can never "run downhill" to end up falling on you (though, nor can a reward); instead, each node on the org-chart can only rewrd/punish their direct report. At some point someone on the org-chart claims ultimate responsibility for getting the job done; and even if it came down to you, three nodes lower, failing to do it, it would still be their head, because it's their promise to their liege-lord.

Such a paradigm is inconvenient, in the sense that if your boss is fired, that means that you're out of a job—you were being paid, effectively, out of your boss's salary. But it's also convenient, in the sense that you can just apply for a job with another part of the company (really, apply to another superior to work for them), and there won't be any institutional bias (e.g. records of a "Performance Improvement Plan" against you because of a bad previous boss's poisonous office-politicking, only the personal biases of the boss's direct friends, who you can just avoid.)

In my view a larger version of that is the way the military is setup in the US. Lots of duplication. Every branch has planes and when they try to coordinate on large projects you get the F-22 project where every branch has demands that make the project take longer, more expensive and, with lots more compromises.

But yeah, the military's a good example of taking the worst of both worlds there.

In a way working at Google is like that. If your project doesn't have "impact" your manager isn't promoted and nobody in the team is.

And engineers are generally free to change team.

It does have some inconvenients and it doesn't remove politics.

https://www.youtube.com/watch?v=qmTWhvWgST0&t=5m25s

A friend of mine also recognized it in this 2015 article (see footnote 1): https://reasonandliberty.com/articles/obamacare

But I really like "soviet capitalism", as it points at a key contradiction. Somehow, fans of capitalism, which maximizes surplus value by freeing individuals to make economically rational choices, rarely seem to notice that large corporations never make use of the mechanisms of capitalism, instead relying on central planning. And like the soviet era, corporate central planners often do things that are economically irrational, but useful to their careers and their quality of life.

Is that clearer?

My goal was to make a particular point about an unresolved conflict in managerialist ideology. If you're still having trouble understanding the point, feel free to ask specific questions, or to try restating the point in your own terms. But if you're mainly JAQing as an argumentative technique rather than seeking to understand, then I think we're done here.

First, you describe a "key contradiction" that the capitalist economy as a whole would operate differently from a corporation. But it's unnecessarily reductive to demand such consistency. Ideologically a corporation is closer to an individual actor than to the overarching economic system imposed by government. In practice corporations grow from a single individual to huge conglomerates on the merits of their market performance, not from threat of violence, monopoly on employment, or other political power.

Second, you claim, "large corporations never make use of the mechanisms of capitalism, instead relying on central planning," which is a bold claim requiring evidence. There is tons of autonomy granted across the levels of a corporation, and a long history of conglomerates and franchises that cover the gamut of such regimes. If all of these are "central planning" then you need to explain what the alternative would be, otherwise its just a hand-wavy no-true-scotsman claim that can't be meaningfully examined or discussed.

You are incorrect, when you start getting into nuances. When you have the govt doing central planning, there is no way to get rid of them when they under perform. When people voluntarily form central planning organizational structures, they are eliminated by the free market if they under perform.

The difference between communism/capitalism is fundamentally of philosophy not of structure. In the former it's coerced co-operation (which almost always results in central planning) and the in the latter it is voluntary co-operation( there will be many organizational structures and some may have a central planning)

How old are you? (no I didn't make a mistake when I asked you that question)

All Democratic governments include a way to do exactly that - by definition. There's room for debate over how effective it actually is at removing underperformers compared to the free market, but saying it has no way to get rid of them is just untrue.

In a democratic government, you're not electing the central planners. In the american government, you're not electing any of the millions of three-letter agencies that rule your life. You hire a president, and he may or may not do something, who knows.

At least a market has some contact with a ground truth of bankruptcy. If there were several competing EPA's competing for money on the basis of their efficacy, that might be interesting.

You are either young and naive, or an idiot. Sorry, name calling is the only way to call out ignorance. Things simply don't work the way you think it does. In theory 'democracy' promises you a lot of things, but you get very little. Most democracies for most part are sophisticated form of oligarchy where the masses are essentially fed what to think, by propaganda, 'debates' etc.

Crossing into making an argument personal is especially not ok, and we have had to ask you about this before: https://news.ycombinator.com/item?id=21797575.

The difference between classes or tribes is their value system. The more you rationalize why your tribe is superior, the less chance you will ever be able to switch to another. So ask yourself if you really want to feel superior, or to prove yourself?

Would you care to show me where you think I claimed 100% of managers have MBAs?

> ask yourself if you really want to feel superior, or to prove yourself?

Neither. There are more things, Horatio.

You wrote it was a "vital qualifier" to join the managerial class. You didn't 100% commit to saying it was necessary, but without that implication, I don't think you have really said anything.

That would be PeopleSoft.

A former employer decided to use it to integrate/replace multiple different working business systems they had been running for at least a decade without issue. Part of that solution involved having 'project specialists' specially trained on the system so that they could run reports for project managers, presumably while also fetching them coffee (/s).

I looked at the UI once out of curiosity but very quickly shut down my browser as my eyes started bleeding.

When you say

> Reports...are roundly ignored

That lack of weight given to your experience as a signal of real business cost is a real problem.

So what is the solution?

1. Understand the problem they're trying to solve. What are their real motives and pressures?

2. Understand where your needs align with theirs and where they diverge in reality.

3. Tell a compelling story of where your needs are in fact aligned.

3.1) Prepare Evidence

If your case is "This tool is causes literal permanent eye injuries to our staff", then there should be written reports of those injuries. If your case is "This software package has multiple missing-affordances which present operational risks to the business", then you should be able to take screen recordings of that.

3.2) Start with why

When turning evidence into a presentation, remember that people listen better when they know why they are listening. So start with: What is at stake?

3.3) Credible language

If your words say "the UX for hundreds or thousands of others is 'the software literally shoots knives out of the monitor and gouges out your eyes'" but you can't actually back that up with the factual reality, you seem like you're exaggerating. If I think you are exaggerating, then I can't trust your words when I'm trying to understand magnitudes.

If I can't trust your words about magnitudes, then how do I give you a voice in making a well-balanced trade-off?

-------

Literally: (adverb)

1. In in a way of speaking that is completely accurate and unexaggerated.

2. In in a way of speaking that is exaggerated for emotional effect.

But my understanding is that in general communication is a 2-way street: Both people in a relationship should be listening with the intent to understand the others' perspective and to watch for misunderstandings. Up and down a larger organization, I think this communication tends to be harder because

1) It is often indirect -- multiple hops from individual contributor to CxO.

2) The communication that can possibly happen grows with the size of the organization.

3) People work on things that are more and more delegated. So the day-to-day problems of an accounts admin are very different from the day-to-day problems of the CFO. So the gap of "understand each others' perspectives" becomes wider and harder to jump.

All this doesn't diminish a leaders' responsibility: it raises it. But it also makes it that much harder to execute if the signals from people in the org are hard to interpret.

> A series of easily-digestible info-graphics

Are nice, but "I've noticed a serious problem. Here is a 30 minute screen-capture of it." is faster to produce and send to a direct manager and then you can (ideally) collaborate on how to raise that to the wider business.

------------------

All this comes with the caveat that I'm an individual-contributor-level software engineer who has never managed a team for an endeavor more complex than a care-package-drive... and I might in fact be far enough on the autistic spectrum that I massively misunderstand how any of this works. (See other comment)

I had assumed that this was an expression of some (unknown) level of difficulty, and that if we could shift the discussion to describing that realities of that difficulty and its impacts on business operations and morale, we could get some insight.

But am I wrong?

This is the first time I've heard about "literally shooting knives and...gouging out eyes" in an IT discussion. Is this actually a thing that results from IT procurement in a literal sense? By "literal" I mean the sense that would refer to a piece of material entering the eye-goo of another human being and causing actual pain and hospitalization.

Does anyone else find it very difficult to understand situations when you are not sure at all how seriously to interpret someone? I'm aware I'm probably on the autistic spectrum...but since we're having a discussion about engineering or technology procurement, could I ask for a bit of specificity?

Is it odd to find the idea of literal eye-gouging to be out-of-place here? That it seems really extreme and like a very black-and-white way to talk about problems? Or am I just losing my mind?

Genuine question: Does my difficulty with understanding the role of literal eye-gouging in IT procurement and UX design signal that I'm becoming unhinged from reality?

I just rolled with it because it was GGP's example.

They made a hyperbolic comment (“literally shooting out knives”) and you’ve focused on dissecting it and accused them of using inaccurate language. Of course they’re just exaggerating when they said that even if people were losing eyes management wouldn’t care.

You switched to first person (“how can I know...”) representing the boss. This not-so-subtly puts you above the person you’re responding to.

Copy-pasting a definition comes off as pedantic.

Finally, no-one asked for an enumerated lecture on how they should be behaving.

hmmmm... I had tried to convey "hey, not being listened to really sucks" but now that I re-read "That lack of weight given to your experience as a signal of real business cost is a real problem." that's a pretty damn sterile way to express that. Also you're right that it should come first before the "here is this other perspective you should consider" bit.

> You switched to first person (“how can I know...”) representing the boss. This not-so-subtly puts you above the person you’re responding to.

hmmmm... really I hadn't considered that. My goal had been to suggest seeing things from the leader's perspective because they have a goal of changing leader's mind. But now that you point this out, I can see how this also creates a pompous framing.

Thank you, thats helpful to know to watch out for.

--------

> enumerated lecture

By this do you mean I was overly verbose? Or that having things in numbers comes off as...professorially pompous? Or both?

> no-one asked for ... how they should be behaving.

So I had interpreted the comment as a combination of an emotional vent but also a request for advice, particularly the "I'm unsure how to solve it. What do we do..."

Is this unreasonable?

---------

> They made a hyperbolic comment ("literally shooting knives")

> Copy-pasting a definition comes off as pedantic.

> Of course they’re just exaggerating

I... I guess I'm really struggling to cope with the loss of a word which is so dear to me and my ability to bridge gaps of understanding with my fellow human. Like, if the word "literally" no longer means.... _____

...I don't even know how to express the concept without a verbose and phrase like "a way of speaking that is completely accurate and unexaggerated." that would overtax the patience of anyone. Take that away and...as far as I can see whole swaths of meaning about the world that I'd want to express are silenced. And I let the emotion of that get away with me.

The word is dying.

And if it affects me so deeply, I should not rage against the dying of its light but actually find a way to properly grieve it on its way.

But there's a subtle difference here in how they used it. They said "even if the UX is ... 'the software literally shoots knives'".

They're speaking in hyperbole, not metaphor. So "literal" is somewhat appropriate. They're not directly saying that their boss wouldn't care about a bad UI. They're exaggeratedly saying that their boss wouldn't care about literal injury.

Hmmmm... I'll chew on that for quite a while...

The actual issue the parent argument is about managing diversity - and that you can never please everyone - and that isn't a pistols at dawn kind of situation.

Sorry, I've seen exactly that pattern happen in my (still) current company and it just leads to teams that are completely unable to think for themselves and work like machines in a cog.

I'm not saying company guidelines shouldn't exist or that you should allow a proliferation of 200 different programming languages, but I have never seen the "devs are stupid" approach work; if this is indeed a problem in your org, hire better people! (Which doesn't mean: smarter hackers. It means: responsible, professional individuals that work well together in a highly effective team and can be trusted to make decisions in the best interest of the product.)

- In orgs that don't trust dev typically have significantly less understanding of dev, and in my experience have really poor security postures. Everything is a slow manual process decided by people who don't understand apps or automation.

- In orgs that trust dev too much, you usually get a federated architecture that doesn't make any sense from a strategy point of you. Some teams are great; others don't have basic controls. You typically have a bunch of different consultancies playing land and expand and selling expensive solutions that don't actually work.

As usual, the sweet spot is probably somewhere in the middle.

Finding the balance is key.

They're smart when discussing code complexity, callbacks, functions, APIs and the like. I've seen this time and again where many devs would get together to flesh out a chunk of a project and work together rapidly for the best way forward, along with nearly all edge cases. This is not simple or stupid in any sense of the words.

However they are also stupid when it comes to a larger view of what they work on. Perhaps myopic is a better term. I've seen devs write code expecting a database server has commodity access to the internet. I've seen devs include untested, unpatchable by WSUS software in generated system images. I've seen devs not give a second thought about logging, monitoring, error handling and more sysad level things, as it was outside of scope.

I trust devs in their domain, which is a narrow view of code. They've demonstrated they cannot be trusted with systems.

But yeah, I think that as an industry we overemphasise (both in hiring and in our weird pseudo-meritocratic community) raw coding skills and underemphasise big picture thinking, communication, collaboration, etc.

Conversely, if you are a developer and you have time to be shopping for video conferencing solutions, what’s the point in having you?

I am often forced to spend a ton of time dealing with tools that don’t work. At my company a lot of meetings start with 10 minutes trying to make the phone conference work. So it’s good use of time to look for tools that work.

Same with Jira. IT bought it and promised to customize it but the last three years they haven’t done anything. so we are now setting it up ourselves. it’s not what we want to do but still the most efficient way to allow us to work.

I don’t know how buying decisions get made but I am pretty sure that user satisfaction is on the lower end of factors that get considered.

I have been making the same "joke" for years on calls that everyone on the call should join me in quitting our jobs to create a teleconference solution that works. Hardyharhar.

(The practical solution for teleconferencing issues is to get people to join a couple minutes early)

I wouldn't discount the parent's post so quickly.

If everybody has to join early, then "early" is the new "on time". It's just sacrificing a different n minutes for setup issues.

Similarly, I've seen a few companies where it's just assumed that a 9:00 meeting really starts at 9:05, so everybody has time to travel from their last meeting. I think the videoconference nonsense is effectively the same. It doesn't really matter if you designate 8:57-9:00 as your "make sure your tools work" time or 9:00-9:03. It just matters that everybody has the same expectation.

Right now we are using MS Teams which so far has been reliable. I am just waiting for the day when it becomes flaky too.

You are most certainly not alone. In one Joshua Fluke's video, he accurately describes the feeling [1].

1. https://www.youtube.com/watch?v=ELrQyUIQkiY#t=7m55s

They have a point, the more things you need a client to do out of the ordinary the more friction you will get selling them. New UI for them to figure out, new permissions, etc. Depending on your business model as a startup that can be a bad thing.

It seems like you try to enforce a rigid structure but don't provide a quick process to changing or appending to that structure. So intelligent people work around your structure and you have no idea. Seen it at many companies. Generally tied to an inability or in-desire to delegate decision making. Which is different than letting people make decisions, rather it involves creating a structure under which they can make decisions.

Employees have the most view into what would make their job more efficient or engaging. You want them to think of optimizations and you want them to feel engaged enough to try and improve the business. If you don't listen then they will work around you rather than with you. Or just find another job.

Employees want something? Delegate to them the responsibility of building a business case and give them a structure on what that needs to look like. Then they can present it and the team can discuss. Make sure to say yes sometimes even if you think it's sub-optimal since otherwise they'll feel it's a pointless process.

Employees in aggregate know the true answers to those things. Employees individually sometimes do, but often do not. For example, if you have a stone-aged development process on an ancient revision of an unsupported language, and you poll your employees, they'll all want change. They'll all want ... different changes/processes/pet programming languages, too.

Seen another way, as a manager who is not involved in the day to day you don’t deal with the same problems that they do. Quite presumptive of you to think that you know what will solve their problems.

Or in other words, rather than doing all the cost-benefit analysis yourself you teach other people to do it. That way in the future they can just do it and you can review.

edit: It's the difference between seeing your employees as toddlers versus intelligent individuals no different from yourself.

Lots of "Lets move X to Y" which never gets completed then someone addes "Z" and now you have 3 ways of doing basically everything.

Worse is our documentation (which is generally good) frequently documents X but not Y or Z because the person who decided on Y or Z didn't look.

It's mentally fatiguing, I feel like every choice on what to use comes with more trade-offs than I should have to consider for something so simple.

Video conferencing is a good example, We variously have Hangouts, Skype and others, teleconferencing equipment in one room is one thing, in another something else.

The only reliable way to throw video to a screen is a USB-C to HDMI cable I keep in my rucksack.

Feels like half my decisions are saying "No" to an engineer who wants to replace Foo with a very shiny but 99% identical and unknown Bar.

I'm not against new technology but so many people want to adopt new technology X just for the sake of it being new technology X. I see this on developer teams I work with every day and it makes me want to gouge my eyes out sometimes, especially when I end up being forced to use their nonsensical choice of new technology X which makes my life harder.

Part of the problem I believe is that everyone is focusing on their own self-interest. Many developers for the most part don't care much about the business interests/growth. They're already looking for their next higher paying gig and want paid training in technology X at their current gig. Since many businesses provide little concern for long term talent retition, loyalty or investing in professional development that falls outside their business adopted technology preview, I completely understand the developers choosing themselves over the business. At the same time, going overboard shoots yourself in the foot because it strangles the business in the process.

There certainly needs to be a balance and a lot could be gained by giving developers freetime and resources for continued professional development.

At my very large company, in my particular department, any one trouble ticket may bounce between

(1) a Java ticketing app (2) a web/email ticketing system (3) a Jira issue, or (4) a Gitlab issue, or (5) a company-wide issue tracker

Other groups (e.g., customer service) have their own, completely separate systems besides the above.

Some development tasks are tracked with an issue tracker. Others are planned out in Confluence or Jira, per the whims of each team. We have literally 5 different chat "solutions," with various factions preferring each. Every day it seems someone brings online yet another script that sends out helpful emails. My count is around 16k since Jan 1.

The result of all of this is a sprawling, utterly insane flood of useless noise that everyone ignores.

That's quite progressive! Last I checked, many of our monitors only supported DVI and DP, and only some recently bought laptops have USB-C.

Can’t complain about that though moving from Linux after two decades to OS X was a bit of a change.

When I hear NetSuite ads, it's only while listening to the absolute dumbest sports talk shows. Apparently this marketing works...

Contrary to what people might think, companies are not ran as military with the CEO being a commander-in-chief. In most of the companies, members of the C-suite have a certain or total autonomy to make any decisions that they want as long as it is somewhat within their domain. The conflicts between them are resolved via negotiation and horse trading. Just because the CIO does not like what the CFO is doing, does not mean that the CFO is wrong in making that decision, same as just because the CFO does not like what the CIO is doing does not mean that the CIO is wrong. When one CxO steps on feet of another CxO it is either resolved by reaching a new agreement going forward or resolution is punted into the future or one of the CxOs leaves.

If your company really does have a purchasing proces so rigorous that it will reject an "IT" contract signed by the CFO despite it being within their purchasing limit, then there's a reason for that. The reason typically being that in the past there was enough naughtiness by some CxO that they went to all the trouble of putting some heavy bondage into their purchasing rules.

Also, I would be willing to make a cash-money bet that CxOs shopping outside their domain authority don't get immediately fired for that. Even at your company.

I can't help but think this is a symptom of being awash with VC cash - I can't imagine this happening in a bootstrapped business.

This is only true in the evolutionary sense -- Example: "parachuting forces people to be good at checking their gear."

Telling someone that they are going to jump out of a plane won't magically give them a skill like meticulousness.

If you have the basics already, so, bootstrapping forces you to build up that. No guarantees, so.

At a smaller company that values its devs, there hopefully shouldn't be too much ceremony around this, unless it's a particularly large spend.

But at larger companies, yes, you're likely going to have to know how to make your case in a more formal way, and get involved in company politics (ugh).

And there should be a good guide for junior devs on how to do that "justify it" step well in startups. Sounds like something that could piggyback off of https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...

in our case, UC constantly failed hard to properly encode an essentially static excel sheet over screen share - jpeg artifacts the size of basketballs that never went away, even when given infinite time to "catch up". zoom has zero issues with screen share, but randomly drops calls, and yeah the phone + 9 digit id + participant id feels intentionally user-hostile (especially having to repeat that bs again after a dropped call).

This should be very similar to a code review, but seen by CTO, CIO, and CEO (whichever combination is most relevant) so that big unexpected, costly structural changes don't cost long term disfunction and pain.

This was the case at an engineering company I worked with for several years.

The committee, or "enterprise architects" as they called themselves, became too far removed from the trenches, and the devs viewed them as sitting in an ivory tower and passing down ridiculous decrees.

They brought this view upon themselves, as they made it more or less impossible to even speak to them - almost all communication was through requests and forms uploaded to a sharepoint site!

They kept taking it further and further, until you even needed their permission to take a dependency on a 3rd party library for a LoB app. Such requests would sometimes take weeks to get a response.

We could never hold on to devs for long, in large part because they hated working under this bureaucratic nightmare.

The committee made all sorts of terrible decisions, always without consulting the devs and always with little justification, and these had a lasting impact for years to come.

Gods, it was horrible!

it's senior managements job to make sure the dev leads are working well

Basically this is senior / middle management in every company

you had senior management that have not realised the importance of software to their business - so they let a situation develop they would never allow in sales or accounts

IME, this right here should have seen the entire committee fired.

Thankfully it's a lot nicer these days - but I still wouldn't use it as a platform on which to build a web app (yes, we were forced, under great duress to do that - and the result was as awful as you'd expect).

I've worked for companies that operated on very lean budgets. Everybody in the organisation knew what it was, it wasn't much fun but it was a clear policy.

There is no reason you can't do the same here, the objectives might be different but unless people up and down the organisation know what they are you can't expect anything other than anarchy.

Eventually we moved to webex, not because it's the best (it's not), not because it's the cheapest (it's not), but because many corporate customers seems to use it internally, and because it's what just about all corporate customers seem to expect.

Love the quote

It sounds like a toxic mess.

> It’s because no matter how smart you folks are as individuals, in the aggregate you are like toddlers. You dump all your toys on the floor and then chase after some other kid’s shinier toy. Your poor CIO is left cleaning up your mess in the middle of the night after stepping on a Lego brick.

Viewing your underlings as toddlers probably isn't helping matters much. Everyone has very specific needs. They are interested in meeting their needs and need to make local decisions that look dumb from high level. Aka greedy choices.

Its a bit academic, but "Cognitive Structure of Emotions", Ortony might help you break down some of the people issues in your org.

There is a balance. How do you give lower parts of your organization autonomy to make local decisions and at the same time make choices that are sane from a higher level. 40-50 people is typically a tipping point for human social structure. This is where tribal systems break down and require a strong leader and more well defined roles.

Aside: can I ask for some advice on software requirements? We’re designing our solution to meet IT requirements and want to get under the skin of CIO concerns.

Going to leave these to consider: (guess from which book)

1 - Processes are supposed to protect people from Distractions and help them deliver their core objectives.

2 - IT is not merely a department, it is pervasive like electricity.

3 - In order to survive, the business and IT can’t make decisions exclusive of each other.

(IT = centralized function; "business" = functions being supported, including devs)

Or maybe you are biased to go against change because it just annoys you.

You made my day. Quote of the year so far!

Seriously, you shouldn't be making technical choices for professional developers as CIO unless you are writing code as one of them. If you think they are like toddlers, your hiring is already busted. More seriously, CIO is a pointless title no one really knows why it exists. Even more seriously, startup shouldn't be having "IT department". If you do, you are already Walmart at that point, not Amazon.

That's a great line, and it's only funny because it's true.

This is not a operating mode I’d encourage but I’ve encountered it in companies in the past.

After all it's the "approved" solution around here.

My condolences.

Oh man, respect for putting up with and handling all of that. Those choices don't sound "individually smart" either though... There seems to be a lot of pretty straightforward Dunning-Kruger going on.

One funny story was how whenever we'd be burning the midnight oil to produce the final release, we'd declare it the golden master and hand it over to our shipping department to distribute to our customers. One time I had to make a recall due to a fatal bug. The masters were handed back to me with a smile and when I asked, she said that after the last few recalls of golden masters, she always let them sit on a shelf for a week before actually shipping anything.

I actively resist the notion that 'everyone but me is stupid' and propose a more realipolitik explanation: it's because power and budget. in manager heads, if you pick solution A I pick solution B, so that higher ups don't see the same line twice in services costs and get the idea they can obtain savings by merging the two functions, making one of us redundant.

yep yep didn't expect anything different from a techie community.