Discussing “Smart and Gets Things Done” Part I: Make A Place Worth Working

In my last post, Technical Manager Library: Smart and Gets Things Done, I recommended Smart and Gets Things Done by Joel Spolsky as a must-read for new technical managers.

The book’s advice boils down to two major themes:

1. Building a team and organization people want to work in.
2. Finding and hiring the right people for that team.

The book discusses these in reverse order, but I’ll go the other way. Adding great people to a dysfunctional environment rarely makes things better.

Before trying to hire anyone new, make sure you’re a place worth working for

The Joel Test

The last chapter contains “The Joel Test” a quick checklist of yes/no questions that indicate the maturity and effectiveness of any team writing software. As he describes it a score of 12 is perfect and anything less than 10 is a red flag.

It is not unheard of to have a candidate straight up ask you these 12 questions. Ideally you won’t fail The Joel Test! But if you’re going to, you probably want to have a good song and dance ready about why. Great responses could be telling the candidate where you are in the process of checking that box, or explaining why that doesn’t apply at your organization. Less great responses are how you believe only cowards need source control, and we put men on the moon with computers half as powerful as a modern toaster so you should be able to write some websites on a ten-year-old laptop.

Here is the Joel Test:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

This list, like much of Joel’s writing, assumes our team works on a single software product. His audience is the team that writes Excel or Pets.com or whatever. Some of these questions really only make sense in that context. My data engineering team doesn’t exactly have one big product we ship. We maintain around 50 distinct systems and services such as API endpoints, ETL jobs, console applications, web frontends for data entry, BI dashboards, machine learning projects, etc. Many of them are internal tools without GUIs not intended for the general public to ever see, which makes hallway usability testing somewhat moot. Some have been chugging along without issue for years and we hardly ever touch the code or have deployments, making build automation arguably a waste of time.

What is important about The Joel Test in my mind, especially knowing I’m technically going to “fail” it, is that I can have an intelligent and transparent conversation with a candidate about it. About why I agree these 12 things are good to aspire towards, why we’re not currently meeting all of them, and why I’m ok with that in some places and in others it keeps me up at night. I want to hire the kind of candidate who would give me The Joel Test, and those people tend to appreciate transparency.

Make sure your organization can check off as many of these boxes as possible, and for those you can’t: you had better have a good reason.

Developer care and feeding

Spoiler alert! Once you hire someone, they’re probably going to start working for you! If everything you sold them on during the interview turns out to be smoke and mirrors, there is really no reason for them not to keep looking. Joel covers a lot of this in the “field guide to developers” chapter.

Any candidate worth hiring likely has options (not to mention any employee worth keeping). You need these people as much, if not more than they need you. One of my primary jobs as a manager is to make working for me more desirable than starting a new job search. You need to be able to articulate everything you do to make that true to candidates, and what you tell them needs to actually be evident once they start.

Minimize day-to-day frustration
A good score on the Joel Test goes a long way. You need your developers’ day-to-day to be as frustration-free as possible. They should be working today on what they expected to be working on yesterday, not a constantly changing priority du jour. They should be writing code, not wasting a bunch of time doing easily automated tasks like builds and deployments or constantly putting out fires that should have been caught by tests. You need to ensure the road is well-paved and free of obstacles so your team can fly down the track in record time. These are ideally the results you’re achieving with a perfect score on the Joel Test.

Provide adequate compensation
Pay and benefits also need to pass muster, but you will be surprised how much wiggle room there is here, especially for more senior engineers who have seen how brown the grass can be elsewhere. Pay must not be insultingly low, but as long as you are somewhere in the ballpark of a reasonable salary for the position, a good environment and day to day experience will go a long way. Ideally someone can spend a full work day making good progress, shut down at quitting time feeling they pulled their weight, and rest easy knowing an off-hour call is extremely unlikely.

Encourage lifelong learning
Things change so rapidly in technology that if you stop moving, you’ll get left behind. I want to hire people who embrace this and intend to keep their skills and knowledge current. To this end, I offer some fringe benefits to my teams with this goal in mind: a subscription to an online learning platform as part of their employment (such as Pluralsight) which they can use on the clock for a percentage of their week, and budget for one major training event per year (such as attending a conference or boot camp) which they do not need to use PTO to attend. These are not massive financial investments, but they also aren’t all that common. Being able to discuss these benefits with new candidates usually puts another check in our “pro” column, and actually being committed to them in the workplace helps your team stay current and just a little less likely to jump ship.

