Kelley Marsh

I make things better. I amuse myself in the meantime.

how are you?

Rand nails 1 on 1s. Just go read it.

Your people are your greatest strength, your greatest asset, the most precious thing. They’re constantly looking at your actions and lack of action, your voice or lack of voice, a thousand tiny signals you give to the people you manage that let them know how you value them as humans and as necessary and valued contributors to the team.

1 on 1s are your dedicated opportunity to listen, to elicit, to dig around and learn about these wonderful complex complicated delightful people. It’s not a status report. It’s an investment in your relationship with this person and in the success of your team.

A 1:1 is your chance to perform weekly preventive maintenance while also understanding the health of your team. A 1:1 is a place to listen for what they aren’t saying.
The sound that surrounds successful regimen of 1:1s is silence. All of the listening, questioning, and discussion that happens during a 1:1 is managerial preventative maintenance. … Your reward for a culture of healthy 1:1s is a distinct lack of drama.
The Update, The Vent, and The Disaster

August 22, 2022
the balance of leadership

There’s a great post on the Reforge blog about people manager responsibilities that lays out the balance of being a manager quite nicely. It’s a balance I’ve always tried to achieve but never really put into words.

I love teams. I love working in a team, I love creating teams, leading teams, helping craft a high performance highly empowered groups of people that get shit done and have a lot of fun along the way. But to be an effective team lead, you really have to be cognizant and purposeful with how you balance your responsibilities.

In the article on Reforge, they lay out three major areas of responsibility: coaching, directing, and evaluating.

So often, I have had managers that really suck at coaching. The focus is primarily on directing with the company mandated semi-annual nod to evaluation via some intricate process with obscure scales of evaluation that are applied without direct correlation to specific behaviors or events.

Being constantly directed is tedious. It disempowers me, it creates a forced reliance on my manager to provide direction, it takes any ambition you might have had to advance your skills and career and just grinds it into dust.

Frankly, I’ve never had a manager that was also a good coach. Maybe that’s why I try so hard to make sure I’m shaping and leading the team with lots of coaching, clear goals and lines of responsibility, with small and frequent feedback cycles.

August 16, 2022
a thousand times – this.

via rawsignalgroup:

…what we know about high-performing teams is that none of this management-by-abuse shit actually works. We can have empathy for the bosses who are sitting in the discomfort, reaching for anything to make themselves feel better. We can understand that impulse. We have felt that impulse. But the reality is that, when you act on it, you take an already-stressed operating environment and add fear, politics, and churn. Like gulping down seawater, that totally understandable impulse will make things much worse.
What does work? What would an actual ruthless focus on results look like? Psychologically safe teams outperform. Even in a down economy. Treating your people with decency, clarity, and dignity is not just for the good times. In fact, the harder things get, the more you’re gonna to want an engaged, high-trust team to count on.
raw signal group

August 11, 2022
i’m looking at the man in the mirror…

I ran across this article in a Product Management group I frequent. A screenshot excerpt:

That last line is a major WTF moment. Half your time is spent on firefighting? That’s insane. I mean, sure, shit happens. But… if you’re spending half your time fighting fires, then something else is wrong, my friend.

August 4, 2022
riding off into the sunset

So we have this product – an MVP from 2 years ago that never got the love it needed. The little social platform that never was, but with a rich set of profile and content creation tools. And then we built another product on top of those content creation tools with a divergent experience for front-end users. And now we’re about to deploy a third product that also uses those content creation tools, but even less than the one before.

In only 2 years, the time has come. It’s time to sunset the social experience. We’ll maintain the content creation tools, of course. Once we’re free of the social experience, we can transform those tools to more closely facilitate these two new products.

What a hard decision tho. Not only was it the first thing I launched at this company, but I feel it never got a fair shake at life. Priorities changed, teams were redirected, and now here we are – killing it off. I am disappointed and – if I’m honest – a little sad.

Logically, it’s the right choice. Once you get beyond the sunk cost fallacy, once you add up the cost of maintaining the social experience, once you look at the dwindling use and lack of traction, once you understand exactly how confusing these divergent experiences are for our users – the choice is clear and certain. We’ve drafted a phased plan to “unship” a feature, evaluate impact, and then decide whether to continue or not.

