How to keep an office tidy: guidance from an Office Manager

by Valentina Soricaro

We are one: a strong company identity


Red Badger has one of the  strongest company identities  I have ever encountered in my working life.  We feel strong for the company, we like being part of it and the idea behind it; we are indeed always trying for new and funny ways to enhance this even more.

We just love being Badgers (follow us on Twitter  and you will understand what we mean when we talk about #badgerlife).


Ladies Badger monthly dinner #badgerlife

Ladies Badger monthly dinner #badgerlife




I think this is an important factor for a successful working business.

When the  employees feel like  part of the company, they act like they are part of its vital inner core, what can go wrong then? They will work their best magic, because they strongly want the company to succeed, as they will succeed too.


Good staff management skills are key to obtain a solid company identity. When your staff is treated well, it  will reward you (on this note you can read the blog written by Cain, one of our founders on why they have decided to take us on a island for Red Badger’s 5th birthday).


The office is our everyday  home


So the point here is: the Badger identity, the strong feeling we have for this company and for each other has to be applied to our office almost like a transitive property.

We love being Badgers, we work in our Badger office everyday, this has to mean we love our Badger office.

People need to be inner part of the office and need to start seeing it as their second home (after all we spend here the longest part of our days). We  need to almost feel like we  are part of the office, (but unlike furniture we are the vital part of it).


Creativity for the bathroom toiletries

Creativity for the bathroom toiletries



Our vintage stationary apothecary, newcomer in the office

Our vintage stationary apothecary, newcomer in the office



Not to mention the office reflects and  gives the first impression of what the core of the company really is. Clients understand very well when people are happy. Happy people work better; this means more profit for the company and in simple words more money. And a tidy office space where everything is accesible and in its right place helps make happier people.


So it’s all a circle really.


The secret is to make people understand that to care about the office means caring about the identity they choose to take, when working for a specific company

To treat the space almost like a living and breathing thing, living and breathing together with them.

Me and some other Badgers with our new awesome vintage fridge

Me and some other Badgers with our new awesome vintage fridge




GraphQL and The Open Movie Database. From introspection to Inception.

by Albert Still

I recently returned from React Europe 2015 where Facebook released GraphQL, it’s been in production use at Facebook for several years. In a nutshell a GraphQL API opposes REST and add-hoc endpoints, it allows a client to efficiently get all the data it needs in one network request, and it allows a developer to concisely and declaratively express their apps data requirements. 

They released two things: the GraphQL spec and GraphQL.js which is a JavaScript reference of the spec. To learn GraphQL I suggest reading the GraphQL Introduction blog, the spec and the Star Wars specs inside the GraphQL.js repo. 

Using node with restify and GraphQL.js I have created a small app that let’s us query The Open Movie Database with GraphQL. My apps github repo is here and it’s hosted at https://omdb-graphql.herokuapp.com. This endpoint accepts POST requests with a GraphQL query in the body and it will return a JSON result! There isn’t much to my app, the meaty GraphQL file is here and the rest is a vanilla restify app.

A cool feature of GraphQL is introspection. By definition this means “the examination or observation of one’s own mental and emotional processes”. And in this context it means we can inspect the GraphQL schema with GraphQL queries! So lets pretend your busy project manager pinged you my GraphQL endpoint https://omdb-graphql.herokuapp.com and asked you to make a feature for looking up film details. But as you go to ask for the API documentation link you remember introspection! Lets query my endpoint and learn what it can do, then make a query to fetch a movies data.

First of all lets look at the query type in it’s schema. This is the top level entry point into the system and it’s compulsory every GraphQL schema has one.

Here we can see the query object has a field on it called movie that takes a compulsory argument called title in the form of a string. The field returns the Movie type which is of the kind OBJECT, lets take a look at it.

Now we can see all the fields the Movie type has. They mostly all return strings or lists of strings, but the imdb field returns an Imdb type. Let’s take a look at that.

The Imdb type has three fields on it. But they have scalar kinds not seen before. The IMDb id of the film is an ID, the rating is a Float and the votes count is a Int.

Great so know we understand the Movie object and it’s nested Imdb object. Let’s query for the film Inception!

Notice how with GraphQL queries the data we get back matches identically the shape of the query. This is awesome for client developers because they know exactly what they will get back. No custom parsing logic etc. Also it’s important to note no excess data is returned in the response. This is usually known as over fetching. For example imagine I just needed the movies director. In a REST api I would wastefully have to get the whole movie object sent down the wire even though I only want one attribute! 

If you want to play with this GraphQL endpoint I suggest using Postman. Simply send POST  requests to https://omdb-graphql.herokuapp.com with a raw GraphQL query in the body and you will get the JSON result. I lied above, the query type has an extra field on it, see if you can find it…

A few of us are super keen to use GraphQL in production here at Red Badger. Be interesting to see how it unfolds. Follow us if your interested to.


React Europe and GraphQL

by Jon Sharratt

Recently myself plus a few of the Red Badger team packed our hair curlers and rolled out to Paris on the EuroStar for the React Europe conference hosted in Paris.

One of the big topics that I and the team were interested in was GraphQL which turns REST on it’s head slightly. Turns out Facebook have been using it for a good few years and Lee Byron has been working on it solidly for a good while.

React Europe Pass

What is it?

“GraphQL consists of a type system, query language and execution semantics, static validation, and type introspection.”

With this we declare an APIs schema / capabilities (types) up front the API supports in which validation and introspection can be performed. This is coupled with a querying language that allows not only querying of data but also manipulating data using the notion of mutation queries. All this is done via single endpoint rather traditional REST APIs have urls for each resource combined with HTTP verbs and error codes for validation.

If you wish to check out more in regards to the schema and the full capabilities on how you can start creating your own GraphQL APIs Facebook released a draft spec at the conference over at http://facebook.github.io/graphql/. Additionally to this it is exciting to note that Lee Byron built graphql-js https://github.com/graphql/graphql-js/ an implementation as a reference for everyone to start using and hopefully build out GraphQL implementations in other languages.

In the talk at React Europe it really was a shout out to the community to get involved and really evolve GraphQL into something awesome. I really hope this happens it is a fantastic concept especially if you are working on large complex applications with many clients consuming your API or require multiple APIs to be merged into a single data source / API.

So let’s take a look at a simple example to take a look at what is possible. I am currently working on a project that requires some orchestration of Amazon services. So on that note I decided this is perhaps a good place to start to experiment.

AWS with GraphQL

To touch briefly on some the querying power of using GraphQL I decided to start an experiment in wrapping the Amazon AWS Node.js SDK with GraphQL. The main benefits of this is that we can coalesce operations across all of the Amazon services with some awesome GraphQL queries. I don’t really dig into the server code itself but you can take a look on github in how this works.



Let’s take a really simple query, let’s say we wish to list all of the message queues we have within our Amazon account, the GraphQL query (which are strings) would look something like:

Simple eh!? we can basically send a query of which ever resources we like (that the GraphQL schema has defined / supports) along with the attributes we wish to return to a single endpoint. In this case we just wish to return the url parameter of the queue. Similarly we can then request all of the topic I have within Amazon as below:

As the schema query is aware of both queue and topic types from a single API endpoint this is where the power of querying comes to light. Let’s say that we now want to return both queues and topics but decide that calling them “topics” and “queues” is not what our client prefers. We can use aliases to rename and combine the queries to return the structure of the data you require.


Now let’s take a look at mutations, let’s say we now want to create a queue within Amazon in the same light we can create a simple mutation query that accepts arguments, the name of the queue. To create a message queue you simply do the following:

Because a queue is defined as a single type the GraphQL server knows about we can again simply tell GraphQL with attributes we wish to return once the queue is created. Lastly the same combination of multiple queries as above can be applied to mutations. Say I wish to create 2 queues, then 3 topics, check it out!

As you can see this could be quite powerful if you imagine that you could create a queue add permissions, provision servers…. all from describing the Amazon AWS API with GraphQL. I haven’t touched on introspection or the awesome validation in this blog, it is more to give you a flavour of the querying power and open the eyes that there is now indeed a nicer alternative to REST.

If you enjoy using the latest tech like GraphQL, get in touch we are always looking for smart people interested in shiny new tech join us.


London React meetup – June 2015

by Alex Savin

React London Meetup June 2015

It’s summer in London. Despite the sun and Wimbledon outdoor screenings, we assembled once again at cozy Facebook Euston office with fellow Reactors to catch up on the latest cool trends and tools.

Joe Stanton on ES6, React Native and hot code reloading

We’ve got many requests for talks on React Native, and so here is Joe delivering excellent walkthrough, with updates on current status and new features. React Native now includes support for ES6 out of the box, thanks to Babel – which means you can start using most of the ES6/7 syntax goodness today.

Another important news is Apple policy change regarding hot code reloading in native apps. After React Native release Apple added one extra line to the policy allowing hot code reloading for apps using JavascriptCore. Joe went further and implemented a React Native iOS app that connects to the Amazon S3 bucket on startup, checks for updates, downloads new version of itself and on next boot starts using it. From developer perspective this is fantastic news – this means you can deliver features and fixes to the user instantly – as opposed to the usual AppStore approval process that takes several days to get through.

Michal Kawalec on FluxApp framework

Michal presented a web app framework called FluxApp. It is isomorphic, with immutable centralised state and semi/automatically generated actions.

Robbie McCorkell on cross platform development with React

Robbie delivered an important message on code re-usability when developing for Web and native platforms with React. According to a recent tweet Facebook was able to reuse 87% of the code on Ads Manager app between iOS and Android versions. In other news, React 0.14 version will move DOM rendering out of the core package. At the moment it is fair to say that you can re-use your flux architecture, dispatchers, actions, events and data fetching code across platforms. In future it might be possible to also recycle UI components – at least to some extent.

James Dellow on Digital Inclusion Network project

James shared a story of Digital Inclusion Network project where young people get a hands on experience with latest tech and software. 3D printing, virtual reality, software development and necessary tools are all made available for any young person who wants to get involved. There is a Kickstarter campaign currently going to support this project.

Follow us

As usual, you can follow @londonreact for updates on the next meetup and be first in line to get your ticket. Huge thanks goes to Facebook for helping out with the venue and filming of the talks.


Badger Digest June 2015

by Alex Savin


Badger digest is back! Here you’ll find a sneak peak into the most discussed topics on Red Badger internal Slack channels for the past month.

Title image credit: Tiago Cabral



  • HTTP/2 Picks Up Steam – it is now enabled by default for all apps on iOS 9
  • The Code Climate Platform launch
  • How to write a Git commit message

When a commit merits a bit of explanation and context, you need to write a body

  • The Web is getting its byte code: WebAssembly. Also, an important tweet by Brendan Eich.
  • The most important part of your CSS – Dominik Piatek on sensitive subject of grids
  • Empire: A self-hosted PaaS built on Docker & Amazon ECS
  • Unit testing React components without a DOM
  • Update on our very own Arch framework


#Project management

  • Why is UK productivity lower than in many other countries? Podcast episode by BBC Radio 4.



  • That’s Real-Life Responsive Web Design: Meet The Brand New Smashing Book 5
  • Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future
  • SurviveJS – Webpack and React. Go from zero to Webpack and React hero.

A tweet for thought

Current state of browser support for high quality image formats.


The most important part of your CSS

by Dominik Piatek


There is a bit of CSS that you will write or more likely use from a library that will influence your whole project. It is crucial and it’s quality and adequacy can make or break your productivity as you develop. That CSS is the famous (or infamous!) grid.

Laying out things on the web has always been a struggle. You only have to dive into HTML email to see how terrible it was because table layouts are still a thing there. As graphic design practices trickled through to the web and tables were starting to get filled with data instead of layouts, some people discovered that we could abstract some of that CSS into grid systems. And rightfully so – controlling width is one of the most used CSS properties. It was, all in all, a great success. Our grids maybe were not as advanced as in traditional graphic design, but they were a fantastic abstraction that saved us a lot of time.

Then came along responsive design. It demanded a lot more from our humble grid. But as older, buggy browsers were pushed out and using things like box-sizing, inline-block and negative margins became common (and reliable), the grid adapted.

It’s quite trivial to write a grid these days; but it’s not trivial to know when to use inline-block or floats. It’s not trivial to polyfill our good ‘ol grid with flexbox either. Twitter’s Bootstrap grid might not be ideal for your project; you’ll know it when you are going to have to change it all the time. The breaking point will come when you will not use the grid because you will be afraid of the side effects that can cause and you will make little, impromptu, error-prone grids on the spot.

All this should tell you one thing: the grid needs special attention from the developer, from the outset. You can see this by the emergence of tools like Gridset and efforts on bringing the cassowary constraint solver to the web. On most projects, laying out is a massive part of writing HTML & CSS. The better your tools and your understanding of them, the smaller your headaches later.

So what should you do when assessing a grid? Some key points should be:
– how can you safely extend the grid? (ie. what do you do if you need different gutters somewhere down the line?)
– what are the limitations of the grid (ie. how many columns can we have? Can the grid be used in any container? Is there some patterns that should be avoided)
– does it use floats, inline-block (do we need to care about extra white space), flexbox, something else?
– how is responsiveness handled? how can it be extended?
– will it work with other frameworks that we are using?
– how does it fit into the naming scheme used for our CSS?
– what browsers does it support?

If you create your own, setup a test page and run it through Browserstack or similar. Make sure your new rad idea works across the browsers you want consistently. The big benefit of doing this is that you don’t have to settle for the general case of the grid, you can make allowances that your project requires.

Realising the above, I’ve created a library that lets you create grids on demand called Taco Grids. Currently written for the Stylus CSS preprocessor, it’s an experiment in using a flexible tool for creating easily extensible grids. You can read a bit more about Taco in my previous blog post or jump to it’s home page to look at the docs and example usage.


Arch framework – update

by Alex Savin


Arch framework official logo by Sari Griffiths, Clementine Brown and Blanca Tortajada

Arch is an isomorphic single page app framework built on top of React and Immutable.js. It was announced and open sourced at the  React London meetup in April by Viktor and Tiago. Many of us at Red Badger are really excited about Arch, its performance, flexibility and openness. Last week we had a first of its kind Arch hackathon at the HQ, and here are a few updates we’d like to share with you.

Official Twitter handle is reserved – it’s ArchFW. Follow it to get quick updates on development and future events (especially if you’re in London!). It is also one of the quick ways to contact team, ask questions and get feedback.

New dedicated organisation is now available on Github – Arch-js. It contains all Arch -related repositories, including Core of the framework, command line client and example apps from the original announcement talk.

We invite you to join the discussion under the core repository. Post issues you encounter, or comment ongoing topics. If you have an idea on missing example app that would enable you to try the framework, feel free to add it here.

Crash course into Arch and functional web programming is now fixed and available for brave new users. You’ll find even more chapters on Arch internals, concept of immutables, cursors and isomorphism in the docs folder. We also have reserved domain archjs.org for the upcoming webpages.

And don’t forget the talk from London React meetup by Viktor and Tiago with introduction to Arch and apps with centralised state.

What’s next? Few things:

  • More sample apps, in ES6 and Livescript
  • Designing more powerful routing DSL
  • Default support for unit tests
  • Improving command line client

Arch is now properly open sourced with BSD 3 license. We hope you’ll like it.


Smooth Sailing- Designing businesses to deliver value

by Sinem Erdemli

“Improving experience starts with every customer interaction. Your customers see you as a one entity.” -Jiri Brezovsky

This is a quote from his post Stop wasting money on a “beautiful” interface it’s about the importance of improving the overall experience, rather than creating beautiful UI. It’s a brilliant and valid point, one which we at Red Badger think about a lot.

Even though a beautiful design, a high quality piece of software or sky-high conversion rates may seem like the ultimate goal of running a business, especially on a day to day basis, there is one crucial bit that shouldn’t be overlooked. That is to deliver value. 

I just want you to get the job done

As a customer, I don’t care about how well your metrics are doing, whether or not you’ve met your sales goals or when the next software update is due. 

I only care if I can get what I want from you or not. How much do I need to give [time, money, effort] vs. how much I get out of it. 

In the end, if I want to get my hands on a new computer I want to decide which one is for me, where and how to buy it, and how to set it up and who to get in touch when something goes wrong. All of that should be easy peasy, but is rarely so. 

The times they are a-changin’

Businesses have complex structures, they exist on multiple channels, partner with numerous 3rd parties and carry ways of working from the day they were established. 

A business runs with the help of multiple ‘departments’ ranging from marketing, sales, merchandising, customer services, online, suppliers, logistics. There’s also a big board of stakeholders to please with the outcomes.

“The problem [with designing in silos] is that customers don’t just care about individual touchpoints. They experience services in totality and base their judgement on how well everything works together to provide them with value” -Andy Polaine et al.

Each and every department has different targets and end-goals. They are usually focused on just one channel or a single touchpoint of the customers overall experience of a customer. The problem arises when the links between these individual touchpoints are left unattended, when they don’t appear on the targets because they are not tangible enough to make it to the boardroom. As a consequence, your customer’s experience with your business ends up being nothing but a broken, inconsistent and painful journey. 

When you think about it there is only one simple relationship to focus on, whether you’re in the boardroom, at the shop floor or in the office developing the website; and that is the one between you and your customers. 

 Love thy customer

value transaction

When it comes to deciding whether or not to come back, or to ‘recommend the service to their friends’ customers will not think about one interaction in isolation. They will think about how easy it was to use the website, how the staff treated them on the shop floor, they will consider the call they received by customer service team when their package was late all together. Overall their decision will depend on how easy it was to reach their end goal, the whole reason why they chose to get in touch with your business in the first place. 

Keeping the bigger picture in mind at all times will allow you to have meaningful conversations when you’re collecting requirements. It also will give you a reason to talk to each other, regardless of your position in the business. 

Stop and ask why how who

Before you get in your productive autopilot mode, stop and have a think about what the greater goal is.
are you doing what you’re doing?
-How might you make it better for the person at the other end?
-Who else might have an effect of the delightful experience you’re trying to create? 

Go speak to your colleagues, your stakeholders, customers. Involve as many parties as you can. Make sure you, as a business, are giving the same message, have the same tone and same level of delightfulness for your customers throughout their journey with you. 

Then and only then will your efforts count for something. Don’t forget, your profit, sales, conversion rates can only improve if you love your customer, try to make their journey with you as happy and valuable as possible because your customer will love you back. (and will most likely recommend you to a friend, if that’s what you’re after)

further reading

servicedesigntools.org has plenty of methods you can use to think about your business offer as a whole. I would recommend checking them out. Or have a read through Andy Polaine’s book Service Design, it is delightful and one of the best you can find around. 

let’s spread the love together

If you crave consistency in experiences and want to help businesses create value with beautifully designed high quality software get in touch. It doesn’t matter where you’re coming from, as long as your intentions are well:) 


