My Engineering Management Philosophy

Running an engineering team has evolved into a philosophical profession for me. I lean heavily on principles to make decisions and gain perspective on hard problems.

Principles can be defined in 3 ways as a truth, a belief, or a moral standard. More specifically, a principle is anything that's based on strong science, well-reasoned beliefs or philosophy, or the shared values your team or organization. Accordingly, clichés and anecdotes should be treated with skepticism.

For example, software quality is core team principle so everyone is responsible to write tests, document, and improve the product. Yet we can be flexible on how much test coverage is necessary. I make sure my teams appreciate that Quality is a subjective concept. At times the business will require us to prioritize speed over implementation style.

The team is responsible for organically establishing its principles and using them is their daily work.  As leader, I may suggest that we embrace the willing to change our beliefs when presented with new information. If the business changes directions, I might need to guide the team to a new set of principles based on redirect.

Performance Management

I want to cover performance management first because it's a subject that I'm deeply invested in changing. To set the stage, I'll define two keystone principles which informs much of the rest of this subject. You cannot scientifically measure productivity or performance.

A) You cannot measure an engineer's productivity.

Or any other knowledge worker's productivity.

I doesn't matter what you measure: story points, lines of code, bugs fixed, number of commits, technical debt, code quality. None of it can be combined to measure productivity.

These metrics are all subject and deeply flawed in some way.

Can you ever measure engineering output?

You can only measure productivity at the team level. However, any productivity measurements should only be used to help you plan future work or to help you gauge team level enhancements. A team enhancement might be making tests suites run faster, a faster CI/CD pipeline, or removing a shared barrier by moving to trunk based development.

B) You cannot rate anyone's performance in a scientific manner.

I don't care that you think you are smart and believe you can be objective. You are not objective. Our brain creates mental shortcuts that result in hundreds of scientifically provable biases.

When you rate others, it reflects more about your rating habits than it does about the person you are rating.

Don't we need to rate people? No.

You should be focused on helping them do their best work. My job as a manager is to be catalyst for speed up the performance of each team member.

My job is to remove roadblocks, provide clarification, promote our shared team philosophy and values, help you grow as a person and as an engineer.

That covers it for today.

If you are curious to learn more I highly recommend Marcus's Buckingham's 9 Lies about Work. He has spend his career studying how people work; first at Gallup and then ADP.

Here's a quick preview of the book.