This week I created a Dockerized development environment for Panlexicon. I find it’s forever a struggle to bridge the Docker-for-development and Docker-for-production workflows and configuration, but this is Docker-for-development.

I’ve been working on “project planning as narrative”, having written out a long story about an accessibility project that has yet to kick off. Here’s an excerpt:

This led to a collaborative discussion that was also tinged with reasonable fear: how can our team ensure that we’re taking into account the newly collected design considerations? We knew that this would involve some new skills: screen-reading, keyboard navigation, low-vision simulation, and more.

It’s easiest to learn new skills when they’re grounded in practice, so we placed their usage within the context of our delivery pipeline:

1. Design: Screen-reading, expanded awareness of content/action hierarchy, inclusive design patterns. [Design]
2. Prototyping: Expanded usability testing community. [Design, UX Research]
3. Development: Inclusive design patterns, validation and automated testing. [Engineering]
4. QA and Acceptance: screen-reading, keyboard navigation, low-vision simulators. [Engineering, Product Management]
5. Support: expanded awareness [Client Success].

I was reminded of this long story about Windows Vista via a Highly highlight. The thoughts from my notebook (that I then tweeted about:

What would principles of continuous delivery look like if applied to project planning and management? What would be necessary for a project to live in a continuously deliverable state?

I read another long article from Christina Maslach on Burnout.

If there’s one image that I’m talking about today that I hope you remember, it’s this — we have found that the fit, the match, or the balance between a person and the job, is critical for burnout in six areas. They are not listed in order of importance. They’re listed in order of which one people think of first.

• Workload is the one that everybody thinks of first. It must be they’re working too hard. They’re stressed out. The imbalance between too many demands, too few resources to get it done. But there are five other areas that turn out to be just as important.
• Control. In other words, how much autonomy you have in your work, how much choice, or discretion to figure out how to do it the best way or innovate in some way.
• Reward. People think of things like salary, benefits, perks, et cetera. We’re finding in the research that social reward is sometimes more important, that other people notice that they appreciate what you do and let you know that you’ve done something that’s really meaningful.
• Community. These are all the relationships that you have at work, with other colleagues, your boss, clients, whoever. Are those relationships functioning well? Are they supportive? Do you trust? Do you have ways of working out disagreements and figuring out how to move forward, work together well on teams, et cetera.
• Fairness. This turns out to be a very important one. Is whatever the policy is, whatever the practices are, here in this place, are they fairly administered in terms of who gets the opportunity? Are there glass ceilings, or discrimination, or other things that block people from moving forward when they should have that chance?
• Values. Which sometimes turns out to be one of the most important. This is meaning. This is why am I doing this. Why am I here? What do I care about? What is important to me, in terms of what I think is important for our society, the contributions I make, and so forth? With burnout, it’s not just about being exhausted and working too hard and being tired. It’s often that the spirit, the passion, the meaning is just getting beaten out of you, as opposed to being allowed to thrive and grow.

These six areas offer entry points into what could we could be doing differently, that might actually create a better, healthier, improved workplace to support the things we want to achieve.

I follow several blogs that are all-in on Event Sourcing; reading “Event Sourcing is Hard” was refreshing:

What’s the take away here? Should I event source or not!?

I think you can generally answer it with some alone time, deep introspection, and two questions:

1. For which core problem is event sourcing the solution?
2. Is what you actually want just a plain old queue?

If you can’t answer the first question concretely, or the justification involves vague hand-wavy ideas like “auditablity”, “flexibility,” or something about “read separation”: Don’t. Those are not problems exclusively solved by event sourcing. A good ol’ fashion history table gets you 80% of the value of a ledger with essentially none of the cost. It won’t have first class change semantics baked in, but those low-level details are mostly worthless anyway and can ultimately be derived at a later date if so required. Similarly CQRS doesn’t require event sourcing. You can have all the power of different projections without putting the ledger at the heart of your system.

The latter question is to weed out confused people like myself who thought the Ledgers would rule the world. Look at the interaction points of your systems. If you’re going full event sourcing, what events are actually going to be produced? Do those downstream systems care about those intermediate states, or will it just be noise that needs to be filtered out? If the end goal is just decoupled processes which communicate via something, event sourcing is not required. Put a queue between those two bad boys and start enjoying the good life.

I was heartened to read this about “How the Seattle Times is empowering reporters to drive subscriber growth”:

Over the past year, the news publisher, which grew its digital subscriber base 38 percent to 40,000 in 2018, has been trying to get small teams of reporters to think more entrepreneurially about driving subscriptions. It wants them to not just monitor which kinds of content visitors read on their way to paying but also to experiment with new content and packaging formats designed to keep readers engaged.

In 2017, the Times gave its newsroom staff access to a dashboard that showed reporters which stories they published were driving subscriptions. Next, the Times’ executive editor, Don Shelton, formed several teams, called mini-publishers, which paired editorial staffers with members of the paper’s digital audience, product and business intelligence teams to figure out what kinds of content the audience likes, how to make more of it, and so on.

I’m trying out week notes in the spirit of Phil Gyford :

a nice way to group lots of small things together that I wouldn’t bother writing individual posts about.

I binge read Fred Brooks The Mythical Man Month after seeing someone tweet a Brooks’ quote of “everybody quotes it, some people read it, and a few people go by it.” Two surprises:

1. an emphasis on a titular technical decider:

   Conceptual integrity is central to product quality. Having a system architect is the most important single step toward conceptual integrity. These principles are by no means limited to software systems, but to the design of any complex construct, whether a computer, an airplane, a Strategic Defense Initiative, a Global Positioning System. After teaching a software engineering laboratory more than 20 times, I came to insist that student teams as small as four people choose a manager and a separate architect. Defining distinct roles in such small teams may be a little extreme, but I have observed it to work well and to contribute to design success even for small teams.

2. definitely not in the “never plan” camp:

   Sharp milestones are in fact a service to the team, and one they can properly expect from a manager. The fuzzy milestone is the harder burden to live with. It is in fact a millstone that grinds down morale, for it deceives one about lost time until it is irremediable. And chronic schedule slippage is a morale-killer.

We had a work trip visiting Montgomery, Alabama to attend the National Memorial of Peace and Justice and the Legacy Museum, in addition to the Civil Rights Museum and the Rosa Parks Museum. At the legacy museum there was a neat display weighing regressive court opinions (2x) vs progressive ones. I liked a quote from Justice Brennan, in dissent of one of the regressive ones, criticizing the majority of having a “fear of too much justice”.

Two weeks ago I attended a manager training. One suggestion was to dedicate the 1st one-on-one of the month to career development, to ensure it happens. I followed that advice with my reports and had some incredible conversations. I asked them to pick from the Career Planning cards from the Plucky 1:1 Deck.

Technically I focused on linting this week. While onboarding a new rotation to our team they asked, like everyone asks, about a code styleguide. By agreement the team has suggestions but not requirements, but personally being tired of getting the same new-person sourface that proceeds (including my own when I joined), I said that if that’s something they care about, let’s pair on it right now. So we did.

From this post by Cate Huston on burnout I learned about the Maslach Burnout Inventory which has 6 “mismatches” that cause burnout:

1. Lack of control
2. Insufficient reward
3. Lack of community
4. Absence of fairness
5. Conflict in values
6. Work overload

Last, I got an email that the Foundation Center and Guidestar are rebranding as Candid

. I think it’s ridiculous.

I recently responded to a question on FounderCafe

asking “How important is Founder’s Profile to be visible on website?”; this was my answer:

I do think it can be helpful for a small business to have a brief personal narrative about who you are and why you’re creating the business. How you expose that story depends.

I have a lot of anxiety about my business generally. I do have fears that by connecting the business to myself personally that my business failing is a personal failure. I have previously tried to hide behind an impersonal “business” (generic reply addresses, 3rd-person copy) but I’ve lately been trying to not hide behind that curtain.

As a small business, my customers are just as likely to interact with me as they are to interact with “the product”. From onboarding emails and messages, to microcopy within the application, these are driven primarily by a small number of people’s values and personality. Grounding that by letting people know “hey, I’m a real person whose business and personal goals are intertwined” can get you better feedback and maybe give you the benefit of a more meaningful connection (personally and business) with your customers.

If I’m understanding some of your concerns, it sounds like you’re worried that by connecting your name to it, that it will negatively impact your day jobs. I’ve personally never had a problem with that, but that’s heavily situational.

This was another experience that resonated:

When I didn’t have my founder story, I had occasional customers categorize me as some outsourced company, but after I added my profile, those emails stopped.

Your most passionate customers will care about your story, and passionate customers are extremely important in the beginning. Honestly, your story, relatability, and likability might be what closes your first sales.

A Wikipedia Essay that is itself primarily a quote:

Chesterton’s fence is the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood. The quotation is from G. K. Chesterton’s 1929 book The Thing, in the chapter entitled “The Drift from Domesticity”:

In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”

From Escaping the Build Trap by Melissa Perri:

Product managers ultimately play a few key roles, but one of the most important ones is being able to marry the business goals with the customer goals to achieve value. Good product managers are able to figure out how to achieve goals for the business by creating or optimizing products, all with a view toward solving actual customer problems. This is a very important skill set.

When you look at the role of the product owner in most Scrum literature, the three responsibilities of the position include the following:

• Define the product backlog and create actionable user stories for the development teams.
• Groom and prioritize the work in the backlog.
• Accept the completed user stories to make sure the work fulfills the criteria.

These are the functions that are focused on and taught in the shorter product owner trainings, usually over a day or two. Although Scrum has a lot of information on the processes and rituals of what to do as a product owner, it leaves lots of questions unanswered and these questions are important for creating successful products:

• How do we determine value?
• How do we measure the success of our products in the market?
• How do we make sure we are building the right thing?
• How do we price and package our product?
• How do we bring our product to market?
• What makes sense to build versus buy?
• How can we integrate with third-party software to enter new markets?

Product ownership is just a piece of product management. A good product manager is taught how to prioritize work against clear, outcome-oriented goals, to define and discover real customer and business value, and to determine what processes are needed to reduce the uncertainty about the product’s success in the market.

From Overcoming The Five Dysfunctions of a Team by Patrick Lencioni:

How many people should be on a team?

This is the $64,000 question, for sure. And while there is no way to answer it definitively for every organization, I believe the range is from three to twelve.

Most organizations I work with err on the side of including too many people on a team, in many cases because they don’t want to exclude anyone. It’s as though they’re mistakenly viewing team membership as a reward or a benefit rather than as a strategic decision about how to best run the organization. And while I salute the desire to be inclusive, there are some big problems with having too many people on a team:

• On a purely practical and tactical note, it’s tough to coordinate meetings and other team activities when there are fifteen schedules to consider.
• More important, it’s difficult for team members to get to know one another, develop bonds of trust with one another, when there are too many people in the room. Generally speaking, a kid who grows up in a family of ten children is probably not going to have as deep and meaningful relationship with most siblings as a kid born to a family of four. Generally speaking, that is.
• But perhaps most important of all, having too many people on a team makes team dynamics during meetings and other decision-making events almost impossible. That’s because a good team has to engage in two types of communication in order to optimize decision making, but only one of these is practical in a large group.

According to Harvard’s Chris Argyris, those two types of communication are advocacy and inquiry. Basically, advocacy is the statement of ideas and opinions; inquiry is the asking of questions for clarity and understanding. When a group gets too large, people realize they are not going to get the floor back any time soon, so they resort almost exclusively to advocacy. It becomes like Congress (which is not designed to be a team) or the United Nations (ditto).

One member says, “I think we should pursue proposal A,” provoking another member to say, “Well, I think we should pursue proposal B.” Someone else lobbies for C, yet another person wants A with a slight modification, and before you know it, everyone is trying to get their opinion heard.

Inquiry, on the other hand, would entail one of the members saying, “Wait a minute. I’d like to hear you explain why you support proposal A, because I want to understand your rationale. After all, if it makes sense, I could go along with it.” Okay, that might be just a little too idealistic, but you get the point.

From Overcoming The Five Dysfunctions of a Team by Patrick Lencioni:

Question #1: Are we really a team?

Sometimes a team improvement effort is doomed from the start because the group going through it isn’t really a team at all, at least not in the true sense of the word. You see, a team is a relatively small number of people (anywhere from three to twelve) that shares common goals as well as the rewards and responsibilities for achieving them. Team members readily set aside their individual or personal needs for the greater good of the group.

If your “team” doesn’t meet these criteria, you might want to consider whether you have a smaller subset of the group that is a real team. Or maybe the group is simply a collection of people who report to the same manager, but with relatively little interdependence and mutual accountability (that is, not a team).

And remember, it’s okay to decide that your group isn’t a team. In a world where teamwork is rarer than we might think, plenty of non-teams succeed. In fact, if your group is not meant to be a team, it’s far better to be clear about that than to waste time and energy pretending you’re something you’re not. Because that only creates false expectations, which leads to frustration and resentment.

I’ve been wondering a lot about defining a team as a group of people who receive rewards when those rewards are indirect e.g. there isn’t a financial reward. When working within a nonprofit context, there is impact (bettering the world) but not everyone involved is able to turn that into social or economic gain. In other words, the work you’re doing doesn’t advance your career from a skills/competency perspective, and your position doesn’t allow you to claim a significant leadership narrative that might accrue social benefit (thought leadership).

From Marshal B. Rosenberg’s Nonviolent Communications:

“The Most Arrogant Speaker We’ve Ever Had!”

This dialogue occurred during a workshop I was conducting. About half an hour into my presentation, I paused to invite reactions from the participants. One of them raised a hand and declared, “You’re the most arrogant speaker we’ve ever had!”

I have several options open to me when people address me this way. One option is to take the message personally; I know I’m doing this when I have a strong urge to either grovel, defend myself, or make excuses. Another option (for which I am well-rehearsed) is to attack the other person for what I perceive as their attack upon me. On this occasion, I chose a third option by focusing on what might be going on behind the man’s statement.

MBR: (guessing at the observations being made) Are you reacting to my having taken thirty straight minutes to present my views before giving you a chance to talk?

Phil: No, you make it sound so simple.

MBR: (trying to obtain further clarification) Are you reacting to my not having said anything about how the process can be difficult for some people to apply?

Phil: No, not some people—you!

MBR: So you’re reacting to my not having said that the process can be difficult for me at times?

Phil: That’s right.

MBR: Are you feeling annoyed because you would have liked some sign from me that indicated that I have some problems with the process myself?

Phil: (after a moment’s pause) That’s right.

MBR: (feeling more relaxed now that I am in touch with the person’s feeling and need, I direct my attention to what he might be requesting of me) Would you like me to admit right now that this process can be a struggle for me to apply?

Phil: Yes.

MBR: (having gotten clear on his observation, feeling, need, and request, I check inside myself to see if I am willing to do as he requests) Yes, this process is often difficult for me. As we continue with the workshop, you’ll probably hear me describe several incidents where I’ve struggled … or completely lost touch … with this process, this consciousness, that I am presenting here to you. But what keeps me in the struggle are the close connections to other people that happen when I do stay with the process.

From Brené Brown’s Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead:

Last year I gave a talk on vulnerability to 350 SWAT team officers, parole officers, and jailers. (Yes, it was as intimidating as it sounds.) A SWAT officer walked up to me after the talk and said, “The only reason we listened to you is because you’re just as bad at being open as we are. If you didn’t wrestle with being vulnerable, we wouldn’t trust you one bit.”

From Pietra Rivoli’s The Travels of a T-Shirt in the Global Economy: An Economist Examines the Markets, Power, and Politics of World Trade:

So, what do I say to the young woman on the steps at Georgetown University who was so concerned about the evils of the race to the bottom, so concerned about where and how her T-shirt was produced? I would tell her to appreciate what markets and trade have accomplished for all of the sisters in time who have been liberated by life in a sweatshop, and that she should be careful about dooming anyone to life on the farm. I would tell her that the poor suffer more from exclusion from politics than from the perils of the market, and that if she has activist energy left over it should be focused on including people in politics rather than shielding them from markets. And I would tell her about the shoulders she stands on, about her own sisters and brothers in time and the noble family tree of activists, and the difference they have made in a day’s life at work all over the world. I would tell her that, in just a few short years, I have seen the difference her own generation has made, and that someday people will stand on her shoulders, too. I would tell her that Nike, Adidas, and GAP need her to keep watching, and so do Wal-Mart and the Chinese government. I would tell her that I have met dozens of seamstresses in Chinese factories who need her, and that future generations of sweatshop workers and cotton farmers need her as well. I would tell her to look both ways, but to march on.

Specifically:

My T-shirt’s story, then, is not a tale of Adam Smith’s market forces, but is instead a tale of Karl Polanyi’s double movement, in which market forces on the one hand meet demands for protection on the other.

I also like this on boring meetings as a sign of progress:

With a long historical perspective, it seems clear that when the meetings get boring, we have taken a step forward. Boring meetings mean that the radical has become mainstream, and that the establishment has changed its mind about the very nature of right and wrong. The struggles for bans on child labor, or for fire exits or minimum wage or factory codes of conduct, are never boring. But when the fight is won, the meetings get boring. While the battle rages for and against, it is interesting. But when the battle is over and the fight is no longer about whether to have fire exits but where to put them, not whether to have a minimum wage, but how to administer it, not whether to disclose factory locations but by what means and how often—when the establishment has changed its mind and we are just working out the details in (yet another) early morning committee meeting—it gets boring.

From Michael Lewis’ The Undoing Project on how happiness and misery is experienced differently:

“What might have been is an essential component of misery,’” he [Daniel Kahneman] wrote to Amos [Tversky]. “There is an asymmetry here, because considerations of how much worse things could have been is not a salient factor in human joy and happiness.”

[..,]

Happy people did not dwell on some imagined unhappiness the way unhappy people imagined what they might have done differently so that they might be happy. People did not seek to avoid other emotions with the same energy they sought to avoid regret.

This bit on how people remember (and compare) bad experiences is also fascinating:

When he met Redelmeier, Danny was already running experiments on unhappiness in his Berkeley lab. He’d stick the bare arms of his subjects into buckets of ice water. Each subject was given two painful experiences. He’d then be asked which of the two experiences he’d most like to repeat. Funny things happened when you did this with people. Their memory of pain was different from their experience of it. They remembered moments of maximum pain, and they remembered, especially, how they felt the moment the pain ended. But they didn’t particularly remember the length of the painful experience. If you stuck people’s arms in ice buckets for three minutes but warmed the water just a bit for another minute or so before allowing them to flee the lab, they remembered the experience more fondly than if you stuck their arms in the bucket for three minutes and removed them at a moment of maximum misery. If you asked them to choose one experiment to repeat, they’d take the first session. That is, people preferred to endure more total pain so long as the experience ended on a more pleasant note.