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.

An updated Joel Test


Next month it’ll be 16 years since the original publication of the Joel Test. In case you’re not aware of the Joel Test, it’s a simple 12 question check for evaluating how good a software team is. It’s not meant to be exhaustive, and scoring is simple – 1 point for each question you can answer yes to. If you’re scoring 10 or lower, you’ve got serious problems.

In the last 16 years, software engineering has changed a lot, and I think it’s time to update Joel Spolsky‘s “highly irresponsible, sloppy test” (Joel’s words, not mine).

The original Joel Test:

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

One of the strengths of the original test was the ability to get a quick yes/no answer to each of the questions. This was possible because the questions are closed, easily understood and unambiguous. In my revised list, I’ve attempted to recreate this, as I think the simplicity and succinctness is valuable.

I’m also not going to push it past 12 points. It’s pretty easy to create a long list of traits a modern software team should exhibit, but by keeping it short, I aim to focus on those things that will bring a team the most success.

Whilst I’m a fan of development with agility, and extreme programming, I’ve tried not to slant the list too much in this way. I think there’s a tendency within our industry to believe that becoming agile will solve all of our problems, and will mean that we’re building software the “right” way. However, it’s just the fact that sometimes, for some projects, implementations of agile such as Scrum or XP aren’t necessarily the right answer.

So here it is, my take on the Joel Test. Just as irresponsible and sloppy as the original, it’s the Steve Test:

  1. Do you use source control?
  2. Can you build and deploy your software in one step?
  3. Do you build on every commit?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you measure your progress in terms of value delivered?
  7. Do you have a runnable spec?
  8. Does your environment foster collaboration?
  9. Do you use the best tools money can buy?
  10. Is testing everyone’s responsibility?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

1. Do you use source control?

Hopefully it should be painfully obvious how necessary this is to building software. Even for personal projects, and experiments I use source control. The clear favourite at the moment is Git (and Github) however, I’m not going to go as far as pushing that teams should all be using DVCS in order to get a point.

2. Can you build and deploy your software in one step?

We need to move beyond single step build being the target, and more towards single step build and deployment. The ability to do this is at the heart of continuous delivery, and for more progressive teams, continuous deployment. The ability to create a software package in an automated single step, and then deploy that package in a similar manner, creates massive opportunities for the team and business.

A team getting a check mark here will typically have a set of scripts which create a build and package that build ready for distribution. They’ll also have a set of scripts that deploy the application to wherever it needs to go – be this a set of servers, a PaaS, or the app store.

In all cases, there’s no manual intervention required from a developer, apart from running the script. Removal of the humans from the process, removes the potential for mistakes, and ensures that a predictable, repeatable and resilient process is run each time the software needs to be updated.

3. Do you build and verify on every commit?

It’s widely known that the smaller the feedback loop, the better. Since Joel’s original list we’ve got much better at managing the building and testing of applications, creating many libraries and tools to help us in our work. Computing power has also improved dramatically, so that builds can be executed in a manner of minutes, rather than hours.

So, rather than building once a day, the aim should now be to build as frequently as possible, in order to tighten the feedback loop. In order to achieve this goal, the team will need to have some sort of build server in place. Whilst it’s not necessary to practice continuous integration to achieve this goal, doing so will increase effectiveness.

It’s also my belief that it’s no longer good enough to just build every commit. We should be aiming to provide some level of verification as part of this build. Typically, this is done through unit testing, however I’m appreciative that for some teams, this might not be the right answer, and other automated verification checks might be more appropriate. For that reason, I’ve not included the specific verification required on each build.

4. Do you have a bug database?

I’m not a fan of stock-piling defects with the view of fixing them later. In my experience, later never comes. I do concede though that knowing the issues with your products is important, as is communicating to your stakeholders your intentions on fixing them. A bug-tracker is an effective way of achieving these things, so I think that for these reasons it’s still relevant.

That said, I firmly believe that all teams can benefit from having a 0-defect policy – fix it or close it as “won’t fix”.

5. Do you fix bugs before writing new code?

Known defects should be fixed before writing new code, with those minor defects that we “won’t fix” recorded and justified. Not doing so builds up debt in the project, and as with all debt, the longer it remains more interest it accrues increasing the cost to repay.

I was considering changing this question to “Do you work on the thing that delivers the highest value first?”, however the measurement of “highest value” is open to interpretation. As this would lead to a question which is ambiguous, the original remains.

6. Do you measure your progress in terms of value delivered?

Scheduling software delivery with milestones and deadlines is no longer an effective way to ensure that delivery of a product is achieved. Apart from anything else, it becomes necessary to estimate the amount of time needed to complete the work, and unless the nature of the work is precisely the same as something else which has already been completed, this estimate is likely to be unreliable.

Because of this, your schedule is likely to be unreliable, and as such, the only thing that you’ll end up measuring is that 3 months worth of time passes in 3 months.

