Motivation is NaN (Not a Number)

Episode 12

What motivates your programmers? In this episode, Marcus looks at the various factors that impact motivation, and why one of his engineers just wasn’t grooving on a project. Chances are you’ve got teammates who feel the same way. Guess what? It’s not that they’re lacking in motivation, it’s that they’re no longer motivated by what’s being given to them.

 

Show Notes

• People ARE motivated, that’s why you hired them. They lose some of that when they aren’t given new challenges.
• Is it wise to allow risks just so you can keep people motivated?
• Problem solving is exciting, and engineers want to do exciting things.

Links

• Sponsor: www.GitPrime.com

Transcript

Announcer: Welcome to the Programming Leadership Podcast, where we help great coders become skilled leaders and build happy, high performing software teams.

 

Marcus: Hi, I’m Marcus. Welcome to the show. Today I want to talk about motivation, a complicated topic, an emotional topic and I know that because this is my seventh take at this podcast, trying to make sense of it in a way that’s coherent and I finally think after seven attempts, maybe I’m just going to keep this really short and sweet for you. All right? What motivates your programmers? Do you ever wonder that? I did. They’re already motivated. It is not a quantity problem. That is, if you look at your programmers and think they’re not motivated, that’s like saying the glass is empty. That’s actually not the case. These people came to you motivated the first day you hired them, guaranteed, or you wouldn’t have hired them. Before they came to you, they had spent years or decades practicing, learning, going to college, reading books, reading Hacker News, studying, doing side projects.

 

They had spent decades honing their craft. They are absolutely motivated. Software engineers love writing programs and they love the work they’re doing. I don’t know any of them who would say, “Well, you know, my real love is accounting, but I fell into software and so now I’m here.” I just don’t know those people. They got out of it. Software engineering happens to be a field that attracts people naturally who are motivated, who want to and have developed good working relationships with their compiler, who then have invested years in school, in books, in training, in learning, in practice. And now they come to you and they are so excited. And my guess is if we look at LinkedIn’s 2017 study about turnover, we can see that when they came to you, they were coming to you hoping to do big things. They were coming to you hoping to make a big difference, to have a big challenge.

 

And yet, we oftentimes take these people, who want a big challenge, who hope that they can bring their whole brain and their whole heart to work and they’re so motivated, and oftentimes we put them in a system that demotivates them. Okay? And what it does, I think, is it does not decrease the quantity of their motivation because I don’t think it’s a quantity problem. I think it shifts their motivation.

 

Let me pause and thank today’s sponsor, GitPrime. GitPrime’s platform allows you unprecedented visibility into your development team. For too many years I’ve had to guess at the status of projects without any real data to make decisions from. Oh, I have tried everything. Story points, velocity, burn down charts, burn up charts, you name it, I’ve tried it. Worse yet, I’ve made the mistake of promising my boss when something would be done only to be disappointed. When I dug into things with my team, I was always surprised between what the charts show and what’s actually happening. Now, it’s not like anyone’s messing up, but things are happening that I have no visibility of, which meant I couldn’t even discuss it with my team. GitPrime changed all that. With GitPrime, you can leverage git-level analytics. That’s where the real work is happening. It provides deep insights to help you have better conversations with your engineers and your whole team. See things better, build things faster. Learn more and sign up for a demo at GitPrime.com.

 

I can remember having team members who appeared less motivated about the work in front of them and more motivated about rewriting something that was almost outside of their area of work or building something completely new. They were like, “Oh, I think we should be over here.” Or they talked about a new technology. “We should be using React and why are we still using Angular?” They were motivated and excited. It just wasn’t directed at the problem, so I started to wonder. Why.? What is it about these problems, this coding that I’ve given them that is so boring? Like let’s just call it a spade. Why is it so boring?

 

And I remember one time, this programmer was really honest with me. I had gotten a big request from a client. I had spent a day or two, maybe a week whiteboarding in my office, drawing UML diagrams. This is software design and architecture, I thought, planning. This is the work that tech leads and architects and CTOs should be doing. And then we get the plan, get the design, we decompose it into small features and small parts and then we give it to the team to implement.

 

