Solving Problems & Saving Time through Software and Crushing Entropy
Powered by Cecil & Hyde.
The aphorism "A person is smart, but people are stupid" has always stood out to me. It never sat right. If an element of a set contains a property, then the set ought to exhibit the same property. Right?! Well, what are we really trying to communicate when we say this?
I think one aspect of what we're trying to say is that when we take a given person in a situation, we're probably imagining that person at their best. Any given person in their best moment, ready, willing and focused, is going to behave as intelligently as they possibly can.
But what are we saying about "people" in groups? We're no longer imagining one situation, but all situations. And not when any of those given people are at their best, but everywhere along the Bell curve of their possible performance.
We're comparing an individual high water mark, with the average of a bunch of people between their good and bad moments and days. No wonder! I think there is a more charitable description than we can give this than the common aphorism. That is: Humans Acting at Scale.
Why am I interested in this as a software engineer? I build systems that other engineers operate. I build products that users & customers operate. When building these systems and products there are a lot of decisions to make along the way. When we're making these decisions are we thinking about our users and their abilities?
Are we thinking that they will only be operating the system or product after 10 hours of good sleep, after their first cup of caffeine, in their favorite outfit, without a care in the world, and totally focused on doing an excellent job today? Or do we think that they'll be operating the system or product with one hand because with their other hand they are on the phone trying to get someone to come fix their furnace, after they got a bad night's sleep because their dog was up until 1am vomiting? If they drop their phone on the keyboard, or the cat walks across it—what happens?
How many things does this operator need to remember (Knowledge in the Head) versus things the system is showing them and giving them feedback on (Knowledge in the World)? How are details surfaced to the operator? How are expectations and impact of their operations communicated back to them? Do they get a clear confirmation screen? Are their actions reversible?
Once we're working with a product or system that is operated by a group, or multiple groups, of people we have to stop considering the fact that we know one of the individual humans who is operating it. "I know Steve, Steve is great at his job. This is a little complicated, but he can handle it." We have to consider how many other people are also operating it, who no doubt are also good at their job. But that we are all simply human, and our ability to perform & operate varies all the time due to an uncountable number of factors.
Demanding a standard of "just be better and don't make mistakes next time" is not a valid approach you can have towards operators.
Designing with empathy is not about pitying people, or even thinking you're better than them (you're not). It is about designing for the worst outcomes and making sure your system and product support what the humans need in the face of those worst outcomes.
Read more: Humans Acting At Scale
As a new manager, in an environment where team and company processes are morphing and changing, I have been asked to share my opinions on a number of topics. My answers are taking a common shape; tools are placeholders for conversations. The first example is Jira.
There are no shortage of opinions about Jira. Both the software itself, and the effects on teams it can have when wielded in certain ways. I have many strong opinions. I have almost no opinions on Jira. It is... irrelevant to me how people want to use it. How many columns on your board? How many statuses? Are we using labels, custom fields, themes? I say: "Whatever you want."
I do care about is the ticket. I don't care if the ticket has paragraphs of detail, I don't care if you use Jira as documentation (I think you're going to have a really bad time, but thats a different conversation). I don't care if the body of the ticket is empty and as the Engineer you prefer to write it in a notebook. I have zero feelings on that.
What do I care about for tickets? A ticket represents a conversation. I don't care where the conversation gets recorded, or at all (provided the people are capable of remembering it). My problem is when a ticket exists absent any conversation at all.
No matter how hard you try you're not going to have a successful handoff in a ticket. Not to mention handoffs are bad. Handoffs exist when one person has context, and others lack it. Now we have to perform a knowledge transfer. First, have as few handoffs as possible. Teams that work together should be building shared context together. If you have shared context, there is no handoff. How do you measure whether you're doing this well? When the real conversations about the tickets get shorter over time.
If you've worked at a startup I am willing to bet you've had this experience. You open up the Jira backlog. It is full of tickets. Old tickets, weird labels and epics. Acronyms you've never heard of that the startup doesn't even use anymore. You see dozens of tickets that only have a title. You're seething because you have no idea how to make any sense of it all. "Why didn't they document anything?!"
Those old tickets with only a title, no description, were created by some of the founding & early engineers. Maybe they're still working there, maybe they left a while ago. This is strong evidence of a team working with extremely shared context. That ticket may be two years old, but if you ask them about it—they can still describe what its about to you. That team had a conversation and created a ticket to mark the conversation. You're seething when you see this because you have none of the context, you weren't in the conversation.
That conversation is what matters. Jira (or Trello, Pivotal, sticky notes on a wall, pick any other etc) is only a good tool when it facilitates those conversations and makes sure that the team has them. If people use the tool to have the conversation thats what really matters. That is the best way your team is going to build shared context. And maybe one day they'll make tickets with only titles, but you won't be mad because you know exactly what they're going to do.
Read more: Placeholder for a Conversation
You have to be very intentional when you are trying to create an environment of psychological safety for people. This is not one of those things "that just happen", you have to go out of your way. It is not a natural state to find one's self in. After all, we are biologically attuned to address environmental threats. And the workplace can exhibit signs of competition, one-upmanship, intentional withholding, and even outright hostility.
If I am being honest, I don't know that I have ever experienced a fully realized sense of psychological safety at a job. From time to time, from moment to moment, and from one coworker to another there is definitely a sense of safety. Each different meeting, team, and random grouping of folks does require recalibrating that sense of safety, and if I'm not careful I can find myself in an awkward conversation without any feeling of safety.
A dozen years ago myself and two acquaintances decided to start a gym, mostly for ourselves and we figured there have got to be others out there that would be interested! Specifically a powerlifting and olympic weightlifting gym because those activities are "frowned upon" in typical gyms. (Mind you this was before, or just as, the Crossfit explosion was happening).
The first wave of people who showed up were truly random strangers. But they were there because they knew exactly what they were looking for and what they were doing. Soon enough the next wave of people who showed up were "interested" and had no clue what they were doing. We knew that if we wanted the gym to succeed we had to make these people feel welcome to the space, accepted by everyone else there, and most importantly safe.
It is no small thing to get under a bar with enough weight on it you truly don't know if you can lift it. For many, many people that is very unnerving and terrifying. Having people feel welcome in the space became second nature to us. We were very lucky to have the first folks that consistently returned because they truly accepted whoever walked in the door. People started chatting and helping one another load and unload weights and swap stations. Naturally folks came and went, but a core group helped us run the gym. Truth be told the weightlifting community (not "people who randomly go to a gym a few times a month") is an amazing community. And that larger community welcomed our small gym into it.
Creating the psychological safety for people to do something they've never really tried before, especially lifting barbells, took a lot of work. Over time we established a bit of a protocol that we would work through, and, when the time came, asked other long-time members to help us in instructing new members having them use the protocol. This is roughly what it looked like:
By the time they've been in the gym for 30 minutes they have seen many folks spotting one another. They know they can ask because others have demonstrated its safe to ask. They have seen a person squatting 315#+ spot someone with 135# on the bar. It doesn't matter how strong you are or how long you've been here—you help spot people.
If we extrapolate a little bit we can generalize how we found success in creating a safe space:
This is how we found success. We started in a dingy shared warehouse space and we kept expanding. Next we moved into an old maintenance garage that nearly doubled our space. People kept coming. On the packed evenings you could barely find enough space to stand out of the way while other people were lifting. We moved one final time to an even bigger space, a proper storefront, with actual parking!
As of six years ago I no longer help run the gym, as life was getting busier and busier. It is a phase of my life that I am very proud of. The gym is still going strong to this day which gives me so much joy.
Read more: Psychological Safety
An article from twenty-two years ago (1999, I still don't understand how time works) was the final crack that "broke the dam" in my mind. The article is called "Managing Oneself", written by Peter Drucker, published in HBR.
In the field of pedagogy there has long been the realization that everyone learns differently. Some people need to hear it, some need to read it, some need to repeat it, some need to simply take notes. This is all about input. What happens when you flip this and talk instead about output. About performance.
Drucker paints a large dichotomy: "Are you a reader or a listener? ... people rarely are both". And he uses the examples of presidents when discussing "How Do I Perform?"
Ten years later, the same journalists who had been his admirers held President Eisenhower in open contempt. He never addressed the questions, they complained, but rambled on endlessly about something else. And they constantly ridiculed him for butchering the King's English in incoherent and ungrammatical answers.\ \ Eisenhower apparently did not know that we was a reader, not a listener. When he was Supreme Commander in Europe, his aides made sure that every question from the press was presented in writing at least a half an hour before a conference was to begin. And then Eisenhower was in total command...\ \ A few years later, Lyndon Johnson destroyed his presidency, in large measure, by not knowing he was a listener. His predecessor, John Kennedy, was a reader who had assembled a brilliant group of writers as his assistants, making sure that they wrote to him before discussing their memos in person. Johnson kept these people on his staff—and they kept on writing. He never, apparently, understood one word of what they wrote. Yet as a senator, Johnson had been superb; for parliamentarians have to be, above all, listeners.
I don't know why but I had never in my life flipped the "learning" to "performing" and asked the question. Because, for myself, the answer is blindingly obvious. I am a strongly tilted towards reader. If we're having a discussion without enough context I have a really hard time adding any value.
As a reader there are organizations and working styles with which I will never perform well, no matter how hard we all try. I should be avoiding those environments. I need to make it clear to my manager(s) how I perform. And they should be making it clear to me how they perform.
However, do not mistake reader for; inflexible, rigid, or detailed. I thrive in chaos, am very adaptable, and generally am a big picture oriented person. I get the sense that, in many organizations, a reason "readers" are at a disadvantage is because writing is hard. After all: "To write well is to think clearly."
As a reader I want your clear thoughts. I don't want to do the work of sorting your thoughts out for you (unless that is actually my job). I need meeting agendas because I cannot help but sort out my thoughts into clear thoughts prior to the meeting. I ask that others do the same work. And the best way I know how to do that, at least for myself, is to write.
It is my experience that, when groups don't sort out their thoughts before hand, chances are you are going to have that meeting at least twice, or more. The first meeting becomes the prep. The first rule of meetings is that they are expensive. The second rule of meetings is to kill meetings.
Read more: Managing Oneself
Two concepts are becoming more and more important, in my view, to the success of organizations. These two are synthesis, and "both, and" thinking. Academically, these are ideas popularized by Hegel, and Kierkegaard, while the latter also has a long history in Eastern philosophical traditions (e.g. yin and yang).
Without synthesis we get stuck, we stop progressing when we come into contact with new ideas. Both, and thinking starts reframing entire problem vectors and gives us a vision for a way through. I'll never forget the best manager I worked for challenging me with Both, And thinking.
This past week I listened to a new podcast on Staff Eng by Mason Jones. And I had an opportunity to read an older piece from Chelsea Troy on a few management ideas. There is a specific point where they intersect that I find instructive to the concept of synthesis, and "both, and" and want to explore here.
I really appreciated Chelsea's piece because it lays out a re-imagination of what front line management could look like, without pulling any punches about the realities of the job. I don't want to steal her thunder, but at its core is claims: "As a manager you have to manage problems up, not just manage them down".
At some point in the management chain, people are not interested in the problems that the front line folks have, the folks doing the critical jobs that make the hierarchical machine function. For those folks, the "lower in the chain" (e.g. their immediate manager vs at the executive level) that interest is lost, the worse it is for them. At some point, management has to advocate for them. Without that constant force in an organization the morale of front-line workers wanes, and they eventually leave, taking their knowledge about the org with them. This is a reality I have witnessed time and time again.
After all, these are knowledge worker jobs where experience and creativity are necessary elements for a good job. I know when I feel an employer does not value those in me, I start polishing a resume. Definitely read Chelsea's piece for how she imagines we structure front line management, I heartily endorse it.
Mason's experience at Credit Karma gave me another block in the puzzle—how do you elevate that feedback past line management? How do you ensure that it moves up the chain of hierarchical management further? He shared that Credit Karma absolutely has OKRs that come down from management. But those are only a percentage of the quarterly OKRs that are commitments. The rest come from the teams themselves. The share of commitments that come from the top versus the team can, and should, ebb and flow due to where teams finds themselves, and where executives see the company in the broader landscape. This structure demonstrates that management is committed to advocate for the perspective of the folks who are doing the front line work, daily. And that the commitment extends to the executive level.
These are the kind of synthesis, the kind of both, and thinking that we're going to need to ensure consistent working relationships that, not only can last, but are fruitful! Managers have to advocate for both their company, and the people they manage. If the organization refused to accept that managers have to advocate for their people, well, go read Chelsea's piece on that. Organizations have to act in good faith with their line workers and synthesize those folks ideas and experiences with what middle management and executives are looking to do. Without that synthesis everyone will get deadlocked, unable to progress on the critical issues the organization is facing.
Management will not have to question whether or not their critical people are engaged. They can demonstrate engagement based on the OKRs they receive from teams themselves. Are they ambitious? Are they tired? You will have some evidence to combine with your gut feelings. How does this compare to last quarter? Last year? Management doesn't have to be based on only emotional reactions, or only (at times, contrived) measurements, but rather on a partnership-level with those doing the front line work.
Engineers, not to mention other departments, customer support and QA, are not left wondering whether their perspectives are being heard by their immediate managers. And they don't have to guess how much those managers have to fight for those perspectives to be heard. There is a clear and agreed upon process to roll those concerns up for these teams to define their own work, their own future.
If you are a manager, director, or executive, and you don't think your employees leave in order to get a chance to define their own work, you should take some skip level meetings, build some trust, and get their perspectives. After all, "People don't leave their companies, they leave their managers."
Read more: Up, Down. Both, And.