Misidentifying talent

The devil is as always in the details. At least as far as KPIs go, they can be very useful if they are chosen appropriately and if the senior team members have all bought in to the concept. Example:

I used to work in military search and rescue, and the pilots get tasked by a complex bureaucracy indirectly descended from NORAD, and they have a requirement in most areas to be airborne within 30 minutes when called. Thus, our maintenance flight had as its first and foremost KPI chosen "percentage of the time where maintenance can't get an aircraft ready to be flying missions in less than 30 minutes".

That's a fantastic KPI because the maintainers that worked for us were all on board. Getting that KPI as close to 0 as possible (and we did hit zero every few months) was a goal that everyone had bought into, because of course if you can't put an aircraft in the sky then it potentially means people are dying unnecessarily.

Now, any AME or military aircraft tech can tell you the paperwork requirements for aircraft maintenance are very strict and at times quite onerous, but they're required by federal law. So the same maintenance organization also had, broadly, "paperwork error rates" as a tertiary KPI, because of course the maintenance paperwork gets audited by an AS9100 or similar quality assurance shop, usually in-house.

That one is a shitty KPI because the wrench turners who work on complex jobs are more likely to make errors in the paperwork, so there's a perverse incentive wherein your best maintainers make about the same number of mistakes as your journeymen right out of school, simply because it's easier to fill out the paperwork properly for topping up an oil reservoir compared to changing a propeller or a weight-and-balance.

All that to say KPIs themselves are not the problem. Shitty leaders who choose KPIs improperly are the problem.

> In "traditional" companies, developers get work items assigned to them - most often JIRA tickets. These tickets are vetted by the product - or project - manager, and they have most key details to do the work. And they're expected to do just that. There's little need for questions unless it's about clarifying a detail in the ticket.

> Join a "SV-like" company, and you'll see little of this. There are projects, and there are program managers and engineering managers. But for the most part, engineers are expected (and encouraged!) to figure out the "how" of the work, including making larger decisions. In some places, each project would have an engineer leading it, who facilitates breaking up the work. At other places, engineering managers or senior engineers could do this work. Regardless of how it's done, all engineers are incentivized to look at the big picture, to unblock themselves, and to solve any problem they see.

> Engineers taking initiative is something "SV-like" companies celebrate. It's common to see services and features built that engineers suggested or have teams spend dedicated time paying off tech debt that people on the team advocated for. And it is uncommon for managers to tell engineers what exactly to do, to break down their work into small chunks or to micromanage them. People self manage.

> The expectation from developers at traditional companies is to complete assigned work. At SV-like companies, it's to solve problems that the business has. This is a huge difference. It impacts the day-to-day life of any engineer.

Well, there is a consideration for management positions that says an appearance that evokes deference is a genuine qualification for the job.

And while it would be difficult to make that argument for doctors, it's not at all difficult for lawyers.

Isn't the traditional company approach having engineers in charge of engineering?