From getting down with the kids to moving up the pay scale read about the last three talks from the latest Djugl get-together

In our two previous blogs, we gave you a rundown of the first seven Lightning talks at our recent Djugl event. Now we’re onto the final three – and like those that went before, they were diverse and fascinating. Our speakers hailed from Amazon, Beamly and our lovely hosts, Potato. Here’s what these very different speakers had to say…

Working less and getting paid more
This talk certainly had the audience paying attention: David Smith, of Amazon Web Services, explained what Coders need to do to break through the salary ceiling. In his opinion, great technical skills are all very well. But when it comes to moving up to higher salary brackets, soft skills are essential. Using a typical unsuccessful project as an example (and some very amusing gifs), David illustrated how lack of communication leads to a rushed product – and an unhappy customer. It’s at this point technical folk need to step up and make things better by talking to the other teams including Sales and Creative. David says this is how Developers increase their impact and access more senior roles. We saw a lot of the audience taking VERY detailed notes…

Getting involved with work experience
Michael Strutt left us with a warm and fuzzy feeling, as he explained how Potato has been giving back to communities by providing work experience. Surprisingly, not all schools now include work experience as part of the curriculum. For those that do, it’s increasingly difficult to find organisations prepared to participate. Michael talked us through Potato’s experience, sharing the two-week programme the business created and the impact it made. Feedback from the children showed that it was a formative – and in some cases, future-defining – experience for them. Michael also showed the audience how their businesses could follow Potato’s example, with a simple guide to running work experience.

Mind the gap…
The last talk of the night was Transitioning from Web Development to Data Engineering, with Beamly’s Dami Onajole. Having worked in both arenas, he was well equipped to compare and contrast the two different professions. Dami described the parallels between NVC and ETL (Extract, Transform, Load) before going on to highlight two key tools he’s been using as a Data Engineer. The first was Airflow, which allows you to schedule tasks and manage dependencies between tasks. The second was Pandas, a Python library, which according to Dami, is to Data Engineering, what Django is to Web Development.
 
If you enjoyed reading about our Lightning talks and would like to come to the next event, follow Austin Fraser – we’ll be posting details online.
 

How Strawberry and Poetry can improve Developers’ lives: Djugl debrief part 2

The story so far: at the latest Djugl community event, we welcomed ten fantastic speakers. We met the first four in our first blog and in this one, we’re focusing on the following three. They are Ahter Sonmez, Patrick Arminio and Daniel Knell. Each had some hugely useful tips for our developer community, which we’ll summarise here…
Back to the future!
For Software Engineer, Ahter Sonmez, there is something more important than code: version history. In his talk ‘Back to the Future: Benefits & Intricacies of Re-writing the History with Interactive Rebase’, he showed the audience how to go back and change a commit history. Why is that necessary? Because you may need to consolidate or re-order commits so they make more sense in the future. Using interactive git rebase as a ‘time machine’ he demonstrated how to go back and re-write history so commits tell a more comprehensible story. Ahter strongly recommended making this a daily task in order to create sustainable and maintainable code base.

Why Patrick loves Strawberry
Next up, was Patrick Arminio, a Backend Engineer with @OnVerve. He’s a big fan of Strawberry, a GraphQL tool library for Python. Having found that REST simply didn’t scale as his team built increasingly complex apps, he turned to Strawberry – and has been using it ever since. “Strawberry uses modern Python features to build APIs,” explained Patrick. He then went on to demonstrate some of these features including ‘type hints’, ‘data classes’ and the fact that with Strawberry, you have a single end point. If Djugl developers didn’t have a taste for Strawberry before, they certainly will now.

Poetry in motion
Our seventh speaker was Daniel Knell, Chief Artisan at Artisan of Code Ltd. He proposed a tongue twister of a talk, ‘A Poetic Posture for Python Positively Perplexing Packaging Predicament’. In short, it was all about the virtues of the build tool, Poetry. This uses the pyproject .toml, a file defined in PEP516. “It defines a file where can find some special stuff around how to hammer a package and define stuff for tools,” Daniel clarified. And helpfully, it’s a file that’s being used by more and more tools. So, what can Poetry actually do? “Poetry finds all the metadata and dependencies. It’s all in one file and it’s a sensible format. The other thing that makes it powerful is PEP517,” Daniel explained. With a quick demo to illustrate these points, Daniel successfully showed the audience Poetry in motion.

