If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Escalating Isn’t Throwing the Problem Upstairs

Escalating technical issues is one of the most misunderstood responsibilities in software engineering leadership. When done right, it builds trust. When done wrong, it erodes confidence fast. I want to share the simple, high-trust way to escalate problems.

You see, too many engineering leaders misunderstand what escalation really is.

They think it means alerting their boss. Ringing the alarm. Forwarding the pain.

“Hey, this broke—someone above me needs to care about this now.”

I’ve seen it happen countless times: a manager or tech lead kicks the problem up the chain with little context, no recommendation, and zero accountability.

That’s not escalation. That’s abdication. And it undermines your credibility.

True escalation is a leadership skill. It’s about helping people above you make a better, faster decision with less cognitive load. Done well, escalation is a signal that you are in control, even when things are going wrong.

Done poorly, it’s a signal that you’re over your head.

So what does effective escalation look like?

Here’s the simple framework I teach every engineering manager on my teams:

1. What was the good state?

Start by establishing the baseline.

What was working? What did we expect?

Example: “We normally make data available within 5 minutes of a complete simulation run, well below the 15 minute SLA.”

This grounds your audience in reality before things went wrong.

2. What changed?

Describe the deviation from that baseline.

What broke? What’s different now?

Example: “As of this week, the new data analysis is taking 14 minutes.”

Now they understand what went off the rails.

3. What’s the impact?

This is where you give them a reason to care.

Who is affected? What are the consequences if this continues?

Example: “As a result of the longer data analysis, the total time to make the data available is 17 minutes and we’re now breaching the SLA. There are financial penalties tied to this breach.”

Make it concrete. Emotional if necessary. Don’t bury this.

4. What do I recommend and what do I need from you?

This is where most escalations fail. You don’t just show the problem, you own the next step.

Offer a path forward and make a clear ask of the person you’re escalating to.

Example: “We recommend temporarily disabling the new analysis and rolling back to the old one. I need your help getting alignment with the Data team as we’ll delay their project and impact their customers.”

If you want to be seen as a strategic, dependable leader in engineering, learn to escalate like a peer, not a passenger. Show them what changed, what matters, what you’ll do about it, and how they can help. You’ll gain more trust and influence with this one habit than with a hundred status updates.

Three Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I have a course on building your personal brand on LinkedIn, it explains how I’ve built an audience over over 180,000 on LinkedIn and changed my life.

3. I run a YouTube channel sharing advice on software engineering.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: How To Go From Invisible to In-Demand

In today’s fiercely competitive tech industry, personal branding is an important tool for software engineers and founders. It influences how others understand your skills, values, and contributions.

A personal brand can help you build credibility, grow your network, and open up opportunities - whether you're looking to advance your career, attract collaborators, or promote a product.

But how do you build you personal brand?

There’s two main ways…

In Person

1. Know what you stand for - your values, strengths, and what kind of work or problems you’re passionate about. Be ready to communicate this clearly in conversations.

2. Show up consistently - Attend meetups, conferences, and community events regularly. Being present in the same circles helps people associate your name and face with your area of expertise.

3. Listen and contribute - Ask thoughtful questions, share relevant experiences, and offer help when it’s useful. This builds trust and shows that you're engaged and credible.

4. Follow up - After meeting someone, follow up with a short message. Keep in touch occasionally by sharing something useful or checking in.

On Social Media

Here’s the 10 step process I’ve used to build a personal brand on LinkedIn (193k) and X (11k):

1. Determine your goal - why do you want to build a personal brand?

2. Identify the relevant audience - who do you want to reach (that can help you with 1)?

3. Make your profile interesting to the audience - be credible.

4. Identify people you want in your network - use the search to find people you want to connect with to help you with your goal.

5. Reach out to people and build relationships - talk to them as a person.

6. Share original content that resonates with your audience - show people what you know, what you can do, what you are interested in or what you are learning.

7. Engage with your audience - See 5! It’s a social media!

8. Comment on other people’s content - you guessed it, more networking and building relationships.

9. Build a content pipeline - make it easy to create content regularly by adopting systems.

10. Level up your copywriting game - the better you write, the more likely people are to read.

That’s it!

Want to do it with a cohort of other people and discuss it with them and me live? Join the course I’m running that starts May 13th. Details here: https://maven.com/coding-challenges/linkedin-for-engineers.

As a reader of Developing Skills you can get 20% off with the code: DSREADER

Regards, John

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Understand Influencing Styles and How To Use Them To Drive The Outcomes You Want.

When we want to persuade people to do something, change their mind or change their behaviour most of us default to the the influencing style that we feel comfortable with, which is often logical and data driven.

Unfortunately it’s rarely the most effective style, particularly when dealing with people who aren’t our immediate teammates.

In this article I’m going to introduce your to four influencing styles and explain how and when to use them.

The Logical And Rational Style

The logical and rational style of influence places and emphasis on logical reasoning and objective data. The focus is presenting clear, well structured and data-driven/evidence based arguments.

This approach is effective when a well-structured and logical argument is required to influence decisions. To make it work requires that the arguments are presented in a logical sequence creating a clear narrative that is easy to follow.

The Emotional And Personal Style

The emotional style of influence focuses on appealing to the emotions of the audience. It recognises that people are first and foremost emotional beings and our emotions heavily influence how we feel and the decisions we make.

This style is effective when it evokes strong emotions, creating a sense of urgency, desire, fear or hope, which in turn makes the message more memorable and compelling. This style needs to be used authentically and with care, which will build trust and strong connections with the audience.

If abused it is manipulation, which will undermine trust.

The Cooperative And Collaborative Style

The cooperative and collaborative style of influence focuses on building positive relationships with people. The focus is on understanding the needs of others, asking questions to find common ground and seeking to create a sense of unity. The focus is on finding mutual wins that meet the goals of all parties.

To use this style effectively requires:

Active listening: seeking to understand the point of view of others, their concerns and their needs. It involves showing genuine interest and empathy.

Collaboration and teamwork: involving others and creating a space for them to contribute, expressing gratitude for their contribution and welcoming diverse perspectives.

Building rapport and trust: investing time into building real relationships with the people involved and earning and retaining their trust.

Building consensus: engaging in constructive dialogue to explore different points of view and facilitate collective decision making.

The Assertive And Experienced-Based Style

This style is direct, assertive and confident, using confidence, knowledge and authority to influence others effectively. To use this style express ideas, opinions and recommendations with conviction and provide supporting evidence, expertise or authority to support them.

There is a fine line between being assertive and being overly pushy and forceful. Take care to avoid overstepping the mark and alienating the intended audience.

What Now?

Next time you need to influence, think about the person you need to influence and which of these styles will work best with them. Be mindful that it may be more than one.

Which style most suits you and which do you find hardest to use?

Three Ways I Can Help You Level Up As A Software Engineer:

1. I’m available as a coach to help you or the software engineers on you team level up.

2. I run a YouTube channel sharing advice on software engineering.

3. I have a course on building your personal brand on LinkedIn, it explains how I’ve built an audience over over 190,000 on LinkedIn and changed my life.

Hi! Remember me? It’s John from Developing Skills!

I’ve taken a few months off writing here due to other commitments, but I’m back with a renewed focus on the delivery, leadership and soft skills that software engineers and software engineering leaders need to take their careers to the next level.

I hope you’re excited to join me on that journey, if there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Learn Something Different - Four Underrated Ways to Level Up as a Software Engineer

When we think about improving as software engineer, we often reach for the obvious: learning a new language, mastering a new framework, or finally getting fluent with that algorithm book that has been gathering dust on the shelf.

But some of the most powerful ways to grow aren't technical at all — and they’re often overlooked. Here are four underrated ways to accelerate your growth and impact as a engineer.

1. Pair With Non-Technical People

Yes, really. Sit with a product manager, a sales rep, or a customer support agent. You’ll start to see the business through their eyes — the constraints they navigate, the language they use, the goals they chase, the user feedback they receive.

This kind of pairing offers two huge benefits:

• You gain commercial awareness. You’ll understand how your code creates value, how decisions are made, and how features are prioritised. That context makes you a more strategic, product-minded engineer.

• They gain engineering insight. Many people in a business have no idea how software gets made. Pairing helps demystify what we do and builds trust across teams.

2. Read A Book On Leadership

You don’t need a manager title to lead. In fact, many of the most effective leaders in engineering are individual contributors who’ve learned how to lead without authority.

Great leadership helps you:

• Influence decisions and outcomes beyond your job description or even your team.

• Create momentum around ideas you care about.

• Increase your impact across your team and organisation.

Here are two great books you could start with:

1. The Art of Leadership by Michael Lopp

2. The Five Dysfunctions of a Team: A Leadership Fable by Patrick Lencioni

3. Take A Course On Writing

Clear writing is a superpower. It helps you share knowledge, make decisions, explain ideas, and influence others.

As software engineers, we already write a lot: code, comments, documentation, pull requests, user stories, technical designs, architecture decision records (ADRs), and even the occasional Stack Overflow answer or LLM prompt.

But writing well gives you leverage. It makes your thinking easier to follow, your arguments more persuasive, and your ideas more likely to be heard and acted on.

If you’re not sure where to start, try a short course on technical writing, persuasive writing, or business communication. Your future readers (and your future self) will thank you.

Alternatively consider these three books:

1. Simply Said: Communicating Better at Work and Beyond by Jay Sullivan

2. Writing Tools: 50 Essential Strategies for Every Writer by Roy Peter Clark

3. The Art of Explanation: How to Communicate with Clarity and Confidence by Ros Atkins

4. Learn Sales

Sales? Yes, sales. Not in the cheesy, pushy way, you don’t need to become a used car salesman! Learn sales in the deeply human way of understanding needs, telling compelling stories, and motivating action.

