Hone Your Craft, Raise Your Hand

Last week I was talking with some folks at Pillar in Columbus, Ohio, and we were discussing career progression. The discussion evolved into how individuals could move up a career path, or be recognized as wanting more responsibilities.

John Huston, one of Pillar’s leaders, made the comment “Hone your craft, raise your hand.” That comment really struck home with me, so much so that I grabbed a 3x5 card on the table and scribbled the phrase down right in the middle of the ongoing discussion.

I love John’s phrasing because it concisely sums up one of the best ways you can advance along your career path: work hard, ask for more responsibility. I’ve always been a believer that hard work gets recognized in good organizations. [1] It’s not immediate recognition; sometimes it takes an extended effort to get to that point.

Honing your craft is critical both to you and the organization you work for. Honing your craft means you need to invest the time and energy in a focused, planned effort to improve your skills. That helps you get better at your job. Your improvement rolls up into your organization’s ability to better deliver value to whoever the customer or end users are.

Raising your hand isn’t always easy. First off, many of us (I’m looking hard in the mirror here) have problems letting our leaders know we’re ready for more responsibility. We may suffer from impostor syndrome, we may feel it’s arrogant, or we may just have a hard time speaking up. (I suffer from all three…)

Regardless, it’s something that everyone should strive to feel more confident about. Asking for more responsibility makes sure your leaders know you want to help the organization in one fashion or another&emdash;and that’s something they may have been too busy to notice.

My most favorite jobs have been opportunities that popped up after having worked hard at other roles: Director of QA at Telligent, Director of Engineering at Telerik, and a few other things further in my past. I didn’t plan for those advancements, I just worked hard at the role I was in and made it clear I was happy to take on other tasks as needed. That mindset worked out well for me and resulted in neat opportunities I’d never thought of.

Obviously my journey’s different than yours. Your mileage may vary. Insert other disclaimers here as necessary.

Point being, too often we forget that sometimes the best way to advance in one’s career is simply to focus on improving how we do our own work: Hone your craft. We also forget it’s good to let your leadership know you want more responsibility: Raise your hand.

Hone your craft, raise your hand. Solid words for moving your career along.

[1]Yes, yes, there are places and situations where it doesn’t. Remove yourself from those. You own your own path.

CodeMash Session Follow Up

For those readers who attended any of my three sessions at CodeMash: Thank you! I appreciate the great audiences I had, especially those who braved the 55 or 60F temps Thursday morning in Cypress for my Ten Tips for UI Automation talk!

Here are resources for my three sessions:

Leadership 101 Workshop
- Slide deck
- The Leadership Journey, my book on growing into being a great leader.

UI Automation Workshop
- Slide deck
- Basic examples on GitHub
- Demo site showing table access, updates to UI for dynamic IDs and flag elements

Ten Tips for Web UI Automation
- Slide deck

Common references for web testing
- Dave Haeffner @TourDeDave on Twitter.
- Dave’s Elemental Selenium site and newsletter
- Richard Bradshaw @FriendlyTester on Twitter

My CodeMash Sessions

UPDATE: I had the days wrong. Leadership workshop is Tuesday starting at 8am in Salon H. My Web UI Automation workshop is Wednesday from 8-5 in Guava/Tamarind.
I’m flattered to have been picked up for two workshops and one regular session at CodeMash! It’s going to be great being able to focus on just giving great sessions and not worrying about herding various cats around.
Tuesday I’m giving an all-day workshop on web UI test automation. We’ll dive deep into working with Selenium WebDriver, but the concepts will cover plenty of other toolsets. I’ll likely spend a bit of time showing how a commercial tool like Telerik Test Studio fits in to things.
Wednesday I’ve been asked to do a half-day workshop on leadership. That’s incredibly flattering! I’m basing the content for that off my Leadership 101 series, plus the book I’ve just started The Leadership Journey. This brand-new workshop will be very interactive with a good number of exercises meant to help you really dig deep and figure out how to evolve your own leadership style. I’m pulling this workshop’s content together very quickly, and I’m both excited and terrified.
Thursday I’m in an opening slot at 8am talking again about web UI automation: Ten tricks to help you get the most out of your UI testing. The talk centers on web automation, but it really will help you regardless of what UI tech you’re working with.
Interested? Check the CodeMash schedule for details, or go grab the EventBoard app and get your schedule built up.
Got questions on testing, process, leadership, or something else? Look me up at the conference! I’d love to chat!

You Broke My Code? It's My Fault

I was having a conversation with a few smart folks a couple weeks ago and one of them mentioned a great mindset their organization has: “You broke my code? It’s my fault–I didn’t have the right tests in place.”

Step back and think about for a minute.

This quip really set me back on my heels. If you’ve read anything of mine over the years, you know how I feel about taking responsibility for one’s code and one’s tests. This organization’s mindset of owning the responsibility for bullet-proofing your own code with great tests is terrific.

