Books for software engineers and managers



Productive Projects and  Teams

by Tom DeMarco and Timothy Lister

Engineering Manager,
Tech Lead,
Product Manager,
Startup Founder

How strongly do I recommend Peopleware?
10 / 10

Review of Peopleware

Great read. My highlighter logged some miles in Peopleware.

Although written in the days of yore, the lessons of Peopleware still apply to modern software development.

Make a cult of  quality

More than quantity of work, people take pride in quality of work. Managers frequently get this wrong because we feel the pressure of multiple project timelines. We think our teams thrive on quantity. Wrong. Quantity doesn’t mean much to your team members without supporting quality.

DeMarco and Lister go a step further to explain counterintuitive aspects to quality such as the flight from excellence — when you allow standards of quality to be set by the buyer, not the builder. Seemingly a good idea, but with the disastrous side effects of decreased morale and effectiveness of the builder, which ultimately undermines both quality and quantity.

The best teams are preoccupied with being the  best

Being the best is a constant topic of conversation in corridors and meetings. Being the best is a long-term concept, a journey.

Engineering managers should reflect on this – when was the last time you pushed your team toward being the best.

I’m not talking about marginal improvements that surface in retros or quarterly planning. I’m talking about greatness. Do you talk to the individuals on your team about being their best? Does your team talk about being the best?

When you’re on a great team, they have a sense of eliteness about them. Everyone knows when they’re part of something special.

However, the authors rightly warn managers. This isn’t sports. There’s no objective scoreboard calibrating us against our competition. In our field, it’s easy to convince yourself of greatness when in fact you are mediocre.

As a manager, I’ve made the mistake of injecting claims of greatness when I actually intended to speak aspirationally. I thought I was saying “let’s be the best” but what my team heard was “we are the best.” That misunderstanding created problems in performance reviews and retros.

The manager’s function is not to make people work, but to make work  possible

Where most engineering management books focus on meetings, systems, and recruiting, Peopleware rightfully encourages a more holistic approach to management.

To enable work, software managers need to remove noise, rearrange desks, kill unproductive meetings, facilitate code reviews, uphold high standards, order food, clarify expectations, and the list goes on.

Good managers are not just a shit umbrella. Good managers are the grease in a well-run machine.

People say that management is a thankless job, but I’ve found the complete opposite. People regularly thank you, but not through words. They thank managers through thumbs up emojis, project demos, and following through.

The purpose of a team is goal alignment, not goal  attainment

This problem happens everyday at goal-oriented companies. We’re great at setting goals. SMART goals. BHAGs. KPIs. OKRs.

We are taught to love goals.

Here’s the problem. We’re so obsessed with setting goals and achieving those goals that we never bother to ask if the people executing the project are aligned on the goal.

Do they understand the goal? Do they believe in it? Do they understand their job is to deliver solutions to problems not features?

Software engineers tie their self-esteem to the quality of work more than  quantity

Both software engineers and engineering managers are judged in two ways:

  1. Explicitly by the quantity of work they produce
  2. Implicitly by the quality of work

But when software engineers judge their own work, it’s usually through quality and not quantity.

Most requests should skip the backlog and go right into the trash because there is zero chance of them being  done

Who else has a backlog of hundreds or thousands of requests from customers and support staff that will never get done?

You should consider trashing them. Right now they’re weighing your team down.

Engineering managers are responsible for creating an environment that supports flow, where workers operate at full  potential

When software engineers start early or work late, it’s a damning sign that the manager hasn’t created an environment conducive to getting work done.

Being present doesn’t matter. Software engineers need to work at full potential.

Engineering managers should ruthlessly remove distractions and craft an environment for their team to achieve flow.

The need for uniformity in staff is a sign of management  insecurity

Does everybody on your team look alike? Maybe your manager is only comfortable managing what they already know.

You can’t declare a formal standard unless it’s already a defacto  standard

Software engineers don’t take managers or tech leads seriously when they try announcing a standard from the mountaintop. To be effective, standards need either pre-existing agreement from individuals or existing behaviors.

The only freedom that matters is the one to proceed differently than your manager  would

Engineering managers frequently hit this problem with code reviews and technology decisions. We say, “here’s how I would do it” or give the stink eye when an engineer takes an approach we wouldn’t take.

In those situations, the real question is what choice the engineer makes. Do they…

Always reverse course and follow the manager’s guidance?

Talk through the issue and decide on their own?

Ignore the manager’s advice?

If your engineers always follow your advice, you’re in trouble because you aren’t training them to think. You’ve become the limiting factor on both their growth and your own growth.

On the engineer side, they crave freedom, autonomy, and responsibility to decide their fate. And on the manager’s side, how can your company promote you if individual engineers have no experience making decisions and dealing with the outcomes?