Agile Teams Don’t Always Have Tech Leads, But When They Do…

I queued this post last year when I was a Technical Lead for an outstanding scrum team at HealthEquity. The role was new for me here, although I’ve had leadership roles at several companies over the years.

A Little Background

Our team consisted of six people who had never worked together directly. We not only found a way to meet the requirements of the project, but we also did it on time, on budget, with little overtime, and quite a lot of team fun.

At any rate, the team was very successful, and its success was noticed. It resulted in considerable renown for the team. Credit where it is due: the team’s success belongs to the entire team. My role certainly wasn’t more significant than any other. If anything, it was less important.

I’ve been asked by several people how we did it. My answer, as always, is that we have an awesome team. As a contributing member, I shared some of the load. Maybe my philosophy as a tech lead within the team helped as well. I’d like to think so.

agileTeamsDontAlways

My Tech Lead Philosophy

Top Tier Things To Not Forget

  • Principle #1: Respect the opinions of everyone. We are all professionals.
  • Principle #2: Make other team members’ jobs easier.
  • Principle #3: A tech lead isn’t the only person who has great ideas.

Also Good To Remember

  • Patience. Patience. Patience. Patience. Patience. Patience.
  • Give guidance by asking questions. It isn’t always possible, but it usually is.
  • Free team members to focus on sprint work by being the first point of contact.
    • I choose to address this by sitting at the entrance to our team area.
  • Encourage team members to learn by taking tasks that challenge them.
  • Take sprint tasks that don’t interest other team members when possible.

Probably Best Not To Do This Stuff…

  • Dictating solutions and stifling creativity.
  • Taking all the fun tasks for yourself.
  • Interrupting people unnecessarily.
  • Wheaton’s Law: Don’t Be A (Jerk).

————-

Obviously, I’m not perfect in any of these things. I do find that having the philosophy helps point me in the right direction. I hope it helps you as well.

Interested in technical leadership? Start by leading some coding katas for your team.

As always, write a comment below or hit me up on Twitter with questions or comments. Until next time.

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.

Quotable Quotes: Henry Wadsworth Longfellow

maxresdefault

Today I had the pleasure of reading A Psalm Of Life by Henry Wadsworth Longfellow. The following is the last line:

Let us, then, be up and doing,
With a heart for any fate ;
Still achieving, still pursuing,
Learn to labor and to wait.

Recently, Richie Franklin shared this beautiful psalm by Longfellow with my writer support group. Regretfully, I couldn’t read it when he posted the poem, but I opened it in a browser tab for future perusal. I’m a terrible tab hoarder and will keep as many as 50 open at once.

Time passed, as time does, and soon at least a month had gone by — I know, I’m pathetically busy at times. Today I had a little more time on my hands than usual, and I started closing out ancient tabs by reading them or by deciding they weren’t important and killing them without wasting my time. I’m so glad I was able to be in the right state of mind to read and enjoy this beautiful work.

Much more eloquent than I could even aspire to be, Longfellow reminds us to be present in the present, work hard, be patient, and enjoy the fruits of our labors. Oh, and make the best of everything life has to offer.

Wonderful advice for this era of near-instant gratification.

This post brought to you by the most patient dog I’ve EVER SEEN:

giphyPatientDog

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:
https://www.flickr.com/photos/mbiskoping/
https://www.flickr.com/photos/soulrush/
https://www.flickr.com/photos/liquidnight/

2014 Developer Learning Guide: Part 3

This is the 3rd and final post in my series on continuous developer learning. I recommend you read 2014 Developer Learning Guide Part 1 and Part 2 if you haven’t already.

When I started writing about this subject, I thought I would cover all of the options in one post.

I.

Was.

Wrong.

One of the wonderful things about learning, is that there is a lot to learn about it! I’m in the process of recording a new podcast with a friend of mine and one of our first episodes will iterate just exactly why we believe continuous learning is so important. Stay tuned!

Now, the finale…

In-Person (Larger Groups/Formal Training)

Hackathons/Hack Nights

Hack-er
Um… wrong kind of hack!

This is one that I need to get more involved in. I’ve heard great things about hackathons. I only attended my very first one a couple weeks ago and it was a good experience (all WiFi issues aside).

Additional personal experience is more related to startup work even less formal than these events. There have been a couple of times I’ve tried to put together a quick app or program in a short amount of time using the MVP or “Minimum Viable Product” approach from The Lean Startup. I found that I learned a remarkable amount in a short amount of time.

I learned even more when I did this together with some friends who ranged in skills from entrepreneur to systems admin to programmer to business development.

Code Camps/Large Conferences

I’ve considered writing an entire post about these. There is nothing like being surrounded by others who are looking to improve and be awesome at what we do.

This kind of event can run from half a day to a full week. They tend to be a little heavier on the pocketbook, but you can find lower cost options as well. If you live in an area with a very active tech community, you will probably have many great local options that at least save you on the travel costs.

Conferences really get the creative juices flowing and keep you fired up about your work. Most major tech companies have at least one developer conference per year (Google, Apple, Facebook, Microsoft).

WWDC

Employers with a decent training budget send their developers to 1-2 larger conferences per year (almost never 3+).

I try to mix it up like so:

  • 1-2 out of town conferences. I enjoy travel and this is a nice opportunity to get out of the state for a few nights.
  • 2-3 local conferences. To help keep the budget down.
  • As many code camps as I can reasonably attend.

Why so many? There are a lot of topics I’m interested in and it just so happens that they are all related to my work. This year, I attended an AngularJS conference (ng-conf), an Agile conference (AgileRoots was amazing), Utah Code Camp, and DevFest Family. I’m still planning to attend a large UX conference and a more hard-core software engineering/architecture conference.

I’ve also found it extremely valuable to speak at some of these events. No one learns more than the person who stresses over getting in front of a bunch of smart people to tell them about something!

On-site Training

This type of training is great when you have a team that all needs to get on the same page.  Schedule a trainer to come out to your company on your schedule. I will turn you loose on Google for this one… do a little research and you will find many companies offering this type of service.

My experience here is positive. On-site training sessions can be highly valuable just make sure you get a great trainer. Interview them first or suggest a trial session.

Costs, I’m not super sure on but what is published online is $1000-5000 per session. If you think you will have an ongoing need for this, negotiate a better rate.

Certifications/Degrees

Certifications are highly valuable for IT people although they are not be as well recognized in development circles. I have a former boss who refused to interview candidates with Microsoft’s developer certification on their resume…

MIT
MIT. Yes, I know there’s a TARDIS on it.

Advanced degrees are valuable if you are specializing in certain areas of our field. Machine learning, concurrent programming, and human computer interaction are all excellent examples.

Both certifications and advanced degrees become considerably more valuable if your company is willing to pay for part or all of the tuition. Without that, I would probably avoid them because your return on investment may not be very good.

Conclusion

As you can see, the options for learning run the full gamut of price, time, and commitment. The great news is, even if your company has little or no budget for training, all you need is a couple committed developers to get started with the less expensive (free) types of training. Even better if your company agrees to a budget or commits to learning in other meaningful ways (time/food/support).

I recommend that you seek out employers who understand and value learning. I have and I couldn’t be more glad.

Remember to read 2014 Developer Learning Guide Part 1 and Part 2 if you haven’t already. Follow me on Twitter (@dubmun) for comments about development and other shenanigans.

Image credits:
https://www.flickr.com/photos/anantns/
https://www.flickr.com/photos/notnil/
https://www.flickr.com/photos/bbcamericangirl/