Author: Christopher Litsinger

Reinventing Organizations by Frederic Laloux explores non-hierarchical organizations (they’re called “Teal” organizations throughout the book) in an effort to explain how organizations can operate without much in the way of structure — essentially a CEO and then a bunch of title-less employees that simply find work that needs to be done and go and do it. It sounds utopian, to be sure, but Laloux explains the history of several successful businesses that have been operating in this paradigm for some time.
Probably most impressive is the story of Buurtzorg, a Dutch neighborhood nursing organization that grew from 10 to 7.000 nurses in 7 years, and has achieved incredible results:

The results achieved by Buurtzorg on the medical front are outrageously positive. A 2009 Ernst & Young study found that Buurtzorg requires, on average, close to 40 percent fewer hours of care per client than other nursing organizations—which is ironic when you consider that nurses in Buurtzorg take time for coffee and talk with the patients, their families, and neighbors, while other nursing organizations have come to time “products” in minutes. Patients stay in care only half as long, heal faster, and become more autonomous. A third of emergency hospital admissions are avoided, and when a patient does need to be admitted to the hospital, the average stay is shorter. The savings for the Dutch social security system are considerable—Ernst & Young estimates that close to €2 billion would be saved in the Netherlands every year if all home care organizations achieved Buurtzorg’s results. Scaled to the US population, this savings would be equivalent to roughly $49 billion. Not bad for just home care. Imagine if the incomparably bigger hospital organizations were to be run in a similar manner.

The book is filled with similar stories of amazing results, but where it fails, for me, is Laloux’s absolutely positive view of the organizations and practices. At no point is there any serious exploration of negative impacts the organizational changes described. The only negative language used in this book is to describe those who doubt that the system, and the book often uses flowery new-age language to describe business environments: a “beautiful set of practices”, a “wonderful procedure”, “we need integrity and wholeness to transcend the primacy of profits and heal our relationship with the world.” It feels more like a book about religious or spiritual practices than a book about business. Because of the overly-positive descriptions, and lack of any raised concerns, I found the book to be untrustworthy, especially given what I’ve read about Zappo’s attempts to adopt Holacracy.
Some of my peers who enjoyed the book more than I have share my skepticism about some of these practices in the context of a software development organization: I was disappointed that there was no example there. Laloux also doesn’t answer questions of scaling to my satisfaction: I find it telling that the book mentions (frustratingly briefly) that the two largest organizations discussed have both abandoned their “Teal” practices.
Laloux also blows right by issues that raise my eyebrows — as here when he explains that a Morning Star employee is expected to write a letter to colleagues outlining a work schedule that raises life-work balance issues to me (not to mention my cringe at the idea of having to write a commitment to colleagues outlining said “balance”):

Morning Star has a similar practice: each colleague indicates in his CLOU [Colleague Letter of Understanding] his work schedule commitment. A person might indicate, for example, 40 to 45 hours off-season, and 50 to 55 hours in high season (when tomatoes are harvested and processed). Because colleagues discuss their CLOUs, they know about each other’s commitments.

My biggest concerns are with the descriptions of the feedback and conflict resolution processes described in the book. Here’s a bit about feedback:

The first is simply to approach feedback with the ancient insight shared by all wisdom traditions. We can approach the world from one of two sides: from a place of fear, judgment, and separation; or from one of love, acceptance, and connection. When we have difficult feedback to give, we enter the discussion uneasily, and this pushes us to the side of fear and judgment, where we believe we know what is wrong with the other person and how we can fix him. If we are mindful, we can come to such discussions from a place of care. When we do, we can enter into beautiful moments of inquiry, where we have no easy answers but can help the colleague assess himself more truthfully. Bringing this kind of mindfulness to discussions is something we can learn, something that can be taught. Simple practices can help too: we can start feedback sessions with a minute of silence or any other personal ritual that helps us tune in to love and care.

And here’s the conflict resolution process at Morning Star:

The conflict resolution process (called “Direct Communication and Gaining Agreement”), applies to any type of disagreement. It can be a difference of opinion about a technical decision in a given situation. It can be interpersonal conflict. It can be a breach of values. Or it can be related to performance issues, when one colleague finds that another is doing a lousy job or not pulling his weight. Whatever the topic, the process starts with one person asking another to gain agreement:

• In a first phase, they sit together and try to sort it out privately. The initiator has to make a clear request (not a judgment, not a demand), and the other person has to respond clearly to the request (with a “yes,” a “no,” or a counterproposal).
• If they can’t find a solution agreeable to both of them, they nominate a colleague they both trust to act as a mediator. The colleague supports the parties in finding agreement but cannot impose a resolution.
• If mediation fails, a panel of topic-relevant colleagues is convened. The panel’s role, again, is to listen and help shape agreement. It cannot force a decision, but usually carries enough moral weight for matters to come to a conclusion.
• In an ultimate step, Chris Rufer, the founder and president, might be called into the panel, to add to the panel’s moral weight.