First feature redirects get shipped at the end of this sprint. While we’re not expecting any huge user backlash, I know that I, for one, will be sad to watch it all fade into the sunset.

August 1, 2022
communication paths restrict the solution devised

Couple items that stood out to me today from Team Topologies, chapter 2:

Communication paths (along formal reporting lines or not) within an organization effectively restrict the kinds of solutions that the organization can devise.

This was an interesting chapter. When I think about lines of communication between engineering teams that I work with currently, you can see Conway’s law played out brilliantly. Inter-team comms are strong, our two coupled team comms are moderate, and we barely talk to anyone else. Our architecture is unique in the org and limited to only our use.

The same holds true for our product lines. I am strongly coupled with another product manager and we work on the same product. We have limited capacity to tackle problems that lay outside the immediate area of control of our engineering teams – every product/engineer team coupling is fairly siloed, building their own architecture, and prioritizing what they can build within their silo instead of thinking across the organization to solve problems.

How do we combat that, at least at the product level? If lines of communication reflect the solutions built, perhaps that’s a good place to start.

July 21, 2022
conway’s law for product teams

I picked up Team Topologies the other day and am reading it with the product team mindset – trying to parse some of the example applications of Conway’s law for engineering teams to product teams.

Conway’s law, as a refresher:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure
Melvin Conway

You ship your org chart. And it makes sense – what you build will align with the team’s area of responsibility, ownership, and lines of communication.

But is the same true for product teams? In my current org, the “team” is a collection of individuals that are shared across several products with the exception of the product manager. The person responsible for marketing my product has obligations across several products and reports up to a marketing org. Same for data, user research, operations… We’re not even adjacent on the org chart in some instances. So does what we ship from a product perspective follow Conway’s law?

I’m not sure yet. But I’m intrigued by the question.

July 20, 2022
a collection of thoughts on one pagers
Great One Pagers, John Cutler on Medium.

According to medium, this is a 14 minute read on how to produce a document that can be read in 3-6 minutes. Despite the extensive questions to be answered, he recommends conciseness, leaning toward brevity. In particular, I enjoy the behavioral change framework, the clear distinction between a one pager and a solution description, and titling your one pager to address outcomes, not features.

What is a one pager, Molly Sloan on Drift.

I like the audience definition – this is the opportunity to share context and research of user problems to your team. She notes that also, stakeholders may read these. A definition of six sections is provided and a discussion of how you know your one pager is good: how easy it is to write given the material you’re drawing from is voluminous and consistent. It’s clear that this document does not actually describe a solution. It provides context and builds empathy with a customer problem.

How to write a one pager people will actually read, Product Plan

Repeats concepts of brevity, context, research and storytelling.

How to write a one pager that people will actually read, Product Coalition (premium content on Medium from Mal Sanders)

Repeats that this is primarily a document for the product team that is also read by higher level stakeholders at times. He says: “It is a communication tool that serves the team, not a rigid template that needs to be the same each time.”

Which is to say:

one pagers describe customer problems and desired outcomes, not features
they are generally succinct and aim to provide context and empathy for the customer problem
one pagers provide boundaries for the solution space but do not solve the problem
one pagers define success in specific and measurable terms
one pager templates are a starting point for people who need help answering the right questions, and not a rigid requirement
July 19, 2022
making something from nothing

Making something from nothing is hard – 0 to 1 product management is full of really hard choices and ruthless prioritization. You’ll question your definition of “necessary” and find ever smaller slices to carve off on your path to making A New Thing… particularly under the constraint of tight timelines.

Having done it twice, I’m not sure it gets easier but you do get better at it. It’s always asking – does this really really really need to be built before this product can exist? Before it can function? Is there another way to do this? Does this bit really matter? If you don’t build that piece – have you lost the delight and value and differentiation of what you’re attempting to build in the first place? It’s pouring over your choices from all angles of approach and leaning in to the ‘what if’ exercises.

It’s attempting to mitigate risk while embracing the unknown and making the best choices possible in high uncertainty environments.

You’ll never really know for sure until you get that thing out into the world. Hang on for the ride – it’s exhilarating and terrifying and rewarding and risky.

July 18, 2022
Kill your piles

