[0xfffafaCrash]

One thing that’s interesting today is how in the corporate world, even in big tech companies where one might naively think black triangles with explanations might be appreciated by more technically literate managers, working on these sorts of building blocks for big wins will often actually result in projects and teams getting axed. I’ve seen serious attempts at innovation get thrown out the window a number of times in favor of shiny demo projects that demo well but can never go much further. Black triangle projects require time investments that at least big companies only rarely bet on despite being in possibly the best position to do so.

I think a part of it is that humans, or at least those that make their way into management, are in large part very visual creatures. If you can’t show them progress in a traditional visual way you sort of have to figure out some contortion to show some visual thing to use as a proxy of progress to keep the faith. Sometimes it can be achieved through selling some abstract progress metrics about work remaining (most often entirely detached from reality) but that only works so long.

More often you end up knowingly spending a large percentage of resources on vacuous side projects solely because they demo well to management in the short term — it’s a distraction but a way to keep the faith and the resources. I find it funny how much time and energy we’re willing to waste to play the game — paying the souped up visual taxes for decision makers, while doing the real work independently, often in the dark because we know management will react short sightedly to the black triangles.

[JohnBooty]

     working on these sorts of building blocks for big 
     wins will often actually result in projects and teams 
     getting axed.

Had this experience at a previous position. My predecessor had implemented a solution that was extremely hairy, and took many hours to run in production.

My manager (a software engineer himself, still involved in day-to-day engineering on this product) said that it couldn't be meaningfully bettered. But in the meantime, we were taking a beating from our primary customer upon whom we depended for ~75% of our revenue. I viewed this existing solution as a potential company-killer.

So I spent some nights and weekends hacking together an alternative. Got the run time down from several hours to thirty seconds using some basic caching and a basic tree structure... not exactly advanced black magic. It also required about 50% less code.

I excitedly showed it to my manager. I walked him through the code. He became angry for the following "reasons."

1. Instead of making the code smaller, he felt it made the code larger. This is because he failed to comprehend that my MVP "hey this is possible" prototype didn't actually remove the old solution. It was just an MVP! I explained this to him but apparently it didn't take.

2. He couldn't understand the underlying concept. Again, it was... a tree. Something you would encounter in a 200-level computer science course, at the very latest.

3. My code lacked tests. Again... this was a "nights and weekends" MVP.

Probably the single fucking stupidest moment in the history of my career. I am not a person who typically has communication issues with managers or coworkers. I was dumbfounded that he was dumbfounded and to this day I am absolutely baffled by this whole incident. Our relationship had been deteriorating somewhat but not to the extent that would explain his brain-dead and hostile response.

Unsurprisingly this lead to my departure from the company.

[jiggawatts]

> said that it couldn't be meaningfully bettered

There’s the problem!

I’ve had this experience many times — people will internalise their limitations and assume that their best is the best possible. Etc..

When a junior employee just casually proves them wrong, calling the emperor naked, that makes them feel inadequate and even ashamed.

I’ve been involved in many similar scenarios. Often there is a history of meetings, consultants, vendor techs, etc… trying to fix the problem and then a grudging acceptance and business workarounds. To suddenly reveal all of that as a lie is to undo established history. It’s like trying to close down the Vatican and tell all the priests to go home because you found a “neat proof” that there is no God. To say that you’ll experience some disbelief and resistance to your ideas is an understatement!

I had one of these moments where I got a nightly report batch job down from 3 hours to about 5 seconds. The customer turned red in the face, screamed at me, accused me of lying and stormed out of the meeting room.

Turns out that guy had to stay back each night to make sure the job ran successfully and so that he could sign the print out officially. He’d accepted the impact on his personal life, after many arguments about his work hours with his wife, etc…

To have all that sacrifice and suffering instantly made superfluous!? Ouch.

[JohnBooty]

    I’ve had this experience many times — people will
    internalise their limitations and assume that their 
    best is the best possible. Etc..

Man, yeah. I've never found a way to really do this well.

The closest I've come to a winning formula here is to