Knowing how to sell helps you:

• Sell yourself — on your resume, in interviews, and inside your company.

• Sell your ideas — when you're proposing a refactor, pitching a new tool, or leading a technical initiative.

• Sell your vision — especially important if you’re building something new, like a startup, an open source project, or an internal platform.

Sales is ultimately about empathy, storytelling, and influence — all essential skills for any developer who wants to make a difference.

In short: if you want to stand out as a software developer, don't just sharpen your technical skills — expand your influence, your communication skills, and your commercial awareness.

These are the things that turn good developers into great ones.

Want help growing your influence as a developer? Hit reply — I’d love to hear where you’re at and how I can help.

Three Ways I Can Help You Level Up As A Software Engineer:

1. I’m available as a coach to help you or the software engineers on you team level up.

2. I run a YouTube channel sharing advice on software engineering.

3. I have a course on building your personal brand on LinkedIn, it explains how I’ve built an audience over over 190,000 on LinkedIn and changed my life.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Learn To Learn Effectively

“Hey John, we need to build a 3D animation for this page, any idea how we do that?”, Steve asked.

“Do we have a designer who can create it and then give us an animated GIF?” I replied. Steve smiled and said, “No. That wouldn’t work anyway, we need to render some text on it that the user has entered”

I thought for a moment, not sure if this would be possible. Then I opened up Internet Explorer and headed over to the Java website to check out if there was any 3D support in Java, maybe we could build a Java applet that would render the 3D image.

It turned out there was Java 3D had been available for a year! I installed the latest JDK, version 1.1 and got to work building prototype.

The next afternoon I was able to demo a crude version of what we needed. “How did you learn to do that so fast?” asked Mike after the demo.

That’s happened to me a lot throughout my career and the answer is that I’ve continuously optimised my approach to learning. Now I can usually pick up the basics of a new topic very quickly.

So how do I do it?

Firstly I figure out what I need to know. What are the key things I need to learn to achieve the goal of this learning. That often starts with one of more questions I want to answer. The more precise these questions are the clearer the focus of the learning.

I then use these questions to:

1. Start reading around a topic and identifying what the foundational knowledge for the topic is.

2. Start positioning the knowledge I have/will acquire within the big picture of the topic - the goal here is to try and avoid becoming the ‘expert beginner’.

I then combine this knowledge with steps that are very similar to the ones Josh Kaufman’s outlined in the book The First 20 Hours, specifically:

1. Focus exclusively on learning just this one topic for the next 20 hours - don’t try to acquire other new skills at the same time.

2. Break the knowledge/skill down into smaller parts and acquire them one at a time through this process.

3. Get the tools I need to acquire the skill.

I tend to be a bit obsessive about learning new things so it’s likely I’ll go all in on the topic immediately, getting through the first 20 hours in 2 to 3 days. That immersion really helps particularly if you’re applying the knowledge as you gain it. Which is why I like to have questions to answer or something to build (i.e. the reason for Coding Challenges).

Do this and you’ll learn more about a subject in 20 intense hours than most people will in 80 hours of unstructured learning.

Three Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I have a course on building your personal brand on LinkedIn, it explains how I’ve built an audience over over 180,000 on LinkedIn and changed my life.

3. I run a YouTube channel sharing advice on software engineering.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Pick Your Mentor Carefully

A couple of months ago I surveyed software engineers on what mentoring they would like. Why? Because a number of people had asked me if I provided paid mentoring.

The results of the survey reminded me why I’ve avoided offering mentoring so far. Of the 154 responses I got to the survey, there were 81 different goals that they wanted my help with.

Some were well within my wheelhouse. I’d love to mentor new managers on the core aspects of their role, from stakeholder management, through conducting effective 121s to how to effectively coach their team. I’d be delighted to coach and mentor software engineers on soft skills and communication skills.

Others were bizarre, wanting my mentoring for topics like:

• Advanced C# - sorry I haven’t done any C# since 2007, I’m the wrong person for that!

• Advanced Android development - Sure, I once built an Android app because I’m curious, but that was at least ten years ago too. So sorry, I’m not the right person for that.

• Become a Staff engineer in 1 year - from someone with less than a year of professional experience! I’m sorry, but that doesn’t happen. OK sometimes it happens through title inflation, but that’s just having the title, not the aptitude and skills.

So here’s some advice for software engineers and software engineering leaders who have rightly identified that a mentor can help them accelerate their career.

🚨 Before That, I Have Exciting News To Share. 🚨

I’m re-launching the Coding Challenges Live course series beginning with the Redis edition.

Coding Challenges live is a cohort based intensive course that runs for one week during which you’ll implement a lite version of a Redis server. Starting from scratch we’ll work through building a clone of the original Redis server and extend it to support the RESP2 protocol and some additional commands.

This course touches on a wide variety of topics that are applicable to general programming, for example:

👉 Parsing skills. These can be applied to a variety of problems including data munging, scraping, protocol implementation and more.

👉 Understanding network programming. This can be applied to making more robust, secure and scalable distributed systems.

👉 Experience handling concurrency and parallelism in software. Giving you the core skills to build scalable distributed systems.

👉 Testing. Network servers are complex system software with components that can interact in non-trivial ways. Figuring out how to test them is a challenge. You’ll explore unit and integration testing.

This course is for experienced programmers who'd like to take on the challenge of building systems software, specifically a lite Redis server. Not many programmers actually get the opportunity to write network servers or systems software. So, if you're curious about what writing a network server is all about, this is the course for you.

This course is entirely project focused. The goal of the course is not just to learn how to write a server, but also how to approach the problem of server software. Part of the course involves group discussion about problem decomposition, coding techniques, design tradeoffs, testing, and other related topics. The rest of the time is spent working on individual coding.

Coding examples are written in Python. However, the project involves no third-party libraries, esoteric language-specific features, or language-dependent tooling. As such, you're free to implement the project in any programming language that you wish. Writing a server is a great way to learn a new programming language too.

You might not think that you're ready to write a server, but if you've been coding for a while and know the basics of data structures, it's something that you can tackle. No prior background in network servers is required although awareness of common programming language concepts (e.g., types, functions, classes, scoping rules, etc.) is strongly advised.

You can find out more / sign up on Maven here:

https://maven.com/coding-challenges/challenge-redis?promoCode=EARLYDS

If you sign up before 12th November you can get 20% using the code: EARLYDS

OK, back to mentoring…

Selecting The Right Mentor Is Key

To make it work for you, you need the right mentor and that doesn’t necessarily mean someone you currently admire. Here are some tips to help you choose someone who can effectively guide you in reaching your goals.

1. Define Your Goals

Before seeking out a mentor, clearly define what you’re hoping to achieve. Do you want to strengthen your technical skills, gain insight into industry best practices, or receive guidance on career progression?

Knowing your goals will help you find someone who can meet your specific needs, different mentors may bring different strengths. It’ll also help you make the most of your time with them as you can clearly articulate what you’re looking for from the relationship.

2. Look for Relevant Experience and Skills

Choose a mentor with a background that aligns with your areas of interest. A mentor with this relevant experience can offer insights that are practical and directly applicable to your work. If you’re aiming to move into a leadership role, for example, seek someone who has successfully navigated that path.

3. Find Someone Who Shares Your Values and Approach

A good mentorship relationship is built on shared values and a compatible communication style. Find someone whose approach to work, problem-solving, and learning resonates with you. This alignment creates a foundation of trust and respect, making it easier to be open about challenges and receive constructive feedback.

4. Prioritise A Mentor With A Growth Mindset

Look for a mentor who is invested in continuous learning and has a growth-oriented mindset. A mentor who stays up-to-date with industry trends and emphasises personal and professional development will be better equipped to help you adapt to changes and pursue new opportunities. None of us know everything, there’s always more to learn.

5. Start with a Trial Period

It is hard to know if someone is a good fit until you’ve worked with them. A good mentor should be suggesting that you start with a few trial sessions to assess if the relationship is productive and if their guidance is helping you achieve your goals. This can save time and ensure you invest in the right mentorship.

6. Reach Out with Specificity and Enthusiasm

When you’re ready, reach out to potential mentors with a clear message about why you want to work with them and what you’re hoping to get from the relationship. Being specific about what you’re looking for and what your goals are. It will help them decide if they’re the right fit and allow them to be properly prepared to work together.

How To Ask Them To Be Your Mentor

There’s more than one way to ask someone to be your mentor, but to get you started here’s a template you can use for an email, slack message or social media DM. If you’re asking in person hit the same key points:

Dear [mentor’s name],

My name is [your name], and I currently work as a [job title] for [company name]. I've been following your work and have been impressed by your achievements, especially [mention a specific project, achievement, or skill].

As I am keen to [your primary goal], I believe your insights and expertise would be invaluable in helping me grow professionally.

My main goals are:

1. [your primary and specific goal one]

2. [possibly a second specific goal]

3. [optionally specific goal three, but no more]

To achieve them I believe I need to focus on these skills:

1. [list at least one specific skill]

2. [probably a second specific skill]

3. [and perhaps a third specific skill]

Are you open to taking on any new mentees at this time? If so what would be the next steps?

Many thanks for your time,

[Your name]

If you’re interested in any mentoring I might offer in future, please feel free to reply to this email or fill in the mentoring survey.

Regards, John

Three Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I have a course on building your personal brand on LinkedIn, it explains how I’ve built an audience over over 180,000 on LinkedIn and changed my life.

3. I run a YouTube channel sharing advice on software engineering.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: How To Prep For DSA Style Interviews

I dislike DSA style interview questions. A LOT!

I also understand why the big tech companies use them and I realise that whether I like it or not more and more software engineering interviews use them.

