Whether we like it or not, most of us judge books by their covers. Sometimes that’s visual. Sometimes it’s the title.
But here’s a thing I find interesting. Having written a couple of books myself, a lot of thought goes into choosing the title to resonate with the viewing audience. And yet, sometimes a title that’s clearly had a lot of thought go into it turns out to have the exact opposite effect. For whatever reason, some titles are just so off-putting that I’ll avoid reading a book even if it’s been recommended to me.
Two books fell squarely into that trap for me:
Both were recommended to me in the early 2000s. I avoided both for years.
“Rich Dad Poor Dad” sounded aggressively money-driven.
As an Engineer, I was interested in building things that had an impact on the lives of others. Money was just a compensation for that (and for surviving), not a target for chasing wealth for its own sake. Based on the title alone, I assumed the book would be shallow, transactional, maybe even a cynical grab for cash.
When I finally read it around a decade later, boy was I wrong.
It turned out to be the single most influential book I’ve read. Not because of money, but because it reframed how I saw value creation. It shifted my thinking away from academic and technical elegance toward solving bigger business problems and how value actually flows through the systems we create.
Based on very rough estimates, I suspect >95% of people in our industry were/are like me and only ever focused on delivering the best technical solution possible without thinking of the bigger picture.
With this reframing, Rich Dad aligned perfectly with Engineering thinking, just at a different level of abstraction. This is just a personal opinion, but I feel that many of the 95% would be better Engineers if they thought more in business outcomes too.
.
“How to Win Friends and Influence People” was even more off-putting for me.
The title just sounds totally manipulative.
Social engineering. Charm offensives. Tactics for getting people to do what you want.
So I avoided it.
.
When I finally read it, I realised something that made me slap my forehead. Picture Homer (the philosopher from Springfield). Doh!.
The book isn’t really about influencing people at all.
It’s about serving others – reducing friction, defensiveness and fear so that people can do good work together. (do those factors ring any bells from this article in the Buyer – Seller Chasm series?)
Just like Rich Dad, it’s about creating value with others, rather than extracting value from others.
Carnegie repeatedly draws a line between creating and extracting – between sincere appreciation and flattery, between alignment and coercion, between helping someone succeed and extracting compliance. It’s a fine line though. The book absolutely can be misused, but its core message is about creating value for others, not tricking them.
Despite being nearly a century old, How to Win Friends remains one of the best-selling books of all time, with more than 30 million copies sold worldwide and new editions still selling today. It must have something going for it!
.
Dale Carnegie grouped his ideas into four sections:
A) Fundamental techniques in handling people
B) Six ways to make people like you
C) Twelve ways to win people to your way of thinking
D) Nine ways to change behaviour without resentment
.
I’d now like to put Carnegie’s original concepts into the context of OSS/BSS projects and products:
A) Handling people in delivery programmes
Don’t criticise, condemn or complain
In OSS/BSS terms, this means separating fault from learning. Incidents, defects and missed milestones should trigger root cause analysis, not reputational damage. Teams that feel safe surface issues earlier and tend to get better outcomes. Teams that get into chest-beating ego exercises or factional wars have been the worst (and least productive) projects I’ve worked on.
Give honest and sincere appreciation
OSS/BSS transformation projects can be brutal. Regardless of their complexity and challenges, gratitude and recognition are easy ways to lift the spirits of the team. Thank the people doing the less “sexy” tasks (eg data cleansing, release management, test development and testing, migration reconciliation, etc). Every major OSS project has a million activities to be done (which is why we use WBS). Projects fall over if any are overlooked, so it’s important to recognise and appreciate every contributor.
Arouse an eager want
It’s easy for me to say. I am Passionate About OSS. I am an evangelist for these exciting projects. Unfortunately, not everyone else feels the same way. However, our projects have such a widespread impact (ie almost every role in a telco is touched by our OSS/BSS) that we need to involve and excite many. We generally start by framing the benefits in terms of what it adds (or removes) from each stakeholder’s world, from the perspective of what’s important to them. Increased sales, lower churn, fewer escalations, fewer manual reconciliations, fewer audit findings, fewer night calls. The list goes on!
.
B) Making stakeholders want to work with you
Become genuinely interested in other people
This ties in perfectly with the previous point. To understand what rocks each stakeholder’s world, you need to show an interest in them and understand what’s important for them. Learn what keeps each stakeholder awake. NOC alarm floods, billing accuracy, regulatory exposure, release freezes, vendor penalties. Titles tell you nothing. Conversations with stakeholders do.
Smile
Optimism and calm beats clever in every crisis call, of which there’s been a few on every major OSS/BSS transformation I’ve been involved with. John C. Maxwell was quoted in our earlier article, “You can cultivate optimism by…. remaining up-beat even when you’re beaten up”
Remember names
We all know that a person’s name is the most important word in the world to them… But who am I kidding? I’m getting terrible with names in my old age and I know I have to get so much better at this one! Thank goodness for LinkedIn!!
Be a good listener
This is another “table-stakes” criteria that we all know is important…. but also need to get better at (myself especially!). Read the first point above about great-ape behaviours that are commonplace in OSS projects. That’s a case of more talking (and chest-beating) than listening.
Talk in terms of their interests
Not just in the language of their interests, but their language full-stop! It amazes me when vendors give product demonstrations using demo data, stories and use-cases relevant for themselves. It’s rare to hear vendors speak the language of the user (eg their device types, network topologies, service types, etc), to provide an anchor against what they’re familiar with, unless specifically requested to do so. This article discussed the different world views of different roles and what “success” looks like…. within the same telco.
Make people feel important sincerely
Acknowledge expertise. I really dislike it when external advisors come in and claim intellectual superiority over the client team. I’ve been working in this field since 2000 and have seen a lot along the way, but when starting a project, I don’t have even the most basic of tribal knowledge of the client. Each stakeholder within the client always has knowledge, skills, relationships, etc. I always have so much to learn. Always will!
They’ll also be responsible for using and running the OSS/BSS “after the boys of summer have gone” (ie the implementation team). As such, it’s vitally important to acknowledge expertise and credit contributions publicly.
.
C) Winning people to better solution design
Avoid arguments
There are always many different ways to implement OSS or overcome issues along the way. As a result, differences of opinions are unavoidable. The grey area on this one is where a constructive discussion ends and arguments begin. Like the time where I saw one very senior architect stand in the corner covering his ears saying “I can’t hear you,” whilst another was shouting his opinion at the first architect. Needless to say, that problem was never resolved. 😀
Respect other opinions
Same as the converging Venn Diagram above. Others will always have different knowledge and expertise than you. Respect it and learn from it!
Admit mistakes quickly
Name someone who has never made a mistake on an OSS project and I’ll show you a person who has never worked on an OSS project. Trust grows when personal vulnerabilities and mistakes are acknowledged.
Begin in a friendly way
Due to common OSS procurement approaches, relationships between buyer and seller are often flawed from the start. The same link provides a few thoughts about starting in a friendly way and hopefully maintaining a mutually beneficial marriage for years to come.
Get early agreement
To me it all starts with transparency via WBS + RACI charts. They act as a plan on a page where everyone can clearly see, discuss, negotiate and agree on who’s doing what.
We base our transparency-setting around the TM Forum Transformation Project Framework (TPF).
You’re welcome to navigate around the full WBS below by logging into DivvAI here (or clicking on the image below). Alternatively, we’d be delighted to give you a walkthrough.
Let others talk
This is closely linked with a few other items listed above, including being a better listener and respecting opinions. Constraints, requirements, pain-points, etc all emerge when people are allowed to fully explain their world.
Let others feel ownership
Many things go wrong on OSS projects. We need to have a cohort of project champions, those who deeply feel ownership over the project and it’s outcomes, to keep it going. Champions help to overcome the inevitability of what Jim Rohn refers to as the Law of Diminishing Intent.
See their point of view
We’ve probably already covered this one via a few responses above, including the world-views table.
Be sympathetic
There are almost too many examples of why OSS projects require high levels of empathy (for colleagues, clients, competitors, etc). BAU obligations / priorities, budget cycles, procurement rules, issues in personal lives and contract boundaries are just a small number of many real constraints, not excuses.
Appeal to higher motives
For me, the higher motives are easy. OSS/BSS underpin the every part of the telco industry (see image below), which in turn underpins our modern lifestyle. We’re running the most geographically widespread and arguably most complex machines on the planet (ie telco networks). We’re building some of the most important solutions I can think of. But for others, their higher motives might be very different – operational pride, customer trust, engineering quality and leaving the platform better than you found it. You have to understand the higher values before you can appeal to them! 😉
Make ideas vivid
There’s a reason I’ve written nearly 3,000 articles, which have incorporated around 700 images like the examples above. To make ideas vivid that inform and inspire others. To highlight higher motives. That and I just like telling OSS stories! How do you make your ideas vivid for others? How do you get others to buy in to your visions?
Challenge constructively
I was a tennis coach as a way of earning my way through university. I loved the challenge of inspiring youngsters to play shots they’d never played before. To see their growth as tennis players. The same is true today. Our advisory and consultancy work involves quite a bit of coaching and encouraging. See how the Gym and Golf can help you get the OSS of your dreams.
.
D) Changing behaviour without resentment
Begin with praise
The Buyer Seller Chasm is mostly a combination of human factors such as trust, risk, fear, etc. We need to reduce the size of the chasm to get a transformation moving. That often requires encouragement and confidence building.
Highlight issues indirectly
Call attention to people’s mistakes indirectly. Surface issues as system effects, rather than personal failures, or “your team messed up.” As a wise project manager once told me, “Assume cock-up rather than conspiracy” (ie assume it was an accident and they’ll learn from it rather than an intentional fault)
Admit your own mistakes first
Same as “Admit mistakes quickly” above really.
Ask instead of order
One of my closest friends is a counsellor of troubled teens. He always suggest to ask questions that guide a person towards their own discovery rather than directing solutions. Good questions surface better designs than directives. This is another of the long list of dot-points here that I need to get better at
Protect dignity
Handle performance issues privately. Show faith in others publicly.
On my first-ever OSS project we had a client Project Coordinator who took every opportunity to slam the company I was contracting to. He was relentless. But then one day, he was being berated by his boss in a joint client/vendor meeting. I stood up for him and pointed out the challenges that he faced in being able to deliver what his boss expected. After that, his stance against us softened appreciably and he because an ally in getting the project delivered. That was never my intent. I was just doing what I thought was right. But it was a huge point of learning about human psychology for me.
Praise improvement
We’re all quick to praise exponential improvements and breakthroughs. It’s just as important to celebrate incremental progress in hard areas such as this project. This story discusses the dilemmas we often feel in relation to exponential or incremental improvement. The young engineer I talk about here was deserving of praise regardless of which path we took.
Set high expectations
Similar to establishing higher motives above. I strongly believe in the need to set higher expectations for ourselves (and others). The biggest career growth points I’ve experienced have exactly aligned with the biggest challenges and being taken furthest outside my comfort zone. As Dr. Wayne Dyer said, “It’s never crowded along the extra mile.”
Use encouragement. Make the fault seem easy to correct
Make improvements feel achievable by breaking change into small steps with clear completion / acceptance criteria and visible benefits. Sounds a lot like our use of WBS again doesn’t it?
Make the right thing rewarding
Make the right action genuinely rewarding by removing friction, providing templates, clarifying decisions and reducing rework.
.
Most OSS/BSS failures aren’t technical. Well, maybe a little bit. Maybe a lot.
But more decisively, they tend to be human-factor failures disguised as technical challenges / problems / failures.
To my surprise, “How to Win Friends and Influence People” isn’t about manipulation.
It’s about helping other people win.
I’m a big believer that the more value I create for others, the more value seems to come back to me in return. I don’t know how or why, but it just seems to be true.
And that is exactly how complex transformations work too. Create value and value will return. The more you put in, the more you get out.
Therefore, I have this strong sense that if OSS/BSS implementation teams focused less on influencing and more on creating value for the humans inside the system, delivery timelines would shrink, risk would be mitigated earlier and trust would shrink the size of the Buyer-Seller Chasm that otherwise adds to the hidden cost that nobody budgets for.
.
PS. If you’d like to have a look at some of the other books that have had a major impact on me, please check them out at An Uncommon List of OSS Books.
The last four articles have explored the way some telcos are using AI technologies counter-productively today – AI entanglement, transformation planning, dependency visibility and the
I’ve never achieved true autonomy in an end-to-end, complex telco environment. What follows is a hypothesis. I’d love to hear your thoughts and clarifications. What
Many (myself included), believe that recent progress in AI-based technologies should accelerate digital transformation (even if only by inspiring us to think differently about the
In Part 1 of this series, we explored an uncomfortable paradox. AI is being excitedly positioned as the key to telco transformation, yet many initiatives