Yosemite by Cocoaconf: Zen and the Art of Tech Conferences

by Robbie McCorkell

Half Dome peak

It’s 4am and the jet lag has woken me up far earlier than I would have wanted. I open the curtains and am greeted with pitch blackness so I pick up my phone and check on the twitterverse with whatever limited phone signal Yosemite has to offer. By 6am the light is beginning to creep over the High Sierras and I’m itching to get outside, so I throw on my running gear and escape. The air is saturated with the sweet smell of pine but it’s too cold to stop and admire, so I start running in any direction.

After a few minutes I notice the lack of noise around me. There is nobody around for as far as I can see or tell, and I seemingly have the entire national park to myself. The only noise penetrating the forest is the sound of early birdsong and the rushing of a waterfall, so I follow the latter.

When I arrive at the base of Yosemite falls the place is deserted. It would be only later the same day that I discover this area is usually packed with tourists taking photographs and admiring the view. But for now it’s just me and the tallest waterfall in North America. I stay at the falls for a while, it’s difficult to leave, but as the morning mist begins to fade I make my way on and start running in the direction of Half Dome peak with an extra spring in my step.

But why was I here? This wasn’t in fact some idyllic spring holiday I had taken, but an Apple conference. They called it ‘Yosemite by Cocoaconf’.