I am a notorious stockpiler. I like to be prepared. Use the last of the toothpaste? Don’t worry. There’s 2 more in the closet. That’s not the last of the napkins, that’s just the last of the pile I have out on the table for convenient use. I get anxious when there’s less than 4 rolls of toilet paper in the house.

I justify these actions by telling myself it will all get used eventually – after all, I’m not saving old newspapers “just in case,” or refusing to throw out broken items. I’m no hoarder. It’s just a backlog of things I will certainly eventually use.

Or, more accurately, things I would certainly eventually use if I weren’t also constantly restocking the stockpile.

There’s a certain sense of comfort in having that backlog. I had a team member who would never finish his work, never clear out his backlog of tasks. I’d get so frustrated, feeling he was constantly behind, while he felt a sense of security by always working just enough to get his backlog pile to roughly the same size by the end of every day.

Ultimately, a pile is waste – it adds no value. If I constantly have 2 tubes of toothpaste in the closet, one of those will never be used. If I have 20 tasks stuck in testing, then I’m wasting developer time on new tasks because nothing is going out to the client. There is no value in continued development because there is no end product for the client. Wherever you have a pile, wherever you have waiting, you have waste.

The only thing a client can value is something they receive. You’re not adding any value or “getting ahead” by continuing to throw tasks on the testing pile if nothing is leaving the testing pile. How many tasks do you have waiting for “just one last thing” before you ship it off to the client? Why are you starting new things before shipping old things? You’re just making an enormous pile of old things waiting for completion while you get distracted with the shiny new things.

Where are you piles? Go kill your piles.

Except for the toilet paper stockpile. You’ll totally need all of that someday.

July 31, 2015
Scarcity and Abundance

There’s a theory in this book that, while too little of something may be a bad thing, too much of that thing may also be bad. That more is not always better. It’s only better to a point, and then the benefit may not only level off, it may actually decrease.

It’s a U shaped curve. Benefit rises as you climb out of scarcity, and then benefit decreases as you head into abundance.

An example might be class sizes. 50 kids in a classroom is too many – the teacher is spread too thin, you can’t pay attention to everyone, people get left out, chaos ensues. On the other hand 5 kids in a class is probably too few. There may not be enough difference of opinion to get any real discussion, there’s not enough diversity of thought.

Another example – income.

If you’re working multiple jobs to make ends meet, you simply can’t afford to give your kid anything they ask for. You likely end up teaching your child that they can put in hard work and earn the thing they want – they learn the value of effort and reward.

But at some point on that curve, the parent has plentiful income and can easily provide whatever thing is desired by their child. Here’s where things get difficult again. You have to say no because of your values, not because of a lack of resources. It’s easier to say no when you don’t have the ability. It’s harder to say no because of your principles.

It made me think about scarcity and abundance and my own values at work. When we have an abundance of time, do we still live our values?

If you don’t really have to complete a task until the end of the week, but you say you can get it done on Tuesday – do you really do it on Tuesday? Or do you let it slide because you can, given the abundance of time?

Do you tell a client ‘no’ for an early scope creep item that is small, when you still have an abundance of time and budget, based on the principle? Or do you agree, sidestep the difficult conversation, and allow it to slide?

Abundance allows us some generosity, but scarcity can forge your values. Are you living the same values when times are easy, as when they are hard?

May 5, 2015
Are you my leader?

If you asked me what I’m good at, I’d say administration. I’m not always the big idea person, but I know how to get big ideas done.

I’m reading this book about leadership, and I’m no where near as comfortable with that moniker. Am I a leader? I lead my team, surely. Why don’t I think of myself as a leader?

I keep coming back to these agile concepts of scrum, and the concept of myself as a scrum master. The facilitator of a self-organizing team. The scrum master isn’t really responsible for setting tasks. They don’t pick who does what. They just facilitate others, they define process and help the team implement those processes.

And then I think about a leader. Someone who sets the task, sets the standard, makes decisions, and is the source of team accountability.

Where do leadership and scrum mastery intersect?

It almost feels like socialism vs democracy. Old testament vs new.

There’s the concept of the ‘servant leader’ as scrum master, which covers this seeming dichotomy. In theory, everyone is accountable to the team, and the scrum master is responsible for maintaining process, but not the implementation methodology of that process. But in my reality, I have to chase after people for time sheets, I have to conduct reviews, and I’m accountable to leadership for standards that may or may not be different than the standards of the team.

