[HN Gopher] I Failed to Transform the Enterprise
___________________________________________________________________
I Failed to Transform the Enterprise
Author : anonyfox
Score : 93 points
Date : 2021-09-17 12:11 UTC (10 hours ago)
(HTM) web link (anonyfox.com)
(TXT) w3m dump (anonyfox.com)
| SuoDuanDao wrote:
| Wow, that sounds frustrating. I'm curious what the company was,
| sounds like a place to avoid.
| antoineMoPa wrote:
| Based on his CV, probably Aida.de:
|
| https://anonyfox.com/cv
| michaelcampbell wrote:
| > The problem: to achieve the desired level of UX, we needed to
| convince stakeholders that a single-page-app approach would be
| needed, including some APIs to fuel them.
|
| I'd wager a SPA is a hammer/nail reaction here.
| anyonecancode wrote:
| At one job I ran into this pretty badly. The team I joined had
| an internal app that was, basically, a bunch of forms connected
| to a database. It had a lot of problems -- the data models
| didn't actually map to what the business needed, the UI was
| unintuitive. My manager insisted that what we needed to do was
| rewrite the entire thing as a React SPA. I told him, well,
| we're just going to end up with the exact same problems, only
| now implemented in a different framework. This won't solve any
| of the actual problems. He insisted, though, saying that React
| was "modern."
|
| Thankfully, the depth of mismanagement here was pretty
| exceptional in my experience. In most cases, even if I'm
| personally skeptical of the need for an SPA I can see a
| reasonable argument in favor. The cartoonish straight out
| admitting that the sole purpose was to be more "modern" with
| literally zero regard for actually serving any user needs is
| thankfully not something I've run across too often.
| wayoutthere wrote:
| There was an article earlier this week about why every engineer
| should do a stint in consulting.
|
| This is why.
|
| The reason companies like this use consulting companies is
| because the VPs _want_ total control. Internal IT is purely a
| cost center, and unless your company (read: the business) is
| already on board with the product lifecycle op model, there is no
| point in trying to do any of this from within IT. Consultants
| work at the VP level and in a large enough company, we find a
| technical area (usually data as it has the biggest business
| returns) to modernize, then leverage success there build out the
| business case for the rest of the company (data is a good place
| to start building API gateways). And selfishly, the business is
| willing to pay higher hourly rates than internal IT (which we
| generally leave to the offshore MSPs).
|
| When I sell transformational solutions to a company, I know it
| won't be successful without top-down buy-in. Consultants are also
| better positioned to do these transformations because we do them
| all the time; and the exercises around stakeholder management and
| consensus building are extremely important. They're the kinds of
| things internal teams are never resourced or trained for, and
| they don't happen quickly.
| htrp wrote:
| The problem in consulting is that you almost always end up in
| an internal turf war. As mercs, you can pack up and leave once
| the paycheck runs out.....
| jf22 wrote:
| > So while many team members were arguing about theoretical
| things, I onboarded important developers on to the new system and
| they were productive refactoring the old things we produced into
| the new technology stack.
|
| I question the wisdom of somebody who started refactoring and
| replacing systems right after massive layoffs in an industry that
| was crippled by the pandemic.
|
| Businesses in survival mode can't spend resources like this. The
| author points out the executives became enraged when the found
| this out and I agree with the executives.
| lowercased wrote:
| And... when everything failed _except_ the new system, which
| seemed to keep the company operational _despite_ the executives
| ' views... you still agree with them?
|
| You agree with their 'enraged' state? You think it was
| justified? Even with hindsight, or just at that moment in time?
| marcosdumay wrote:
| Depends on the project size and the details of the company
| risk.
|
| As a rule, when things are broken it's the best time to go out
| fixing them. But yeah, this has a non-zero cost that maybe can
| destroy the company.
| andix wrote:
| The pandemic was also a chance to implement new stuff, as there
| was anyway no real revenue generated. Everything was chaotic,
| so if you made mistakes you could just brush them off with
| "because of covid".
| wsc981 wrote:
| _> I question the wisdom of somebody who started refactoring
| and replacing systems right after massive layoffs in an
| industry that was crippled by the pandemic._
|
| Well wisdom is gained from experience and it seems the author
| learned a few lessons.
| Gunax wrote:
| Where's the ceo and board in all of this. Someone must actually
| care about the bottom line.
| Aeolun wrote:
| This is such a pain in the ass. You'd think that just providing a
| better solution would make people happy, but noooo.
|
| Do not encroach upon my power, you cretin! It doesn't matter if
| the business dies because of my stupidity, as long as I go down
| captain of this ship!
| wsc981 wrote:
| Just from the point of view of some manager: perhaps worked
| many years at a company with the ultimate goal of entering
| C-suite. Maybe gave up other good opportunities for this goal.
| In such situations it must suck a lot to see your power and
| influence wane. You might have made many sacrifices and then
| someone starts some projects that could ruin everything you
| worked so hard for.
| bmeski wrote:
| Then learn to code.
|
| Edit: It's a legitimate solution. I've survived 3 reorgs at
| my company because I could code. I read up on the new
| incoming system and became effective.
| [deleted]
| MattGaiser wrote:
| I think a lot of it is that managers aren't really the captain,
| or at least lack the same expectations. They are more a
| contracted operations manager who can hop in a lifeboat first
| or can get paid more steadily if the ship runs aground and
| therefore they are more needed to clean up the mess.
| fridif wrote:
| I've been both in-house and consultant to a variety of big corps
| in a variety of industries, and I can say that invariably every
| single one is messed up and inefficient.
|
| Yet still somehow customers buy the products and (more often than
| not) the company delivers a product that is half working enough
| to be tolerated and used.
| jmull wrote:
| Meh. When it seems like everyone is stupid but you... you are
| probably the one who is on the wrong track.
|
| This is all very vague, so who knows.
|
| But at the very least, I would guess the OP's attitude of I-know-
| better-than-everything-that-came-before arrogance plus ignorance
| of why things were the way they were made big failures
| inevitable.
|
| It's a real limitation -- though a common one -- to need everyone
| to see things from your perspective, rather than being able to
| understand their perspective.
| ask_b123 wrote:
| So, if I'm understanding correctly, the author used Lisp in this
| story?
| htrp wrote:
| I think it's more related to the language power continuum....
| he was probably coding in a "more powerful language" while the
| rest of the org was coding in a less powerful one.
|
| If I had to guess Rust vs Java/C/Perl?
| tartoran wrote:
| I figure you've changed tabs and read a different story. No
| mentions of Lisp here
| Floegipoky wrote:
| The article mentions Phoenix, so probably Elixir.
| reilly3000 wrote:
| One thing that vendors have that internal teams don't is million
| dollar marketing budgets. Selling the sizzle of successful
| internal projects is its own kind if work, but if neglected even
| the greatest of projects will succumb to the onslaught of
| vendors. Good technical leaders recognize this inherently and
| celebrate their teams creations, non-technical leaders don't and
| take pride in buying from big brands and the fancy luncheons that
| come along with them.
| netcan wrote:
| Underrated comment.
|
| If you break down what most vendors and consultants do, in
| terms of either dollars or hours, you'll usually find that they
| mostly do sales, PR, client relationship, etc. Projects are
| designed and managed to make the right people look good to the
| right people, manage expectations, etc.
|
| They'll spend massive time giving non-tech executive buyers
| easy, fun choices.. let them feel strategic, visionary and
| empowered. They'll communicate the hell out of every piece of
| progress. Whoever hired them also has a massive incentive to
| buy into and sell onwards, that the project is a massive
| success.
|
| IE... if your job is to make a clients' Salesforce instance do
| a thing, 80% you your job is stuff other than making a clients'
| Salesforce instance do the thing.
|
| Internal dev teams will rarely have this pageantry. Meanwhile,
| no one outside that team knows what they do, how well they do
| it or such.
| ed_elliott_asc wrote:
| This is one of the most insightful things I have ever read on
| HN.
| jollybean wrote:
| If you want the 'aha' moment have a look at most software
| vendors incomes statements.
|
| They spend 2x more on selling than they do on R&D.
|
| So when that Oracle Sales Guy is giving you the pretty talk,
| and taking you to lunch remember that all that money your
| sending to Oracle is literally mostly going to him! The
| product makers just get 'a cut'.
|
| Now consider how much of high tech is just that, sales and
| marketing, conferences and luncheons.
|
| That's a staggering waste for a developed economy.
|
| We are very inefficient with these things, we need better
| approach to IT.
| agomez314 wrote:
| this link is returning me a 404
| ask_b123 wrote:
| https://archive.is/brKSf
| michaelcampbell wrote:
| Working fine for me.
| agomez314 wrote:
| working now for me!
| yardie wrote:
| > Big solutions to the big problems. Exactly what consultancies
| sell. It was obvious to them that having any inhouse-developers
| is the biggest business risk at all.
|
| I will never, ever, ever, do in-house software development ever
| again. Non-software companies treat their inhouse developers like
| crap. They don't get it. I don't know when non-software
| businesses thought it was a good idea to move software developers
| in house. Most of the company don't want them there. Or deal with
| them begrudgingly. It's hard to quantify their revenue so they
| are treated as an expense not cost saving or revenue generating.
| And they are the first on the chopping block when things turn
| down.
|
| In my experience, if you are recruited by a company that doesn't
| sell software or software services you should tread very
| carefully, ask lots of questions. Sometimes you'll find out a 100
| year old furniture company only has a dev team because the
| grandson thought it was a good idea. And then you run very far
| away.
| Waterluvian wrote:
| My company sells robots, not software, and treats us like
| royalty. Perhaps "tech companies" fall under the umbrella and
| I'm just misreading you?
|
| Edit: I'm confused then: if robots have software therefore it's
| a software company, then tons of companies are software
| companies. But so many of those products, the software is just
| a hidden detail that no customer ever thinks about or cares
| about. Where do you draw the line?
| gostsamo wrote:
| Software company here means somewhere where the software is
| part of the product, not part of the facilities.
| jjav wrote:
| It easily gets tricky though.
|
| By that definition google is not a tech company, their
| product is selling advertising space. Tech backend just
| enables that.
|
| Or Netflix. Certainly not selling tech or software, they
| rent movies.
| gostsamo wrote:
| Both Google and Netflix have unique software products
| that make their main business functional. I've worked on
| internal projects and the difference in management
| attitude toward them and the real product is rather
| palpable.
| xondono wrote:
| Any company that builds physical products that require
| programming (either firmware or software), is a software
| company.
|
| For most companies building the physical product is a loss
| leader, what they're selling is their custom software.
| rjsw wrote:
| Some hardware companies expect the software people to work
| around the under-specification of the hardware that has
| already been designed and sold.
| leesalminen wrote:
| Robots require software to work, right? So you're officially
| part of the revenue generation chain.
| iamstupidsimple wrote:
| Yeah, it's about proximity to the core business. People
| usually don't join FAANG to be HR or lawyers, but
| developers. I'm sure it's the same at other places - why
| join a bank as a programmer, or a law firm as a designer?
| Go where you're valued.
| pjc50 wrote:
| Obviously you're a software company, you just happen to have
| to sell the platform for the software to run on as well.
|
| (There is an interesting discussion to be had about where the
| boundary between "software" and "hardware" companies is, but
| an environment with a high level of wilful misreading isn't
| one of them)
| yardie wrote:
| A robotics company is still a software company. Unless there
| is a human standing at a bank of switches directly
| controlling the robot. I'm talking about non-tech companies.
| The start a inhouse devteam when they really needed a
| consultant.
| infogulch wrote:
| "Sells robots with software on it" still counts. Here the
| software is part of the product, unlike a furniture store.
| AnIdiotOnTheNet wrote:
| By your definition a company that sells refrigerators could
| be considered a software company.
| ghaff wrote:
| There's a large class of products for which the software
| is essentially an after thought. And it shows.
|
| Appliances are an obvious example. But also things like
| cameras to a large degree. Or auto infotainment systems
| until Apple and Google software was integrated. (Embedded
| is sort of a different category that is functionally
| essentially part of the hardware.)
| detaro wrote:
| Ok, but for the article example of a travel booking
| company, you could easily argue the booking experience is
| part of the product.
| yardie wrote:
| Not the same thing. Robots are literally programmed to
| perform a task. A travel booking agency? I don't give a
| shit if it's AI or 1000 gnomes making hotel reservations.
| In the former the software is part of the product, the
| later travel is the product.
| FredPret wrote:
| Actually I might prefer the gnomes
| specialist wrote:
| Is your code somehow tied to revenue? Woot. If not, you're
| just overhead to the PHBs. No matter how much money you save,
| misery you prevent.
|
| So generally, IT vs product development.
|
| I have been on IT projects (internal development) tied to
| revenue. It was pretty sweet while it lasted.
| lumost wrote:
| The parent is likely referring to companies that needed a
| square space/Wordpress site and maybe a Shopify account but
| instead hires 3 scrum teams to build their e-commerce
| platform.
|
| The software output at such a company is confused at best.
| Usually with some exec pitching digital transformation
| without definition. No one wants to deal with the tech team,
| pay and expectations suck, getting hardware can be a years
| long process, and eventually someone pulls the plug.
| pc86 wrote:
| You mentioned pay, the pay at these places is terrible. I
| got an Engineering Manager offer for a company I worked
| with years and years ago, the top end of their budget was
| $90k. For the manager. Devs (there were _five_ ) were
| making $30-45k. At that level of pay you're simply not
| going to get good people. Even if you get one or two who
| are decent engineers, they're not sticking around when most
| of the team isn't that great. WLB is important but there
| are plenty of places paying $80-100k for mid-levels in
| LCOL/MCOL areas where a 40 hour week is the max.
| hyperpallium2 wrote:
| I think such companies will tend to be replaced by companies
| built around IT - because they can gain the benefits of
| software, of flexibility etc (compared with physical objects,
| anyway).
| dcchambers wrote:
| I think it comes down to if the company views your job as a
| _cost center_ or a _profit center_.
|
| Software developers at software companies/tech companies
| generate profits, so they are treated as such.
|
| Software developers at more "traditional" businesses (retail,
| industry, manufacturing, etc) are often seen as an expense and
| something that should be treated like any other expense - try
| to minimize it.
| dkarl wrote:
| Looking at the original article, it seems the author was
| working for a software company that was in denial about being a
| software company:
|
| > The amount of customization by far exceeded the initial
| offering of the services, and had to be done within the
| constraints of each individual technology stack. > > This
| accumulated in hundreds of partially overlapping systems, wired
| together with brittle ad-hoc integrations.
|
| They had a software solution and were officially spending zero
| dollars on software development. You can't beat that. Never
| mind the huge amounts of time they spent keeping it working.
| All of that money showed up in other places on the bottom line.
| Maybe a lot of it was IT, but a lot of the expense was probably
| people whose job title had nothing to do with technology
| spending hours doing repetitive and error-prone integration
| work with third-party systems, emailing around spreadsheets and
| CSV files, manually tracking down and fixing bad data, and
| answering the phone for confused customers. As soon as you
| start employing software developers to create a more efficient
| system, it looks like you're spending 100x more for software,
| on a trajectory to take a very, very long time to achieve
| parity with the existing system.
| ProAm wrote:
| > Big solutions to the big problems. Exactly what consultancies
| sell.
|
| The problem is most consultants are not good at what they do.
| It why the sales guys for the consulting company are not the
| devs. Most the time consultants come in for 3-6-12 months,
| cause some trouble and then just leave the mess to the company
| to address later. There are some good consultants but most are
| just people that couldn't work in house because they are not up
| to par for long term engagements of products that need to stand
| the test of time to add legitimate value.
|
| > It's hard to quantify their revenue so they are treated as an
| expense not cost saving or revenue generating.
|
| This depends on the business, most the time, unless you make
| software you are an expense. The company makes their money in
| different departments and making money is the name of the game.
| It's takes a different set of skills (albeit better/stronger,
| industry knowledge and communication skills) to be an in-house
| developer vs a contractor.
| alex_anglin wrote:
| >The company makes their money in different departments and
| making money is the name of the game.
|
| The challenge here is that under this model the different
| departments get credit for the revenue they generate. What
| their relationship is with the in-house dev team is very much
| something that one should be aware of if they choose to be in
| that situation. It's not too dissimilar a situation to every
| single 'change management' model that has executive
| commitment as the number one success factor.
| ProAm wrote:
| I agree. It's a different animal that being just a
| developer at a consultancy. You are supporting other
| departments to become successful. If you are undeniably
| helpful people/departments/executives will know that. I
| personally do not care for credit at all for tasks
| accomplished. It's always the journey I find more
| rewarding. Give me my salary, benefits, opportunities to
| grow, etc... and Im good, but I know not everyone is like
| that, especially users on HN.
| stronglikedan wrote:
| When I first got into manufacturing, I encountered this too,
| but I saw it as an opportunity. I was the sole (and first)
| developer when I came onboard, and within a few years, I had a
| team. A decade later, and the entire company depends on my team
| on a daily basis, because we've automated tasks and provided
| tools for every department. Not to mention that I've broken
| company records for salary increases on multiple occasions
| throughout my journey here. So, maybe it was a little more work
| for me to get them to "get it" with regards to software
| development, but I did it. That said, I do understand that not
| everyone wants to have to put in that extra work, but it does
| feel damn good if you do.
| haswell wrote:
| > _That said, I do understand that not everyone wants to have
| to put in that extra work, but it does feel damn good if you
| do._
|
| I do think this is valid, but feel I should add: that
| willingness needs to go both ways. You were willing to put in
| the extra work, and your employer was willing to "get it".
|
| There exist organizations that will never "get it" despite
| the extra work, and these are the places others are talking
| about when they say "run away".
|
| I experienced both variations of this earlier in my career. I
| was successful the first time, and tried to apply that
| success in a larger environment.
|
| The lack of organizational willingness to "get it" in that
| second environment is what motivated me to move to a place
| where building software is the primary reason for existence.
| I do not intend to look back.
| ed_elliott_asc wrote:
| This hasn't been my experience, I prefer working for non
| software companies tbh
| MattGaiser wrote:
| I was an in house dev and have friends that do it. Con is low
| pay. Pro is usually great WLB, as delays and confusion aren't
| up against a hard deadline.
| Razengan wrote:
| > _Sometimes you 'll find out a 100 year old furniture company
| only has a dev team because the grandson thought it was a good
| idea._
|
| /r/oddlyspecific :)
| vadfa wrote:
| I have been in the same boat. It wasn't 100 years old, and it
| wasn't a furniture company, but it ended exactly the way
| yardie described it :-) No one wants you there because they
| see you as a waste of money and a threat. A lesson to be
| learnt I guess.
| yardie wrote:
| Scene: Mid-city warehouse district. Me at job interview early
| 2000s.
|
| Me: So what is it you do here. The job description says you
| are looking for a developer?
|
| Them: Oh, we make and sell boxes.
|
| Me: Like the cardboard boxes you get delivered?
|
| Them: Yes, exactly!
|
| Me: Okay, so where does software fit in that? Are you aware
| of development cycles? {Other interview questions I can't
| remember}
|
| Them: Oh, we don't know the technical part too much. We want
| to automate some of it.
|
| Me: ...
| lowercased wrote:
| Reminded of a couple of projects:
|
| 1. I worked with a single internal guy to build a web-based
| ordering system, in the days where people faxed in orders. This
| replaced weeks of data entry, dozens of part time data entry
| people, and enabled a big change in materials ordering and
| production (orders were all in a database within a few hours, vs
| literally weeks of keyed-in faxes from before).
|
| The one guy that was in charge of all this suddenly had a lot
| more power internally, and it pissed off a lot of other folks who
| suddenly had less influence.
|
| 2. More recently, worked with a team of external contractors, and
| internal folks were resistant to help any of us set up external
| dev systems. They all worked in the physical offices, and had no
| need for 'run a dev system on a laptop'. One of our guys spent a
| lot of time (and kept getting chastised by the client's mgt) for
| getting and documenting a build process for external contractors
| to use. The pandemic hits, office buildings are shut down, and
| internal folks have a much harder time figuring out... how to do
| anything from home.
|
| In both cases, under-the-radar skunkworks projects ended up
| having large (and in one case transformative) impact and value,
| but were ignored or fought by those with entrenched power.
| sergius wrote:
| A case of 'Innovator's Dilemma' perhaps?
| specialist wrote:
| > _...fought by those with entrenched power._
|
| For decades now, per Alistair Cockburn, I assumed people just
| really, really hate change.
|
| There's some research which shows our selfish little brains
| have an immunological type reaction to change. Anything that
| threatens our internal stable equilibrium is squashed like an
| invader. No matter how much we say we want to change. No matter
| how much we may need to change.
|
| While wholly correct, turns out Cockburn was an optimist.
|
| We now know that some fraction of people would rather watch the
| whole world burn than give up one iota of power.
| sqldba wrote:
| So true. Seen situations so much like this.
| SPBS wrote:
| > And then the obvious thing happened: a complete breakdown of
| all important systems, like a house of cards. And: most vendors
| were not working due to lockdowns or other important issues
| during the pandemic.
|
| > The only system not affected by the complete meltdown was: our
| new one, which was designed to withstand outages from backend
| systems below.
|
| I don't understand, how can their SPA frontend still be
| functional when the backend is totally down? You can display
| things to the user, but you cannot do anything meaningful from
| it?
| w0mbat wrote:
| I was expecting a Star Trek article and am very disappointed.
| darkerside wrote:
| Interesting tone. The tone says, all these people are idiots, and
| they failed to understand my beautiful creations.
|
| But he then outlines all his failings at the bottom, which I
| agree with, so he clearly knows better. It's it possible that
| this tone deaf attitude was a primary culprit in the downfall of
| the organization he and his handpicked successor built?
| marcinzm wrote:
| You can't build something in a vacuum when there's other people
| with power in the organization. You need to treat the system as
| a whole including the politics involved. Sometimes that mean a
| less optimal solution to gain some influence with key
| stakeholders.
|
| This is one reason technologists can make bad managers. They
| don't think about the politics or don't want to play it.
___________________________________________________________________
(page generated 2021-09-17 23:01 UTC)