Category Archives: Technology Career

A Code Camp Every Week

You’ve asked.

At least a couple of you did!

Here are the basic principles of the HealthEquity approach to lunch and learns. This article is the super abbreviated version of a 10,000-word epic I’ve been writing for ages.
Me when I realized no one wants to read a 10,000-word epic article.

Why do I care? Why should you?

Folks outside HealthEquity might consider this part of the secret sauce of our organization. Any team/company in the world could take the same approach, and we wish they would. As an industry, everyone benefits from more engaged, better-educated teams.

I don’t remember the first time I saw the following set of questions, but they are deeply ingrained in my approach to leadership. What could be worse than an entire staff of expert beginners?

“What happens if we spend time, effort, and money growing and coaching our team members and they leave the company?”

“Isn’t it worse if we don’t make those investments and our team members stay with the company forever?”

-Someone I Paraphrased

I want to build on this micro-focused concept of individuals working for a single company and expand it to the macro level. Let’s be honest with ourselves, in this world where technology people are in perpetually high demand, folks often switch jobs every few years. Initially, my goal was that folks wouldn’t leave our team, or at least when they do, their new employers would take notice and see a pattern of excellent people coming from HealthEquity. Also, I wanted folks would have fond memories and recommend us as a place for their friends to work. I realize now, this was driven by ego, and it was too narrow a scope for the vision we really need.

We need to be thinking about the success of our industry as a whole. To that end, I propose the following:

Continuous Learning Manifesto
Focus on doing what is right for our team members, companies, and customers, by looking for ways to continuously measure and improve our learning and share our findings with the world at large.

Stepping off the soapbox now…

Preaching is not the point of this article. Let me share the cool stuff we’ve been doing.

Some of my co-workers love lists, so I’ll use a list to illustrate the cycle we’ve been through.

  1. We realized we could improve and asked for feedback.
  2. We used the feedback data to create a plan to improve.
  3. We acted on the plan.
  4. We built feedback into the program.
  5. We continued to listen and act on feedback.

The short version is: we retrospected.

Here’s what we ended up with. A multi-track “lunch learning” program for seven out of every ten weeks 4 times yearly. 56 total days a year!

I’ll say it again. MULTI-TRACK SESSIONS SCHEDULED 2 DAYS A WEEK 28 WEEKS A YEAR.

You’re probably saying, “That’s crazy!” Originally, I might have agreed, but we’ve been doing this for 3 years running. We’ll kick off our 4th year this month (February 2019)!

Here’s the quick version of what we do (yeah, another list):

  1. We pay for lunch.
  2. We facilitate our educators.
  3. We retrospect individual sessions and the program as a whole.

Where we started.

In the beginning, our lunch and learns were just like yours. Sparsely attended, often complained about soapboxes for management and the elite of our organization. We had to figure out how to democratize the process.

Several members of our teams responded to our early efforts to move from “all video, book, and preach” to something new. We were doing one thing a day three days a week, and everyone was expected to attend unless they had more important work. Anyway, the feedback was this: “Why not do something where there are different options for different people who want to learn different things? Multi-track-style!” I was floored. I once helped organize a small tech conference, and it was a ton of work! There was no way to make this happen, or so I thought.

Here’s an anonymized schedule from mid-2016.

Taking things one step at a time, we surveyed for interests and found that people wanted to learn about some specific things. Then we put out the word to everyone working in tech at HealthEquity. We had plenty of volunteers! For a time, I took on scheduling rooms, building a schedule for ten weeks, running retrospectives, helping presenters, and teaching a few things here and there.

From the beginning in 2015, we also opened up Intro to Coding in C# classes to the entire company, and even managed to promote several motivated individuals into our technology group as part of the effort!

If it seems like all of this was an epic amount of effort, you’d be right. But we spread it out over time and learned as we went, so it was never too much to handle at once. Eventually, as we retrospected, we found ways to streamline. As things streamlined, we expanded outside the technology group to the entire company in 2018 including plenty of non-technology topics!

What’s next?

We’re still evolving, and now we’re creating tools to assist with our practices. I’ve intentionally left a lot of detail out because I know not everyone is interested in it. Like I said in the beginning: no one wants to read a 10,000-word epic. I’m warming to the idea of calling this concept “Lean Learning”. What do you think of that?