I suppose this whole post is just thinking out loud. I am drawn to act in service to the team, and yet there are times I must lead. How do you draw the line? How do you set clear expectations? How do you keep that from sending confusing or mixed signals to the team? Where’s the middle ground – and is middle the right place to be?

Perhaps answers come with time and trial. Onward!

March 23, 2015
Believe the actions, not the words.

In many ways, I’m an idealist. An optimist. I want to believe the best in people. People are nice, respectful, and well-intentioned. Their words match their actions. There are not hidden agendas. In my world, high trust is the default mode of operation.

I maintain this perspective by never reading comments on anything online, clearly. I ask you to afford me my idealistic beliefs.

I’m proud of them, quite frankly. I believe in my team, in my clients. I want to believe and foster the best in people. I believe in clarity of intent, in honest, open discussion, and in the presentation of a true picture of where you stand and what you represent.

I don’t want to be jaded and cynical. I want to believe. And at the end of the day, I want others to believe in me. To see the congruence between what I say and what I do. I refuse to stop kicking when I’m put in a position where actions don’t match stated values. I will carry my little naive torch, and be an example of what I expect to see in others.

It’s not always easy to live your values. Perhaps I just needed to remind myself of that today. Being accountable is a beautiful thing.

March 18, 2015
There’s nothing stopping you.

It’s one thing to have an environment where an individual’s initiative is not discouraged. Where if your team member goes out on their own to implement a new idea, they are not punished.

It’s quite another to foster an environment where initiative is perceived as desired. To make a place where your team is cultivated, strengthened, encouraged, rewarded, to invest yourself deeply in the success of your team.

I think about team culture quite a bit, being on two teams myself – one as a leader, one as a team member. Having the benefit of both managing and simultaneously being managed, you get a different perspective on your own theories of leading a team. You see both sides of the coin, you live both sides of the coin.

This week, I spent a lot of time thinking about how to cultivate an environment where people are encouraged to solve their own problems, where they feel safe, but are consistently challenged to learn and grow and try new things. Where failure to succeed the first time results in encouragement, not punishment.

Without insincere superficial praise, without masking real problems with new distractions every week – how do you keep a team challenged and encouraged to go out and experiment a little?

How do you get a team beyond having to point out to them that no one is stoping them from trying that new idea, to a place where, when an idea occurs, the top of mind response is to feel encouraged to try it?

That’s a big swing. One environment is all about fear of risk, fear of punishment and failure. The other environment is embracing the possibility of failing, recognizing it as an opportunity to learn, and moving forward fearlessly.

Which are you creating with your actions? How do you react when someone on your team fails? What are you doing to foster and reward those that take initiative?

February 26, 2015
On Motivation

I have this little cube on my office desk. It’s a timer. You flip the cube over so that a number is on top, and then it beeps after that many minutes have elapsed.

This is useful in many ways.

Got a meeting in 15 minutes? Flip the timer to 10 min. You can ignore the clock and safely work on whatever you’re working on for 10 min. When it beeps, you have time to save your work, get a bio break, open your calendar, and get to the meeting on time.

Need to get up and stretch every hour? Flip the timer to remind you to stand up and walk around every so often.

My favorite use is sorta like the Pomodoro technique. When there’s something I’m dreading – answering a stubborn client email, writing ridiculous status reports, cleaning the house – I set the timer for 10 minutes and I just… start. How bad can 10 minutes be? Surely you can endure 10 minutes. Just start the stupid thing. You can quit in 10 minutes.

Usually, 10 minutes is enough to make decent headway into the task – as a project manager, I do a ton of smallish to medium tasks. Usually, 10 minutes is enough to prove to myself that this task wasn’t so bad after all. And usually, I’m done shortly thereafter.

The problem comes when you’ve already reached into your bag of tricks a dozen times, already pulled out the cube and every other tool you’ve got to get stuff done, and you still come up short in the motivation department. When you’ve exhausted your resources, and you don’t feel any better after your 10 minutes is up.

What then?

You put your head down and you slog through.

It reminds me of shoveling snow. (As if this post needed more tangentially related stories.)

In Rochester, you ain’t driving anywhere until the snow gets shoveled. And it’s no fun. And you’re tired of it after 10 minutes. But it’s got to be done if you want to eat something other than mayo, a jar with 2 pickles left, and snow for dinner.

