I believe that one of the most powerful things you can do as a leader is to own your mistakes. Nobody is perfect, and therefore it’s inevitable that you will make mistakes. Often, holding a leadership or management position means that these mistakes are magnified and have a impact on many more people. So why admit your mistakes? Wouldn’t this be showing a weakness? Wouldn’t it show that your infallible? Won’t people judge you closer?

Choosing the “best tool for the job” is a mantra that many software engineers repeat when asked to explain their choice of tool, language or framework. In some cases, this choice is right, however far too many times in my career I’ve seen “best tool for the job” loosely translate to whatever was top of Hacker News this week. The unintended consequence of always choosing the “best tool for the job” is a software inventory which spans multiple languages, frameworks, build systems and deployment tooling.

I was fortunate enough to spend the last couple of days at Lead Developer 2017 in London. The conference has been described as a leadership and management conference dressed up as a technical conference. It’s one of my “must-attend” conferences of the year. There were some clear themes from the talks this year, with perhaps the strongest message coming across that as technical leads and managers it’s own responsibility to build safe, inclusive environments where people can thrive.

Part of the role of an Engineering Manager is to help others to achieve their career aspirations. However, it’s not always easy for people to articulate the direction they hope their career will take them. For some, it can be difficult to describe their ideal future role, or to answer that “where will you be in 5 years time?” question. I have struggled with this question too. I wanted to share a technique one of my previous managers used with me to uncover my aspirations.

There are few truly great places to work, therefore you should aim for a place that gives you the freedom to make it great. — Steve Bennett (@stevebennett) February 17, 2017 Early today I tweeted this, and I thought it was worth giving a little more detail as to what was underlying this pithy sound-bite. Over the last year, I’ve changed companies twice. At the start of 2016 I left eBay and started a new role with Marks and Spencer.

This is part two of my review of books I’ve read in 2016. Part One can be found here. My complete “Year in Books” can also be found on Goodreads. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble, David Farley 🔗Quite simply, this is a must read for any modern software engineer, or for anyone associated with building software. The nitty-gritty of implementation isn’t really covered, so don’t expect to finish the book with all the answers.

At the start of 2016, I made a resolution to read more. I managed to do this, and read more this year than I’ve been able to do in recent years. Most of my choices have been leadership or management books, or those related to sport. It’s also been mostly non-fiction. Over the coming posts, I’m going to share the books I’ve read this year, and my thoughts on them. Part one, starts below.

What are the little things that annoy you in your current role? What are the things, that when they get in the way, make your job just 10% more difficult than it needs to be? If your workplaces have been anything like mine, I bet there’s at least one thing that you can come up with that annoys you. Even if it is something little. Let’s look at an example. These are the kind of annoyances I’ve come up against in previous workplaces.

🗣 Calling all Engineering Managers! 🗣 🔗Engineering Management can be an incredibly lonely place. This is especially true if you are new to the role. You’ve probably moved from a role where the 1’s and 0’s were the key thing you were worried about. You focussed on the technology, and obsessed over the product. You measured your output in features, bug-fixes or commits. At the end of a good day, you could say, “I did that”.

“In computer programming, an Application Programming Interface (API) is a set of routine definitions, protocols, and tools for building software an applications A good API makes it easier to develop a program by providing all the building blocks, which are then put together by the programmer.” – Wikipedia Anyone writing code will already be familiar with APIs. Whether it’s the API exposed by the standard library of your favourite programming language, or a REST API exposed by a third party service, it’s a necessity to understand the concept for building more than a “Hello, World!