Seven speakers done and three to go – look out for the final installment of the Djugl debrief, coming soon!
 

Djugl Lightning Talks: From nailing 121s to winging it as a CTO

The scene: Potato’s offices in central London. The crowd: curious developers with a hunger for industry knowledge. The refreshments? A sizzling summer barbecue – but that’s another blog. This one is all about the ten amazing speakers who made the evening such a success. We can’t cover them all today, so we’re going to focus on our first four amazing guests.  
Testing times
First up was Chris Beecham of @ThomsonReuters, whose topic was Unit Testing. This was among our techier talks, but Chris made sure that everyone was on the same page by drawing on a scene from classic sci-fi adventure, The Matrix. Using the famous red pill-blue pill quandary, he demonstrated a high level testing process. It was a great way to illustrate what to do when you have an object method which uses a resource that isn’t available in the local development environment.

Too many hats?
Chris passed the baton on to Leah Cohen of @DigitalGlacier. She tackled a very different subject: What Makes Managing Engineers so Difficult? Drawing on her own experiences, Leah explained how organisations often expect line managers to be hands-on senior developers too. The result? Someone who’s too distracted and burnt out by different tasks to be dedicated to their team. Shockingly, only 58% of managers have actual management training, according to Leah. Her solution is simple: distinct career pathways for Engineers and Managers.
121 101s
Our hosts, @potatolondon, also had some expert advice for the audience. Agile Coach, Laxmi Kerai (likes: owls, cat gifs and reading) took the stage to discuss the basics of 121s. She gave some hugely useful and practical tips to make 121s productive and less intimidating, from changing the setting by heading outdoors, to designing the agenda together. Laxmi also talked about the importance of clear, two-way communication and listening to feedback. And watch out for those ‘door handle moments’ – casually making hugely significant comments just as you usher the employee out the door!

A crash course for CTOs
Coming up to the half-way point, we met freelance developer, Richard Kirsch. Except he wasn’t always a developer – in the past, he was also a CTO. Having never performed the role before, he had a serious learning curve. And that formed the basis for his talk: How to Blag Being a CTO. The self-deprecating title concealed a wealth of guidance that was relevant for both experienced and wannabe CTOs, from getting the critical stuff right, to seeking advice and fighting for your time.
Phew – so much to think about and we’re only four speakers in! Stay tuned for part 2 of our latest Djugl debrief.

Real life at Austin Fraser (part two)

Ever walked into an office and felt at ease straight away? Although it’s hard to pin down, we think that vibe is incredibly important. At Austin Fraser, we’ve gone to great lengths to make sure our people feel happy and enjoy working here. We’re honest about our culture – which is one of the reasons we’ve won ‘OpenCompany’ status from recruitment website, Glassdoor.
There’s no getting around it – succeeding here takes drive. But if you’re motivated and up for a challenge, we’ll do all we can to help you achieve. It starts with a positive culture where there’s a sense of camaraderie and colleagues supporting each other. If people have a problem, they don’t moan – they speak up. In fact, there’s a lot of emphasis on communication, not just with team mates, but with clients and communities too. We’re not about hard sell. We’re about taking the time to build connections.
It’s all part of our company vision, which has been established by our leaders – Pete Hart and Derek Simpson. They started the business in a garage, back in 2007 and they haven’t forgotten their roots or the importance of staying humble.
Having said that, our leaders encourage ambition and have plenty themselves. Which is why our list of international offices keeps on growing. The people who thrive here are equally determined and have an affinity with our values: Earn it, Own it, Love it. In other words, striving for goals, doing things the Austin Fraser way and being passionate about what you do. We appreciate our team’s hard work and talent enormously, which is why we don’t skimp on incentives. You’ll find they’re always worth the effort, whether it’s a night at an amazing restaurant or a trip somewhere exotic.

