How to drive away your best engineers

- Lowering your hiring bar. When you hire people the burden to get them up to speed and productive is on the existing team. If these people are smart and motivated, great! But no-one benefits from having 200k+ engineers now have to spent their days explaining how GIT (yes, really...) works to a small army of juniors.

- Not involving your current team in decisions that affect them. Re-shuffle the teams around, re-architect the product, change the existing workflow, etc. If you hire professionals with 10-20+ years of experience just to ignore their advice, they're going to be looking for an employer that does appreciate their input very quickly. Nothing is more frustrating than telling a manager not to put his hand in a pan of boiling water, just to see him do it and then blame the cooks for having a pot of boiling water around :)

My current manager decided to add 50 outsourced engineers to a team of 5 to deliver the product in a year (instead of the 1.5 - 2 originally guesstimated).

In addition to this he decided to give the responsibility for the architecture of the application to outsourced "solution architects" with no domain knowledge and reorganized the teams to split them by job title (e.g testers, developers, operations, "management", etc).

Current productivity is lower with 55 than it was with 5, 3 out of 5 have already handed in their resignation. We're burning through an additional 3 million this year with 2 crappy React pages to show for it.

Next year the damage will probably be worse given the rapid outflow of talent.

Managing software orgs is hard, and most orgs can't do it well. Using additional management methods, more managers, and more engineers can make the software org less efficient. Software production is weird. Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal. Very extreme compared to most fields employing such numbers. Software can be really important & high value. Value can be utterly disconnected from the cost of producing it.

I say "less efficient" purposely rather than "worse." It might actually make sense to go from an efficient 25 person team to an inefficient 500 person team. The additional cost of might be dwarfed by the benefits of marginally more higher output. That might be better economically (even socially), but less efficient.

If you're in one of these orgs, you will not be more happy though. Efficiency feels good. Inefficiency feels bad.

These are the same complaints I hear from inexperienced engineers over and over and over again – and not just engineers, but anyone primarily responsible for 'labor' vs. 'management'.

The 'best engineers' empathize with the perspective of 'management,' that running a company is probabilistic, and that managers, co-workers, and other departments – like finance, recruiting, product, and marketing – are also duty bound by challenging constraints often beyond their control.

Here's some of mine:

Put "security" before all else. Pointlessly surveil and monitor your staff for feelgood security theatre. Mandate MFA for every trivial login so that simply checking your email becomes a tedious schlep.

Spam your employees. Send out daily self-congratulatory ego-trips as "newsletters" celebrating how well the company is doing. Sap morale by reminding every lowly engineer just how insignificant they are, what huge profits the company is making and how much senior salaries are. For bonus points use a "no-reply" internal address and make it impossible to block them.

"Team build" by putting on mandatory "social" events, and various awareness and training. Shame employees to do not "participate" because that have actual work to do.

Keep zombie projects alive. Even though clients have cancelled and everyone knows it will never be delivered, keep projects running for the sake of appearances and to keep managers close to retirement in a job for another year.

Actually, stop me! This could go on all day. Someone really should write a book "How to kill a company".

If that's true, then it's probably mutual. Engineers typically do not realize that their manager's role is to manage people and process (which is a bit of a specialization in itself), and knowing how to build software is not necessary but definitely useful - mainly for questioning your engineers when they tell you something that sounds crazy.

If any engineers are under the impression that their job is harder or more important than management, sales, etc, they're being arrogant.

Coming from a former strong engineer who started a company and now manages people more than code.

This applies regardless of actual talent and does not guarantee results. I've seen mediocre SWEs with inflated egos jump around because they felt their "world class" talents weren't being put to good use, some unsuccessfully, but some rather successfully fooling their way through the ranks of management. But I've also (more frequently) seen disillusioned, extremely talented engineers leave an org that was paying them obscenely well already, but was making them feel like they were wasting their time, for a shot at a startup dice roll which does not pay off as well (on average).