Yosemite Falls

CocoaConf is a touring training conference for Apple developers based in the US, and has been going on since 2011. Since Apple started naming its operating sytem OSX after Californian locations it seemed obvious that somebody at some time would organise a pilgrimage to one of these, but to my knowledge nobody had. CocoaConf just happened to be the only conference ambitious enough to attempt this with OSX Yosemite. Who knows whether this will become a theme for the next versions of OSX, but we all hope they pick somewhere nice. On two separate occasions during the conference I heard someone say “Thank god they didn’t name it OSX Oakland”.

The theme of this conference was unlike any I had been to. Sometimes feeling more like a spiritual getaway than a tech conference, the talks at Cocoaconf Yosemite were more focused around self improvement for you and your company. Talks ranged from tips on managing your team and projects to learning how to avoid burnout, to the history of the Gregorian calendar; all of course within the context of Apple and its products. 

There were also some more technically focused talks in the mix including Christa Mrgan’s excellent walk through designing interesting looking apps for iOS8, Andy Ihnatko on the history of wearable devices and expectations for the Apple Watch, and Andrew Stone’s wacky talk on the lifestyle of working for Steve Jobs at NeXT in the 80’s.

Mountains and sky

However, the focus of this event was not to learn or discover new technical skills. This conference was more focused on bringing together a set of likeminded people to discuss the platform they love to build upon, trade war stories from their careers, and share ideas. Whilst sharing ideas with people of different backgrounds can lead to new and interesting revelations, I came to realise that sharing ideas and philosophies with likeminded people can often strengthen and expand those you already have.