And this one programmer just wasn’t really grooving, like normally on some stuff, he was really motivated. But I thought, oh, he has low motivation. Again, I’m thinking wrongly in terms of quantity. And yet he was always bringing me new ideas and I said, “Why is the work in front of you so boring?” And he said, “You took the challenge out. I get that this was a big project and you’re excited and when you got it, it was unknown and nebulous and confusing and complex. But what you did is you boiled all that fun out of it. You took the challenge out of it and you designed something that then all you need is 10 lesser skilled programmers to be able to implement it. That’s not very exciting.” He says, “For example, I’m working on login. Do you know how many login screens I’ve done?”

 

And I said, “Yeah, but aren’t you excited about the big vision?” And he said, “You know, truthfully, this isn’t going to save the world. We’re not feeding children in Africa or doing clean water work. So it’s very hard to get behind the mission. So no, to me, you have put me in a system where all you want me to do is look at one story at a time. You say, ‘Don’t have work in progress. Pick a story, do it.’ And the story that I got handed, all the stories look frankly like LEGO pieces, they’re equally dull, round blocks. It’s putting them together that’s interesting. It’s the final vision that’s interesting. And in some ways it’s the design. It’s the problem solving, the work itself that is so exciting. And yet now all that’s gone, it feels like there’s just a bunch of tasks.”

 

If this sounds familiar, it might be a problem where you work, that is you or your product managers or the product group or some other group before it hits engineering might be doing so much design, and thinking, and problem solving that your engineering group has simply become implementers. Typists. Like you’re manufacturing software. The requirements come in. It’s almost like you’re a machinist instead of solving problems about how to build something.

 

For example, let’s take a machinery example. Imagine you were a welder, and imagine you were asked by a client, you have all this welding equipment. Imagine that somebody says, “I’d like you to build a trailer.” Well great, you’re going to draw up the plans, you’re going to do some CAD work. You’re going to hit the requirements for cost and size and length and number of axles and all the other stuff, and then you’re going to go out and you’re going to plan your work and you’re going to build and fabricate this trailer. You’re going to weld it, you’re going to attach the sides, the wheels. To you it’s a whole thing and, and it’s a wonderful thing. It’s a problem. Build a trailer. Maybe you’ve built a lot of them, so you kind of have some templates, but you still start with almost nothing and problem solve and turn, decompose, break it down, sequence the steps, and at the end, boom. What do you have? You have a trailer.

 

You could imagine, though, a trailer manufacturing company would have a department that drew the plans, a department that ordered the materials, an assembly line that sequenced the work, that moved it through, along a series of low skilled laborers who knew how to weld or attach a wheel or tighten a bolt and then they would do their job and none of those people may appear to be very motivated. This is sort of the old Taylorism industrial revolution approach to how things get built. It’s manufacturing, and it’s the assembly line, and it works really well when you have a lot of unskilled or low skilled labor.

 

And you need something that’s incredibly repeatable, like, of course, Henry Ford’s cars, right? They went from what, half a day or a day assembly time on a car down to a an hour or maybe 90 minutes. That sounds pretty incredible, but of course they were always building the same thing, and you know that there’s very little problem solving in that. The problems got solved by the industrial designer, the sequencing and the decomposition of the problem. Creating all the stations, figuring out the most effective way things should work and really treating people like cogs. And so in this case they might’ve gotten some motivation out of the work itself, but my guess is is that your programmers might be feeling a little bit trapped on an assembly line if they’re exhibiting low motivation for the work you have for them to do. Now I’d like to propose that this is an area you could … Woo, boy, I’m going to really propose something crazy.

 

Maybe you could talk about it with them. Maybe you could look at the whole way that a big crazy idea comes from a client or a business unit and you could say, “Where does the design, where does the complexity get drained out of it? Where does it turn into tasks?” Because it almost always turns into tasks, stories before it gets to your engineering group because we end up with all these steps. Now I’m not saying that you should include your engineers in everything. I’m not saying we need to throw out your product management group, but I am saying that your programmers want to work on bigger things, and my guess is if you asked them, some of them at least might feel like this. The tasks that were given feel very much like tasks. Like I’ve heard programmers tell me, “It feels like we’re on a gerbil wheel.” Right?

 

There’s just a never ending litany of tasks and things to do. So why wouldn’t they quit? Why would they do them at all if it’s this awful? Have you ever noticed that programmers are always bringing new technologies to you? They’re always bringing new databases and architectures and languages and platforms and tools. They’ve got all this other stuff and they want to apply it. This is how they bring motivation to the work they have. Unfortunately, a lot of it is not necessary and so it’s not welcome by you, by the management, by the business unit, even by the customer.

 