So what about daily life in the office? What can you expect? Although everyone works hard, we’re also sociable and love getting together. There are always events such as quiz nights, birthday parties, sports days, team building and of course, the Annual Sales Meeting – aka, an epic Christmas party! And then there’s our All Hands Live – a global business meeting that’s streamed live to every office around the world. It’s a chance for every employee to hear from our leaders and pose questions in real time. And underpinning all this is a culture that’s based on fairness, respect and equal opportunities. Whoever you are, wherever you’re from, you’ll be welcomed here. We are committed to recruiting the best talent, regardless of background.
Want to know more about our team and what it takes to join us? Take a look at /en/join-us/

Real life at Austin Fraser (part one)

A lot of organisations talk the talk. But, at Austin Fraser, we also walk the walk. In other words, when we say life’s good at our business, it’s not just sales blurb – we’ve got facts and figures to prove it – and that’s why we’ve won ‘OpenCompany’ status from recruitment website, Glassdoor. We’re sharing this in a two-part blog, so you can get an insight about what life is like at Austin Fraser.
Let’s start with something fairly basic and fundamental: your pay.
If you compare us to similar businesses, you’ll find our salaries are pretty competitive. We keep an eye on the rest of the industry and review them regularly. What’s more, they come with a range of benefits that are the equivalent of up to 35% extra value on top of your pay.
And speaking of our international offices, there are seven in total – which you could transfer to thanks to our relocation package. You’ll find us in Reading, UK; Hamburg, Munich and Berlin, Germany; and Austin, Denver and Dallas in the USA. Excitingly, there are two more sites coming soon: San Diego (October 2019) and LA (2020). Each site is in a great location in the heart of the city. Go inside, and you’ll find an attractive, modern environment, with great facilities. We’re talking open spaces for collaboration and state of the art tech with dedicated break-out zones. Everything you need to excel and achieve on your terms.

Working remotely is also a reality, thanks to our hi-spec technology. Everyone has a MacBook, whatever their level of seniority. We’re always looking at ways to improve the kit we provide too. As tech evolves, we’re investing in new developments that benefit our staff. 
However, there’s no point in helping people perform at their best if there’s no way for them to progress. We take your development as seriously as you do and make sure you know how you can advance. That’s why our career paths are as clear-cut and transparent as they get. You can see how your role can evolve – and how much you can earn – right from your very first day. Plus, we’ll make sure you have the Learning & Development to build your skills so you can get yourself promoted. This is an aspect of life at Austin Fraser that stands out in the industry. We believe in giving people the support to get where they want along with the freedom to plan their journey. Our end to end training includes modules for new starters, managers and senior managers. What’s more, learning is simply a part of our culture, so it’s considered perfectly normal to take time out for training.
So that’s the important, practical stuff. But life here is about so much more than that. Stay tuned for the second part of this blog, where we’ll tell you why people like working here so much – the warm and fuzzy stuff!

Developers are now expected to do everything by themselves

For the February edition of Leaders in Tech | Berlin, Austin Fraser invited Andrew Holway, founder of Otter Networks, to speak about the current state of DevOps, the impact of new platforms like Kubernetes, and how technology leaders should think about both infrastructure and knowledge management in their organizations.
 
Andrew’s presentation (which was recorded and will be available subsequently) started with a review of the “old world” and the “new world” of software engineering, from when engineers needed to take care of hardware, networking, and all sorts of complicated operational issues in order to run software online. In an in-between phase, Amazon Web Services has abstracted away many of the annoying and frustrating parts. However, Holway posits that the main user that Amazon creates its tools and services for is a DevOps engineer, and that it’s not reasonable to expect developers to directly consume AWS’ APIs. In the new world, Kubernetes and other automated platforms like it have dramatically reduced the complexity of operational work that DevOps engineers used to handle, virtually eliminating the need for DevOps as a discipline.
 
