“Time is our most finite asset, and leverage – the value we produce per unit of time – allows us to direct our time toward what matters most”. This is one of the core ideas of the book “The Effective Engineer” by Edmund Lau.

Now, doesn’t that sound a lot like Andy Grove in his “High Output Management” book? Indeed, it does, and the book makes a couple of references to Grove. But its obviously different in its focus on engineering. So let’s see what’s inside.

The right mindset

Before diving into actual things to do, the book talks about the right mindset. And surely, this is not limited to engineering at all. Lau introduces the often quoted concept of fixed mindsets versus growth mindsets, whereas people who think in a fixed mindset tend to believe that their skills and qualities are set in stone and pre-determined, they avoid challenges, easily give up on obstacles and live in fear of feedback, while people thinking in a growth mindset believe they can nurture and grow their skills, they embrace challenges, see failures as opportunities to learn and find inspiration in the success of others.

Now, needless to say, being an effective engineer and focusing on high-leverage activities is based on adopting a growth mindset. He advises: “Own your story”.

So let’s get to the meat of it: What are the high-leverage activities Lau is talking about?

1. Optimize for learning

Given a growth mindset, “learning” is an obvious high leverage activity - as learning will allow your skills to grow, yielding a high long-term dividend on everything you will do in the future.

There are a few practical tips for how to increase your rate of learning as an engineer:

• Look for a job and environment that makes learning easy (good onboarding programs, mentoring, culture of curiosity, lightweight approval processes)
• Surround yourself with people who are smarter, or more talented, or more creative than you
• Work on tasks with a reasonable degree of autonomy
• Read books
• Build a strong network of relationships (with people who you can eventually learn from)
• Tinker on side projects

Especially for the “side projects”, learning days or “20% time”, Lau has a few extra tipps on what you would want to do:

• Study code and abstractions written by the best engineers at your company
• Study any technical/educational materials available to you at your workplace
• Master the programming languages you are using
• Send your code to the harshest critics for review
• Enroll in classes in areas you want to improve
• Participate in architecture and design discussions
• Jump fearlessly into the code of other People
• And work on a wide range of diverse projects

And there’s a bonus waiting for people who truly adopt a learning mindset:

“Research in positive psychology shows that continual learning is inextricably linked with increased happiness”

2. Prioritize regularly

It seems pretty obvious that it’s a high-leverage activity to chose the right things to work on. But Lau points out, that many people cannot easily summon the necessary “activation energy” to sit down regularly and shift your priorities to the ones with the highest leverage. It’s just a very energy consuming activity, which on top doesn’t make one feel like having accomplished anything.

Here’s another few practical tips on setting priorities:

• Hake it a habit to continuously shift your top priorities towards the ones with the highest leverage (e.g. by adopting any of the “getting things done” schemes)
• Learn to say no to things that are not high priority
• Don’t let the life’s daily interruptions dictate your schedule
• Focus on the “important non-urgent” items (as they usually are neglected most)
• Invest time into skill development and learning
• Protect your “flow state” (time without any interruptions)
• Fight procrastination (by e.g. creating “if-then” lists of small tasks that you can pick of “if you have 15 spare minutes”)

Engineering specific tipps for effectiveness

While the first section applies to pretty much any profession, the second part gets more into the specifics of software engineering. Here’s what Lau recommends for high-leverage:

Invest in Iteration speed

Shortening the debugging and testing loops is probably the single most high-leverage activity to speed up development.

Lau observes a problem especially in bigger companies:

“However, as most companies grow, they slow down too much because they’re more afraid of making mistakes than they are of losing opportunities by moving too slowly.”

Investments into iteration speed come in different colors. Basis of every improvement is a proper observation on what the actually bottleneck is. Technical bottlenecks can be e.g. tackled with automation (“if you have to do something manually twice, then write a tool for the third time”). Some are non-technical, e.g. the dependency on other people, cross-team dependencies, or approvals from decision-makers. Find the bottlenecks, and then improve them.

Measure what you want to improve

“If you can’t measure it, you can’t improve it” the old saying of Peter Drucker goes. But selecting what to measure is as important as the measurement itself. So what makes a good metric?

