> “People look at recruiting the same way. ‘If we do five hires per quarter per recruiter, we just need to add two more recruiters and we’ll be hitting our targ

> “People look at recruiting the same way. ‘If we do five hires per quarter per recruiter, we just need to add two more recruiters and we’ll be hitting our targets.’” However, engineering leaders will be hard-pressed to find a similar lever to pull. “For engineering, there are just no measures that I find super helpful here The lever isn't people, we've known that one since the 70's. But what we've learned over the past 15 years is that more quality, speed, and reliability through automation and shifting left, is a lever that works. A decade worth of DevOps reports show this to be true: the high performers do certain things, and the low performers don't. If you do the things, you also start performing at a high level. But you have to actually do them, not just intone tech jargon and hope for the best, like so many ineffectual leaders have. > when you hear from your eng leaders that ‘Engineering is an art, and you can’t predict how it’s going to work,’ it’s frustrating. They’re sitting there thinking, ‘They’re telling me this is art, but I’m spending $100 million on this art each year.’ That’s not reassuring.” But you can predict how it's going to work. It has barely been written down, and it is never really taught, but everything you need to know is out there. There's no mystery to producing software products. Ask any veteran. The same stupid bullshit keeps happening, until you do certain things, and then the bullshit stops, and things start working better. > too many well-meaning engineering leaders go by the book of conventional leadership advice. Too many engineering leaders don't understand that not all "engineering" is Engineering. If you want to engineer a building or a brake caliper or something, that's not art. You use math and science and engineering skills to design the thing to work, based on what is known to work and quantifiable and specific criteria. But to actually manufacture the thing you engineered - quickly, effectively, without defects - that is a craft and an art. There's designing a thing, there's building a thing, and there's operating a thing. These are very different things, and require very different ways of working. Software people have this bizarre misconception that somehow they're all the same thing, like some blob of random actions that they should intuitively know, and will execute flawlessly without any kind of enforced process or continuous improvment, and it should be easy, predictable, cheap, fast...... That's not how the world works. But I get it. Not everyone is a veteran who has seen and done all the things and knows the right way to do all the different things. The thing is, you don't even need to know the right way to do things. What you do need to do is rely on data. Look at DORA metrics and the qualities of high-performing teams. Change how your org is working until those metrics improve. Continuously iterate on improvement, through process, experimentation, study, refinement. If you walk that walk (not just talk the talk), you will get improvement, predictability, value. But you know how many engineering leaders I've seen actually walk the walk? One. And he got canned by political pressure because he was making other leaders look bad.