Books from 2016 – Part Two

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.

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. It talks from a high level of abstraction, and it’s clear that it’s somewhat targeted to managers as well as developers.

The book lays out the reasoning for changing your development process through automation, and provides a high level view of how to do this. It’s opinionated, without being preachy, and leaves enough room for the reader to make their own choices of how to implement the ideas in their own context.

It is fairly repetitive in places, however I forgive it as the topic is so important to all involved with building software.




Another book that presents a management model in the form of a fable. This form gives the reader enough of an introduction to a concept in order to get them interested, however not enough to know how to apply the ideas in practice. I think this is the main problem I had with the book.

Whilst the concepts were presented well through the story, it did leave me wanting more detail to understand how I could apply the ideas in my context. I was also aware that the story was fictional, so whilst the ideas seemed sound, it did leave me thinking whether they actually work in practice.

The book is often lauded in management circles, and it does provide a good introduction into becoming a leader rather than just a manager. It shows that empathy and trust are necessary to build and lead a great team, and that just getting the best people together isn’t a guarantee for success.

Overall, an enjoyable and thought-provoking read, although a little light on details and actionable ideas.

This book made me feel uncomfortable at times. Not because it was bad, but because it was too close to situations I’d personally experienced.

Because of this, I could see the gap between reality, and the way the fable described process and process improvement. Readers of the book will be left with a couple of tools that they’ll be able to use, but probably won’t leave with the depth of knowledge to understand why these tools work. It also takes the author a long time to get to some of the key points, which means that their importance is lost.

I think it provides a good introduction into the world of DevOps and IT management techniques, and the use of a story, will help inspire those IT managers that are struggling with their own organisations to find out more.

I’ve been a follower of Jarvis for a while, and was eager to read his views on privacy. Jarvis lays out a compelling vision of publicness, going into detail to explain the benefits to both businesses and individuals. In parts, he pulls on his own experiences to show how being public can be of a great advantage to an individual.

Jarvis also tackles some of the problems with being public, however I think that because of his stance he doesn’t dive into them as deep as he could. A book which talks so much about privacy online is also subject to falling out of date quickly, and in some places this is already the case.

Radical Focus is another business book, wrapped up in a fable to inspire. The Fable in question focuses on an early-stage start-up with a couple of founders who are struggling to grow the business. The founders want different things, and operate largely independently in order to achieve the necessary growth.

In steps a knowledgable VC along with an experienced CTO, both singing from the same OKR hymn-sheet. Hanna, our main protagonist sees the value of the approach, and implements the OKR system into the company. A year later, the start-up is soaring, and OKRs take a large portion of the credit.

It’s a good story, and helps to frame the “why” of using OKRs in your business. Like many of these fables, it gives the reader enough of an introduction to the topic to inspire them to find out more.

The second half of the book details more examples around the implementation of OKRs at different companies. I found this really good, as it gives the reader some things that they can go away and try – something that is often missing from the business-fable genre. It also mentions alternative literature (specifically Google’s implementation).

I would have liked to see more detail on the implementation of OKRs, perhaps backed up by some empirical studies into the effectiveness of the system. Whilst several well-known companies are mentioned, there’s not much science to back up the claims around increased alignment, productivity and ultimate success.

That said, I’d suggest it as a beginners read into the subject of OKRs and goal setting.

Books from 2016 – Part One

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.

Bock is part of the people operations team at Google, however I don’t think that this limits this book to only people working in HR. The book is an insight into the way that Google works, the practices they use, and the “science” behind implementing these practices.

I found that in some parts the book, that I was being sold on how cool Google was to work at, and why my workplace wasn’t doing things right because we’re not offering the same way. It wasn’t preachy, but the “come on, it’s not that hard” attitude was at times a little off-putting. I would have liked to see more balance, perhaps with more emphasis on some of the things that didn’t work out so well.

That said, the content in general is good. Each chapter closes with a clear set of “Work Rules” for making the work environment a better place for people.

As a fan of Pixar, I’d been looking forward to reading this book for a while, and finally got round to it earlier this year.

The stories behind the creation of some of Pixar’s most successful movies, including Toy Story, were fascinating. As was the behind the scenes look at the acquisition of Pixar by Disney and the resulting impact on both teams.

Whilst the anecdotes were, in the main, entertaining, the actionable insights and content was sometimes lacking. Looking back on the book, I think that the title of Creativity Inc, is slightly misleading as it focusses more on improving the productivity of a team.

You also need to consider that Pixar were part of the wage-fixing group that was exposed a few years ago. Knowing this information, some of the ideas fall a little flatter than I believe the author intends.

I don’t really know what to think of this book. Lyons tells a great story – a 50-something ex-journalist taking a position in a fast paced, growing start-up. The cynicism of the author on the practices of his host company help to highlight some of the ludicrous activities that are perceived as normality on the tech-bubble. It’s the call-out that the tech scene needs, as some of the practices look really stupid when you lay them out on paper (for example, graduating from a company, rather than being fired).

