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:

  1. Migrate existing users off the existing solution
  2. 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.

Seven Levels of Authority

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.

KCDC Conference 2021 – 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.

That Conference – Build Things People Want

This week I am presenting at That Conference on Feedback Loops and building things people want. Wanted to roll up a few resources and point out some more topics for people interested in this topic.

Slides


Blogs on this Topic

ICP Explainer pt 2: Build Their Dreams

One of my favorite product tools, especially when talking to non-product folks, is the Ideal Customer Profile.  That is because it finds that perfect overlap between the deep history of targeted marketing and easy to understand explain metaphors.  Too often when I am talking to business leaders, senior engineers, or customer support staff the theory…

ICP explainer: Segment the World!

One day, a few years ago, I was chatting with an enterprise architect about some of the prioritization and focus issues the team was facing.  I told him “our real problem is that we don’t know our ICP”.  To which he paused for a long beat and said “Insane Clown Posse?”. Fair enough.  I grew…

It Depends

Early in my career, I moved into a new company as the only product leader for the engineering, network, and desktop support teams.  I went from having 2 direct reports to (eventually as I rebuilt the team) 21 and department head responsibilities.  Knowing I was going into a leadership position with a team that had…

KCDC 2022 – Build Things People Want

Super excited to be presenting at KCDC about building things people want. This is one of my favorite topics and it provides a lot of opportunity to dig deeper into topics. Slides Blogs on This Topic Videos on This Topic

Customer Intimacy and Segmentation

The biggest mistake young companies make is trying to sell everything to everyone.  It is impossible to get a clear value proposition or distinct competitive advantage without a targeted market segment.  The biggest mistake older companies make is not realizing when the market has changed and that segment is consolidating, shrinking, or shifting.  Both of…

Formulating Problem Statements

This morning, my children were arguing over spoons.  At breakfast it is my 5-year-old Finley’s job to get out the silverware for herself and her sister.  My Thalia, in the meantime, is just about to turn 3 and is fully feeling her control issues.  Every morning they use these particular baby spoons to eat their…

Finding the First Thin Cut

My goal in any product development effort is to get an iteration in front of users as quickly as possible so I can see real users interact with it and respond to their emerging needs. The quicker I can build that first MVP, the sooner the feedback loop of engaging with users can take over.…


Videos on This Topic

Formulating Problem Statements
Hypothesis Testing

More Videos on my Presentations Page

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 like.  But I do know that it will be different and leaders who just try to rest to how things were a year ago are going to be in shock as their employees chose to move to more flexible companies.  So, what do we need to think about as we balance collaboration with employee desire?

Remote work is a benefit, revoking it will have consequences.

While most companies didn’t move into remote work a year plus ago because they were trying to add an employee benefit, that is, in fact, what they did.  Now that employees have gotten an opportunity to work remotely, and for the most part successfully, many will view any change to the remote work policy as the removal of a benefit.  In a lot of workplaces, the right to work remotely was previously reserved for special situations where an employee may want to move across country and the employer desperately wanted to retain that employee.  Now you have the same situation but in reverse.  Employees that choice to make a blanket policy that requires all employees to return to the office, even if only a few days a week, will see turn over.  The presentation of how this return to the office is conducted, and how much agency the employees have in their return, will also affect retention.  As part of your plan, consider retention goals along side other goals like productivity, collaboration, and team unity.  Figure out what you want to measure and what your most important goals are.  For some employees, the ability for managers to be able to work with their staff in person may be a worthwhile tradeoff for significant turn over.  However, just as furloughs, pay reductions, or other benefit reductions will result in employee exits, the same will happen here.  Also remember that the employees that leave first are most often the most talented as they can most easily find other work.

Employee opinions matter

Along that same line, asking employees what they want should be part of your policy strategy.  Rolling out a new return to work policy without conducting a visible employee feedback process will result in lash back, no matter if the employees agree with the ultimate policy or not.  Especially coming at the end of a year where everyone has lost a sense of control in their own life, most people will not take kindly to being told what they will do instead of being consulted in their own destiny.

Also consider that each employee has different goals, work/life balance needs, and work styles that will contribute to their optimal workplace environment.  There is no one size fits all approach.  Policies that declare a certain job family or group of people based on location of their homes will be required to work in the office while giving blanket approval to continue remote work for another group will be seen as unfair or ill considered.  Yes, it is much easier to make policies that apply across the board.  However, leaving room for manager discretion, especially for high performing individuals, is essential.  This isn’t just a matter of retention; it is also a matter of inclusion and diversity.  Different people work, process information, have interactions in different ways.  There differences between people is part of what allows serendipity to happen, not just being in the same place at the same time.  Honor those differences by honoring individual needs.

Identify tradeoffs based on work style and actively mitigate