So here’s how I would tackle then and subsequently how I would prepare for them.

Doing The Interview

Following these six steps will maximise your chance of performing well in most coding interviews and in particular DSA focused interviews.

1. Listen carefully, then repeat the question - pay careful attention to the problem as your interviewer describes it. Then repeat it back to them in your own words. This will help ensure you’ve understood it and demonstrate to the interviewer that you have. Then if you haven’t they’ve got a chance to correct you before you spend time solving the wrong problem.

   Repeating the problem in your own words will also help you think through the problem more clearly, putting you in a good position to…

2. Check you assumptions - either by design or by accident (it depends on the quality of the interviewer) most of these problems are in some way ambiguous. Start writing down your assumptions and then ask questions to verify them. When you’re writing, say it out loud too - tell the interviewer what you are doing, aka ‘think out loud’ - they can’t read your mind.

   It’s always worth checking the following:

   1. Will the input fit in memory? Alternately what is the min/max/typical size of the input.

   2. Is the input always valid?

   3. Will the elements be unique / are duplicates allowed?

   4. Is there only one solution?

   5. Can I assume the input is sorted/not sorted (where appropriate)?

   6. What should it do for edge cases? For example, empty and single element inputs.

   7. What are the time/space constraints?

   8. If there is multiple outputs, should they be ordered?

3. Create some test cases - write down some example input and the expected output. This gives the interviewer another chance to spot any errors in your assumptions and some examples to work through when you begin to…

4. Sketch out some solutions - think out loud about some solutions. I’d often think about the brute force option first, the describe the time and space complexity of it. That gives you an upper bound for a target solution. Then consider a best cases (lower) bound. For example for an array based question that’s likely to be N, given you’ll need to visit every element at least once. Remember faster code often needs more space - consider the space / time tradeoff.

   Consider whether the best data structure is going to be an array, a linked list, hash table or tree. Having considered the best data structure and sketched out your solution it’s time to…

5. Write working code - Using the language you know best (more on this in preparing for the interview) start writing down working code. Implement the solution you sketched out. This should be the shortest of these six steps as you’re just writing up the solution and thinking you’ve done so far. Then when the function is done, be sure to…

6. Test your code - work through those tests cases you created in step 3. Check that your code handles the edge case and check that each example results in the right output.

Preparing For The Interview

The reality is most software engineers will fail a DSA style interview without preparation. It’s a skillset that we just don’t use regularly. So if you know it’s coming, you need to prepare. Here’s how I would prepare for the interview.

1. Use the language you know best, if in doubt use Python - you want to spend as little time as possible actually writing the code, leaving you as much time as possible to understand the problem, create tests and brainstorm solutions before writing the code, as well as leaving time to test the solution after writing the code.

   Therefore pick a language you know very well, or if in doubt pick Python as it’s fairly terse and the core data structures are all part of the language.

2. Learn Big O - Big O notation gives us a common notation to describe the limiting behaviour of a function / algorithm. Check your favourite algorithm text book for an explanation. Or hit reply and tell me I should write a post explaining it!

3. Practice - like many things in life, from building software to playing guitar we have to do the thing to get better at the thing.

4. Practice effectively - there are many people on social media boasting about doing 1000s of DSA problems, that’s wasteful. Group the problems by type, i.e. string related, two-pointer, linked list, etc. and solve enough of each type to be familiar with it then move on. Be consistent with your practice too, it’s better to do 30 minutes every other day than 3 hours once then nothing for two weeks.

5. Learn the patterns - There are common patterns and approaches. Learn what these are, i.e. two pointers for finding pairs, binary search to find something in a sorted list, sliding window to track a subset of elements.

6. Build muscle memory - return to some of the problems you’ve solved before and redo them. Get used to writing common implementations in the programming language you use.

7. Practice doing the questions as if you were doing the interview - don’t be tempted to visit one of the popular websites and read the problem, write some code and try it. Try to make your practice reflect doing the interview. Read the problem statement out loud. Reword it and make notes. Think out loud throughout.

If you do lots of DSA interviews, what other tips would you add?

Three Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I have a course on building your personal brand on LinkedIn, it explains how I’ve built an audience over over 180,000 followers on LinkedIn and changed my life.

3. I run a YouTube channel sharing advice on software engineering.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Increase Your Luck Surface Area

When I started my career as a software engineer I was lucky enough to get to work on the most interesting project the company had.

Then when that project was done, I moved on to the next, new and very interesting project. Weirdly, when that project was over I moved to a third really interesting project. At this point people around me started commenting on it: “Hey, John, you’re so lucky, you get to work on the best projects and you’re just a junior developer. I wish I could work those projects instead of what I’m doing!”

Fast forward eighteen months, I’ve started my own business and it’s going well. I’ve managed to land a couple of good clients and we’re making a reasonable profit. I start to hear the same thing again: “Hey, John, you’re so lucky, you started a business and a couple of good clients just fell in your lap. I’ve struggled to grow my business for two years and never got such good clients”.

Before that I’d never regarded myself as a lucky person. I still don’t. So what happened?

I believe the answer lies in the idea of a Luck Surface Area, as described by Jason Roberts in 2010. Here’s what he said:

“If there's one thing I've discovered in recent years it's this. The amount of serendipity that will occur in your life, your Luck Surface Area, is directly proportional to the degree to which you do something you're passionate about combined with the total number of people to whom this is effectively communicated. It's a simple concept, but an extremely powerful one because what it implies is that you can directly control the amount of luck you receive. In other words, you make your own luck.

Here's how it works. When you pour energy into a passion, you develop an expertise and an expertise of any kind is valuable. But quite often that value can actually be magnified by the number people who are made aware of it. The reason is that when people become aware of your expertise, some percentage of them will take action to capture that value, but quite often it will be in a way you would never have predicted. Maybe they'll want to hire you, or partner with you, or invest in you, or who knows what. But in whatever way it happens, it will be serendipitous.”

He went one step further and formalised it in the equation:

The point is simply; the more you do and the more people you tell about it, the larger your Luck Surface Area will become. Or If you prefer a graphical representation:

To me this explains why I was “so lucky” and got to work on the interesting projects in my first role as a junior developer and then managed to win some good clients and grow my business. I was making my own luck through a combination of my passion for what I was doing and my constant drive to share what I was learning and doing with others.

I have continued to do this throughout my career.

As I pursued my business I wrote a book, I networked, I wrote for industry journals, I spoke at conferences and presented on entrepreneurship at local chambers of commerce and the University of Bath.

Later, as blogging took off I wrote a blog for 18 months, gaining over one million monthly unique visitors and subsequently being featured in magazines like Mens Fitness, invited to appear in several TV shows and offered a book deal.

Fast forward to 2023 and I started writing again, this time on LinkedIn. I set out to build an audience of software engineers in the hope that it would lead me to a business idea I was passionate about.

As a result of writing on LinkedIn I ended up creating , I have offered a book deal, offered several lots of sponsorship, offered consulting, been invited to speak at several conferences, and been invited to be a guest on numerous podcasts.

I’ve also done a number of collaborations with great people like and and have more lined up for the future.

So I believe you can create your own luck by doing and telling.

So How Can You Get More Lucky?

My advice is build a personal brand. Become known for what you do, by doing it and telling others about what you do, why you do it, how you do it and how you’ve learned to do it.

If that sounds good to you, here’s a simple 6 step plan to create your personal brand:

1. Determine your goal - why do you want to improve your personal brand?

2. Identify the relevant audience - who is the audience that you need to build your brand with to reach your goal?

3. Make yourself interesting to the audience - build your credibility with them.

4. Identify people you want in your network - who can help you reach more of your audience.

5. Reach out to people and build relationships - be interested in people and provide them with value.

6. Keep in touch.

All those steps are the same for in-person and online networking. 5 of the additional things you can do to grow your personal brand are:

1. Share original content that resonates with your audience.

2. Engage with your audience.

3. Comment on other people’s content.

4. Build a content pipeline.

5. Level up your copywriting game.

These steps can be applied to LinkedIn, Twitter, Medium, Instagram and other social media. I’ve personally focused on LinkedIn. If you’re interested in building a personal brand on LinkedIn and want more detail, I’ve recently launched a course teaching you the process I used to:

✅ Grow my LinkedIn following from 3,000 to 130,000+ in just 12 months (and on to over 182,000 today).

✅ Become the No. 1 ranked ‘IT & Tech’ influencer on LinkedIn in the UK and 34th worldwide.

✅ Generate 40 Million post impressions on LinkedIn.

Want to know more? Then check out my Build Your Personal Brand On LinkedIn course.

Two Other Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I run a YouTube channel sharing advice on software engineering.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Learn From The Leaders You Admire

One of the best ways to level up as a software engineer is to become a leader.

No, that doesn’t mean becoming a manager. I’m talking about becoming a leader, taking the lead on a project, task or initiative that you are interested in.

Things like:

• Getting rid of that technical debt that’s annoying you.

• Automating a process you and your team hate doing.

• Introducing a new technology.

Because leadership is something you do, not a role you are appointed to. Which mean anyone can do it once they decide to.

So How Do You Learn To Be A Leader?

There are many ways, but there’s one simple trick that works well. Learn from the best leaders around you! Model their behaviour, because it’s working for them in the context you share.

Remember leadership is situational and they’re already figured out the right style, you can learn from them how they do it, in the environment you’re both in.

Look around at the organisation you work for, consider:

• Whose ideas are always adopted?

• Who do you admire and follow?

• Who do the people you need to convince listen to?

Then reach out to those people and ask them for help. Make it really simple for them to do so. Here's how.

1. Ask for Recommendations

Simply ask, that could look something like this:

"Hi, I love your leadership style. Do you recommend any books, podcasts, or newsletters that I should check out to improve my leadership skills?"

