UI is a function of your organization

https://blog.jim-nielsen.com/2024/ui-fn-org/

by damethos • 2 years ago

173 113 2 years ago

gjvc• 2 years ago

and the fact that the same tropes are recapitulated over and over again without any reference to prior art. Alan Kay is correct; computing is a pop culture.

reubenmorais• 2 years ago

Reminds me of the Free Energy principle a bit: https://en.wikipedia.org/wiki/Free_energy_principle

andsoitis2• 2 years ago

Conway’s Law from 1967.

[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin E. Conway, How Do Committees Invent?

junon• 2 years ago

I've never really agreed with this assertion. What gives it the weight of being an axiom?

pavlov• 2 years ago

Communication flows create dependency points that limit what the design can be.

Consider an organization that designs broom handles. They have an industrial design department that selects the shape and material, and a market research department that selects the color and packaging to fit current trends. If the market research is purely downstream from the industrial design, their feedback can never affect the tactile properties of the product, thus limiting the range of possible designs.

Replace the physical product with an abstract system, and the same design dependency issues apply.

btbuildem4• 2 years ago

I would say it's very hard if not impossible to find a counterexample.

munificent• 2 years ago

Conway's basic argument is pretty simple:

1. For any two software systems to interact, they must use some sort of agreed API or protocol.

2. In order to have that agreed API or protocol, the teams building those two systems must communicate in some way (even if it's just one-way communation where one team documents an API and the other consumes it).

3. Therefore, the communication structures of the software system will reflect the communication structures of the organization. So the software architecture mirrors the org chart.

lylejantzi3rd• 2 years ago

The Only Unbreakable Law - Conway's Law.

https://www.youtube.com/watch?v=5IUj1EZwpJY

tobr• 2 years ago

Is this a response to UI = f(statesⁿ)[1] or are they both a response to something else?

1: https://daverupert.com/2024/02/ui-states/

alias_neo• 2 years ago

So who's going to tell us that the Domino's Pizza Tracker is just a timer?

I don't eat there often, but when I have, the Pizza sits in QA for about 10 minutes, then is "out for delivery for about 15, despite the fact I could literally walk to the place in 15 minutes, and they sure as heck and walking my pizza to me.

Then there's the fact that they outright lie by saying it has been delivered, then turning up about 10 minutes later.

Between the fact it's not the best pizza and this dodgy behaviour, they pretty much make sure I don't eat from there more often than about quarterly.

xnorswap2• 2 years ago

It's a failure of incentives for accurate tracking.

It's the same reason that when you buy from McDonald's, the order shows on the screen as "ready for collection" then "collected", then disappears from the screen well before the food has hit the counter at all.

The staff are incentivised to just press everything through the system asap regardless of the actual status of the food. They're presumably performance-measured against targets and aren't punished for just checking that everything went through quickly regardless of the reality.

Domino's are particularly bad (or noticeably bad) for it.

It's an important lesson about remote top down control and a failure mode of JIT systems. I've long wanted to prepare a proper blog post about this exact phenomenon using Domino's and McDonald's as examples, but I haven't put in the effort to collect the right evidence to fully understand the negative effects of IT systems misrepresenting reality.

shaan7• 2 years ago

Yup. I pickup my orders from Domino's quite regularly and it the tracker is reliable. The only thing that does happen is that they sometimes do mark it "Ready for pickup" while someone still needs to take the pizza from the oven and put it into a box. So I sometimes wait a minute seconds at the counter for that to happen.

madeofpalk• 2 years ago

If you've ever been told to wait in the parking lot at a fast food drive through, it's because the store has a metric on dwell time and throughput that they're optimising for.

wkat42423• 2 years ago

Yes this is really dumb at McDonald's. Very confusing. I'm surprised nobody checks for this practice.

But in my area they now do table delivery so I tend to use that.

Ps: it's really funny to see McDonald's proudly advertising table service as if it's some cool new thing they invented :)

kayodelycaon• 2 years ago

I worked at McDonald's briefly 15 years ago. Every single person bagging would mark an order as completed when someone started working on it and then use the recall button to see what the order was.

nebula88044• 2 years ago

If you go observe the restaurant (or work there for some time) you'll notice that these failures generally occur during crunch time because the screens that instruct what is in the order become overfilled with too many orders. Nevertheless, if you are present you can observe the build process of your food and see that typically it is generally within the correct time window.

The staff are incentivised to just press everything through the system asap regardless of the actual status of the food. They're presumably performance-measured against targets and aren't punished for just checking that everything went through quickly regardless of the reality.

But at the end they are still required to deliver the food or else there will be worse consequences. It is just not realistic to expect perfection in a noisy system where you can't exactly predict how many people will come during a busy hour. Mcdonalds is trying to improve with their massive data collection operations. Things such as reading your license plates in the drive through are not only just a profit making scheme: they help predict analytics on what you may order and the goal is to improve wait times during busy hours.

theolivenbaum• 2 years ago

We used to use an app from a startup for local orders that would always say 17 minutes to pickup. They couldn't estimate the time, so just used a number that didn't look like it was hard coded. Took some time for us to realize the lie and stop trusting it

nebula88044• 2 years ago

The Dominoes operation is pretty digitized. If its 15 minutes away you can go and watch the order made live.

As soon as the order comes in, it pops up on their screen. Is the restaurant busy? That would affect the time.

From there, the person assembles it (you can usually see this from the order counter) and then he pops it into the oven with the constantly moving rack.

This part is limited by the speed of the rack so there is a lower time bound where you cannot go under or your pizza is uncocked. Asked for well done? Well it goes back into the oven after coming out.

If you are there you eliminate the time from when the pizza comes out and it waits for the delivery driver to pick it up and deliver it. He could be out delivering something else or there could be traffic on the way to you.

You can walk in, place the order, and pay..then watch the order process begin in front of you and get the best possible pizza.

exabrial• 2 years ago

I used to think Apple was the king of UIs.

They have long departed from quality and functionality; Jobs has a no nonsense approach where form followed functionality. If it functioned properly, the form was intuitive. Apple UI interfaces from the Jobs years were incredible. Nowadays, under forced yearly redesign policy, we’re reversed so far things are just hidden and awkward.

Kinda funny: you force it and it sucks.

andsoitis2• 2 years ago

I used to think Apple was the king of UIs.

The way I see it is that Apple excels at designing and building UI patterns and systems (I don't think anyone comes close), but they're terrible when it comes to the UI of actual software products.

velcrovan3• 2 years ago

For UI patterns and systems, do you have a post-Jobs example?

I'm thinking the word in that last sentence should be “excelled” (past tense).

donatj• 2 years ago

See: System Settings

System Preferences I could pretty intuitively find anything I was looking for. The newer System Settings is basically unusable outside of search

Jgrubb• 2 years ago

My work laptop recently started having issues with the keyboard so I got a loaner, an unopened M1 Pro. It was still on an older version of the Mac OS, and I am so bummed that they want it back.

The UI that you're referring to is malpractice.

wkat42423• 2 years ago

System preferences was a really poor design tbh. It just felt so easy because it had been there so long and everyone had the muscle memory.

The new one is not much better I agree. But the old one was objectively not great in terms of UX Design.

The main problem with the new one in my opinion is that they're shoehorning a mobile experience on the Mac. Something Apple does more and more (and not just Apple, gnome does it too)

MajimasEyepatch2• 2 years ago

Honestly, I'm not even sure that this is a problem that can be solved. There are too many settings you could access, with no obvious single way to categorize them all. Search is probably the best you can do.

bastardoperator• 2 years ago

Does this include the use of cmd+spacebar? Personally, I feel like I haven't had to open it outside of my search.

agloe_dreams2• 2 years ago

The best example of this is the macOS document proxies. They were a sensical representation of an icon you can drag and drop, now they are hidden under a hover of the title that stupidly animates it out.

Anybody would would make a critical productivity feature a hidden hover should be canned from a UX team. This choice was defended by Alan Dye.

pimlottc• 2 years ago

Sorry, what are document proxies?

EDIT: Oh, is this it? [0]. I can't say I ever noticed that before (when it still existed)

0: https://osxdaily.com/2014/08/20/open-files-new-app-proxy-ico...

amelius• 2 years ago

I used to think Apple was the king of UIs.

Heh. There was a time when you had to upgrade your OS by ... first going into iTunes. Maybe this is still the case.

https://support.apple.com/en-us/108964

tomjakubowski2• 2 years ago

You're talking about iOS. We can only judge these things in context. What was the first Android version where everyone could receive updates for the OS over-the-air, not going through a computer + USB port? And when did Apple support the same for iOS?

socialentp• 2 years ago

Steven Sinofsky wrote about this in the context of the early days of Microsoft in “Don’t ship the org chart” https://hardcoresoftware.learningbyshipping.com/p/047-dont-s...

hitekker• 2 years ago

I'm pretty skeptical of what Sinofsky says. Back in the day, former Microsoft employees called out the differences between what he said and what he did, i.e. "Don't ship the org chart" -> his own org ships the org chart.

https://news.ycombinator.com/item?id=4778996

https://news.ycombinator.com/item?id=4776031

canucker2016• 2 years ago

One of the hilarious exchanges (pun intended) that happened on Sinofsky's blog concerned MS Exchange. The executive-level view of events is vastly different from the actual events.

tl;dr:

Stevesi (Technical Assistant to BillG): Mgmt forced Exchange to use NT Directory (followed by glowing description of the NT directory)

DonH (Exchange Directory dev lead/ later Active Directory dev lead): No, NT was late, and eventually canceled NT Directory. Exchange wrote and shipped our own Directory and then moved the code to NT to use as the base for Active Directory.

Stevesi prevaricating about high-level executive view of the interaction of NT vs Exchange directory.

DonH: No, that's wrong. NT provided nothing. Exchange created an email-specific directory. I used that to make Active Directory. Water flowed uphill not downhill.

from https://hardcoresoftware.learningbyshipping.com/p/021-expand...:

"That proved to be a defining moment because deploying a directory was hugely complex and there was no way EMS could do it twice. In one of the rare times an architectural choice was pushed to a team, using the directory from NT became a requirement for EMS. Many others supported this, including the Server leadership. It was to them as natural as pushing Excel to use Windows—the directory was that core to NT Server—while sharing files and printers was the baseline scenario, it was the directory that brought deep enterprise value to customers. For the better part of the following year or more, EMS would not speak well of using the NT Directory, and conversely the NT team felt that EMS was trying to use the Directory in ways it was not designed to be used. This sounded to me a lot like getting Excel to work on Windows, and it played out exactly that way. Had EMS not used NT Directory, it is likely Directory never would have achieved critical mass as the defining app for the client-server era (and remained the cloud anchor for today’s Office 365). And conversely, had the NT team not met the needs of EMS, then the NT Directory would have likely been sidelined by the rising importance of the email directory in EMS. Forcing this issue, while it might be an exception, only proved the strength of a strategic bet when it is made and executed. Still, it was painful."

Comment from DonH Apr 22, 2021, at end of blog entry:

"Speaking as the dev lead for the Exchange Directory (1991-1996) and later on Active Directory (1996-2005), there's a lot wrong with this chapter. NT's approach to functional directory services in the early 90's was "wait for Cairo. they're building one", which meant that we in Exchange had to build our own directory service. When Cairo collapsed (late 1995) Exchange and NT struck a deal so that once Exchange 4.0 shipped (April 1996) one of my developers and I brought a copy of the Exchange Directory source code over to Windows, and we built Active Directory out of that. Exchange in no way "bet on" the NT Directory; we essentially built the replacement for it in order to get the features we needed. Ask me if you need details.

However, the part about endless repeated pressure to build everything (specifically including the directory) on top of SQL is entirely accurate.

I'm only moderately annoyed that I had to pay ten bucks to post this correction."

Second comment from DonH:

"You're missing the point that there was no NT Directory. The strategy given to us was "use the NT directory, which is the Cairo directory. Sorry that doesn't exist yet, so Exchange might need to cobble something together for its first release." I built that something, and later went on to use it to fill the directory service shaped hole in Windows.

Presenting this as Exchange leveraging the NT Directory might be polite, but it is definitely not accurate.

And although I remain eternally grateful to LDAP for saving me from COM I completely agree about omitting it from the history."

ivan_gammel2• 2 years ago

Many people refer to Conway's law here, but I'd argue that this law is true only for the static organization design, where structure is rigid and never changes. This law and and the title of the link hide much more important dependency: organization is a function of business requirements. System design is a function of them too. It MAY happen that organization is designed first, but it is not necessarily the case. Organization changes happen all the time and systems tend to stay during those changes. Many companies have subdivisions organized around the customer journey or certain product topics, e.g. Acquisition tribe or B2B business unit. Those structures work very well and do not reflect the Conway's law (system architecture required in this case is often org-wide and modular, requiring all org units to follow the same design approach).

btbuildem4• 2 years ago

It's interesting to think of this in conjunction with the Peter Principle. In any org that's existed long enough, you will have a "crust" of people who have been promoted until they're too incompetent for their position. If long enough time elapses, these incumbents will account for most of the decision makers in the org chart, from the root on down. Given how incentives and motivations change with seniority, it's not a far stretch to assume that they will want to remain where they are - cannot be promoted any further, and would rather not lose current status.

I know it's just a little thought exercise, but I see enough of that reflected in the real world to pause and consider. I would wager that in majority of cases, organizational structure does indeed remain static, at least in orgs that live on long enough timescales.

MajimasEyepatch2• 2 years ago

Conway's law would still apply in a company where the org chart is changing. Obviously old systems don't disappear in a reorg, but new ones will reflect the communication structures at the time that they were built.

In companies that go through frequent reorgs, you'll often see a lot of "scar tissue," where you can tell that one set of services date back to a particular epoch. For example, these services are from a different time when the company tried to enter a new market, and here's a bunch of messy microservices from when the company added a bunch of developers after the Series C and the engineering processes failed to keep up. And along the way, you'll see a bunch of half-finished migrations that require both the old and new systems to be maintained simultaneously.

In your example, if that org is adapted to frequently shifting team boundaries with some central top-down architectural authority (CTO, architect, committee, whatever), then Conway's law would predict exactly the kind of modular architecture with a "shared design approach" that you describe.

btbuildem4• 2 years ago

When I look at a nightmare scenario like Salesforce, I am inclined to agree with you.

ivan_gammel2• 2 years ago

but new ones will reflect the communication structures at the time that they were built

It is correlation vs causality question. Conway law may actually be the former rather than the latter.

dredmorbius• 2 years ago

I spent a fair bit of my career working with a piece of software which has evolved across a number of different operating systems, and, one presumes, development teams.

Among the reasons I refer to myself, tongue in cheek, as a software anthropologist, is what I'd recognised from that software: it bears the marks of the major platforms it evolved through: IBM mainframes, VMS, Unix, MS Windows, and ultimately an Apple Macintosh variant (though principally the tool now seems to be PC-oriented).

Similarly, on Unix, one can often identify applications' origins based on their toolkits and widgets: Athena Xaw widgets, Motif, VUE, KDE, GNOME, etc. Though often criticised for the lack of consistency, I'm aware that different tools reveal their affordances by the toolkits (and GUI presentation and behaviour) they reveal. Similarly BSD vs. GNU command-line tools, and various other command origins. Particularly notably, the 'dd' command, which comes from, and borrows syntax from, IBM TCL, a mainframe environment.

Digging deeper, Unix's origins in Multics, the B programming language, etc., are also apparent.

Again, this is somewhat confounding tools and teams, though I'd suggest that the principles are similar and related. The upshot is that past decisions get layered into software, with the oldest layers typically closest to the core.

pvdoom• 2 years ago

This. Conways law is about the actual organization, not the orgchart.

db48x2• 2 years ago

Conway didn’t discuss how organizations change over time, but if you look for them you can see the results in the systems around you.

Casey Muratori has some great examples in his video on the subject: https://www.youtube.com/watch?v=5IUj1EZwpJY

alberth• 2 years ago

Domino Pizza tracker

The article is centered around the pizza tracker, but I thought that tracker was fake.

Just for illustrative purposes.

Is it not?

https://www.the-sun.com/money/6927297/dominos-pizza-tracker-...

Larrikin• 2 years ago

I'm sure some MBA douche presented the calculation at headquarters to save the money by making it fake, but when it was first released there was a massive campaign showing Domino's workers getting the orders printed out and hitting buttons at various parts of the process that actually did update the tracker.

subroutine• 2 years ago

I'm not sure about Dominos, but the last time I ordered Papa Johns, the pizza tracker had a disclaimer that said it was "for entertainment purposes only, and does not reflect actual events"

diggan• 2 years ago

That article is basically "they say, they say" argument between two Twitter users, not sure one could come to any conclusion based on that. It's also a The Sun article, FWIW.

I've always thought the tracker was real, at least here in Spain (it looks different than the US one in the article pictures), as it always seems to have changed at different intervals. Could also be just randomized a bit I guess. Long time ago I ordered from Domino anyways.

8organicbits• 2 years ago

includes the name of the employee baking each pizza

Yikes, I wouldn't put that info online. What's the point?

gibbitz• 2 years ago

My former boss wrote the first version of it when he was working for Crispin-Porter + Bogusky. He claimed that internally Domino's already had the infrastructure for their own telemetry and logistics and putting a python API on top of it to connect to the web was a no-brainer. To hear him tell it, it was his idea. Of course I later worked for a company that was helmed by the former Domino's CEO at that time who claimed it was his idea. Based on the technical backstory I would believe my former boss over the CEO. Of course the existing telemetry at Domino's could be garbage or fake...

shubhamjain2• 2 years ago

The whole post is based on a questionable assumption that Domino Pizza Tracker accurately reflects the status of the Pizza, when it could just be a dumb timer based on a statistical average. Sure, the Pizza Delivery person in the last step has to be accurate, but that's simpler than tracking if the Pizza is in the oven. As for the point itself, I think the real-time status tracking is a very, very small subset of UIs. Yes, it's difficult to deliver if the organization isn't designed around this, but most sucky UIs aren't limited by not having the data.

rileymat2• 2 years ago

Its not perfect, but at Starbucks, the “working on your drink” notification comes when they rip it off the machine, so it is kind of real time. (Kind of, because often they rip off 3 or 4 and stick them to the wall)

velcrovan3• 2 years ago

it could just be a dumb timer based on a statistical average

The post makes this point explicitly. It doesn’t sound like you read the whole thing.

shubhamjain2• 2 years ago

My bad! I raced through the article, skipping the important bit.

btbuildem4• 2 years ago

Seeing all the mentions of Conway's Law here jogged something in my mind -- could one assert the converse and "reverse engineer" the org structure of a company by examining the systems it has designed?

This could be super useful when considering the next place of employment for example; the organizational dysfunctions and idiosyncrasies only become apparent once you've jumped in with both feet.

01HNNWZ0MV43FF2• 2 years ago

Legend has it that Google produces a new chat program every year or two when a high-up manager wants a promotion.

Microsoft also seems to have generational UI revamps. There's a funny bathtub curve where Win32 has outlived many of its replacements.

db48x2• 2 years ago

Yes, you can! You can even tell when the organization was changed, since many complex systems are upgraded over time. The example I like best is the Windows volume control(s), as pointed out by Casey Muratori (https://www.youtube.com/watch?v=5IUj1EZwpJY).

deepsun• 2 years ago

where the step from “order received” to “pizza in the oven” happens only because of a timer in the UI

Then don't lie. Instead of the status, just say outright that it takes up to 5 minutes for the pizza to get in the oven. And show a timer.

hcarvalhoalves2• 2 years ago

Sometimes, UIs are designed with unrealistic expectations and mismatches of how processes work in reality. This is maybe lost on today’s “native digital” generation, but anyone who worked at organizations a while back should understand this intuitively.

Back then, processes inside companies where paper-driven, a variation of “produce some kind of document, pass it along to another department, get a stamped copy/receipt to prove it’s been done”. I always use this example when designing architectures and UIs: if you couldn’t design the same process as paper being passed around, the design is missing something. You need to really grok the company structure and the domain to design something sensible.

couchand2• 2 years ago

Yes! And, the killer feature of paper that no digital UI has yet to fully capture is the margin.

If your business process doesn't have a form field for some data, but the person on the ground understands that it's valuable, it's naturally scribbled onto the margins, and then worked into the next version of the form.

If you're using nearly any digital UI, the feedback loop (if it exists at all) is a side channel.

More businesses should just use paper.

01HNNWZ0MV43FF2• 2 years ago

If PDF editing tools were a little better and the average users' file name habits weren't ghoulish we could have digital paper.

hcarvalhoalves2• 2 years ago

More businesses should just use paper.

… or rather, digital processes shouldn’t throw away the benefits of paper.

E.g.: document databases instead of fixed-schema tabular (paper can accept more data than was anticipated), append-only databases instead of update-in-place (paper doesn’t forget). I’m a big fan of Datomic and similar databases because of that.

skybrian• 2 years ago

Why can’t this be done with a textarea for notes? Any chat system or ticket system has this.

BeFlatXIII6• 2 years ago

And, the killer feature of paper that no digital UI has yet to fully capture is the margin.

This is THE reason why, in the year of our LORD 2024, physicians still HATE electronic medical records. Margins, sticky notes, and red ink you can circle anywhere you d~~n well please, not organized data easily parsed during discovery.

Affric• 2 years ago

And then people demanding free text fields be removed from various forms/b2b/market systems on the basis that they are rarely used… those easily contain all of the most valuable information in the system.

The world is highly cursed. The information system which accommodates this is highly blessed.

manvillej• 2 years ago

If it doesn't work with sticky notes, it doesn't work.

the rest is just scale.

Terr_• 2 years ago

Back then, processes inside companies where paper-driven

Even today, the analogy I give for explaining APIs and integration sometimes involves tax-filing paperwork. The API for this system is that box 2 contains your full name, but the API for that system is a form where your last name in box 5A and your first name is in box 5B...

sksksk• 2 years ago

I often think about my partner's pregnancy journey, when she was pregnant she was given a folder which had all sorts of forms in. For every appointment she went to, she'd bring the folder in and the staff would read the existing pages, and add their own (results of scans etc...)

Due to some minor complications, her book ended up being quite full, and we went to lots of places, some hospitals, some GPs (which are private companies), and they could all read and add to this book.

In the UK, you can rock up to any hospital with maternity facilities when you're in labour, and have your baby there. You bring your folder with you, and they can read the notes from previous doctors. Once the baby is born, you hand the notes in, and they are collated together and put on your NHS record.

I often think about making a digital version of that. How difficult it'd be to build something that worked across all the systems that different healthcare providers use, is reliable, and secure.

Sometimes, analog is best.

kylecordes• 2 years ago

I have noticed that the Panera Bread status tracker used to provide good information, but doesn't anymore. It frequently says an order is done while it is still being worked on.

Might be a UI/Organization mismatch, as described in this article.

Or maybe it's the staff intentionally marking things done early, to game metrics expectations from management.

tsylba• 2 years ago

The Domino's pizza tracking bits is a funny one for those whom had read Snowcrash, where a whole earlier section of the book is about the advancement of the pizza delivery industry.

I don't know, it seem to me the 90s had a very dystopian view of future Pizza Hut.

« The Deliverator stands tall, your pie in thirty minutes or you can have it free, shoot the driver, take his car, file a class-action suit. The Deliverator has been working this job for six months, a rich and lengthy tenure by his standards, and has never delivered a pizza in more than twenty-one minutes. [..] Pizza delivery is a major industry. A managed industry. People went to CosaNostra Pizza University four years just to learn it. Came in its doors unable to write an English sentence, from Abkhazia, Rwanda, Guanajuato, South Jersey, and came out knowing more about pizza than a Bedouin knows about sand. And they had studied this problem. Graphed the frequency of doorway delivery-time disputes. Wired the early Deliverators to record, then analyze, the debating tactics, the voice-stress histograms, the distinctive grammatical structures employed by white middle-class Type A Burbclave occupants who against all logic had decided that this was the place to take their personal Custerian stand against all that was stale and deadening in their lives: they were going to lie, or delude themselves, about the time of their phone call and get themselves a free pizza; no, they deserved a free pizza along with their life, liberty, and pursuit of whatever, it was fucking inalienable. »

bjnewman85• 2 years ago

Umm, the argument in the article seems self-defeating. UI=f(org) except we end up with the same UI with radically different orgs because we can just f() over the differences with dark design patterns and users can't tell the difference.

I can show you anything in a UI - only good orgs can develop valuable products from those UIs.

vonnik• 2 years ago

This is a variation of "you ship your org chart."

After hearing the outbound version of this truism, I discovered that the inbound version is also true; ie "you buy your org chart."

Anyone selling to v large organizations, corporate or government, will know what I mean. Bloated and dysfunctional orgs with eternal sales cycles buy from bloated and dysfunctional orgs that can survive eternal sales cycles, and which are willing to sell bloated and dysfunctional products to satisfy arbitrary criteria.

This is one of many reasons why startups have a hard time selling to very large orgs.

cratermoon• 2 years ago

I order from Domino's now and then. I've noticed that someone named Scott seems to be working preparing pizzas at all hours on all days. It didn't take me very long to figure out that the tracker was just putting in a placeholder event. The actual delivery tracker seems to work OK, though.

jbs789• 2 years ago

So the output of an organisation is a function of the organisation. Or the amount of effort you put into something affects the outcome. Shocking.

alxmng• 2 years ago

“To the extent that the business takes place in software, designing the software is designing the business.” @mulegirl from Twitter

UI is a function of your organization

Related Stories