YOW! CTO Conference 2018— the abridged version

YOW! is a technology conference held across Australia each year. Speakers from around the world (including Australia) give short talks about their experiences with technology. These are the highlights from the Melbourne event held in December...

Working at Netflix — Brendan Gregg (Netflix)

“A culture worth sharing” jobs.netflix.com/culture

• Engineers discussed whether to use CentOS or Ubuntu, but within the context of “what’s best for the company” (rather than what’s best for themselves). Conversation remained professional throughout the meeting.
• If there’s something bad about Netflix, people are empowered to fix it. Fault tolerant — both in technology and in culture (willingness to try things, curious).
• Netflix uses 360 degree feedback surveys to measure whether people are living the values. It is not anonymous. Helps each other to improve.

Leveraging Platforms to Achieve Speed at Scale — Tomas Varsavsky (REA Group)

• Problem: Teams have autonomy to make decisions. But there are consequences to autonomy — fragmentation. So the challenge is how to find and encourage commonality across all teams. Solution is to build a platform which provides solutions to the common problems. Autonomy vs Leverage — need to take away some autonomy to get benefits of common platforms.
• “Platform” = “Product”. Think about building platforms as though you were building a product.

The most successful tools/platforms:

• Solve a real constant problem
• Strong vision for what tool should (and should not) do
• Ongoing investment
• Great user support
• Good documentation
• Classroom style trying
• Easy upgrade
• Open to feedback and contributions
• Needs a brand
• Contains a bunch of products
• Brand stands for something (checklist)

If you apply product thinking to building platforms, it helps you understand what is required to make it successful, like any other product.

Grads are Your Future — Michelle Gleeson (Seek)

• Being senior-heavy in an organisation means there are less opportunities to lead people. Hiring junior people is cheaper and allows you to shape them to fit your company’s culture.
• Seek eventually settled on a score card: Passion, Social responsibility, work experience in tech, work experience in other industries.
• “We don’t use a quota system”, but instead select the top 10 candidates from each desirable group (e.g. 10 women, 10 men), and then run them through “Assessment Day”.
• Assessment Day consists of meet & greet, group activity, pair programming, individual interviews, site tour, then an assessors session to select the final 10 (no quota at this stage).
• After that, they go to Bootcamp to learn how to be successful in a dev team. 4 week exercise and full time mentor. Focused on a real problem, end to end. Then 18 month Grad program with 2-or-3 x 6 month rotation. Assigned a mentor too.

How to survive and thrive in an Enterprise Agile Transformation — Sean Langton (Bank West)

Bank West introduced the Halo payment-ring (a wearable credit card).

• Multi-disciplinary teams with customer experience research at the center, Autonomous, tribes
• Single operating rhythm (cadence) across the bank helps everyone do the same thing, not adding requirements that derail projects
• Manifesto for Half Arsed Agile Software Development (Enterprise Agile != Agile Software Dev). Need to do SDLC training for business teams.
• Agile can become a cult (following practices without knowing why). Need to champion “common sense” as a principle.
• Shining a light (on a problem/process) is the best disinfectant (way to improve it). Being transparent allows you to get help, find solutions, make changes.
• Ceremonies are superficial, but they may reveal disfunction within teams/projects.
• Effective governance is now mission critical — lean architecture process (record decisions in a log), make committees open (so people can see what goes on).

Scaling mobile app development at REA — Stewart Gleadow / Prasanna Gopalakrishnan (REA)

• Started off with a single mobile team, one app. Now there are lots of product teams wanting to get their features into the mobile app. How to get multiple teams to contribute to a single code base?
• “Federated Delivery” — best way is for team A to provide services to teams that consume them. How to do that in mobile?
• Setup a component development model, which allows different teams to work on different components, and the app assembles those components together. (Pretty much what web teams have been doing for the last few years).

Scaling Birchbox: Lessons Learned — Liz Crawford (Birchbox)

• Personalisation — being attentive to what a customer is doing on the site. Don’t need fancy AI for this.
• Communicate on the customer’s schedule, not the marketer’s schedule.
• Need to have a single view of the customer
• Hiring fast & well is hard, and don’t stop hiring if you are growing.
• Cultural artefacts and traditions act as glue for the team.

Manufacturing High Performance — Casey Rosenthal (formerly Netflix)