A major missing one is the demoralizing effect of having to work with incompetent team members, with management unwilling or unable to do anything about it.

An incompetent person is likely not a bad person - more likely a good person who is the wrong position, or who just isn't capable.

I recall working on a team where I was called over by one of the members to help out. I was new on the team, and wondered what the sidelong looks from other team members were about. She wanted to know why her program did not run. I asked to see the compiler output. She asked what a compiler was. How a person could attain a masters degree without actually knowing that is beyond me, but her skillset clearly had nothing to do with software.

This was in a government agency, so she was promoted to management where she became one of those other problems on the list.

What's the difference between estimating and forecasting? Seems very binary as written, but at some point don't you have to look forward and make some assumptions on complexity/effort required to solve a problem and the general time it takes to solve them in order to do a forecast?

> Make the process of defining software painful.

> Make engineers estimate their work.

IMNSHO, these all have the same "fix":

Technically-proficient managers (that are also good managers). The combination of those two is rare.

Management is often considered an "ego position," so unqualified* people fight to be managers. It's not always about the money. It may be about the office, the car, the administrative assistant, the invitations to trade shows, etc.

Also, upper management types frequently consider "workers" to be "lower class people," and only want people they can relate to, personally, and that don't make them uncomfortable, in management roles, so they end up mining the Yes Man and Politician veins for managerial talent.

In my case, my company actively discouraged me from being technically proficient. They would routinely deny me training (so I went to training seminars on my own dime, and took vacation time), and would ignore my technical work (which was often extremely relevant and useful). I ended up doing a ton of open-source work, just to keep my tech chops up. Because it was my own work, I did stuff that had very little connection with my "day job," and also brought my own equipment.

I hated being a manager. It was always a burden, but I feel (and everyone else seemed to agree), that I was pretty good at it. Since leaving my last job, I ran screaming for my tech work.

*"Unqualified" is not just "technically unqualified," but also "emotionally unqualified." I think managers need to remember that they are managing people, not just "human capital," and that, if things are done right, their employees may be more technically qualified than they are. That was certainly the case for me, and I was proud that my team knew more about the work than I did.

So I guess this post is only for big companies and VC-funded startups. I'm the technical cofounder of a tiny bootstrapped company, and for now, I'm the only engineer. Being the sole engineer is stressful, but it's currently necessary, and I think it's worthwhile to maintain the control and integrity that we'd probably have to give up if we pursued the funding to hire a bigger team. Even when we do have the revenue to hire, we will certainly not go straight to a team of 6 or more engineers. Big teams have their own problems, like communication overhead.

1. Why are you asking? and

2. What happens if I'm wrong?

I subscribe to the view that you can either launch based on features or launch based on time. You cannot do both. If your product is a compiler and you want to support, say, ARM and that requires a bunch of work, you have to choose to release a version at a particular time or to launch with that feature complete. Many people just don't get this.

You can try and hit a time goal by resourcing but this is often done in a counterproductive way eg by throwing bodies at the problem when it's far too late and as we know that can just slow down the process as the people who know what they're doing have to ramp up the people who don't.

Often you're being asked for an estimate because management wants to ignore this and is fine with forcing their team into "crunch time" to meet some arbitrary goal.

As for what happens if I'm wrong with an estimate, basically am I going to get "punished" for underestimating? Be that through getting a bad performance review, a lower bonus, a lower stock grant or whatever.

If so, you've just created an incentive structure for me to completely overestimate because there's typically zero benefit in overdelivering (other than a perfunctory "ata boy"). So if I think something will take a day, I'll end up estimating 1 week, maybe even 2.

You should build some buffer into any estimate but if you are punished for taking longer and not rewarded for being faster, what do you think is going to happen?

Now you might have a bug to fix a typo on a website and if you say that'll take a month obviously that won't fly but a team will generally settle on estimates that are really large without being large enough to draw scrutiny.