If you have questions or want to hear more about HealthEquity’s Lean Lunch Learning program, hit me up on LinkedIn ( https://www.linkedin.com/in/williammunn/ ) or in the comment section below. I’m more than happy to help you get a similar program started, or tell you reasons why you should work at the greatest HSA company in the world!

Why Should You Prepare Lightning Talks and Wildfire Talks?

I can hear you now: “Isn’t it sufficient to have talks? Why define special types?”

“Why prepare ANY talk?”

“Ugh!”

Well, I’ll tell you, but first a touch of background.

It was probably five years ago when I discovered the concept of a Lightning Talk during a Utah Software Craftsmanship meetup. Some research tells me the idea has been around in some form or another since 1997 (Wikipedia).  I think Lightning Talks are great for a variety of reasons, but they don’t fit every situation.

During a retrospective of a couple of different Lightning Talk sessions we held at HealthEquity, feedback came up that some of the topics could have used expanded time and attention. We came up with a concept that, while also not new, we dubbed Wildfire Talks. Wildfire Talks are equivalent to a TED Talk in many ways. They deliver a short, poignant message and should meet the same criteria of a TED Talk, but aren’t branded and are usually only given in person.

You may have guessed, one of our goals in technology at HealthEquity is to develop leaders. We consider our senior individual contributors to be leaders in their own right. Public speaking and the art of persuasion is part of the gig in leadership, so we use these types of talks as an easy entry point to help folks learn.

Lightning Talks

If you aren’t familiar with Lightning Talks, they normally aren’t planned and scheduled. They are five-minute talks, and they are sometimes added to an existing meeting or meetup. I’ve also facilitated sessions composed entirely of Lightning Talks.

In both cases, every presenter for the session is already a member of the audience/meeting.

How does the audience benefit? I’m glad you asked! The format lends itself nicely to helping folks get exposure to a wide variety of interesting information in a quick format themed around a shared interest.

What I love most about Lightning Talks is the no-pressure approach to introducing people to public speaking. For someone who is nervous, five minutes is often long enough for the jitters to subside. They are also informal, so presenters can experiment with presentation techniques and find the methods they prefer.

The facilitator can smooth the way for Lightning Talks during your gathering.

To begin, set expectations for the audience by announcing you will open the floor up in increments of 5 minutes.

Audience Requirements for Lightning Talks

  1. Volunteer to speak.
  2. Applaud after every talk.

Folks volunteer (an important distinction for Lightning Talks) to talk about something within the bounds of a guiding statement the facilitator provides. An example guiding statement could be: “All talks should be related to new developments in technology released in the past ten years”. With the above guiding statement, talks could be about 3D Printing, Internet of Things, your favorite development tool, a cool new piece of hardware, how Bitcoin works, a new programming language, etc.

Presenter Requirements for Lightning Talks

  1. Introduce yourself.
  2. Stay on topic within the guiding statement.
  3. Slides/screen sharing is optional (and should only be used as punctuation).
  4. Gracefully end after 5 minutes including Q&A (signaled by the facilitator).

Optional

You can ask for audience ratings/comments (stickie notes work well for this) for presenters who would like them. It’s an excellent opportunity to get some feedback for those who want it, but don’t collect the data if the presenter isn’t interested.

 

TRANSITION

Wildfire Talks (or TED Talks)

Wildfire Talks are the evolutionary step from Lightning Talks toward a full 45-55 minute talk. In contrast to what we sometimes see from longer form talks, the intent is really to make one point and make it well.

A good rule of thumb is to follow the advice of Talk Like TED by Carmine Gallo: focus on delivering something emotional, novel, and memorable wrapped in a clear beginning and end.

Unlike with Lightning Talks, Wildfire Talk presenters are asked to speak in advance. Each talk is approximately fifteen minutes, and although some people can get up and wing it for that amount of time, they would often be even better with a little preparation. When a facilitator selects Wildfire Talk presenters, they will want to choose people who’ve already mastered the Lightning Talk format.

Wildfire Talks can add detail and are often a more useful tool to convince people to consider something they might have been on the fence about before. Slides and screen sharing remain optional, but if you do use them, make sure their purpose is to give the presentation pop and drama, not as a checklist of things to present.

As a facilitator, if you are organizing a series of Wildfire Talks, consider narrowing the focus more than you would for a session of Lightning Talks. In four fifteen-minute sessions, you could have talks about:

  1. .NET is the Premier Open Source Framework
  2. Why are Some Development Shops Switching to F#
  3. Best New Features of C#
  4. Strategies for Writing Threadsafe Modern OOP Code in .NET.

Presenter Requirements for Wildfire Talks

  1. Introduce yourself including your qualifications to speak on the topic you’ve chosen.
  2. Stick to the single topic, don’t stray off course.
  3. Keep slides minimal and relevant.
  4. Stick to the 15-minute timeframe. The facilitator will keep time and give notice.
  5. Say what you’re going to say, say it, and say what you said (summarize, explain, summarize).

The audience must clap (they’ll want to).

I hope this is helpful. Five years ago, I wouldn’t have been able to guess what a Lightning Talk was if you’d asked me. After giving a few of them, I had more experience in front of technical crowds and was able to see some patterns in my presentation style that worked well (and some that didn’t).

The Wildfire Talk concept was born of retrospective feedback after I facilitated an hour-long session of Lightning Talks at HealthEquity. I believe the benefit here, is focused learning for both the audience and the presenter. It still isn’t a huge time commitment, but the presenter can focus on getting better at delivery of content, and the audience gets the additional info they craved after a lightning talk on the same topic.

I hope you’ll take the opportunity to practice presenting.  Public speaking has been called one of the biggest fears of humankind. Take the small steps of learning to present Lightning Talks and Wildfire Talks, and you’ll gain competence much faster than you think.

Now. Keep your best talks on standby so you can trot them out the next time someone asks for speaking volunteers. You’ll be glad you did. You’ll spread learning about a topic you believe in. You leader, you.


A Tech Lead Is Not A Manager: Influence vs. Authority On Agile Teams

I previously wrote about how I worked on an agile team as a tech lead. The article focused on the things I recommend. Today, I’m going to take the opposite approach and share what to avoid: the misuse of authority including mistaking an influencing role for an authoritative one.

You can read the original article here.

Roles, Roles, Roles

On agile teams, a Tech Lead is far more like a Software Architect or an Agile Coach or a Product Owner or an Engineer than a Manager, Director, or another role with people reporting directly to them. You don’t have AUTHORITY as a Tech Lead, your weapon of choice is INFLUENCE. Of course, even people with authority should rely on influence as much as they possibly can. Authority is a tool in the toolbelt of some roles, and those people must use it sparingly. Autonomy is too important to take away from creative workers (and Engineers are indeed creative).

At times authority must be used by people in what I like to call “dark side” roles. Managers, Directors, Veeps, etc. must at times use the stick instead of the carrot. Usually, this is reserved for extreme cases when a team member is refusing to follow company policy or is threatening or endangering someone. In a positive culture, these things should seldom IF EVER happen.

One of the things I love about the organization at my current company, HealthEquity, is the culture of influence. Influence is the currency of the day at all levels of leadership, and it’s used efficiently and effectively.

What Does Misuse Of Authority Look Like?

Some key things to look out for: body language, word choices, and the audience. Watch for words like these coming from your mouthhole:

But, I’m the Architect/Manager/Director/Scrum Master/Tech Lead/etc…

…you have to do this.
…this is the only option.
…because I said so.
…it’s my way or the highway.
…eat crap and die.

Absolutes and personal attacks/insults are not going to work. They may sometimes achieve the immediate effect you wanted, but it’s going to come back to bite you in the end.

Avoid negative feedback in a group setting at all costs. If you MUST provide negative feedback (and yes, sometimes we must) always, ALWAYS, do so in a private 1:1 situation. Involve your people leader if you aren’t comfortable one-on-one.

Instead, look for ways to encourage, build-up, support, and assist people in doing what you believe should be done.

Shameful Anecdote Time

Once, in an earlier decade of my life, I was an inexperienced young team lead. I had responsibility for a developer who was undertaking a critical task. The task wasn’t moving along the way my manager and my manager’s leader hoped it would. There was some time sensitivity involved, and I was asked to research the issue and get things moving along. I did some investigation and found that the developer was spending a lot of time (over 50%) not engaged in his work.

I’ll admit it; I was frustrated.

Instead of following the advice I’m giving in this article, I decided to walk right up to this person’s cubicle and ask how the work was progressing. Nothing particularly wrong with the approach, although in hindsight, I should have known the discussion was likely to become sensitive. I should have invited the developer to a private location to discuss one-on-one.

Anyway, when we spoke, the developer told me how well it was going and how hard he was working and how he’d have this already late project completed just as soon as he could, but not for at least a few more days. When describing the work remaining, I felt it was completely trivial. It could have been completed THE NEXT MORNING.

I won’t go into detail, but I lost my cool. I felt pressured and I let the pressure rule my emotions. My voice rose high enough for at least neighboring cubicles to hear, if not more. I told this developer that he would finish this work by the end of the next day or there would be hell to pay.

I’ve never seen someone’s face go from zero to pure unadulterated hatred so quickly.

The developer finished the required work on my timeline, but I had ruined a relationship and completely demotivated my co-worker. As kind, cheerful, and pleasant as I could be, it never made up for my error. The individual became a habitual underperformer, and eventually was let go by our manager.

I’ve always wondered how the situation might have gone if I knew then what I know now. Would I have pulled this individual aside privately? Would I have offered my help or another’s on the team to push through the last bit of work? Would I have asked more about the situation and sought to understand why he was underperforming in the first place?

I’d like to think I would have. I’d like to think I’d have given less weight to some of the authoritarian “truths” I’d been exposed to growing up.

Avoid False Truisms Of Authoritarians

Avoid being taken in by the truisms of autocratic leaders like Bonaparte and Hitchcock. Do not let their philosophies influence your leadership style.

“Men are moved by two levers only: fear and self-interest.” -Napoleon Bonaparte

“If an actor comes to me and wants to discuss his character, I say, ‘It’s in the script.’ If he says, ‘But what’s my motivation?’ I say, ‘Your salary.’” – Alfred Hitchcock

The work we are doing in any creative or thought-related organization requires 100% of the team’s buy-in, commitment, and enthusiasm to be as effective as possible.

Leaders don’t and can’t have all the best ideas. Create psychological safety for people you work with to aid their growth and contributions.

Authoritarian leadership styles have little or no place in Agile organizations.

In closing: I recommend avoiding the “command and control” mentality in favor of “inspire and innovate”. Tech leads (and technology leaders in general) aren’t running military operations; we are engaged in creative endeavors.

If you enjoyed this article, why not check out some of my other favorites on the subject?

Learn Like A Viking

My friend Ron Coulson (who I’ve known practically forever) has challenged himself to write a poem a day this year. He is well underway. This is #63 of 366, because, you know, leap year.

I’ll be the first to admit I’m no poet, but the subject matter here is near and dear to me — learning! I also enjoy a good metaphor and the Viking theme here is vivid and wonderful. Overall, it struck me as fantastic and I thought I’d like to share it with you all. Ron generously agreed. I hope you enjoy it as much as I did!

drinking-horn

Untitled

Let us devour knowledge in a way
That would make vikings cringe
Let’s gorge ourselves until we
Vomit certainties no one can dispute
Let truths drip from our chins
As the spittle of enlightenment
Lands in our opponents eyes
Raise your mugs, my friends
Then chug down life’s lessons
Until we are drunken sages
Then sleep
Then do it all again

-Ron Coulson (2016)

If these words have inspired you to learn, check out the new page I’ve added to the blog where I’m attempting to keep track of some of the best coding katas. Try one out. Let me know if you have favorite katas you’d like to see there.

Interview/Hire Great Devs: Part 2

This is the 2nd and last post on hiring great developers. You should probably read Interview/Hire Great Devs: Part 1 if this topic interests you.

Fulfilling Expectations

Remember that the type of person you want to hire is going to expect around 3-4 hours total in the hiring process. If they feel that you don’t perform due diligence with them, their concern will be that you are not doing it with anyone else and that the team will suffer. Of course if the candidate doesn’t seem like a good fit at any point, cut them loose immediately and politely.

If your candidate made it this far, it’s time for…

Phase 3: In-Person Interviewing

Let Your Experts Do The Talking

Evil Nerd Genius
And now we all know the truth about German programmers…
They code in cuff links.

Next, have candidates interview on-site with your existing people for one to two hours (if you don’t want the whole team in there at once divide the time into 20-30 minute blocks). There are pros and cons to both approaches.

Be sure to communicate any overarching goals with your team. If this person is to fill a specific role, let them know so they can analyze the fit. If everyone you hire should be a continuous learner, make that clear. If you want someone who won’t be bored with tedious work, that should also be communicated. There are only two technical guidelines to stress.

Just.

Two.

  1. Long coding assignments should not be performed on a whiteboard.
  2. Long coding assignments should not be performed on a whiteboard.

There are plenty of decent alternatives to making a developer sweat about syntax and handwriting. Bring a laptop to the interview and pair program with them. Send them a coding assignment to complete on their own prior to the interview (time-boxed of course). This applies to anything longer than a fizz buzz-type problem.

Otherwise, let your experts ask whatever questions they believe are important. They are evil geniuses who want to unleash hell on your candidates, AND THEY SHOULD.  These should be some of the people you trust the most to help achieve your goals as an organization, they know the right questions to ask!

Afterward, get a quick thumbs-up count from your team and if it went well…

Perform A Leadership Review

Do an in-person with anyone your team doesn’t dislike. Probably 30 minutes or less. See if your impressions from the online/phone screenings seem to hold up. If you are considering this person for a role that may increase in responsibility, make sure to ask the right questions (including if they are interested in that sort of thing).
At this point, assuming success, proceed to…

The Final Phase: In-Person Closing

Sell, Sell, Sell (Be Obvious And Honest)

Allow 30 minutes to answer their questions and really sell them on the opportunity.

Sale! 50 Percent Off

What you have to offer is great, remember that! This is the company you chose to work for and continue to stick with. Even you you are having a bad day (we are all entitled occasionally) do not sell the opportunity short. Talk about the best parts of your job. Be enthusiastic. After all…

“Nothing great was ever achieved without enthusiasm.”

– Ralph Waldo Emerson

Be completely open and honest. Don’t conceal problems but don’t highlight them as anything other than what they truly are: opportunities to improve. Developers are optimists. We believe in change for the better and want to help it happen. Appeal to our desire to solve problems.

Eat Lunch

The candidate that makes it this far should have a very informal lunch with the team he will be working with so everyone can get a feel for interpersonal relations… it’s very difficult to get a feel for someone who is expecting trick technical/personal questions at any point and is on foreign territory. Lunch offsite is neutral territory and you can learn a lot about a person in that environment.

Lunch is a good habit to get into anyway. I like it.

It goes without saying that if you get to this point then you most likely have a keeper.

Make An Offer

Do this after lunch or do it the following day. You should know if this is the right person for the job or not. You have all the information. If the answer is no, tell your candidate as soon as you know.

The Offering

Negotiation is to be expected. However, in today’s competitive market, get your best offer out on the table as soon as possible.

NEVER try to undercut a programmer/developer/engineer/etc. It will not end well for you. The candidate maybe offended and walk, or worse, join the company and go though all the training and ramping-up and leave for a better opportunity in 6 months.

There are many, many jobs and too many online resources available to compare salaries and other benefits. If you aren’t sure you are being realistic, check out your competition on Glassdoor or general rates on Salary.com. Take this data to the powers that be and make a change if needed.

If there are other great reasons to work for the company, things that give you a competitive edge, highlight them. If you have a great environment for learning (see my posts on the subject here, here, and here) tout it! If you’ve hired well-known or respected developers, point candidates to their online presence on Github, LinkedIn, and Stack Overflow for verification. If you have stock options, great healthcare, or free/discounted products, talk about them.

You get the idea.

Conclusion

Overall, this is pretty similar to the process one employer used when convincing me to move to halfway across the country (for minimal pay increase, no stock options, etc.) and I had plenty of other opportunities. The overall process is proven and is common with really good shops that care about hiring the right people. Remember to always end the process after any stage as quickly and succinctly as possible. Do not get a reputation for wasting people’s time.

Image credits:
minion
.
https://www.flickr.com/photos/liquidnight/