The Power of Sensible Defaults

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. The fractured ecosystem of development occurs as each developer or team makes their decision in isolation, only considering their immediate consequence. The silos and diverse technology stack reduces the opportunity for reuse, leading to teams reinventing boiler plate code for testing, monitoring, instrumentation, and perhaps even business logic.

In this environment products become harder to evolve, developers struggle to move between teams and the bus factor quickly tends towards one. Running systems become harder to maintain as the idiosyncrasies of each language run-time needs to be understood, leading to more specialists needing to be on-call. Containerisation and 12-factor apps (itself a kind of Sensible Default) have helped, but as anyone who has been on-call will tell you having a good understanding of the apps running is invaluable when the worst happens.

A recent medium post by Ozan Onay, ”You are not Google”, shows another side to the “best tool” argument, rightly pointing out that you probably don’t need that cool new tech you’re proposing. Often a technology which is “good enough” really is good enough for your domain. There’s no need to go further.

I believe that teams can overcome these issues by employing Sensible Defaults. A Sensible Default is a practice, language, framework or tool adopted as the default choice for an engineering team. It’s the commonly agreed approach to building products, and the first thing to consider when starting a new project, or when there’s a new problem to solve.

As an example, you may decide to use React for your Sensible Default for front-end development, Flask and Python for building web services, and PostgreSQL as your database technology.

Notice, I’m not saying it’s the only choice, it’s just your default. Engineers are still empowered to choose other technology where necessary, but alternatives need to be justified in relation to their advantages over the Sensible Default.

I’m not the only one that sees the advantage in having defaults. In 2014, Ben Vinegar wrote a medium post about how “The best tool for the job, isn’t always” where he describes the reasons for standardization whilst he was at Disqus.

So, whilst it may feel restrictive, and at odds with everything you’ve read about motivation and autonomy, I believe that more teams should embrace the power of Sensible Defaults.

Documenting your Sensible Defaults

The choice for the Sensible Default is one that should be carefully considered, both in relation to the technical problems it will need to solve and the skills in the organisation. A Sensible Default choice has wider ranging impacts that just the local team, so the candidates for the default need to be assessed against different scenarios aside and with the wider team. I’m not going to go into the process of making technology choices, as this topic probably deserves it’s own blog post, but I do want to comment on how decisions should be documented.

In agile environments, decisions around architecture and technology have a habit of being lost especially as teams move to more evolutionary ideas of architecture development. The motivations and context behind decisions become difficult to track, and it becomes difficult for team members, both new and existing, to keep track of them as projects develop.

Therefore, once debated, discussed and dissected, technology choices that become the Sensible Default should be documented for future reference, using something like Architecture Decision Records (ADRs).

By keeping a versioned record of Sensible Defaults the team not only have a repository when new developers can learn about the development environment, they also have a set of records which provide details of the decisions for later review as the context changes.

It’s likely that you already have a number of Sensible Defaults in your organisation. For example, you may have settled on Java for building web services, and you may find that most of your web services have been developed using Spring Boot. If this is a case, run a fit-for-purpose assessment on the technology in use and document your new Sensible Defaults.

Deviations from the default

Whilst the Sensible Default should be the first choice, it’s not intended to be the only choice. Engineers can deviate from the default, providing it’s a considered decision.

When describing this concept to people, I often use the analogy of a fairground ride height restrictions. Good architecture decisions are based on clear system requirements, both functional and non-functional. A Sensible Default decision builds on these requirements by adding a set of people based requirements such as cross-skilling and training. This list of requirements is the bar a new technology must get over in order to be considered for use.

There’s always a cost to introducing a new technology, and anyone wishing to do so must provide details on how they plan to educate the rest of the engineering team. They can defer this cost, by limiting the scope of the training to those directly working with the new tech, yet in doing so, they carry the risk and burden of supporting the project until the technology is more widely known.

This may seem a little unfair on the team that wants to experiment, however it helps to increase the bus-factor within the wider team, and helps to reduce the chances of a single point of failure developing who is more prone to burn-out.

Deviations from the Sensible Default should also be stored in ADRs, with the relevant context and discussion that lead to the deviation. Storing decisions in this manner help teams avoid repeating conversations and re-debating choices when new team members join, or teams change. They also provide useful information for future maintainers of a project.

The number of deviations should be kept to a minimum. Should the number of deviations continually grow, it’s probably time to consider whether the Sensible Default is the right one.