Or:

"Hi, I love how you get the management to buy into adopting Rust, I’d like to learn how to do that. Do you recommend any books, podcasts, or newsletters that I should check out to learn how?"

This is a low effort ask from them and it gives you some resources to check out. For the best results follow up by sharing what you learned, thanking them, and ask for more recommendations.

2. Volunteer for Projects

If you're looking to get some hands-on experience and to learn by doing, you could use:

"I'm working on my leadership skills and would love to take on some tasks or projects where I can develop further. Do you have any tasks or projects I can do for you?"

3. Ask To Tag Along To Observe Them in Action

Sometimes it helps to see what good looks like before we try to do it ourselves, In that case you could ask to tag along and see how they do it. Try asking something like this:

"I'm keen to improve my leadership skills and I really admire how you influence in meetings. Are there any additional meetings I could sit in on and observe you leading in person?"

Wrapping Up

These small asks help you learn directly from the leaders you admire without being a burden making it easy for them to help you grow!

If you follow through on all of this, keeping them informed of your progress, you’ll be earning their trust making them more likely to offer help, including mentoring or coaching.

Two Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I run a YouTube channel sharing advice on software engineering.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

How to Coach Software Engineers: A Practical Guide

Coaching is a great way to help the member of our teams to achieve their full potential. Unlike teaching or mentoring, where the focus is on sharing knowledge or providing guidance from experience, coaching is about fostering self-discovery and problem-solving in the coachee.

If you’re not sure whether you should be teaching, mentoring or coaching, check out my article that explains when and how to use teaching, mentoring or coaching.

As a leader, coaching involves helping our software engineers find solutions on their own rather than us giving direct instructions. We do that by insightful questions, listening actively, and providing feedback that encourages personal and professional development. By focusing on the engineer's goals, strengths, and areas for growth, coaching helps them become more confident and effective in their roles.

When to Use Coaching

There are several situations where coaching is particularly beneficial for software engineers:

1. Developing Problem-Solving Skills: As software engineers we often face complex problems that don’t have one obvious solutions, so we need to learn to select the best option for our specific context. It takes experience to learn how to do this and to have the confidence to do it. If we just tell an engineer what to do, they don’t get the change to develop this skill. So, instead of giving them the answer, coaching encourages them to think critically and develop problem-solving skills

2. Fostering Independence: Early-career software engineers, in particular, benefit from coaching when they need to build confidence in their own decision-making processes. Coaching encourages independence by helping them work through the challenges on their own in a safe environment.

3. Navigating Career Transitions: Whether an engineer is moving into a leadership role, taking on more responsibility, or switching to a new technology stack, coaching can help them adapt by addressing their concerns and helping them set clear goals.

4. Improving Soft Skills: Coaching is useful for improving communication, collaboration, time management, and other soft skills that are vital to a software engineer’s success but aren’t typically covered in technical training.

How To Coaching for Software Engineers

Start with a Foundation of Trust and Empathy

Before we can coach people we need to earn their trust. The engineers we are coaching need to feel that they are in a safe, non-judgmental environment where they can share their thoughts and challenges openly.

Building empathy is key to achieving this, show a genuine interest in their work and challenges, and avoid rushing to judge.

Trust can also be built by being reliable and consistent as a coach. If an engineer feels that you're not fully present or that their concerns aren’t important, they’ll be less likely to engage fully in the coaching process.

Set Clear Expectations and Goals

At the start of the coaching relationship, clarify what the goals are. You both need to have a clear understanding of where they are today and where they want to be.

Use Questions to Drive Discovery

The most effective coaching relies on asking good, open-ended questions that help the engineer think critically and explore different perspectives. Do not offer solutions. Coaching is about helping them them to come up with their own by asking questions like:

• “What have you already tried?”

• “What is the biggest challenge you're facing with this approach?”

• “How would you solve this if you had unlimited resources?”

• “What outcome are you hoping to achieve?”

These types of questions push the coachee to think deeper, encouraging creativity and self-reliance.

Create Accountability

To get the most out of the coaching, ensure that they follow through on the actions they've agreed to take. During each session, review their progress toward their goals and discuss any challenges they encountered. This keeps them motivated and responsible for their own development.

Common Mistakes to Avoid in Coaching Software Engineers

Mentoring / Providing Solutions Instead of Coaching

One of the most common mistakes managers make is slipping into mentoring or providing solution. Coaching isn’t about telling someone what to do or checking in constantly to monitor progress. It’s about empowering them to solve their own problems. Do not take over the task or provide step-by-step instructions. We coach when they have the skills or knowledge, but are struggling to apply them.

Focusing Only on Short-Term Goals

While it's important to help engineers achieve immediate goals, such as completing a project or fixing a bug, coaching should also focus on long-term career development. Help them think beyond their current role and consider their future trajectory, whether that’s specialising in a technical area or moving into management.

Not Following Up

Coaching isn't a one-time event; it’s an ongoing process. Make sure to follow up regularly on the engineer’s progress and adjust your approach as necessary. Without consistent follow-up, the coaching process can lose momentum, and progress may stall.

Conclusion

Coaching software engineers is about fostering growth over the medium to long term. By helping engineers develop critical thinking, independence, and long-term skills, coaching can have a lasting impact on their careers and the teams they work with. It’s one of the highest leverage activities you can do for them as a leader.

Two Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I run a YouTube channel sharing advice on software engineering.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: You’ve Got To Know When To Teach ‘Em, Know When To Mentor ‘Em, Know When To Coach ‘Em…

As a software engineering leader, it’s crucial to address any gaps in the skillset, aptitude and behaviours of your team. Not only will it keep your team productive but it will also foster growth, adaptability, and satisfaction among your engineers.

The challenge, then is to choose the most effective way to support your team’s learning and development.

There are three primary approaches you can use: teaching, mentoring, and coaching. Each offers unique benefits, but their effectiveness depends on the needs of the individual and the team. Understanding when to apply each method is key to cultivating a high-performing team.

Teaching

Teaching is the direct transfer of knowledge from an expert to learners. It involves structured learning, such as workshops, courses, or lectures, where a subject is presented systematically and in detail. Teaching follows a clear plan, designed to build understanding from foundational concepts to more complex ideas.

When to Use Teaching:

• For foundational skills: When engineers lack essential knowledge in new tools, languages, or methodologies, teaching is the most efficient way to bring them up to speed.

• Clear knowledge gaps: If there’s a defined need (e.g., learning a new programming language), teaching provides the structured approach to fill the gap.

• Limited time: When there’s a tight deadline and you need to quickly equip your team with specific technical knowledge, teaching can offer fast, targeted learning.

When Not to Use Teaching:

• Soft skills development: Teaching is not as effective for developing interpersonal skills like communication, problem-solving, or teamwork.

• Long-term growth: Teaching provides short-term knowledge but may not encourage the continuous, critical thinking required for ongoing development.

• Experienced engineers: Experienced engineers may already possess foundational knowledge and benefit more from hands-on guidance or situational learning.

Mentoring

Mentoring is a relationship-focused approach where a more experienced engineer (mentor) guides a less experienced engineer (mentee) over a period of time. This relationship allows for informal learning through discussion, feedback, and advice. The mentor shares with the mentee their thought process, explaining how they would tackle a problem.

When to Use Mentoring:

• Career growth and guidance: Mentoring is ideal for helping engineers navigate their career paths, offering advice not only on technical skills but also on industry trends, leadership, and soft skills.

• Building confidence: For less experienced engineers who need support and encouragement, mentoring can help them grow confidence in their abilities through regular feedback.

• Long-term development: Mentoring works well for sustained personal and professional growth, where incremental improvements and thoughtful reflection on experiences are key.

When Not to Use Mentoring:

• For immediate technical skills: Mentoring isn’t designed for rapid, intensive learning. If the team needs to master a specific tool or skill quickly, mentoring may not deliver fast enough.

• Mentor availability and expertise: If mentors are not well-matched in terms of expertise or availability, the mentoring relationship may not yield the desired results.

Coaching

Coaching is a goal-driven process where a coach helps engineers unlock their potential, usually through structured questioning, active listening and reflection. Coaching focuses on empowering individuals to find their own solutions rather than providing answers.

When to Use Coaching:

• For problem-solving skills: Coaching helps engineers improve their decision-making and analytical skills by encouraging them to think through problems and find their own solutions.

• For high-performers: Coaching can be particularly useful for experienced engineers who want to enhance their leadership, communication, or strategic thinking.

• For behavioural change: When a mindset or attitude adjustment is needed (e.g., improving team collaboration or handling stress), coaching is a great tool to foster introspection and self-driven improvement.

When Not to Use Coaching:

• For technical skills acquisition: Coaching isn't the best method when your team needs specific technical knowledge. It's more about fostering development in skills such as leadership, communication, or adaptability.

• For skill acquisition: Coaching focuses on helping the person apply what they already know, if they need to acquire new skills, use teaching or mentoring as appropriate.

• For novice engineers: Coaching might be less effective for inexperienced engineers who lack enough foundational knowledge to ask the right questions or drive their own solutions.

Choosing the Right Approach

Upskilling your software engineers is crucial, but it’s important to choose the right method depending on the situation. If your team needs to quickly learn new tools or methodologies, teaching is the best route. For sustained growth and personal development, mentoring offers a nurturing environment, while coaching helps unlock an engineer’s potential, driving high performance and behavioural change.

By understanding when to apply each approach, you can tailor your upskilling strategy to meet both the immediate and long-term needs of your team.

Two Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I run a YouTube channel sharing advice on software engineering.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

Tip of The Week: Leadership Is Situational. Adapt Your Style To Your Situation, Not Your Preference!

