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.
Our work experience is an experience of iteration. Loops. We show up day after day. Week after week. Year after year. The goal should be for each of those loops to be building on one another. But, this is not the only kind of loop. The loop that interests me is the OODA loop. Initially articulated by John Boyd for the Air Force, it can now be found throughout the business and management world.
People have written books and courses about the OODA loop, but if I were to distill what completing a loop in the software development process looks like it would be: the time between realizing a feature gap exists and deploying a solution and having customers using it. The internals of the loop itself is important, no doubt. But what Boyd was really telling us is—in a competitive environment, whoever can complete their loop and start another before their opponent, has the best chance of victory.
The speed at which you complete loops is everything. This is the root of so many other pieces of advice (e.g. "Best is the enemy of good.", "Define an MVP") and warnings ("Scope creep is bad", "Don't optimize prematurely"), as well as the baseline of so many agile practices that prioritize working code and de-prioritize long term planning.
Now, how do you make that loop fast? Again, there are tons and tons of focus on the technical aspects; GitFlow vs Trunk-based dev, test coverage, continuous integration, continuous delivery vs release trains, etc. But, there is one point that I would love to see more focus on: making decisions.
Irreversible decisions should be made with great care and consulting many sources. However, very few decisions are irreversible. All other decisions should be made as quickly as possible.
You should arm your teams with values that actually help them make decisions during their day-to-day. Many values look great on the wall, but how many help you choose Path A vs Path B?
You should arm your teams beforehand with a rubric or matrix that tells them: "When you are forced to choose between X and Y, choose X." The shape of many decisions are known ahead of time—enable your team to know they are making the right ones (without you) by outlining the scenario to them.
This is one of the best ways to ensure that you are managing with Context and not with Control. When you are making decisions be sure to share the context of why and how you came to this conclusion. Make a note of how much information you have that your team does not. Create a process of communication to give them this information. If your team is making decisions that surprise you and that you disagree you should consider that a failure of leadership. They are missing context you have, or you have not gotten your team(s) to value what you value.
This is the responsibility leadership takes on to create quick OODA loops for your organization.
[Image credit goes to Pavel Samsonov of Amplitude from Twitter]
Read more: Loops, Loops, and More Loops