Tag Archives: coaching

Crummy Paintings

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.

Coaching Engineers – A Review

One of my regular responsibilities at my new job at the Credit Union is coaching developers, engineers, sdets and QA folks. Today, I got to be involved in three different coaching sessions that all had unique subjects and discussion points.

Session 1: How to get to Senior – Developing Expertise

This is a fairly common situation. A developer wants to go from Software Developer to Senior Software Developer.

The process of making Senior Software Developer generally comes down to adding more responsibility and influence to your day-to-day job. To get to a senior role, you can do one of the following:

  1. Take on a team lead role. In this case, you are the point person and responsible for more of the project work itself. You T-shape your skill set, but become the primary point person for the whole project.
  2. Take on a manager role. In this case, you’re trying to mentor and grow the skills of the folks around you. You may not be directly responsible to all the functions in the project, but you help and mentor those folks around you.
  3. Take on an expert role. In this case, you target getting deeply technical and specialized. Your plan is to become a known leader and expert on a particular technology.

The developer in question was interested in learning more about this third pattern of developing her expertise, and what it would take to continue that progression. She expressed interest in web user interfaces with Angular, and spent the session showing me what she had learned and worked on, and where she was going next.

To coach, sometimes you just need to be the accountability buddy.

Session 2 : Whose Design is Right?

In this session, a team of software developers had some questions about the nature of their solutions. They did not agree about the approach to a problem, and this particular session was with one side of that argument.

Side note: I love these sorts of discussions. Folks getting passionate about the way they choose to solve a problem is WONDERFUL.

The best part is that there was not a clear winner in the design of the application itself. They were different designs, to be sure, but they each had technical merits that could very easily be seen.

At the core, this one came down to coaching back to the engineering. The crux of the problem was that there was no data proving one solution better than another. The quantitative features of the respected solutions had not yet been tested, and that was the end state I coached towards here.

If your design is better, prove it with data. Otherwise, GTFO of the way.

Session 3 : SDETs in the Credit Union

Initially, this one was setup to be a discussion about how to write code to use a Windows Application automation tool (Selenium with WinAppDriver), but after the first session, it was apparent many of the SDETs present already had a lot of experience with those libraries. There were four SDETs and one analyst in this session, so it became a larger discussion about the nature of testing. We started collaborating on ideas about the about the best ways we could automate some of the harder tests to deal with.

Finally, it came down to discussions about the AAA pattern of testing, the kind of test code we wanted across the org, and even some of the difficulties in teams where SDEs and SDETs have a combative relationship.

Coaching engineers is exhausting and inspiring all at once. It was a great day, and I feel blessed to be able to do it!