When we become leaders or get promoted into a management or leadership role many of us default to the leadership style we feel comfortable with, which is often the one we’ve seen modelled by current or previous bosses.

Unfortunately that means we often stick to that one style, whether or not it is appropriate for our current team/organisation.

In this article I’d like to introduce you to 13 different leadership styles, when to use them, and when to avoid them.

Coercive Leadership Style

This is a top-down, authoritarian approach focused on demanding immediate compliance and action. It is also known as: Autocratic, Authoritarian, or Commanding leadership.

When to use:

• Crisis situations: When swift decisions and clear directions are essential (e.g., during an emergency or crisis situation).

• Short-term, urgent goals: Where there’s no time for collaboration or feedback.

When NOT to use:

• For daily management: It will usually demotivate employees and harm morale.

• Creative and knowledge-based roles: It stifles innovation and initiative.

Affiliative Leadership Style

A relationship-based approach focused on building strong relationships, and creating a supportive, positive work environment. It is also known as: Relational leadership.

When to use:

• To rebuild trust: After conflicts or when morale is low, this style helps heal and strengthen relationships.

• To promote teamwork: Encourages collaboration and a strong sense of belonging.

When NOT to use:

• When performance issues need addressing: With a strong focus on praise and nurturing this leadership style can often be overlook the need for constructive feedback causing performance issues to be overlooked and unaddressed.

• As a stand-alone style: It is best combined with authoritative or coaching styles.

Bureaucratic Leadership Style

A rule-driven approach focused on following established processes and procedures. It prioritises structure and control over flexibility or innovation therefore bureaucratic leaders are typically found in large, established organisations or highly regulated environments where adherence to strict rules is important.

When to use:

• In highly regulated industries: Where compliance and risk management are crucial (e.g., healthcare, finance).

• For routine tasks: In environments where consistency and accuracy are important (e.g., manufacturing).

When NOT to use:

• In creative environments: It stifles innovation and flexibility.

• During times of change: It can prevent organisations from adapting quickly to new challenges or disruptions.

Coaching Leadership Style

Focuses on personal and professional development by helping employees identify and work towards long-term goals through coaching and feedback. A coaching leader spends a lot of time and energy on identifying and nurturing the individual strengths of each member of their team.

The coaching leadership style is similar to democratic and affiliative leadership, but coaching leaders place more emphasis on the growth and success of individual employees.

When to use:

• For individual growth: Use during one-on-one sessions, performance reviews, or mentoring.

• To develop skills: Ideal for helping employees grow into new roles or advance in their careers.

When NOT to use:

• In urgent situations: This style is time-intensive and not suited to environments requiring quick decisions.

• With unmotivated employees: It’s less effective if employees are not interested in self-improvement or growth.

Democratic Leadership Style

A collaborative approach that values input from team members, encourages participation, and incorporates diverse perspectives in decision-making. It is also known as: Facilitative or Participative leadership.

A leader who employs the democratic leadership style values the knowledge, skills, and diversity of their team. They are a consensus-builder, constantly seeking input from their direct reports and peers.

Democratic leaders are excellent listeners, and they develop confidence in their leadership by utilising the collective wisdom their team and peers have to offer. They are creators of future leaders. By empowering employees to exercise authority, they are preparing them for future promotions.

When to use:

• When you need ideas and feedback: Ideal for brainstorming and problem-solving where team input adds value.

• When your team has expertise: It works well with knowledgeable and skilled employees who can contribute meaningfully.

When NOT to use:

• In times of crisis: Immediate action is needed, and collaboration may slow the decision-making process.

• With inexperienced teams: They may lack the necessary knowledge or insight to contribute effectively.

Laissez-Faire Leadership Style

A laissez-faire leader provides minimal direction and trusts employees to manage their own tasks, allowing for a high degree of autonomy. Also known as Delegative leadership.

When to use:

• When leading a highly skilled, self-motivated team.

• In entrepreneurial start-ups where innovation and autonomy are critical.

• When employees are experienced and need little supervision.

• In situations where the team requires freedom to experiment and innovate.

When NOT to use:

• When employees require guidance, feedback, or course correction.

• In environments where structure and accountability are essential.

• When the team lacks the experience or motivation to manage themselves effectively.

Emergent Leadership Style

Emergent leadership develops organically as a team member gains influence and respect through interactions, rather than through formal appointment or election. This style relies on relationship-building and reciprocal exchanges to establish leadership. An emergent leader relies on influence rather than authority.

When to use:

• In teams where formal leadership roles are not defined or are evolving and the would-be leader holds no authority.

• In situations where informal leadership can complement or enhance existing structures.

When NOT to use:

• In highly structured environments where formal authority and clear leadership roles are crucial.

• When immediate and decisive leadership is needed and formal authority is required.

• If the team struggles to accept informal leadership or if there is resistance to change.

Pacesetting Leadership Style

A pacesetting leader leads by example. They set high standards and sets demanding performance expectations and lead by example in the expectation that others will follow suit.

When to use:

• With high-performing, self-motivated teams: Ideal for teams who thrive under pressure and enjoy being pushed to achieve excellence.

• For short bursts: When tight deadlines or urgent goals need to be met.

When NOT to use:

• For long-term management: It can lead to burnout, stress, and reduced employee engagement.

• With inexperienced teams: They may feel overwhelmed by high expectations.

Servant Leadership Style

A people-centric style that focuses on serving and supporting employees by putting their needs first, fostering growth, and encouraging collaboration. Servant leaders share authority, put the needs of others first, and help people realise their potential.

When to use:

• To build a strong team culture: Ideal for creating a sense of loyalty, trust, and respect among team members.

• For employee development: When your focus is on empowering employees to grow and succeed.

When NOT to use:

• In high-stakes situations: It can be too passive during crises where quick decisions are needed.

• With highly independent teams: They may need less hands-on support and more autonomy.

Strategic Leadership Style

Strategic leaders balance day-to-day operations with long-term growth opportunities, navigating complex and changing environments. The strategic leader creates a vision, clearly communicate that vision, and effectively drive that vision into reality.

When to use:

• In dynamic environments where managing current operations while pursuing growth is crucial.

• When a clear vision and strategic direction are needed to guide the organisation.

• To enhance productivity and align employee performance with organisational goals.

When NOT to use:

• In stable environments where routine management without a focus on strategic growth is sufficient.

• When employees need immediate, concrete guidance rather than a broad vision.

• If the organisation lacks the resources or support to implement strategic changes effectively.

Transactional Leadership Style

A performance-based approach where leaders provide rewards or consequences based on task completion, with a focus on achieving short-term goals. Transactional leaders are only concerned with the work their employees do.

When to use:

• For short-term, goal-oriented projects: Works well when clear tasks and objectives are laid out and rewards can motivate employees.

• With routine tasks: Where incentives can drive productivity and efficiency.

When NOT to use:

• For long-term development: This style doesn’t focus on employee growth or motivation beyond immediate rewards.

• In creative or dynamic settings: It can stifle creativity and limit intrinsic motivation.

Transformational Leadership Style

Transformational leaders focus on continuous improvement by pushing their team beyond their comfort zone, often setting ambitious stretch goals. The most effective transformational leaders are charismatic. They are skilled communicators, eloquent and able to communicate to employees on a deep, emotional level.

When to use:

• In high-growth organisations that require innovation and rapid change.

• To inspire and motivate teams to achieve ambitious goals.

• When fostering a culture of continuous improvement and personal development.

When NOT to use:

• When employees lack the support or coaching needed for challenging new responsibilities.

• In situations where consistency and stability are prioritised over change.

• When the risk of burnout is high due to constant pressure.

Visionary Leadership Style

A future-focused approach where the leader inspires and guides employees toward a compelling vision of the future, encouraging innovation and long-term goals.

Visionary leaders are natural born problem solvers. They are able to visualise possibilities that most don’t. They can not only see what’s possible, but they can also articulate it to their team.

Steve Jobs is a prime example of a visionary leader: passionate, open-minded, and creative, he created a culture of innovation during his time at Apple.

When to use:

• During periods of transformation: When your organisation or team needs a clear vision to drive them toward change or new opportunities.

• To inspire innovation: When fostering creativity and a sense of purpose is important to the organisation’s growth.

• With a capable team: When the team needs a vision to follow but not guidance on how to execute. Visionary leaders often rely on others to execute their vision.

When NOT to use:

• In day-to-day management: It’s less effective for handling immediate tasks or operational details.

• With inexperienced teams: They may need more concrete guidance and support to execute the vision.

Adapt Your Leadership Style

To be the most effective leader you can, you should to understand each of these leadership styles, their strengths and weaknesses and then adapt your approach to match the situation and the people you are dealing with.

Effective leaders know when to adjust their leadership style based on the situation:

• Coercive leadership is useful in crisis situations or when immediate action is required but should be avoided for daily management or creative environments.

• Affiliative leadership is perfect for rebuilding trust or promoting teamwork but should be paired with other styles when performance issues arise.

• Bureaucratic leadership ensures compliance in regulated industries but can stifle creativity in dynamic, fast-changing environments.

• Coaching leadership is great for fostering long-term employee growth but is less effective in urgent, high-pressure situations.

• Democratic leadership works well when seeking input from skilled teams, but it slows decision-making during crises.

• Laissez-faire leadership empowers highly skilled, self-motivated teams but fails in situations where employees need more guidance or structure.

• Emergent leadership thrives when formal leadership is absent, but struggles in environments that require clear authority.

• Pacesetting leadership drives high-performing teams to excel but can lead to burnout if used too often or with inexperienced teams.

• Servant leadership builds loyalty and trust through a people-first approach but may not provide quick decisions during high-stakes situations.

• Strategic leadership excels in balancing day-to-day operations with long-term growth but can be too visionary in stable environments.

