I came across this story of Tim Mackinnon recently. It provided a valuable reminder of the importance of looking at your vision of success and how you structure incentives to realise that vision.
You see, the reason that Tim’s productivity score was zero, was that he never signed up for any stories. Instead he would spend his day pairing with different teammates. With less experienced developers he would patiently let them drive whilst nudging them towards a solution. He would not crowd them or railroad them, but let them take the time to learn whilst carefully crafting moments of insight and learning, often as Socratic questions, what ifs, how elses.
With seniors it was more like co-creating or sparring; bringing different worldviews to bear on a problem, to produce something better than either of us would have thought of on our own. Tim is a heck of a programmer, and you always learn something pairing with him.
Tim wasn’t delivering software; Tim was delivering a team that was delivering software. The entire team became more effective, more productive, more aligned, more idiomatic, more fun, because Tim was in the team.
The Worst Programmer I Know
There is a concept on sports teams of a glue guy. Someone who isn't a star but provides the foundation for teammates to thrive.
Shane Battier was the epitome of a glue guy when he played in the NBA. He wrote of what it took on The Players' Tribune. One part that stuck out was:
One way is by never worrying about looking cool. (Not that I was ever mistaken for cool.)
I knew my value was helping us notch victories however I could. So there were certain things that I did to ensure that my team was always as prepared as possible. For example, I used to ask really basic questions during film room sessions.
“Coach, can we run through that last set one more time?”
“Hold up coach, which direction do I roll out of this pick?”
“Wait coach, which player is supposed to switch here if the point guard drives?”
“Sorry, can you run through that set just one more time?”
Yeah, I was that guy.
Nobody likes that guy. I know that.
But there was always a strategy behind why I did it: I always knew that if I had a certain question about a game plan, there was almost always going to be a younger, less experienced player on the team who had the same question but was too intimidated to speak up. Having that question answered could ultimately pay dividends during a game. If the moment of truth comes and that player is prepared, that’s a plus for our team.
Elite 'Glue Guys' 101 - Shane Battier (The Players' Tribune)
This is difficult to capture in metrics. It's more of an eye test or a gut feeling. The team plays better when they're on the floor. Sometimes it's providing support for less experienced colleagues.
If everyone is trying to be a star then the team won't win. Players take possessions off on defence and are disengaged on offence when the ball isn't in their hands. People will look for credit in a win but avoid responsibility in a loss. They will expend time and energy blaming others instead of looking at how to fix the situation. The team will fall apart. They won't reach their goal.
The incentive of winning a championship provides the opportunity for people to find their role in the collective that will provide the platform for success. The incentive of "I need to put myself in the best position to get a new contract somewhere else" will lead to division and losses. A team full of stars rarely wins. Just ask Kevin Durant, Kyrie Irving and James Harden on their experience on the Brooklyn Nets.
You won't win a title without stars but glue guys need their flowers too.
I was also reminded of the Bill Atkinson -2000 lines of code story in Apple from the early 1980s. The story goes that managers decided to track productivity by asking engineers to fill in a form at the end of each week. In the first week of this change Atkinson was working on QuickDraw, a 2D graphics library that he had wrote.
Bill Atkinson, the author of Quickdraw and the main user interface designer, who was by far the most important Lisa implementer, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.
He recently was working on optimizing Quickdraw's region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code.
He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000.
-2000 Lines Of Code - folklore.org
The idea of using lines of code written as a metric makes sense in a blunt force trauma sort of way. You can use a hammer to open a door when you forget your keys or you could call a locksmith or pick the lock yourself. The first option may be the quickest to route in and may be necessary in some cases. However, you're going to need a new door afterwards.
Incentives can work in a similar manner. Reward people bugs fixed and there is an incentive to write bugs to fix them later. Track lines of code written and the incentive is to write more code, not better code.
This is why the story of Twitter engineers printing out their code for evaluation by Elon Musk and Tesla engineers made no sense. I didn't care much about Elon Musk before that point but when I saw that story, my feelings were summed up perfectly in this post on Mastodon.
Accountability is important and it is important to measure what is and isn't working. Just don't pick the easiest tool you can think of. Pick the right one.
Take the time to think about how I want my team or company to run. What behaviour do I see providing the most value? How can I reward it so other people will be incentivised to copy it? It's not easy and it will require iterations to make it better.
It will require trust. That can mean giving your team some time to experiment with different approaches to the work. It's not efficient at the beginning. But it will pay in the long run.
It won't require bossware or expensive consultants. We know their answers already. Fire people. Hire contractors, preferably from somewhere cheap. Make your service worse for your customers by investing less time and effort into it. Just don't make it so bad that they leave. Buy competitors to lock up the market. If they don't sell, sue them. Cut prices to starve them out. Jack up the prices when they leave the market. If someone offers to buy you, take the money. Don't bother building a business. That's too hard. Take the money and call yourself an entrepreneur. Pretend that you run a business. Write a book.