DevOps is FSCKed by Andrew Holway slides:
https://docs.google.com/presentation/d/e/2PACX-1vRV4B7JSfyukZRFosukMNwQu7rt8KH1nor44CswGF6zBrdkuwueBJvDg6ZPGoqXHH8AbeA7kYx5AD2v/pub
 
The talk sparked many questions and discussions among the 50+ attendees, who ranged from CTOs to team leads to startup founders. For example, one question from the audience concerned how databases are handled. Andrew’s response revealed the larger trends within software engineering: “Even if you’re consuming your database from the cloud provider, you still have to have some knowledge of databases as a developer – most full stack developers have a good understanding of the databases. The role of DBA disappeared some years ago, I haven’t seen one in ages. The role of DevOps engineer is going the same direction as DBA, and these roles are just being pushed into the development team. Developers are expected to do literally everything by themselves.”
 
Dmitry Galkin, a cloud solutions architect at Cloudification.io attended the Leaders in Tech event because he had checked Otter Networks website in advance and was curious to see what the talk would be about. In the end, he had a different perspective than the speaker. Even though he thought it might work for smaller teams, for bigger and more complex organizations, Dimitry said, “I wouldn’t be so sure that DevOps will disappear in the next five years.”
 
Nicholas Wittstruck was also in the audience at the Leaders in Tech event in Berlin, he has been at several Leaders in Tech meetups. Nicholas is the Head of Shop and IT at Bringmeister.de, and his take on Holway’s presentation was that, “It’s important on a strategic level – when it comes to the next project that you work on, you have these things in mind. In this specific case, when it comes to deploying your  infrastructure next, maybe it makes sense to have a look at Kubernetes and do it on GCP [Google Cloud Platform], even though you’re using AWS right now.”
 
As a returning participant to Austin Fraser’s Leaders in Tech event series, Nicholas Wittstruck has some advice for people who are on the fence: “There are two things that I really like about these meetups. The first one is that there are really interesting talks. It’s also about meeting people that are in the tech scene in Berlin. I’m meeting some people again at each meetup, which is nice for networking. You get to know people who have similar problems.”
 
Many thanks to Secret Escapes for hosting this edition of Leaders in Tech | Berlin in their office in Mitte. Don’t miss the next Leaders in Tech event, become a member of our Meetup group. Leaders in Tech brings together CTOs, CIOs, VPs, Heads of IT, and other senior technology leaders to discuss current tech trends and build lasting relationships.

Lessons from Psychology and Pedagogy for Software Teams

On Wednesday, Feb 13th, 2019, Andrew Holway of Otter Networks will be speaking about the rise of productivity engineering, which aims to reduce the cognitive load that Kubernetes and other fully automated platforms place on software developers. His talk, “DevOps is FSCKED” will cover a lot of ground, including some important concepts from psychology. To help you get up to speed on these, here’s a primer on a few of the ideas that may come up in his talk.
Tacit Knowledge
Tacit or implicit knowledge is a category of expertise or skills that are gained through personal experience that are difficult or impossible to pass on through written or spoken communication. In contrast to formal or explicit knowledge, which can be codified in documentation, codified in books, or shared in discrete units, implicit knowledge tends to be created through experience and relies on context and practice.
Tacit knowledge is best shared or transferred through high-quality social interactions. Formal instructional environments often don’t work as well; something more akin to pair programming allows the learner to observe and practice with someone who already has the knowledge.
How does this relate to DevOps, Kubernetes, and productivity engineering? Holway explains, “To manage all the infrastructure as code, you have to have a dedicated person. It’s hard and annoying, and it requires a ton of tacit knowledge. You end up with a separate person, and you’re back to system administration and developer silos.”
Cognitive Load
The concept of cognitive load commonly refers to the idea that there’s only so much our brains can think about at one time, and if we “overload” the mind with too much, it tends to make more mistakes. In some settings, like in instructional design, it derives from the idea of “working memory” which suggests that short-term memory can hold a limited about of new information that a person can work with.
For developers and in software teams, the cognitive load burden can be thought of as the number of software-related issues or details that a person needs to keep in mind. If developers are also handling system administration-related tasks, the decisions they have to make and the impact of those details create an additional burden on them that wasn’t there before.
Is your interest piqued? Come to the event to find out how Andrew Holway will take these ideas from instructional design and apply them to technology teams.

