For anyone that knows me offline, you will understand I am a big fan of Star Trek (very cliche). Personally, the most fascinating part of the Star Trek universe is the different species and their cultures. For example; it’s interesting to understand how the writers envisage the human race will evolve sociologically in 200 years. The writers seemingly have taken key parts of the human psyche/ways of living from our near past and adapted those to different species throughout the Star Trek universe.
One of the more widely debated cultures is that of the Ferengi. The Ferengi outwardly portray the capitalistic and free trade nature of modern society, to an extreme. To a Ferengi, earning profit is the key driver of success, at the expense of all other societal and personal endeavours. As their society evolved they formed a list of 285 rules which everyone in their society should live by; these are known as the ‘Ferengi Rules of Acquisition’. I have attempted to take 3 of these rules and apply it to field of software engineering and the Engineering Leadership role specifically:
Rule no. 43: Feed your greed, but not enough to choke it.
As an Engineering Leader you will constantly need to facilitate discussions with the development team, and other stakeholders around priorities; i.e. ‘What are we going to work on next?’.
I can guarantee, in any organisation, there will be a strong thirst from the development team to spend time addressing technical debt, and rightly so. It’s important for Engineers to want to improve the status quo and better their playing field. The role we can play as Engineering Leaders along with Product Leaders is to understand that desire and act as a translation service to non technical stakeholders to help understand the cost/value of these proposals and engage buy in.
This is where we can use rule no. 43 to apply a thought pattern here. As an engineering leader feeding that desire for the pursuit of technical excellence is extremely important, for the technical estate and team morale. We need to be careful, however, that we don’t choke ourselves whilst doing so. We need to ensure that we pick the right battles and, ultimately, that these proposed changes will enhance the delivery pipeline.
Rule no. 55: Take joy from profit, and profit from joy.
This one is simple, celebrate your victories and inspect them honestly.
When a team delivers, and delivers well, it is of the highest priority that Engineering Leaders encourage and facilitate the team to celebrate their success, ‘Take joy from profit’.
It is equally important that to ensure we deliver well and deliver often in the future that we look back at this victory and have honest conversations as to what drove that success and look to replicate this where possible with actionable lessons. When you get the chance to ‘profit from joy’ take a step back.
Rule no. 217: Always know what you’re buying.
Two aspects of being a good Engineering leader are accountability and honesty.
The team must always be aware at any point in time, what they are buying. When we are refining work, or juggling priorities, or unfortunately setting deadlines a team thrives when they have a clear vision and honest purpose to this work. This will help the team understand and give them the power to push back on items that do no truly meet that vision and engage buy in to that work.
Engineering leaders need to understand delivery metrics, whether it’s idle time, velocity, lead time, etc. It’s incredibly difficult, I have never seen it work, to drive success without data driven decisions. You need to be accountable to the data so that you can make the right decision by the team and the wider organisation. When making decisions, you must ‘always know what you’re buying’.
I would be keen to hear other ways that you might look to apply lessons to Engineering Leadership from unconventional sources.
ngl I love the Rules of Acquisition.
Although I have never been an engineering lead in big tech, Rule No. 43 is what you play with client work in consulting or freelancing.
Nobody wants to pay extra to upgrade to Next.js 13 or refactor because you think TailwindCSS is cool.
However, if you think a change objectively speeds up future work and the client agrees, you can make incremental changes in preparing the app for an eventual transition to a new tech/stack.
Kudos for taking the risk and posting about it - I enjoyed the read! For me it's Harry Potter, and I'm afraid to share that with the world 😅