Every person I met seemed to be at the top of their field, working for large companies and startups alike, all with their own perspective on building apps for the Mac and iPhone. And whilst meeting people in the industry was great for professional networking, I was also very pleased to meet some familiar voices in the world of podcasting including Guy English, Serenity Caldwell and Jason Snell.

In addition to the location and talks at Yosemite, the third main attraction was the attendees themselves. The conference had a very small audience of approximately 80 people, and every one that I met had fascinating backgrounds and views. Networking of this kind was made even easier by the included daytime activities that had been organised to help attendees explore Yosemite valley. For example, a guided photography walk around Yosemite falls with TED conference photographer Duncan Davidson allowed me improve my photopraphy skills and trade shots with fellow attendees and speakers alike. Unlike most conferences, networking was never the primary goal but instead happened entirely by accident through a mutual enjoyment of the location we found ourselves in.

Footbridge in the woods

I would usually look for a more technically focused conference so I approached this one with an air of skepticism. But I found all of the talks to be fun, interesting and dare I say it, inspirational. I would almost go as far to say that in comparison to a traditional conference where there is no guarantee that I might come home learning anything new, I gained more value coming home from a conference that made me see the work a do a little differently and with a boosted enthusiasm. And what better place to feel inspired than one of the most beautiful national parks in the world. A wonderful experience for someone in any industry.