In fact, I’ve had so many customers tell me, “Why did you guys change that? It was working fine before and now it works different and it seems like it’s different just for the sake of being different.” And I attribute that to programmers and designers who get a little bit bored with their work and so they say, “You know what will make it exciting for me? You know what will keep me here longer? You know what will keep me from pulling my hair out is if I can find a way to be motivated about this work and what would motivate me is if I can learn something new, if I can try something out, if I can apply something that I’ve been tinkering with at home that is exciting to me.”

 

And when that happens, unfortunately it often times doesn’t really align with the business goals, doesn’t align with the business needs. And it makes software more complicated, more expensive, harder to maintain, harder to deploy, all that other stuff. And at the end of the day, customers are scratching their heads going, “Why was this change necessary?” And they start to mistrust us. And we as managers feel caught in the middle. Don’t get me wrong. I remember there was a programmer on my team who really struggled to be interested in the work that was given to him, but was on the side really excited by this database called Neo4j, a graph database.

 

And he kept pitching me, “Why aren’t we using Neo4j? I want to use it.” I’d say, “No one else gets it. We don’t need it. We’re doing relational database problems. It’s fine.” Finally, finally I let him do this project with Neo4j, and he knocked it out of the park. He killed it, like it was great. He was fast and motivated, showed up early. He was so excited and I was like, “Boy, this, this guy’s like his first day of work again.” You know, he’s so jazzed. And of course when the client got it and my boss got it, other people started to look at the build time was longer. And frankly there were lots of hard questions. “Why did you switch technology?” And as the manager, I had to give a reason. And you know, the reason I could not give was, it was not safe for me to say, “Because Bob wanted to do it that way.”

 

I had to then invent reasons. And I hope that you don’t have to do this, but I bet you do. You have to justify the reasons why technology changes happen, sometimes only so that we keep our people motivated. After all, how many login screens can we create? How many database reports can we imagine people are going to create and still be interested? And so it’s almost like we turn a blind eye to that bad business decision, to use a different technology that no one else on the team uses or to make a change just for change sake. And we think, well, you know what, if we don’t give those programmers something, they’re going to leave. And if they leave, then we’re double screwed. So we give them little bites here and there and we cover it up with rationalizations about technology benefits.

 

But I’ll be honest, I think 99% of the time that happens, it’s not that the programmers are trying to solve a business problem, it’s that the stuff we give them is really dull. And I think it’s kind of sad because programming is exciting work. No, no, no. Let me scratch that. Typing is dull. Programming at times is dull. Problem solving is exciting. Problem solving is what we all want to do. So I’d like to challenge you to take time and talk with your team about their motivation. Do not make this mistake and ask, “What motivates you?” Instead assume that they are highly motivated human beings because I think that’s absolutely true. That’s the mindset I want you to adopt. And I want you to start asking questions like, “What gets in the way of you doing your best work? What gets in the way of you being excited? Where are you excited? What excites you right now?”

 

I don’t want you to ask these questions so you know what to give them. I think that would be wrong. I want you to ask these questions so you can see the places in the system that might be robbing them of problem solving motivation. I think that everyone is motivated to solve problems. I do think that many systems pre-solve the problems, making the work uninteresting, so trying to understand A, is that happening and B, where is it happening and why is it happening and how could you leverage more of your programmers’ expertise even across the organizations to be able to participate maybe in problem solving in new ways?

 

You might actually even find that designers are struggling with this. The product managers are struggling with this, that there is just a general feeling of being on an assembly line and if that’s true, I think the thing to do is to identify where it’s happening, identify why it’s happening and start to collaboratively understand the impact so that we can make a change to the system. Understanding what motivates people is pretty simple. They want to do great work, do a good job and stay interested. They want to solve big problems. You’re fooling yourself if you believe all they want to do is sit at their desks and code and not think, because at the end of the day, they want to make a difference, and I want you to create a system where they’re free to do that. All right. This has been Marcus. You can find me at Marcus@MarcusBlankenship.com, if you’d like to email me. And we’ll be back next week with the Programming Leadership Podcast.

 

Announcer: Thank you for listening to programming leadership. You can keep up with the latest on the podcast at www.ProgrammingLeadership.com and on iTunes, Spotify, GooglePlay, or wherever fine podcasts are distributed. Thanks again for listening and we’ll see you next time.