This blog post is all about: ruling time out of the equation (because it's very deceptive), what happens when Purpose meets Social Contract, what does Autonomy really mean (and why freedom is a minor part of it), whether 50h is better than 40h (or you simply need to go beyond 60h ...), why over-time has nothing in common with seniority and how do all these things correspond to Engineering Culture.

Part I of the series can be found here.

Where were we? Just about to get into the details of what constitutes a work environment of high achieving where teams truly go above and beyond. And to answer the question - is there a way to eliminate crunch? or maybe it's unavoidable?

OK, let's get rolling.

Role of "time" in the equation

First of all - the knowledge/creative work iiiiis specific. And creating software products is one of the weirdest kinds of creative work - ephemeral, nothing is granted (to work) forever, work is highly incremental, barely repeatable (in majority of cases), standards (of quality) are very intangible and some specific activities (take troubleshooting) are very hard to estimate. Very little in this industry can be done "by force" - if problem is really hard, adding more people or forcing (non-determined) people to spend more time on it is very unlikely to help.

Real obstacles in Software Engineering rarely have (except for trivial ones) known "sizes" and proposed solutions are usually (especially at the first glance) quite hard to assess in terms of overall quality (which one is better, which one is good enough,. etc.) - especially if such an assessment is made by a non-engineer.

Because of all of that, similar work can take X time under certain conditions while if environment changes a bit, that time can either increase or decrease N times. From a bystander's perspective both cases can be indistinguishable.

We all know this, no point to dive further - my point is that:

TIME should be always of secondary importance when it comes to planning, executing, managing engineers' work.

Surprised?

Time is easy to game (by decreasing quality in a hardly noticeable way), expensive to predict (to increase accuracy we need to acknowledge the fact that estimation effort grows exponentially) ... and deadlines DO NOT motivate people. Yes, they serve as a "wake up call" - this is a part of student syndrome - BUT this issue (syndrome) can be easily got rid of in a different way (e.g. by decreasing delivery cadence)!

Replace "time" with ...

To keep the long story short, the secret to have people make wonders together is all about PURPOSE, SOCIAL CONTRACT and AUTONOMY.

A. Purpose

The Purpose is all about "why". It's a goal, target, vision, dream that does truly unite people. It resonates with them, it's aligned with their motivations - to put it simply, they embrace it as theirs and (as a result) it's high on their personal priority list.

Purpose has to be common for all the people in the team. Separate purposes significantly impede the alignment - you ALL need to play in the same team. If we win, we ALL win. If we lose, we ALL lose.

Purpose needs to be inspiring, "real" & believable. It may be freaking hard to achieve, maybe we can't even imagine how to make it happen now (it's not an issue, really), but we need to be certain there's nothing that completely prevents it from happening.

B. Social Contract

... is at least equally important. It's all about what we do to achieve our Purpose. It's the set of ground rules, principles and values we all COMMIT to. It doesn't have to be written down, but it has to be literally respected.

I'm not going to cover it in details here, as I've recently written a full-blown article on this topic solely - you can find it here.

But there's one certain element of Social Contract worth emphasizing here: the boundaries of your personal level of commitment. The boundaries are highly individual, depend on several factors (priorities in life, how high is the Purpose on this list, other commitments, etc.). Some can work only as much as (on average) 40h per week, some are more than enthusiastic to go far beyond. If we're not honest & transparent about this boundary of ours - cracks will appear & our team will not go as one.

C. Autonomy

"Autonomy" means much more than it appears at the first glance: it's not just freedom to make decisions (within boundaries) but also:

• being fully accountable for these decisions ...
• setting realistic and pragmatic plan to reach goals within your area of autonomy
• keeping the necessary level of transparency around this area ...
• maintaining the sufficient level of discipline (based on self-awareness and data) to execute - an urge to do more (to fulfill the Purpose) could cause the agreed standards to deteriorate (unless it's accepted in the Social Contract)

Basically - if you're aligned on the Purpose and respect the common Social Contract, you should be given the sufficient freedom and Autonomy (to do your stuff) - as long as your goals are unambiguously defined, correctly prioritized, well-communicated (risk management!), value-based, measurable and MET.

But how do these help?

Wait, nicely written, but ... how does it help? So we're now driven by the Purpose and we have some Contract and what? No crunch anymore? Or crunch is OK, because it's in the Contract?

Good point, let's clarify.

First of all - it's not a matter of 40h/w. Or 45h/w. Or any number of hours in particular. It's a poor measure. It's not the number of hours that is a problem (it may be a part of the problem ofc). 40h is some sort of a baseline - a number of hours required by the typical job contract. A simplification. A set point in the scale.

But I don't want to measure the engineers' work in hours. Or especially in multitudes of 40hs. Because of the reasons stated in the top of this post. I want it measured in EFFECTs. In met goals they've set themselves (within their area of autonomy).

The goals (that lead us to our Purpose) DO motivate us, while "Stay longer!" does not. Especially if we've expressed these commitments (goals) with our very own mouths - in contrast to enforced deadlines: which are not "OURs", they are "THEIRs" (which is a very dangerous dichotomy).

... reinforced by ...

All of these will work if reinforced by a proper reward & recognition system - a vital part of a Social Contract.

What's fundamental here: the maturity (seniority) & additional personal commitment are two completely different aspects of work, to be rewarded totally separately (they fall under different rewarding schemes).

The former (seniority) is about all measures of engineer craft: "hard" skills, communication, teamwork, reliability, focus on priorities - these are rather constant & we develop them in time (they come with "bruises" and "scars" of our engineering career) - or not (if we don't grow professionally). These should be remunerated with a regular salary - two developers of the same "seniority" should have the same "constant part" of salary (contract-guaranteed), regardless of whether one of them works 40h & the other 60h per week (on average).

The latter (commitment surplus) is more tricky - if someone decides to put additional effort in our shared Purpose, this should also be rewarded BUT this doesn't make such a person more senior. The best methods to appreciate such personal sacrifice are:

• "skin in the game" - shares/options - directly associating company's success with individual's future compensation
• ad-hoc effect-based rewards (one time) - but don't make them fully predictable and don't use any kind of formula / calculation rules as such an approach would move the effect of such reward from appealing to intrinsic motivations to extrinsic ones
• let the particular individual/team (who made additional effort) to "carve out" her/his/their "princedom" - a domain he/she/they can further expand/develop/grow and that will flourish due to her/his/their efforts

Conclusion

There are several equally absurd phenomena in software engineering:

• forcing people to stay long hours for the sole sake of "working long"
• working each day perfectly 8 hours 00 minutes 00 seconds (how the f... do you manage to plan work like that ;P)
• believing that decent software craftsmanship work can be measured in time and that 40h is the "golden mean" for everyone
• estimating if you're not the one who'll do the work
• ignoring the fact that all the (r)evolutions in Software Engineering didn't even scratch the Iron Triangle - they've just added more factors to it (so it's not a triangle anymore ;>)

Avoid these fallacies by cultivating a proper Engineering Culture, oriented around common Purpose (you don't have a Purpose? you're in trouble ...), with Social Contract shaped for your team & conditions, by giving your people a sufficient level of Autonomy (and governing whether it's used with a sufficient skill and focus). Such conditions do not move crunch "borderline", do not make it more bearable or justified - they eliminate the term from the vocabulary.

We do work to meet goals we've agreed upon, within our borders of comfort, knowing how much we can rely on our colleagues. And we move as one.