Tag: coaching

Shoveling

The day before New Years Eve, 2021 I got locked out of my house.

I needed to get in so I could let in contractors for my kitchen remodel, and my wife and children were away in a house we’d rented for the holiday.

It had dropped well below freezing the night before and my deadbolt broke, so I needed to wait for a locksmith to come and help me get into my house.

It was still quite cold and I was going to have to wait at least 2 hours for a locksmith, so I figured it’d be better to get the blood moving outside rather than playing on my phone. 

I looked around, and noticed that the parking lot had not been plowed. So, I started shoveling.

The thing is the parking lot is huge. Holds like 50 cars. No way I could do the whole thing. With 2 hours and a cheap plastic snow shovel? Not happening. Too big a job.

Still, I started plugging away on my side of the parking lot when Royce, my 88-year-old neighbor, came out of his place. He told me he needed to get to the doctor and asked if I could shovel a path to his car. With his portable oxygen machine, he couldn’t do it himself. For him, the stairs to his house are a lot. Walking through the snow would be too much.

I stepped up the pace, and cleaned a nice path to his car so he could get himself to where he needed to get.

While I was shoveling, other folks started coming out of their homes to see the parking lot one-sixth-of-the-way done, and me in a beanie trying to clear more snow with a crummy plastic shovel.

One after another, folks grabbed shovels, and started clearing off their own little area of the lot, or areas around the other cars.

By the time the locksmith came to the house, the lot was fully cleared. All the snow was in nice, neat little piles.

Metaphors are dumb, but you can clear the snow.

We all can.

As long as someone starts.

Start.

It’s Only Embarrassing If You’re Embarrassed

I recently got an email from “Tony” asking if he could write an article on my site. He wanted to write up an article (“no charge”, he assured me) about entrepreneurship and tools.

An ad.

My immediate thought was a bit of shock… has my blog gone viral? Do I have enough traffic to warrant someone thinking they could successfully advertise on it?

A graph showing my blog's views and visitors per day in bar form, over the month of July in 2023. It is NOT impressive, showing a max of 6 views on July 14th.
Blog stats clearly showing it has NOT gone viral.

After looking through my old blog posts, I revisited that old recognizable feeling of “wait, didn’t I used to do this?” And frankly, I was embarrassed.

Once again, had I let something that I love to do fall off the planet.

In my old job at the Credit Union, I used to write an all-engineers email every Friday morning. I would start it on Wednesday and then spend hours Thursday evening finishing it.

Yet once again, I couldn’t seem to break away for 20 minutes a day to write down what’s happening.

I do best in routines. I eat the same foods for breakfast / lunch, and only change up dinner because my wife doesn’t particularly appreciate eating the same things every day. I go to the gym on the same cadence every week: 4:30pm on Monday / Tuesday, and 11:30am on Wednesday through Friday, Saturday 9am, and Sunday 11am.

If something I love to do is not in my list of habits, I lose track of it.

Now, it seems I have fallen out of something I once identified with. Something that shows me to be a fraud, or not what I claim to be.

Even worse the shame remains because even while writing this I fear that I’m attempting to, once again, restate the lie that I am something of a creator. A writer.

As if doubling down on it as an identity will make blog posts happen.

I mentor folks in my job. Every day. Literally my favorite part of being a Staff engineer.

I would allow absolutely none of the people I mentor to be as harsh about themselves.

No negative self-talk: a rule I read and remember from Pete Carroll’s Win Forever. A rule I demand entirely from my mentees.

I’ve never been so much of a rule-follower.

I choose to NOT be embarrassed by these things.

Did I fail to document my learnings while working at a pet store? Yep.

Have I failed to document much of anything while working at the pet store? Yep.

Do I still have the voice I once had? Of course I do.

I’ll tell Tony that I’ll pass on the free article. I think a DYI approach to blogging might be a better way to go.

Crummy Paintings

An amateur painting of a mountain and a river.

Back ~20 years ago, I took up painting. Fun hobby.

The problem with taking up painting is that you sorta end up with a lot of paintings you can’t use. I mean, you hang up a dozen paintings and eventually you run out of wall space.

So I started selling ’em. The town I lived in had a pretty great farmers market, and they let near anyone in there, so I set up a small table and for a few weekends, I was pitching my “If Bob Ross had cataracts” style of paintings.