There are pros and cons to each interaction style.  Fully remote individuals need to work hard to collaborate and consciously build relationships that may naturally develop by bumping into someone at the watercooler.  In office individuals can find it harder to concentrate or to find quiet to work in and be easily distracted by the talk around the watercooler.  Everyone needs to find ways to balance between time at work and time at home regardless of if they are physically in the office or not.  It is overly simplistic to say that people in the office have better connections to their coworkers or people who work remotely focus better.  Everything takes work and it is up to both the individuals and the organization to help employees perform their best regardless of where they work.  Collaboration tools and video helps remote employees feel more engaged.  Sound buffeting and focused spaces help in office employees feel like they can get “heads down time”.

In addition, hiring a remote workforce allows you access to a larger pool of candidates, no matter where your office may be located.

Remote friendly is now the standard

Regardless of your return to the office plan, more likely than not you will now have employees who will remain full time remote.  There was a general trend towards remote friendliness before Covid and now, as with all things in the last year, that trend has accelerated.  This means that a remote friendly office is no longer an option.  You must put cameras in your conference rooms, include collaboration tools in your budget, and be prepared to help manager navigate productivity discussions with employees they can’t see typing on their computers.  However, remote friendliness is more than just how you make sure your remote team members can be part of conversations.  It is also making sure all employees, regardless of where they work, feel like they are part of the team.  Time has to be taken to think about these things.

A Day in the Life

I was recently discussing with a colleague the two distinct parts of my job: Engineering Team Manager and Software Product Director. In one half I am responsible for the cohesion of the team, supporting and growing team members, and employee exits. In the other half I am responsible for the cohesion of the product vision, support and growing the product features, and retaining clients.

I see a lot of overlap in the work I do in each half but often these two sets of responsibilities don’t come together in a single position. My colleague suggested that I outline a day in the life in this kind of position and see if it resonates with anyone else. And so this is my attempt to do just that.

8:00 Get situated

Review any emails or Slack messages from yesterday that need responded to. Make a list of to dos or promises in progress. Prep anything needed for meetings for the day

8:30 One-on-one

Talk with a team member about their current work assignment and where they are struggling with some technical skills. We set up a mentorship plan with one of the more senior members of the team. Then we transition to talking about their long term growth plans and check to make sure the current work assignment matches with their development goals.

9:00 Standups

Three teams, three standups, three completely different conversations and engagement styles. One team jokes about upcoming lunch plans and then quickly walks through the board top to bottom. One team stops at the first story and get going on a technical debate on approach before I ask if we can take that to our planning. One team goes member by member and seems a little disengaged. I make a note to circle back on the last time to see what team building we can do.

10:00 Design Meeting in Planning

After setting it aside in standup, the team wants to immediately get into a debate on approach in planning. We pull out the digital white board and I start drawing out what I am hearing them say as the debate continues. Soon everyone on the team is drawing out ideas as well and we are settling into a rhythm of collaborative problem solving. I quickly review the market goals of the product we are developing and remind the team where it fits into our overall architectural goals as the discussion goes off into a debate that is not necessary for the immediate problem. Once we all agree on the approach, we turn it into stories and get into planning for the week.

11:30 Lunch

12:00 Re-situate

Look through any emails and Slack messages that came during planning to make sure that nothing needs my immediate attention. Add things that can wait to my to do list, respond to things that can be dealt with immediately. Fortunately, not very much needs urgent attention so I look down my list and calendar to find the next most valuable work.

12:30 Roadmap Presentation Prep

Given the relative quiet of the day, I find some focus time to work on the roadmap presentation I am recording later this week for clients. Put together screenshots of recently released features and outline how I want to describe what is coming next in our products. Review the project plans on the current products against our actual sprint work to ensure I will not be making promises we can’t deliver on. Send an update to the Exec sponsor of one of the products to tell them we are releasing a feature soon they will be especially interested in.

2:00 Open Office Hours

Open my Slack channel for Ask an Engineer and wait for a client facing support staff to ask a question. I quickly end up explaining how the object relationships of some data are impacted the way the information is showing up on the page to one person. Then I get into a discussion of our roll out of a new feature to clients with another.

3:00 Respond to Client Issue

Out of Open Office Hours I have one take away to work through a client issue with the development team. A client has expressed concern with how one of the products is working. I work through the client concern with the team and draft a message back to the client explaining our solution to the concern.

3:30 Huddle on a Proposal

The Sales Director has a prospect with a unique use case for one of our products we wants to talk through with me. We review the prospects needs and the different ways we can use our product to solve it. We come up with a good solution that won’t require any custom development and should work for their budget. I message a member of the client support team I worked with during open office hours to see if we can use one of their clients as an example.

4:00 Review Market Research

With the goal of finishing a draft of my client roadmap presentation, I review the market research for one of the products I want to talk about to ensure the development plan we have in place is supported by our understanding of the market needs. I listen through a problem interview I had recently with a client on that topic and pull out some phases they use for the notes on my slides.

5:00 Close out the Day

I take a moment after saving my presentation to look through my promises in progress list and check off what got done. Then make a note for the next day to think about ways to increase engagement in standups for team three. Close my book, and leave.