It’s therefore better to aim for a team that measures it’s progress in terms of value delivered. In order to be able to achieve this, it’s necessary to be able to measure the real customer value delivered. Creating the ability to measure real customer value will unlock other potential within the team such as the ability prioritise requests and requirements on those things that bring the highest return.

Focussing on delivering the first 20% of the project that delivers 80% of the value can sometimes be enough.

7. Do you have a runnable spec?

A subtle, yet important modification to this question. Having a specification for your software sounds like a reasonable thing to aim for, yet with no way to verify that the specification and software is in sync, there’s no way of knowing that the specification is valid. Systems also change as they are developed, as new requirements are uncovered. The specification therefore needs to be a living artefact, able to change and iterate as the software does.

Having a specification which describes your system, and that can be used to evaluate the implementation is much more valuable. The specification will evolve as the software does, and you’ll be confident that the specification still accurately describes the state of the system.

Your runnable specification also helps to support questions 2 and 3, as you might want to use as part of your build verification stage.

For some teams, this will mean adopting tools such as Cucumber and writing your specifications using Gherkin. I don’t think it’s a necessity to use these tools, yet they do facilitate writing runnable specifications.

8. Does your environment foster collaboration?

In the original list, question 8 promoted quiet working areas for programmers, to help them get into the “zone”. Whilst I still think that there is value to this for some tasks, I believe that an environment that fosters and promotes collaboration will form a better basis for an effective software organisation.

Lots of companies have tried to short-cut their way to collaborative environments through movement to open plan office spaces. The intention is a good one, yet the execution is poor, and there is a slow growing backlash against the open plan office. What’s more, I’ve personally found that open plan offices encourage engineers resort to noise cancelling headphones when they need to get individual work done. When the whole room has headphones on, you have to question whether the switch to open plan offices was worth it.

Instead, we need to make spaces where individual teams can collaborate effectively. Teams should have well defined areas, with the tools they need (question 9) such as whiteboards and information radiator screens. The team themselves should be in control of their environment and be able to modify it to something which works for them. This includes repositioning furniture – much to the dismay of many facilities managers.

It also stretches to the way teams are incentivised and rewarded. Whilst many software companies have dropped stack ranking, it’s still widely used in the corporate world. Stack ranking pits individuals against each other, with each person attempting to demonstrate their worth above others – not really what you’d expect of an environment which promotes collaboration is it?

Collaboration is also promoted where individuals are encourage to contribute outside of their specialism. As an example, teams that segregate testers from engineers aren’t supporting collaboration. An organisation with defined silos such as these will be more likely to run into problems delivering software.

9. Do you use the best tools money can buy?

Anytime you ask an engineer to use a sub-standard tool in order to do their job, you’re adding to their frustrations at getting the work done. Joel lists some good examples of micro-frustrations that an engineer might encounter from not having the right tools. A couple more examples might be not having the right IDE for the work you’re doing, or not being able to use the best monitoring or logging systems.

It’s not just about money though, it’s also about freedom of choice. Giving engineers the same standard laptop build as everyone else in the company, complete with restrictions on what can and can’t be installed is a sure way to frustrate people.

Freedom of choice should also extend to the software stack used to build a product. Java and Oracle RDBS is not the right answer to every problem. Forcing square pegs into round holes won’t lead to productive teams and good quality software.

10. Is testing everyone’s responsibility?

Testing is no longer only the responsibility of testers. Modern software development, and many of the checks in my new list rely on testing being part of everyone’s role. I expect that engineers write tests, and that figuring out that something works is not left to another team (see above).

The argument that Joel makes around engineers being more expensive than testers, and the follow on that you should have a testing team in order to achieve developer cost efficiencies is no longer relevant. Testing is a craft, in the same way that development is a craft and as such, a tester will add skills to a team in the same way that a front-end or back-end engineer will. I hope that we’re moving past the idea that testers are somewhat lesser individuals in an software organisation.

Making testing everyone’s responsibility ensures that we’re building quality into our products, rather than attempting to tack it on at the end. It has the consequence of tightening the feedback loop between writing code and testing it, meaning that the time between issues being found and fixed, becomes shorter. In the case where engineers are building automation checks, the time taken to execute this loop could be seconds. Isn’t this much better than throwing builds over the wall for others to verify?

11. Do candidates write code during their interview (process)?

At some stage in the interview process, any engineering candidate should be writing code. You’re hiring this person to write code, so you need to see how they go about it, and what their code looks like. Personally, I prefer to pair with candidates, as the feedback loop is tighter, and I can evaluate their coding skills in a fair way.

In my opinion, writing code on a whiteboard doesn’t enable you to get a check-mark here. It needs to be done in a natural environment, under standard working conditions.

12. Do you do hallway usability testing?

I think this is still really relevant. There are lots of teams that do much, much more than this in terms of usability testing, and that’s fantastic. However, I think that this should remain as an attainable minimal goal for all teams.