And then the slog method fails. It’s not sustainable. You start to lose pieces of your soul, forcing yourself through the motions with no heart.

Something has to change.

Will it be you? Or your situation? Or both?

February 19, 2015
Paperweights and Change

I’m sitting at home, watching these big fat flakes of snow fall, waiting for a call. We’re currently a 1 car household, the other car having just transformed into the world’s largest paperweight in the parking lot of Wegmans. We’ll head back to meet the tow truck driver when he calls to say he’s on the way.

This morning, the forecast said to expect 5-8” of snow. Now it says only 3-5” of snow.

This morning, we had 2 functional cars.

Life is change. It’s an adventure that we can influence, but rarely ever truly control.

As I opened my laptop just now, my browser was open to a conversation in a Project Manager group on LinkedIn about dealing with unauthorized change. The responses are generally insisting that unauthorized changes don’t happen in a properly managed project. That clients present a Scope Change Request, or they go through the Change Control Board, whatever that is. Or to stop all work until the change is authorized, and to punish the offenders swiftly.

The stark contrast between the rampant idealism in this conversation and the reality of projects is stunning.

What a disservice to our peers, to our teams, to our management – to pretend that our influence in the realm of controlling all aspects of a project is complete. We’re not managers. We’re shepherds. We guide, we influence, we provide direction. We attempt to clear the path, to avoid obstacles. But we’re not really in control.

Change is coming.

So is the tow truck. We hope.

February 14, 2015
Failing at Full Screen February. Already.

5 minutes into my first meeting, and I’ve already failed at Full Screen February.

I was mostly on the meeting to report on any status questions asked, while the account managers negotiated a contract. And so I busily applied myself to organizing a different project for the week, while they discussed.

And then I realized what I was doing. And that it is already February. And that I had better pay attention before one of my team called me on my behavior!

The lure of the second monitor is strong. I managed to finally ignore it, but then I wanted to pick up my pen and start a todo list for the day. I kept picking up my pen and putting it back down.

So fidgety.

I sat down at 10pm last week – not tired enough to sleep, not wanting any screentime – and picked up a book. It’s a book I’ve read before, and enjoyed. It was so hard to get through even just a few pages. The author writes in a style somewhere between sparse and flowery – descriptive, setting the scene, adding information to build the mental image, but not really integral to the plot.

And so I kept skipping forward, waiting for the next sentence that would further the plot. I kept having to stop and re-read. I mean, if I’m reading the book, I should *read* the whole dang book. It was so hard to make myself stop and look at every word, to not skim, but to take it all in. I got so frustrated with myself, with my lack of focus on the one thing I was trying to do.

Full Screen February will be harder than I thought.

Onward.

February 2, 2015
Full Screen February

You know what is really irritating? When you make the effort to get up out of your car to walk into Starbucks, and then the people in the drive-thru get served before you do. I mean, you put all that effort into actually stepping foot into the store, to really *be present* with your barista, and then they serve some lazy jerk who couldn’t even get off his butt to get out of the car before they serve you?

How rude.

I should mention I’m in a meeting right now. I assume there are things going on in this meeting that I should be paying attention to, but I’m totally distracted. I just got a flood of Jira emails, a got a developer pinging me on Hipchat to tell me to go tell this other vendor to fix their stuff, I’m only halfway done with the things I wanted to accomplish today, plus, well. I’m writing a blog post.

Turns out that I’M the lazy jerk in the drive-thru.

Hold on, there’s some kind of awkward silence in this meeting, I need to see if they just asked me a question. BRB.

Okay, I think I bluffed an answer pretty well there. Where were we?

Oh yes. Me being a lazy jerk.

It’s too easy to not be present on these meetings. To be on a video chat and not even be looking at the other people on the meeting, to be staring at my second monitor, to be typing emails or checking messages, or using the time to catch up on something else.

And that’s not fair to the other people in these meetings. If the meeting is worth my time, then it is worth my complete attention. If the meeting isn’t worth my complete attention, then I need to not be in that meeting. Simple as that.

I’ve decided to try to mend my distracting lazy ways, or at least forge a better habit of paying attention, and treating these meeting attendees as the valuable contributors that they are. So I’m declaring Full Screen February for myself.