Encouraging experimentation

Many times when I explain the concept of Sensible Defaults, I’m challenged by engineers who believe that by setting defaults I’m reducing the scope of innovation and experimentation. It’s a fair challenge, and I believe that it’s important that new technology is evaluated and considered for use, lest a team end up with difficult to maintain legacy software that is hard to recruit new team members for.

To ensure a team doesn’t end up in this situation, I encourage the use of innovation or free development time. During this time, engineers are free to use whatever technology they like to build non-mission critical applications. This is the space to experiment with the new deployment technology, or JavaScript framework which Hacker News is blowing up with this week.

By using new technology to build real-world applications, automation and tools that help improve engineering efficiency, engineers make it past the “getting started” tutorials and start to understand how the technology works in a production-like environment. Achieving this level of experience with a technology means that the debate over it’s uses can reference existing applications, rather than just replaying the top comments and opinions from the blogosphere.

From chaos to cohesion

Whilst engineers are comfortable adhering to standards (see arguments over the correct use of HTTP methods and status codes in RESTful web services as an example), when it comes to choosing technology, the drive to use the newest technology coupled with the move to service based architectures often leads to a somewhat chaotic and overly complex development environment.

I hope that I’ve shown here that by employing critical technology review and documenting the results as Sensible Defaults, engineering organisations improve their operational efficiency and resilience. The needs of the many outweigh the needs of the few.

However, Sensible Defaults are just that - defaults. They’re the first choice, not the only choice, and deviations are still possible, providing we make these choices consciously.

We can use innovation time and non-mission critical development for experimentation, helping to ensure that the development team has the opportunity to learn about new technology in a production-like environment.

Finally, I’d like to close with a quote I found whilst researching this blog post. Whilst the post it comes from doesn’t talk about software, I feel it sums up the need for Sensible Defaults well.

Sensible defaults can reduce friction and provide simplicity anywhere one can think to apply them. They are the bedrock of minimalist practice and a quiet mind. @patrickhone - Sensible Defaults

Lead Dev London 2017 Field Report

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. Carly Robinson delivered her excellent talk on "Mentoring Junior Employeers at Slack HQ" which included references to the importance of a supportive environment for entry-level developers. Also on this theme, Jill Wetzler used empirical evidence in her talk "Tips for Building Diverse Teams" to show the issues that under-represented people face in STEM environments.

Another key themes was the need for leaders to be deliberate in the way they communicate. Adrian Howard showed how lessons learnt from conducting user research can be applied to your one-on-ones in his talk "How to Talk to Earthlings", Katherine Wu ("Ask v Guess Cultures") and Mathias Meyer ("Building and Scaling a Distributed and Inclusive Team ") both talked about the impact of culture on communication, and Erika Carlson gave the audience a set of clear actionable techniques for improving giving and receiving feedback in her talk "Better: Fearless Feedback for Software Teams". I'm really looking forward to this video being available to rewatch and share with my teams.

Lara Hogan put a different spin on the leader's role in communication, wrapping up the conference with "Leading by Speaking" which gave advice on building and delivering a great speaking performance when under the spotlight. I found this a great way to round off the conference and the next book on my reading list is Lara Hogan’s book Demystifying Public Speaking.

Aside from these key themes, I found Cate Huston’s talk on mobile application development ("YOLO Releases Considered Harmful") particularly relevant to me. In the last year I’ve moved from web application development (YOLO Dev), into the world on packaged software where you don’t own the update cycle and process. The majority of talks at conferences have the inbuilt assumption that audience are building web applications and I found it good to see someone talking about a different (more relatable to me) set of challenges.

Finally, I couldn’t complete a field report without mentioning Nickolas Means’s talk on "The Original Skunk Works" at Lockhead Martin. Nickolas told the audience of the struggles engineers encountered in building supersonic jets, with very little resources and to tight timescales. He showed that the lessons from Lockhead Martin and “Kelly’s rules” are practices that are applicable to software development, and the way we build teams. Nickolas has a fantastic ability to tell a story, and I'd recommend taking the time to hunt out some of his previous talks.

This was the third year of Lead Dev in London, and my third year in attending. Each year the content has got better, and each year I come away with new ideas and techniques to apply. What’s more, I come away with verification that I’m doing the right things, and to put it the way of one of the speakers - “this is my tribe”.

