In this blog post you'll read about ... where does the motivation come from, why direct pushing doesn't motivate us (for real), what is "the runway method", whether it's OK to stretch beyond 40h/week (50h? 60h?), why software development is like surgery and what's the difference between good & bad praise.

Oceans of ink have been spent on all the articles on efficiency & productivity in the software development industry. As the technical aspects of gaining more velocity are not only tricky but also require a high level of expertise, many seek for more comprehensible & readily applicable methods related to soft dimensions of this topic: engineers' motivation & so-called "engagement".

Unfortunately, some tend to either apply concepts taken straight from the 80s or completely ignore the meaningful differences between building software and more traditional types of handiwork. The most typical mistakes I've seen were related to:

• belief that motivation can be "created" (invoked? summoned?)
• not seeing the difference between intrinsic & extrinsic types of motivation
• mistaking cheap pep talk with real empowerment (e.g. via proper feedback)
• over-exploiting individuals' motivation by direct pushing
• lack of understanding what makes people highly performant mid- & long-term
• ignoring the negative effects of regular (treated as a normal thing) crunch time - not only regarding people, but also products they build

As I've already stated above, there are tons of materials on that available on the web, so I find it pointless to go through all of these issues one-by-one. However, there are specific points I find worth emphasizing & that's what I'd like to cover in this blog post.

Motivation is in us already

It's NOT possible to create a particular motivation in a person (out of thin air). That is a well-known fact. What you can do (in case of a specific individual) is to:

• help to find out one's motivations (e.g., by inspiring, giving an example, providing some proving ground) that (s)he already has (even unconsciously)
• wake/re-energize one's motivations (e.g. by providing support, feedback, eliminating environmental constraints, helping to set a meaningful & well-aligned goal)

The point here is that imposing someone motivations that are not natural for her/him will not work in case of intrinsic motivations - regardless of how hard/long you try. If someone DGAF about charity, building good products or coaching people - you cannot make her/him start caring. (S)he may change (given some time & based on new experiences), but this can't work if forced or just peppered with money (or any other kind of extrinsic motivator ...).

Direct pushing doesn't help motivation

It's a really bad idea to attempt increasing (even short-term) someone's productivity (or rather "commitment") by direct pushing ("work harder!", "you can do more!", "I know you're able to squish even more out of yourself!") in software development (and many other industries). Direct pushing doesn't have anything in common with motivation, it's a careless attempt of exploitation.

What works FAAAAR better? (for all the parties involved)
The runway method

How does it work?

Talk to the individual, learn her/his motivations (help her/him learn them first if uncertain) & make it a win-win game by aligning the goals. Carve out (in work environment) conditions that will make this person achieve her/his goals in a way that is beneficial for whole team/company, but let this person set the border of commitment (e.g. overtime, responsibilities taken) her/himself.

This way you provide a runway, but it's up to the person to take off. Sky is the limit.

Example(s)? Sure.
Some people want ...