Full Screen February means my meeting is full screen. It’s my full attention. No other windows open, no checking email on the side, just the one thing to focus on on the screen. One full screen meeting, focused attention.

Maybe I’ll learn I need to cancel some meetings.
Maybe I’ll learn to run a more efficient meeting!
Maybe I’ll get better connection and better problem solving out of these meetings.
Maybe I’ll learn to set more accurate priorities for my attention based on real value of the things that compete for my attention.

Either way, it’ll be a challenge. Full Screen February. Are you in?

January 28, 2015
A Discourse on No

I’m a member of a few Project Manager-ish type groups on LinkedIN. Recently, there was a big discussion about how to say No to a client. Some of my favorite answers from the discussion:

Just Don’t Say No
Use data and options to deliver the message instead of outright No to the receiver.

Threaten With Dire Consequence!
I find the best approach is to provide the consequences of saying yes to the person, party, group involved. Then asking them if you say yes which consequence are they willing to accept. If there are none then they will come to the same conclusion as you and they will tell themselves ‘No’.

Of course making sure the consequences are substantial is the key.

Make Jerky Assumptions
Unless it’s a true emergency situation, approaching “NO” as if it were a “YES” can usually deflect the request. Just select one of the following approaches.

1) Sure we can do that, what function(s) would you like us to remove so we can remain on budget and schedule?
2) Sure, I’m sure the senior executive won’t mind that we delay the project just for your request
3) Sure, can you give me your departmental charge code so I can start charging time to it.

You get the point.

By that time they will have figured out that the request could wait.

Agree and Back Out Of It Later
It’s quite difficult to say NO to local client however I always say “I will try”. Afterward I will send email explaining why it cannot be done and explain the impact if we still want to do it. It works most of the time for me

Obfuscate!
Start with the findings.

“The combination of factor after due diligence was done…”

And finish with

“Will regrettably lead us to conclude it is not possible/feasible/advisable/… To do what you require/need and hence our position is to cancel and reassess”

It Wasn’t Me!
I generally find a straightforward “no” accompanied by a brief explanation as to why not appeases most people. There will always be the difficult ones who still find it unacceptable, but I can usually pass the buck upstairs when that happens. These people soon learn that the “no” hasn’t come from me personally, but is an informed and calculated business decision backed by our Management Board.

But this guy nails it. If you’re going to say no, then just do it. Clearly, simply, honestly. Being direct and clear builds so much trust. No hiding, no pretending, just real communication.

“No” is an awesome word. It has HUGE impact when stated bluntly, because so many people actually AVOID using it in favour of long, convoluted explanations!

“No, because…” is a good way of getting the message of “No” across, with an element of softening of the impact of the (negative???) word.

We’re all aware of the emotional impact of being told “No”. So, qualifying the “No” with information that is relevant, focused, and of interest to the receiver, retains a lot of the impact of the “No”, while keeping the emotional response controlled (to a degree!)

I’m a big fan of the word no. Even hearing it.

I appreciate it when a supplier tells me “No”, instead of giving me some long explanation as to why a delivery/activity is not going to come in on time. The emotional response of hearing that long explanation (Frustration? Disappointment?) causes me more grief than the shock of a straight “No”. You can get over a No, and put a plan in place quickly.

Dealing with one of these explanations usually turns into a battle of wits, where you, the customer, is trying to tease a blunt “No” out of the supplier anyway!

I could write about this for days…

Ain’t language great?!? 😉

June 26, 2014
Empathy, Engineering, and People

A discussion of empathy in engineering:

Erin Cech at Rice University agrees that empathy is essential and names our current culture in engineering a ‘culture of disengagement,’ one in which engineers focus almost exclusively on technical details with little or no attention to empathy and moral issues. Cech’s recently published results show that engineering students’ level of empathy decreased over the four years of their engineering education. Yikes. Not only are we attracting students with lower empathy to begin with but they become less empathizing over the years of their engineering education.

Why is empathy essential in engineering? Engineers design and build products, yes, but these products are for people! To design effective products and processes engineers must understand the people who will use them.

[emphasis mine.]

For all of the focus on technology, on building things faster, more efficiently, it’s all for naught if it doesn’t serve the user’s needs. If we’re not solving someone’s problem, then what’s the point?

June 25, 2014