Leadership and management is a craft. Moving from a senior developer to a technical manager is a career shift, not a promotion. Events like Lead Dev give me a chance to interact with others who have reset their career and to continue hone my craft. It also gives me the chance to hear about the challenges that others face and build out a network of folks going through similar things to myself.

Lead Dev London 2018 was announced (although no dates yet), along with further events in New York and Austin. More information about the conference, including speaker bios, schedule and event notification can be found on the Lead Dev website.

Career Development Planning Questions

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. During the session, he asked a number of questions about my current role and then asked me to transport myself to a point in time in the future. Once there, we discussed what my day-to-day work looked like, and uncovered some of the aspects I considered important for any future role.

We then spoke about the distance between my current day-job and the role I described as part of my future self, and built a plan to address the differences.

The technique is very similar to the futurespective retrospective activity that many agile teams use to uncover problems with the way they work.

I've used this technique with others in my team to build their own career plans. In doing so, it's helped me to understand some deep-seated desires within people I work with, and given me a better understanding of the things I need to do to help them reach their goals.

If you want to run a similar session, I've included the questions I ask below. I usually conduct these sessions in front of the whiteboard, asking the questions, and writing or drawing the answers on the board. This allows the person whom you're conducting the session for to really concentrate on visualising the future, rather than having to take notes.

First, let's talk about your current role

  • How do you describe you current role?
  • What does a typical day or week look like for you?
  • Who are your key stakeholders?
  • What makes you happy?
  • What was the best thing you worked on?
  • What irritates you?
  • What was the worst thing you worked on?
  • Thinking of a typical week, how would you plot your time on a pie-chart?
  • Are you more of a specialist or generalist?
  • Are you more strategic or operational?
  • Are you reactive or proactive?

Now let's look forward. Imagine we meet in 5 years time...

  • Where are we meeting? What are we doing?
  • Where do you live? Have you moved?
  • What are you doing wth your free time?
  • Are you working? Is it full-time or part-time?
  • Which country are you working in? Which City?
  • Are you working from an office or somewhere else?
  • Do you travel with work? How many times a quarter?
  • What industry do you work in?
  • Tell me about your work. Do you work for a company? Or yourself?
  • Are you a developer? What are you building?
  • What is the culture of your workplace?
  • What projects are you working on? Tell me about them.
  • Tell me about the company you work for.
  • How big is the company? Where are they based?
  • What is your role? Who are your stakeholders?
  • Are you managing people? How about mentoring people?
  • What do others say about you?
  • How do you learn new things?
  • How do you stay current?
  • Thinking of a typical week, how would you plot your time on a pie-chart?
  • Are you more of specialist or generalist?
  • Are you more strategic or operational?
  • Are your reactive or proactive?

Looking at you future self...

  • Is there anything else that will help me understand your future role?
  • What aspects are non-negotiable?
  • What answers are you certain of? Which are more difficult to answer?

Comparing you and your future self...

  • What are the main differences?
  • How did you move between specialist and generalist?
  • And how did you move between strategic and operational?
  • And between reactive and proactive?
  • What skills are you missing?
  • What do you need to improve?
  • What new experiences do you need?
  • What's going to stop you from achieving your aspirations?
  • Who's going to stop you from achieving your aspirations?

Finding great places to work

Early today I tweeted this.

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. Later in the year I left Marks and Spencer to join Alfresco.

In both cases, I’d become frustrated with my current company and thought that there existed better options for me to progress as part of a different team. I left eBay because I was fed up with the international travel required in the position, something which was becoming more frequent as my role became more senior. I left M&S when it became clear that my ideas of what great engineering teams look like didn’t align with the way the senior leadership wanted to take the team.

As I moved teams, I was optimistic that the new position would relieve those frustrations I’d had with the old one. Whilst in most cases, this has been true, plugging one hole only caused the frustrations to come from elsewhere.

What’s clear in every change I’ve made, is that there are very few (in fact, there maybe none) truly great places to work. Whilst there are many places which may appear fantastic from the outside, there's always something about them that will cause frustrations.

Therefore, if there really is few great places to work, then it’s likely that you’ll end up at the ones that aren’t so great. If this is the case, what matters more is whether you have the freedom to drive the place to be great.

So, rather than assessing your next position on how good the team currently is, look at how likely it is that you’ll get the opportunity to make them better. A team that has a track record of inspecting and adapting, and can acknowledge its problems, is likely to be a better long term fit than the team that already believes it has achieved “great” status.

