#26 - Intentional Technical Leadership

Newsletter - Saturday, 8 October 2022

Hello my friend!

Happy Saturday! 🎉

Welcome to another issue of the Intentional Technical Leadership newsletter.

I hope you're all doing well. I've not been feeling well this week and took a few days off.

I've always struggled with taking time off but I'm trying to ensure that I do when I'm unwell. It's good for my own health and as a leader, it's important to model that behaviour for my team.

As one of my old team at the BBC used to say:

"It's ok to not be ok."

I've managed to find some time to write the newsletter this week and there are some really interesting articles. I hope you enjoy them.

🔖 Interesting Reading

You're never too young or too inexperienced to be a mentor

I often get asked to mentor less experienced managers or software engineers. There's a common misconception that you need to be a senior manager or engineer to be a good mentor. This article debunks that myth.

I really care about getting people into the technology industry, especially those who are under-represented. This post has some great ideas for getting started with mentoring, even if you don't feel like you have the experience to do so.

It's often said that some of the best mentors and teachers are those who are still learning themselves. If you're just a few steps ahead of others then you can share your own experiences and help them avoid some of the mistakes you made.

I'd love to hear your own experience of mentoring. Do you have any tips for those who are just starting out? Email me if you do.

How to build a healthy relationship between engineering and product

One of the challenges I've had over the years is ensuring that the engineering team and the product team are working together effectively.

This fantastic article by Danielle Leong, a VP of Engineering, provides some great tips on how to build a healthy relationship between the two teams.

She shares her insights on understanding the motivations for each side of the business and where there should be common goals. This allows the product and engineer teams to collaborate on shared business objectives to reach a common goal.

I've definitely struggled with some product and engineering relationships over my career so there are some really actionable tips in this post.

ADHD Coding Recruiter : Self Advocacy | Parul Singh

Parul Singh is a very open and honest recruiter who shares her journey with Attention Deficit Hyperactivity Disorder (ADHD). She's been sharing her experiences and advice on Twitter for a while now and this is her fantastic newsletter. She's a strong advocate for the importance of self-care and mental health - something we should all be thinking about more.

Parul is incredibly vocal about the challenges of neurodiversity in the technology industry and is a strong advocate for inclusive hiring processes for all neurodivergent people. For someone like myself who is a hiring manager, this is incredibly valuable information.

She's also passionate about supporting diversity initiatives and highlights the issues within the tech industry that cause inequality - particularly pay inequality.

I highly recommend following her on Twitter and subscribing to her newsletter.

📺 Worth Watching

Being Comfortable With Failing | Simon Sinek

Another great video from Simon Sinek who shares his thoughts on the importance of failing.

He talks about building trust in teams and how we should encourage a culture of psychological safety. He also shares the importance of learning from failure and how we should be encouraging people to fail without fear of humiliation or not getting promoted.

I love the idea of calling it "falling" rather than "failing".

If you fall you can get back up and try again. If you fail, you're feel like it's over.

🌶️ Hot Take

Estimates are frequently way off - why? | Cory House

This is a great Twitter thread from Cory House, an experienced software developer. In it he shares why estimates of software development are usually incorrect and what you should be thinking about when planning your team's work.

We all know that estimating the development times for our projects is difficult. This thread is a great reminder of why that is and what we should be thinking about when assigning times to work.

If you'd prefer to read this all on one page then click on this link - Estimates are frequently way off - why?.

Do you estimate work with your teams?

Do you keep any metrics to determine if they're correct?

Share your thoughts on estimation and reply to this email.


I hope you enjoyed this week's selection of intentional technical leadership articles.

Hit reply and let me know what you think.

Feel free to send me any interesting articles or podcasts you've found as I love hearing from my readers.

Have an amazing week and be excellent to each other!

Speak to you soon,
Marc

Senior Engineering Manager @ Netlify

Not signed up?

Enter your email below to sign up for my newsletter to receive weekly articles. Each week you will learn more about technical leadership, intentional remote working, and growing your leadership career.

I hate spam as much as you do: your email address will never be shared.
You can unsubscribe at any time.
Powered by EmailOctopus