Vivian. Tall lady, with a huge hat that made her look massive. Sparkly thick pink glasses. Had a hoarse laugh and deep laugh lines like she had laughed for years. Sparse red hair and equally sparse teeth. Talked with me for an hour about her kids, her grandkids, her dead husband, and her deadbeat brother. 

To this day, she is only person to this day I’ve ever heard say the word “deadbeat” out loud. 

She really liked this ONE painting that I had not been able to even GIVE away. And I really wanted this sale.

She held the painting and stared at it for what felt like an hour. Told me about her daughter who came by on Thursdays to do laundry with her who’d have loved it. Told me about how it reminded her of Mount Si (a mountain here in Washington) and how she used to pick blackberries by the coffee-can full near the river there, and the river in the picture looked just like it, so much you could hear the constant rush and gurgling of quickly-moving water.

She was going on so much, I thought she was milking me a bit to try to get me to lower the price.

It was one of my last paintings, and the market was gonna close, so it was kind of working too.

“Well, I’ve got to pack up. Did you want to take it with you?”

“Oh no. Wouldn’t match the bathroom at all. Totally wrong colors. My bathroom’s pink.”

And then she walked away. Just smiled and turned away. I was left packing up with a table, my cashbox and the remaining 3 paintings.

2 of ’em I scraped the canvas and painted over. You can do that once the oil dries.

But I kept the one with the wrong colors.

And when you attach a lot of your self worth to what you do, that ‘not fitting’ can hurt. And when you’re not able to see folks in your day to day, that ‘not fitting’ can hurt. And when you’re the only person on your team that can do what you do, ‘not fitting’ can hurt.

Vivian loved the painting for about an hour.

But did it fit? Nope. Didn’t match her bathroom colors. Vivian was right. It’d look terrible on a pink wall.

I kinda like it on mine though. I’ve gotten pretty used to it.

The Imposter

I have teenagers. I hear about how much I suck on a regular basis.

But when my teenagers tell me I suck, it’s usually for something I’m pretty proud of: making them eat vegetables, do homework, save up their own money to buy something rather than buying it for them, ad parental nauseum.

The problem is, it isn’t usually the teenagers that have my ear.

Imposter syndrome is a helluva thing.

Imposter syndrome is what they call the feeling that you don’t belong or deserve the things you have. That your social status, your job, and anything else you have is completely and unequivocally unearned.

The feeling that you don’t deserve it.

That if the rest of the world only knew, they’d call you out as a fraud.

What if they knew that I pass off feelings and intuition for facts, like constantly. (You now know this, so read on with a critical eye.)

What if they knew I was a hick from nowhere. (Palouse region nowhere, thank you!)

That my “knowledge” was all off-hand bullshit I got from having not enough to do, and mostly came from being too lazy to get up from the computer.

Some say the best way to deal with imposter syndrome is to remember your empathy. That ALL people have similar self-doubts.

Frankly, it has never been a comfort for me to know that.

That only way I know how to combat imposter syndrome is to admit what I don’t do well, and hold myself to task on it. To shit, or get off the pot. Decide the priority on fixing it, and then get busy fixing it, or let it be.

Fundamentally, it comes down to giving myself permission. It’s perfectly acceptable to suck at some things. But the things I don’t want to suck at, I’ll work to improve.

A peach is a terrible apple, but both make wonderful pie.

In that vein of holding myself accountable, here’s a list of things I suck at.

I have a degree in English, with a concentration in creative writing from Western Washington University. With said degree, I have published nearly nothing. I don’t even blog all that often.

I still have pages I wrote twenty years ago. I recently read some, and it all sucked. It was preachy and self-important and one time, rather than using the world “mental” to describe a process happening in the mind, I made up a word.

“Mindic”.

In my word processor, there’s a red squiggly line that shows me that even my personal dictionary doesn’t include “Mindic” quite yet.

In tech, I suck at just about everything. Nearly all networking stuff. Kubernetes. Go and Ruby. Most programming languages that aren’t in my standard wheelhouse. Certificates. A lot of security stuff. Game development.

I do CrossFit five times a week, and after three years of doing it, I still suck at the following: double-unders, a pull up without a band, running faster than a 10 minute mile, Turkish Getups, Snatches, and pistols.

I am not a great boss. I’ve had many people report to me, and only a scant few of them are happy for it. Most simply tolerated it. Some had marked contempt for it.

I have 2 guitars that my uncle custom-made. I still can’t play anything beyond Mother from Danzig, or a slow version of Blind Melon’s No Rain.

