As some of my readers know, I’ve taken the last year off from the corporate world. I’ve done some things on my own, sold some things on eBay, and worked as a contractor for a mining pool. Now that I’m back into interviews, one thing I get asked more than ever before is about my management style.
I prefer to think of it as a management mindset, as the style would adjust to each minion’s needs and “work language” for lack of a better term. And despite relatively little formal management training, I’ve come to a coherent and occasionally appreciated position.
You can only be as good a manager as your manager is to you.
A large part of team management is proxying in both directions between the people who report to you, and the person or people you report to. Your reach and control is probably limited — you can’t usually spend more than the budget allows on salary, or eliminate 7am calls for your west coast team because a manager three levels up wants 10am meetings from his east coast office.
But on a more granular level, if your own manager isn’t supportive of what you need for your employees, there’s only so much you can do to make that happen. This is often because your manager’s manager is limited, and on up many levels.
This can be an uncomfortable maxim to present to a prospective or current manager, as some will take it as a personal affront. But good managers (leaders) will understand that it’s reality, and they can’t do more for you than their manager permits (generally speaking). They probably know it even if they haven’t specifically thought about it.
Disclosure: I work with Flexpool.io but I am not writing in any official capacity or with any proprietary knowledge. You should mine with Flexpool, but it’s not mandatory.
Disclaimer: Hashrate rental can be expensive and unprofitable if you don’t know what you’re doing. If you do know what you’re doing and can manage your risk, check out Nicehash and MiningRigRentals and maybe you too can embarrass the tech media. (Referral links may earn me a little bit.)
This morning, some “news” pieces came out in some of the tech press. Not the big names most people have heard of, but venues with some reach and some expectation of basic knowledge.
The “story” was that some unreleased and possibly even non-existent GPUs were mining to Flexpool, the number 5 Ethereum mining pool in the world This sounds pretty amazing, even unbelievable, although after the April 1, 2021 Captains Workspace reveal video on the “RTX 4090” you realize some people will believe anything.
The evidence? High hashrate and workers named “4090TI-Overclock-Test,” “RX7000-Control-Test,” and “RX7000-Overclock-Test.”
A couple of these mention later in the article, after breathless references to the scale and/or specs of the cards named and the vast amounts of Ethereum that could be mined by these farms, that it’s unlikely.
A couple months ago my friend Christopher asked his friends about getting comfortable with public speaking. I’ve told this story to small crowds from time to time, but never put it all out there… so here is how I contracted Splash Mountain Syndrome, and what it meant to my public speaking career.
Most of my readers are familiar with Impostor Syndrome, where you doubt you’re good enough to do your job or tell your story, or that there must be someone better out there. Most if not all of us in tech have dealt with this at one time or another, feeling like the turtle on the fencepost.
Well, to explain what I experienced in my speaking career at Cisco, we have to go back to spring 2003. I was between jobs, and had gone down to Southern California to spend a weekend with a lady I was interested in. We went to the grand opening of Amoeba Records Hollywood, and also made my first trip to Disneyland.
She stood in line for nearly an hour with me for the Winnie the Pooh ride, so when she wanted to go on Splash Mountain, I figured I shouldn’t start letting her down quite so early in the relationship. So we went to Splash Mountain. The line was faster there for some reason.
As we went up on the ride to the top, I wondered if it was too late to back out. Maybe hop out at the basketball court and walk down, and probably get kicked out of the park. As we got closer to the mouth of the mountain, it became clear that I had no option but to hold on for dear life and deal with it. And as we emerged into the light, my legs clamped on the log car, I closed my eyes, and dropped.
As we walked away, I asked my companion if she’d heard a noise like a small rodent being strangled. “Yes,” she said. “That was you.”
How this applies to public speaking
I can say that it was more distance than drop ride disappointment that kept that from being a long term relationship, but similar feelings happened almost every time I got ready to travel for a speaking engagement.
I’d be eager to sign up for an event, whether a partner conference or partner sales event, Strata+Hadoop World, or Cisco Live. But the closer it got, even if I already had my presentation pretty much committed to memory, I’d start to think I made a terrible mistake, that I would dread the whole trip, that I’d get my first heckler, or that I should just let someone in marketing handle it.
The dread would intensify as I was packing, probably because even after six years of work travel, I still sucked at packing efficiently (I’m still not that great, despite lots of YouTube videos). But I’d still finish up the packing, with a laptop bag heavier than my clothing and coffee bag, and head off to Seattle or Atlanta or Manhattan or Las Vegas or Denver or wherever.
Of course, I’d do fine, entertain people with the fairly unique mix of facts, experience, humor, cultural references, and sarcasm that I became known for, and get good feedback afterward. We’d find a good restaurant for dinner, and then move on to the next adventure.
But the next time a trip came up, I’d go through the same cycle. At least I didn’t make the noise again.
As Martha Stewart would say, it’s a good thing
I think it was a good thing. I’ve seen speakers who are way too comfortable and lose their edge, their connection with the audience, or even their talk track. We’ve all been in sessions where the speaker is there because of title and clout rather than their scintillating message and delivery; I wonder how many of those people have lost Splash Mountain.
Splash Mountain Syndrome helped keep me on my toes, and definitely made sure that I didn’t get so comfortable with my content that I went into autopilot and lost audiences and credibility. It still led to an uncomfortable hour or more leading up to my trips, but I came out of it stronger and more confident.
Have you experienced anything like Splash Mountain Syndrome? Have any tips for people preparing for pulbic speaking? Share in the comments if you’d be so kind.
In September 1996, I left my desk at IQuest Internet in Indianapolis for the last time. A friend from the MUDs I was on had talked me into talking to her brother, a recruiter at Taos Mountain Software, and two weeks later I had an offer, notice given for my apartment and my job, and the terrifying thought of driving 2300 miles with my possessions in a Ryder truck, my very unhappy cat in the front of the truck, and my Pontiac Grand Prix on a trailer it was too heavy for.
But on the flip side, I was getting out of the Midwest and its glorious winters, escaping a salaried position that ended up being a pay cut, and most importantly, leaving behind end-user tech support. For the next 25 years or so, I did tech support, and infrastructure/architecture/caffeine delivery systems, but for internal colleagues who were generally more aligned with my assigned priorities.
Now, I’ve gone back onto the front lines, supporting end users from around the world in several different languages (thanks to Google Translate or Bing Translate), explaining and troubleshooting and answering questions about cryptocurrency in general, Ethereum and Chia in particular, and specifically how to make them work with one of the more advanced mining pools.
As I told the owner when I started, I’ll scale back or even hand over the reigns altogether when I find something more in line with Silicon Valley expense levels, but for now, it’s an extension of what I’d been doing on Telegram since January, and it’s supplementing my coffers in the process.
I meant to write this last month, when it would have been 30 days, but the conversations get overwhelming and blog posts get distracted-from, so here we are closer to 60 days in reality.
I’ve made a few references lately to avoiding Jurassic failures. In some tech circles, including cryptocurrency projects, it seems very popular to make bad decisions and not claim responsibility. And yes, I’ve been writing and talking and thinking a lot about crypto this year. I’m not alone, but I’m the only one on this blog who you’d be able to make that observation about.
The Jurassic reference of course is to Jeff Goldblum’s character Dr Ian Malcolm in Jurassic Park.
Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.
The Jurassic Park reference is a bit more universal than the one I used to use, which was to Wangdi something. I had a Nepalese classmate in college named Wangdi, and the main thing I remember of him from those years was his disc soccer/disc golf prowess. Well, that, and the time he had someone spread three soccer discs in a throw which he would normally have caught with ease, but in this case he tripped over a sprinkler head about two steps into his run and faceplanted in the quad.
Don’t always do things just because you can
Corollary: Don’t always do things just because you saw them on the Internet
2. Don’t try to start out at full speed; watch where you’re going and work your way up
Corollary: Set a reasonable plan and try to follow it. Don’t get distracted by squirrels
3. Plan to spend at least one minute for every $100 spent, learning how your item works
Corollary: If you can’t do that, don’t expect others to do it for you for free
Between these two warnings, you can take something away. First, don’t always do things just because you can (or because you saw them on the Internet). Second, don’t try to start out at full speed; watch where you’re going and work your way up.
And third is my One Percent Rule, not to be confused with Arthur Conan Doyle’s Seven Percent Solution. For every $100 you spend on an endeavour, spend at least one (1) minute learning or trying to understand it on your own before demanding help in free volunteer forums or from overworked support staff. So if you’re spending $3,000 on a GPU, but you’re not willing to spend 30 minutes learning how to use it, maybe don’t spend it. See also the first and second rules above.