• Transactional leadership is effective for short-term, goal-oriented tasks but doesn’t focus on employee development or creativity.

• Transformational leadership motivates teams to achieve beyond their limits but can risk burnout if not balanced with proper support.

• Visionary leadership inspires teams during times of transformation but may leave inexperienced employees needing more guidance.

Two Other Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I run a YouTube channel sharing advice on software engineering.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Don’t Be An Accidental Manager!

82% of managers have had no formal training!

These managers are known as ‘accidental managers’. They no formal leadership training and it shows!

Accidental managers directly contribute to almost a third of their staff leaving their role. That’s no surprise given only 27% of employees consider their manager to be effective.

It’s not great for the managers either. Many of them are not confident about their leadership abilities and most of them feel strongly that they need for more training and development to be effective.

I’m one of the “lucky” 18% of managers who have been given formal training and it hasn’t helped!

Why? Because all the formal training I received from organisation’s was focused on how to handle poor performance, ensuring managers had a clear understanding of the formal process of conducting a Performance Improvement Plan (PIP).

I hated that! I wanted to learn how to recruit and build a high performing team! I wanted to know:

1. How to write an effective job specification so I attract good candidates and avoid bias.

2. How to interview effectively.

3. How to onboard staff effectively.

4. How to ensure the culture in my team sets them up for success.

5. How to create psychological safety within the team.

6. How to run an effective one-to-one.

7. What leadership style should I use and when.

8. How to get my team to take on difficult challenges.

9. How to appreciate my team and my colleagues.

10. How to up-skill my team.

11. When should I use teaching, mentoring or coaching to up-skill them.

12. How to effectively mentor.

13. How to coach effectively.

14. How to communicate effectively.

15. How to talk to non-technical people and get their agreement.

16. How to deliver difficult news to people.

17. How to deliver feedback effectively.

18. How to manage conflict.

19. How to tell people they are wrong without offending them.

20. How to network effectively within the organisation.

21. How to influence effectively and how to influence without authority.

22. Stakeholder management.

23. How to get buy-in from my boss and their boss.

24. Goal setting and OKRs.

25. Project and programme management.

26. How to make better decisions.

27. How to build a technical roadmap.

If you’re a software engineering manager, does this reflect your experience?

I’d really love to know! Please either hit reply and tell me about your experience. If you’d prefer to be anonymous I’ve put together a short (four questions) anonymous survey you can fill in.

Many thanks, John

Three Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I run a YouTube channel sharing advice on software engineering.

3. I have some courses available:

   1. Become a Better Software Developer by Building Your Own Redis Server (Python Edition) which guides you through solving the Redis Coding Challenge in Python.

   2. Build Your Own Shell (Go Edition) which guides you through solving the Shell Coding Challenge in Go.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

News - I Have A YouTube Channel For Software Engineers

I’ve recently started building a YouTube channel sharing short videos on software engineering. I’ll be sharing more of the advice I publish in Developing Skills.

I’m doing a free lightning lesson with It’s all about why being a great engineer to work with will get you promoted! It’s on Thursday, September the 5th, 2024 at 5:00 PM (GMT+1) Full details here!

Tip of The Week: Balance Technical and Soft Skills to Accelerate Your Career

In software engineering, technical skills are always revered. But focusing on technical skills alone is a mistake. Soft skills — the abilities to communicate, collaborate, and lead — are critical.

Why Soft Skills Matter Most

Soft skills are underrated, they are the glue that holds teams and projects together. Here’s three reasons why.

Firstly, software development is a team sport. No matter how brilliant your technical skills are, they’re worthless if you can’t collaborate with others. The best software engineers know how to listen, communicate clearly, and empathise with their teammates. They bring people together and ensure everyone is moving in the same direction.

Secondly, the problems we face building software are rarely straightforward. They often involve handling ambiguity and dealing with conflicting requirements and constraints. Engineers with strong soft skills aren’t just coding to spec; they’re solving the right problems in the right way.

Finally, as you become more senior, your technical contributions will matter less than your ability to lead and inspire others. Engineers who can communicate a vision, build consensus, and manage conflict are far more valuable than those who simply churn out code. Leadership is about influence, and influence is rooted in soft skills of communication, empathy, and emotional intelligence.

Technical Skills Are The Foundation

That said, technical skills are the foundation of your career as a software engineer. They are non-negotiable. You simply can’t be a software engineer without the ability to build software.

Finding The Balance

The key to a successful career is to find the right balance of soft and technical skills. Here’s how:

1. Conduct Self-Assessment: Look at your current skill set. Where are you excelling, and where are you falling short? Get feedback from colleagues and mentors — not just on your coding abilities but on your teamwork, communication, and leadership qualities. Being honest about your weaknesses is the first step toward improvement.

2. Set Ambitious, Balanced Goals: Don’t just aim to become a better coder. Set goals that push you to improve both technically and interpersonally. Don’t just focus on learning new technology, but also explore taking a course on effective communication or leadership.

3. Actively Seek Diverse Learning Experiences: Technical skills don’t only develop at your desk, and soft skills aren’t just about team meetings. Mix it up. As well as the technical skills development you’re doing, look for opportunities to join communication workshops or volunteer for leadership roles to build your soft skills. The more varied your experiences, the more balanced your growth. For a double win, volunteer to lead a technical initiative such as running a series of professional development talks, mentoring programme or a technical book club.

4. Integrate Soft Skills Into Technical Tasks: Don’t silo your skills. Use every opportunity to practice soft skills in technical contexts. When debugging with a team, emphasise collaborative problem-solving. When presenting a technical solution, focus on clarity and storytelling.

Recognise That The Balance Changes As You Progress Through Your Career

As you advance in your career, the balance between soft and technical skills doesn’t just shift — it transforms. Here’s what to expect:

Junior to Mid-Level Engineers: Early in your career, your focus should be on technical skill-building. You’re learning the ropes, writing code, and becoming proficient in the tools of the trade. But don’t neglect soft skills. The engineers who stand out are those who are not only technically competent but also great team players and communicators.

Mid-Level to Senior Engineers: As you progress to this level, you’re expected to take on more responsibility — leading parts of projects, mentoring juniors, and making technical decisions. Your technical skills still matter, but soft skills become more important, particularly as you move to senior.

Staff+ Engineers: At this stage, you’re expected to take on more responsibility — leading projects, mentoring mid- and senior level engineers, and making architectural decisions. Your technical skills still matter, but soft skills become equally, if not more important. You’re now moving to a position where influencing others, making strategic decisions, and fostering a collaborative environment are key.

Leadership Roles: As you step into leadership roles, the game changes entirely. Your job is no longer about coding, it’s now about leading teams, setting strategic directions, and driving the organisation forward. Here, soft skills are your primary skills. Your technical background informs your decisions, but your ability to lead, communicate, and inspire is what will define your success.

Find the right balance for where you are now and have a plan to achieve where you want to be.

Three Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I run a YouTube channel sharing advice on software engineering.

3. I have some courses available:

   1. Become a Better Software Developer by Building Your Own Redis Server (Python Edition) which guides you through solving the Redis Coding Challenge in Python.

   2. Build Your Own Shell (Go Edition) which guides you through solving the Shell Coding Challenge in Go.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Don’t Be An Alpha Geek

“What is this rubbish? Which idiot wrote this code? It’s the dumbest thing I’ve ever see!” came booming out of the conference room.

Uh-oh! Jenny thought. A quick look through the glass wall showed the engineers all cowering around the conference table with Simon pacing around the room ranting about the dire code he’d just reviewed.

Jenny stuck her head through the door and asked Simon if he could spare her a minute. They stepped into another meeting room and before she could utter a word Simon was off, “These guys are idiots, they’re writing terrible code, why do we have to have them on the team? I could do it all better on my own!”

Jenny paused, took a deep breath and prepared herself for another challenging conversation with Simon. He was a great engineer, but the rest of the team were scared of upsetting him and incurring his wrath and it was hurting their productivity.

So what’s the problem here?

There’s a fine line between pursuing technical excellent and being an alpha geek and Simon was on the wrong side of the line. An alpha geek is often an excellent software engineer who is driven to always have the right answers, and solve hard problems.

They tend to value technical skills above all else and believe that the best technical person should make all the decisions. It’s therefore inconceivable to them that anyone else should get a say in how things are done.

When they become managers or CTOs things are even worse, they believe they’re creating a culture of excellence, when really they’re creating a culture of fear.

How To Avoid Being The Alpha Geek

To avoid becoming an alpha geek work on your emotional intelligence. In particular focus on developing self-awareness and empathy. Self-awareness helps you be more aware of your behaviour and empathy helps you understand how other people feel.

To develop your self-awareness use introspection. Observe your own thoughts and feelings, but instead of asking “why”, ask “what” questions. For example, instead of asking “why are people intimidated by my technical knowledge”, ask “what am I doing that makes people feel intimidated by me?”

To develop your empathy give looping a go. When you’re speaking to someone, ask a question and give the other person time to answer but don’t stop there. After they’ve answered paraphrase what they’ve said, and follow up with a question such as, “Is that right?” or “What else am I missing?” Focus on what is really important to them. Repeat the process until both of you agree and have a shared understanding. The aim is for you to understand where they are.

If you’re concerned you might be an alpha geek, you might also like to read my earlier post: 12 Ways To Tell If You’re A Difficult Engineer (And What To Do About It) and add considering those 12 points to your introspection.

How To Avoid Promoting An Alpha Geek To A Management Role

If you currently manage a technically brilliant software engineer who is perhaps sometimes difficult to deal with or always has to be the smartest person in the room, please don’t promote them to management.

You won’t be doing them, or the team they will lead a favour, in fact you’ll be hurting them. If the engineer is great, work to keep them and find a way to extend the non-management track in your organisation’s career ladder so they can continue their career as an individual contributor.