Since the disagreement is private, all parties are expected to respect confidentiality during and after the processes. This confidentiality applies of course to the two persons at the heart of the conflict as well. They must resolve their disagreement between themselves and are discouraged from spreading the conflict by enlisting support and building rival factions.

Thinking about how these processes might look to someone who’s been discriminated against in life — who’s likely to approach any of these discussions feeling oppressed rather than empowered raises huge concerns for me. Can you imagine that conflict resolution process in the context of a sexual harassment incident? Step one is to sit together and sort it out privately? Then they need to find a mediator? I seriously can’t imagine that this is truly the process in that case, and yet Laloux (as always, ignoring any potential problem areas in the practices he describes) does not mention any other process. In that context — even if that would be legal (I can’t imagine it is) — it is horribly, deeply immoral.
Laloux would respond to my concerns that they are coming from my own fear and ego (the word “fear” appears 83 times in 326 pages of text). Maybe that’s true, but I don’t think I’ve approached much of my career out of a sense of fear, and I am genuinely interested in the approaches these organizations are taking.
In fact, in spite of all of my criticisms about the book, I found it a very worthy read. First of all, it was deeply challenging to many of the views that I hold. More importantly, in spite of the fact that Leloux suggests that attempting parts of these practices within a hierarchical structure is a waste of time, I found many ideas in the book (and in my thinking about the book) that I will be experimenting with over the next few months.

This is a self-published book that covers a lot of ground, and it has some flaws. Reading this feels a bit like experiencing a non-stop high velocity flow of ideas (sorry, couldn’t resist) that can be roughly organized and overwhelming at times (I was reminded of the character Jordan from the movie Real Genius).
But the ideas themselves? They are crazy thought provoking. This book has me thinking a lot, and I think you could choose almost any section of it and dig into the ideas for weeks before coming up for air. This book will definitely require a re-read to fully explore what I’ve discovered from reading it, and I expect to find it just as fascinating the second time through.
As the subtitle might have you guess, this is primarily focused on solving painful projects. As I read the book, I thought back to various projects I’ve worked on where Idea Flow could have made a tremendous difference in our ability to identify the correct problems, and sell the executives on why we needed to invest in fixing the issues identified. I’ve recommended the book to several folks who are currently working on projects that have a lot of “pain” and I expect it will help them quite a bit. One strong reaction I have after reading the book is that Idea Flow Mapping strikes me as an idea that would be very difficult to implement as a top-down initiative. This is a developer-led movement for sure — the amount of data that needs to be collected could easily be perceived as very “big brother”-ish (in fact, more than one developer I’ve described it to used exactly those words) as a management initiative. Klein’s own suggested presentation supports this:

I want to make the business case to management for fixing things around here. No more chaos and working on weekends, this needs to stop. I need data to make the case to management, though, so I need everyone’s help.

I also haven’t fully figured out my own reaction here, but although I think this framework could offer a lot of value to many teams (including teams that I’ve worked on in the past), I’m quite convinced that the approach described here would add little if any value to my current team. Why is that? I’m not sure — perhaps my team is small enough that the communication of ideas between the developers and code are easier to keep in sync. Perhaps it’s simply that the codebase itself is small enough. Maybe it’s just that the group of developers are similar enough to make ideas flow naturally. I’m also willing to concede that I may be flat out wrong. I know I’m going to be thinking through this for a while though, and trying to figure out why I think that this is true.
Even though the practices described here don’t feel right for my project right now, the ideas will influence the way I approach problems moving forward.
Klein’s ability to describe the escalation of pain in our processes can occasionally feel like re-living the very worst of our professional experiences:

The pain doesn’t happen all in one step. One decision usually sets up the preconditions for an unavoidable high-risk situation later.
The classic example of this in software is writing confusing code. When the code is written, the author can manage it fine, get it working and deployed to production. There is no immediate impact from this decision. The problem comes in when we have to understand or modify that code and there is suddenly a high risk of making mistakes.
The best way I’ve found to explain these problems, I picked up several years ago from an article by Scott Bellware. The pain comes from an increase in the number and severity of safety hazards.
When we use analogies like land-mines, fires, and various types of hell, we’re referring to the hazards in our everyday work. We may not be working with sharp objects or explosives, but the anxiety, stress and exhaustion from working in a hazardous environment is very real.
Likening these conditions to working around land-mines makes a lot of sense. We aren’t necessarily aware that we’re in a high-risk situation until we happen to step on the land-mine and something explodes. The lack of awareness makes these conditions all the more dangerous. It’s the knife that’s in the wrong drawer, the toys left out on the stairs, the loose screws in our bicycle. Hazards increase the risk of injury.
Let’s say we deploy some changes, then later realize we made a mistake. Our code is doing something horrible like over-charging our customers. Now we have an urgent situation on our hands. We care about the company and don’t want to fail, so we do whatever it takes.
Suddenly we’re working late nights and weekends, choking down Red Bull to stay awake, and hacking out last minute changes. We might end up breaking something else in the process.
It doesn’t matter if we’re sick, if we were supposed to go watch our kids’ recital, or meet our spouse for an anniversary dinner. When things go wrong and our project is online, we sacrifice a lot. At the moment of urgency, we can no longer choose safety.
By compromising safety, we increase the likelihood of making mistakes and the pain from the impact. Things don’t always go wrong, we’re gambling. If we’re lucky, we save time. If we’re not, we can lose big. The more we lose, the more time pressure builds and the more compelled we feel to gamble.
Compromising safety pulls us into a vicious cycle that’s fueled by constant urgency. We keep rolling the dice and making riskier and riskier bets, in an attempt to save time, but in the long-run our optimizations backfire.

