Ok, I’m going to share this like no one has ever thought of it before.
The other day, I was giving a lightning talk at Utah Software Craftsmanship about how I run bi-weekly team meetings with Lean Coffee. In short, I highly recommend the practice. It helps keep our meetings quick and on-task. Succinct really.
People seem to like it because we discuss the most important things, and we usually finish early.
If you aren’t allowing your meetings to end on time or early– use this opportunity to rethink your life. You don’t want to sell anyone death-sticks.
Back to the lightning talk. I spoke for about three of my five allotted minutes and opened up the floor for questions. There were a few, but the most interesting question by far (paraphrased) was this:
How do you get people to arrive at desisions when running a meeting with Lean Coffee?
The query took me by surprise.
For a moment, I considered decisions that came out of our meetings. Granted, there weren’t a ton. Often these sessions are more informational. Sometimes they result in questions I don’t have an answer to, so I take to-do items and communicate back to the team later.
However, we did reach decisions. We planned a team party, for example. For these types of situations, I looked for a majority consensus. Often, we found ourselves using a technique I will now dub “Lean Teatime”.
Lean Teatime
Lean Teatime is a subset of Lean Coffee. It can be run either in the middle of a lean coffee session, or completely separate from it. The gist is simple:
Set expectations by making clear the intent of the Lean Tea session (e.g. selecting a venue for a team party).
Make sure everyone has access to Post-It notes and Sharpies (the tools of any agile facilitator).
Set a timer (2-5 minutes) and have the group come up with as many ideas as possible. They will write each thought on an individual Post-It.
Organize similar items into groups and stick them to a desk (or wall for bigger groups).
Give everyone groups/3 dot votes and turn them loose to place dots on the item groups they prefer. Allow one dot per group or multiple, your choice (I prefer 1 per).
Order the results from most votes to least. In the event of a tie for first, vote one more time with the two tied items only.
I like to do a fist of five at this point to see if anyone just hates the thing that ended up on top. In this case, I’ll ask the group to offer mitigation suggestions.
All of this only takes a few minutes and usually has a positive result.
So there you have it. The “genesis” of Lean Teatime. I hope you find it useful.
If you enjoyed the article, hit me up on Twitter or leave a comment below.
If you disliked the article, hit me up on Twitter or leave a comment below.
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.
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.
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. If you’d like to read more on this topic, I wrote a follow-up article in 2017 about Influence vs Authority on Agile Teams.
Interested in technical leadership and not sure where to start? Lead some coding katas for your team.
As always, hit me up on Twitter with questions or comments. Until next time.
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
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.
Long coding assignments should not be performed on a whiteboard.
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.
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.
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.
Hiring great technical people starts and ends with making a great impression on the best people. This means you have to get the best people in the door. Once you have hired some of “the best”, your team will attract more of the same but starting out can be difficult. This post focuses on what to do once you’ve attracted their initial interest. I’m specifically covering interviewing and hiring awesome developers, but much of this is applicable across technical disciplines and other skilled positions.
Initial Phase: Resume/Profile Screening
Know What You Are Looking For
Start the process by knowing what kind of great technical people you are looking for. Are you looking for great young talent that is unafraid of making mistakes? Or tried and tested people who account for exceptions before they arise? Are you looking for teachers or learners (or both)? Do they need certain specific skills or only the great desire and ability to learn, grow, and improve? What is the near, mid, and long term composition of your team?
Many questions should be asked and those questions don’t always have a clear answer. Do you need a consultant or full-time hire to help determine what you are looking for?
Be able to narrow your search quickly based on your must-have criteria and let the rest be discussion points during later phases of the hiring process. Don’t spend more than 5 minutes per resume, LinkedIn profile, or StackOverflow Careers profile weeding out the “No Call” people. It should be obvious because you already know what you are looking for.
I recommend creating two Top 5 lists to assist with knowing what you are looking for. The number of items on the list isn’t the focus. Use 3 or 7 or whatever suits you. It’s the exercise that is important. Write down 5 must-have attributes and 5 must-not-have attributes. Use these lists during initial screening. Pass on anyone with less than 4 must haves or more that 1 must-not-have.
Second Phase: Phone/Online
Personality First
Phone screen or Skype/Hangout for personality and team fit first. I prefer to see people face to face but this isn’t always possible. If you are starting a new team, this phase is even more important. The person you are screening should be someone you can see yourself having an interesting conversation with over lunch. You will be spending a lot of time together building a team. Getting along well is vitally important.
The personality screen doesn’t need to be long. Maybe 15-30 minutes. If it goes well, move on to the next phase without hesitation. If is doesn’t, this is the end of the road for this candidate regardless of their other credentials. This may seem extreme or harsh but honestly it saves your time and effort as well as the candidate’s.
On the flip side of this is the importance of representing the culture and personality of your group as accurately as possible. Talk about your goals and aspirations as a team and as a company. This gives the candidate an opportunity to self-select out of the hiring process as well. You don’t want to hire people who won’t be happy in your environment. Honesty is definitely the best policy.
If you are looking for a leader (or emerging leader) this is also the time to make a early assessment of the candidate’s ability to fill this role. Confidence and charisma matter more here that they might otherwise.
The Learning/Knowing Equation
A technical (and partly cultural) phone/online screen of the people you think might be a good personality fit is the logical next step. The interview should be performed by a trusted technical member of your team. This phase is going to go back to the first section because you must know what you are looking for. Rank candidates based on that knowledge.
That said, don’t hold out for a “unicorn”. For our purposes, a unicorn is a developer who knows your tech stack inside-out, knows your business, and knows what you need to do to solve all your current and future problems. I believe unicorns can be developed if you hire people with the right potential, but they cannot be found and hired. At some point the mask comes off.
With this in mind, your focus should be on the candidate’s ability to learn and on gauging what they already know and their ability to teach it. These traits are and probably always will be vital for a technology employee. Of course you’d like someone with experience in some of your technology. The point here is not to miss out on someone who is a fantastic learner/teacher and doesn’t check all of the other boxes on your checklist.
I describe this second screening as partly cultural for a reason. Your interviewer should be verifying that the candidate not only can learn and adapt quickly, but also if they enjoy learning and adapting quickly. When going through the things they do know, the interviewer should look for something they are personally less familiar with. They then can encourage the candidate to teach it to them. Remember to discover if the candidate is not only capable of teaching but also if they enjoy it. The collaboration component is important.
There are great tools to help with this phase. A good screen-sharing app like GoToMeeting, Skype, or Screen Hero is the best way to do some quick pairing on a simple problem. The problem should be something the candidate may not be wholly familiar with so that their capability of dealing with the unknown can be assessed. That said, this should still be fairly short and sweet. 30-45 minutes tops.
If it seems like this is a good possible fit, personally invite the candidate to visit your facility. If you don’t have a facility, invite them to lunch. If you are looking at remote or relocation hires and the position is permanent, you should arrange transportation/lodging. Under no circumstances should you ever make an offer at this point in the process.
The candidate should have a clear and concise understanding of the next steps at this point. If you are unsure if you should move on to in-person contact, the answer is no.
Part 2 Coming Soon
I will cover the particulars of the types of things you should be doing to “Hire Awesome” in the in person interviews. No specific date, but stay tuned. In the meantime, I’d love to see your thoughts and comments here or on Twitter.
