The 48 Laws of Power for developers
Lessons from Robert Greene's book, reread for software engineers who want more influence and respect at work.
Power in the codebase
You've probably heard of "The 48 Laws of Power", Robert Greene's controversial book. It's usually read as a guide to social dynamics in high-stakes environments. A lot of those laws, written for courts and kingdoms, turn out to apply to the tech world too. Even in a field that likes to think of itself as a meritocracy, reading the power dynamics is part of how people build influence and end up leading.
I'm not suggesting you run Machiavellian schemes in your next stand-up. This is about noticing the forces already at play in any organisation and being deliberate about them. Here are four of the laws, reread for people who spend their days in a codebase.
Law 1: Never outshine the master, or your tech lead
In our world the "master" is your tech lead, your manager or a senior architect. Wanting to show off a clever solution is natural, but there are moments when it's better to let the people above you have the win.
You might think, "but I am good at this, why hide it?" It isn't about hiding your talent, it's about how you present it. If you keep pointing out your lead's mistakes in public, or ship a solution that quietly bypasses their input, you aren't building allies. You're building rivals.
In practice that means offering solutions instead of only finding faults. "Your code is inefficient" lands very differently from "I've been looking at an optimisation for this function that could improve performance." It also means crediting people when a suggestion of theirs unlocked your work, and supporting your lead's direction during a big project rather than trying to overshadow it.
A secure leader will value your contributions. An insecure one may read them as a threat. Telling the two apart and adjusting is a skill worth having.
Law 7: Get others to do the work, but always take the credit
This one sounds harsh out of context. Reread for developers, it's about delegation, mentoring and influence: getting more done by enabling other people rather than personally writing every line.
As you move into senior and lead roles, you can't scale by coding more hours. Mentoring is where the leverage is. When you guide a junior developer through a problem and they deliver, you get credit for building a strong team and they get the experience. The same goes for code reviews: instead of fixing the bug yourself, walk the author to the fix. Their skills grow and the improved code reflects the team's work.
It also applies to architecture. You lay out the shape of a complex system, your team implements the modules, and when it ships the direction you set is visible in the result.
The point isn't to be lazy. It's to be a force multiplier. The credit that lasts comes from ambitious projects finished by a well-directed team.
Law 11: Learn to keep people dependent on you
This sounds possessive, but in a professional context it means making yourself genuinely valuable and hard to replace: skills, knowledge or relationships that turn you into a linchpin.
Partly that's job security. It's also influence. When people rely on your expertise, your opinions carry weight.
There are a few ways this happens. You become the person for a critical or unfashionable system that others avoid. You understand the business logic behind the code better than anyone, so when someone needs to know why a thing works the way it does, they come to you. You end up holding tribal knowledge about how legacy systems connect, the quirks of an old API, the reasoning behind an architectural decision. Or you become the bridge between development, QA, product and operations, and your ability to translate between them makes cross-team projects work.
The distinction that matters: don't hoard information. Become the person who solves the problems others can't, or solves them faster.
Law 18: Do not build fortresses to protect yourself
It's easy to disappear into your IDE with headphones on. Deep work is good. Total isolation is not, at least not for your influence or your growth.
"But I just want to write code" is a fair position. If you only ever interact with your immediate team, though, you miss opportunities and insights, and your reputation stops at the edge of that team.
Volunteering for projects that span teams widens your network and shows you can work across boundaries. Internal guilds, tech talks and meetups let you share what you know and meet people. Code reviews are a social surface too: ask clarifying questions, offer help, use them to see other parts of the codebase. Being approachable when someone needs help, even outside your own task, compounds over time.
Staying connected is how you hear about opportunities, gain allies and make sure your work is visible beyond your immediate circle.
Code and context
"The 48 Laws of Power" is an unlikely source of career advice for developers, but strip away the historical setting and much of it describes ordinary organisational dynamics. Technical skill matters most, and it's rarely enough on its own to reach the levels where decisions get made.
Understanding how influence works in the everyday interactions of your team makes you more effective. Not playing games, just seeing the board.