Slides
Category: Uncategorized
KCDC 2023 – Estimates are Evil
Slides
CodeMash Conference 2023 – Consuming Endangered Pachyderms
Slides
Blogs on related topics
Mental Model Minute: Seven Levels of Authority
We are all growing and learning as professionals in a collaborative workspace. It can be helpful to take a step back and look at different models of individual and team behavior. A “mental model minute” takes just a moment to describe a different view on how to perform or interact better that we can react…
The Next Right Thing
You’ve seen Frozen 2, right? I mean, if your household is anything like mine, it’s playing on repeat in the background as children scramble, color, and fight. Admittedly, I have only sat and watched it end to end once. Still, there is one part of the movie that stick out to me and, I think,…
Build Things People Want
When I started at my current company, the mandate I was given by the developers was to help them build things people want. It is something I have heard over and over again from developers throughout my career. And frankly, it’s a goal that the organization and the developers should be aligned on. The business…
Also check out other presentations.
CodeMash Conference 2023 – GDPRs, and PCI-DSSs, and HIPAAs, oh my
CodeMash Conference 2023 – The Interview Lab
Slides
Blogs on related topics
Processes for Establishing Teams
Often when I am coming into a new team much of the work I am doing, while I get up to speed on the product and market, is helping the team focus and work together. Over the years I have come across, modified, and developed several tools to help facilitate establishing teams, norms, and roles. As…
Mental Model Minute: Intent Based Leadership
I have so many things to share with you but so many discussions I have been having keep leading me back to this Mental Model Moment I thought I would share. And it’s easy, because it’s the author and this great illustrator do so much of the work for me. On the other side I…
Remote Work is Here to Stay
As operations leaders across the world stumble and struggle to figure out their “return to work” strategies, I have been reflecting on the nature of the fundamentally collaborative work we do in software development and what it will look like in this new world. I don’t know what the post-Covid world of work will look…
Also check out other presentations.
Processes for Establishing Teams
Often when I am coming into a new team much of the work I am doing, while I get up to speed on the product and market, is helping the team focus and work together. Over the years I have come across, modified, and developed several tools to help facilitate establishing teams, norms, and roles. As always, no tool is exactly right for all teams. Adapt and change for the nature of the team you are dealing with.
Norms
Goal
Establish a common set of team level rules for how we collaborate and interact. This can be everything from SLAs around PRs to the number of meetings we have, from how we handle conflict to support rotations.
This process should be team led. The team leader should be a participant in the discussion. As such it can be very difficult for the team leader to also facilitate the discussion. A team norms discussion also becomes a way the team actively works through their communication and conflict management style. If possible, it is better to do this synchronously. The conversation is part of the point. Approximately an hour should suffice for this discussion. Some teams can do multiple exercises (norms + mandate or norms + decision making) in one session. Once norms are established, they should be updated over time.
Process
Let the team know you will be doing an exercise so they can think about it in advance. The prompt is “Think about a team you worked on that was great. What made it great? Think about a team you worked on that was terrible. What made it terrible?” Capture one thought per sticky.
Then group stickies together into themes. Talk through the stickies in each theme together as a group. As a facilitator make sure that people are engaging in debate on whether that idea is important to them as a team or not. This will allow you to come to a set of statements that basically boil down to “We believe…”
Examples
From a very mature team with a lot of baggage, this set of norms evolved over the 2 years the team existed. This example is only a subset of the total norms the team had. They did a remarkable job of holding each other accountable by simply saying “thank you for following our team norms”.
At a very different company, a very different result. This was a team coming out of a lot of process whiplash. Also, they were globally distributed (designer in India, team lead in South Africa) so there was a lot of concern for async communication and clear hand offs.
Roles and Responsibilities
Goal
Clearly define who owns what part of a process or has decision making power is essential to clean hand offs and action. While many activities fall clearly into one job title (HR is a great example of a job with clear boundaries) in the space between Product and Engineer, or between levels in an organization, things can be a lot murkier.
This process can either be leader with team or leaders among themselves depending on where you are seeing grey areas. It is best that anyone who’s position is being defined is part of the process. This process requires a willingness to engage in some difficult discussions about both skills and responsibilities and can become heated so it’s best to have someone with position power that can break an impasse.
This process should be done in conjunction with establishing a DACI process or establishing a 7 levels of authority so you can clearly talk about both the “owner” of a process and who should be involved in the decision and how involved.
Process
This is a classic card sort exercise focused on job responsibilities. This should happen in two phases.
Phase 1: Collect responsibilities
Bring the affected group together to collect all the responsibilities that need to be defined and owned. Working alone capture one responsibility per sticky. This can be as simple as “review a PR”, as mundane as “schedule meetings”, or as complex as “architectural direction”. Set a timer for the independent brainstorming. At the end of that time, go through all the items and group them and chose a “winning” card to represent each group of ideas. Take these cards to a new clean area.
Phase 2: Card sort
Have boxes for each of the roles you are trying to define. Together as a team determine which box each sticky belongs in. If the sticky belongs in multiple boxes, duplicate it. If a sticky represents a “decision owner”
Example
Most of this kind of discussion I have done has been in person, so I don’t have a captured shot. This is a heavily cleaned up example from our process of hiring a Head of Eng and establishing teams with a “pod captain” for each.
Decision making structure
Goal
Sometimes it is helpful to separate the Roles and Responsibilities discussion from the decision-making structure. This can especially be true when there are a lot of people involved in decision making and it can be separate from the actual job responsibilities. This has been the case for my current role as we have moved from a single Engineer team of 25 to 5 pods with pod captains.
Process
Same as ‘roles and responsibilities’ card sort with the initial part focused on decision making stages. In our process we also added in the variable of where and how the decision should be made and SLA because of how async we are.
Example
I am a Unicorn (and other insights from community building)
This is not (necessarily) work related.
This is my daughter, Finley. Yesterday at school she learned how to sign “I am a unicorn” (gif link). I consider this an important life skill.
She regularly comes home and tells me about the various new signs she has learned like “exuberant” (one of her favorites). Finley does not have any hearing or speech impairments. Her Kindergarten teacher is using American Sign Language (ASL) and Spanish as tools for teaching reading and writing. She has a friend Felicity (the daughter a dear friend) who lost her hearing and recently got a cochlear implant. While the other kids teased Felicity, Finley showed curiosity and compassion. She has told us that when she grows up, she wants to be “a voter” and wants to live with “deaf people because they can teach me so much”. I am indescribably proud of her. But this doesn’t happen by accident.
My uncle Ron taught me ASL for the alphabet, numbers to 10, relationships (mother, father, etc), basic courtesy, and some animals that would interest a 9-year-old. It was survival level ASL and a gift that he gave to as many of his nephews and nieces. It was also a glimpse into a world that most people don’t know exists. Ron was born blind and deaf because of a congenital condition that also impacted my sister to an extreme degree. He would teach ASL by moving your hands into the correct shapes. I learned the nuanced differences between F and 9 that a sighted practitioner of ASL wouldn’t care about (even within the deaf community, there are subcommunities). He also taught braille at the Iowa School for the Blind and was a professional computer programmer. I also learned recently that he was a well-respected advocate for disability rights (Ron referred to himself as disabled. He hated the recent trend towards “differently abled” because, in his words, “being blind isn’t an ability”). He built communities everywhere he went in his life. Through him I learned about nuanced parts of the deaf community that a hearing person would never interact with.
I have always talked to my children about my uncle and my sister and the things they experienced. I can see in the three generations how much the world has changed. Ron struggled and fought for understanding and support for his whole life. I was ambidextrous leaning towards left-handed as a kid, the teachers wouldn’t let me write with my left hand. Finely is learning ASL in Kindergarten and her teacher protect and encourage her left-handedness. The world has evolved. Slowly and in ways sometimes too small to see. But at least now my child knows how to say “I am a unicorn” in multiple languages.
This part is work related.
I think my new hero is Frances Haugen (who also is an Iowan, btw). What she has done, the bravery it displays, is breathtaking. She talks about the possibility for social media that brings out the best in humanity. Recently, every time I have written a document I have thought “how would I feel if someone like Frances was looking at this?” This has been especially true as I have been trying to get clarity around our data capture and tracking policy. Because I want what we do here to be for the general good. Because I believe that there is a need for people to build communities. And that should happen in a way that isn’t creepy and isn’t just trying to manipulate people. I am equally motivated in my work by a consciousness of how understanding different cultures and life experiences makes us less cruel and more compassionate towards each other. And by my 6-year-old who is being exposed to those differences in a way that makes her curious instead of afraid. How different her world is, already, from the one my uncle was born into.
Mental Model Minute: A Decision Making Model
Collaboration is good. Making decisions is good. These two things don’t have to be in conflict. I have seen a lot of small but growing companies where this feels like an either/or choice but it doesn’t have to be. The key is knowing who makes the decision and how much input is required. The more explicit we can be about who makes a decision, the better we are going to be at actually making the decisions.
To that end, I have started using a really lightweight framework for this and wanted to share that here. I am going to get more diligent about this personally. In meetings, documents, and other decision making spaces I am going to put out this little block. Example from a recent meeting:
EPIC: Better Sidebar/Links Organization
RFC(s): None currently
Priority: Very High (1c)
Meeting type: Discovery
Description: Allow Creator to have better control over the left bar with some options including:
- More granular organizational structure / more sections than just “other”
- Specify the open on site vs open in new tab options
- Dominance of iconography / style
Stakeholder Roles:
Decision Owner: Jennie for this meeting, PM moving forward
Consult/Advise: CEO, Designer, Engineering team
Inform: Client
During the meeting, I will verbally note the things we are trying to decide and, if appropriate, what the decision was. After the meeting, I will document the decisions made at the meeting and any logic for that decision. This is especially important in our async environment. The idea here, though, is to make decisions quickly without a lot of process and clearly. I am sure we will iterate on this over time.
Mental Model Minute: Intent Based Leadership
I have so many things to share with you but so many discussions I have been having keep leading me back to this Mental Model Moment I thought I would share. And it’s easy, because it’s the author and this great illustrator do so much of the work for me. On the other side I can share my take aways and how I have implemented this with teams before.
Start with Clarity
Intent based leadership is all about setting the distant island we are trying to reach via the ship, and then collaborating as a team for the best way to get there. Teams are formed with different skill sets and the ability to have hard conversations around both priorities and implementation.
I had one team that was building a Form Builder. This was a priority for the company because of some compliance issues with our existing solution (PCI security) and a potential untapped market. So for that team we had two clear goals:
- Migrate existing users off the existing solution
- Prepare a product for go to market
Every meeting we had, every planning, every time we discussed a feature, we asked if it met those two goals. To the point that my otherwise quiet UI/UX developer (the Sheriff) would interrupt me outlining a feature to say, “This doesn’t seem in line with our goals, why are we doing it?”
In other words, the team started to understand “Is it the right thing to do”.
Build Structures around Competence
Over time the “is it safe” questions become engrained in the conversation. Each time I work with a team on whether we would release something I would ask the same questions. To the point were one of my developers started to impersonate me. “Will it break production? Have we informed the users? Do we have documentation?” Questions like that. This, as well, becomes a pattern of how the team acts.
At my last gig, we had a system that was forklifted from a mainframe with no test environment. As a result, questions of release, between my delivery lead and myself, were always about how much certainty can we have that none of us will be working the weekend. Followed directly by questions of where are the opportunities to create unit tests, or small test environments around sections of the application even if end-to-end tests can’t be done.
Moral and Ethical Responsibility
As a leader, there will always be some tasks you must reserve for yourself because it is irresponsible to allow that to be a team decision. The key here is to be explicit (using those 7 levels of delegation perhaps) on when that is happening.
When I was a department head I reserved two things:
1) Starting the firing process with HR
2) Telling a customer “no”
Neither of those things where my team should have carried that burden. I explicitly told them this. My tech leads would reserve some very specific breaking technical changes. For example, only the tech lead of my dev/ops team could take our CI/CD system completely offline.
Mental Model Minute: Seven Levels of Authority
We are all growing and learning as professionals in a collaborative workspace. It can be helpful to take a step back and look at different models of individual and team behavior. A “mental model minute” takes just a moment to describe a different view on how to perform or interact better that we can react to and learn from. I will post these from time to time. If you know of mental models that have helped you, post!
One of the hardest things to navigate in a collaborative workplace is whose decision something is. This is where the “Seven Levels of Authority” from Management 3.0 by Jugen Appelo model comes in handy. His model is about authority definitions between a manager and their team. I have found it useful between individuals or across teams as long as you clearly define who is playing each role.
The Model
Too often in decision making we think it’s “your decision” or “my decision”. However, actual decision-making authority is way more nuanced than that.
At one end of the model, the decision is 100% “mine”. E.g. as the manager, I am telling you what we are doing. I have most often seen this level arise (in healthy organizations) in situations where information is highly protected such as a firing decision or where risk is high such as PCI compliance.
On the other end, the decision is 100% “yours”. E.g. as the team, the manager has delegated the decision and has no need to be further involved. I have most often seen this in implementation details or technical details from a non-technical manager/product owner.
In the middle of the model is “Agree”. In other words, the decision is made jointly between the parties. The biggest risk with “agree” decisions is they don’t ever actually get made. To mitigate that it is helpful to put an artificial process like dot voting or a timebox in place.
Most decisions fall on one side of this or the other.
With “Sell” and “Inquire” the decision is made by one party but the other party wants to be informed after the fact. With “Consult” and “Advise” the decision is made by party with the other party giving input before the decision is made. In all these cases, a party has the clear decision-making authority. For example, in “Consult” the decision is made by manager with input from the team beforehand. An example of this may be hiring decisions. With “Advise” decision it is often important for the manager role to publicly support the decision after the fact for the team to feel like they are actually allowed to make the decision until norms are established.
How to Use it
The other night, my husband’s phone died. He went out and bought a new one. I asked him how much he spent on it, and he deflected the question. I got angry at him and he was upset with me. Why? We had talked about how a phone is critical for both his home and work life. Whereas I can run with something barely functioning for a surprisingly long time, he spends 80% of his work time on the phone. His phone had ceased to function as a phone. We had talked about how it was urgent he get the phone replaced. We even agreed I would single parent bedtime so he could get to the store before it closed. So why was I upset? Because it was not a simple “his decision”. In this case, think of me as the manager (yay marriage). He thought this was a level 7. I had fully delegated the decision to him. I thought it was a 5 or 6. I wanted to hear about the decision after the fact and the details. In a 20-year relationship, we can be dialed into the difference between a 6 and a 7. In most work situations that level of detail isn’t necessary. But knowing where that difference in expectation arises allows you to adjust for the next time.
In my last gig, I had a business partner who was going to use the app my team was developing. We would have discussions about the requirements of how the application would make her life better. At various points when trying to decide how something was going to work, I would be very up front with her about who got to make that decision. “That is a technical implementation decision. So I can go talk to the team about options, but we may be limited here” when we were more at the 5/6 area. When we are more at a 2/3 I would say “We can make that happen for you. Here are the trade offs but it is ultimately your decision as the user.” It helped give her clarity on where we were in the project and what the outcomes would be.
I have a friend who uses this technique at work. When she is describing a course of action she is planning on going down, she will end it with “but my boss can always tell me I have other priorities or to do it differently”. Her boss is always in the room in these situations.
Jennie Ocken 
