Peopleware

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.

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.

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.

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?

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.

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.

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.

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

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.

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?