1. Build a relationship where you have given praise and positive feedback to the individual's other efforts, privately and publicly. To be 100% clear here I'm talking legitimate praise here, not butt-kissing.

2. Find a way for the "victim" to share in your achievement somehow. Help him save face. "Bob and I were looking at ways to optimize the batch job etc etc, and we found a way... etc etc." People who know you and "Bob" will understand who really did the work.

That said, I would say my success at this sort of thing has been pretty low (although I am on a positive winning streak of one positive outcome in a row...)

    He’d accepted the impact on his personal life, after 
    many arguments about his work hours with his wife, etc…

Oh jeez. The... the pathos here is overwhelming.

[jiggawatts]

Generally I've found that there is no easy way to call someone's baby ugly. Sometimes it is best to just say it outright, other times you have to skirt around the issue, or just let them come to the conclusion themselves when you demonstrate a fix to an "unrelated" issue that just so happens to be relevant to their problem.

> Oh jeez. The... the pathos here is overwhelming.

A landmine I've stepped on multiple times is that this type of scenario is sometimes not tragic, but actually a form of soft corruption: after hours work gets overtime pay! "Fixing" these issues can cut into people's salaries very significantly, perhaps reducing their pay to less than half. They're obviously going to fight you every step of the way, without ever saying the real reason for why they're really opposed to your helpful suggestions.

[JohnBooty]

Oh geez, that unhappy guy was getting OT pay? yeah that explains a lot!!

Great points all around

[ryandrake]

I've worked in places where management understood the idea of laying a foundation, and building up the abstractions and information architecture, and understood that the result of the first 50% of the project could be a single text log showing all the data paths working, but those companies are rare. Most places are like you said: they won't believe any work is happening until they are bamboozled by a visual demo of the software--and they think it's "close to done" when the visual demo matches what they think the software should eventually look like. That's why so many places ship unfinished demo-ware: Engineering shows off the proof of concept that only scales to 10 customers and doesn't actually write to the database, and then management demands they ship it because it looks done and the deadline is coming up.

I wish I could figure out, as a candidate, a good question to ask in order to suss out which kind of company is interviewing me.

[drc500free]

This is the most important bit, to me:

> By the end of the day, we had complete models on the screen, manipulating them with the controllers. Within a week, we had an environment to move the model through.

The Black Triangle was a leading indicator of a payoff that began happening by the end of the day. Too many similar projects result in a constant string of promises that we are just about to turn the corner on velocity/capability if only we would let the engineers focus on this refactor for a bit longer.

In practice, "Black Triangles" projects are bets like any other. If they work out, they unlock faster velocity and the ability to deliver better features. Often they deliver nothing but a refactor to someone's idea of a better architecture, and are lucky to ever reach breakeven on engineering time.

[winwang]

> One of the engine programmers tried to explain, but she shook her head and went back to her office.

...Maybe they shouldn't be making their way into managing engineering then?

To be fair, the lady in question, Jen, did come around in the next paragraph. However, it still highlights the extremely annoying problem of doing non-visual work under visual(-only) people -- one then has to actively create visuals.

This quote from Feynman expresses a similar idea: https://fs.blog/richard-feynman-on-beauty/

[filleduchaos]

> ...Maybe they shouldn't be making their way into managing engineering then?

...What part of being a financial controller and acting HR is "managing engineering"?

[jiggawatts]

I learned a lesson early on in my career: never show a functional but ugly demo.

I once worked for months on a modern front-end for an incredibly old legacy system. This was so technically challenging that we weren’t sure if it could be done at all, so a functioning demo was a huge achievement.

What the customer saw was that it was ugly: black and white, plain text, no CSS, no styling of any kind.

They completely ignored the technical milestone and spent an hour asking if we could rearrange the buttons and change the colours. Bike shedding, in other words.

Since then I would much rather show something that’s very pretty but completely broken.

[recursive]

In my experience, maybe half of "foundation" or "infrastructure" work is actually bullshit. That's probably why it's not a carte blanche to just do whatever with nothing to show for it until "later".