Andrew Holway on DevOps: Held together with spit and hope

 
Later this month, Andrew Holway of Otter Networks will be speaking at Leaders in Tech | Berlin. His talk “Devops is Fscked” (Meetup), will look at how fully automated platforms such as Kubernetes are making it possible for software developers to utilize cloud services directly and eliminating the need for siloed infrastructure management.
I met up with Andrew to learn about his journey from sailor to supercomputer designer to freelance DevOps engineer to CTO — and now to teaching companies to eliminate their dependency on DevOps.
 
You started off in a totally different kind of engineering, on boats, doing rigging and some electronics, but ended up working with supercomputers. How did you start working with DevOps?
I was basically like a fixer, a problem solver. I worked in supercomputing for 5 years where I developed large scale supercomputer platforms for processing data from high-profile academic science projects such as the Large Hadron Collider. I came to Berlin and I started working in commercial sector stuff, and then in Amazon Web Services. I noticed that a lot of what I would build for my clients in AWS was basically only supportable by me. I didn’t realize it at the time, but when I look back on it… the nature of what I do is very complex and there’s generally only one of me. When I leave a situation, there tends to be something that needs to be taken care of. And often that thing cannot be taken care of because only I can take care of it.
This has been a common thread throughout every DevOps job that I’ve done. I’ve put together some solution, but when you’re building it, you’re often learning. That means you’re also generating a bunch of technical debt, just by the very nature of learning.
Most of IT is built out of technical debt. Everybody’s constantly learning about how to do the thing that they’re doing. That’s especially bad in DevOps because everything’s changing so fast. It’s especially bad when you’re consuming services from external partners, such as Amazon Web Services. Everything’s glued together with spit and hope.
Tell me about a previous company or team you worked with where DevOps wasn’t working.
I worked with a company in Berlin… I got hired by the then-CTO. It was a quite complicated system; it had many moving parts. Everything was written in Ruby and every single system was deployed in a different way. Everything! The main website was deployed on some servers in Rackspace. There were some other bits that were deployed onto ECS. Then there were some bits that were deployed in Docker on another platform. And some other bits were using another deployment method and another technology.
All these DevOps engineers that were there during the heyday of the company, they treated it as a massive learning exercise. Nothing was finished, it was all half-done experiments.
The DevOps engineers didn’t ever go back and fix whatever they had done before?
They had four engineers and all of them did whatever they wanted. Then they all went off and worked for other companies.
I’m pretty sure it was the unmanageable infrastructure which killed that company. It was insane, everything was unstable, everything was half-done, it was mind-blowingly bad. It was unmaintainable. This happens a lot. You have these DevOps engineers running amok. I’ve been that person: there’s no oversight, nobody else knows what they’re doing.
When did you realize that DevOps consulting wasn’t solving the actual problem?
The moment I walked out the door, nobody knew what I’d done, nobody understood it. You can write documentation until you’re blue in the face, but the knowledge of how to deal with all of this stuff, I know now is tacit knowledge. Tacit knowledge is knowledge which is very difficult to share or transfer verbally or written down. This is why documentation in software development is kind of a joke.
A carpenter can’t read a book on carpentry and sit and talk to a million carpenters, and then just make a table. Technical knowledge is tacit, you have to feel the tools in your hands. You can’t just read the documentation and do it.
How does Kubernetes change the relationship between developers and DevOps?
All of the complexity, which DevOps engineers previously had to manage, ceased to exist: in Kubernetes, all of the “Ops” have been “Dev”ed. Everything that I ever tried to achieve as a DevOps engineer is all delivered by Kubernetes out of the box: scalability, reliability, cost-effectiveness.
What is the ideal end of state for software developers using Kubernetes and productivity engineering?
They’ll have ownership of their own domain. They’re autonomous, they can write, they deploy, and manage their own applications. They  don’t need any third parties to do that. I consider that we’ve won when we never hear from people ever again. That’s our goal: to set people up so they don’t need to talk to us again.
 