The book is self-published and, as with many self-published books, it occasionally flared the OCD grammarian in me. A bigger problem for me is that it was not possible to read this on my kobo for two reasons. First, the images flow off to the right of the page, so they’re not fully visible. But even allowing for that, color is required for understanding the images — you’re going to have to read this on a color screen (or print it out, I suppose).
Organizationally, the book could use the hand of a professional editor as well. One example — the book could do a better job of laying out the mechanics of how idea flow mapping works and how to read an idea flow map a little earlier and more clearly. It’s not a complicated topic, but the book jumps quickly into showing idea flow maps without a sufficiently basic primer on what they are and how they work. By the end of the book, I think I understand how they work, but during the first few chapters I often felt lost.
Regardless of these small complaints, the book and it’s ideas are well worth exploring. You should go read it! If you’re not the reading type, you should at least watch Klein lay out her case here: Let’s make the pain visible

If you’re a reader of this site, you’re likely to have watched Amy Cuddy’s TED talk on power poses. This book expands on that, and is filled with fascinating insights into recent social science. I read the book after seeing Cuddy talk at Philadelphia Free Library’s Leading Voices. (You can listen to the podcast here.)
I was interested in the talk and the book largely because I’ve recently been spending a lot of time thinking about interviewing and hiring through the lens of building a more diverse team. One of the things I was hoping to get out of the book were some ideas for helping those from underrepresented communities in technology be more “present” during interviews. I certainly benefited from the ideas Cuddy presented in her TED talk when applying for my current job, and I shared the ideas with my daughter right before she kicked ass on the SATs. When I think about applying this from the other side of the interview, I have this vision of saying, “Okay, now stand in this room like Wonder Woman for 2 minutes, and I’ll be right back so we can begin.” Fun as the image may be, of course it would be far to socially jarring to actually work in an interview situation.
Why is it important to me to figure out how to put someone interviewing to work on my team at ease? Cuddy explains that better than I could:

Research shows that in pressure-filled situations, when we are distracted by thinking about possible outcomes of our performance, our skills are measurably diminished. When we explicitly monitor ourselves, second by second, any task that requires memory and focused attention will suffer. We don’t have enough intellectual bandwidth to perform at our best and simultaneously critique our performance. Instead we’re caught in a faulty circuit of trying to anticipate, read, interpret, and reinterpret how other people are judging us, all of which prevents us from noticing and interpreting what’s actually happening in the situation. This dynamic, which psychologists refer to as self-monitoring, is significantly higher for people who experience impostor fears. It takes us out of ourselves. It stands in the way of our presence.

So given that we know that interviewing is one of the most pressure-filled situations, what can we do when interviewing to break that faulty circuit? Here’s one useful thought from the book:

Pamela Smith, a professor of management at the Rady School of Management at the University of California, San Diego, and [Adam] Galinsky have demonstrated in their research that power often operates at a nonconscious level, meaning that it can be activated without our knowledge — turned on like a switch — and can affect our thoughts, feelings, and behaviors in ways we’re not even aware of. That’s good news. It means we don’t need to wear a crown to feel powerful, and we don’t have to plot and strategize ways to deploy our power in order to reap its benefits.
Recall a moment when you felt personally powerful. A time when you felt fully in control of your own psychological state — when you had the confidence to act based on your boldest, most sincere self, with the sense that your actions would be effective. Maybe it was at work, at school, at home, or in some other part of your life. Take a few minutes right now to remember and reflect on that experience of your personal power, on how it felt.
It felt good, right? Whether you know it or not, you’ve just been primed. Thanks to that little exercise, your psychological state was, and likely still is, infused with feelings of confidence and strength.

