This is the 2nd edition of a book that was apparently first published in 2017.
The basic thesis is this: In security, design your priority list of whatThis is the 2nd edition of a book that was apparently first published in 2017.
The basic thesis is this: In security, design your priority list of what needs fixing based first on successful attacks in your own company. Why do companies not do this? Because they have entrenched systems that are "too hard to fix" or where operational downtime would jeopardize the business. Because they won't fix those core things, they fix things that don't matter and wonder why their security profiles are not becoming stronger. According to Grimes, the two areas that are going to dominate your list are: (1) Unpatched systems (and those systems are: browser add-ons, networked, services/daemons, OSs, and productivity applications [p. 136]); and (2) social engineering (for example, p. 62). But the identification of these two specific threat areas is not the point: You have to gather your own data based on your own situation, and figure it out yourself, especially by identifying root causes. And get those threats into priority order! (Grimes notes frequently CISOs who have a list of identified threats from external audits, but because they're in no particular order, they don't know where to start.) Additionally, Grimes repeatedly reminds us that if we fix root causes, we will eliminate whole categories of risk. For example, in a company I know quite well, Chrome add-ons cause of a lot of problems: The answer? Whitelist the add-ons you allow. This is a decision that takes courage, but if you really care, and you can get buy-in from the business, it's going to remove most of the threats from the complex world of add-ons.
Grimes is quite negative on following the security press and common wisdom. For instance, he goes back to Meltdown and Spectre, which were attacks on chip/firmware flaws (pp. 137-139). At the time, Grimes argued, unpopularly, that there were no attacks in the wild; so why fix them, especially given the expense of re-flashing firmware. Two years later, there were few if any attacks exploiting Meltdown and Spectre; and the fixes that did come out were almost harder to manage than the initial problem. Thus, Grimes would have advised: Why are you wasting cycles trying to fix an essentially hypothetical exposure instead of working on the attacks that have been successful in your own world?
What else? Let's talk about the scope of this book. Grimes notes the now classic NIST CSF breakdown of the components of a good security program, namely: Identify, Protect, Detect, Respond, and Recover (p. 185). This book is about only the first three: Identify, Protect, and Detect. In other words, this book does not replace what you're already doing: It refines what's on the "front end" of your program.
The book contains illuminating case studies. For example, remember Conficker? This was a nasty attack that took over key aspects of Windows and then aggressively spread to other machines. Microsoft's first attempt to fix this was to focus on patching. That helped. But it didn't help enough. They took a data-driven approach, and discovered that the key attack vector was the auto-run feature on USB drives. So Microsoft changed the default to not auto-run. This change drastically reduced the number of systems infected. They wouldn't have found this without counting up the number of computers attacked by various means.
I would say that this book has two flaws. The first is that it talks perhaps too much about Fortune 50 companies that have spent tons of money on fixes that haven't worked -- and when they turned to a data-driven approach as described here, they were more successful. That is, they shifted the emphasis of their big spends. But what about smaller companies that don't have that much money? Grimes would say that they should still follow his methodology, but I'm not so sure if that is quite the place to start: I think such companies might first prioritize the new generation of malware hunting tools such as Carbon Black, CrowdStrike, and SentinelOne. You would come to this decision following a data-driven approach, but I think nowadays there's more certainly around the needed suite.
The second flaw is that many of the issues here describe problems with the Windows operating system and Microsoft products such as ActiveDirectory and Office. Grimes is right that in the last two decades, Microsoft has radically upped its game with regard to security. Still, I'm not so sure that's enough because of the complexity of such an all-in-one solution. In our search for root causes, maybe it's time to acknowledge the fact that Microsoft products are enumerated over and over on lists of software with the most CVEs. To Microsoft, I might add Atlassian (built on Java) and parts of the Java ecosystem. Increasingly, I would advise companies to just give up on the whole lot of that stuff, or at least run them in virtualized containers. People who argue I'm wrong have entrenched staffs with expertise in those systems. It's time to move to decoupled SaaS products that can be swapped out (and re-train your staff that is administering AD in the colo).
With regard to the book, I think that means that you look at your top threats and ask the further question: Is there something wrong in the overarching system that results in these threats being the key threats? You might even apply this argument to social engineering. We fear phishing attacks. Why, I wonder, do we even allow links to be clicked in email in the general case? Isn't it time to whitelist those, and turn off the phishing channel altogether? Grimes's answer is more training and awareness (and I agree with that) but I'm kind of dumbfounded that we have live links in email from outside the company in the first place. Let's turn those off or migrate them to more controlled environments (e.g., DMs in Slack)....more
This is a novel about DevSecOps that describes a company in the finance sector that bungles its compliance obligations, receiving an MRIA ("Matter ReqThis is a novel about DevSecOps that describes a company in the finance sector that bungles its compliance obligations, receiving an MRIA ("Matter Requiring Immediate Attention") a regulatory finding issued by the Federal Reserve. You don't want one of these. If you don't fix the problems identified in the MRIA, you may be forced out of business.
My bet is that this book would be a valuable read for people in the CIO's office and for engineering managers who are trying to develop a more automated approach to compliance. The book is published by IT Revolution, who brought us The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. This novel (maybe more of a novella) isn't as compelling as Phoenix but you'll still learn a lot.
In the novel, Investments Unlimited receives an MRIA because they can provide little assurance that their in-house developed software has been reviewed for issues such as the way it depends on open source software (which may have vulnerabilities), and proof that code was reviewed. The story revolves around a team that attempts to address these issues by building a more automated software build pipeline, that uses tooling to provide assurance. In a compelling way, the book does not shy away from the technical limits the team experiences, and there is a nice twist in their approach to satisfying the MRIA that would be a spoiler if I described it.
That may sound a little dull, but if you're in the business of making software, a lot will resonate here. Generally the company Investments Unlimited is lucky because they are able to have conversations across functional areas. You may not be so lucky. It's interesting to see how ideas pop out. The two key players are down inside the leadership hierarchy (which is provocative all by itself: leadership is a bit absent here) -- Michelle, who is a Senior Staff Engineer, and Andrea, who reports to the Chief of Audit and Risk.
The book contains useful appendices on MRAs and MRIAs, Pipeline Design, a shortened version of the DevSecOps Manifesto, a brief outline of the idea of "shifting left" and its criticality to the whole DevSecOps enterprise, a note on SCA (Software Composition Analysis), and finally, a summary of Biden's Executive Order calling for improvement the USA's Cybersecurity.
All of these topics in the appendices are deepened by the story. So if you've wanted to understand the topics of these appendices in a narrative, this is the book for you. ...more
This is an incredibly provocative read. One reason I decided to read it was that four of my Goodreads friends have it on their "to read" lists, but noThis is an incredibly provocative read. One reason I decided to read it was that four of my Goodreads friends have it on their "to read" lists, but none had read it. That is really unusual: It's not uncommon to see a book with a lot of "to reads" but almost always there's someone who has jumped on it. (All women, too; does that matter? Probably not?) So this made me curious: What is it about this book that might make people aspire to read it, but somehow it doesn't yet get read? Oh, and I should say why I read it: I noticed the author's work popping up on lists of resources engineering managers should check out (example). Those lists were right.
The title mentions the "courage to be vulnerable," but it's really about shame and what the author calls "shame resilience." One thing the author notes towards the end in her appendix on her research methodology is that just saying that you're researching shame "triggers discomfort and avoidance in people" (p. 253). I believe this. When I got a chapter or two into the book and realized it was all about shame, it was a little hard for me to continue; but I'm glad I did. Anyway, maybe that counts for some of the resistance: It's a scary topic.
In any case, Chapter 3, which is a head-on analysis of shame, was devastating for me because it helped me understand some painful family history that came up when my dad was in the hospital, about two weeks away from death; he shared some things that were shocking for me at the time; I wish I had had this book in my rear window because it would have helped me situate better what he was saying. (Also, in retrospect, the book perhaps validated that I had show some vulnerability in that conversation.) One thing I think you will realize reading this book is that no matter how sturdy you think your psyche is, we all live in the world of shame, maybe especially recently (p. 20). Chapter 4 provides analysis around how we "armor" ourselves against feeling shame -- and shares some patterns to resist arming up.
But I think the most important chapter may be the last one, about parenting. A really crude summary would be that it is important to learn how to not think about how your child "is" but rather how your child "acts": This will enable you to help your child detour shame and experience instead, guilt (I know, this sounds horrible too, but go back to pp. 71-74 if you glide over it). Additionally, the author has wise but sound counsel about situating your child to have the courage to do hard things (and possibly fail).
Chapter 6 is also quite good, about interactions in the work place. If you have direct reports and you conduct one-on-ones with them and intend to help them grow -- or at least not say things that will block growth -- this book teaches how to avoid some dangerous things we say or think too often in the work environment.
Let's see, what else? This book will cause you to re-evaluate the way you behave, and it will set you on the path to ask, and answer, some painful questions about how you interact with loved ones -- and anyone. If you're lucky, the book will help you to change some behaviors.
I'll be re-reading Chapters 3 and 4 for sure....more
This is a capacious narrative about how the world has engaged in cyber warfare since 2013. In large part it is about "zero day" exploits, which are buThis is a capacious narrative about how the world has engaged in cyber warfare since 2013. In large part it is about "zero day" exploits, which are bug discoveries that only the holder knows; with a zero day against Microsoft Windows, for instance, the attacker can go in and there's nothing anyone can do about it. The United States's NSA and Department of Defense have many zero day exploits that they keep under wraps. Perlroth explains how the business of trading zero days evolved, and how entities have used them. I've been following Perlroth's articles in the NY Times for some time, but the book has the great advantage of pulling everything together into a story.
But perhaps more importantly, she explains the politics around zero days: For example, it's in the NSA's interest to hold zero days so that they can -- if they want -- exploit computers in, say, Russia. But if a zero days starts being used by other entities, then the value of holding it goes to zero: And the NSA should be notifying Microsoft so they can fix the bug. Some years ago, a horde of NSA zero days were made public. Since the bugs these zero days depend on were never fixed, our computers becomes exploitable.
Perlroth is a courageous journalist: She probably put herself in danger a number of times, and the book tells that story, too. There's also quite a bit in here about the mess of the Trump administration when it comes to cyber. Fortunately, some bold souls in the government repeatedly did the right things, and we avoided some truly horrendous situations.
The epilogue contains a number of recommendations for how the United States could manage zero days better: It's very clear and very concrete. At one point in the epilogue she apologizes a bit for the book maybe not being that technical: But the broad scope, discussion politics, business, and the ethics of cyber war balances out the avoidance of drilling down into the tech.
I've read a lot of books about managing people; this is one of the best. It's quite tactical and practical and is loaded with ground-level guidance abI've read a lot of books about managing people; this is one of the best. It's quite tactical and practical and is loaded with ground-level guidance about how to intervene with the people who report to you. But what is quite striking about the book is how it thinks about the different modes of one-on-one people management: The book draws shrewd distinctions between the quite different roles of mentoring, coaching, and sponsoring (chapter 2).
For Hogan, mentoring is when you advise. Coaching provides more freedom for the person being coached, because in the coaching role you want to ask open-ended questions and provide reflective comments that narrate where the coached person is. Why? Because you, as a coach, are trying to situate the coached person to grow without telling them what to do. This reminds me quite a bit of the "language protocol" which undergirds the Entrepreneur's Organization's "Forum" structure (the Forum structure asks you to share experience [not advise] and let people draw their own conclusions). This distinction between mentoring and coaching is really important, because for people to step up, you have to refrain from advising; you must create the context so that the coached person can choose her own path. Finally: Sponsoring is about situating/promoting people so that they eventually manage and lead. This is about providing grounds for recognition so that someone can be given or grasp new responsibilities. My only regret about the section on sponsoring is that it's so short (pp. 29-30). I think Hogan could write a book on this single topic (and she notes in passing that it is her favored mode of managing). I infer that she would teach us that if you have managers who are stuck in the same 1:1 mode (e.g., mentoring when it's time to move on to coaching or sponsoring), they may be stifling or blocking their reports.
As a manager, you really have to get your choice of approach (mentoring vs. coaching vs. sponsoring) right. I remember back when I started in academia as a junior professor, I suffered as the mentee of a self-nominated senior faculty mentor. It was terrible. I didn't need advice: I needed coaching. But the coaching strategy was completely beyond the capacity of the faculty member. It's been a sore point with me ever since.
Elsewhere, the book talks about getting your communications right. Hogan rightly says that if there is news that will likely be painful, you need to talk it through; email is not going to work. She recommends, then, a later recap email that sums up what went down (pp. 61, 70). Believe me, this is something that a lot of new managers get wrong: Hogan is helpful in suggesting techniques to get the messaging straight and coherent. The book is also quite good on providing reasons for "All Hands" meetings. Why do you do an "All Hands"? Well, it's because when you have big communications to share, you need to do it once so that everyone gets the same message. People wager that can drop the regular cadence of the "All Hands" meeting, but the risk there is that by loosing the repetition, you lose your ability for the "big news" meeting to be taken in course. I.e., w/o a sequence of repeated "All Hands" meetings, that one where you have to announce something tricky or potentially disruptive will itself seem like an emergency meeting: And people will over-react or be confused or just not get the message because it is presented in an exceptional venue (pp. 67-69).
I really can't praise this book enough: Besides the counsel on how to manage, the final chapter goes into the question . . . why are managers so tired all the time? And the book advises, surely based on the author's scar tissue, techniques for finding/developing a great peer network, learning how to prioritize but more importantly grade the everyday energy suck, and how to say "no" (83-95).
Note: One thing this book is not about is structuring teams, promotion ladders, and guidance for engineering team/process managers such as directors and VPs. For that, the author advises you check on The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change (my GoodReads review). The book also does not couple her ideas to engineering process, such as Scrum (by not doing that, I think the book may have a lot to offer non-engineering managers)....more
This is a great book on statistics for the general reader who knows nothing about statistics or its applications; it's also a good refresher. It is deThis is a great book on statistics for the general reader who knows nothing about statistics or its applications; it's also a good refresher. It is definitely one of the most entertaining books on statistics, right up there with The Lady Tasting Tea: How Statistics Revolutionized Science in the Twentieth Century. Even so, this book took me longer to finish than anything else I've read recently, because despite its jokes and superb examples, it kept putting me to sleep!
There is a great final chapter that touches on ongoing real-world conundrums where statistics might help us out a lot: football injuries; the apparently increase in autism spectrum disorder; etc. I may set up Google searches on these topics because they are clearly hot and an opportunity to evaluate statistical methodology oneself. These would also be great topics for high school and college students who want to explore something relevant. There is also a chapter on "program evaluation," e.g., deciding whether big bucks should be spent on various things to change society. The author has been accused in Amazon review of having a liberal bias, but I have to say that he has judiciously picked a basket of topics regarding program evaluation with conclusions that anyone would be interested in. For example, he goes over the famous Tennessee STAR program which pretty definitively showed that smaller class sizes provide better education outcomes (oh, but surprise: that's expensive).
I can't give this a five-star review, though, for a few reasons. One is that it has some funny gaps. For instance, R^2 is not explained very well (p. 198) which is a pity because it is one of the most common statistics people will see in everyday data exploration; meanwhile, in another section it is casually mentioned that an R^2 of 0.29 means that a model "did a decent job of explaining the variation" (p. 220). I'd appreciate knowing what a good threshold is. And R^2 is not in the index of the box. These little blemishes are all over the book. To be sure, the author is quite clear that the book is not intended to "teach statistics" but when a little more flesh, it might be a little more clear. It would be great to accompany this book with a statistical textbook that matches the chapters and demonstrates working over the data with R or some other statistical package.
This is a concise introduction to Kanban, focusing on the idea that your teams and colleagues need a way to see (with their eyes . . .) work so that iThis is a concise introduction to Kanban, focusing on the idea that your teams and colleagues need a way to see (with their eyes . . .) work so that it can be planned, discussed, and remove surprises from the organization. I would say that if you're a new practitioner of some kind of agile methodology (Scrum, Kanban, whatever) and want to tune up your work boards, this book could help quite a bit. It is not doctrinaire, and provides a lot of different patterns; no specific software package is discussed, and indeed the book makes a good implicit case for physical boards. The book also knows that not all patterns are for everyone, and contains a judicious chapter called "Beastly Practices" (173-183). where the author rants about some ways that you can shoot yourself in the foot (e.g., Gantt Charts, but perhaps more critically, individually-named swim lanes -- don't do that!).
The book is punctuated with team exercises where you use sticky notes in a variety of ways to level up your teams. The exercises seem a little dull to me, though, compared to what you might find at tastycupcakes.org and other places.
The book has a nice discussion of flow metrics and queuing theory (pp, 141-149), but there is a fatal flaw in this discussion, which is that Little's Law requires that all work be measured in the same units. Good luck with that: I don't think the discussion here is going to provide you with something you can use "out of the box," though the author does recommend Vacanti's Actionable Agile Metrics.
There are some bonuses. Tangential to her main topic is the idea of "Lean Coffee" (pp. 165-168) which is a way to bubble up ideas from a group in a semi-democratic way. We have a large meeting at my company that exposes "red flags" and "green flags" but it has become boring with less utility: An occasional "Lean Coffee" might be just what we need.
[I should note before beginning that a colleague of mind picked this up for free at a conference and gave it to me.]
This book is a sane reading of the[I should note before beginning that a colleague of mind picked this up for free at a conference and gave it to me.]
This book is a sane reading of the riot act to all information security professionals and those who want to work in information security. I say "riot act" because Francen is unerring in raising the temperature and alarm at how terribly knee-jerk so much security work is, while simultaneously underscoring how truly at risk we are: companies (large and small) and the federal government alike. (And this is not a provoking of "fear, uncertainty, and doubt" [FUD] because Francen frequently differentiates the fake from the facts.) I say "sane" because I suspect that this book emerged from some very emotional behind-the-scenes ranting, which Francen has managed to control by tempering his approach with facts. The book is loaded with references and recommended reading.
The chapters are thematic, each one a series of problems and solutions. Let me itemize a few things that really got to me:
* First off, the core of this book is based on values. If you don't start with an idea of what you can tolerate for risk, based on your solicitation from business leaders, your security program is simply not going to work. You must identify likelihood and impact, and then go to your business owners and ask them to decide whether it's worth it to fix things up. But the key here is that you're starting from the value proposition that high risk may jeopardize the mission of the business. Francen is very good on the idea that we too rapidly go for technical controls, where our real problems are around user behavior and user training (e.g., pp. 96-99 and elsewhere).
* Second, we are doing a massive disservice to our values around risk and safety by simply turning the crank on what our regulations and assessors tell us to do (especially chapter 7, "Because I Said So"). Francen has clearly been in the business for a long time, because he shrewdly picks out two areas where companies get pummeled by their assessors, but to what end? One area is the SIEM tool (i.e., Security Information and Event Management, or, more humbly, centralized logging). We went through this very exercise motivated by our assessors. As it turns out, after a lot of reflection, we really needed centralized logging, and by implementing a SIEM, we were able to turn off some other systems that were costing us money. But just satisfying the checklist would probably have rendered it shelfware. We have already seen value in our ability to conduct centralized forensics. But, truly, the value emerged from our own assessment, and our definition of requirements brought us the right solution. (Chapter 9, "The Money Grab," has some solid guidance on product selection.) The second area where he identities assessor-driven security is the need to get a penetration test. In this story, he recounts how the report submitted to the assessor was in fact a vulnerability test, not a real penetration test. Yep. But what was the real problem? The company had never really thought about how an attacker would go after them, so they didn't know what to ask the tester.
* Third, the security industry is starved for talent. The final chapter is an eloquent plea for more security professionals that have the right values and know their onions. Francen provides guidance on how to bring more women and minorities into information security. This is doable. Francen points out that in the early 50s there were only a few hundred women certified public accountants in the USA; now there are hundreds of thousands; this gap was rectified by awareness campaigns and hiring initiatives (p. 256).
Like a lot of more general information security books, this one sometimes wavers between generalizations that don't always provide value (experienced nerds will get impatient), coupled with needing to know some nerd talk to understand where Francen is going (so non-information-security people may get a little lost). But I think the balance is good. Even though the book is pretty well-organized, I think it would have benefited from an index, just to make it easier to find his references to certain topics....more
This is a fantastic book that attacks the silo-ization of IT (and its leadership) in a business. I am going to have to write a longer review, but for This is a fantastic book that attacks the silo-ization of IT (and its leadership) in a business. I am going to have to write a longer review, but for now I'll just say that a remarkable feat is accomplished in chapters 5 ("Requirements") and 9 ("Governance and Oversight") where Schwartz essentially derives the OKR system from "Agile" first principles. He comes up with a system that has much of the thinking of OKRs without all of the baggage.
Elsewhere the book expands on his deep skepticism -- as expressed in his earlier book The Art Of Business Value (a much more difficult "read") -- about whether it makes sense to have the "business" represent value to IT teams, rather than collapse the very distinction between the business side and the IT side.
This should be required reading for CIOs, CTOs, wannabees for those roles, and, I would say, CEOs....more
This is a critically important book. The opening chapters are about the direct military involvement in the creation of the Internet: while some of theThis is a critically important book. The opening chapters are about the direct military involvement in the creation of the Internet: while some of the story is derived from little-known dissertations, the narrative reports a history that is not told in the mainstream works.
From there, we proceed to learn how the American government backed many of the libertarian players in the 90s ideologies of a free network.
The book concludes with a vigorous take-down of Tor and Signal. Good skepticism of Snowden as well. The conclusion notes that we cannot secure ourselves from observation but also claims that democracy needs these instruments of sunlight to reveal oppression.
If you care about privacy, security, the militarization of putatively neutral technologies, freedom, the press, etc., this book is for you. ...more
Well . . . This is another one of those funny books that is sort of a “5” and sort of a “3.” The book broadly claims that the tech industry builds intWell . . . This is another one of those funny books that is sort of a “5” and sort of a “3.” The book broadly claims that the tech industry builds interfaces and products that are (not necessarily intentionally) biased. The book says that the main driver is the homogeneity of tech company investors and employees.
There is no doubt in my mind that this is true, and on that basis, I’d recommend this to anyone in or outside of tech. We product builders and designers are doing a crap job of acknowledging the incredibly broad types of people and styles of interaction out there. Because of tech’s homogeneity, there’s so much stuff that just isn’t thought about critically (e.g., image analysis software not being able to analyze non-white faces). But as I’ll get into it in a moment, I would very strongly recommend this to historians of technology as a little guide to problems that deserve significantly more research. The author’s a web consultant, but I think we need to bring out the scholars. There’s good stuff here about geography, the 2010s -- more reports of personal experiences would make the story even more valuable. (I keep thinking about to another book I reviewed: Turco’s The Conversational Firm, which shows how far we can get with ethnographical strategies.)
There are some arguments here that are very dear to my heart. For example, on p. 137 and chapter 3, the author notes how engineers and product designers will focus on the main experimental flow, and minimize the importance of “edge cases.” For example, say 80% of the users are young, and only 20% are old (perhaps needing bigger fonts). Well, the company is going to focus on where the money is: So font-changing features may be downplayed. The author rightly stresses harm and consequences: Even though the 20% might not be where the money is, the negative consequences of not helping them out with a useful UI can cause a lot of damage. One area I have been concerned about is privacy and security in healthcare. Say a login code is sent to an email: But that email might go to a shared account. For the most part, this is probably not troubling: The user “opted in,” supplying that email. But should we work harder to ensure that only the individual can access that account? What if it’s a shared account and medical details about domestic violence make it to that address. Again, say the patient has signed a consent to allow that message to go via email to a particular address. Should that minority example make us very concerned to protect the “minority” user pattern? I think so. The book does a good job walking the reader through this.
But I have some concerns:
* Geography: Time and time again, the examples lean towards west coast companies: Uber, Facebook, Twitter, etc. There are some exceptions. But I’d like to know: If the California tech culture is so bad, are there other places that are better?
* Timespan: Is this a particularly bad moment? Wachter-Boeettcher provides the appalling facts around the decline of women computer science majors (37% in 1984, 18% in 2014). “I can’t pretend to know the precise reason for this shift” (p. 182). Me neither. But this book is so anchored in the present, it begs the question of how we would assess, say, the tech culture of the 80s. I bet it was better. But was it? Just as an example, back in the day, Ann Wollrath was the lead author on the original RMI article. Big stuff. What was the culture? It would mean a lot if Wollrath told us that it was the same back then. Then we might understand the core problem as a more broader ill.
* Intentions: There are some good anecdotes here about how female voices are used for Siri, Alexa, and Google Maps (etc.) (pp. 36-38). Right. But what conclusion should we draw? “Women are expected to be more helpful than men . . . The more we rely on digital tools in everyday life, the more we bolster the message that women are society’s ‘helpers’” (p. 38). I get this. But then the author says: “Did the designers intend this? Probably not.” I protest! Go out and interview the designers! What were their reasons? Apple, in particular, thinks hard about this stuff. What were the factors going into a female Siri, and how did they outweigh providing other Siris (male; accented; whatever)? I want to know. The book makes an insinuation, but I think there’s a real research task to be performed. Bring out the ethnographers.
In large part, the book is driven by articles in the tech media. The next step is to get out there and start quoting people on their individual experiences, in order to test some claims (e.g., is the problem peculiarly tech in California in the 2010s? Or is it men in tech (more geography would help)? Or even a side-effect of the investment structure and capitalism (seems implicit in chapter 9) -- and, in particular, figure out where people are doing it right, and why. [The one positive example given in the book is Slack, but I’m not going to give much quarter there: Slack was produced by advertising and exploring the corporate customer’s desire to control discourse in the company, not by inclusiveness.]...more
Wow. This is an amazing ethnography of a technology firm that focuses on marketing . . . whose leadership chose not to define rules but to inculcate aWow. This is an amazing ethnography of a technology firm that focuses on marketing . . . whose leadership chose not to define rules but to inculcate a culture based on conversation. I'm going to have to expand this review, but for now I'll just say . . . if you work in 2017, this is a must read: It provides many qualitative insights but the groundwork is empirical.
The book is a 100pp case study of a software project for the Swedish police, followed by some brief chapters on a number of concrete techniques.
What iThe book is a 100pp case study of a software project for the Swedish police, followed by some brief chapters on a number of concrete techniques.
What is great about the book is that Kniberg will steal bits from all of the methodologies he knows (Scrum, XP, Kanban, etc.) to "get it done." On a number of occasions, he says (more or less): "Well, I think we can improve that eventually." For a software project methodology book, it is remarkably open. It is, therefore, a pure version of the Scrum mantra: "Inspect and adapt."
A few specific things: Describes a two-tier system for managing deliverables; computes velocity not based on points but on delivered features; talks about the necessity of having "slack" so that you can respond to urgent tasks.
About my only reservation is that in 2016 this book from 2011 is a wee bit dated; for instance, most teams I know are delivering software every day, and not at the tempo of a month or two as described in this book. But if you're reading the book now, you're probably cool with that. ...more
It is with some regret that I give this book 5 stars, because I have met some of the people in this book, and there is a lot here that is undoubtedly It is with some regret that I give this book 5 stars, because I have met some of the people in this book, and there is a lot here that is undoubtedly a hatchet job (more about that in a moment). But it's so damn entertaining, and bears so many truths about the world of Internet startups, that I have to acknowledge that this is a "must read."
Dan Lyons shows realistically and with great humor that some Internet startups have built a culture that engages in trivialities, is ageist, sexist, and not very diverse. If you're in college or in your 20s and think that you want to get involved with a startup, read this. Meanwhile, his subject is a marketing company (his is HubSpot) -- some of which are the bottom feeders of the Internet. These are companies that provide the tools to send spam and cultivate attention through devious link-baiting and other technological tricks. Ironically, the marketing company in question centers its lead generations not on the "inbound marketing" techniques they champion, but via a call center boiler room where they exploit (according to Lyons) cheap "bros" as employees. Lyons also pays witness and is a victim to some very crude management and power moves that I have seen in my own time in startups.
And why are these startups so badly managed? Not very well articulated here, the answer is growth. These companies must grow or die, and the "hockey stick" of growth provides berths for a lot of people who should have been shed by such companies earlier. Indeed, Lyons's own hiring is probably evidence of the desperation of a company that is growing very fast and doesn't really understand its own business. They think they have a place for an ex-writer for Newsweek, but really, they don't. They're acting on a fantasy. But is that surprising? Not when the company can't yet figure out their business model and how to make money.
I'm a 20-year veteran of startups, and am older that Lyons, so much of his testimony rings quite true. I have been very lucky myself and so far have not seen much age discrimination, though everywhere I see the lack of diversity he describes. As an industry, we're trying to fix that, but it's going to take a long time.
Having said all that, Lyons is incredibly naive in his own narrative. He gets his job via the CEO and the CTO, but then finds himself neglected by the chief marketing officer. Welcome to the working world! Lyons should have picked up much earlier that there is really no place for him at the company. He sticks around, and sticks around, and his protests that he needs his paycheck strike a false note because he very swiftly gets an opportunity to write for the "Silicon Valley" series, and eventually snags a writing gig at ValleyWag. Why not sooner? Hard to say. He seems to think there is some dignity in his old job -- journalism -- where he prides himself in being able to trade dirty jokes. Really? That's the good old place?
There is a constant drumroll of negativity regarding the CMO, but the reality is that he presents very little evidence that the CMO cares at all. The insinuation is that the CMO is irresponsible, but the presentation of the facts on that score is pretty weak. Eventually the CMO is fired for events that seem to be about capturing the manuscript of this very book - but so far the records are sealed and so it's all a hypothesis.
Finally, a huge gap is the story around HubSpot's engineering and product teams. Lyons notes frequently that the software is mediocre, but yet customers stick with it. Maybe we should infer that the product is not so bad. Knowing some of these people, again I'll suggest that the perceived gaps in the software have a lot to do with growth and the stress around shifting product requirements and the competitive landscape.
Once again, to the college or 20-something reader: There are great technology startups out there that have a real mission. Seek them out. And let's hope that someone writes a book as entertaining as this one that is about a company that does right by its customers, shareholders, and the public. ...more
I am not much of a fan of the various things the Andreessen Horowitz (aka a16z) VC firm says to the press, but I read enough positive notices of this I am not much of a fan of the various things the Andreessen Horowitz (aka a16z) VC firm says to the press, but I read enough positive notices of this book that I decided to read it, and . . .
This is one of the best business books I've read, particularly for technology startups. I actually laughed out loud in two places that were big learning moments for me. These are not spoilers, they are just little incidents, to wit:
First, Netscape had to create a very aggressive market strategy to get parity with Microsoft in the web server business. They were lagging. They come up with something good, and scheduled an announcement. Then, two weeks prior, the author's CTO, Marc Andreessen, spilled the beans to an industry rag. Horowitz emailed him and said (I paraphrase) "so much for the scheduled announcement." Andreessen wrote back a mighty reply, schooling Horowitz on the important of the opportunity to announce, and how they were getting "killed killed killed killed" in the marketplace. Andreessen signed off, "f--- you," and cc'd the CEO and chairman of the board. Of course, Andreessen was right, and the violation of protocol was appropriate given the emergency.
My second laugh can when Horowitz found his key executive sales leader. The funny bit here was that Horowitz really underestimated the person. With 5 minutes left in the closing interview, he asked; "Do you know anything about training sales people?" And the candidate pulled out an inch-thick binder of self-authored training materials, and said, "if you're really serious, we can reschedule for two hours and I'll tell you everything you want to know about training." Everyone on Horowitz's board was against the hire, but this guy was clearly the pro, and he got him, and the company survived some really difficult challenges.
In any case, the book is loaded with clear analyses. One thing Horowitz is quite good at is the articulation of decision trees. Horowitz will tell the reader; "If you can answer this question with 'yes,' then go this way; if 'no,' then this other way." I think there was at least one discussion that went three levels deep talking through the options.
About my only complaint is that I wish there was more discussion of how the OpsWare company was extracted from LoudCloud. He tells the story, but I would like to know more about extracting a software company from a services company.
I could go on, but I find it hard to imagine anyone in business who wouldn't learn something and meanwhile be entertained. The key audience is CEOs or potential CEOs, but as a middle manager in tech, I got a lot out of this.
[Note added 23-Feb-2017: This seems to have a lot of likes, but I want to make sure that people understand that my perspective is a bit specialized. T[Note added 23-Feb-2017: This seems to have a lot of likes, but I want to make sure that people understand that my perspective is a bit specialized. The book is lively and very interesting. If you want to read a provocative and detailed story of innovation, this is a great choice. I think the full story requires some extra reading, which I note in the review. The book has its limitations, but it's still a "good read."]
Regrettably, I can't give this a great review.
In part, it depends on what you want. If you want a history of innovation from the point of view of the winners -- the people who created the technology we use today -- then this book might be for you.
Isaacson hits all of the main highlights of the development of digital technology from Ada Lovelace to Google. In terms of new contributions, his treatment of Lovelace is much broader than what one normally gets, and he's very good on the women who worked as programmers for Eniac and the like. That's good. Additionally, there is new interview material that provides details that I haven't seen elsewhere: For instance, the book notes that both parents of Tim Berners-Lee (inventor of the web) were computer programmers, and that TBL was an electronics nerd as a kid. The quotes from people like the founders of Google are a bit looser than usual. I like that.
Yet there are three big problems here:
(1) First off, this is a history of the victors, and its extremely "presentist" in that it privileges things that are our technology today. Thus people like Jef Raskin and Ted Nelson are essentially buried. Yes, there are a few words on Nelson, but he deserves more like 10 pages, and Raskin gets one mention. Raskin was the true originator of the Mac; he deserves way more credit. Another example: Gopher. The Gopher protocol, which predates the web, was extremely important, and, arguably, would have been more useful for certain kinds of information browsing. Yet another thing that is scanted (as in so many histories that involve computer-mediated communication) is the depth of social sharing on time-sharing systems; it was a big deal and seems to be just outside the view of most historians. I think Isaacson's canvas is large and this would have complicated his story.
(2) The discussion of bidirectional information transfer is very weak. It comes up on p. 300 with regard to Lee Felsenstein and the free speech movement. People like Felsenstein thought computer networks would change society because they might provide for "broadcast" from the citizen. Despite the advent of blogs, twitter, etc., the dominant model has been "publication" (as Isaacson rightly points out from his personal experience editing Time online - 420-422). But I think Isaacson makes a big mistake to not talk at significantly greater length about how bidirectionality was lost in the early history of the network. To be sure, he does get into the blogging phenomenon, but it is weak because so focused on a single individual (Justin Hall). Anyway, the concern isn't even so much about individuals contributing content, but the very structure of the Internet and the policing of "uploads" (for example, your broadband provider gives you a lot less data quota for upload than download). Obviously the missing figure here is Nicholas Negroponte, who long advocated for true bidirectionally for communication - his key case was always video out of the home, so grandparents could easily send movies to their kids. A similar gap to the lack of spadework to uncover the deeper interest in bidirectionally is the discussion of how Mosaic/Netscape never had a decent editor that might provide for easily composing web pages from the browser (see p. 418). This wasn't just an issue for the Berners-Lee: It was a howl coming from the early adopters of browsers. (The lack of such editors also points out limitations in the standards track and how RFCs cannot really turn the industry.)
(3) Finally, the biggest argument in the book: That innovation comes from teams and groups, not from individuals (479-488 and elsewhere). The qualifiers for this claim are huge. The biggie is that he means: "successful" innovation, i.e., innovation that has gone mainstream. Clearly there were plenty of team innovations that weren't absorbed by the marketplace. Shouldn't we then acknowledge how teams can fail? Additionally, what is meant by "teams" and "groups" isn't solid. Isaacson admits as much when disrupting his own claim by outlining "three ways that teams were put together in the digital age" (482). Sorry, you can't have your lumping claim, and then at the end of the book break it down. You can make the claim about three modalities of team innovation at the beginning of the book and then show it: But pulling this canard out at the end of the book is just not fair.
In sum, if this is the only book you're going to read, it's OK. But the real story is bigger and Isaacson's take on all this is slanted and focused way too much on the technology we have, rather than the technologies we might have. I don't think asking for that is asking for a different book, either, because Isaacson is interested enough in the losers to mention them. His book would have been immensely richer by giving them their due to the tune of perhaps 50 additional pages over the whole book....more
Let me note first that I work remotely as a technology leader at a Boston-based medical startup . . . but I'm basThis is a very tricky book to review.
Let me note first that I work remotely as a technology leader at a Boston-based medical startup . . . but I'm based in the Twin Cities. I know remote work very well. I use every tool in this book. I've been remote since the beginning, and my managers and colleagues understand the dynamic, but it's still hard, and not something that is fully embraced in our work.
I'm going to have to divide the readership up into categories:
(1) If you work remotely and have company that tolerates or promotes remote working, this book gets three stars.
The reason is that you will be hungering for more patterns and stories regarding the nitty gritty of how remote work actually . . . works. For instance, the book says (I paraphrase) "use Skype" . . . "you can work in a coffee shop" . . . "your manager needs to take extra care catching up with you" . . . "overwork can be a big big problem for remote workers - don't let them kill themselves with work" -- well, you know all this already.
The book is not really for you. To be sure, you will still learn things, and the book confirms a number of things you have suspected but not really articulated. For instance, it is very good on the paradox that workers in two fairly different time zones frequently get more done collectively: One reason is that because of the time shift, the team can't interrupt itself with random meetings: You always get 3 or 4 hours to get the core work done. Smart.
(2) Your company thinks remote work is insane.
You really need to read this book. For you guys, it's five stars all the way.
Don't listen to people like Marissa Mayer, who at Yahoo put the kibosh on remote work -- she is wrong (they may very well have a problem with badly-managed remote work . . .). With well-managed remote work, there are huge gains to be made in productivity and the happiness of your team, as well as the basic economics of your business. For instance: If you don't allow remote work, you are limited to the people in your geographic area; if you can handle remote work, then you can hire the very best in the whole world.
(3) Your company tolerates remote work but hasn't really figured it out. The book provides a good deal of guidance. I think this is a five star book for you, too, because it's about time that you thought hard about your lack of planning and thought in this area.
The good news is that there are great advantages to remote work. The bad news that it requires a lot of thinking to get it right. There are big contradictions in remote work. For instance, the authors advise that remote workers figure out a routine (pp. 209-211). Meanwhile, they note that "Routine has a tendency to numb your creativity" (p. 228). With freedom comes responsibility.
The book is quite padded - there are illustrations that seem to be there only to boost the page count. I wouldn't waste my money on a printed version: Kindle all the way.
Aside from the over-all argument, which is breezy but sound, I want to pick out a few specific points where I think there's some good detail:
-- securing your remote workers - pp. 61-63. -- why you don't need answers "right now" -- p. 77. -- different time zones can be a benefit -- pp. 91-92. -- use screencasts -- p. 95. -- benefits of company paying for gym memberships (p. 129) and allow people to make their own sensible buying decisions with company credit cards (p. 199) and managing their own vacations and time off (p. 200). -- you need to police snippy comments, which can be much worse in chat applications (p. 161). -- stop thinking that by just seeing people arrive at 8 and leave at 6 that's somehow good because people are putting in "a lot of hours" (p. 182). -- fewer meetings means better meetings, because face time is scarce (pp. 205-206). -- remote can be good even when you're local -- pp. 213-214. -- separate your computers; i.e., keep an iPad with no access to work email so you won't be tempted -- p. 215.
Loading...