• “High performance team” — is not necessarily a team with the most skills. Team performance can be changed. Engagement is one factor, but there’s also other factors.
• Most teams starting up optimise for either performance, availability or fault tolerance. Good teams can optimise for 2 or more. Netflix added “feature velocity” as a target. Netflix moved to a micro-service architecture to optimise for feature velocity.
• There tends to be a separation between architects (the people designing the software) and the engineers (the people who write it). This is nuts. This is bureaucracy.
• At Netflix, there is no chief architect. Chaos monkey is a tool that randomly turns off a service everyday. This forces the engineers to solve the problem, without anyone telling them to do it. They get to see how close to the “safety boundary” they are. Chaos engineering gives a signal for safety margin. See https://principlesofchaos.org/
• There’s no right way to write software. Instead, it’s about what are you optimising for when writing software. Don’t try to optimise for simplicity, as some things are irreducibly complex. Embrace complexity and navigate it.
• High alignment: having teams aligned to department, CTO, CEO.
• Economic Pillars of Complexity: states, relationships, environment, reversibility. Serverless, containers, canaries — make it really easy to put things into production and reverse their decision if necessary.
• KMO: Kitchen Model of Organisation. A HPT works like cooks in a kitchen — everyone is busy and in the end the meals are served. Cooks don’t micro-managing each other. Instead, each cook knows what they are doing and why.
• Efficient systems are brittle systems. Tolerate inefficiencies.
• CTO & leaders are responsible for attracting diverse talent. “Having a diverse team is a sign of good leadership.”

‘Leadership’ to ‘First Time Parent’ to ‘Working Parent’…….lets make this better! — Tanya Windscheffel

• Pre-pregnancy: Anxiety, Financial planning, Miscarriage, IVF is common & emotionally draining, Adoption. Solutions: buddy program (to talk about these things), buy extra annual leave, talk about your journey.
• Pregnancy: Working outside of office may be necessary during pregnancy, unconscious bias training, acknowledge that women fear losing their job once they leave.
• Maternity leave: do salary review before they go on leave, set expectations on return, increased training & education. Could the company offer a baby sitter so that women could attend company events?
• Coming back: it’s really hard. Meetup culture — maybe have some during the day, to make it more accessible.

Moving from a monolith to a distributed monolith (a cautionary tale)— Nish Mahanty (iR Exchange)

• Microservices are quite seductive in terms of what they offer you, and abstracting away certain problems. The reality is, they are complex things.
• Build your core intellectual property. For everything else, Borrow > Rent > Buy > Build.

Great talk about the journey from a monolith to a monolith-in-the-cloud.

Lessons from a security incident — Tal Rotbart (PageUp)

PageUp got hacked. But they detected it and stopped it before damage was done.

• Being hacked is a matter of when, not if. Accept this.
• GDPR regulations meant that company had just 72 hours to disclose breach
• Challenge: how to maintain security while constantly changing? Defence in layers.
• After the hack: people were stressed, fearful. Needed to rotate people who were in high-stress roles so that they did not break.
• Having a security incident response plan is really important. Have clearly defined roles & responsibilities so that people know what to do without delay.
• Join the Joint Cyber Security Centres | CERT Australia

Code Review is the Manager’s Job — John Barton

• The title says it all. Managers should engage with the pull request process
• References to lots of books. Andy Grove from Intel wrote a book about managing engineers.
• Culture is the behaviour that you reward and punish with. If you don’t manage it directly, the culture will emerge anyway. So you might as well address it.
• It may be better not to comment on a PR directly, but to sit down with a team member and go through your feedback together. Or to note it down in a markdown file, so that it could be discussed at retro or one-on-one.

Supporting Constant Change — Neal Ford (ThoughtWorks)

• Most Agile Dev books talk about business-driven change, rather than technology-driven change. What if we built architecture that was designed to support constant change?
• “Software reuse is more like an organ transplant than snapping together Lego blocks” — John Cook.
• “The more reusable something is, the less usable it is”. Reuse is a trade-off of some other property (e.g. flexibility, simplicity).
• Micro-services have bounded contexts, which allow many services to have the concept of “Customer”, but they don’t need to share the same representation of a “Customer”. In this world, duplication is the trade-off for simplicity. Similar is the idea of adding “side cars” (containing logging, network circuit breakers + other common stuff) to a business service: you are sharing the things that are truly common, but separating the things that are truly different.
• “The last 10% trap” — how to build the last 10% of requirements? This is the problem with 4GLs — it was really hard to implement the last 10% within the framework. Every ERP package suffers from this too. Maybe Serverless is in this category.
• Architectural governance needs to be automated (from book “Evolutionary Architecture” by N. Ford). Idea of writing tests that test design of system (e.g. www.archunit.org).