It’s one thing (a great thing!) to step up to the plate and be serious about getting testing ingrained in your delivery process. It’s a serious elevation to get a mindset where every developer takes it personally when someone else breaks their code.

“You broke my code? I needed more tests.” What a great mindset.

Book In The Works: The Leadership Journey

I swore I’d never write another book after finishing 1300 pages of Windows Developer Power Tools with my co-author James Avery.

Famous last words.

When the kind folks at CodeMash asked if I could put together a four hour workshop on Leadership, I figured I’d better get some solid content laid out to make sure the class wasn’t just boring anecdotes of mine. I needed something more focused, and something with some practical put-this-to-use-tomorrow kind of ideas.

Apropos, let me introduce to you The Leadership Journey. This book contains the original Leadership 101 blogposts and will end up with a lot of new content. There will also be practical exercises to help you focus in on a few key things.

What’s the books goal? To help you answer a few key questions:

• Do I want to be a leader?
• What are my strengths and how can I make the best of them?
• What are my weaknesses, and how can I best mitigate them?
• How can I make my team be awesome?

I’m publishing the book on LeanPub with a recommended price of $9.49. I hope you’ll have a look at it.

What would you find helpful in your own leadership journey? Leave me feedback here in the comments, or over on the book’s LeanPub page.

Choose Wisely AND Back Out Easily

Alan Cooper (Yes, that Alan Cooper) had a great-sounding Tweet yesterday that made me stop and think:

Instead of choosing the correct path in advance, develop better tools to incorrect paths soonest and without rancor.

I get the point I think Mr. Cooper was trying to make: we need to be able to recover more easily from our mistakes in software. I especially love his point of “without rancor” because we need to be more accepting of the fact that the path to success is littered with unsuccessful tangents.
However, I’ve got a subtle iteration of his phrase I like better:

Do your best to choose the correct path at the start, but know how to figure out it’s an incorrect path, and figure out how to reverse soonest and without rancor.

I completely agree that we need to get in the business and cultural mindset of being OK with failure/mistakes, getting out of them as quickly as possible, and doing it without rancor.
That said, I’d prefer the subtle difference of emphasizing avoiding those mistakes where possible. We should not, repeat NOT get wrapped up in fear or analysis paralysis blocking us from decisions that might lead to mistakes or failures, but we should be doing enough sanity checking to ensure the choice meets business value requirements, fits the teams’ ability to deliver, etc.
In my Leadership 101 talk I make the differentiation between smart mistakes and dumb mistakes. Smart mistakes are ones made when you’ve been thoughtful about your approach. Dumb mistakes are when you dive in to dig a 14’x8’x18” rain garden pit, then realize you’ve dug it right next to your house’s foundation–not the place you want a lot of water sitting for extended periods. (Ask me how I know about this…)
Backing out from unsuccessful choices is critical. First spend a little time planning to ensure you can avoid as many of those choices as possible.

Rethink Your Hiring Critieria

This article on how Google's changing their hiring practices really hit home with me.

I've long viewed learning ability and problem skills as far outweighing where someone graduated from or what their resume history looked like. I've previously blogged about my thoughts on hiring, and  my position descriptions have tended to drive HR departments crazy because they weren't checklist oriented.

I've always been more interested in how well someone's going to approach working as part of a team over what classes on compilers they took, or what certifications they've passed.

Technology changes too fast to focus on criteria like "3.6 years working with .NET 4.5" or "Must have graduate degree in artificial intelligence." I'd rather have people on my team who have made some big mistakes, learned from them, and want to share that knowledge with the rest of their team.

Do your hiring criteria look like shopping lists in the technology buffet? Perhaps you might reconsider reworking those around criteria that focus on your organization's real needs: candidates who can help you quickly and effectively solve problems core to your business needs.

Hire me!

I'm open for work!

Last week I parted ways with Falafel Software. They’re a great bunch of folks, but we weren’t a good match culturally or philosophically. That’s absolutely OK, and we parted on good terms. I’m happy to continue recommending them and calling them friends.

That means, however, that I’m open and available for new opportunities! I’m actively looking for work as an independent consultant, or for any full-time spots where organizations think I might be helpful.

What sort of things can I help you with? I’m passionate about helping organizations deliver great value to their customers, regardless of whether those customers are external or internal. I’ve helped teams build out their testing skills (not just test automation, but overall testing), smooth out quality issues impacting their organizations, and cut out waste throughout their delivery cycle.

That may sound a bit hand-wavy to you, so for more details check out my LinkedIn profile, visual resume, or more “traditional” (eg ‘non-gonzo’)resume.

Want to chat about things in more detail? I’d love to talk with you! Drop me an email at my new Indie digs: jim@GuidepostSystems.com.