Needless to say, I came home from my time at Yosemite hungry for more. One day I’ll go back and explore all the High Sierras have to offer in full. But for now I encourage anyone to consider attending a conference not quite as focused on a particular language or technology, but on your profession as a whole. You might find it will help you to see your work differently for months or years to come. And who knows, you might just have fun in the process. 

View looking back at Yosemite

Red Badger offers an annual £2,000 training budget to experience things like this. Sound good? Then come join us.

Nerdy Babelfish – The Importance of Communication in Tech

by Roisi Proven


Here on the Red Badger blog, we certainly don’t pull any punches where technical discussion is concerned. In a lot of posts, we assume a high level of knowledge when it comes to our readers, and avoid going overboard with explanation in order to get to the core of our discussion without being boring.

I for one think that this is a great thing. We want to attract the most intelligent, highly skilled people to interact with us, and we can’t do that if we over-simplify things. I feel hugely proud to be a part of a company that has the courage to push forward with new tech, no matter how complex it may seem at first glance.

However, for the less technical people in the team (I include myself in that) it can present a bit of a dilemma. For testers and project managers especially, who bridge the gap between technical and operational, knowing how to explain things is crucial. When you work with a team of such highly skilled developers, you have to be able to not only keep up with them, but make a very complicated thing highly digestible from a business perspective. 

