How can you motivate a programmer to do their best work?
Put them in a strict system, or let them run wild? Implement Scrum, or let them work on whatever they want, whenever they want?
Patrick Fitzsimmons, an independent programmer in Philadelphia, has tried it all. He’s worked on his own, in a small group with Scrum, and in an even bigger group with Trello. He knows when to let a programmer follow their itch, and when to rein them in.
Below is my “How We Get Shit Done (HWGSD)” chat with Patrick. Here are the highlights:
→ Although it can work not to have any system for tasks/goals at first, it won’t work for very long.
→ Scrum can work. But if you overemphasize the story points, your team will either feel demoralized or they’ll overly cushion their estimates to compensate.
→ Kanban/Trello can work. But if you don’t set metrics, your team won’t know if they’re meeting expectations.
→ If a developer can hit creative high notes, it might be worthwhile to give them greater leeway in terms of work style and hours.
What’s your background with software development?
I started in college with some friends, building products. After college, I worked at a startup [HubSpot] for eight years, as we grew from a handful of people to about 600 people. I went from working by myself, to working with a bigger team, and by the end I was leading a team of twelve. Every year, it was basically a new company, since we were growing so fast. We experimented with a lot of systems to see what worked.
What systems did you try along the way?
At the beginning, we had no processes whatsoever. It was just the two founders, and me, and a developer in Egypt. We’d get together a couple times a week and talk about what we wanted to build. Then I’d go off and build it. It was very ad hoc; nothing written down. Sometimes this could lead to switching between projects and thrashing, rather than finishing one thing. Also as we grew, management had less of an idea of what we were working on and when it would be done.
About a year in, we started to get more formal. We had a team of 5 or 10 people at that point, and a VP of Engineering, and we started to use Scrum. At the beginning of the month, we’d plot out what we wanted to do. We’d ascribe points to stories, count the story points, and track how many story points we did each month. We tried to stick to the rules of Scrum: doing daily stand-ups and not changing things mid-stream too much. The VP of Engineering would make graphs of our progress and present them to the management team.
If you didn’t get your stories done, then you were a failure for the month.
And that worked. The only problem was that we relied too much on the story points. We’d get too obsessed, like, if you didn’t get your stories done, then you were a failure for the month. But, if you cushioned your estimates a little bit, then you felt better. That gave us too much of an incentive to cushion.
What happened when you moved on from Scrum?
We moved toward a Kanban style — a little more ad hoc — where we had a Trello board with a list of everything we wanted to do. On their own, the developers would pick things off the Trello board and start working on them. We didn’t have any formal system for planning or measuring the developers’ work. Every week or two, we’d sit with the Product Manager and give him an idea of what was realistic to expect. And that worked pretty well.
But sometimes we’d run into trouble. We didn’t have a standard way for measuring output, so a developer might think “Good, I finished these [Trello] cards in the past couple weeks.” And I might be thinking “Why isn’t he going faster? The other developers are doing much more work.” So I had to use a lot of subjective judgment to see if someone was meeting expectations. If he wasn’t, I had to ask myself: Is he lazy? Is he not a good programmer? Does he need help? Is he not putting in the hours?
If you try to plan those developers — saying, “You need to do these defined tasks” — you can kill that creativity.
Your best developers are the ones who have their own ideas. They go on customer calls, they understand the product, and they know as much about the business as you do. They might have an idea, and over the weekend they build a prototype of some awesome new thing. If you try to plan those developers — saying, “You need to do these defined tasks” — you can kill that creativity.
But it can go the other way too. I’ve had developers who got excited about something and worked on it on the side, and I would think to myself, “This isn’t going to work. They don’t have good product judgment.” So you can’t let them to work on their own thing because it won’t be worthwhile to the company.
How do you communicate to a developer that they’re going astray?
I never had a perfect solution. Once you start disagreeing, it can quickly get personal and they can get defensive. And that’s when you realize you’re in a touchy situation. You don’t want to rule down by fiat and break their soul.
You don’t want to rule down by fiat and break their soul.
So I’d try to say, “Let’s step back and get in front of a screen. Let’s put the problem we’re trying to solve at the top of the screen. Then let’s list all the possible solutions. There was a way I was thinking about it, and a way you were thinking about it… Are there any other ways we weren’t even thinking about?”
Then for each option, you list the pros and cons. Once you do that, sometimes you find out that you disagreed because you each had hidden assumptions. Maybe he had read an article about a new feature that was going to be a game changer, and that’s why he wanted to do it. And once you put it out on paper, you realize he has a good point. Or maybe I opposed it because I’d seen our team try that solution two years ago, and it had been a disaster. So when we put it all out, sometimes the conflict resolves itself.
If that doesn’t work, sometimes I just defer to the person doing the work. Because if they make it work, great. And if they don’t, then they’ll put in the extra hours to fix it.
But sometimes your interests aren’t aligned. For instance, maybe the employee wants to use MongoDB or Node or some new tool because it’s good for their resume. But it’s not good for the company. Then you just have to say, “I know you want to do it this way, but there are 50 other people on the team, and we don’t want chaos, so we have to follow our standards.”
So it sounds like there’s no right answer. You can’t put everyone in a system and you can’t let everyone explore on their own…
There are right answers! And wrong answers. The problem is, there’s no system or science that will tell you what those right answers are. You just need a lot of experience and human judgment.
When someone can hit the high notes like that, they get special leeway.
We had one employee who was very erratic with his hours. But he was also extremely creative. He might work for a couple days, but then he might put in three days of manic hours and come up with an awesome new prototype that no one else could’ve built. When someone can hit the high notes like that, they get special leeway. So if that’s how they work and that’s how they hit their highest creative points, then you have to make some allowances.
Then again, we were hiring a new person who kept coming in late. Because they were in the office so erratically, we couldn’t even train him on our system. He wasn’t paying attention to any of our style guides, or how he was coding, or being in a team, or learning the system. And he wasn’t productive either. So we let him go after a couple weeks because he wasn’t with the program.
You basically have to set out your guidelines. And then, if people have their own styles that don’t conflict, there’s no reason not to let them do it their way. Or, to the extent that there’s a conflict, it’s a negotiation based on how good they are and how much pain it causes you and your team.