What To Do If You’ve Promoted One To A Management Role

If for some reason you’ve promoted an alpha geek to a management role, I’d suggest moving them sideways ASAP. Think about alternative roles they can take. A CTO can become a Chief Science Officer or Chief Architect. An engineering manager or director can become an architect, for example.

What to Do If You Are The Alpha Geek

Instead of focusing on being right, try to focus on what is important. Sometimes it’s technical, sometimes it’s team cohesion, sometimes it’s solving the right problem and sometimes it’s admitting you were wrong.

Don’t just focus on your technical skills, recognise that domain knowledge, business skills and people skills are hugely important too and work on them.

Become a mentor to other engineers. If you can bring yourself to view your mentee as someone to teach and guide and your role is to change your style and approach to what works best for them, then you’ll learn how to share your knowledge in a constructive way without shouting others down. Leading through influence instead of fear.

If you don’t then you might find yourself in the same position as Simon. As great an engineer as he was, Jenny had to let Simon go a couple of months later. For a month or so after that the team struggled but after that the team’s productivity shot up and they did better than ever.

Engineering excellence matters, being likeable and being able to work with the team matters too. Be a leader, not an alpha geek!

Got a story of being or working with an alpha geek? Then please share it in the comments!

Regards, John

Two Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I have some courses available:

   1. Become a Better Software Developer by Building Your Own Redis Server (Python Edition) which guides you through solving the Redis Coding Challenge in Python.

   2. Build Your Own Shell (Go Edition) which guides you through solving the Shell Coding Challenge in Go.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: How To Talk To Non-Technical People In A Way They Understand So They Will Agree With You

“Why won’t management give us the time to fix the technical debt?” asked Steve.

My usual response was out of my mouth before I even thought about it: “what did you say to them?”

“I explained that we had 103 tickets open and 47 of them related to technical debt. The key issues we need to tackle are related to the cloud platform and some legacy APIs we built way back. Plus we need to tackle some issues in the data pipeline so we can improve our training data for Borg.” replied Steve.

I began to see the problem. Steve had been talking to the CEO and CFO about tickets, technical debt, cloud platforms, APIs and data pipelines. It meant nothing to them. The CEO had a sales background and the CFO had never worked in the tech sector before. They had absolutely no idea what he was on about.

If you find yourself in this position, talk to people in their language. Don’t use domain specific jargon - things like API, tickets, cloud. It will confuse, not clarify the message. Instead try to understand their concerns and translate the message into terms they understand and can relate to their concerns.

Put another way, if you aren’t transferring information or it’s not being understood, you’re not communicating.

So how can you talk to non-technical people and get them to understand and agree with your ideas? Here’s how:

1. Get to know them and their concerns - spend some time in their world getting to know what they are concerned about, what their goals and priorities are and how they speak about them.

2. Tailor your content for your audience - speak to them using their language, address their priorities and concerns. Translate what you care about into what they care about.

3. Check your message has been understood - too often we assume that just because we’ve said our piece or sent our email that it’s been received and understood. Often it hasn’t. So when you’re communicating be sure to get feedback from your audience to ensure they have understood your message. To do this ask them open ended questions like:

• What are your thoughts?

• Can you give me some feedback on the ideas I’ve presented?

• How would you like to proceed?

• Which option would you like more details on and what would you like to know?

• What are the next steps that we a can agree on?

I worked with Steve to apply this approach and over the coming weeks and months we got support to address the key issue. For example:

• We grouped the tickets into themes that affected upcoming customer sales presentations or renewals then explained how they would potentially impact our future revenue - both the CEO and CFO understood and cared about that.

• We addressed the cost of the cloud platform and gave the CFO some simple reports that gave him some insight into the monthly costs and the trend.

Two Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I have some courses available:

   1. Become a Better Software Developer by Building Your Own Redis Server (Python Edition) which guides you through solving the Redis Coding Challenge in Python.

   2. Build Your Own Shell (Go Edition) which guides you through solving the Shell Coding Challenge in Go.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Don’t Criticise

“From the logs we saw something weird was happening in the chunk lambda. We’ve identified a potential bug and are creating a test for it, once …”

Mark was cut off by Dan butting in: “That’s not going to account for the increase in DynamoDB write though, that lambda doesn’t even write to DynamoDB! You must be looking at the wrong thing!”

“We’re starting from the beginning of the process and…”

But Dan cut Mark off again: “Well that’s dumb! We know the problem is a cascade of writes to DynamoDB. The only thing that writes to that is the audit lambda. You should have started there!”

Mark was getting visibly annoyed now, he didn’t like being interrupted, but he hated being publicly criticised.

After the meeting Mark did fix the bug he found, along with several others, including one in the place Dan thought might be the issue. He also complained to his manager about Dan’s behaviour and was reluctant to take on any work that might result in him having to collaborate with Dan. He wasn’t the only one.

Eventually, as good a software engineer as he was, Dan was let go because the team couldn’t work with him.

So what’s wrong with criticism?

Well, criticise is defined as: “to express disapproval of someone or something”. It’s even worse when you look at the list of words that mean the same (synonyms): attack, castigate, chastise, condemn, rail, and slam.

Ouch, who wants to be on the receiving end of that?

In short when you criticise someone you are going to upset them. You’re going to lose any goodwill you had with them. Instead of having a potential ally in future, you have a potential enemy.

Yet many software engineers seem to make it their personal duty to criticise the work of anyone and everyone around them. Sure they might be smart but that does not give them license to tear down everyone else.

Their behaviour hurts their teams too. The very people who could and should be coming to them for help are now reluctant to do so. After all who wants to deal with someone who attacks them? So instead of improving the work of the people they criticise they create barriers to collaboration, reducing the effectiveness of the team.

The problem is criticism wastes a lot of time and energy. It puts people on the defensive and makes meetings like the one Mark and Dan were in unproductive.

Ah, but what about constructive criticism I hear you ask.

The reality is many people take criticism personally. To them it’s criticism and they don’t know what your intention was. Even if you tell them it’s intended as constructive criticism, they’re still likely to feel bad. That doesn’t mean you can’t correct someone, it just means you need to take care how you do it.

So next time you feel like criticising pause and ask yourself:

1. Why are you going to criticise them?

2. Are you trying to help them?

3. Or are you trying to make yourself look better?

4. What is the positive outcome you want?

5. Is there a better way to achieve it?

When you really do need to correct someone here are 3 simple tips:

1. Do it in private, don’t put them in a position where they feel the need to publicly defend themselves.

2. Focus on the behaviour, facts, work or data, not on the person.

3. Soften the blow. Praise what you can. Offer some positive feedback and support on what they are right about / did well.

You can read more about how to correct people effectively in my earlier post: YOU ARE WRONG!

Two Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I have some courses available:

   1. Become a Better Software Developer by Building Your Own Redis Server (Python Edition) which guides you through solving the Redis Coding Challenge in Python.

   2. Build Your Own Shell (Go Edition) which guides you through solving the Shell Coding Challenge in Go.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Learn People’s Names And Use Them To Build Better Professional Relationships

Our names are an integral part of our identity. They matter to us. A lot. Why? Because our name is one of the first words that we learned as babies, and our parents often share with pride the reason for our names.

So, when someone uses our name, we register it. It triggers a response from us because, our whole lives we’ve been conditioned to recognise and respond to it.

And if we’ve chosen to use another name, be that a nickname or an shortened version of our name, that’s just as important to us, because we’ve chosen it.

Remember that a person’s name is to that person the sweetest and most important sound in any language. — Dale Carnegie

When other people remember and use our names correctly, it sends a clear message: they have paid attention to us. It makes us feel valued. It makes us feel seen. It makes us feel as though we’ve made enough of an impression to be memorable.

That in turn makes it easier for us to relax, to connect, and feel more comfortable in our relationship with them. We tend to have a favourable opinion of the person who has remembered our name, and that just makes communication flow.

When people forget our name, mispronounce it, or intentionally address us using the wrong name, the message is very different. We feel dismissed, disrespected, that we’re not important enough for someone to make the effort. We tune out. We think less of the person abusing our name.

And not knowing someones name sends and even stronger message, particularly if they are subordinate to you.

So, learn people’s names and use them when you speak to them, they’ll like you more and you’ll build better, stronger relationships.

Simple right? Well, no, not always.

Sometimes we are afraid to ask someone their name. Sometimes we worry that it’ll be inappropriate, sometimes we worry that we’re intruding and sometimes we’re just embarrassed to admit we don’t know it.

None of these reasons are good reasons not to learn someone’s name, so keep it simple and use one of these three ways to ask:

1. Hi, I’m John, what’s your name?

2. Could you tell me your name place?

3. I’d love to be able to address you by name please?

Keep it simple. No one will be offended by you asking for their name.

Sometimes we believe we’re not very good at remembering names. If that’s the case, create a system to ensure you remember them. You’re an engineer, it’s a problem for you to solve, not ignore.

To get you started, here are three tips you can use to help you remember someone’s name:

1. Use your phone to make a note or write it down: You can then refer back to your notes to remind yourself, repeating this will ensure you remember it.

2. If you’re at work, check the org chart: Use it remind yourself - often you’ll be able to see their name, photo and some context, which can help you remember.

3. Repetition, repetition, repetition: Repeating their name (quietly to yourself) helps you remember.

Sometimes we struggle to pronounce people’s names or don’t even know how to. In that cases here are three tips to ensure you are correctly pronouncing someone’s name:

1. When they tell you their name, repeat it: This will help you remember everyone’s names as well as the pronunciation of them.

2. When you don’t know, just ask: Then repeat their name a few times. When people see that you’re committed to getting it right, they will appreciate the effort more than they’ll mind minor errors.