Even then, many managers will take an estimate of 6 days and negotiate down to 3 days without knowing what went into that estimate. That too will lead to buffers being padded.

If someone takes longer through no fault of your own (eg it just turns out to be really complicated in a way you couldn't anticipate) then I've seen it more than once where a manager will throw that engineer under the bus to save their butt from their own management.

In short, estimates are an almost sure-fire way to create an adversarial environment between engineers and their direct management.

Most of IT managers I met possessed no real IT skills. They wrapped their heads around only as much theory as needed to _manage_. Most of them did not came from engineering world but from business one.

Ideally, manager should be able to do the work their team is doing, but reality is quite different. I stopped expecting managers to understand what I do outside of expected effects.

Regarding estimates, it really is frustrating when a non-technical manager cannot understand the inability to state any reasonable time estimation.

- so how long will it take you to finish this task?

- no idea, haven't done anything like that in the past

- ok, so how long?

We’re obsessed with technical talent but we hire managers at random after asking a couple of behavioral questions they’ve heard a thousand times.

The fact is, in every organization there's the technical side and there's the political side. The bigger the organization the more need there is for a political, not a technical, manager. The former manages the people, stakeholders, etc. The latter manages the product itself.

In many organizations both roles are done by the same person, who tends to do one side better than the other. In engineering organizations the manager is probably more on the technical side because engineers.

The problem is that large organizations (insert your definition of large, it could be >20) or organizations with multiple customers managing upstream expectations and prioritization are really important. These people are paying the bills, after all. At that point you need to start fending off salespeople, account managers, and other executives.

Unfortunately, telling customers to fuck off you're busy isn't the greatest path to customer satisfaction, retention, etc. You need a political manager to do that for you.

I know of a few large orgs that have formalized this tech/political manager structure, because it's effective. But you need to understand what's happening and why. If something rolls downhill to engineering it's because the political side believed it was required; you need to accept that. Likewise if the political manager gets pushback they need to understand that the issue is real.

So taking a step back, the article is complaining that you should have managers that understand what engineers do. I'd flip that - we need engineers that understand what managers do. Engineers are not special. Neither are managers. It takes people working together to get stuff to happen, period.

What does this even mean? I've never heard of a forecast that didn't use a combination of past data and an assessment of complexity of future work to assemble the forecast.

And assessment of complexity is the heart of estimation.

Can anyone help me because my imagination is failing me here.

1) Rampant tech debt. Engineers are not empowered to fix it or their focus is on something else.

2) High barrier of entry. Most SaaS companies are bad at onboarding engineers or they simply don't care, usually because C-level staff and investors work towards sales metrics.

3) Mismanagement. Passive engineering managers who spend most of their time attending obscure meetings and expect individual contributors to chase them, maverick employees who do more harm than good, antisocial behaviour due to having no conduct expectations, etc.

My personal opinion is that nowadays SaaS engineering is akin to being a miner during some mineral rush. You can make significantly more money than the average Joe in exchange for a shorter life expectancy.

* Put them oncall on Xmas when they are new to the team (because teams are like army where the newcomers must suffer)

* be pedantic and hysteric in code reviews

* have meaningless processes that drag for hours. E.g. iteration planning that goes on for 2 days

* enforce nebulous "principles" (e.g. anything by RC Martin) because manager that hasn't touched code in a decade went to a show of him and was "impressed"

* have clueless architects design systems and processes. Specially anything microservices-related.

* have lesser engineers run the teams and processes. The kind that is good in Public Relations but have little or no real skills

* have id-politics matter more than anything else. E.g. most important problem this week being why women employees got a pink promotional cup and how is that discrimination

* do not allow access to web mail and a gazillion other sites because "security"

* do not allow local code (if you see this - run) and instead promote "dev" in remote controlled envs

* foster a blame culture (who did that?)

* foster a toxic culture where politics run the place

