What defines a good Engineering Culture?

Nasir Ghulam
Travelex Tech Blog
Published in
5 min readApr 7, 2017

It’s THE question that gets asked at numerous conferences, interviews, meet-ups, coffee breaks, one to one meetings etc.

Well, the answer IMO is that there isn’t a single factor at play here. In fact there are a number of mantras to create and maintain a culture that allow people to express themselves when solving issues and writing code.

I’ve worked in a number of different organisations and each have had their own “Secret Sauce”.

Wikipedia’s definition on “Secret Sauce” :

“A secret ingredient is a component of a product that is closely guarded from public disclosure for competitive advantage. Sometimes the ingredient makes a noticeable difference in the way a product performs, looks or tastes; other times it is used for advertising puffery. Companies can go to elaborate lengths to maintain secrecy, repackaging ingredients in one location, partially mixing them in another and relabelling them for shipment to a third, and so on. Secret ingredients are normally not patented because that would result in publication, but they are protected by trade secret laws. Employees who need access to the secret are usually required to sign non-disclosure agreements.”

Ok. In the various Engineering departments that I’ve worked in, we weren’t strictly patenting anything or branding ourselves but rather the “Secret Sauce” was the collection of environmental conditions that existed.

Here are the ingredients that I’ve liked and prescribed to the most in my career :

  1. Be Customer Empathetic

Isn’t this the core reason why we’re here? Businesses of all shapes and sizes have customers, so focus on them. Make your Engineers customers of your products first. Start by giving them the products and time to get to know the pros and cons of your product portfolio. They’ll surprise you when they use the product and suggest improvements.

If you’re able to get the Engineers to field real customer calls, this is a great way to ensure they understand the product issues faced in the real world. I recall one story of a small start-up wanting to address continued product and service issues. One day the CEO of this small firm decided he wanted to get his Engineering team really customer focused. He did this by placing the “Customer Call phone” (a real Red flashing phone!) in the middle of the Engineering desk. Every time it rang, there was a real customer on the phone with a genuine issue. What did this do to the Product?. It changed the quality of the code, testing, release process and vested the team in creating a better product. Ultimately, it cut call volumes down immediately and resulted in happier customers.

2. Hire for humility

I often say this, hire the person that is humble in what they’ve achieved and how they interact with the team. Hiring for humility will benefit an organisation’s growth as you’re picking someone who’s open to debate and has the ability to give others space to discuss and disagree. Also, someone who doesn’t want the limelight all the time and more importantly wants the team to succeed for the single goal (What) and purpose (Why).

Hiring for humility isn’t about hiring those who don’t speak up and contribute when things aren’t right but in-fact the opposite; hiring someone who likes to review and challenge can enable the right outcome. I call that having passion for what you believe in.

3. Be a life hacker

Hire those that like to explore and hack things all the time, whether it’s in their own time or at work. Hire people who are creative by nature; this is what Engineers are. Engineering is a creative craft, so exploring new technologies, looking at efficiency in new languages and new ways of working is paramount in any learning organisation. Hackers make the best Engineers as they’re prepared to be bold and stand out when needed. At Travelex we’ve allowed our teams to explore their craft by picking the tech that best fits the job and the results have surprised us.

4. C.I.

Continuous Improvement and not Continuous Integration (although the latter is also critical!). It’s important that as an Engineering organisation you are improving on what you’ve built and invested in. Doing a bi-weekly retro is ok but it doesn’t touch the surface of actually setting aside time for a review of the processes, environmental conditions and goals setting. This gives you a consistent measure to see if you have reached the desired outcomes.

I often find that downtime between sprints and delivery is a really good time to unpick what’s been done, time to learn something new, add a skill or two. Valuing Engineers having downtime (spare capacity) is actually a good thing. After all, are we really productive 100% of the time all day, every day?

At Travelex we’ve had the fortune of having Agile coaches early on in our cycle to help with the mind state of continuous improvement and “Kaizen” (change for better). However, you don’t need Agile coaches to help instil the state of CI or your Kaizen; just trust your Engineers to help build the desired mind state.

5. Get things done.

Whether it’s the upgrade of Jenkins, or adding new features to our platform and Product, I like to hire those that prescribe to the attitude of “Getting things done”. Many times I’ve seen the “Get the job done” attitude being the degree of separation between success and failure. Hiring for this mind state has been the critical ingredient to any Engineering team that I’ve had the opportunity to work in.

So, in reflection of the “Secret Sauce”, and in my experience, nobody has a single recipe. Different ingredients make up the sauce, one size or flavour doesn’t fit all. Environments, leadership, company vision, Project Management, rituals and investors all add to the conditions. The trick is to find the ingredients that make up the sauce and then tweak them slowly to improve on. It takes months and years to create the right flavour for the sauce, so when you find one that works, treat it well and honour the code and conduct you’ve established. Isn’t this basically what we call iterative improvement?

--

--