I watch many youtube channels with 100Ks of subscribers. Those creators are not out there spending resources getting an audience and those audiences are not coming from personal connections - the platforms are facilitating the connection.

Re : how "attempting to work in the art world" works : this is a very interesting subject/discussion - at what point is someone regularly publishing entertaining youtube videos about small engine repair "working in the art world"? When they get enough income to quit their day job or some lower bar - I dunno - both ? neither / never?

Re stardom: what you're saying is 1000 true fans != total number of fans/casual followers. Agreed.

I didn't go to near the extent of the training John Pilley did with Chaser, but I did do the verbal only approach and put the toys in another room - and I was able to teach him to retrieve probably 5 or 10 toys by name. I was really amazed. I didn't do nearly as much training with the second Aussie - but she picked up on the whole game even quicker than the first dog (because she had a role model?).

Another thing I learned about this game/training : it really wears the dog out. After 20 or so minutes of playing "go find the toy" they dogs lay down for a nap.

(ps. doing "nose-work" games with dogs also wears them out)

>"If we could get more of them doing it, it would be great," he joked.

>Karisoke's Vecellio, though, said actively instructing the apes would be against the center's ethos.

>"No we can't teach them," she said. "We try as much as we can to not interfere with the gorillas. We don't want to affect their natural behavior."

I wonder if this "prime-directive" style rule might be something they consider changed - if there was a way to teach the gorillas to disabled various kinds of traps it seems that would be great.

On the other hand, I wonder what the side effects would be.. anyone?

1,000,000 gross in a peak year.

say business is open 290 days of the year.

avg per day = 3448 euro

if average customer order spend is ~15 euro, that's ~230 orders per day that must be made to sustain the 1mm euro gross.

So - if the biz is open 6 hours (optimized around eating times) - that would be ~38 orders/hour.

Key Questions: for the average case : is 38 orders/hour OR 230 orders/day reasonable or not?

for the non-average case: can they make 2x the orders really busy days - i.e. what is the absolute peak orders than can make in a day?

I've heard it before from folks who were putting themselves in the #1 category, and also, it appeared, exhibiting Dunning–Kruger effects.

Which brings us to #2 : look at them relative to what's important to your business. Much of the time a deadline isn't really a deadline at all - its a point in time to show progress in the right direction. With that in mind, i might say to the team - "what's important to this business is _______ , so lets be sure to highlight our progress on items a/b/c because they're key to ______. ..all this other shit in the backlog is #2 .. n that Alice and Bob want. Alice and Bob will get their shit when we get the important shit done (which might be never) [0]

What direction is important to the business? Well, hopefully the direction of solving a problem or delivering a widget to someone who is waiting to actually use it and hand over $ in exchange. If its something else its often your deadline playing chicken with someone else's deadline on the gantt chart and then its the old joke about two guys running away from a bear.

[0] Alice and Bob will get their shit when they start contributing items to the backlog that are aligned with what is important with the business.

EDIT: deadlines aren't inherently "bad" - especially when one is competing against others for something. The problem is too many points in time are made to look like deadlines and often by the wrong people. Imagine running a marathon, and someone is yelling at you from the sidelines : "run as fast as you can to the 4 mile mark!"

"the new chair model must fit into these production constraints"

"the new software must be written to fit into this system - JVM based, web interface ..."

The problem, it seems to me is that software developers often think: "what programming language do we really like && can continue to use for $long_time over $scaling_of_business".

When this is the case, business management expectation problems emerge regarding costs, maintenance and timing when the business scales by 10 or 100x. Early phase teams are lambasted for making poor decisions - and "adult supervision" ( i hate that term ) is hired to "fix things".

Thing is, the early "poor decisions" may not have been poor decisions at all relative to the business needs. However, since costs and retooling issues weren't discussed and planned for - the early team look like a bunch of fools/amateurs.

As software developers, we need to understand and communicate that the tools can we use to accomplish the needs for the business at one stage are different than those of a later high-scale stage. its OK, completely natural, and a requirement if we want to keep our jobs and grow with the business.

analogy: If a specialty carpenter is designing and building high end furniture with a set of well made brand-name niche tools and techniques they wouldn't expect that those same tools would be used if sales take off and 10x or 100x the number of units need to be produced. It would be understood that retooling would be required, people with expertise in those tools be hire and that there would be new costs involved. Also, the carpenter who starts the business with small scale tools isn't lambasted for being an idiot for picking those tools in the early phases. It would be quite odd to suggest that that person have picked tools and hired people for 100x production when they were selling single digit units a year.

What I was most surprised about when we started is how the game sort of wears them out almost like a good run at the park. (we have 2 aussies and 2 silken wind hounds)

after reading the book "chaser" - I trained one of them to distinguish several toys by name similar to what he had done in the book. it was a lot of fun and now he's always bringing me toys to play with. Interestingly he brings them at very specific times of the day when I'm most likely to play with him: morning while making coffee, and evening while cleaning up the kitchen.

I've often seen leaders/managers get upset about the little shit while not acting the way they expect others to act in the areas they care about.

My step dad and a few bosses I've had over the years are great at this; they jump in and start doing the work and its amazing to see others jump right in along side them. Also, and this is key: they jump in and work along side their own reports who are doing the right things (this is a powerful message to a team).

One boss and mentor (and now a good friend) - would write documents/presentations and share them with an employee: "hey, I'm doing this presentation to _______ , check it out. I'd like you to ramp up and next month take it over. I'll be happy to help if required"

One time, some people were arguing one day about how to test some software and hardware. Boss observes the argument and comes in the next day with a little circuit board he made to help complete the tests. The model within the team from then on was often "hey I built this thing to help with the _____ ..what do you think, will this help?"

Another example, eng boss in a standup : "hey, I like how you did that thing with ____ in the code, I'm going to fork that and try an experiment". Comes back a few days later "hey check out this branch.. its a way to do _____; You can see what I'm getting at - and maybe figure out how something like this can work in the main codebase ..food for thought".