How to prevent perverse incentives as a fresh software team lead when I get to hire and build my team?

Question

In my last job, there were a lot of perverse incentives that prevented most team members from really doing their best. There was one co-worker who managed to do nothing since work from home started simply by being 100% available on the Slack chat and claiming to be resolving "production issues." He is actually building a startup for Y Combinator.

Guy is brilliant and highly capable (regularly given large raises), but when management stopped looking, he stopped working. His view was that if your boss doesnt see your effort or your result there is no point in doing the work as there is then no reward.

I wasn't really much better. Management in the job did not give time for fixing bugs in planning periods so no bugs were ever found by the developers. Unless a customer complained, my features were 100% bug free. I also never bothered to learn the business domain because I knew I was going to leave, making knowledge of how the business worked useless to me. I instead just outsourced all that to the business analyst. That probably cut my productivity in half for the company but also let me learn Go on company time. There was also some resume driven development in there.

On the project management side I have friends who have pushed projects doomed to fail simply because they wanted a large dollar figure on their resumes. One of them pushed to clone Zendesk internally because of that.

Ive done a lot of things to benefit myself that screwed my company because it made sense for me to do that. I am wondering if there is a way to structure things to prevent that now that I am in management and get to create my team from scratch.

What should I know about perverse incentives when designing and building my new team?

I am not in favor of coercion.

Answer 1

Think carefully about what you want from team members and align interests and incentives

As far as I can tell, most managers give very little consideration to this on a day to day basis and that lack of consideration can be seen frequently in questions on this site. Many things that managers hate are because they expect employees to make themselves worse off for no gain.

Now, all things being equal, most employees will do the right thing. However, there are plenty of dumb things that press on the scales of that judgment.

We had a question on here about why people do not challenge management mistakes. LetThemFail has an extreme example and all those employees are willing to let the project explode because they found leaving to be cheaper than talking to their bosses.

We had a question about a guy who gets out of doing the unpleasant work by seeming unqualified, letting him focus on work which is rewarded.

We had a question on here about letting bugs flood production so that management recognized the development team for its efforts.

We had a question where a boss got mad about an employee for not wanting "greater challenge." In the answers, there is an excellent parable about a mule. It did not even occur to this manager why his employee may not want the project.

All of these situations are a failure of management to consider the choices available to their employees, the economic value of the choices, and to alter company behavior to make the choices they want make sense for their employees.

Resume driven development and not learning the domain are just acknowledging the inherent lack of long term incentives that software developers assume to exist. Developers generally know that they will be searching for new employment every two years or so, causing them to be very conscious of what is on their resumes. I suspect you learned Go because that is the new hot technology employers want.

Put some conscious thought into the day to day activities of your developers.

If you want unit tests, you can't pester developers to get the features out quickly.

If you want the code review to not be rubber stamping, time needs to be allocated for it.

If you want developers to report bugs they find, they shouldn't be expected to personally fix them on top of their current work.

If you want developers to learn the domain, they need to have a plan for growth within the company. They can't be arriving with a focus on building their resume for the next firm.

Now, you can say that this is a lot of work and you should not need to do this. Most companies do not. That is why most employees at companies are disengaged.

Answer 2

I've done a lot of things to benefit myself that screwed my company because it made sense for me to do that. I am wondering if there is a way to structure things to prevent that now that I am in management and get to create my team from scratch.

1) Don't hire people out for themselves. I'm pretty unapologetic about weeding selfish people out of the interview process. You can spot them in the wording of their resumes. Do their achievements seem impossible for their position? If yes, they might be taking credit for the work of others. Do they dominated the entire conversation space during an interview? If yes, it's unlikely you'll get a word in when you work with them. Can they take feedback in an interview? If not, they're pretty self assured of their own knowledge and will be difficult to work with. Obviously there is no perfect formula and it's all about increasing your confidence in the candidate and decreasing the risk.

2) Create a structure that not only encourages but necessitates team work. Every piece of code that goes into our code base will be touched by at least 2 people and on average close to 3-4 people. There is the code implementer, code reviewer(s) and code tester. It's really hard to be selfish and get some low quality code through the process.

3) Really care about each member of your team. The main strategy I have to managing my team is to really care about them and I mean the whole person. Are they doing okay? Are they taking enough time off? Are they getting a chance to work on things that they want to work on? etc. Because when you take care of the people, the rest of the stuff work themselves out.

Answer 3

Think about what people want and how you can reward them with those things while also getting work done.

For example you learned Go. Great, I've learned stuff on company time because it helped both me and the company. So be supportive of people learning stuff that helps them do their job.

Another way of doing this is to agree time estimates that are generous but reasonable. Factor in bug fixing and time to learn new things. Then if they complete the task well faster than expected they can use the rest of the time to develop their skills, or maybe get a voucher towards a course or something.

Allow them to write up learning and bug fixing as achievements that will be credited at performance reviews. You will have to trust them a little and take their word for it when the result of that work isn't immediately visible in the finished product.

Work is not just you exploiting people for what they know or can produce. It's a two way street, if you look after them and they feel like you are genuinely trying to help them and that putting in the effort gets rewarded most people will respond positively.

Also remember to pay well, there is no substitute for that.

Answer 4

Management in the job did not give time for fixing bugs in planning periods so no bugs were ever found by the developers.

but when management stopped looking, he stopped working.

It's all about managing a team, not building one, that is just a portion. If you don't manage them properly after building the team problems will quickly arise. The managers you described didn't do it properly. Take a management course it's not difficult.

Basically you don't stop looking and you should be aware of what each staff member is doing.