From Code to Conversation

To me, good communication skills are vital if you want to work in tech of any kind. Just because one person understands everything there is to know about a system, doesn’t mean the person fixing the bug you write does. Similarly, your client will likely have a very different, non-technical focus to the project. As a result, you need to be able to distill a sometimes mind-bogglingly complicated technical problem into a form that even the least technical Product Owner can understand.

Let’s take something that, for anyone in web development, will be very familiar. Deploying code from a local environment into a live environment. This will obviously vary depending on how your business functions, but the core steps are the same. You write your code, spinning up a local environment to check your work. You write some automated tests to cover your work, and then submit a Pull Request on your repository for review by another coder. This code will then be tested further and deployed on to your live environment, usually running the tests through a Continuous Integration tool such as Circle or Travis. Simple right?

Or maybe not. Here is a top level breakdown of concepts and terms in the paragraph above that may leave non-technical people scratching their heads:

  • Deployment

  • Local environment

  • Automated tests

  • Pull request

  • Repository

  • Continuous Integration tool

That list is just the tip of the iceberg, as I’m sure if we were to go into more detail about the the build process we would lose people even further. So when I’m explaining how long a build will take to a customer, there is absolutely no point in me explaining it like this. 

From Conversation to Code

This process can most definitely work the other way around as well. If a client adds a bug of their own to the database, or requests a new feature, it can be easy to dismiss it because it seems frivolous or insignificant. This is because, as technical people, our priorities are different. We want to have something that runs smoothly and looks beautiful, and woe betide anyone who asks for something that we feel may compromise that.