1. ... more independence - assign them "mission" (with clear success criteria) / beachhead to start "an assault" from
2. ... an intellectual challenge - provide them something to let them sweat
3. ... more visibility in the professional community (higher public status) - allow them to contribute in an area they prefer (that's also beneficial from team/company perspective) - employer branding? contacts with universities, user groups? developer advocating? leading OSS projects that have originated within your company?
4. ... to build team/unit - let them do the recruitment themselves, end-to-end (if they are indeed up for the challenge)

"Contract" of such agreement should be unambiguous - the individual is provided with specific conditions to fulfill particular goal(s). However, (important!) don't quantify the goal yourself - it works far better if it's this person's statement & commitment, otherwise, how would you tell whether this was imposed ("I knew it will not happen ...") or truly committed to? Challenge, encourage, question, clarify - but within reason.

Direct pushing with misaligned motivations and/or no "runway" (aka no REAL skin in the game) has very predictable outcomes - a manager surprised that his subordinates are reluctant to work their asses for his promotion, start-up founder not able to understand that due to total assymetry of the positions she has completely different measures of success than people she employs (who bet their future careers on entirely different factors ...).

Is 40h per week a barrier we should not cross?

I've worked in many different kinds of work environments. Starting with relaxed 8h per day ("9-17, kkthnxbaibai") & ending with consistent 16h every day for months, with people crossing the border of 24h of continuous work & regular work scheduled on Sunday morning. Based on all these experiences:

• I can't emphasize enough the importance of "slack time" - if individual's "utilization" exceeds her/his acceptable level, work satisfaction & creativity disappear almost instantly! Their place gets quickly taken by increased error-proneness & gradual burn-out - ultimate killer of any motivation ...
• the idea of (individual) "acceptable level" is very important - everyone should personally decide how much effort (& time, & energy) (s)he can commit to particular endeavor; this is of course affected by alignment with (real) motivations & all other kinds of incentives, but should NOT be affected directly (by direct pressure) - let people decide for themselves!

These points are essential to assure people that the key to work-life balance (& personal happiness) is entirely in their hands. And happy people = high performing people (a condition that is necessary, but not necessarily sufficient).

So, in short words: I do expect people to work effectively for as long as it's written in their contracts (e.g. 40h per week). If "runway" we set up together is appealing enough for them, I do NOT mind them to work longer/harder/with more personal sacrifice. But it's THEIR autonomous, non-forced decision - they've got the "runway" (to execute their opportunities), now it's up to them to decide how far their want to go in making use of it.

Manipulative? Yes, a bit, but in a visible & transparent way for all parties (so I don't have any ethical dilemmas about that).

Wait, so 50h or 60h weekly is OK if it's individual's decision?

YES.

We're adult people & I don't want to make career or personal/work life balance decisions for others.

But I'll be frank - I strongly advise AGAINST working more than 40-45h per week. Even if you e.g. love coding, feel free to code as much as you like, but you'll do wisely by spending "the time surplus" (over 40-45h) on some side activities: pet projects, learning new technologies, building your personal brand in the engineering community (by contributing to OSS, blogging or sending CFP to various conferences).

Aim for fun, do something that helps you recharge, unleash your creativity, "reset" your mind to refresh the perspective, hedge your core skillset with some additional knowledge. Human's reservoir of passion is not endless, it's rather something that needs careful cultivation - you can't just reap the fruit w/o thinking about future.

"One more screen! One more function!"

Sofware seen from spreadsheet perspective can be mistakenly perceived as a result of a process similar to traditional engineering. Work is being divided into comparable chunks (for the sake of estimation) that are getting delivered one-by-one, almost like they are brought in on the conveyor belt. So why not to tweak with the "engine" of this conveyor belt? Why not raise the voltage? :)

(Un?)fortunately, this will not work (well) - it's a mirage, a dangerous deception.

If you really want to compare software development (except truly basic, highly standardized, low-quality stuff that gets produced in high-turnover outsourcing centers) to something, try surgery - or even neurosurgery.

Why so?

1. mistakes in software can not only have costly consequences (corrupt data, security leaks, outages) but also can be very hard to troubleshoot - engineers need focus (but not constant reminders to "focus more!").
2. bad decisions (e.g. made under the pressure of time) can have long-term consequences that are very hard to get rid off - e.g. unfortunate technical debt can make adding a new "screen" twice as effort-costly as it was before. So excessive pressure doesn't help.
3. multiple levels of abstractions (these pile up quickly) can have so many (& such tricky) interdependencies that they become too hard to grok through. Hence limit distractions & context switching.
4. preserving solution-specific knowledge is very hard, hastily created modules with volatile knowledge become knots of accidental complexity everyone just walks around (yes, henceforth causing even more trouble). That's why illusory save of time may have a near-instant hidden cost.

Seriously, answer me one question: would you motivate a surgeon by pep talking him with such statements like "one more surgery!", "you can do it, slice harder!", "I believe in you, you are able to transplant liver in half of that time!"?

Yea, exactly.

Be careful about what you praise/rebuke

Let's consider a hypothetical story:

Late evening. The engineer who's already after work at her home, realizes some critical implication of recently introduced change that will affect the production environment's stability. The problem may occur today, tomorrow, maybe in one week - she's not sure, but it seems that catastrophe is inevitable. Engineer opens her laptop, switches to proper branch & hotfixes the problematic code. The world has been saved. Again. For now.

This person certainly deserves the praise. She has proactively helped the company to avoid an impending problem, in her own private time.

But it makes a hell of a difference whether you praise her for

• working on the evening, after hours ...
• ... or on her proactiveness & taking the ownership to conduct the necessary fix

In the first case, even if you had good intentions, you're mistakenly putting a positive emphasis on something that can be in many cases unnecessary, may hide real problems and in the end (in some other circumstances) may have negligible positive effects (but OTOH can be "gamed" & exploited).

In the second case, you focus on the actual "value added" (benefit) and attitude that is truly worth promoting - problem has been avoided due to high awareness, professionalism & proactive action. Yes, working late (& hence some personal sacrifice) DID happen, but this was just a mean to achieve the important outcome.

Does it make that much of a difference? Yes, it does as feedback (both positive & negative) plays a very important role in shaping the culture - passed message should be crystal clear to get the desired effect.