I suck at cars, beyond checking the oil.

My wife rechecks the dishes after I wash them, to make sure they’re clean.

I’ve been told I need better aim in the bathroom.

See, the thing is, even after writing all that stuff out, it really isn’t all that bad. It ain’t my best work, but it’s honest.

If my boss (Hi Brian!) reads this blog and notices I’m not great at Kubernetes, well, I can work on that.

If my wife reads this and notices how the bathroom and dishes stuff was relegated to the bottom of the list, I’m sorry, and I’m working on it.

If my teenagers read this: Get back to your freaking homework! Eat more vegetables! And for the love of god stop begging for things and save up your allowance if you need it so damned much!

Photo Credit: Bobby McKay from Flickr
Used with permissions from the Creative Commons License 2.0

Coaching Moment – The Ivory Tower Slash Dungeon or You Are Not Your Product

I had a recent conversation with an engineer. He initially asked for feedback on a presentation he’d done during our SDETs meeting. He presented the data loading tool he and his teammate had created, and he did a great job in that demo.

I do love a demo.

I asked him about next steps though, trying to lean into some higher level discussions I’d had with others about his team. This particular engineer is part of a two man crew dedicated to load testing system at the Credit Union, and has been for a long time.

The system is written using a load testing framework that the vendor is deprecating. His partner and him are considered ‘the experts’ at using that framework at our organization, and are entirely siloed from everyone else.

Even if they could convince management to cough up to add heads to the team, that added body wouldn’t add value until a year or more of working in the framework they’ve created.

I described his silo as an “Ivory Tower.”

He responded “It doesn’t feel like a tower… more like a dungeon”

Engineers design systems to do a job within the constraints provided.

Give engineers a tough technical requirement and add the expectation they’ll run it with no help, and you end up with a monster.

A monster that’s scary as hell to everyone else, but entices you to stick around with:

  1. Job security in a volatile field.
  2. A sense of expertise in a tech environment that’s constantly changing.
  3. A sense of ownership in what you’re doing and building.

The monster might say: “It’s not really a dungeon. It’s a gated community.”

I’d say it’s an abusive relationship.

I recall my time at {Redacted} here. One of the developers there has been working on the same product there for well over 8 years.

He’s good at his job. A highly capable developer. He likes the company, and likes the people there.

They can’t risk having him do anything new at all though. He’s stuck.

When I left, he was leading two teams (mostly by example), both working on the same product, doing the same thing he was doing 8 years ago.

Worst still, the product is largely a commodity nowadays.

There are major platforms written here that will do what his product does, and do it faster, and with an actual support model if something goes sideways.

He forgot that his value was in the expertise, rather than the product.

{Redacted} is a good company, but it’s damned hard to see where he’ll go from there.

“Just try to keep an idea that load testing should be a product… rather than a person.”

That was the message I gave my Credit Union engineer, and I find it true about all engineers. It’s a message that engineers specifically need to know.

You are not your product.

Your value is not connected to your product’s value.

You’re more important than that.

Make sure you treat yourself accordingly, and more specifically, make sure you design systems to treat you accordingly.

On Being Coachable

I have spent a few posts about my experiences coaching other folks. It is immensely satisfying to coach and mentor people in their careers, but not everyone is mentally ready to be coached by someone else. Pride is legit, and exposing yourself to the critical eye of others with the express purpose of having them break you down can be difficult. Many times the things we need the most coaching on are things we attach our sense of self to. Subsequently, we do not improve as fast as we could have, if we had that course correction.

Here are four tips for being coachable.

1. Remove the Personal Stake

Take a deep breath and start here: You are valuable. You matter. It is critical that you continue being who you are. Unfortunately, the things we need coaching on often are those same things that we use as a crutch to define our identity. Look very deeply and critically at your own crutches before you do anything else.

You do not need coaching on how to be a better you. Coaching is for skills, for empathy and awareness. A good coach pushes you towards a place where you can improve what you are doing, not who you are. If you attach your ego to a set of skills, you will buckle against guidance.

This is 2020. Most people will hold several careers over the course of their lives. There is no value in remaining static to a single set of skills, and just as so there little value attaching your identity to those skills. If you find yourself saying ‘but this is who I am’, step back, and ask ‘is this who I want to be?’

2. Make Yourself Conspicuous

