Does your computer miss keystrokes if you type too quickly? Does your mouse or trackball randomly lock up for a few seconds? If so, a new-ish kernel feature, USB autosuspend, might be to blame. The feature is intended to extend the life of battery powered USB devices such as wireless mice. Unfortunately, it targets all USB devices including ones without a battery like wired USB keyboards.
Fortunately, autosuspend can be disabled via the
usbcore.autosuspend kernel command line flag. Most distros use GRUB to boot so you’ll need to edit
usbcore.autosuspend=-1to the GRUB_CMDLINE_LINUX_DEFAULT variable in
/etc/default/grub. For most distros the variable is near the beginning of the file.
sudo update-grubto re-generate GRUB’s boot configuration.
cat /sys/module/usbcore/parameters/autosuspend. The command should print -1.
If autosuspend was the underlying cause USB device responsiveness should be back to normal.
A couple of weeks ago some engineering management friends and I were discussing our experiences with different organizational structures. All of the usual suspects were mentioned: hierarchical, flat, radically flat, Spotify’s often emulated squads, matrix, and others. As the conversation progressed I was struck by the apparent difficulty of implementing “modern” org structures.
For example, implementing squads effectively requires mastery of new organizational entities: squads, tribes, and chapters. Implementors also need to understand how these entities interact with one another. Owing to the relative youth of the squads model many of these interactions and management strategies are either undocumented or passed around as tribal lore in conference talks, blog posts, and Twitter threads.
All of this causes me to wonder “why oh why do small software companies try to implement esoteric org structures?!?” Life is already hard enough when you’re trying to iterate rapidly on a product idea in search of traction and revenue. Attempting to roll out a fringe-y org model at the same time seems to me to be about as reasonable as free climbing El Capitan while also memorizing the first 100 digits of pi.
I think two factors bias many small company leaders towards newer unproven org structures. First, they’ve had bad experiences with management previously. They’ve either had a toxic or apathetic boss and/or been tossed into the deep end of management without any support. “You’re really good at designing and building systems! Congratulations! Now you’re managing a dozen people. Go get ‘em tiger!”
Second, they conflate product innovation with organizational innovation. And who can blame them really? Industry press is awash with articles extolling the virtues of
$LATEST_ORG_STRUCTURE and how
$BIG_NAME_UNICORN could never have been successful without it. This really frustrates me as a software leader. As with most things FAANG (and Uber and Lyft and Spotify and WeWork and AirBnB and …) these lessons just don’t apply to 99.9% of startups and software companies. And, even if they do, they certainly don’t apply to small-to-medium sized companies. The economies of scale and funding/revenue cushions required to make a bet on something as fundamental as how to structure your company just aren’t there.
Org structure is meant to serve the aims of the business. It’s not an end in and of itself. Good structure helps your company execute efficiently and quickly. Good structure clarifies communication, decision making, and business priorities. It’s absolutely true newer org models can help you achieve these goals but there’s no guarantee. Choosing a “boring” org structure reduces distractions and increases your chances for success.
Are you a fan of books like Gibson’s Sprawl Trilogy, Effinger’s Budayeen Cycle, and Vinge’s “True Names”? If so you owe it to yourself to check out the game trailer for CD Projekt Red’s new game. Ah. Maze. Ing.