Obviously using a throwaway here. Our board members got it into their heads that successful companies must have an AI "play", so they instructed the CEO to invest about 10% of our development budget on AI.
We are doing absolutely inane projects that have no hope of succeeding.
We serve a niche industry where certified professionals have to do certain tasks personally, instead of being able to delegate to secretaries. Somehow our CEO has been convinced that AI can be trained to do these tasks, at a reliability level not achievable by other humans.
Team motivation is in a weird space: everyone is relaxed because there is no pressure to succeed - we all know the project will fail unless someone develops well-perfoming, human-level AGI before Q4/2020. Lots of long lunches and checking out early in the afternoon.
At the same time, everyone is worried how terrible the fallout is going to be once the project reaches its inevitable conclusion.
Interesting times, but at least we can now tell investors we are a keen company with an AI play up our sleeve!
Many of us have been there. I think what struck me was how low the treshold really is for what's accepted as "AI" in most industries.
Do this:
1. make something that has some "modern" AI such as deep learning in it, but that doesn't do anything much useful (because that's almost impossible in most cases). E.g. predict something trivial based on a time series, and repoort it. We all know how hard this is, so just take some hello world ML project and change some inputs.
2. Find some easy project that actually makes business sense, and that isn't yet done, and can be done with simple logic or some old school "traditional" ML or constraint solving e.g. a scheduling/optimization problem.
3. Make sure these efforts are "merged" so that the fancy AI tech AND the measurable good outcome is the same project. The "AI" moonshot of the company.
4. You can now say you are doing "AI", you have measurable success.
It cracks me up that on the new LG TVs (I have a C9), it has “AI preview”. Which means: when I hover the Netflix icon in the dashboard it presents a list of the most recently played shows.
I think the “Open Recent” menu debuted in 1980s? But now it is AI!
To the average person AI makes everything sound more modern, "smarter". So it gets sprinkled in everything. Things that have been using the same logical algorithm since the dawn of computing are now called AI. The worst is hearing people in the field calling every piece of automation and single purpose code that does one thing the same way every time as "AI".
Everyone does it just to attach their old or boring tech to the fancy new trend and have some "cool" rub off on them.
A "friend" of mine is doing exactly that in its disruptive startup. Their AI part is a joke and handle a part that nobody really care about, but hey they are doing it like every other cool kids.
It's not impossible. But there is a very real gap between "this is cool in a research paper" and "this is deep learning that works in real life".
It's a large gap, covering everything from application topics, to data quality, to the need to actually run the damn think in a production setting with scalability, availability, error handling, etc.
Production applications of deep learning aren't particularly glamorous, they're not the "next big thing" right now. Rather they're improvements of existing applications.
Google's on device live captioning works really well, but still somewhat niche, and requires special / higher end SoC's to run.
It will get there eventually. A lot of it is hardware / deployment constrained.
Search by image and object detection and computer vision in general is cool and potentially useful, but right now, it's cumbersome as fuck to pull out your phone, find the Lens application, take a picture etc. Needs to be baked into a wearable / neuralink type setup.
But self driving applications of CV work because the cameras are always deployed and running. But the hardware is expensive.
> why is using deep learning to do something useful impossible?
This is completely false. Here are some examples: Google translate. It's infinitely useful. It's not perfect, but it's good enough for me when I want to quickly check whether my translation into my second language is okay, or I'm not sure I got the meaning right of some translation.
Second example: My home security cameras now uses object classification and only alerts me when there's movement in "high risk zones" and it's human. So many stupid false positives of shadows and stray cats completely gone. I'm pretty sure I can fine-tune it with examples of myself and my family and it will ignore them when it's reasonably confident it's them, but I couldn't be bothered.
Yes. Google Translate is obviously a useful product, and obviously Google will have thousands of areas where they can apply AI (enough that they'd even write frameworks for it). But 99(.99)% of us work in mundane jobs doing boring CRUD apps. My post was meant in this context.
You work in a company making an intranet product for the paper tissue industry. Your manager wants v3.0 to have some AI in it. No one remembers the fiasco when "Cloud" was added in v2.0
A fun game used to be "translate this phrase English to French, then translate it back again and laugh at how meaningless it's made by the round-trip". That doesn't work any more.
As far as I remember it was close to unusable. Even most basic translation to languages besides German, Spanish and French was a nightmare. That was at lest true during my second year at the university (~2010-2011).
From what I've read, the early translations were really rough (but on par with competing free products), until they fired all their linguists and brought in AI guys.
Not exactly. Google Translate was always a statistical approach from day one. That was the reason it was better than the rules engines that dominated before that. The Translate guys really pioneered statistical machine translation.
However it was all done with hand-crafted statistical functions and code. The new stuff using deep learning is the first time it'd have been referred to as "AI".
Most of the "useful" tasks AI has helped us with are problems that are domain specific and lend themselves well to machine learning (for example object detection in images and machine translation as another poster mentioned).
However, what I think the poster meant was that just tacking on AI for the sake of it to a problem which most likely doesn't have an applicable use for it (which currently is the case for most existing IT projects or apps) is doomed for failure.
> but at least we can now tell investors we are a keen company with an AI play up our sleeve
Obviously I don't know the details of your company situation, but I've experienced myself over the years, that sometimes it can be less overall cost and trouble to give this kind of lip service, rather than fighting an overwhelming fashionable trend until that trend runs its natural course to extinction.
> Team motivation is in a weird space: everyone is relaxed because there is no pressure to succeed
If I was leading that team, I would try to find (or insert) nuggets of goodness (smaller/non-obvious objectives and tasks) in that project which allow the team members to get some personal longer term benefit out of it.
And ideally find (or insert) nuggets of goodness (smaller/non-obvious objectives and tasks) in that project, which have a good chance of becoming useful to the company later - beyond the scope of the official project.
And hopefully the team would become excited about doing something meaningful beyond the official project objective.
p.s. I'm speaking from experience in this kind of a situation.
The story would probably make little sense to most HN readers, since it's very old and what was very non-obvious back then, became very obvious 5 years later.
Around 1994/95 client/server was unassailable in board rooms (much like AI is now). And after initially speaking up against it, I ended up shutting up about my criticism of that architectural approach, since it would have just gotten me fired.
So I ended up sneaking some early Internet technologies into a big client/server project I managed. Doing that ended up benefiting those developers in future jobs, and the company, because they didn't have to re-write that part so quickly. :-)
This may be a stupid question, but what does "client/server" mean in this context?
I would interpret it to mean any networked or Internet-based application that has both client- and server-side logic, which obviously isn't anything special in 2020, but it sounds like you're referring to something else that would now be considered outdated?
> This may be a stupid question, but what does "client/server" mean in this context?
Not a stupid question at all, since terminology has been shifting over the decades.
Back in the early 1990s, the original client/server generally meant all application code (logic and UI) on the client computer, and all the data on the server. So a very fat client.
Database stored procedures (i.e. some logic on the server) only arrived on the scene later during that time, because the original architecture of all code on the client caused performance nightmares. But don’t get me started on the trials and tribulations of early stored procedures. They often caused more project turmoil rather than smoothen things out. — Partly because they weren’t good languages yet, partly because of amplifying developer vs. dba conflicts.
Without any server-side logic, I suppose user permissions must have been handled entirely by the database, with clients connecting as different database users?
Did row-level security already exist in some databases at that time? Otherwise this must have been quite limiting.
There were alternatives to stored procedures for centralization. I remember RPC and CORBA being hot topics around that time. The tiered architecture was a thing before the Web.
I might be totally off the mark here, but in context I assumed the contrast was with doing all work on a thick "client". A client-server architecture in principle lets you run thinner clients and offload the heavy work, but in practice the network would've been expensive.
A modern analogue might be something like premature distributed computing.
If my memory serves me right, distributed computing was the advent of smaller computers (back then often called mini computers like DEC Vax or IBM AS/400, but those were more like smaller mainframes, still using dumb terminals as frontends.
But you’re right in saying that the original client/server had all of the UI and business logic on a very fat client - and the server only served the data over very low bandwith networks.
A modern analogue might be something like premature distributed computing
A modern analogue might be n, where n is more familiar to the composer of this, or, the source of information determining the production of this text is most familiar with n, where n does not include the word premature
I've always called these direct database applications. The implication that the client directly connects to the database without the benefit of a middle tier.
Yeah - kind of, but Oracle forms originally didn’t even have a graphical client - that’s probably why Powerbuilder and Visual Basic dominated the early 90s. Also, Oracle was still fighting it out with Sybase in the mini computer dbms space.
It’s hard to see the hype up close sometimes. The closest analogy I can think of and it’s an older one might be how in the mid-2000s everyone needed to make a “Web 2.0 mash-up” or how for awhile everyone needed “social” (remember Ping?)... if you were stuck with a stack based on jQuery and global variables, good luck transitioning to React without Facebook’s scale. Sometimes all you can do is try to stay organized, see a project through and hope it can evolve to something greater after the fad wears off...
The PC Mag article seems mostly pretty accurate - however, I’d argue that the web isn’t classic client/server, since the server sends the code to the client just in time. Classic client/server had a totally different code deployment mechanism. It was a full app installation every time - often via sneaker network, since few corporate networks had enough bandwidth to deploy new apps over their network. And installation software infrastructure was almost non-existent. Version control systems? Seldom. Netscape was one of the very first apps that was entirely network delivered at really large scale.
If I had to describe the web to a time traveller from the 1980s, I might say the modern web browser is something like a super smart and capable 3270 terminal, while the cloud is the mainframe.
I remember just before my first web project. I worked on a Oracle client server project (SMDS management tool) and to install the client, you installed about 4 products via 14 floppy disks one after the other on the client PC.
Took two days for two of us to install it on five or six client PC's
So you can probably imagine what it was like when we had several dozens of client pc’s across several customer companies across several cities across the continent.
> if you were stuck with a stack based on jQuery and global variables, good luck transitioning to React without Facebook’s scale.
My team is doing exactly this on my initiative and seeing some positive effects already, even though we're only like 2% of the way there. Would you mind expanding on what you think is futile about it? I wouldn't want to be the one advocating something that with hindsight will look obviously stupid.
Well, leaving aside the React vs Web Components debate, the only issue is that some folks add technologies like React but forget to remove the old ones as they go. They half-finish the job. Then they do that up to 5 times more...
My advice would be to try to refactor the jQuery app to reduce global state first. For example, use ASTs and other techniques to programmatically determine what global state is used where. Think of it not as “porting” to React, but more as ‘re-writing in React” — the sooner you can finish the rewrite, the better. Take it in smaller, thin, but global (across the whole app) steps, and work to break the app dependencies back down to separate components — this is especially true for CSS, which historically has been global by design for much of its life...
If shipping during a rewrite, make sure you have some very basic tests running. Try to implementation-agnostically look for and click text or otherwise use the web app in your tests, then run the tests before and after making widespread changes... Use screenshots from the tests to quickly visually scan for errors. Pay attention to errors in browser consoles also, if not using TypeScript to its fullest yet.
I may be misreading them, but GP seems to be doing the re-write in the recommended way, small chunks at a time. I think the advice cautioning against wholesale replacement re-writes is sound, but piecemeal transition is much more achievable. I think it took about 5 years to transition Wayfair from asp to PHP one page/system/scheduled task at a time, but the result was a working system at all times that improved with the re-write. Not that I have any love for PHP, but (Classic) asp was even worse. (I can’t speak to asp.net, never used it.)
Asp.net Core is fantastic. ASp.net is ok but not as good.
Asp.net Core is cross platform, has a self hosted https server called Kestrel that is insanely fast, has a really sensible composition of middleware, built in DI, and a strong community. Hangfire is a great job runner, signalr is available with real-time push over web sockets, identity server 4 can handle all your Authn/Authz and Entity Framework Core + Linq is very powerful and a lot faster than the full framework version.
I think he's saying the "foresight parts" were his initiatives, not the board's, and the board's part in it all had to be scrapped sooner rather than later while his initiatives did not.
I have had a couple conversations where a business guy starts off with a decent idea then he says something like "the cognitive AI module will fill out your expense report after watching you do it for a couple weeks".
What the fuck? If I had the ability to code a cognitive AI module which could do that I would not be building it for you, I would solve self driving and license the software for billions.
Business guys usually comes together and brag about their works. Quite often, they start to talk about things they heard but don’t understand much.
And the other one hear about it, get excited, but also don’t understand much. Then on the meeting, he brought the idea up and convince everyone to do it.
The next you know, you’re pulling your hair out trying to understand what is going on
This happens way too often. They often read a blog that talks about how X was implemented at company Y and mindlessly cite the blog for their own related-but-different-in-important-ways ideas and it’s upto the engineers to fact check the wackiness. It’s not pleasant.
This happened to me recently where a PM shared a blog about someone who had built an “all encompassing multi cloud cost calculator” for their org and had blogged about it. The PM was naturally extremely excited but I asked him to find more details about the tool and if/how that can be used. Turns out even though it was supposedly open sourced it wasn’t really available to just anyone but the author promised he would release it in a month. That was over 6 months ago, no word from the author or PM.
These blog fueled hype trains are extremely destructive. It makes engineering appear trivial. Building useful tool might be easier now but it’s not trivial. And if a tool sounds too good to be true it probably is.
This makes more sense when you remember that being "concerned with reality" for a salesperson mostly means "Getting the commission paid and moving to a different role before everything blows up too badly", rather than "delivering software that meets the sales deal's contractual requirements".
Salespeople are too rarely judged/punished for the disastrus messes they leave behind, and all too quickly judged/rewarded for being able to convince a customer to sign off on a big number without any care for long term implications of that deal...
A few years ago at a small company after a round of golf with some other shmuck, our CEO told us we needed SSO via OAuth, because that's how we can convince people we're secure. How soon could we get it developed? Spare no expense!
We had a single website with an already written to OWASP standards login, no external API or plans for any.
What always drives me crazy about instances like this, is that managers and the c-level seem to be much more willing to listen to some "random" guy or blog over their own people. People they hired, people that have a much better understanding of the issue, the processes and so on.
This effect is by no means limited to tech. And engineers, regardless of type, are by no means immune to that as soon as they reach higher management positions. I have yet to figure this one out. Which drives me crazy sometimes, because my gut tells me that as soon as I did most "problems" I have regarding managment would be solvable instantly.
I think a big worry for any C-levels is "what if my employees are wrong". And there is good reason to hedge against this, because insiders have clear interests in defending past mistakes.
And if you hired your people yourself, you probably know you skipped over some qualified people who were to expensive, and weeded out some overconfident people who turned out not to be all that. In the end, you wonder what those expensive smart people would have said, and you wonder if your confident sounding employees are just overconfident incapables that you failed to weed out.
Hence, getting an outside perspective from someone you trust has a lot of attraction. However, getting that outsider person to be knowledgeable enough, and getting them the right information, is a tough task.
When I was 17 I worked [production] in a sofa factory that made huge profit. They hired every highly specialized consultant available. I asked one of the consultants and some office folk for an explanation (I was paid 3 guilders or so per hours ($1.5)) To my surprise both the consultant and the office folk thought it was a fascinating question and explained elaborately how [to them] it was worth every penny to have written proof for every business process. Investors could point at anything and get a pile of reports explaining exactly why the chosen method was the right one.
(When I left they continued to pay me for months. It struck me just now that cheap employees probably looked great on paper.)
Why they paid me roughly 1.5 USD and the consultants several thousands per hour.
My bad, I originally wrote " They hired every highly specialized consultant available for .... guilders each" but I only hear the price of one and I failed to remember if it was 5000 or 20 000 for a 2 hour chat.
At my last job, about a month or six weeks after starting, the CTO would meet with new devs and ask them if they thought we were doing anything wrong. He was clear “I have to ask you now because in a month it’s gonna seem perfectly normal to you.”
I recall telling him they were doing builds like no one I had ever seen (“Yes we have a plan to change it.”) and and asking why do you use R as the main language for the ETL pipeline (“It makes it easier for data science and we can run it in Spark.”)
In my case, the business guy stubborn and think he know best, many times.
Every times, I told him it wasn’t what he think. For a few times, I let it go, part to let he learn about the reality. I thought he would change the evaluation process. But no, he still stubborn.
I remember at Microsoft, people would need to win an argument with Bill Gate to get their idea approved. Sometimes, it was a really hear arguments. Maybe some people get inspired by this story too much.
I know a guy that works at a company where the CEO will sell something to customers not knowing anything about the technical details, and then come back to the business and "make them do it".
I previously worked for a Dutch fintech company that operated in the same way, but from my understanding they were (probably still are) really quite effective, profits hugely increasing year-on-year.
But this Dutch company also makes use of some kinds of SWAT dev teams that help customers on the spot with issues, making sure the product lives up to the clients’ expectations, even if this means modifying a product delivered by the core dev teams. I.e.: if some feature was promised, but not yet part of the current release, the SWAT team might hack something quickly, often on the spot in the clients offices. Later on, such a hack might be replaced with a proper solution.
Isn’t this the norm? I complained that sales were “demoing new features” to customers before the back-end dev team had even heard of these features. I was basically told to stay in my lane. A property developer making design mockups of new highrises doesn’t run it past the bricklayers first, so why should product/sales talk to us digital bricklayers...
In one sense, great, I don’t want to bother about what a customer’s priorities are. But it turns out that only works if you TRUST the product team.
In my previous job in a consulting company one of the sales people mentioned how this is the first place where he has to sell the project twice: once for the customer, and one for the co-workers who'll work on it.
It was a nice company. Bosses had very limited direct power over the developers and designers, and rightfully so -- it's supposed to be a team of experts, after all.
I had a moment like that once where the product manager said something like "at this stage of the process the software will go off and find the documents specifically relevant to this stage" - and I was like pointing out we could do a search but that might bring back irrelevant stuff or fail to find relevant stuff - he insisted that it would automatically find just the exact documents people would need at that stage in the process.
It was an "AI complete" feature as up to that point it required someone who knew what they were doing to decide what documents were actually relevant - not "close enough".
The product was used for arranging formal approval processes for things like drugs and government contracts - the definition of what documents were relevant was often quite strictly defined in a practical sense but less so in sense that a bit of software could make sense of.
I've been kicked off a project because I couldn't stop talking about training data (they already had) and machine learning algorithms (NLP, text classification) that we could implement right now to start automating a couple of internal processes that are currently pointlessly manual. Think moving incoming e-mail to appropriate downstream support channels.
Not enough magical AI / AGI in there.
The countless PowerPoint presentations built after my departure described processes along the lines of "the AI will detect when you're about to miss your connecting flight and book you into your favourite hotel with your favourite dinner pre-ordered".
Surprisingly, the project survived and now they collect training data and use machine learning for text classification.
Solve self driving? How bout market prediction and just play the market forever. Why would you risk failure when you can just do nothing and make trillions?
If someone offered me AI that drove me to work while I slept or watched movies, or AI that filled out my expense reports, I'd ask if the AI is able to scan the receipts by itself.
Just start a software consulting business. An outsourced programmer goes for $100+ per HOUR. No need to have the initial capital you need for market prediction.
Dude I see hilariously absurd ideas for AI implementation in both the film and podcast worlds. There is definitely potential - such as transcriptions - but people are way overselling the efficacy and trying to “disrupt” with AI in ways no industry professional is asking for.
Even transcription is hard when it's used in the way manual transcriptions are used. Whenever there is sufficient value in transcription to bring the manual process close to worthwhile the cost of mistakes will also be high. But lower value applications can have much lower quality requirements, e.g. imperfect transcription could still be used to generate a high level topic log of a conversation that might be useful e.g. for backtracking after a digression.
The pinnacle of the low failure cost principle must be ad targeting, it costs nothing besides opportunity to display the wrong ad. And the success metric can even be inverted if the mistake is sufficiently surprising: I'd probably be more likely to deliberately click an ad that is entirely off my beaten path, out of curiosity, than something that aligns with my actual interests. Who wouldn't click on an ad for e.g. curling brooms? Curlers.
It’s only disruptive when it actually disrupts something I guess is my point. I’m not so curmudgeonly as to think “this stuff will never work,” I just see so many folks selling it as if it already does.
I find that a C suite member talking about AI without a specific goal in mind (“we will use AI to automate X, which will help us do Y better”) is a huge red flag.
It also seems to be a main selling point of a lot of logistics and supply chain star-ups these days. I guess it sounds way sexier than "give us millions to build a new forwarder and our own tech because we don't want to use off-the-shelf software and we want to be acquired by DHL one day".
At least once a month I get contacted by some recruiter contracting with a company like this. They all seem to have a vauge screen reader -> OCR -> AI fill in the blanks, form submission charter. They claim to be profitable and have 10+ customers, but their examples of how their product is used sounds like they are automating Sally in Accounting's job, and she's 2 years away from retiring, so if they could get the software to interface with the 1990s software she's been using for the last 10 years, they won't have to retrain her replacement when she finally retires. I'm sure Boomer Replacement is a market, but does not seem like a 1000x unicorn growth market.
Once the CEO asked me to build a human level AGI in front of our only customer (small company).
I asked them what they wanted to do (it was solvable with keyword search) and told the CEO that I’d be happy to get it into the next version. It took an afternoon or so to implement.
It's interesting that you seem to be insulting your CEO, who managed to solve a customer problem with reasonable tech requirements for you and a grandiose upsold sales pitch. Seems like a win-win-win
If it happened like the OP described, they just got lucky, but it could have gone differently. A good (but less than honest) CEO would have colluded with the developer before talking to the customer, both agreeing to upsell an easily implemented feature. However, the mark of a PHB is that he/she will ask for random features while completely misjudging their feasibility -- sometimes you'll get lucky, sometimes you'll crash and burn horribly.
My rule of thumb is that if it's a plot to dishonestly deceive the customer, it's probably collusion. If instead it's an honest plan made with the understanding of the customer, it's a collaboration ;)
> He is notable for his micromanagement, gross incompetence, obliviousness to his surroundings, and unhelpful buzzword usage; yet somehow retains power in the workplace.
To kind of go against the flow here: _most_ of the projects I worked on seemed to be a waste of time when I worked on them, but ended up making a lot of money many years later, years after I'd moved on. I like the green field stuff, and green field stuff looks like a waste of time most of the time. The first three versions suck ass and don't do much, but without having them you don't get to something that doesn't suck. Both the first and the second project I worked on at MS seemed like horrible waste of time in early aughts, but have likely made tens of billions of dollars for it by now.
Then there are projects where I did something ahead of its time (and was ultimately unsuccessful) yet other people did the exact same thing later and made a ton of money.
Finally I ran engineering at a startup which spent ~3 years largely wasting time and money, only to be acquired for hundreds of millions of dollars for reasons that are still unclear to me.
You never really know. Success is a random, nonlinear process and your effort is but one input to it. I've given up trying to predict if something will be successful if the work that's being done at the front lines is solid from the engineering standpoint. Business is mostly about being very persistent and/or being in the right place at the right time.
For all you know your company might be one PhD hire away from absolutely blowing the doors off competition. Or it may get to that point years later because it started thinking about it now. Or having at least some sort of an AI strategy (even if not very successful) might double the acquisition price in some upcoming merger. All of those things would make your work worthwhile in retrospect even if the project fails. You never know such things.
These uncertain situations are usually a blessing in disguise: because management has no clue, you can pretend that you have clue, and steer things in the direction that's useful to you. Put some cool things on your resume, if nothing else. Move on, see if you have better luck elsewhere.
This is a great comment. If you're comfortable sharing any more information, I'd love to know just a bit more detail. What were the technologies or strategies that seemed useless at the time, but eventually succeeded?
In the first project I worked on at MS we were entering a new, established market with multiple strong competitors, and because Microsoft at the time did not have the right tech stack to do web services, the initial tech choices were dubious at best. The first version looked great, but under the hood it sucked like you wouldn't believe. Then sales somehow sold it to some pretty large/important customers, and the team had to spend the next 2 years fixing things "under the hood". Now it's one of the leading products in its market.
My second project there was about enabling the desktop version of Office to be rented and backed by online services. At the time the idea was novel, and nobody believed it'd succeed, _especially_ because Ballmer was pushing it pretty hard. But succeed it did, wildly.
I know multiple such examples anecdotally as well, from friends. The initial versions of Azure seemed like a waste of time also (VMs topped out at like 32GB, everything sucked mightily throughout the entire stack, nobody thought it has a fighting chance). Today it's the second largest cloud, and growing rapidly. Still kinda sucks though. :-)
The initial version of Bing crawler was pretty horrible also (index team had more time, so their code looked squeaky clean in comparison), and it spent years trailing behind Google until they figured out how to close the gap (with "hiybbprqag" thing - the press got it wrong, they weren't "stealing" Google results per se; they augmented training data with clicks that come from Google search pages IIRC). Today Bing powers Duck Duck Go among other things. It's still not a wild success, but it's most definitely not a waste of time either.
Ha. CTO at my last place did something similar. He hired an AI/ML team. I asked him what projects he had in mind and he said once the team was on board they'd find things to do. He also said we needed a voice app because he read an article about the size of the market. I quit before seeing how any of that worked out.
Previous employer did something similar. Hired a crazy expensive data scientist, spent truckloads of money on a data swamp, er, lake, and then didn’t really have any goals for what to do with all that capacity.
The new hire got lucky, as there was some low hanging fruit (optimizations we all knew about). The obvious solution was implemented and then he ex post facto claimed 100% credit for the revenue enhancement. Since it’s like 10x his salary every year he’s pretty much on autopilot.
If you walk into your CEOs office today and say "I can increase revenue from our site by 1 million dollars" (#)
you will get a hearing. If three devs on that site do it, with a poc they will get the chance to do it 95% of the time.
But the CEO who hires a data scientist is explicitly asking that person to walk into their office and say "I can increase revenue by X" - that is their job. The website dev does not have that job.
And there are two views on this problem - the CEO did the right thing by hiring someone to explicitly optimise the site - there are improvements to be made, create the right organisation so that those improvements flow to company.
Or there is the other argument, that the organisation is stifling innovation from below, and that the CEO should have been actively soliciting improvements from dev team and elsewhere
Not this place. Our department produced multiple designs and products that had substantial positive revenue. We even did some ML projects with our existing team and/or SaaS products. Anything that didn't come from the head office was treated as a rogue experiment.
That's why you have management to listen, decide direction and argue about it. Seems like engineering management wasn't doing it's job so someone hired a Data Scientist outside their hierarchy to actually get things done.
I had a similar situation, but it didn't go through. I offered to reduce the company-wide monthly costs by 5% in exchange for 40k once by replacing an outside vendor with my own self-developed clone which the company would then own. Didn't go through because our investors feared an increased dependency on me as an employee.
Especially with investors, the incentives might be that you're better off doing exactly what was asked for i instead of going rouge to boost the company's profits. For you, the developer, that's an unnecessary risk and there's no reward for taking it.
That kind of ignores power structures. Higher ups seem to be more willing to listen to external peope than internal ones. Plus, why should they pay you more for doing "your job"? Compared to a super expensive external guy who's hiring needs to be justified.
Yeah my fairly small non-profit recently hired someone with a math degree to do stats and "big data analysis." We are talking about a company with <100,000 total "market."
In my experience, to these people, big data means "the excels look really big."
In my own experience, often non-technical people will attribute things as AI that we wouldn’t, eg any basic automation. Really anything that’s in any way intelligent or seems that way. I had a project where people were excited about a feature that was basically just alerting when one value crossed over or under another... I wonder if your team could provide real value to customers providing some smart “AI” feature that isn’t actually machine learning.
I had a boss not so long ago who kept selling our customers our "Conversational AI Bot". What we gave them was a fairly dumb keyword search of a library of questions the customer would type in along with answers - wrapped in some html widgets displaying cartoon robot heads.
It still astounds me that not only did none of those customers sue us for blatant misrepresentation, but most of them were delighted with what they'd bought.
I had a similar cognitive dissonance when doing "R&D Grant applications" a long time back. I kept on thinking "Research" was the sort of rigorous academic work you do to earn a PhD. In the government/business world, it seems pretty much spending time or money to learn how to do anything not 100% required for your business previously counts. Including things like "selling our widgets, only via the internet" being valid and acceptable thing to get government rebates for "R&D". I still feel dirty everytime I draft one of those grant applications... :shrug:
The line of were AI starts is not well-defined. If you think about it, virtually all software can be considered AI if you put expectations low enough. From the other end, one could argue that once you understand the inner workings of a piece of AI, it just becomes a fancy algorithm to you. In the end, everything is just a piece of software converting input to output.
My experience is that people tend to consider things AI whenever it feels like "magic" to them, at least in non-technical circles.
On the other hand, actual AI is kinda cut-n-paste accessible now too.
I slapped together a POC javascript tinyYolo feature detector demo last weekend (using someone else's code and pre-trained model from their github project), and joked when I showed it around that "And we can tell investors we're running AI, deep learning, and convolutional neural networks in our realtime production workflow!"...
(But as we all know, all the _proper_ magic is done by the regexes buried in that Perl module dependency hidden in a deeply nested source code directory that no-one without a grey beard is ever game to peer into...)
If you have someone doing a task manually, you could technically argue that you’re using an incredibly advanced neural network. Just not an artificial one.
I was recently joking that I was training a neural network with a water spray bottle (teaching the cat not to jump on the kitchen counter). And just while I type this, my little neural network came to walk over the keyboard...
Completely agree. If its artificial (all software) and its in some way intelligent p, or appears that way, (a lot of software, or features thereof), then you could argue its artificial intelligence, based on just those two words (ignoring the definition technical people give AI). That’s why machine learning is usually more useful from a technical discussion viewpoint.
> From the other end
Yeah, using wongarsu’s example of chess: brute forcing chess was once a highlight if AI achievement and now its just a crude search algorithm.
Times change, patterns stay the same. I remember when Facebook got big, so obviously everybody had to copy them.
Imagine working on an accounting application when the CEO suddenly instructs everybody to figure out how accountants could connect with each other and maybe publish their balance sheets instead of cat pictures or whatever. Details changed, but it was that weird.
Just pivot to "assisted-AI" where your solution is really bad but it adds "super-powers" to all their existing employees. It may give cover to some other businesses to fire staff under the "force-multiplier" argument that your software adds ("If their software makes every employee 33% better, we can fire 33% of our staff!").
My dad always disliked the strip you cite, because the change Dilbert expects is $5.25, but there's no way to provide $7.14 in a way that couldn't be trivially reduced to $2.14. If the goal is to make things easy for the cashier, he should obviously provide $2.14 and just keep the $5 he already has anyway.
Years ago I worked at a store with registers that didn't calculate change; myself and the other cashiers would need to calculate the change mentally. Once in a while I would get people like this who threw out convoluted amounts of change. Normally it was fine, but sometimes towards the end of a long day when my brain was tired I wanted to strangle them.
The store actually had really great employees overall and I suspect this little factor played a big part in that. Part of the application process was a basic math test and it was funny to see how quickly some applicants recoiled when they found that out. It seemed to be a great filter.
You don't calculate change. You just count it out, picking up coins and bills as you go. Start at the sum to pay and count towards the amount the customer gave you. Work your way up from the least significant digit using the smallest denominations. No hard mental calculations are involved, you just need to know how to count. Basic cashier knowledge they should be teaching you on day one.
"Basic cashier knowledge they should be teaching you on day one."
About 10ish years ago I had an idea for a product that would essentially provide online training on this for cashiers. Back then I thought 'but everything is moving to cashless payments, plus more and more registers calculate change, no need for this". I wonder sometimes if this was The One That Got Away for me...
Oh boi does this hit hard as a engineer that recently got hired as a part of the AI/automation team on a startup, that few month in got told by the boss that "we need a AI team because we promised the investors. Investors are not interested in tech without AI baked in". Whelp.
I wish I knew the details of the project; getting to mess around with new technologies for a year and no strict deliverables is a great position to be in. Worst case, you got to learn some new tech and pad your resume for your next job.
I used to work at a software house which makes software for few big companies. A few years ago our CEO thought it's time to diversify our income stream by creating some SaaS. He came up with a really then-buzzword-packed(AI, ML, IoT, microservices, Kubernetes, mobile first) product.
Quite ambitious, especially for a team of 5 people, regular web devs who had no working experience with any of those. Everyone voiced their concerns but we were told to just use our best efforts.
Long story short: after a year or so, our boss decided to scrap our half-baked system and gave up on the idea of creating some internal product entirely.
It looks exactly like my company, but I am few months ahead. I am now at the time where investors starts to ask for results. The CEO wants to please them and starts to put pressure on our team by changing priorities almost everyday (which impact the project quality).
The thing is, everyone knows that the project is doomed to fail.
I've had a very similar experience. I'm surprised at how little so many managers and investors understand AI.
They talk about it like it's some sort of panacea that will make a company automatically grow 10x. Then you ask them what they actually want you to build and... Crickets.
I'm cynical about a lot of 'trends' that have popped up over the year, because oftentimes they're just compromises or marketing to get employees to join them. Notably, in recent years, a LOT of employers / recruiters will stuff "IoT" or "Blockchain" into their job descriptions, knowing full well they do nothing with it - or if they do, it's a couple hours a week they give up on to keep the employees happy, interested and motivated. It's a weird theater.
Most of those jobs are generic Java work, but it's hard to find motivated / qualified people to work on just that.
I worked on a project that basically was a very simple rules engine, encoding a bunch of domain knowledge in a digestible dashboard format, which happened to use a few predictive models' output as well to drive a few of the rules. The product owner insisted that "AI" be in the name, whereas I was reluctant to put lipstick on that pig. Ultimately (as usually happens if the product owner is your boss) the "AI something something" name stuck, but the whole branding of the endeavor rubbed me the wrong way (even though the product was actually somewhat useful).
Perhaps the most significant outcome is that you guys will be peppering your resume with AI buzzwords, which the board may be paying through expensive staff retention.
Almost seems like menial work that your CEO might be using to gain a better foothold on gathering external investments. My experience with CEO's says that they aren't complete morons. I hope for your sake there is another valuable reason why he has you all doing this work.
yeah I've resisted these fake ai project as much as possible, but sometimes the budget is there so you're better off spending it.
bet there's something between a full AGI and a set of ifs on the audit log that could help the human experts reduce error rates and fit within the direction constraints
Machine learning requires a lot of nuts and bolts devops type stuff that isn't directly related to the problem you're trying to solve. I think it's a shame that a lot of this stuff gets reinvented at different companies and kept under a cloak of secrecy.
Any part of the problem that is not specifically related to the company's vision should be part of a communal effort make machine learning and AI tractable.
Companies should compete on their core Mission and cooperate on all the plumbing.
I told the project leader that nobody wants a share button there, because of the nature of the data, nobody will share it.
They disagreed strongly, suddenly the share button was super important.
So I put tracking on it. A year after launch, guess what? Yep that’s right, nobody clicked the button. Not a single user.
So I showed them the data and told them I was right. I told them I was sick of not being listened to, and sick of designing and creating software that literally nobody uses, and handed in my resignation
Was a good thing in the end because it pushed me onto the entrepreneurial path
But I know how much it sucks writing software that no-one wants
Ohhh been there ! Executives and managers always think we need a share button ! This will bring in the traffic they say ! I asked would you share this ?? Ja of course they say... Then I asked them when was the last time they "shared" ANYTHING via a share-button, not just this-thing... ANYTHING... They all fell silent. We still don't have a share a button :)
Hahahaha I re-read my paragraph and it does sound a bit like that!
I wish it was - then there might have been some engineering challenges related to scale, but sadly no, it was a mobile web app for getting small % discounts at stalls at a niche event.
Nah, there's plenty of sex-positive Twitter accounts that share a lot of porn in the most social way, to the actual living people that follow them, have conversions about it and sometime even meet up in real life.
No it wasn’t because without it the paragraph content below would move up. (It was on mobile so there’s not a lot of space anyway)
Their insistence on the button was a combination of “my application designs are flawless, and should never be questioned”
and
“I read an article 15 years ago that said put a Facebook button on everything, everywhere because Facebook”
It wasn’t even a “ah ha, I got a discount at this cool store” it was a share button on the info page .... it’s like putting a share button on the terms and conditions page. It’s stupid. Nobody wants to share that.
> But I know how much it sucks writing software that no-one wants
To be honest it does not. If you are business-driven person it does, if you are more into the craftsmanship this is a dream scenario. Suddenly a lot of freedom is granted with the lack of users :)
Exactly my thoughts when reading the original comment. In his case he was already handing in his resignation, so he didn't care too much. Someone who isn't willing to risk their jobs should be careful while proving a someone else wrong as not to offend / publicly shame the other party.
I once implemented caching middleware complete with logging of request times so we could see which calls would benefit the most from caching. We never turned it on. A few months later our system is on fire so the investors send a guy to babysit us and improve things. He starts writing a profiling tool. He won't listen when I tell him that I've already done it, just ignores me. I got so frustrated that I log into the production system and turn it on manually for about a minute. Email him the resulting log. He makes a histogram in excel (doesn't mention me) and there was much rejoicing. (And we started caching requests and lo, the servers did cool.)
“Agile teams that truly iterate with the customer can often avoid these problems because the customer is there the whole way through and the team continuously pivots to close gaps discovered by the customer throughout the project, thereby building something the customer actually needs and wants.”
I‘m 2 years into my first role as a product owner (made the switch from design) and working at a fortune 100. The thing that’s struck me most since starting this role is that as while the company has invested more to our transition to agile teams (hiring external agile transformation companies, everyone goes through scrum training etc) we seem to have distanced ourselves even further from the customer.
I report to a product manager, who I think in turn has had zero hours interacting directly with our customers or our users. Our roadmap seems completely driven based on whatever features seem to be flavor of the month (or quarter since we do roadmap planning quarterly) and it’s been a struggle to even try and get buy in to having our customers represented in some way by proxy (e.g. through personas, or setting product metrics that attempt to measure customer value). Features that we do release have no expectations around what is considered successful usage (usage will be measured, but without context, so if 5% of customers use a feature there’s no interpretation if this is really low, or really high).
The puzzling thing is that when I talk to my manager (or managers manager) about this disconnect, they seem to agree in principle, and that we should be doing these things but no one ever does.
I’ve been told that someone in leadership described me as being too “black and white” in this area, but I consider myself both pragmatic and flexible to alternative ideas.
Because I’m still new to this role, I wonder if I’m being naive or idealistic around how we approach our feature development, or if this is just how most companies operate.
Here's some advice, which you are free to take or to leave, (and that's very reasonable since my advice is generic and I can't speak to your exact circumstances)
1) Just start doing it. Don't wait for someone to give you permission to prioritize customer needs. Pick up the phone and call them. Go to a store and watch them shop for your product. Talk to people. When you set OKRs/KPIs, just make them about customer needs. Be the change you want to see. Especially if you have spiritual buy-in from your manager. But your intentions have to be crystal clear on point about wanting what's best for the customer and the business and doing so in a rational way until you earn some social capital. It cannot be interpretable as political or they'll construe it as that and fire you
2) Use bureaucracy jiu-jitsu. Do what you think needs to be done in order to make the customer and the business successful. When someone tries to make you work on their arbitrary BS, give them a form to fill out and tell them it's in your team's triage queue. Make them force you to deprioritize a project which has clear value and then when that happens, make sure you announce loudly to all stakeholders why that project was depriortized and what's going to be implemented instead. If your stakeholders have even 2 braincells, they'll do the pushing back for you - you don't need to do it alone.
Lastly, you can't change an entire culture by yourself. For some places, it's just too late. But if you can find allies who feel the same way you do, you can be the beginning of a large change for your whole org by just being a good example
Great, practical advice for companies of that size. We can debate about whether it's unfortunate that it's necessary (I'd tend to agree that it is), but learning how to do this is the basic block and tackling required to get things moving at BigCos.
I'd be cautious about this advice. Many times even though the company in general might be a feature factory [0], there might very well be a human who actually meets customers, or at least tried meeting them and failed for some reason.
So a much better and safer idea might be first to figure if there were any attempts in the past, or is there any ongoing similar initiative right now, find the participants if there was any and then to proceed.
By the way if all the PMs at FAANG are like you, that might be a terrible place to work at.
This problem isn’t unique to big tech. It’s much easier to tell each other you are customer driven than to actually pick up the phone.
I’m in b2b SaaS, and the best approach I’ve found to combat this is to get involved in sales meetings. Salespeople look at you funny if you ask to come along, but if you convince them you aren’t weird it usually works. And you tend to make the meeting more successful, as well as getting actual useful insights into what prospects actually want.
While this works on the surface; many times you'll find what sells is often features your competitors hit you on, but not what will actually sustain customers.
One issue with "buyers" is that they aren't the one using the software.
I worked at a big tech company many years ago and it's precisely this disconnect that I will never work for a big successful company again. Successful companies tend to have a lot of "buffer" in terms of resources so they feel no urgency to ensure that resources and time are allocated to something meaningful. The objectives of middle managers are often not aligned with the companies. I've been on projects that were delivered on time and under budget only to be canned just before shipping because after two years the market has shifted. No one in those two years felt the need to change anything or make the hard decisions. Rather it was easier to just act like everything is fine until the last possible moment after wasting 2 years of worth of engineering resources with 50 engineers. The problem isn't you.
>Because I’m still new to this role, I wonder if I’m being naive or idealistic around how we approach our feature development, or if this is just how most companies operate.
IMHO, the way to answer this question is from a sales perspective. What's the revenue of the product? Is the product doing well financially and are customers renewing? Are the sales teams able to hit their targets?
I work in a customer facing role for a huge company and you've described the situation here well. We've got a ton of products, some of which are doing really well and one of which is tanking. The one that is tanking is something the company is placing a huge bet on.
Whenever I speak with product management for the product that is failing, they have this grand vision looks amazing in slides, but when I work with customers it's obvious that vision isn't grounded in reality. It's like they spoke with a bunch of CIOs and drew up this vision that has nothing to do with how the market actually is. It's almost painful to talk with product management because they just keep going back to this grand vision and anything that goes in their ears gets filtered by this viewpoint.
And it absolutely shows in the dismal sales and high customer churn.
If the product is doing well, maybe you are naive. If the product is failing or barely treading water, you're not the one being naive.
It's important to keep the customer in mind when you're looking at sales figures. It's too easy to be lulled by solid sales and low churn into not actually seeing the customers at all anymore. That's usually the beginning of a downward slide ending in massive churn once a competitor releases what your customers actually wanted from you. This advice is easy to keep as an individual, hard to keep as an organization (unfortunately).
You work in a fortune 100 company, welcome to bureaucracy.
Those middle managers do not give a shit because they are middle management! Big companies have tons of people like who's only motivation is to simply not get fired (this is one point the movie Office Space nailed by the way.)
A fish rots from the head. If your executive leadership is not obsessed with its customers, nobody else will be. And you guys will continue to be rudderless which is demoralizing.
Big, fat, companies get lazy and that sucks for a guy who wants to make a difference. Go work somewhere that encourages logical (black/white) thinking and values engineers who want to turn customers into raging fans.
Or just work each day enough to not get fired, and build your own product on the side.
What you're missing is that the 'customer' in this case is not the buyer of the product, but rather a proxy for them found in the PM.
Big, heavy, complex products, the kind one imagines F100 companies build, are not suitable for literal agile where a paying customer as willing and able to iterate with the development team.
With that kind of product, you have many customers. When you have many customers, they always have conflicting requirements. You cannot engage in an agile process with more than (say) three of them for the same product. You'll very quickly reach an impasse and lose all of them as customers, and end up with the same product anyway. And you'll open the kimono, so to speak.
Instead the PM has to decide (based on various activities such as seeing what other companies are doing, where the space is headed, and yes, talking to customers) what the product is to look like, and he (or more likely, you the product owner in this case) has to engage with the dev team. You have to be the customer that actually needs and wants something, and that the dev team has to satisfy. This is why PMs have to have significant industry experience. Often, CEO of a small company slots into PM role in larger companies.
Agile as written, with paying customer in mind, is for consulting style engagements. But that doesn't mean it can't be applied well when PM is a stand-in for the customer. It keeps the dev team moving, and brings the 'C' players up to 'B' level. (Unfortunately it also brings the 'A' players down to 'B'.)
> Because I’m still new to this role, I wonder if I’m being naive or idealistic around how we approach our feature development, or if this is just how most companies operate.
yes and yes. You are being naive, and this is how most companies operate. That your boss can't explain it to you just shows that the company doesn't understand the application of agile and are just cargo culting, like most companies, and doing a very poor job of "Agile" because they don't understand it. Most companies implement agile as a way to micromanage devs, not as a way to get a better product, and even then they suck at it.
Customers can be a nightmare simply because they don't want to be closely involved and on their end, they usually are not engineers so the requirements can easily not make sense.
I don't blame people for avoiding such tasks, especially in a Fortune 100. The bigger the company, the more diffuse responsibility and the harder it is to steer the ship anyway.
It's worse when they /do/ want to be closely involved, but then also thinks that being closely involved means dictating functionality to a T.
Using software does not translate remotely well into /designing/ software. Too many people want to play small-time user interface designer while realistically having no design knowledge beyond "I've used software before, and I have IDEAS about how to do things better."
So much effort is wasted on implementing things people think they need, having recognized a problem and conceived one idea that might solve it if only someone could implement their vision.
I sometimes envision a world where (layperson) patients show up at a hospital with a medical condition, describe a novel surgical treatment to the physicians, and then the physicians follow their instructions exactly because, hey, why not? It might work! There definitely won't be consequences if it doesn't!
Another issue I found while writing software that customer service agents used was we did not get feedback from CS agents without being deliberate, only from the managers of the users (CS agents). The managers were interested in other features like, time tracking, conversion/sales reports, while CS agents were interested (when we finally talked to them) about things that would improve their sales (ex: show available manufacturer rebates for skus to help make a sale)
This is often because people don't understand that the real deliverable is knowledge gained throughout the process and the software is actually an artefact of this knowledge.
You might enjoy reading all the things that Marty Cagan has written about product management. I think he has a good take on what it means to be a good PM, and what you're describing sounds like what he calls a Feature Team [1]. Unfortunately, it's really common to be in an organization like this where the roadmap is driven by outside stakeholders, and product managers are treated like project managers who just implement their ideas.
This is exactly my approach. Years ago I wrote a set of tools to help me in my day to day operations. In this way I was able to work very fast. I added more and more features. Then at some point I decided to distribute the tools to the rest of the team. Now, nobody can live without them ... (about 30 individuals)
> I’ve been told that someone in leadership described me as being too “black and white” in this area, but I consider myself both pragmatic and flexible to alternative ideas.
When I've seen responses like that in the past, it's often somebody who just doesn't want to listen to any complaints, for various reasons. I recommend a quieter approach, where you don't tell anyone what you really think about the problems, but just wait for an opportune moment to ask "can we do X for Y?" in a public forum. That way you can't be ignored, you aren't complaining at all, and somebody else can later take credit for implementing your idea, without them having to admit that they were the cause of the problem to begin with.
Off topic, but would you mind sharing how you made the transition from design to product management? I'm considering making the jump myself and am curious about what the experience has been like.
The bigger the project or smaller the company the more customer involvement is demanded. You may not be in that nexus. If the app runs with new features perhaps that is good enough.
The problem is the definition of customer and the actual commitment to a customer focus, in my experience.
It's usually hijacked away from the actual customer - that is to say, a person who pays your company for products and/or services - to various internal "customers" who are nothing of the sort.
Spotify are ostensibly the Gods of Agile, but how many Spotify music customers were actually begging for podcasts? How many of them were begging for Spotify to lock podcasters behind their paywall and stop podcasts working with any tool? Was there even a single paying Spotify customer demanding that?
It wasn't the customers, it was the beancounters. Spotify itself doesn't have any "original programming" as the video players have, so the logical move is to capture a market worth something for a lot of listeners.
This wasn't about doing something for the listeners, it was about capturing and milking a market.
Spotify is a growth company. They build for future customers.
Podcasters at also business partners, just like songmakers are. The only relevant difference between podcasts and music is that you've been conditioned to expect that music costs money but expect podcasts to be free.
Spotify didn't blackmail Joe Rogen into licensing his podcasts for $100M.
I'll share a disturbing anecdote about one of the largest and most influential software companies in the world, based in the Bay Area, and I'll leave it to you to guess which one. I know of several people who work there who are ranked very highly and are paid extremely well, who have told me personally that the work they do there is terrible for the users (i.e. it's exploitative) and terrible for the internet (it interferes with open standards and access). But it also creates profits for the company. The individuals feel that it just pays too well, and for that reason, they could never voice their true feelings inside the company, and neither could their colleagues. It would mean giving up humungous paychecks. Inside the company, it's like the Emperor's New Clothes. Everyone pretends that they are making the world a better place, when they know without a doubt that in fact, they are making the world a worse place. They are not bad people. This company is filled with people who are making that silent tradeoff every single day.
Very few people are "bad" people but the way you're describing it makes it pretty clear that they're making unethical choices, and they're doing so consciously. Actions speak louder than words.
The sad thing is, what are they going to do? Change it? Leave? Let's pretend each of these individuals are making $2M a year. They'll just be replaced with someone else that'll take the humongous paychecks. They could take a moral stand and leave, and I think continuing to work in that environment would be hard, but I don't fault the individual to the point I'd consider them a "bad person." Their complicity in these activities is not bad enough to warrant being angry at them, but I do feel a bit sorry for them. It is a hard choice they wouldn't have to make if there was a bit more oversight of these internet behemoths.
If they're making that kind of money, they can not only afford to leave, but have plenty of time to figure out what to do afterwards. Unless, of course, their current lifestyle is beyond their means (one would hope not in that situation).
The choices aren't like those in a DoD company (we assume from the poster this is a FAANG company). You aren't actually building weapons platforms. It's a bit more like slot machine engineers here; people's lives are 'worse', but not 'over'.
As such, I think it's very personal.
If they are OK with building digital casino-like places, so be it. If they are not, then they should make a plan to leave. If they feel that the money is the only thing keeping them there, they have to look into their own mirrors.
Is that a rhetorical question? Because a person who makes conscious unethical choices is a bad person. Otherwise there would be no metric for "badness" and the word would be meaningless.
This was the one of the wonderful bit of insights from the suprisingly deep and insightful show "Bojack Horseman". Basically, there is is no such thing as "deep down inside i'm a good person". You are your actions.
> Everyone pretends that they are making the world a better place, when they know without a doubt that in fact, they are making the world a worse place. They are not bad people.
"Doublethink is a process of indoctrination whereby the subject is expected to accept as true that which is clearly false, or to simultaneously accept two mutually contradictory beliefs as correct, often in contravention to one's own memories or sense of reality." [1]
What do you call it when one doublethinker absolves a different doublethinker for doublethinking? Doubleplus-doublethink?
Yes, 100% agree. Unless we change the system to stop these abuses, then the good people who "do the right thing" and quit will simply be replaced by other new employees who don't give a shit. The end result is that bad people are rewarded with huge paychecks while good people are punished with fewer opportunities and/or lower paying jobs.
I think the hypocrisy of this stands out in tech more than other industries, because people have got used to the idea of tech "making the world a better place" and being a force for good.
There are bright people making lots of money in other industries who would struggle to even pretend they are making the world a better place.
In fact, how many jobs are there where you can get reasonably high pay and status, and still feel like you are actually improving the world? Medicine springs to mind, the sustainable energy industry...some parts of the software industry...anything else?
Sadly it seems most of us need to sell at least a little bit of our soul to pay the rent.
The problem is that software no-one wants often has the best careers.
I worked on a system used by many people and it was hard work, was getting 10-15 years old, held together with tape and lots of users who all had their gripes and requests.
I moved to a system hardly used by anyone and life is so much better. Get to play with interesting technology and no one minds because there is now risk of annoying a our users who dont really care. The best thing is I get paid more here too.
What area? I've mostly quit software because of how much I hate working on complete garbage and also don't have the schooling/engineering skills to work on truly cool stuff. Pivoted to wood working.
Funny, I know a guy who was did woodworking (and construction) that pivoted to software.
I worked with him on a consulting project used by nearly 30 million people, great dude and great experience.
On the other hand, I didn't have an engineering degree, and worked on software for a major bank, and then a consulting company where I worked with ex-construction worker.
I found a gig on a team at another company where I make 40% more. The team I work on has zero real customers at this point, and we're doing real interesting stuff. We plan on converting our customer base over to the work my team has done, but that's still in the works.
Anyway, I think schooling isn't as important as people may think. You can learn some really cool and cutting edge things if you put your mind to it. And if those skills are marketable (not necessarily valuable, although companies might think so), you can get jobs utilizing those skills.
Tinkering with the tech you're interested in can be a good way to get into a position working on that piece of tech. It might not always work out, but it's worth a shot if you really want a fulfilling and interesting job in that area.
Been in the industry for over a decade most of which was in fintech, some in crypto. I don't count any of that as "cool". I've still got some years left because it's good money but eventually I want to pivot to wood working. I started working on my own apps this year and it's much more enjoyable.
This feels so true! I had a similar experience.. spent 3 years working for big US companies, completely focused on whatever trend would impress investors the most with no one giving any thought to what might actually be _useful_ for people who, you know, actually give us money.
Now I work for a small company doing very niche work and I don't think I could love my work more. I mean people do use our software, but there's no VC funding so no pretense of needing to hop on the latest bandwagon. It's just so much better.
That might look good in the short term, but there are many companies and roles which require you to show the actual number of users, or the load of the service that you worked on. Also many technically challenging issues only come out under load, and actually working on challenging things are very different from reading about them. Just my 2 cents.
there are many companies and roles which require you
to show the actual number of users, or the load of the
service that you worked on.
I got my first job as a programmer in 2001 and not once was I asked that. I'm sure they exist but I wouldn't count on that being so common as to significantly impact the OP's career prospects.
Two things I've most often noticed people care about when hiring:
1. experience with the exact tech / field that they're hiring for
2. having brand-name job experience (google, amazon, etc).
It's sad but you'll probably get better mileage from having worked on a useless prestige/pet project at google using fashionable tech than a critical system written with JavaEE & serving a lot of high-value customers at Alliance Generic Insurance Services Corp.
I do agree that there is a risk of it all crashing down. I dont think they ask us for load or users, but they notice an area where money isn't coming in.
I currently work a "crypto" startup - we've developed our own language and platform for developing smart contracts.
Our CEO constantly talks of "ecosystems" and "blockchain", when that's none of what we actually have (or have concrete requirements to build...).
Our investors and customers have no real idea what they want or what to expect - most of the customers just want a basic enterprise system, but have been wooed by blockchains and AI and magical fairies that sounds really nice in a contract but deliver no value in reality.
The saddest part is that we have an amazing team - the smartest folk I've ever worked with, with so much potential to create amazing technology, if only we had a plan or direction.
Like I saw on another comment, it has all become long lunches and checking out early, because everyone knows the project is doomed (albeit well funded... for now). Where does one even go from here?
I work in a similar place now and have in the past. I've taken the following approach as much as possible: 1) Use the opportunity to learn new technology and toolchains regardless of applicability. This can greatly increase your worth when looking for jobs in the future. 2) Try to find things outside of work to give your days meaning. Find a hobby or side project. I started designing board games. This lets you treat work much more as a 9-5 punch the clock task and lets you look forward to working on your real project later.
It is still entirely frustrating to feel like you spend your days digging holes and filling them back in but you have to fill your days with your own meaningful purpose.
I've never been in this situation, but would it be possible to take some kind of unofficial leadership, and build your own product, without caring about the vague requirements?
Just do something cool, whatever.
Just take a few colleagues you trust/think might be willing to go along, brainstorm some ideas and go for it.
It feels to me like creating a company, but without the hard parts: you already have the money and the smart team.
Create your own startup from within.
I am currently employed to develop an entire data analytics system because a government department can't get their firewall rules right.
None of the members of this government department want a bespoke system, they want to use tools they are familiar with but due to the firewall rules this isn't possible.
It truly is fascinating, the world of tools and ecosystems built up to sidestep inane security rules in organizations.
Spoken from experience, this includes things like Anaconda in orgs where devs can’t use just any Python packages, or scripts from the internet copied and pasted into files because the firewall blocks git cloning. One could even consider AWS as a platform for devs to get around InfoSec red tape and have some semblance of control. The goal as a dev here is to fight the fewest fights to make tools available, by getting access to the biggest “bundles” of tooling they can.
In such organizations, there is either no concept of cost/benefit of overly restrictive firewall rules, etc, or the culture is such that the security team has become entrenched and unquestionable.
Can confirm. I’m able to spin up multiple sets of m5.24xlarge without anybody blinking twice, but I’m not trusted to spend money to buy a ballpoint, for which I’ll have to go through the whole PO process.
The disconnect here is unreal.
When the only tool you have is a hammer, everything by necessity becomes a nail.
We are required to use some internal assets, so I am using a combination of Flask, our "workflow execution platform", and some Amazon EC2, S3 and Glacier on the backend. Angular and a few data viz libraries for frontend.
For a couple of years now, I've been developing features for a product that hasn't found product-market fit. Features that nobody _really_ gives a shit about. I can talk directly to one of the cofounders, bring them evidence based on analytics or the past failings of the giants upon whose shoulders we're standing on. His response is, majority of the time, "yeah, I get that. We promised this to a few customers and I really think it'll work". It hasn't worked.
It's an iterative process. Our conversations have gotten better over the years. He has the connections and market knowledge so I have to respect his wishes most of the time. I make it sound bad but it's because I'm, like many of us, tired.
A small team in a company I worked for got into machine learning a few years back. They had some success with some toy examples and were now looking for applications. They tried to use it for optimizing some specific engineering procesess.
Two people (one was me) were warning them that this is a waste of time and will cost the company a fortune and then no one will want it because the quality will be so much poorer. And the whole thing looked like an instance of hammer-looking-for-a-nail.
Fast forward a few years, the team tripled in size, built a multi-million-euro product, and some very large customers now trust their operations research to that new thing.
It's hard to take a lesson from this without hearing why you think that happened. Do you think the product got so big because the team applied AI usefully and your initial evaluation was wrong? Or do you think they gained customers because there is not much competition in that niche and customers were drawn to the sales team's claims of AI despite the AI not being very good?
My personal takeaway was that I don't know as much as I think. I didn't produce any data at the time to prove my point (not that I would have known how to), and because of that it's hard for me to analyse the situation more meaningfully as to why I was wrong.
Why they were successful in the end: the team struggled for some time before they got momentum with a single really large customer that put in resources, and made other customers follow. It's not that the tech got better that much, customers were just more willing after they saw one of the leaders in that space invest in that approach, and they were afraid of falling behind. It was not because of machine learning, but despite of it.
So are you saying that the article is just written by "non-visonaries" who dont know what they are talking about? The old "If I had asked my customers for what they want, they would have said a faster horse"
Did anyone here work on implementing Bing web search into the Windows 10 start menu?
I'm curious to know the decisions that led to an operating system file search prompt ignoring exact file, directory and app names in favor of trying (and generally still failing) to show irrelevant web results.
Perhaps it was driven by the Bing team's request for more ad impressions. The Windows product manager might have wanted the feature to satisfy the Bing team, without deluding themselves into thinking Windows users would like the feature.
After years of low level annoyance, I looked up the regedit incantations needed to disable it. Now start menu search is amazingly snappy and only returns relevant results.
I listening to customers is not really something you can only do with agile scrum. You can figure out what customers need with roadmaps or projects too. Outside enterprise, you also don't have one set of customer/users, you have thousands or millions them.
I agile scrum often leads to situation iterate the teams iterate towards local optimization or solving problems that people think they need, but fails to deliver actually create next level impact, since teams are hesitant to make plans longer than in two week increments.
I think most successful product teams take the practice of closely listening to the users (as the whole team or product organization), trying to understand the user, but choose to build product they think is right, even it's not what the customers currently say they want.
> Don't just build Something™, build an industry leading product that customers want and love!
The point of writing software is to get paid. If the process leads to something actually useful, good on you. If not, you still got paid. It was just a drill, life continues.
It's really wild how different people's reasons can be for doing the same thing.
I think a better future world is still possible and needs to be built by passionate people. I'm in software to try to do my small part in getting there.
I probably won't succeed but that's why it's a BHAG. I also don't ever want kids, a spouse, and am perfectly happy riding the bus or a bike so yeah, my annual income needs are usually met somewhere around February and lounging around gets old eventually.
Your system sometimes works better ... I really can't do anything unless I'm passionate about it. I can sit in a chair from 6am-11pm and will get nothing done for weeks if I don't believe in it. It's stupid and I need to get over it.
I kinda wish someone waving some cash in front of my face was enough to get me to do something. That'd be much easier because I could be the one waving it.
That advice is OKish if you only ever want to be a mediocre employee clocking in to get your wages.
I think you need to be far more proactive in training your mind if you want to become a founder [edit: of a successful business], or move into more responsible roles, or even just to get satisfaction from shipping great software.
Why do you need to work up to being a founder? Any bozo can start something new especially given that the vast majority of start ups either never go anywhere or flame out somewhere in the first year or two. Even I've "become a founder" a couple of times.
a lot of people see being "a founder" as a goal because it gives you complete agency in your work.
you could in theory define it as having a sole-proprietorship type lifestyle business.
it's poignant in this thread because many people have worked on "meaningless" projects within a company for years on end - and you don't have a choice.
One of the major benefits to having a less invested attitude is that you are not as annoyed or disappointed when things don't work out. In the end, most of us do not have a stake in the product we are building and the success of the product has only minor effect on the developer, by understanding it's a job and not life you will be happier overall if the project does not succeed.
This is terrible advice and this type of thinking is a common indicator of an employee who is not motivated. The goal is to not just build but build products customers want.
That is highly subjective. Money is a motivation but some people seeks more from their jobs. I wouldn't work on a job if it is not really giving me a sense of accomplishment either.
I currently work on a project that has struggled to make actual sense for a few years now. Sure I like getting paid, but there's a growing void in my soul.
Jobs where this kind of attitude prevails suck to work at. Frustration waits around every corner. And the more pointless projects and dysfunction permeates a company the more chance the other shoe will come crashing down any moment and the company will fall apart and people will lose their jobs.
Highly anecdotal, but 100% of the software devs I know in this position (living paycheck to paycheck) are living above their means, in a city. If they moved to the countryside (in another country if need be), they would have to work 2 months a year with the same pay with a larger house, garden, savings etc. After covid it is actually easy to do, but before as well if you are not completely horrible at your job. However, they are never going to do it; they need to live where they live for some reason.
In that case; I do not get it. Moving is easy, at least in the EU. They could own their house (there are many houses for sale in villages and country across the EU for 50-100k with garden etc so even in a tight city wage you can immediately own and rapidly pay off a house) and suddenly save money. But then again, I am not attached to places and especially not cities (finally a lucky bet with covid) so maybe I just do not get it.
I feel like your version of reality is different to the one most people live in.
Highly skilled people live in big expensive cities because that's where the best jobs and most professional and social opportunities are.
Once you move to the countryside your jobs and networking opportunities plummet and you'll have to endure a soul crushing commute unless you work remotely or your house and your job are close to train stations on the same route, not to mention, at least in Austria, shit internet.
People want to live with or interact with like minded people and it's much easier to find what your looking for in a big city. The countryside is lonelier and more conservative.
Sure, you can have a lot of space and a garden, but not everyone is into that and most would prefer to have the amenities of a city: sports gyms, cinemas, cafes, bars, meetups, good doctors without having to drive everywhere or wait for a train.
Sure, my point is, then you have to suck up the fact that you live from paycheck to paycheck (which was what I was responding to). You don't need to but you choose to, that's fine.
And nah, never had this much work, my network is only growing (and I have not lived in a city for 20 years), I don't need to commute because remote work is great (for the past 25 years). I meet plenty of like minded people on the internet; for me that works. Not saying it's for anyone, but it works for me (and my family and friends by the way).
But yeah, everyone should do what they want and like; just saying there are alternatives if you don't want to live from paycheck to paycheck and live in a city.
Hah I live above my means and need a high salary _because_ I moved out into the countryside. Maybe it's different where you are, but living in the country is expensive. It won't look like it from the outside, but ...
My home insurance, my heating, my Internet, my electricity, all cost more than if I was urban. I own and maintain my own water supply and sewer system (septic). I have power lines coming up from the road, over a hedge of cedars that cost me $2000 to trim every few years or they'll impede the power lines. On my property, so mine to deal with.
I had to buy a little diesel tractor ($15,000), I had to buy a zero turn mower ($5000) because mowing 2.5acres (out of the 6 acres I have) would take forever otherwise. We need two cars because of where we are.
And property taxes are super high for me. They'd be cheaper if this was an active farm business making over $7000 CAD a year, but it's not. Because how could I do that while also working a full time job?
And yeah, the commute. Not fun. No gas costs really because I drive electric and plug in at work (and home), but still.
But I have chickens and an orchard and a woodworking shop, and make wine from my own vineyard, and have room in the garage for a Saab 900 SPG that I will restore...someday... and my kids have lots of yard to look out at while they sit inside instead and watch videos of people playing video games ...
I guess we live a similar life but in a different country (Canada vs Portugal?) which probably accounts for the difference. All those things you say are true but they just don't cost anything here and, besides that, it's mostly alway warm so those costs we don't have. I don't commute as I have forever worked from home (with rising salary, also forever).
We have chickens, many (fruit)trees, make beer, cider and wine. Outside gym. Pizza oven. It's great.
yeah, it's partially because i still need to be able to commute to work, so I have to be within the greater toronto/hamilton region, which is really expensive.
Nice! I been there many times. One of the things I would've told myself travelling back is to move to Canada in some mountain village. Too late now, but that always drew me there.
Agreed on that. Also, sometimes it is both. One does enjoy the parts of the job that provide satisfaction because most decent programmers by heart do enjoy fruitful creation. And then sometimes there are shitty pieces of work or dealing with people who are a piece of work. In such times, it actually helps to disassociate a bit from the work and look at the monetary side - until the sky clears. The key point is _sometimes_ and the expectation that the sky _does_ clear.
To be clear, I don't suggest this to those who are in the throes of software engineering passion and their work is part of who they are - sometimes may be too many times for them.
Don't get me wrong, that's me. I have two kids, a wife, and a hobby farm to pay for. But a shitty work environment is still shitty, and it's not like there aren't lots of jobs to choose from in our industry...
I agree with you, but I would add that on most software projects it's possible to find a way to derive satisfaction from the work.
Solving problems and writing elegant code is good, whether it's running the next Amazon or streaming intrusive ads to a Smart Toothbrush or whatever. (I'd draw a line at weapons systems, gambling, automated extortion etc - but YMMV.)
Economic value rarely correlates to more 'human' measures of value - which is depressing but nevertheless useful to me as someone whose skills are societally useless but moderately lucrative. I suspect many of us here are in the same boat.
Except when management finally wises up and realizes the product has no future... neither do you.
Much better to look around and find the product/project that is actually going to spawn revenue for the company and get on that team. When layoffs come, you've a much better chance of weathering the storm.*
* No guarantee that management won't do something stupid and lay off the golden egg under some stubborn belief the money sink will someday take off.
True, but I think we can separate the idea from the person/company.
The problem statement is very well written. The Director of Engineering rotating because they can’t deliver, and the battle between Product and Engineering.
Conclusion is rushed, but it boils down to what agile advocates at the core: product manager and QA need to be in the room along with engineering.
It is until they hear daily about the challenges, first hand, and they see the struggle that it makes sense. Does not matter how many reports the PM does, first have seeing why technical debt is making things slow is invaluable.
Only addition I would add is: there is a reason why sprint waterfalls exist. You can’t iterate forever, and someone needs to play the role of the mature person that knows when something is good enough and needs to be shipped. I think Agile as a framework is at its limits. We need something that lets us run the engineering but at the same time becomes more predictable to business.
I suppose I'm tainted because I've seen one too many methodology consultants. "What you're doing now is bad...but this new way will solve all your problems.." Enter "Value Scrum" your new savior.
After almost 3 decades in software, I've come to perceive a few things about the industry and the people in it, especially the new entrants:
1) All problems begin with "how can we solve this with new software/feature/etc?" because after all, we're software people and we make software so clearly software is the answer.
2) Society believes #1. They expect that all problems are solved with software. Not only does society believe this, VCs believe this also. There is incentive to behave as #1 in the hopes that it leads to $$$.
3) Anyone not believing #1 is a detractor, or worse, a Luddite. Technology as solution is the prevailing axiom. It is Maslow's hammer. All non-believers must be purged or cancelled.
So when I read what I'll admit is an enticing article that demonstrates experience and analytical thinking by the author I'm intrigued and mostly supportive. Just like software frameworks (yes, you Javascript community) the answer to problems is always a new present solution which one day will be a future problem whether it be tech or tech inspired methodology. Tech first problem solving usually always leads here.
I was also struck by an adaption of a statement I read once about XML. The adaptation follows: "Agile is like violence, if it isn't working you're not using enough of it."
So what does this mean, abandon all tech? No. It means, apply critical thinking. Let dissent be ok. Do the things the article suggests. You don't need training, or a seminar or a consultant. And if the leadership wants to do something you can't fully engage in, find something else to do. Don't waste your life.
Agencies and consulting companies have built their fortune on clueless customers. But I honestly don't really care anymore. I just want to write code and go home
> Don't just build Something™, build an industry leading product that customers want and love!
One of the biggest challenges is that someone eventually has to say "no" for that to happen. It is easier to just say yes to whatever is wanted than fight with someone about doing it.
I am working with Start-ups since 2008 - and classic companies before that.
My chances to know beforehand what customers want is 50/50.*
So I am very humble by now. Launch super early. Get Feedback. Quantity wise and quality feedback (listen closely if you made their life any better). Iterrate and/or change path.
Yes, like flipping a coin. Sad that, quite a lot of managers have a way lower hit rate as they have an inherent ”the customer is like me and users are stupid” bias (both at the same time, so that makes them...)
I wonder what is the chance if you are following the "worst" practices?
User is stupid -mentality, being a dictator and not explaining why things are done the way they are, etc... Id expect it to be lower, but not that much lower. Luck is a major component because new product development is basically forecasting the future. There are so many things which are out of your control. If you get lucky 4/10 times with worst practices and 5/10 times with best practices, it does not really matter.
Besides, it makes a much better story that you only knew how others are stupid and because of this only you could do the right solution. Whole western society loves the myth of intelligent jerks... Like Steve Jobs. "it's ok to be an asshole if you are smart".
> My chances to know beforehand what customers want is 50/50.*
It probably is not 50/50 for literally any idea, it is maybe 50/50 for well considered ideas, but even then I doubt it. I am pretty sure there are things which you clearly know will not go down well with your customers, or that your customers won't care for.
Worse is when you know another part of the company is sabotaging what your trying to achieve.
One might call it the right hand competing with the left, but frequently the path forward to the next version/product/whatever is pretty clear, but the existing product teams are well entrenched and of course make all the $$$$, so its a game of politics, and keeping a low profile while trying to gain traction.
Pretty frustrating in many ways. Especially when you start to gain traction, then suddenly groups start to take 1/2 steps, which might have been useful and productive years earlier but now just act subversively.
In my previous work, I learnt that two teams could write two solutions tackling the same problem. After two years, they would each present their solution and the hierarchy will keep one.
This article makes me feel very fortunate to work the way we do in my company. We have tight feedback loops with our users, we plan work together as a team (not just a PM dictating things), we're not forced to give finger-in-the-air estimates (we work on stuff until it's good enough to ship and then ship it) and we follow up with analytics and user interviews to figure out if we achieved the outcome we were after. We rinse and we repeat.
Can you say more about how you plan work as a team? Interested to hear how you keep this fast and productive and avoid getting caught in the weeds of other's opinions.
I'd say the main factors that avoid getting stuck in the weeds of opinion vs. opinion are:
- Focus on the outcomes you want to achieve, not the exact thing you're building or the way you're building it. This should be based on the needs of your users. Of course there are exceptions like refactoring tasks, infrastructure improvements, etc.
- Give people a lot of autonomy on how they achieve the desired outcome
- Work together across product, engineering and design so people's opinions are heard early and often
- Ultimately have a "boss" who can stop the endless discussions if it comes to that (doesn't happen often)
Another thing is if you feel like you're iterating quickly, you feel less like stuff is set in stone and that results in less analysis paralysis and less bikeshedding.
I have in the past with (small) clients. This was an upgrade to an existing product with flagging sales and their proposed direction made me scratch my head from day one.
However, I both wanted to do the work (it was really interesting by itself) and they made it clear to me that they didn't want my business input. It of course eventually went sideways, accusations were thrown around, the partners split up and I was left with ~18 months of unfinished work that didn't really get me anywhere (except paid -- never, ever risk your time for someone else's upside).
I'd say do the work if it's personally edifying and you don't mind the possibility of weak-minded people trying to throw you under the bus when it falls apart. If you're an employee, you are not shouldering the risk or responsible for existential-level decisions (or at least shouldn't be).
Having said that, seek out better teams with a higher chance of success if you can. Bad teams are sometimes hard to spot because they may look successful on the surface but may, in fact, be a few bad decisions away from falling apart.
One thing to look out for is founders who have a company because of an initial period of luck but questionable direction and drive to build something more sustainable (or larger). I've seen that a lot, even in myself when I was younger. People incorrectly attribute their success to their skills / vision / mojo and have enough runway that they internalize those beliefs while ignoring the slow death of their project.
It's hard to separate that misguided exuberance from a healthier drive. A good sign is when they temper their confidence with humility -- "we really got the timing right on the first one". If instead they talk about how they're crushing it and how "number 2 is going to be 10x" you might want to rethink hitching your wagon to them. In other words, if a founder ever makes you cringe while talking about themselves, that's probably your intuition telling you they don't really have what it takes.
Nice write up of the problem, but the solution is not that simple. Not saying that you shouldn't try, but the problem of doing something that customers want is extremely difficult and has a lot to do with luck. We have implemented many features no one wants, and many features that the users wanted and use. It's impossible to know the outcome beforehand. We have always discussed with the customers before hand, but that does not mean the feature is going to be used. Even when customers are paying for something it does not mean they really use it. So "Don't just build Something™, build an industry leading product that customers want and love" is nice and catchy, but the reality is never going to be that easy. And how do you even know if you just did it the wrong way? If a small change would have changed everything? You can't really trust people either because they don't know what they want. You can't trust analytics because you don't know if you are measuring right things? When do you know that no one wants a particular feature?
Putting yourself to a pedestal because you've figured out a problem won't help for sure. Be humble and accept that figuring out the right thing is hard work. Most often people are doing their best, working in silos or else where. Most product managers are not there to make your life terrible, even though you might think that way from the article.
This would be an interesting ask HN. I dont think theres much to discuss on the actual link since it looks like its just some sort of ad for some training program?
It's inevitable, isn't it, given that we have to work for a living?
In school they call it 'procrastinating', when you're supposed to be doing an assignment, but you're doing everything but the assignment?
You can force people to do the bare minimum - I just don't know how long we can have enough jobs where the bare minimum is better than not doing it at all, or automating it in some fashion.
This is the question of the 21st century and I'm afraid it'll only be the upcoming generation of politicians like Andrew Yang who even stand a chance of answering it in a way that doesn't lead to significant civil unrest.
Sadly most of the software I have developed has been "something no-one wants", but I keep trying because if I ever do build something people want then that's my greatest professional life goal met.
Very often, that someone isn’t the customer, but someone in the team’s management heirarchy, and usually those tasks are both prioritized and poorly specified and subject to worse requirements flux than customer requirements (unsurprising, since customer requirements are based on actual business needs, while management requirements are based on whims, flights of fancy, that-comment-a-higher-level-manager-just-made-that-gave-me-an-idea-of-how-to-impress-them, etc.)
Agile methodologies at the team level don’t really protect against that, though.
Due date driven work isn’t necessarily because that’s copied from manufacturing. It often seems to be just an accountability and planning measure. Ie if we (stakeholders) know the thing will be delivered in June, then I can launch my thing in July and I build that into my forecasts.
If there were no deadlines for features And teams could pivot willy billy based on whatever they find, cross functional planning would probably be difficult.
I think the right hybrid for larger companies is some agree on cadence for adjustments in direction based on customer feedback / learnings (eg quarterly)
At my company due dates are used purely as motivators. Every date promised to upper management is absurdly aggressive. I'm told this is meant to instill a "sense of urgency" to motivate people. It makes new hires burn themselves out. The few who survive the pressure eventually realize it's all a show and just get used to apologizing for all their "failures."
This all seems a little back to front - engineering in a vacuum. I mean sure it solves the problems the engineering team has but at the cost of making everyone else's job near impossible.
"Date scrum" isn't an anti-pattern, it's a basic requirement. e.g.
Sales staff: Please buy our product
Customer: Cool. Can I see it?
Sales staff: Not ready yet
Customer: OK when will it be ready?
Sales staff: No idea. Whenever the engineers are done "discovering the best solution". Also, please sign here to commit X millions for a solution not yet discovered that will be delivered by an unknown date.
This seems obvious to non-sales folks: why would you like to a potential customer about what you're selling? But for some reason, it's common enough that every software engineer I've ever known has experience with salespeople attempting to sell things that aren't ready or don't even exist. When customers push back, Sales comes to engineering with "we can't make this sale until we've built X. can you have that by Friday so I can get this deal signed?"
>Don’t try to sell a product that doesn’t exist yet?
To be brutally blunt - that's a genuine engineer question.
If sales staff only sold what is ready to go right now they'd be ten miles behind the competition and out of business within a year. (And engineers would be laid off)
Cutting edge is the bleeding edge here. Sales pushes products that barely exist and engineering float solutions that aren't quite production ready. Whatever company cuts those two factors closest to the bleeding edge without bleeding out wins.
(And no I'm not in sales, just arguing a strong sales perspective for balance cause hn isn't sales crew)
I work as a product owner in a company described almost exactly by this article. We shipped our important feature last month and nobody's used it yet. We have a product team totally separate from the engineering department and they come up with the ideas that we build. My input on the product is valued only at fairly low levels, around detailed implementation (how buttons should work, whether users will likely figure something out). I really don't like it, but at my level, I don't know what I can do.
My primary approach to address this is to push for improved data analytics, starting with our tracking and pipelines. I do think a data-driven culture can help lead the team/company in the right direction, and that it can spread from my level. Progress is being made, albeit slowly.
Execs have some lofty goals of changing the paradigm, but I don't see that happening in the next 2-3 years. Any advice on how I can help effect meaningful change from my position? Or perhaps could I be better served working somewhere else, building better habits.
I have a weird story of the same type, I developed a new module on the product (Quite an obvious one, no need to educate users), and got very little traction, but after 2 years, but reports and support started piling in. My new interpretation is that we just had to let the market pick up on it and do its transition at its own pace (I don’t know if development is paid for yet).
IMO, that's the biggest sign that your job's not going to last very long.
I remember partial involvement in a major feature that I thought was kind of lame; but it pulled in quite a few engineers and was a major deliverable. I thought to myself, "huh, I guess customers will actually pay for this?"
Then later I found out that no one actually bought the feature.
This happens so much, I wonder what the effect would be if management actually got honest feedback and listened to it. I think often the engineers implementing things know if they will work or not but their opinions are ignored, if they are even brave enough to point out the things that won't work. It's the curse of the employee relationship. Employees don't want to stir things up, so they do what management wants, despite their experience telling them it'll fail. This is why I don't view success as connected to whether a project is financially successful or not. Success is pushing to production. That's all.
In this case, we (engineers) had a lot of trust with management because usually features were developed with lots of customer involvement. (And when features weren't, they were usually MVP-style to test-market something.)
So, in this case, I pointed out some limitations and immediately got back an answer that implied that the customer was aware of the limitations and was more concerned about something else.
That's why I was shocked to find out no one bought it!
Anyway, to further add insult to injury, the new feature added lots of complexity to the product; complexity that added development cost to further development.
I worked in a startup, that had around 30 employees (15 in tech at the time) and we had a good product that sold like hot cakes. But due to some issues the company closed that product down. Anyways, we were looking for new ideas.
There was this new guy who was previously in business development and customer support and somehow had got his role changed to associate product manager by talking to CEO, about his passion etc. He suggested a product by reading about a recently funded company in USA. I, a product manager and another one of the product manager, simply rejected the idea given very small market size and complexity of the product and technology required. But CEO bypassed our suggestion and we did build that product for more than 2 years, putting in tons of effort and resources, perfecting it but even then there was hardly any noticeable sales.
"Customer involved every day" doesn't necessarily mean that you let the architecture or product be designed strictly for the customers need. Point is to have as much user feedback as possible, to take into consideration (or purposefully say "we're not considering that").
To end up with a useful product in the end, it's better to err on the side of involving the user too much, than too little.
I worked at a major defense contractor in a small office for as an intern. The entire 50 person office was working on a single top-secret contract which very obviously was never going to get off the ground. After working on it for over 5 years, the prototype was still about as janky as could be and required a team of human operators to perform dangerous, highly intensive, time-intensive-training-necessary work just to get it to work. No one could say anything because everyone would be out of a job, and so, as far as I know, the project hobbles on.
I work for a bank and we’re rolling out later this year some new accounting management software for our users, to help them keep track of their budgets etc. Over the last seven years or so I have myself tried using such tools at various banks I have accounts at, and I could never get into it never really enjoyed it. I do use accounting software that is entirely separate from my bank. And some of the ones I used to use were discontinued, perhaps due to lack of interest. So I’m rather certain that what we’re working on is probably not gonna be successful.
Don't want this to turn into a big politics tangent, but I've thought that one use case for a tech workers union is to be able to push back against questionable business decisions from management.
I've seen places where engineers and other ICs, some team leads and managers, those with far more experience and clout at me, voice skepticism against questionable product decisions coming from upper management, only to receive nothing in response. Even when these decisions involve infeasible engineering forecasts, leadership stay the course. The worst they might get is some uncomfortable questions from the most bold, outspoken senior or staff engineers during all-hands. And the response is usually some stock party line about staying the course and everything will work out. Sometimes, this is coupled with toxic cultures that prevent people from truly speaking out.
Beyond fighting for better labor conditions, an intracompany tech worker organization should be able to push back against bad management decisions. Imagine if your engineering guild had power not just to determine the tech stack or coordinate between teams, but also to check the power of management on product and technical decisions, or even question strategic business decisions.
People imagine tech unions will just be a rehash of Industrial Era blue collar unions, but they have the potential to be something more- a way for the rank and file to finally have the clout to push back against bad engineering decisions from poor leadership.
Sure, you can say disgruntled engineers can just leave, or companies with bad management cultures should deserve to fail. But that just seems like defeatism. It seems like a form of capitalism that promotes throwaway, wasteful behavior. If employees have valid concerns, but management ignores them, doesn't it seem like a shame for an organization to decline and the product to die because of no one could oppose management's mistakes? What about the customers?
That's honestly not a bad idea- I've seen high exec turnover resulting from their own mistakes, and much of the engineering team might have been happier together under different leadership. Worked for Fairchild Semiconductor, I suppose.
Who's to say that technical priorities aren't worth prioritizing? How many times do companies treat their tech as a cost center rather than a profit center, leading to expensive mistakes? I don't understand why one would want to be an apologist for the Pointy-Haired Bosses, unless they themselves are in management.
Everyone thinks corporate fiat rule is the best way to lead- until they find themselves outvoted on a stupid initiative. Perhaps the right way to respond to it is to vote with your feet, and leave. But again, that seems like a waste if the course is salvageable.
> People imagine tech unions will just be a rehash of Industrial Era blue collar unions, but they have the potential to be something more- a way for the rank and file to finally have the clout to push back against bad engineering decisions from poor leadership.
They probably ought to promote those organisations under a different name then.
I don't know if this counts. I worked briefly at a place that was making sensors for fitbit-style wearable medical devices. One thing that was really cool was a device that could measure your blood alcohol level. They were trying to miniaturize it to fit in a watch or whatever.
The investors and intended market are a staunchly Muslim oil oligarchy.
(In case it's not clear: ¿ɥǝ 'sɯǝlqoɹd ǝq ʇɥƃᴉɯ ǝɹǝɥʇ sɹǝlɐʇoʇǝǝʇ ɟo uoᴉʇɐu ɐ oʇ sɹosuǝs ǝzooq lɐuosɹǝd ɔᴉʇɐɯoʇnɐ ǝɔnpoɹʇuᴉ noʎ ɟI )
I had one of these, I found my writeup again today. It had an embedded copy of OpenOffice to read .doc files. https://reddragdiva.dreamwidth.org/599841.html Also, the specification implicitly required the implementation of strong artificial intelligence.
Not meaning to make sweeping generalisations, but in my experience, any company that mentions AI or machine learning too many times in there promo material seems to fall into the rather unfortunate categories of "working on something that no one wants" and "working on something unlikely to yield useful results"
No. We know people want this. Many existing customers joined the wait list to try it, and a few employees are using a ludicrously inadequate alpha version.
We might get the details wrong, but somebody is going to make a killing with this in the next few years.
Many of the features can be a total waste of time, true, once we spent 3/4 of a budget building UI for the product whose biggest customers (95% profit) never used UI. But then again, business plans change, some features need to be customer-tested, etc.
at the previous company i worked for, we were developing several products that either no one wanted or were so bad you wouldn't use even if you could for free (i didn't even install the app thing on my phone because of how morally corrupt our mobile team was).
we had bizdev guys running around making deals in third world countries, and pr dept. working overtime just to create the illusion something was moving. r&d dept went through like 3 org restructures within span of 6 months, for no reason other than to satisfy the ego of r&d vp. i mean, i've seen politics that would make machiavelli seem virtuous by comparison.
This is pretty common in government. We have way too much duplication between projects so somebody gets the bright idea to replace all the standards with one standard but it doesn't get traction and basically doesn't get used.
No quite as bad as that, but we are a feature factory, expecting the next big contract to make it. Instead we keep on adding tons of features to an already large product with a tiny team.
Throwaway on this guy, but I actually was ground zero on a project like this. The rabbit hole went incredibly deep.
I was a pretty new hire at a small computer repair company with an absolutely manic CEO. The guy was an egomaniac and thought that because he owned a computer repair company (mind you, he has zero tech skills, his partner was the one who did all of that), he was the next Steve Jobs.
I originally got hired at the company to do work on their web SEO "business division".
By "business division", it was a 12 man team building Wordpress sites for about 5 clients. No version control, no backups (unless you count zipping the WP install and leaving the archive in the same directory on the server), paying nearly $1200 for Enterprise Azure for traffic that didn't even equal 10,000 hits/mo across all clients.
It eventually got around I knew what I was doing, so I got pulled off to another project--one to architect a custom backend for a new idea the CEO had.
One of the other coworkers at the company (who did everything in PHP--and I mean literally everything), had built a wheel interface in a web browser.
The CEO saw the wheel, and decided that the interface was going to be a social media app. Literally form over function.
The app quickly got convoluted because there was literally zero project management. We would literally get ideas from the CEO in an email and we'd start to work on it until he got the next big idea. There was zero accountability to what we were building. We would be interfaces and logic that would get torn down or hacked 6 months down the line. We spent literal months building this convoluted 6-7 layer deep wheel interface to make a Yelp rip-off clone.
Imagine you wanted an estate lawyer? You would have a wheel of 7 elements. One was "professional services". You'd circle the wheel around and click on it. You'd then get 7 more wheel elements. You'd circle the wheel around to "lawyers". Once on lawyers, you'd scroll around until you found the icon for "estate lawyer" and when you hovered to it, you'd get an interface on the top of recommended lawyers based on some constantly changing algorithm of friend recommendations and geo locations.
This app was in development for nearly a year and didn't see a single user until around 9 months in (where we posted "gigs" to Craiglist, promising money if you were a "top user", but I don't think anyone got paid).
We never did a formal launch because we kept building and building and building.
We added business recommendations first.
Then it became movies and other media.
Then we build a friends list that let you put in contact information about your friends (we rebuilt contact list).
Then we built a tracker that would ping your location at few minute intervals and store it and a timestamp on our server.
Then we built an aggressive scraper that would scrape your call history and contact list, store it to our server in plaintext, and then query each phone number in a plaintext query to Google to see if we could match it.
We build a "pre-fetcher" that would aggregate data and scrape images from Google Images and build business profiles we'd pass off as our own.
The list went on and on and on--all while rebuilding the friends privacy settings over and over.
The entire time, I desperately wanted to find a new job, but couldn't because the economy was shit. I constantly was berated and yelled at. Promised equity but never got a statement. Pay was terrible (they bait and switched me with the SEO pay).
Finally after some unreasonable disagreement with the CEO, I was "indefinitely on unpaid leave" (I was basically fired without being fired), so I just quit. I got a call with a death threat days later.
Luckily, I landed another small time job shortly after. I ended up suing the previous company, but they hired the biggest defense firm in the state to stall out--so my lawyer bailed. Not before they called me, leaving me a second death threat for hiring a lawyer.
> Instead, they are usually focused on making sure the team is building what their boss thinks should be built.
This rings so true. I vowed to never again work with companies with non technical leadership for this reason. My career so far has mostly been building features nobody wanted for people who are trying to impress management and/or VCs.
> The less technical the dev manager is, the more likely they are to be ignorant of technical debt, that is until customer escalations become politically untenable. This life cycle is why the engineering VP job has about a one year lifespan at many companies who run Idea Silos.
I've never heard of this concept of idea silos before. It makes so much sense. At my last company it was even worse. I had 4 managers over 2 years, yet the more senior management gave the VP of engineering free reign to make whatever changes he wanted (yes, they were all men), so the system was a cobbled-together mess of half baked features as a result of each manager coming in trying to make sweeping changes to show off their "scrum" skills.
> Engineers are problem solvers, and if the primary problem becomes delivering Something™ that will pass QA by the Date™, they will, with enough pressure, solve that exact problem.
Ahhh I can't even handle how accurate this is. You should have seen the spreadsheets and meetings we had about sizing and building roadmaps. The entire engineering department's job became keeping managers at bay by producing roadmap items on schedule. There were meetings upon meetings about "metrics", which were just numbers we made up but put into a fancy spreadsheet, because doing calculations on made up numbers makes them appear more legitimate than raw made up numbers.
The majority of the effort of our department was wasted on features nobody wanted. They sounded impressive and apparently were cool enough to keep investors satisfied. This company also went to great lengths to re-brand itself as an "AI" company, whatever that means, even though none of the people in charge had the slightest idea what AI was really capable of or how it would benefit the business.
The worst part is that it took so long for me to realize I was wasting my time. After the third major feature I delivered to be used by absolutely nobody I realized we were out of sync with reality. I thought I had made this great discovery and was almost excited to bring it up because I thought it would be a great opportunity to change to do better by our customers. Instead I was met with a response that essentially amounted to "shut up, know your place, and give me code", which is when I realized I was really just a cog in this machine designed to get engineering VPs bullet points for their CVs, and left.
My manager (a director) at a FAANG used to give me (and only me, justified with my strong background - though he used similar tactics on others) tasks that couldn't be solved and didn't have any business justification so he could keep me from getting promoted. The first few promotion cycles I still tried to find alternatives (X doesn't make sense, but Y would reach similar goals in a reasonable way), but the motives were quite clear.
At first I was looking for ways to move within the company (I was hired in the wrong part of the organization and on the wrong level, making this a bit difficult) and started working with other teams to be able to switch, but I realized it wasn't really worth it because most teams were building things that were very strongly driven by VPs and directors own motives rather than users or even what is good for the business. [1]
My impression was that this is partially driven by several factors:
- the very strong market position means customers don't really have a choice. It's actually rather hard to make good decisions when the market can't give you good signals. Situations would arise where one customer wants something, another wants the opposite and both may have a negative short-term impact on the bottom line. The lack of competition to really verify which decision would be successful gives too much power to the decision maker with really bad incentives, leading to some suboptimal decisions (unless there's a strong long-term strategy that is followed through).
- the drive to make "data driven" decisions, without understanding what that really means. Depending on how the data was presented, completely different conclusions were possible and instead of using common sense with the data, this was treated as an absolute truth to end many discussions. What quite frequently would happen was optimizing towards the wrong metric or underestimating bias.
- Silos created by people who were hired at a different stage of the company. Some of the managers just hadn't grown with the company - people who were around for 10+ years were hired for much smaller revenue und user numbers and this further increased the problems with the two points above. My impression was that the incentives weren't well aligned with overall goals of the specific product.
I think the solution in the article above would be a good way to avoid some of the problems I've encountered, by creating a more direct feedback loop between the product and the sales side and aligning incentives better. I don't think it's the best way how many companies grow with very diverse sets of offerings to have huge sales and engineerings orgs, rather than smaller groups that cover the product end-to-end. It's still possible to have many of the benefits of being a large enterprise (shared talent pool, operational processes, costs etc.), while avoiding the drawbacks.
[1]: I can't share evidence, but this particular company is well known for discontinuing popular services.
We are doing absolutely inane projects that have no hope of succeeding.
We serve a niche industry where certified professionals have to do certain tasks personally, instead of being able to delegate to secretaries. Somehow our CEO has been convinced that AI can be trained to do these tasks, at a reliability level not achievable by other humans.
Team motivation is in a weird space: everyone is relaxed because there is no pressure to succeed - we all know the project will fail unless someone develops well-perfoming, human-level AGI before Q4/2020. Lots of long lunches and checking out early in the afternoon.
At the same time, everyone is worried how terrible the fallout is going to be once the project reaches its inevitable conclusion.
Interesting times, but at least we can now tell investors we are a keen company with an AI play up our sleeve!