How simple would it be to start an interview with a question like “Tell me the professional accomplishment that has made you the most proud?” If that should prime someone to feel more confident, and have a better conversation? Well, chances are, you’re going to have a much better conversation.
During Cuddy’s talk, I asked her whether there was any research on how an interviewer could improve a candidate’s confidence through body language (you can here her response at about 1:08 in the podcast). She offered three concrete suggestions. “Come out from behind the desk… Be aware that your presence is really intimidating… so make sure that you’re not using that big expansive body language… Listen for whether they’re telling you everything they want to tell you… Ask, ‘Is there something else you’d like me to know about you?'”
The book offers another, related interviewing tip on the importance of warmth and openness in our body language:

In a famous 1974 paper, Princeton psychologists presented a pair of experiments on the self-fulfilling power of body language. The researchers wanted to know if white college admissions officers were unconsciously adopting cold, disengaged, and discouraging body postures (e.g., orienting their bodies away from the applicants, crossing their arms, not nodding) when interviewing black applicants, and, if so, how these postures might affect the applicants’ interview performance. In the first experiment, white interviewers were randomly assigned to interview either black or white applicants. Indeed, when interviewing the black applicants, white interviewers used cold, disengaged body language, and the black applicants were perceived to have performed more poorly in the interviews than the white applicants. In the second experiment, trained white job interviewers were split into two groups and instructed to use either cold, disengaged body language or warm, engaged body language. They were then randomly assigned to interview either black or white applicants. The black applicants performed as well as the white applicants when their interviewers exhibited warm, engaged body language. And applicants of both races performed equally poorly when their interviewers behaved in a cold, uninterested way.
Furthermore, in both cases, the applicants’ body language matched that of the interviewers; they were unconsciously mimicking what the interviewers did, which is what we usually do in social settings. In short, our body language, which is often based on prejudices, shapes the body language of the people we’re interacting with. If we expect others to perform poorly, we adopt body language that is off-putting and discouraging. Naturally, people take the hint and respond as expected — poorly. How could anyone ace an interview under those circumstances?
When our body language is confident and open, other people respond in kind, unconsciously reinforcing not only their perception of us but also our perception of ourselves.

Again, simple — remember to lean in towards the speaker and pay close attention. Nod or vocalize encouragement when appropriate. Orient your body towards the speaker. If you’ve been put in the position of interviewing candidates, hopefully you understand how to do these things in a way that feels natural. Essentially, treat the conversation as if you’re going to find it deeply fascinating, and chances are, you will.
The book offers far more than some useful insights into interviewing; it’s filled with research that will spark your imagination: after reading about research into risk-taking after assuming power poses (spoiler: it goes up) I became worried about what casinos might be able to do with that research. After reading about how her research has been applied to horse training(!) I’ve been debating conducting some research on our pets.
Cuddy has filled the book with the personal stories of many people who have been inspired to reach out to her and explain how her TED talk has changed their lives. While these stories provide a good bit of the heart and soul of the book, at times this feels a bit overwhelming (especially in the final chapter, which is essentially a collection of these stories). Very strongly, the same warmth, humor, and personal experiences that compelled us all to share Cuddy’s TED talk come across on almost every page of this book. It’s well worth the read.
Update:FiveThirtyEight has published an interesting article on problems in reproducibility which talks about Cuddy’s research quite a bit.

[disclaimer: this is based on a “beta” copy of this book from gitbooks. the book is not complete at this time, and may be a bit different by the time you read it. I believe that most of my comments will still apply, but I’m also likely to re-visit this when it is complete.
further disclaimer: I happen to work with Pam Selle. However, this was not a solicited review, nor was it discussed with the author.]
If you’ve seen Pam Selle talk, or listen to the Turing-Incomplete podcast, then you’re probably going to read Beyond the Resume: How to get your next job as a developer in Pam’s voice, which comes through clearly in the book’s conversational tone. In this case, that’s definitely a good thing. It’s like sitting down with a friend or colleague and getting some advice over coffee. Which is probably exactly what you’re looking for while you’re dealing with the stress of a job search looming over your head.
Of course, in this case, you’re sitting down with someone well connected in the industry who has some useful insights on how to effectively frame a job search in the candidate-friendly tech job market. I don’t agree with everything Selle has to say, but it’s certainly useful and thought provoking; and I suspect the final edit will be well worth consideration. As the subtitle indicates, Selle’s insights are focused on the developer market- while there may be some comments of generic utility, this probably won’t provide value if you’re trying to land a job as a CPA.
Overall, if you’re looking for a job as a developer, the book is well worth the read. Here’s a quick sample that I think does a great job of capturing the tone and utility of the book:
In fact, a search for “$YOURLANGUAGE interview questions” will serve you very well, because here’s an unfortunate truth:
Most engineers are terrible at interviewing.
Not only are they terrible, they often have little guidance on what they should do, what questions they should ask. Even if they do have some guidance, I can almost guarantee these kinds of technical interviews will be similar to what you can practice online.