A key element to being coachable is access, and making what you are doing open and visible. If your coach or mentor cannot see you what you do on a regular basis, you are limiting that person’s ability to help you. The key here is to make your coach aware of the specifics of what you are doing.

Examples: As a softball coach, I can talk in general terms about batting, but for an individual player, I can target her specific stance and swing when I see her swing. My CrossFit coaches address movement when they specifically see them, and the movement is still fresh in my mind. When pairing with a software developer, I can consistently nudge back to write tests before they write the implementation, as opposed to doing a simple code review, where I may not see that developer’s whole process.

3. Get a Regular Feedback Loop

Now that you have made what you do visible, you have to setup a regular feedback schedule. Look for feedback that is targeted, specific, and on a detail you are capable and interested in changing. Regularity of that feedback is the critical element here. Setup a scheduled time for that feedback and disconnect it from the immediacy of the moment.

This one sounds counter intuitive but coaching is done well during a time of introspection. During the moment, it is too easy to get emotionally attached to what it is you are doing, and so criticism hits buttons harder than they really are intended to. You need to pick the right time, when the moment is still fresh in your mind, but detached from those immediate emotional points connecting it to your sense of self.

4. Invest Your Time

The only way to get better at something is to put in the time, and it’s the most useful way to follow after a coaching session. You cannot watch a video on improving your short game, and just expect your handicap to drop three points. Spending time on Udemy watching guitar instruction videos is great, but you have to put in the work and practice what you’ve seen. Nobody learns to swim from a book about swimming.

Once you’ve taken the time to remove the personal stake, make yourself conspicuous, and set a regular feedback loop, the final step is to exercise consistent and deliberate practice. Things won’t necessarily come immediately, but you’ll be able to push forward more quickly. Dedicate calendar space and some distraction free time to practice the deep work required to improve. Turn off the rest of the world, and build your skills.

Coaching Moment – Sharpen the Axe

Yesterday I was in a career planning meeting with a developer, who complained she didn’t have enough free time to learn all the stuff she needed to learn to move forward. She had too many meetings during the week, and too many too many tasks assigned to her on her project team. Even worse, the tasks she was getting that they all were the same ‘kind’ of tasks. She said “I’m not getting better. I’m stuck. <<Another developer on her team>> has already started working on <<a new technology>>, and I don’t have time to even look at it.”

That comment was an absolute heart-breaker for me.

I despise being stagnant. I am also distinctly competitive. That feeling of being stuck on a team and watching everyone else do bigger and newer things is one I have a lot of empathy for.

One of the telling moments of our conversation was how this particular developer was filling her time. In her mind, work hours meant she was working on her project, full stop. She had forty hours a week planned towards project work, and even basic administrative stuff like email, meetings, was designed to fit in to that time.

A long time ago, I heard this quote attributed to Abraham Lincoln.

“If I had six hours to chop down a tree, and I’d spend the first four sharpening the axe.”

Lincoln, maybe? I have no idea…

“We have tons of training options. What are you doing to train yourself?”

She mentioned a Pluralsight course she had started in her off-hours, but not finished. I told her I wanted her to add learning time to her week, and I wanted a bi-weekly status report on what she had done. She asked about fitting in her project work.

“Sharpening the axe IS project work, when the project is chopping down a tree.”

As someone in technology, maintaining a continual pattern of learning and training is a personal responsibility. Google made themselves well known with their advent of ‘20% time for personal projects’. Having never been a Googler, I couldn’t tell you if that’s true, but I do know staying up on the developments in the industry is crucial for personal fulfillment and job growth.

Take the time, and sharpen your axe.

Coaching Moment – Why Won’t They Give Me Permission?

I had an impromptu conversation this afternoon with a system engineer. He wasn’t looking for ‘coaching’, in the same vein that my developers are inclined to do, but a conversation about how to integrate a new technology into the credit union’s mechanisms. I am a poor network engineer. My understanding of network sophistication is pretty slim, and my ignorance was exposed, repeatedly, throughout this conversation.

However, as we discussed the problem, and came to a series of potential solutions, a common thread came up in my colleague’s responses to a solution.

“Yeah, that probably could work, but it will be nearly impossible to get this through…”

“This would work, and would be kinda fun. But moving the CU toward this is like turning a ship around…”

I checked in here. There wasn’t a technical reason these solutions weren’t reasonable. They were just too ‘new’. I queried further, and it became very clear a lot these ideas were things my peer had thought of. He just never got permission to move forward.

And just like that, it became a coaching moment.