A notable example of this for me, is some of the tracking and 3rd parties that I’ve seen requested for integration into various projects. If you look at them in a purely technical way, they are by and large quite undesirable. They may risk slowing down your site, or perhaps cause conflicts with already implemented features that will take more work to fix.

This won’t matter to your client. What matters, invariably, is the continuing success of the business. If the implementation of a 3rd party could hugely improves customer engagement on their site, arguing with them about milliseconds is unproductive and may become needlessly combative.

So What Can You Do?

On both sides, the point at which communication breaks down is the point at which people stop asking “Why?” From the tech side, why am I making this change? Why is doing it this way better than doing it in a way that may seem faster? There’s no need to get technical with those answers.

Going the other way, we should be asking why we are implementing, while still staying empathetic to the overall needs of the client. Yes, to a developer certain 3rd party integrations may seem painful, but if they have sat down prior to starting the work and learned a bit more about the situation surrounding the task, the work will feel more meaningful, and you may even be able to suggest a better alternative.

Through all of this, you should always try to put yourself in the other person’s shoes. I will never sit down and have a conversation with someone without first spending some time thinking about how they might take the news I’m going to give. Often it’s not about the words you say, it’s about the delivery. So I can boil a build deployment right down to “the feature you want will take us 3 hours to take through our internal process” and as long as I’m delivering that with meaningful information such as timescales, the complicated stuff isn’t going to feel so important.

Once you put tech jargon or business jargon aside, it really is just two people having a conversation about something that they both really care about. As long as you remember that the person sitting across the table from you wants the same thing, the rest is easy.


Want to work somewhere where you don’t need to be afraid to stand up and give your opinion? We’re hiring! Join Us