3. If you can’t ask, search online: YouTube is full of videos that cover the pronunciation of names. It’s that important people have realised there’s a lot of value in creating these videos. There are plenty of websites that will let you enter the name too.

It’s worth repeating: remembering and using people’s names is one of the simplest ways to make a positive impact on a person’s perception of you.

On that note, Hi, I’m John, what’s your name? Hit reply and let me know. I’d also love to know how I can help you advance your career in tech. Send me your questions and I’ll answer them in future newsletters.

I look forward to hearing from you.

Regards, John

Two Ways I Can Help You Level Up As A Software Engineer:

1. I write another newsletter, Coding Challenges that helps you become a better software engineer through coding challenges that build real applications.

2. I have some courses available:

   1. Become a Better Software Developer by Building Your Own Redis Server (Python Edition) which guides you through solving the Redis Coding Challenge in Python.

   2. Build Your Own Shell (Go Edition) which guides you through solving the Shell Coding Challenge in Go.

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Figure Out If You Are The Problem And Fix It

One of the things that attracted me to software engineering was the idea that I could write code all day and not have to deal with people.

The reality is we have to deal with people and it’s a lot easier for them and a lot less stressful for us if we’re not difficult to deal with. It’s a lesson I’ve learned the hard way.

12 Ways To Tell If You’re A Difficult Software Engineer

1. Your manager tells you you are - It’s the most obvious indicator and it comes in two versions: your manager finds you difficult to deal with or other people have complained to your manager that you’re difficult to work with.

2. You are continually challenging or correcting everyone - You challenge every decision and correct everything you perceive to be wrong believing that no one else is ever right.

3. People are nervous or guarded around you - People change, becoming quieter, more guarded and seem to be walking on eggshells around you, they might be afraid of how you’re going to behave.

4. You view people asking you questions as an annoying distraction - When people ask you questions you’re short with them or even ignore them, keeping your back to them and hands on your keyboard or your camera off and you keep coding during a call.

5. You think your technical skills make you better/more important than other people - People can tell when you think highly of yourself, they recognise when you’re too proud and unwilling to work with them.

6. People problems follow you around -If you find you’re suffering constant friction wherever you work, then you might be the problem. As the saying goes, where there’s smoke, there’s fire.

7. You expect other people to accept you for who you are and deal with it - Instead of taking responsibility for your own shortcomings and actions you expect other people to accept the way you are. It’s their problem for not being able to handle that you’re blunt and/or direct.

8. You blame others when things go wrong - You never admit your mistakes and always blame others when something goes wrong.

9. You prefer to work alone/other people slow you down - Whenever possible you work alone and you make it clear collaborating with others is a chore.

10. You always complain, yet rarely offer solutions - You complain about everything, always seeing the worst, yet you never suggest solutions.

11. You take all the credit - When things go well, you take the credit for it all. Everything was built off the excellent work you did alone.

12. You hoard knowledge - You’re reluctant to share knowledge with other people and you make it hard to the rest of the team to understand your work.

If more than one of these applies to you, you may well be a difficult engineer. Changing just a little will make your life better.

What To Do If You Are A Difficult Software Engineer

Here are my top 12 tips if you want to change:

1. Decide to change - Actually decide to change and make a commitment to it. It’s going to take time and it won’t be easy. You’ll have to be humble and you’ll probably need help. Only you can decide to do it.

2. Ask your manager for specific feedback and help - If you believe your manager is or would be genuinely interested in helping ask them for help. Start with specific feedback on what you did, why it wasn’t good and how you can change for the better.

3. Ask for a mentor or coach - If you’re not comfortable working with your manager, perhaps the relationship isn’t good enough, ask HR or another manager for a mentor or coach. If the business can’t find one internally, find your own outside the business.

4. Make sure your coach/mentor is going to model the right behaviours - Don’t pick Linus or some other famous, and perhaps famously difficult engineer as your mentor. Find someone who can empathise with you and also model the right behaviour.

5. Take responsibility for your actions, your behaviour and your mistakes - stop blaming others. Own what you do. Own responsibility for the change too.

6. Be humble - Seek first to understand before seeking to be understood. Ask questions and try to understand other people’s ideas, find some common ground on which you can build.

7. Before criticising or correcting ask yourself these three questions:

   1. Does this need to be said?

   2. Does this need to be said by me?

   3. Does this need to be said by me now?

   If the answer to any of those questions is no, keep quiet.

8. Count to 10 before responding - give yourself time to process, resist the temptation to respond on impulse.

9. Encourage others to share their ideas - Let them speak up and ask them to share. Be curious. Often if they are wrong you can lead them to discovering that for themselves by asking questions.

10. Share your knowledge - You might think hoarding knowledge makes people think you are an expert. The reality is you will be perceived as more of an expert when you share your knowledge freely.

11. Focus on solutions not problems - Make a commitment to yourself that you won’t raise a problem without a solution.

12. Give credit generously - You’ll get more credit for what you did and bonus credit for sharing.

I know that it’s far easier to point out what you should do than it is to do it. These 12 tips aren’t going to cause a miraculous change overnight. They are the start of a journey. It will take time to make a change and to replace existing habits with new ones.

I know, I’ve been there, it takes time. The key is to decide to change and start.

If you’re struggling hit reply and tell me more, or reach out to me on LinkedIn.

John

Hi this is John with this week’s Developing Skills - Skills for Developers looking to develop their careers.

If there is a topic you’d like to see covered, please let me know by replying to this email📧

Tip of The Week: Learn To Correct People Without Offending Them

As I returned from the kitchen with a fresh cup of coffee Simon ran out of the office in tears. What was that about? I looked at his fellow junior engineers questioningly, wondering what had happened. They looked embarrassed and uncomfortable then away.

As I put my coffee down, I noticed a private message flash up on my laptop from one of the senior engineers: “Hey John, poor Simon has just been torn apart by Bob. Sure Simon was wrong - hey, he’s a junior it’s gonna happen - but Bob was pretty harsh every time he corrected him.”

When I went outside and spoke to Simon he confirmed it, Bob has been correcting him all day and it was undermining his confidence. He wanted to quit his job right then.

Like Bob, it’s inevitable that at some point in our career we will have to correct someone. It’s an unavoidable part of being in a healthy, growing team. After all, we can’t all know everything, so we should be able to correct each other and lift each other up.

When it’s done well, correcting someone can change their behaviour, helping them achieve better results and strengthen your relationship with them. Yet too often we do it badly, damaging the relationship and causing resentment. Like Bob did.

Here are four steps you can take to avoid that.

1. Be like Elsa from Disney’s Frozen and “let it go” - a lot of the time it really doesn’t matter if someone is wrong. So before you rush to correct them, take a moment and ask yourself - does it really matter if they are wrong? Is there anything important at stake here if you don’t correct them? If not, let it go.

2. If you really do need to correct them, correct them in private - it’s human nature to be embarrassed when we’re wrong. We’re even more embarrassed if we’re wrong in public. So, to limit that embarrassment correct people in private. If you really need to correct in public take care to minimise the impact. For example if someone is presenting a plan that you believe is flawed, don’t pick it apart publicly, instead slow things down and offer to help. For example:

Thank you for the work you’ve done on this proposal. There are a few suggestions I’d like to make, perhaps we can get together after this meeting and work on it together?

You’ve stopped the current issue and can later in private constructively correct them and help refine the proposal.

3. When you are correcting someone, focus on the behaviour or outcome, not the person - when you focus on the person, it becomes personal and intended or will feel like a personal attack. That is going to make the other person defensive, damage your relationship and lead to a negative outcome.

Instead focus on the observable behaviour or outcome and not on them. For example:

I noticed some errors in the proposal, I would like to see them addressed before we review it with the team again.

Be sure to then provide specific examples of the issues that need to be corrected.

4. None of us like being corrected, we’re embarrassed by our mistakes so when you have to correct someone, soften the blow - don’t just knock them down and then keep kicking them, instead praise what you can. Offer some positive feedback and support.

You can do this well by beginning with a positive statement about their work or behaviour and some praise for their achievement so far. Then provide the correction and follow it up with a reminder of the praise and wrap up on a positive, supportive note.

For example:

Thank you for taking on this difficult challenge, I really appreciate you stepping up and volunteering to work in the proposal. Especially as I know you’d rather be writing code than documents. I really appreciate the teamwork.

I noticed some errors in the proposal, I would like to see them addressed before we review it with the team again. List specific examples...

This was a difficult task, so I really appreciate you taking it on and getting us to where we are today. Thank you for stepping up. Please let me know if I can help with the revisions in any way.

Unfortunately, this was very early in my career, when I wasn’t experienced enough to give Bob this advice. Instead we had a frank discussion in private, but without me having the experience to cushion the blow and stick firmly to talking only about the behaviour.

Sadly that meant Bob felt wronged too.

Therefore his behaviour didn’t change and a few weeks later he was fired. The working environment improved for those that remained, but it was a net loss for all of us. Bob lost his job, we lost his expertise.

So please don’t be like Bob or I were, learn from our mistake.

FINAL CALL! Would You Like To Build a Personal Brand on LinkedIn?

Starting on the 22nd July I’m running a course and 30 day challenge where I show you how I:

✅ Grew my LinkedIn following from 3,000 to 130,000+ in just 12 months.

✅ Became the No. 1 ranked ‘IT & Tech’ influencer on LinkedIn in the UK and 34th worldwide.

✅ Generated over 40 Million post impressions on LinkedIn.

✅ Grew my newsletter to over 100,000 subscribers on LinkedIn and over 50,000 on Substack.

And how you can too. You can learn more and sign up here: https://johncrickett.gumroad.com/l/30day-li-challenge/