It’s been 7 months since I’ve written a status report. Of course I have thoughts on alternatives to this obsolete ritual.
Over the past 5 or so years managing software teams, I’ve come to realize that I’m not the manager that some organizations want. That’s ok with me.
I have a different definition than most leaders when I talk about “commitment”.
Wow, it’s been a really long time since I’ve posted anything. Booked has been keeping me very busy, but I’m going to make an attempt to publish more posts this year.
I was out to dinner with some friends the other night. These are guys that I worked with in a past life and some of the best teammates I’ve ever had, so I have a ton of respect for their opinions.
The topic of “rockstar” developers came up – I’m not sure how, but we’re a bunch of software developers so I suppose it was inevitable. The question was around if rockstar developers are good for a team.
Throughout my career I’ve heard leaders bellow from the towers – “[insert name here] is a rockstar! We need to hire more rockstars like [repeated name here].” Obviously, if we had a team of rockstars we’d build incredible applications so quickly and such high quality that our competition could never catch us, right?
Look, I’ve never met a literal rock star, but I’ve watched my fair share of VH1’s Behind the Music. Stars want to be stars. Maybe they don’t even want to be stars, I don’t know, but they seem to gravitate towards being the center of attention. There is an air of arrogance and ego, literally putting themselves ahead of the rest of the band.
Rock bands usually only have one front man – one star. Many frontmen have kept playing over the years, using the same band name but rotating through an assortment of supplemental musicians. To them it’s not about the group – it’s about themselves.
How good would a song be if you had 5 people shredding sick guitar solos at the same time? I mean, I’d watch it, but it would be a disaster and hardly resemble a coherent song. Or you’d have a bunch of people jockeying for the lead role. Here’s what happens when you put a bunch of rockstars on the same team. Don’t actually watch that – it’s not good.
Contrast that with a jazz band. Typically, everyone shines at some point, but while one musician is delivering their solo, the rest of the group is supporting them.
It’s a similar situation on most sports teams. There may be one person that scores most of the points most of the time, but teams rarely win having a single, dominating star. Even the best person on a sports team has to support, coach and mentor other people on the team if they want to succeed as a group. Jordan needed Luc Longley for the whole team to succeed.
I’ve been interviewing and hiring developers for a long time and spoken with more amazingly talented people than I can count. People who could program circles around me. But software development is about so much more than hands-on-the-keyboard development. Software development requires differing opinions, reciprocal coaching, and an ability to check your ego at the door.
A team full of big egos will spend more time debating theoretical performance of an algorithm than actually building a simple solution that solves the problem.
A team of passionate, competent developers who care about getting a working solution in front of customers will naturally select a solution that works. That solution may not be the most technically impressive, but it will solve the problem. And solve it correctly.
While the team of rockstars is fighting with each other about which framework is best for implementing a complex distributed messaging solution in order to save form data, a team of passionate, competent developers will have built an entire application that does everything needed. No more, no less.
A team full of big egos is truly a recipe for a toxic team. These types of people tend to believe that their opinions are always correct. These teams will bicker and argue incessantly over inconsequential details.
But what about a single rockstar? Surely you need that person to carry the rest of the team.
A team with a single rockstar will silence the more reserved people on the team, which kills great ideas before they are ever introduced. In my experience, the rockstars rarely pair program and rarely coach. They rarely write unit tests, let alone practice test driven development (if their initial instincts always right then the tests just slow them down!). They create a mirage of short term speed, hiding the fact quality is slipping and most of the team doesn’t know what’s going on.
A team of passionate, competent developers will support each other. Their ego doesn’t blind them to the fact that they are human and will make mistakes. They will find simple solutions. They will outperform a team of rockstars every time. This is the team I want.
What do you think? Have you worked on a team of “rockstars”? How did it go?
What time will you be home today? It’s a simple question. If you’re like most people you go to work and come home about the same time every day. You should be an expert in estimating when you’ll arrive at home. I bet you cannot predict the time that you’ll get home tonight, though. I bet you’d be even less accurate if I asked you to predict what time you’ll be home six months from now.
Sometimes I feel like this is what we ask software teams to do when we ask them for estimates. Software developers build software every day. We should be able to predict how long it will take to build new software – but we can’t reliably do it! There are ways to improve our estimates, though.
Let’s jump back to the commute example. If your commute is short then you’ll be accurate most of the time. Sometimes you’ll have a meeting that runs late. Maybe it’s Friday and your calendar is clear so you take off early. You can be way off from time to time, but pretty often you’ll be pretty darn accurate. This is why we want to break deliverables into small pieces. Small pieces have less uncertainty.
Things get less predictable the further out you go. Going from a half-mile commute to a mile commute will increase the variability. One mile to twenty miles increases that variability by orders of magnitude. There are simply more unknowns as the size of your commute grows. Traffic, accidents, weather – there are a lot of variables that can affect the actual time.
Big features and deliverables have this same problem. There are simply too many unknowns to be accurate. Undocumented limitations of libraries, complex algorithms, changing requirements, for example. And asking software developers to commit to anything with that level of variance isn’t fair.
But it’s done anyway and leads to all kinds of dysfunctions. Unrealistic estimates based on little knowledge are treated as promises. Broken promises lead to distrust. Distrust leads to infighting, incessant status reporting, and pissed off developers.
So lets stop asking for estimates that are months away. I don’t know even know what time I’ll be home tonight 🙂
Humans are loss-adverse. We place an irrationally high value on losing something over gaining an identical item. So for example, I’d be more upset about losing $10 than the happiness I’d feel by gaining $10. If I buy a meal and hate it, I’ll likely finish it anyway.
In general, people would rather gamble on a 50% chance of losing $1000 rather than giving up $500. Down $50 at the blackjack table? Odds are most people will want to try to win that back rather than take the loss. Curiously, most people would rather accept a guaranteed $500 rather than accept a 50% chance of making $1000. Irrational? Yup, but extremely predictable.
Loss Aversion is the fancy name for the phenomenon. People prefer avoiding losses to acquiring gains, which drives them to become more-risk tolerant in the face of loss. I think it can help explain how we build up and continue to live with technical debt in software development.
Tech debt is a useful metaphor describing the long term consequences inflicted upon a code base by deferring work. Similar to financial debt, we often choose to avoid doing the “right thing” now in favor of a faster path to the end result. The interest accrued by the debt adds up over time and can cause major problems.
There are lots of reasons that software engineers knowingly take on tech debt – deadlines, lack of knowledge or skills, too much work in progress – the list goes on. Sometimes it is unavoidable, sometimes not. Every project has some level of debt, though.
Paying off accumulated technical debt is where I see the ties into loss aversion. The time spent fixing a hastily implemented data access strategy, for example, is time not spent implementing a cool new feature. There is rarely any directly visible customer value delivered by paying off technical debt. In most people’s eyes, this is a loss of time, opportunity, and resources.
We are irrationally risk-tolerant in the face of this loss. Instead of spending $500 to pay off the debt, we’ll flip the coin, let the problems grow, and take the risk of losing $1000. Who knows, maybe the problems won’t surface for a long time. Maybe never. Maybe tomorrow, though.
So how do we fix this if the human mind is hardwired to avoid losses?
Shift the mindset of technical debt. Knowingly taking on technical debt is a loss, not a gain. We are losing the ability to easily respond to future requirements; we are not gaining a new feature in a shorter time frame. And existing tech debt should be seen as a sunk cost – it’s lost, and it’s better to forget the past.
If we accept the current state rather than treating tech debt as an incurred loss we will be less likely to gamble with the possibility of future losses. And hopefully our minds will start to blast warning sirens as we consider taking on new technical debt in the future.
I’ve had the good fortune to have worked on some incredible teams. The best teams I have been a part of each had a very structured and rigorous interview process. It took longer than average to hire new team members, but the tenure of team members was high and our attrition rates were unbelievably low. The teams gelled and that collaboration was reflected in the applications that we built.
Having an interview process like this leads to a lot of interviews over the course of my career – speaking with dozens, maybe hundreds, of potential candidates. I started writing this as a single blog post but it grew too large. Here’s what has worked for me, broken into a short blog series.
Other Interviewing Inspiration
This is a part of a series on Hiring Techies.
Evaluate Potential, Not Accomplishments
I don’t spend a ton of time reading resumes. Depending on the position we’re hiring for, I may look for a few critical skills but I’m mainly looking for themes that tell me that the candidate has a passion for technology. Do you contribute to an open source project? Do you blog? Do you have a history of attending or even speaking at conferences? Show me that technology is an important part of your life.
Don’t get me wrong. I do not want to read about your hobbies or what you do for fun. The fact that you have been the president of your local Pokemon club for 3 years or that you’re and avid White Sox fan is irrelevant. I want to get a sense of what you will bring to the team.
Does the candidate’s resume only highlight individual accomplishments? Are there any bullet points about past team’s successes? How about any experience introducing new technologies or organizing brown bag lunch sessions? I can typically spot a true team player based on how they highlight their successes and what they are proud of.
I want to work with a team of leaders. I want a team of mentors. There are millions of people who can write a web application. There are very few people who can write a web app and help me build a better team.
I’m looking for technological aptitude. A laundry list of impressive technical languages and tools is indeed impressive but it should never be the reason for hiring a candidate. Worse yet, it should never be the reason for passing on an interview opportunity or turning a candidate down. It took me a long time to realize that I don’t need to find someone with that fulfills every item on my wish list.
It’s important to remember that when we hire, we’re hiring a person and not a bag of skills.
Skills and experience are important, of course, but this should support your decision to hire someone rather than be the basis of your decision. This is probably the most frequent mistake I’ve seen folks make. Teams have missed out on great candidates because they were missing some specific tool in their belt. I’ve also seen very smart people hired who end up being culturally destructive.
Every position is different and the skills that are critical for the candidate to be successful in that position will vary. If your domain requires certain skills or experience then, absolutely, screen for that. I would expect this to be the exception rather than the rule, though.
This is a part of a series on Hiring Techies.
Of course, if I’m evaluating a candidate to join my team I want to ensure that they know what they’re talking about. There are many ways to do this. Some people slam a candidate with technical questions for hours. Some people choose to do a whiteboard session solving a problem real time.
Like most, my preference is to go first through a short technical phone screen. If it’s obvious that the candidate has the critical skills we need, I’ll send out a coding challenge to be completed within the next few days. This is a short but non-trivial set of acceptance criteria – something that an average developer can complete in a few hours. Some folks balk at this request. This actually tells me a lot about the candidate and is an immediate red flag. Most candidates are happy to be given an opportunity to show what they can do and submit a solution within a day or two.
At this point the team reviews the submitted solution and decides whether or not to bring the candidate in for an interview. We make it clear that the solution that was crafted will be discussed during the interview.
As programmers, we spend considerably more time reading and discussing code than we do writing it. We need to be able to clearly explain our ideas and be willing to listen to feedback. The discussion I have with a candidate about their submitted solution will tell me more about their technical skills than a barrage of technical questions ever would. We’ll review design decisions, the application structure, SOLID principles and clean code, any technologies or frameworks used, and so on.
I also love reviewing the unit tests that were submitted (or having a discussion regarding the lack of tests). We’ll talk about TDD – why it was or wasn’t applied. It’s always fascinating to hear how the tests influenced the design.
I will very rarely challenge a candidate to solve some problem in person. The reason I don’t like to have the candidate code live is because the interview itself is already high pressure. Most of us have experienced this kind of test when interviewing. I want to see what they do when they’re at their best – not when they have a bunch of strangers staring at them. Programming isn’t about memorization. Anyone can find framework documentation online in seconds. Programming is about problem solving and I want to see how candidates think about problems.
Working code is one of the best ways I’ve found to evaluate a candidates technical skill level.
This is a part of a series on Hiring Techies.
The Team Interview
Who is involved in your interview process? Do a few managers speak to a candidate and then decide whether or not to hire them? There are few things more disruptive than having someone dropped into your team. If the day a new hire comes on board is the first day they meet their team then there is something wrong – not only in your interviewing process but I’d bet that there are probably major trust issues at the organizational level.
I probably spend nearly as much time with my teammates as I do my wife. If I’m spending that much of my life around someone then I need to know that we are (professionally) compatible. It’s not fair to the candidate or the rest of the team if they don’t have a chance to interview each other. I try to give as many people on the team as possible a chance to meet the candidate. After all, the folks on the team are much more qualified to decide who is right for the team than a few distant managers.
This advice goes for hiring individual contributors as well as managers. If your organization is looking externally for to fill a leadership role it’s extremely important for the people who will be reporting to that person to have a chance to interview them. Not only does this help evaluate the candidate from multiple points of view, but it will also establish a rapport early on.
The team must be completely bought in to the decision of who is hired into their team. Assigning a new person to a team can lead to distrust and skepticism. A healthy team knows what they need and will welcome the chance to be involved in the process. And believe me, the candidate will also appreciate being able to meet with as many potential future coworkers as possible.
These interviews can be conducted as a series of 1-on-1 discussions or as a larger group discussion. I’d limit this to at most 3 people at the same time, though. Panel interviews are intense for the candidate. They can also be challenging for the interviewers because inevitably someone will be more outspoken. If you do run a panel interview, practice first. Know who will be asking which questions and make sure that each interviewer has enough time to get through their most important questions. And always account for buffer time needed for the candidate to ask questions.
Once all interviews are complete the decision on who to hire has to be unanimous. If even one person does not agree on the hire then have a team discussion about the concerns. If consensus cannot be reached, pass on the candidate. Again, this shouldn’t be due to some missing technical skill – those can be taught. Find the right person, then worry about getting the right skills in place.
My teams may have missed out on some great people with this approach, but I’m confident that it was the right decision for the team. It is a risk, for sure, but the effect of a bad hire far outweighs it.