Theres a popular notion that artists work from inspiration - that there’s some strike or bolt or bubbling up of creative mojo from who knows where… but I hope (my work) makes clear that waiting for inspiration to strike is a >terrible, terrible plan. In fact, perhaps the single best piece of advice i can afford to anyone trying to do creative work is to ignore inspiration. Mason Currey.
Within organizational debt, there is a volatile subset most likely to come abruptly due, and I call that subset organizational risk. Some good examples might be a toxic team culture, a toilsome fire drill, or a struggling leader. These problems bubble up from your peers, skip-level one-on-ones, and organizational health surveys. If you care and are listening, these are hard to miss. But they are slow to fix. And, oh, do they accumulate!...
However, the real productivity killer is not system rewrites but the migrations that follow those rewrites. Poorly designed migrations expand the consequences of this rewrite loop from the individual teams supporting the systems to the entire surrounding organization. If each migration takes a week, each team is eight engineers, and you’re doing four migrations a year, then you’re losing about 1 percent of your company’s total productivity. If each of those migrations takes closer to a month, or if they are only possible for your small cadre of trained engineers—whose time is already tightly contended for—then the impact becomes far more pronounced....
A function-oriented structure in which firms have “vertical” groupings such as Marketing, Finance, Operations, R&D, or Customer Service. Each function has a specialty, and these specialties are critical to the performance of the firm. This kind of structure is effective when the organization’s product lines are fairly narrow or serve defined market areas. The Product Manager’s Survival Guide. And now for product-oriented structures: A** product-oriented **structure is commonly used by midsize to larger firms that are divided into product groups, product lines, or even product divisions....
While going through the second chapter of Shape Up book, just want to summarise some of the key points of it. Real-world scenario with “calendar feature” was perfectly broken down to the points, except of “point-zero” that is constantly missed out in Cyprus: With only six weeks to work with, we could only build about a tenth of what people think of when they say “calendar.” The question became: which tenth?...
Basecamp started off in 2003 as a tool we built for ourselves. At the time we were a consultancy designing websites for clients. Information would get lost in the game of telephone between the client, the designer, and the person managing the project. We wanted Basecamp to be a centralized place where all parties could see the work, discuss it, and know what to do next. It turned out lots of companies had this “information slipping through the cracks” problem....
Matt Mullenweg, the founding developer of WordPress and the founder of Automattic, joins Basecamp co-founder David Heinemeier Hansson for a spirited debate about tech monopolies, power in open-source communities, and how to be good stewards of the modern web that they helped build. Listen on Rework.fm
Great article recently published by Dries Buytaert, founder of Drupal project, describing the balance of makers and takers in open source community: Small Open Source communities can rely on volunteers and self-governance, but as Open Source communities grow, their governance model most likely needs to be reformed so the project can be maintained more easily. There are three models for scaling and sustaining Open Source projects: self-governance, privatization, and centralization. All three models aim to reduce coordination failures, but require Open Source communities to embrace forms of monitoring, rewards and sanctions....
That moment is really the turning point,” Barbara Burian, a research psychologist at NASA who has studied Qantas Flight 32, told me. “Most of the time, when information overload occurs, we’re not aware it’s happening—and that’s why it’s so dangerous. So really good pilots push themselves to do a lot of ‘what if’ exercises before an event, running through scenarios in their heads. That way, when an emergency happens, they have models they can use....
Since our earliest days of writing software, we were warned of perils of global data - how it was invented by demons from the fourth plane of hell, which is the resting place of any programmer who dares to use it. (C) Refactoring, 2nd Edition