• It helps to focus on the right things
• When visualized over time, good metrics help to make progress (or backlashes) visible
• Good metrics can be a driver for progress and a source of motivation
• A good metric lets you measure your effectiveness over time and allows comparisons to other tasks in terms of leverage

That said, it’s extremely difficult to find good metrics. Sometimes we tend to pick easy-to-measure or totally irrelevant metrics. Sometimes they are not actionable, or do not properly respond to what is being done. Or are just so volatile, or fluctuating that they don’t help. They might be subject to external effects, or just loosely correlated instead of showing a causal effect.

I can strongly recommend the book “How to measure anything” on the topic of metrics and measurements.

Validate ideas early and often

I sometimes hear people say that “the projects is going to take the time it takes”, so there’s no point in spending extra effort to collect data or validate the path – that would just “drag down the project even further”. Now, Lau clearly takes the opposite stance: he says that we should continously look out for opportunities to spend a little extra effort to get the validation that we’re still on the right path.

That’s especially true for bigger projects, or projects with major risks: we should address these risks early on, do early integration tests, seek feedback on software designs, design APIs first, and commit code early and often. There are a lot of parallels to product development in a wider sense, where usually there are many unknowns that product teams would want to trial and test as early as possible in the process (ideally before the first line of software is written).

Improve your estimation skills

This might be a more controversial section, as the software community also has a big “no estimations” camp. Lau says: “A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets.”

He gives a few concrete tips for better estimates:

• Think of estimates as probability distributions (I like that a lot) - “Instead of telling a stakeholder that we’ll finish a feature in 6 weeks, tell them that there’s a 50% chance we can deliver in 4 weeks, and a 90% chance that we can deliver in 8 weeks”
• Decompose projects into smaller tasks to estimate them
• Estimate based on how long the task will take, not on how far away the external deadline is
• Let the person who does the actual work do the estimate
• Beware of the anchoring bias
• Use multiple approaches to estimate the same task
• Beware of the mythical man month (i.e. speed does not scale linearly with more people)
• Put research activities into a time box and make decisions on the available information after this time box, even if the information is not perfect
• Allow others to challenge estimates

Lau puts a special word of caution out there for software rewrites. “A very common characteristic of software engineers is our desire to rewrite something from scratch”. But these projects usually are the most risky projects. He makes a strong point to not combine re-writes with changed behavior. “Convincing yourself and team members to do a phased rewrite can be difficult. It’s discouraging to write code for earlier phases, knowing that you’ll soon be throwing the intermediate away. (…) [But] for large rewrite projects, an incremental or phased approach is a much safer bet”.

Balance Quality and Pragmatism

Even when we acknowledge that quality and clean code are important: There is a point where there is no positive return anymore when being too rigid about it. Requirements here are clearly different between a 50 person team, and a team with 1000 engineers. But as Lau puts it:

“Rigidly adhering to a notion of building something ‘the right way’ can paralyze discussions about trade-offs and other viable options.”

Avoiding incidental complexity is one of the key measures here (as discussed in my blog post about A Philosophy of Software Design )

Team aspects

The last chapter talks about what we can do on the team level to improve leverage. There’s a few things Lau comes up with:

• Hiring and Interviewing is one of the key high-leverage activities (in a growth environment), as finding the right people produces a huge long-term dividend
• Sharing of code ownership (limiting the “bus factor”, and creating learning opportunities for the team)
• Building collective wisdom through post-mortems
• Creating a great engineering culture

For the last point, creating a great engineering culture, he lists a few characteristics of cultures that allow for highly effective engineers:

• An optimization for iteration speed
• A relentless push for automation
• Having the right software abstractions in place
• Focus on high code quality with good code reviews
• A respectful work environment
• Shared ownership of code
• Investments in automated testing
• Experimentation time (like hackathons, or “10% time”)
• A culture of learning and continuous improvement
• Hiring the best people of course also contributes

Conclusion

I truly believe in the concept of time as a scarce resource, and high-leverage activities as a way to deal with it. The answer what the current most high-leverage activity is will be different for every individual and every situation, but the idea of making learning itself a priority is surely a very good point. Making this priority setting a habit, a real ritual, surely helps to overcome the “activation energy” problem. I am curious to learn what bottleneck you see around you, and whether they will really make it to your top priority list!