I found Lyons view to be amusing, yet in places, it did across as bitterness. It left me feeling that Lyons had a chip on his shoulder about no-longer being the most important person in the room and for his status at Hubspot. He also comes across as unauthentic, shaming brogrammers for their culture whist in the same time praising the boys-club culture of media. Whilst he makes the claim that he was in the start-up for the long-term, it does leave the reader wondering whether the author’s intention was to take the job in order to write this book. Hubspot just ended up being the “lucky” company to enable him to do this.

If you work in the tech-scene, then it’s a good read, however being able to empathise with the author does mean that the impact of this book is limited.

It’s hard to read this book and not let your opinion on it be tainted by your thoughts on Silicon Valley, and the start-up and tech cultures. I think that those who are living in these cultures, or on the fringes will find it enjoyable, however living in the UK, the story doesn’t resonate in the same way.

From what I can tell (from media), the story told is pretty accurate. Focussing on teams as they progress through the incubator is a good way of hitting all the main points. The book also covers some of the criticism of Y Combinator.

You’re not going to learn any secrets from behind the curtains of Y Combinator in this book, however the anecdotes do provide the reader with a view of what it’s like to be a start-up founder in SV. How relatable you find that story, and ultimately how enjoyable you find the book, will be dependent on your own view on the SV start-up culture.

The story of how Elon Musk left South Africa, emigrating to the US and ended up founding some of the most innovative companies in the world is a fascinating one, and makes for an excellent read.

The book covers the life of Musk well, however it is at times a little bit fanatic in it’s love for all things Musk. The hard topics such as his relationship with his father, his divorce and the way he manages the companies aren’t explored in detail. Doing so, would have created a more complete view of the man and his ambitions.

Because of these missing details, you’re left wondering whether this is a true recount of the achievements of Musk.


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.

  • Having to use a “special” laptop to access holiday requests.
  • IT procurement systems which reject your request for a laptop power supply.
  • The office being incredibly hot and humid in summer
  • Inability to book meeting rooms because people “pull rank”

On their own, each of these things is little more than an annoyance. A blip in your day that you need to work around. I call these kind of annoyances micro-frustrations. Things that will frustrate you every time you encounter it, but not really big enough to make you flip the table.

A micro-frustration on it’s own isn’t a problem. It’s even possible to live with a couple of them. However, when a large number of micro-frustration come together they cause real problems for an organisation.

Consider the four examples above – In isolation they’re the kind of problems you can work around. Yet if you’re job is to manage people the combination would be problematic. You’re scrambling around to find meeting rooms for your next one-on-one; switching laptops between the one with power and a shared one to access the holiday system; sweating because the AC in on the blink, you’re probably going to end up pretty annoyed on a regular basis.

In this situation, you’re left thinking that the company doesn’t care enough to ensure you’re able to do your best work.

It’s a death by a thousand cuts, and eventually these micro-frustrations will build and you will leave due to them. The problem with micro-frustrations is that you might not know when this point will come, but eventually it will.

Much of what is written about management is focussed on the importance of developing others. This is important, but as a manager it’s also your job to make sure that the people you work with don’t end up in a situation similar to the one described above. It’s about sweating the small things, eliminating the micro-frustrations that get in the way of the real work.

A common question I ask in one-on-ones is “what do you find frustrating?”, or alternatively “what is one thing I can do to make your life here easier?”. The answers to these questions are rarely big, change the world, problems. They’re the little things, the micro-frustrations. It’s part of my role to remove these micro-frustrations before they have chance to aggregate.

Sometimes, this involves hacking round the systems. Need a new laptop power cord that IT won’t buy? Ok, we’ll buy one and expense it, and in parallel I’ll work with IT to get some sensible policies in place for the future. Air conditioning not working? Right. Work from home and I’ll deal with facilities to get it fixed.

Being a manager is about helping your people to do their best work, even if sometimes that means doing things to resolve things which may seem insignificant at first. Don’t allow micro-frustrations to persist, and don’t allow them to come together to form something a lot bigger.

Engineering Managers Slack Team

🗣 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”.

Now, you’re in a role where your primary focus is people you work with. You’re responsible for more than bits and bytes, and you can no longer measure your effectiveness by the number of bugs you fix, or by the number of commits you make. It’s a little unclear what a “good day” looks like.

Things just got, well, a little strange.

In my experience, this is the transition people make when going from Individual Contributor to People Manager. For most engineering managers, there’s little to no training involved. You learn through doing, and through the mistakes you make as you go along. In the best cases, you’ll have a mentor or manager that can help you with the change, however, it’s not always the case.

Making this transition is difficult, and having done it a few years ago, I know personally how lonely it can be to be a new manager. Sometimes you need the advice of someone outside of your company, and it’s hard to know where to turn.

I had the pleasure of working for a short time with Meri Williams, who also recognised these challenges for new (and experienced) Engineering Managers. Meri had spoken to a number of freshly minted mangers, and brought us together as a community.