* fire good engineers and keep the above mentioned Public Relations ones

* have and promote managers that are good in gaslighting and not much more

* work for managers and with colleagues that you'd advise your kid to stay away from because they cannot be trusted

* hire titles with no real experience and many ego issues and push them hard through the ladder. Classic example PhDs straight from uni.

I get the pain expressed here, it's real, and the problems are REALLY HARD to solve. Any one of these is multifaceted and cannot be solved by "management" alone. Asking VPs to code a feature every quarter is both unrealistic and silly. Complaining about too many managers, meetings and processes is common and fair, but not to say "if you have painful process fix it with this different, equally strict and brittle process" is naive to the point of funny. Saying "estimation is hard so don't do it" an incomplete answer, and railing against smaller teams or realigning people broadcasts "I don't really think about budgets, emerging needs or things above writing code".

So much of this can be addressed within the team; you can promote streamlined process that does enough to align without prescribing, you can add some consistency in who does what work to build more durable teams and form a consistent mission, you can estimate in effort not time. The author seems to think the ideal is achieving stasis and maintaining it; to me this is impossible and actually sounds like hell.

Software managers who were never programmers _know_ they don't know about programming, and understand that this gives them some blind spots, so they are often willing to take constructive, professional, tactfully given hints on that. Software managers that were programmers, in some cases, not only don't have people skills, they don't think people skills are important or useful, and they don't try to get better.

Not saying former programmers _cannot_ be good managers, I've seen some that are. But I don't think non-programmers are, on balance, less likely to be good at managing software development, because they know what they don't know, and managers who were formerly programmers often don't.

I've been writing code for a living for 20 years and I swear it wasn't always this bad. There were fulfilling software jobs at one point. What changed?

This! It's more or less impossible to correctly estimate how long it will take to develop anything but the most basic pieces of software, and even then you can't be sure.

I've had so managers who just don't get that there are so many unknown variables in the software development process.

No matter what estimate you give, you cannot win. Estimate short, but it takes longer? Then you are accused of not knowing what you're doing. Estimate long, but come in short? Then you are expected to shorten all future estimates. Estimate right? Nah, that never happens.

Every price of software developed is different and will take a different amount of time to be developed. It is really quite stressful for a dev who is working their ass off to hit difficult targets in an organisation that refuses to be flexible about that sort of stuff.

> Make your engineering managers, Directors or VP’s take about one week in a quarter and get them to build and deliver a feature.

While we're at it, why don't we also get them to design a part of a car, design an icon for UX, do some accounting and have them do a legal brief?

> Stop estimating.

How does this person think an organization schedule, budget and allocate resources?

> In my opinion, Have a minimum team size of six.

To build what? Some production software can be built by one person. Some need hundreds. This is like saying an organization needs a minimum of $1.5m annual budget for software development because it's software development.

A few points stroke a chord. Specifically...

The definition of engineering manager who doesn't know how to do stuff and it's solution is very wishy-washy. Based on experience, this works in some contexts but not all. I think the author's hearth is in the right place, but the way it's explained is very short sighted. In other words this makes me think the author has never worked with an eng manager.

Layering: good problem to solve, solution? In theory, but in reality this is also very difficult to balance (e.g. from experience, especially when moving above 150-200 ppl working in the same area).

Too many meetings: very good problem. Solution? Partially meaningful. If you want to generalise, my take would be to make things async as much as possible. Collaboration between teams might be needed, and perhaps healthy. When you don't have collaboration you end up not knowing what's going on (i.e. isolating teams) and risking pulling meetings over and over.

Software definition; mostly agree, but again, the solution is much more complex than what the author leads to believe. Also assumes you have testers and product will be happy to sit through each ticket revision. This problem is solved by anticipating these requirements way way earlier than that.

Software delivery: are we talking about technical debt or what? If that's the case, the solutions (20%) make no sense. That's where you start diving into each single problem, breaking them down by priority, involving product and making sure things are tackled at the right time.