Aside: One of my old managers used to hate complaints. Hated them. His personal stake in what we had built attached a personal note to anything technical complained about. If you came to him with a complaint, and an expectation that he would ‘fix it’ for you, you came away rebuffed, and in no unclear terms. But if you came to him with a complaint, and a well-thought out fix for it?

That nearly always ended up differently.

I coached this particular engineer about feeling welcome to take that next step, and propose a ‘fix.’ This is common to the Pull-Request model of open source software. An lone issue and complaint is reasonably ignored, but an issue with a well-thought-out pull request, correcting the flaw? That is something worth paying attention to. Even if the correction is inaccurate, it is worth paying more attention to someone willing to put in the work to correct it. In your own life and work, put some skin in the game.

Avoid being a complainer that is not willing to own the problem or the solution. Get in there, find out what’s hard about the problem, and take the chance to own the solution. Will it always work? Of course not, but the effort you take learning about the problem will likely lead to a better solution down the line.

Coaching Session – Is Everything Broken, or Is It Just Me?

Today’s coaching session revolved around a young developer recently moved into an established team. The developer had experience in Agile teams with specific practices, and this team’s practices were VERY different, and almost non-existent. As opposed to a product team with a defined backlog process, this new team is catch-as-catch can, and largely individualized. This developer was concerned, greatly.

“Where is the product owner? Why isn’t she engaged here? Where are the stories? Where is task breakdown?” And on and on, indicating worries great and small. He was half-convinced the entire structure was broken, and needed to be rebuilt from the ground up.

Man oh man, could I empathize with that.

There were a lot of complexities to unpack in this developers complaint, but I called out his newness to the team. He was joining an extremely stable team, with established norms and structures. It is entirely possible that the Agile mindset and culture of the team needs to change, but for an engineer, the first thing to do is get competent on the platform.

This team is a bunch of individuals working. That is a problem. Fixing the process needs to happen, for sure. That isn’t the purview of a brand-new-to-the-team engineer. Nobody is going to listen to someone who comes into an organization and immediately vents about how everything is broken.

Process absolutely matters, but for this engineer, engineering has to count first. That’s what I coached him to do. I recommended he get good at the tech FIRST, and then talk about process improvements.

After that conversation ended, I setup a meeting with the product owner. I wanted to see what sort of issues she was seeing, and if there was anything this principal software dev could help with.

Coaching Session – Panic at the Deadline

I had a conversation with a new dev lead today. This lead was recently installed into a project with an upcoming deadline that he was genuinely worried about. As we started the conversation, the worry sort of came out of him in piles. When he was finally able to take a breath, I collected from him that 1) he believes that the code-base is largely un-salvageable (he only recently joined the team) and 2) the deadline is completely rushing at him (about a week and a half before the first delivery.) I had spent a few minutes looking through his project and coached him toward doing the following.

1. Get a CI / CD Pipeline Setup

The first thing to do here is to get a Continuous Integration and Delivery pipeline setup, so you can quickly and reliably deploy in an automated fashion. The fact is, no software comes out as a 100% bug-free product the first time and this software will be no exception. By building up the CI pipeline you’ll be able to fix things quickly and consistently. Every commit should create an artifact, and assuming success that artifact is something can release. If the software isn’t good right now, the product can get good over time.

This was the bulk of the conversation, as it felt like to him that I was recommending that he throw sh*t at a wall and hope that it sticks. The big value comes from the ability to iterate.

2. Code Doesn’t Have to be Perfect.

The fact is, when you have a deadline you have already agreed to, you have to get over the fact that the code is crap, and likely will need a rewrite. Code is a tool used to create a product, nothing more, so worrying that it’s “not good enough” is contra-indicated.

The dirty truth about software is that no code is good enough. Ever. There is always something to do better and cleaner. That is not to disparage the craftsmen out there, but a craftsman does not back out of a commitment. When you make a commitment, you keep it.

3. Keep Your Campground Clean

This one was fairly specific to the project, but in development projects un-merged branches and directories all over the place that are largely empty do not help anyone, and make the project look bigger than it is. If you have a REST API and a daemon, you don’t need a ‘Tests\Python’ folder that has nothing in it. Things that look small, will feel small.

I will check in with him again after a few days to see what progress he has made on those items. If he can get the CI/CD pipeline down, and know HOW to get the code into production boxes quickly, we can move into things like refactoring into patterns that might smooth some sailing here.