[Joel_Mckay]

I have to admit I initially hired a few Papered Posers, and it was a mistake to pay them 2.4x higher than market rate to ensure the project would reach conclusion on schedule.

The lessons we learned:

1. "Manage or be managed...": your first lesson is people will try to manipulate those in positions of authority regardless of competency. i.e. the idea of "goodwill" being the true core product can escape the irrationally ambitious/sycophantic.

2. No amount of money can make someone care about company projects. The worker may be interested in the project, or is simply there for the wrong reasons. Remember you want to keep employees content, but a "kingdom of kings" is unsustainable.

3. People can postpone something until tomorrow indefinitely. Thus, pay very close attention to projected deliverable times.

4. Fire someone for being unproductive according to a defined workmanship-standard as soon as possible. It will notify the rest of staff you are not there to play games, and stupid behavior will have consequences. Mostly effective with Jr staff using ChatGPT to try and BS the world like any other con.

5. Delegation? Just initially run trial contracts with potential staff first for each project deliverable. Failure to deliver on time means they don't get another dime, or a second chance to be unaccountable for their behavior.

6. Entrenched incompetence: organizations have their own emergent structure, and it will usually drift back to the same dysfunctional patterns/designs.

7. Redacted

8. try to leave things slightly better than when you arrived.

9. Managers usually can never be a normal employee again. People subconsciously fear they cannot control authority, and will prefer to hire someone easier to "handle".

Best regards, =3

[KerrAvon]

You may wish to talk to someone to evaluate whether the company you work for might be completely dysfunctional-- none of that list sounds like it's coming from a healthy place.

> 9. Managers usually can never be a normal employee again. People subconsciously fear they cannot control authority, and will prefer to hire someone easier to "handle".

This is usually not the case at a FAANG, for whatever it's worth. Multiple people I know have voluntarily moved back to IC from management positions. It's not that unusual for senior devs to try managing and figure out that they don't like it (whether or not they're good at it) and then move back into being a highly regarded IC.

[Joel_Mckay]

My personal experience with titles has always been complicated.

By the time a corporation has reached FAANG scale, they become boring and ultimately immutable out of necessity. I find it sad many folks dream of joining that drudgery, inventing nothing, and gambling on asinine business plans. =3

[eastbound]

Hi,

I’m coming here a few days later and I would like to thank you for the feedback and reflection. My impression is there are two styles:

- Restless: Hire and fire as fast as possible until you work with the right people, be tough. Could be positive if you can spell out the rules of success very clearly, with 100% reliability.

- Patience: Hire and train until people fulfill your needs. Run the risk of charlatans. Sometimes even good people end up slacking off because they aren’t motivated by the trust and the absence of the carrot and the stick. But you have the satisfaction of caring about people’s wellbeing. Which they most probably abuse, and they’re probably not even happy in this situation.

It’s Christmas so I’m having hard times firing 2 non-performing people who may just happen to need more time to ramp up than I estimate. January’s coming up soon.

[Joel_Mckay]

Indeed, often it is a tough call, but sometimes even the best talent cannot overcome the inertia of seniority. I have witnessed folks:

* deploy the wrong stack due to existing team skill issues, than the maintenance sinks time and resources away from the project

* hit unclear project goals leading to constant distractions, and entrenched policies dominate design back into garbage

* have informal testing in random situations developers never get to see

* break the testing repeatability loop, so bugs never get properly resolved

If one only has 2 staff left, than they are likely doing 8 jobs 8 times less efficient than one expects.

Best of luck =3

[osigurdson]

>> Failure to deliver on time means they don't get another dime

"On time" can be achieved by over estimating. As a hypothetical, dev A estimates that a project will take a year and completes it in 6 months. Dev B estimates 1 month for the same project and completes it in 3.

Companies that focus too much on things being "on time" ultimately get the "nothing is worth doing" corporate culture.

[Joel_Mckay]

Actually, sometimes it means hiring rank amateurs, and training them to reliably complete tasks like a real business. Understanding the time constraint would be lower for Jr, and thus the equivalent pay scale will be less lucrative... but it is up to individuals to decide their own work ethics.

Using PERT deliverable/vertices redundancies is often necessary for projects no one has seen before:

https://en.wikipedia.org/wiki/Program_evaluation_and_review_...

Note, the simple system uses probabilistic time estimates of key deliverables, considers redundancy, and explicitly mitigates teams that introduce liabilities.

If it put people on the moon, than I figured it was good enough for most of my ridiculous projects. Have a great day =3

Rule #17: "Always listen to the person that signs your paycheck. Everyone has an opinion, but some opinions are more profitable than others"

[osigurdson]

I think the PERT chart is pretty accurate. The issue is typically predicting what all of the nodes on graph will be ends up being a waste of time. Instead, there are really just two points: current state and desired state. It is better to spend time clearly articulating the desired state so that everyone really understands it. Then incentivize people to get there as quickly as possible.

[Joel_Mckay]

I think our perspectives differ slightly, as I really don't care to micromanage adults that know better. Notably, the fixed cost of development is far less of a concern than long-term deployment, support, and maintenance costs.

Probably a ROWE would be a similar modern equivalent...

Have a nice day, =3