The rest seems to be good.

>scuttle verb(1)

1: to cut a hole through the bottom, deck, or side of (a ship) specifically : to sink or attempt to sink by making holes through the bottom

The actions of these people make you to give up on Occam's razor in disbelief. Sometimes they're the owner of the company who are doing everything someone who'd want to sink a ship would do.

The worst is when the ship was amazing (generating revenue like crazy, great reputation, top notch record, satisfied clients).

Also, promise people equity then change the goal post by introducing new variables, haggling over everything, and attempting to screw them in every sentence (for instance, change the vesting period in one sentence, add a condition in the next sentence, claim they've had no impact on the company in the next, threaten to fire everyone in the next, add yet another condition in the next, tell people you can't give them the equity you promised because you promised someone else and do that for the other person too).

That's, in essence, how to fuck up your own company lightning fast.

1. Hand out responsibilities and make engineers accountable without giving the engineers any influence on decisions.

2. Make team decisions without asking the team.

3. Make promises to individual employees that is not inline with the team or company strategy.

4. Make tech decisions among management people.

5. Outsource new development and let the staff work with legacy.

6. Constantly increase the scoop of what the engineers are working with.

* When a project is declared "finished" break the team apart and spread them about the company. Because the original dev never see the code again, why should they care.

* When a project is late, and it always is, pull out the original schedule rammed down our throats when the project was first started. Then it's easy to see who to blame.

* Have legal (YES!) decide rules for agile. True: they decided on 1 week deliverables, demanded complete documentation per week, insisted on a waterfall approach to design and dev. "When you've done it, you don't have to revisit the past!"

* Documentation was in charge of dev: "They read the docs and know what needs to be done:. I never figured out who "they" were.

* Create a lengthy, complex paper trail for deliverables.

True story of one company - now extinct. They had about a 50% turnover rate.

* Manager maturity. Young managers tend to be very hands on, they will naturally micro manage. More times than not they were previously an engineer, possibly in the role your currently in, so they continue that role, but with manager power and authority. Young managers work best with younger employees. Young engineers need hands on managers to explain things and mentor them, and that plays well into a young managers need to manage things. Older, experienced, and more mature managers tend to learn what their value is and where they are important. Usually that means listening, coaching, and communicating. Technology has literally changed under their feet, so they tend to be hands off. They also rely on their team more to make decisions and drive towards success. They depend on you. These managers tend to work well with senior engineers (a senior engineer is someone with decade(s) of experience).

* Conflict. A few years ago I did a handful of manager interviews with some top tier tech companies. I was a bit dismayed that these companies were not looking for nice guy managers who values things like compassion and supporting their employees, and possibly even be friends with them. Rather, they want managers who are hard, can wield power, and comfortable with conflict. Conflict here means that management and employees are in constant dispute over literally everything. This means that managers are constantly squeezing work out of you and will have no problem introducing politics and other authority techniques into their day to day managing.

* Communication. Open communication is extremely important. What I find is that when you have many layers of management, decisions are made using information which needs to be withheld from lower levels (or decisions are made based on no information!). When it reaches the lower level, it seemingly makes no sense and can be confusing. Good management communicates everything and does so transparently. This way everyone understands the what and the why. If you don't agree, given you know the why, then you are at least better prepared to pitch an alternative or make the needed changes. If the why is something contentious like you or the team is underperforming, then again, its best that is communicated so everyone has the power to make corrective action, if they choose.

I think a lot of this comes down to culture. A good culture values engineers and adapts to making them happy, as that is how you get the most productive engineers.

this is a joke right?

I’d much rather me give an estimate than some EM or PM since I’m building the damn thing.

And totally confused by the author’s suggestion to “forecast”, which is what if not an estimate?

Remove anyone’s competence, relatedness, or autonomy and you will drive them away.

Is software engineering a lucky game ? I say YES!.