So you walk into a new company, get the lay of the land and then realise, crap! Their development processes are like they were design by a bunch of first-year uni students doing a group project.

There is no DevOps to speak of. There are snowflake servers everywhere. Their git branching strategy is unmanageable. They run tests only every 3 or 4 releases. Their deployment is manual and different for each release. The have no real alerting.

Ok. Take a deep breath! Calm down.

So much to do, but where to start? The business has produced a list of improvement actions, but those actions are focussed around fixing the symptoms of the problems, not solving the root cause. The business does not understand that the path to DevOps improvement is complex and each task has many inter-relations and dependencies.

This is the problem that I faced about a year ago. To overcome this, we went through a process of defining all of the DevOps tasks we could think of and mapped them into a dependency diagram. This diagram was useful to communicate both internal and external to the team.

In this case study, I’ll go through the process to design the dependency diagram, but also our progress through the diagram one year later.

This presentation will have a close look at what makes high performing software development teams, as well as what hinders them. It will cover each level of the organisational hierarchy starting at individual software developer, then group of engineers, full cross-functional product-engineering team, wider product-engineering department, and finish at the entire company. At each level, we will see multiple examples of teams to see what factors contribute to high performing software teams, as well as less performant teams.

As organisations have become more agile and try to build “high-performing” teams, they have started to hire for cultural and team fit. As a result they search for people who can collaborate and are team players; who are willing to develop a deep trust in each other and in the team’s purpose; who freely express feelings and ideas; who engage in extensive discussion; who are adaptable and embrace change and who are comfortable managing constructive conflict towards a better outcome.

There are however, many people who do not meet that criteria, and for various reasons, may struggle to meet that criteria in the future.

Everyone brain is wired slightly differently and not everyone’s wiring fits the mould described above.

Does the exclusivity of the above criteria result in certain people missing out who could have significant positive value.

As organisations have become more agile and try to build “high-performing” teams, they have started to hire for cultural and team fit. As a result they search for people who can collaborate and are team players; who are willing to develop a deep trust in each other and in the team’s purpose; who freely express feelings and ideas; who engage in extensive discussion; who are adaptable and embrace change and who are comfortable managing constructive conflict towards a better outcome.

There are however, many people who do not meet that criteria, and for various reasons, may struggle to meet that criteria in the future.

Everyone brain is wired slightly differently and not everyone’s wiring fits the mould described above.

Does the exclusivity of the above criteria result in certain people missing out who could have significant positive value.

This presentation will have a close look at what makes high performing software development teams, as well as what hinders them. It will cover each level of the organisational hierarchy starting at individual software developer, then group of engineers, full cross-functional product-engineering team, wider product-engineering department, and finish at the entire company. At each level, we will see multiple examples of teams to see what factors contribute to high performing software teams, as well as less performant teams

Big Data. It's complicated, right?

For the past 18 months or so, we've been developing a Big Data system that is used in production as part of our user facing application. I assumed this was the standard thing to do with Big Data and that there wouldn't really be much of a difference between using Big Data in user-facing production compared to using it for Data Science and Machine Learning.

As time passed I interviewed people for roles in our team, and talked to other teams, I found that the types of things that we were doing seemed to be different from what most other people were doing.

It may sound obvious, but it took me a while to work out that Big Data for Data Science requires different techniques to Big Data for user-facing products.

In this talk, I'll walk through what we're currently doing to solve our transformation problems, and explore some of the differences between user-facing and Data Science. I'll present some of the lessons we've learnt, the tech we've played with and invite you to help with some of the problems we continue to face.