To learn more about Andrew Holway’s predictions about DevOps and Kubernetes, strategies for transmitting of tacit knowledge, and the growing need for productivity engineering, join Leaders in Tech | Berlin on February 13th, 2019: http://eventbrite.com/e/leaders-in-tech-berlin-devops-is-fscked-tickets-54523716905
 

Austin Fraser supports ConnectTVT digital talent initiative

We are joining forces with ConnectTVT to support the region’s next generation of digital talent. As part of this collaboration we have sponsored five tickets for local schools, colleges and universities in the Reading area at this year’s inaugural Tech for Good conference.
Tech for Good is a headline event for the Festival of Digital Disruption (FoDD), the three-day town-centre tech ‘takeover’ in Reading, running November 21-23.
As a key employer in the Thames Valley, we are working tirelessly to lead the way in investing in digital skills and the wider tech economy in the region. Through our Leaders in Tech programme, we bring together C-suite and senior level executives to explore emerging IT trends, share expert insight and support the growing tech community.
Other investments include the new RDGUK Office Hours initiative, which aims to foster a collaborative ecosystem for local businesses, as well as more education-led programmes such as the recent Reading University Hackathon.
A long-time partner of ConnectTVT, we collaborated with founder Louize Clarke and her team to bring Glug Reading to the region as well as its 50 Game Changers initiative.
Mark Thomas,Technology Regional Manager, commented: “Working with talent in this space, it’s alarming to see the huge skills gaps in technology.  We’ve always championed ConnectTVT’s mission to make sure the Thames Valley maintains its leadership in the tech economy and are huge believers in paying it forward. We’re thrilled to be part of the Festival of Digital Disruption and hope that the next gen come away truly inspired to explore careers in tech.”
Louize Clarke added: “There’s a lot of conversations around investing in the next generation but we really need more investment on the ground to achieve this. We’re lucky to have friends in Austin Fraser who support our vision and genuinely want to connect young people with the opportunities that technology can offer.”

Is the role of CTO broken?

Are the financial benefits of becoming a tech contractor upsetting the traditional career progression and creating a shortage at the top?
This challenging question has prompted numerous conversations within our Leaders in Tech communities.
When we ask this question of engineers  –  particularly those with more experience in smaller companies  – they imagine a sort of ‘super Tech Lead’: a very senior engineer who is going to lead the technical direction of an organisation.
So what exactly does a CTO do all day?
Answers to that question from current CTOs have included:

Working with commercial stakeholders (CEO, board, investors), to identify the commercial roadmap over ‘x’ months.
Working with product owners and business analysts to develop a realistic product roadmap that supports the commercial roadmap.
Identifying a tech roadmap aligned with product and commercial roadmaps.
Negotiating when you realise the commercial or product roadmaps are unrealistic because of technical constraints. Note: negotiate, not “tell others it can’t be done”. Negotiation skills are critical.
Figuring out how to structure teams, line reporting, process and cadence within the technical team.
Getting the balance between feature development, BAU and technical debt/bug quashing right for the commercial and product culture within the business.
Keeping up to date with changes in law that have impact on technical roadmaps.
Preparation and negotiation of budgets to be spent on tech staff – salary budgets often have to be treated differently to others.
Preparation and negotiation of budgets around technical operations such as hardware, service fees (data centre, cloud, etc.), software licensing, patent licensing where appropriate, etc.
Validating all of the above with senior management and board members, mostly using the language they are most fluent in: finance. You will spend a lot of time building spreadsheets and slide decks, and you’ll ideally need to do basic interpretation of a balance sheet to keep up.
Communicating the above with shareholders and future investors whilst giving yourself enough margin to not get fired if it doesn’t pan out.
Setting cultural tone for the technical team. All of the below contribute to that, but ultimately you are going to set the example. The kind of behaviour you choose to reward is what the team will eventually value.