Fixing broken teams

You can pay out the nose, provide 5 star catered meals, generous PTO, and whatever else but if most of the work day involves arguing with teammates, being lectured to by pedants, carrying the weight of incompetent coworkers, and feeling threatened or harassed: it ain’t worth it.

If you have four unhappy people on your team, adding a fifth is not likely the answer. Get your house in order first!

Lead by example
Teams do tend to rot from the head. You need to lead by example and make people feel part of the team. There are managers who feel that just because they have been elevated to this lofty position, they are now “important” and can issue edicts on high to their lowly subordinates. If you are this kind of person, you are the problem with your team. Get help.

There are of course other ways to be a bad manager. Another problem is selecting the right metrics and incentives. I do believe the adage that you cannot manage what you cannot measure, but in knowledge work you have to be extremely careful with what you choose to measure. It is too easy to pick a metric that doesn’t actually lead to the results you want, and most metrics can be easily gamed. For example, I inherited a team with a key metric of ensuring the company invoices were delivered by the 5th of the month. They were meeting this goal, every month, even when it meant shipping incorrect invoices. Do you think our customers were more excited about timely invoice delivery, or billing errors?

Maximize strengths, minimize weaknesses
Sometimes there is trouble in the team itself. You need to know what your team does and how they do it. You need to learn the strengths and weaknesses of everyone on your team. Joel describes teammates who don’t produce a lot of code, but are excellent debuggers who everyone else is always leaning on. You will often find one person may not produce as much individually, but is a multiplier of others either through assistance with a specialization, architecture and design, bug fixing, support, documentation, morale, etc. Amount of code written is not always the best measure of a successful developer.

Once you know them, ensure any strengths are being maximized as well as minimizing any weaknesses. Maybe your best engineer has been promoted to lead and now sits in on the sales calls or requirements sessions, because “that is what the lead does”. But they are also the most socially awkward of the bunch and never ask probing questions or say “no” when it needs to be said. You’ve just found out why the requirements are always incomplete and we never hit our dates! Get them out of there! Don’t be afraid to shake up the status quo. You need to adjust everything to the team you actually have. You will never succeed trying to smash square pegs into round holes. Is the junior dev really the person who always seems to know what the customer needs despite what they said? Are they the one always asking a million questions in the project kickoff? Minimize the weaknesses, maximize the strengths. You can right size job descriptions and salaries as needed. The point is: don’t dream up the perfect team then hope to find people that fit that. Hire people who are smart and get things done, and figure out how to turn those people into the perfect team.

Addition by subtraction: don’t be afraid to let people go
Sometimes people just aren’t the right fit, and these people have to go. I believe you should always try to give everyone a chance to grow, especially if they are already on the team, but sometimes it just doesn’t take. You can’t coach someone who doesn’t want to be coached. You can’t help someone fix a problem they can’t admit they have. Bad performers can ruin an entire team. They are writing the bugs that crash your system at 2am and wake up the seniors. They are rubber stamping everyone’s code reviews and not helping catch problems. Be extremely direct with the feedback about what is not going well, coach them on how to improve, but if that improvement doesn’t happen you need to let them go.

Many worry that letting people go will negatively impact team morale, and I can tell you that has never been true any time I have had to do it. In fact most often everyone else finally starts saying out loud what everyone had kind of suspected all along: things are better with them gone. It certainly should NOT be your go-to move for team improvement, but sometimes it just is the best solution. It also sends a clear message to everyone else on the team. We take this seriously, we have high standards, and we will not tolerate people who aren’t helping us reach them. If you are letting underperforming people go, truly because of their performance, I have found it does not make others fearful for their jobs. The rest of the team usually appreciates that this problem has been solved.

Address toxicity immediately
One exception is harassment. If someone on your team is creating a hostile work environment, fire them immediately. As quickly as you possibly can. This does not just include the obvious problems like sexual harassment or discrimination, but also things like using personal insults or threats (even as “a joke”) when giving feedback, being overly argumentative, yelling at people, undermining others, or any other behavior that makes other people not feel safe or valued. This person is toxic and they have to go.

Closing Thoughts

Building a team worth working for is the first step to attracting and retaining great talent. In my next post, I’ll dive into the second major theme of Smart and Gets Things Done: how to find and hire the best people for your team.