Are Scrum Masters Harmful?

This year, I’ve had the opportunity to work with agile teams across a couple of different companies. Whilst Alfresco and Marks and Spencer work in different industries, both have adopted agile as their way of working. To help teams deliver, both employ full-time Scrum Masters, and at both companies, most agile delivery teams use Scrum, complete with all the ceremonies, to deliver software.

Seeing the way that both development teams work over the course of the year, I’ve begun to wonder whether the role of Scrum Master is actually harmful. To be clear, I’m not saying that the people in these roles are bad people, rather that by employing a full-time Scrum Master, you are unconsciously locking yourself into a particular development methodology.

The Scrum Guide defines the Scrum Master role as:

“The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.”

Embedded in this definition is the assumption that by employing a Scrum Master, that you have someone who’s responsibility is to guarantee that your teams are adhering Scrum. This person ensures that teams are following the Scrum practices (estimating, burn-downs) and operating within the confines of the Scrum framework. The Scrum Guide adds this restriction when discussing the use of retrospectives (emphasis my own):

“The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.

For some teams, other development practices or frameworks are more appropriate. For example, it may be more appropriate for a team to use Kanban when more flexibility is necessary, or when teams of specialists exist.

Unfortunately, over the past year I’ve seen teams cargo-culting Scrum in their teams, and it’s my hypothesis that having a role of Scrum Master is partly to blame for this. It becomes hard for a team to challenge Scrum as a way of working, when a person they work with every day holds a role that is solely there to employ Scrum. A vote against Scrum can be seen as a vote against this person. This results in the team continuing with practices that don’t help them to deliver software in their context.

The good Scrum Masters recognise that the job title is just that, and that it shouldn’t unduly influence the way the teams work. However, this can’t be said for all. Challenging Scrum as a framework is seen as questioning their validity, and so they act to defend all aspects of the framework. It’s in these cases where I consider the role of Scrum Master to be harmful.

Of course, it could be that the organisation wants to use the Scrum framework, whatever the implications. This doesn’t feel right to me, as it’s at odds with the ideas behind the agile manifesto, in particular “people over process”. In these cases, further inspection is required to understand why an organisation is so hell-bent on implementing Scrum. I’d wager that in many cases it’s down to a lack of understanding of agile development.

So, what is the alternative?

I’ve talked this through with a couple of colleagues, and others in the software industry. GDS steers away from the Scrum Master role title, instead using the role “Delivery Manager” for providing team support, and developing team efficiency. If job listings at NotOnTheHighStreet, Co-Op, ITV and ASOS are anything to go by, then other teams are taking a similar approach.

I’ve not worked with a company that uses this approach, so I can’t comment on what impact this change has, or whether this title change has other unintended consequences. One of my concerns would be the introduction of another “Manager” role (to add to Engineering Managers) into the engineering organisation.

Would M&S and Alfresco operate better after just changing the job title of a few people? I think it’d send a good message (we’re not tied to Scrum), however I think it’s just one aspect of a change in culture that’s needed. After all, the same people will still hold these titles, and if these individuals see Scrum as the one true way, then it’s unlikely to have the necessary effect to improve team performance.

Another alternative is to remove the role entirely, and have the team self-organise around the work. Operating in this mode requires engineers that deeply understand how what they do fit into the wider business, and have the necessary skills to introspect and improve. Many teams can’t do this effectively without support.

Finally, there’s the approach we took whilst at eBay. Some teams had Scrum Masters, yet it was a hat a developer wore rather than a dedicated full-time role. For some teams this worked really well, however for most the Scrum Master role was seen as team secretary and as such wasn’t a hat many people wanted to wear.

The right approach for your organisation will depend on your context and the goals you’re trying to achieve. I don’t think that there’s a single way of solving this issue, however I’m also pretty sure that unless you are unreservedly dedicated to the Scrum framework, that the role of Scrum Master can have unintentional consequences.

The titles that individuals take on in your organisation will influence the way you work. I’ve described the effect the role of “Scrum Master” can have on the way a team works, and the (sometimes) unconscious decisions we’re making by employing people into this role. It’s a widely known idiom within software development that “naming things” is one of the two hard problems in computer science. We’ve seen here, that this not only applies to code, but also to people within your organisation.