If you make big changes, just do it. Don’t explain it at length. If you explain it, you give people room to argue and hem and haw and ends up being counterproductive. It’s an invitation to bikeshedding.
“Therefore any cruelty has to be executed at once, so that the less it is tasted, the less it offends; while benefits must be dispensed little by little, so that they will be savored all the more.”
Humanitarian isn't really the right word, but it's good advice even if you're not being evil about it. If you have to give out bad news, it's better to be quick and complete about it than have rumors swirling for weeks, or have to keep giving out a new bit of bad news every week for months. That's true even if you're not intentionally being cruel, and can help people process it all at the same time, instead of just living in a deluge of bad feelings.
This is true. I just don't think Machiavelli was well known for his positive humanitarian outlook towards things. I suppose it's assuming bad faith. You do make a good point though, and it's probably better to try and take a positive message out of it.
Are you confusing Machiavelli for Hobbes? Machiavelli was largely a proponent of liberty, and his patrons whom he gifted the Prince, the Medicis, don't even make the top 5 list for inhumane behavior as far as powerful Italian ruling families go.
Fitting that most top-tier business schools quite literally use The Prince as a textbook for building and maintaining organizational power structures. Future executives are taught that Machiavellianism is very bad... unless you're the one doing it.
The modern word "Machiavellian" has had a life of its own and doesn't correlate directly to what is actually in The Prince, though. When we (in 2019) describe someone as machiavellian, we tend to imagine some sort of mustache-twirling evil mastermind. The book itself is more like a dispassionate, semi-scientific textbook on how to be a ruler.
The quote I listed above is a good example. M. is essentially just saying that, "if you have to do bad things, do them quickly and all at once." Generally good advice, I'd say.
A modern analog would be firing employees - avoid it if possible, but once it's determined to be absolutely necessary, just do it. Don't waffle, give conflicting messages, or build an atmosphere of dread. Make the tough decision, execute it quickly, and then move on. Of course, one could argue that the manager should have made better decisions to avoid the need to fire people in the first place, but that's a deeper discussion.
And honestly, the reverse idea in the quote is also true. If you have finite resources to spend on perks, don't blow the perk budget in Q1; divide it up into several smaller boons and spread it out across quarters. We know human psychology has diminishing returns on positive feeling and you'll get more out of several small dopamine boosts than one big one.
Machiavelli is still taught because, frustratingly, it still applies.
I call bullshit. If there is a single class at HBS, Wharton or Stanford that uses The Prince as a textbook I will eat a teddy bear. I’d be slightly surprised if there was a class that used readings from it extensively but that at least is possible. Business schools don’t have courses in political philosophy, nor do top ones have courses that are brain dead airport business books in lecture form.
Good news for you though, 24-packs of Gummy Bears are available on Amazon for just $8.79, thanks to the demand for them from large companies as a low-cost perk that can be doled out across quarters cheaply. ;)
First of all, this is an excellent comment thread. Secondly - I think technically they said "used as a textbook," not sure if the link demonstrates this extent of reliance on the book.
> Business schools don’t have courses in political philosophy
You're completely wrong here. My business school (global top 10) had multiple required courses on political philosophy -- both corporate politics and government politics. Navigating complex political situations is the most important skill to have as an executive in corporate America. In fact, those classes are usually the most popular with students and consistently rated as being some of the most valuable by alumni.
I'm not surprised that business schools have students reading The Prince, but I highly doubt that any classes are treating as a practical how-to manual... which is what the GP was clearly implying.
That's exactly how it was taught, supplemented by HBS case studies that heavily referenced The Prince.
Granted, it's taught as "here are things to look out for from your subordinates" -- but if you read between the lines, it's "here's how to walk the line on this stuff and get away with it".
I think Google has finally embraced the fact that they're an advertising company and they're not going to change the world for the better. This means they need to drive off the idealistic hackers that built the company and replace them with corporate drones who aren't focused so much on building an empire as much as protecting it.
This has been happening at both Google and Facebook over the last 5 years. I think the fact that they're driving off their most talented (and expensive!) employees is part of the plan for transitioning from explosive growth to maintenance. The growth mindset has become a liability for them.
Tangentially related I hope developers will realize that the current stack inherited from them is basically enterprise software made for large teams of interchangeable developers, just with better marketing than J2EE 15 years ago.
> I believe that if there was a full standard distribution for Java EE (e.g. Icefaces+JSF+Seam+EJB3+JPA+Hibernate+Glassfish, to name just one possible API stack out of thousands of different combinations), people would write a lot more good documentation for that particular stack, and it would become a lot easier for more developers to start using it effectively. With the right tools and good documentation, productivity could potentially be about the same for Rails and Java, but at the moment Java is shooting itself in the foot in this regard.
I would have to agree with this -- I work with a lot of large telecoms and nearly all of them use Java for any back-end services that need scale. Sure, Java is insanely verbose syntactically; but that has the side-effect of forcing you to formally model your application architecture in order to generate stub code. The unfriendliness of Java is just managed through tooling that presents a simplified interface to developers. It's easy enough to wrap a JVM in a container to work with Kubernetes or arbitrary cloud services, so many of the operational aspects of working with the JVM are greatly simplified.
Moreover, Java on the web (first in the form of JSPs, later Spring-based frameworks) was largely a reaction the shortcomings of LAMP, which was largely a reaction to the shortcomings of Perl5 CGI-BIN (what I consider to be the first widely-used web framework). The great irony is that Perl had an advanced dependency management system in CPAN in the mid-1990s and PHP had nothing for years. Ruby on Rails succeeded largely by combining a CPAN-like dependency management system with a web-native development framework.
You must be joking. A good Rails dev will run absolute rings around any java or .NET effort no matter what tools they're using. I don't even think I'm being subjective here; I work with java (well, kotlin/scala) devs and even they wouldn't say anything like that.
Rails has disadvantages yes, concurrency and its lack of ability to support long-running tasks foremost amongst them, IMO. But dev speed, for standard "startup web app" features? There is no contest and I'm baffled as to why you would claim otherwise.
There are few technologies I despise more than Spring. Well, maybe OSGi. Also, hibernate and JPA. I've lost so many hours of my life fighting those things.
I try to stick to Clojure for most of my JVM-ing these days. Right now I've got this one large Java/Spring-boot service I've inherited sitting in the middle of an otherwise micro-services-based architecture built using Clojure/ring and Python/flask services (for the ML stuff). I keep thinking about how I want to start calving off chunks of that thing to re-implement in something not Java/Spring.
Because Spring magic is great until it's not. And then you're banging your head against your desk for a week chasing down some weird heisenbug related to some nonsensical Spring behavior. And there's no sense of accomplishment when you finally resolve it, because the entire exercise only served to increase your esoteric knowledge of Spring, which you never wanted to deal with in the first place.
Having recently spent some time in a leadership position, I must admit I became disillusioned with "consensus emerging from democratic debate" - everyone tends to argue from their myopic view of the issue and to avoid thinking through the consequences fully (because ultimately they won't be responsible for them).
That said, as a subordinate, I hate it when no rationale is given. And it can be counterproductive too because people will start to speculate about "true reasons" behind the decision. Instead a reasonable thing to do seems to be to publish a rationale but make it clear that the debate is over and everyone has to commit to the decision even if they disagree with it.
I agree with your experience. However I disagree with one aspect, in my experience.
Giving a rationale hasn’t engendered trust, and instead has contributed to conspiratorial discussions (they say it’s about x, but it’s really about y!) and often times the conspiratorialists were kind of right. There is no good answer but a straight directive with little food to chew on leads to less counterproductive speculation. And often it is less “dishonest”.
> and often times the conspiratorialists were kind of right
I think people are fairly good at noticing when they are just getting “spin” or an incomplete answer. The conspiracy theories pop up to fill the void. The only way to avoid this is to give enough information. Once you are caught withholding key information you will never be fully trusted again.
Giving no information is probably better than giving misleading information but it certainly doesn’t engender trust.
If you want your employees to be honest with you then you must give them a reason to trust you. Personally I believe part of that is being as transparent as is rationally/legally possible.
Much of google’s success is built on trust. People had to trust them a whole lot to sign up for most of their services at one point or another. Most employees I have met felt the company was very open, their ideas mattered and that they were working on something positive.
Maybe that much trust is naive but when your decisions can amount to things like censoring the internet for half the world it’s maybe not the best plan to just pull the trigger and tell everyone who works for you to just deal with it.
Most folks don't really care what you are doing. Because they don't understand your issues at all. Just say "It was the solution to a problem we were facing. If you want to find another solution, be my guest" and watch their 'anger' disappear quickly.
That’s not that terrible of advice. You are empowering others to take action rather than feel disaffected. If they can come up with a better way with the same constraints then why not? Otherwise everyone gets to move on.
Not explaining is a bad idea, since it means that people who disagree have no chance to be convinced or even understand the motives if not convinced, so they are much less likely to effectively cooperate with the new course.
Instead, explain at length and let people discuss, but at some point explain that the decision is final unless some major new elements come up.
People who disagree are not going to be convinced by corporate comms. It’s not going to happen. It’s a bigger distraction than what you’d otherwise get.
The idea is not to release "corporate comms", but in full transparency, honesty and with complete willingness to be proven wrong release all the data (email messages, meeting transcripts, web sources, documents, spreadsheets, simulations, etc.) the decision was based on and your thought process.
Hey I would counteract my kids' 'Why?' with "Why is not a question. Why what?" They'd have to form a clear question. Made them digest the issue enough to say what they were curious about. And incidentally made it more work for them to keep asking "Why".
Great! One was a soldier in Iraq and Korea, got his masters in MechE and is a process engineer in a factory now. Looking to move on.
The middle son is already employed in Silicon Valley, in some startup I can't pronounce. Getting bored, might want to move on.
The third is a trained pianist and cellist. Now is in IT in Target's national deployment center in St Paul. Definitely interested in broadening his experience, and would welcome a call to talk about other opportunities.