What started as an email thread, quickly developed into a Slack Team. We’d now like to invite other new(-ish) Engineering Mangers or Team Leads to join the conversation.

We’re aiming to build a safe, confidential space for engineering managers to exchange ideas, information and get advice.

If you’d like more information, or if you’d like an invite, drop me a message on Twitter – @steve_codes.

An API for Teams

“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.”

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!” application.

The API abstraction provides the programmer with a protocol defining the methods of interaction, whilst at the same time hiding the details of the implementation. A well-defined, consistent, structured API is a joy to work with. An API with inconsistencies, or that exposes interfaces in a dramatically different shape to others, makes life as a programmer hard.

So, if we understand the value that a consistent API can bring to software, could we apply the same ideas of abstraction to the way we work as teams?

When the engineering group exists as a single entity, there’s a single way of operating, and a single interface for anyone outside of the team. We can think of this interface is the Team API. It’s the set of methods and protocols the team exposes.

As soon as the team starts to become a team of teams, this single interface needs to mature into a interface which is consistent between teams. It becomes necessary to ensure that an individual team, the wider business, and other engineering teams, can collaborate efficiently and effectively with each other.

Defining the Team API

The Team API defines the way the team will operate with others. It provides the routine definitions, protocols and tools that are used to engage with the team. Much like a software API, a consistent Team API makes it easier to build products, deliver value and fix problems across the business.

At its basic level, the Team API should define:

  • The communication protocols between members of the team and anyone external to the team
  • The way the team accepts work items
  • The way the team delivers work items
  • The way the team shows progress on work items

When your engineering team consists of multiple teams, these points need to be consistent. It’s less important that the implementation is consistent, just that the Team API is.

Just as with the implementation of a software API, teams should be free to change their implementation of the Team API to focus on methods that work for them.

With this in mind, a good Team API should also:

  • Abstract away from how the team implement the API
  • Hide the internals of the team implementation of the API
  • Remain relatively stable

In one organisation, I encountered a situation where each team had different Team API. Some teams made themselves available over Skype, whilst others used Slack. Some teams required stakeholders to raise tickets in Trello, others used Jira, whilst the rest relied on a conversation with the product owner. The differences created unnecessary confusion and cognitive load, and reduced accountability for deliverables. The engineering team couldn’t articulate their priorities, and they were unable to manage their dependencies.

Conversely, another team I worked with defined the communication protocol of their Team API as Slack. All teams had a channel, and it was easy to find and ask questions of a team in through a single medium. There was a single defined interface, and a shared understanding of how to communicate between teams. Teams were engaged with customers, stakeholders, and other engineering teams (I actually think that some of this was because Slack is such a good product, but the single communication protocol more than played its part).

Innovation in teams

Whilst the Team API should be consistent, the underlying implementation can change. If the Team API defines that incoming requests are made through Jira tickets, then it shouldn’t mean that the team must use Jira for their day-to-day work. If Trello works better for the team, then they should use that. In doing so, they will incur a cost of managing two systems, yet the overall net benefit might be worth it.

So, although the Team API should be stable, individual teams should continue to innovate the way they work. Teams should continue to inspect and adapt the way they operate, always looking for areas to improve. The abstraction that the Team API provides enables teams to evolve the way they work, trying out new things without impacting the wider engineering team delivery.


No system lasts forever, and eventually there becomes a time when an API needs to be deprecated, and be replaced with something new. With this in mind, it’s just as important that the Team API has a defined method for innovating and communicating changes to its consumers. Any changes that are made need to implemented swiftly and comprehensively. The efficiencies produced by establishing a consistent Team API cannot be realised by running multiple versions simultaneously.

Snowflake teams

Whilst engineers appreciate the value of consistent software API, there’s a challenge in providing a consistent interface to the way they work. Teams often hold the opinion that they are special snowflakes, and that by conforming to a standard interface, they’ll be constrained in how they operate.

In most cases, this isn’t true. Developing a consistent Team API provides everyone with a common language, and shared understanding of how to collaborate between teams. A common interface fosters collaboration, as you no longer need to put effort into understanding the way another team operates, or rely on knowing someone in the team to resolve the issue you have. It also helps your team. There’s a well-defined interface for requests coming into your team and for you to communicate out, helping to remove the distractions that can occur when channels are not well defined.

At this point, I think it’s worth adding a warning. Rigidly adhering to your Team API, can harm collaboration. At one company, I encountered teams who refused to speak to each other without the necessary tickets being raised first. Even if the conversation was to find out whether the ticket was being raised with the right team. It’s clear then that although the Team API needs to be consistent, it also needs to be flexible. To this end, we should recognise that there are different types of requests, and that they probably need different channels of communication. This can also be encoded in your Team API.

In closing

A good API defines methods and protocols whilst hiding implementation. Good API are also consistent with others across a similar domain. We can use both these ideas to improve the way the wider business operates with engineering, and how engineering teams work with each other. Software engineers appreciate the consistencies and abstractions provided by API, so maybe it’s time to start building Team API with these ideas in mind.