Notice, there isn’t much engineering going on here. Depending on what’s going on within your company, it’s unlikely you’re going to be spending too much time working on product, and it’s worth expanding on that:
In very small companies, you are going to have to work on the product directly. In larger companies you won’t have time to work on the product directly.
Leaders in Tech | Berlin
Join us on Thursday 18th October for the next instalment of Leaders in Tech | Berlin, a community for CTOs, CIOs, VPs, Heads of IT and other senior technology leaders to get together and discuss current tech trends.

Jason Franklin-Stokes – interim CTO with 30 years of successfully creating, building and growing technology start-ups in Germany, France, UK and US – will be discussing why the CTO role is dead! (or at least dying out). Are businesses demanding faster time to markets and user centricity? Is this shifting a focus from Tech to Product. Why do companies need a CTO? Or even a head of IT? If the CPO is the role that everything rotates around then surely the CTO is dead?
If you are a senior level technology leader, this is an opportunity for you to meet with fellow technology leaders from established and/or innovative businesses. To share in best practises, discuss up and coming advances in technology/methodologies & generally connect with like minded individuals with similar interests/challenges.

Leaders in Tech | Reading: Does size matter? Big Data Deconstructed

 
Leaders in Tech | Reading: Does size matter? Big Data Deconstructed
 
On the 13th September we hosted one of our most successful events today in which we discussed the benefits and trends of AI, Big Data and Machine Learning.
We discussed how to draw much deeper insights into our data, understand what motivates our customers and what slows down our production lines.
We identified that businesses leveraging big data and machine learning, can expect to see a marked improvement in their KPIs. For those not yet using big data, the biggest barrier is simply not knowing if the benefits are worth the cost and effort.
Adding machine learning and cognitive interactions to traditional business processes and applications will enable greatly improved user experience and productivity.
 

 
We were very lucky to have some excellent speakers on the night – covering a very diverse scope of topics:
Riki Dolby, Director of Engineering at InfoSum spoke about how data-driven business intelligence delivers tangible business value and competitive advantage.
Jon Stanesby, Director of Product Strategy at Oracle covered key points around what A.I. can teach us and what our knowledge can in turn effect A.I.

Ross Verrall, Senior Developer at Nvidia discussed the concept of demystifying the Deep Learning that is sweeping across multiple industries and is shaping the reality of day to day businesses
Ray Noppe, CTO at Advinia helped shed light on the impact of AI on the lives of people suffering with Dementia. This thought provoking talk gave a different perspective on the use of A.I. in day to day care.
As part of this we were able to entertain a huge number of Leaders in Tech with a four course wine and canapé tasting that proved an overwhelming success.
 

 
Thanks again to our speakers and all who attended our Leaders in Tech meet up held at our Reading HQ. We very much look forward to seeing you at our next event!

London Magento Users Group – F*&k Ups!

 
In our September instalment of London Magento Users Group, we will be hosting a F*&k Ups! Night. We will have speakers get up in front of a room full of strangers to share their own professional f*&k up. The stories of the business that crashed and burned, the partnership deal that went sour, the product that had to be recalled, we want them to tell all.
Agenda for the evening, as follows:
18:30 – 19:15 Arrive, network, eat and drink!
19:15 – 19:25 Introduction from Emma Gilder, Co-Organiser, Austin Fraser
19:30 – 19:50 Tom Robertshaw, Ecommerce Evangelist, Space 48
“Over the last 10 years, I’ve gone from being a Comp Science student to a developer, to an agency owner, to an ecommerce evangelist. This has given me the opportunity to fuck up in a range of roles and responsibilities! All that practice means I’ve now gotten the hang of how to royally screw up a situation. So whether you want to overwrite production DBs, get removed from client Christmas card lists, or offer two for one hot tubs to all your client’s customers, come and learn from the best in the business.”
19:55 – 20:15 Speaker to be announced shortly…..
20:20 – 21:00 Network and drink some more!
We are the proud sponsors of the London Magento Meetup and co-organisers for the last 6 years. We’re here to listen, advise, and ultimately, to help organisations perform better.
Get your free ticket here: https://www.meetup.com/magento-london/events/254207661/