Agenda

Technology has become the force multiplier in achieving growth. Businesses are scaling up their investment in technology and engineering to unlock growth. As Engineering Organizations grow, they reach a tipping point at which mastering the scale of everything itself becomes a challenge. So, how should an Engineering Organization grow itself to not become a hurdle but stay a propeller in achieving growth ambitions for its business? Let's dissect together what makes a scalable engineering organization. In this talk, we will cover the dimensions of scale in an Engineering Organization and how to lead through it to create success.

I would like to take everyone through a journey of moving a team, and then helping influence a company, to a more remote supportive culture. This includes successes, failures, learnings and areas that we will continue to grow. I'll go through the tools we've used, and how those themselves have supported (and not) this way of working. There will be examples of some of the meetings we have reduced, the fundamental ways the teams have changed how they work, and how they truly support each other. I'll talk through the reasons why I feel asynchronous (and sometimes synchronous) working is so beneficial, and how the culture of the team helped inspire other teams, and how you might be able to use what we have learnt, and the values we are building on, to create a truly flexible, work from anywhere environment.

Development and security silos in organizations are making it harder for us to build secure products and boy, do we need them. High-profile security breaches are the norm nowadays. If you’re a developer interested in building security into your products’ DNA, you’d have probably already noticed how hard it can be to get those efforts into your product’s roadmap and day-to-day tasks.

This session will show you three proven steps that you can apply in your own teams to not only build from scratch but also grow a DevSec culture in your tech organization. Through a real-life story and a series of (possibly frightening) anecdotes, you’ll learn about practices and tools that’ll also help you embed security in your own applications.

It is assumed you have some knowledge of web programming, basic security concepts, a thirst to challenge the status quo, and a sense of humor.

Becoming a manager is one of the hardest shifts in any individual contributor’s career. As IC, most of the time you write code: functions, classes, APIs that accept a set of inputs and return an output. As a result of the predictability that comes with writing code, you can write test cases with confidence that they will continue to work as planned. But as an engineering manager, you deal more with people topics which are not that predictable. You can’t push a change and instantly go to look at logs to see the impact of the change and revert when necessary. Even worse! Managers of several teams don’t have the luxury of a short feedback loop. Feedback from change may come in days, weeks, or months to managers– long enough to have a consequential impact on the team, delivery, culture, and more. The further you go up from the software team, the more you’re removed from the team’s day-to-day challenges, activities, and flow. But to steer your teams in the right direction, guard culture, and improve team health and engagement, you need visibility (observability). You need to be able to infer the state of your teams from the outside and be able to understand the state of things by looking at data.

The holy grail of leading with visibility is to be able to answer yes to all of the questions below:

1. Can you understand how stuff is being built?
2. Can you understand how stuff gets built on time and within budget?
3. Can you understand if the stuff built will continue to run?
4. Are the people building the stuff engaged and happy to take part in building the stuff being built?
5. Are your users getting value and satisfaction from what is being built?

In this talk, we’ll ground discussion on obtaining and measuring data that matters to give you visibility into your teams whilst drawing on my experience at TIER.

Making technology decisions on well-documented and stable systems can already be challenging, but how about opaque ones - when we deal with a black box? As technology leaders, we almost always operate within constraints - but a lack of general understanding of a system is perhaps the most challenging (especially under time pressure and if the system in question is mission-critical, such as payments). In this talk, I'll go through common black box scenarios and provide advice on how to deal with them:

- Legacy software: When we inherit software written by other people, we rely solely on adequate documentation, which is unfortunately rare.
- Senior engineering talent leaving: Even if they wrote good documentation, understanding complex systems takes time.
- Poorly written systems.

Of course, we can understand any black box if unlimited time is available, but that's seldom the case. Yet, there are several things that we can do:

- Measure outputs and inputs: While the systems can be opaque, what goes into and out of them is not. Analyzing those points can yield valuable insights into the system's inner workings.
- Adopt a scientific approach: Conduct experiments, test hypotheses, and document the results. Observe the behavior of the system patiently over time.
- Set up feedback loops: While running the system, prod it and observe any changes in behavior and performance. Isolate subsystems: Break down the black box into separate components and measure their inputs and outputs instead of the system as a whole.
- Replicate: Replace different components piece by piece, culminating in a complete copy.

Those solutions will help engineering leaders guide their teams around the frustrations and dangers of working with black box systems.

What picture and ideas come to your head when you hear the word “Leader”? For many years what I imagined was a man, but not just any man, I would think of a confident one, charismatic, talkative, and outgoing. In summary, an extroverted person.

For all those years that idea that I had formed in my head hindered my capacity to recognize different types of leadership and to even think about the possibility that I could be one.

There are many materials and perspectives about leadership and yet I’m here with one more. In this talk, I will share my personal journey in reframing what leadership meant to me as an Introverted person and why, contrary to what I initially believed, some of the characteristics of introversion actually helped me in the path of becoming a Lead Developer during my time at Detroit Labs.

Furthermore, in this talk, I will share some of the questions and the conclusions I arrived at during this discovery journey such as:
What is leadership to begin with?
What does it mean to be introverted?
How can I use my characteristics as an Introvert to be a good leader?

In summary, this is the story of leadership discovery from the perspective of an introverted woman of color, and for that reason, many parts of this talk will also touch on the intersections between introversion, culture, and gender.

Debugging, in its various forms, has been around for as long as people have been developing code. It is a critical step in the creation and maintenance of code. No matter what it is that you are developing, you will undoubtedly have an array of issues, and debugging enables you to get to the bottom of these; to find the bug and to then find a fix for it.

But debugging, as we know it, is broken. It takes time, it is always a struggle to get the exact data you want, and worst of all, you are often called to debug at the most inconvenient times.

In this talk, we will delve into the reasons why debugging techniques are broken. Why a method that was developed last century is no longer relevant (or useful) to our ever evolving technology stacks of today, and what advances have been made in the space to ensure that everyone can use the right tools for the right use case. We will delve into the finer details of how tools empower teams to take real ownership and how, by addressing the biggest pain points associated with traditional debugging techniques, we can rebrand it to a task that developers would want to take on.

We have collectively internalized the idea that being on call is a distasteful burden, a necessary evil at best. What if I told you that:

* on call could be 100% voluntary?
* being on call could be a sign of prestige?
* you could look forward to your turn on call, when you get to take a break from the roadmap and fix all the shit that has been personally bugging you?
* being on call can be a great time to unleash your curiosity, learn new skills, and develop/refine your technical judgment?
* an on call rotation, properly run, can heighten the stakes, build your empathy towards your users, and strengthen the bonds between you and your teammates?

On call doesn't have to be something you are forced to endure... we can do better than that. It might even become your favorite week of the month

Have you ever found yourself stuck waiting 6 months for API to support a feature which needs to be ready in two weeks? Maybe spent weeks trying to figure out how to make a feature work while dealing with multiple versions of legacy code? Struggled to explain to a designer why a tooltip will take two weeks to develop?

Different groups and professions value different traits and operate under different cultural assumptions, which are often unconscious. Different attitudes towards deadlines, decision making, attention to detail etc. may cause conflicts and misalignment, causing major setbacks in delivering quality results fast.
Software engineers are located in the midst of these forces pulling in many different directions. We can leverage an understanding of why and how our attitudes differ to create alignment and bring everyone on board to achieve our common goals.

You don’t need “manager” in your title to lead engineering teams. More and more, companies are investing in senior individual contributor tracks to support engineers as they grow.

But once you get that senior role, how you work changes in many ways:
* You are working across multiple teams, so your goals are not a team’s goals anymore. How do you know what they are?
* You’re not “on the ground” working day-to-day within a team. How do you keep track of what’s going on?
* Coding is just one of the ways you deliver value. What else should you be doing?

Your role now is to gather context and evaluate opportunities to help shape what you and other teams should focus on.

In this talk, you’ll learn how to define your development journey as a senior individual contributor, figuring out what you should be working on, how to set your goals, and how to you define your backlog of work. You’ll also learn how to track your progress so you can keep growing as an engineering leader in the individual contributor track.

We talk a lot about imposter syndrome lately, especially in minorities in tech communities, and especially regarding developers who pivoted in their career. But imposter syndrome can strike anyone, no matter their background or actual skills. In fact, it has little to do with objective abilities: you can be a Microsoft MVP and still be crippled with self-doubt. I won’t cheer you back up with “be confident!” and other pep talk, but I will give you strategies to put in place to gain more self confidence. If you’ve ever had a little voice telling you “no, let it go, the others know more” or “you won’t be able to do that, don’t even try”, this talk is for you. By the end, you will be armed with tools to shut that voice, and replace it with positive action. I won’t cure your imposter syndrome, but if you put in the effort, it will be a world of difference!

Green Software Engineering isn't limited to delivering a product with an environmentally sustainable purpose. The goal is to create reliable software that meets the needs of user requirements while reducing ecological impacts. This implies writing clean code and maintainable code that can last if it needs to. The hosting infrastructure has to be selected with sustainability and performance in mind. And when it comes to data, the implications are quite huge. The phrase "data is the new oil" does not only have to be evaluated from a "value perspective" but also from an environmental one: Studies show that up to 7 kWh per Gigabyte are needed to store data. In this talk, we will go into detail about the planning of infrastructure and systems in both backend and frontend to reduce the environmental impact.

Leading a software team is a great challenge. It’s a group composed of highly skilled people with different profiles and aspirations who somehow still need to achieve a single objective. So how does one succeed at this task?

Besides being a naturally complex challenge, it is hard to understand where to focus on. Between the people, the project, and the technology, there is definitely enough to keep someone busy.

This presentation will cut through the noise and bring a practical perspective to it. It will use systems thinking to present a holistic approach to leading a successful team. 
Success is defined by:
- The team is efficient at delivering working software and achieving business goals.
- People working in it are fulfilled and growing in their careers.

It will center its contents on all the systems within and around a software team and analyze them in the three areas it needs to succeed: Product, Engineering, and People. It will look at the leader’s role and give insights and techniques on where they should aim their attention to succeed. 

Transitioning from an engineering manager to a manager of managers can be a confusing, challenging yet rewarding time. You get to help grow engineering leaders while being responsible for the success of multiple teams or even an entire department, no pressure! You have a new set of peers and high stakes stakeholders. How does your experience as an engineering manager apply to this role? What new skills will help you succeed?



Having been through the highs and lows of such a transition myself, in this talk I will share tips on navigating power dynamics, recovering from mistakes at this level and more. You will leave this talk with an increased understanding of what managing managers entails and tools to help you navigate such a transition successfully.

You may have heard your boss say it: "You need to be more strategic!". Maybe it came up in your latest performance review. Or you just want to work more strategically in order to fill all parts of your role as a leader. Or maybe your team/organisation needs more strategic support to help them succeed.

But what does it actually mean to really think and act strategically? What actions can you take to lead more strategically every day? And what skills can you develop that help your ability to think and act strategically?

In this talk, we'll cover these questions to help you become more strategic. With the additional help of examples from engineering leaders, you'll walk away with practical tips that you can start implementing tomorrow to help you become a more strategic leader and, consequently, more effective and successful in your role.

Data collection done by people is a wasteful act and could result in duplicated work by different people.
Gathering info for tasks, or for the ability to maintain code or infrastructure - Documentation plays a crucial part in that.

In this talk, I’ll show you a structured way to write a technical doc, without being a technical writer - So everyone could do it to their best ability. I’ll explain why you should care about these docs, and how eventually it serves your best interests (Yes, more than 1).
If you want to save your time and other people’s time - Writing documentation well could have a great impact on that.

Open source software is the de facto standard for many new applications, this is especially true in the database industry. Currently, MySQL, PostgreSQL, MariaDB, MongoDB, Elastic, and others have shown up in every industry and organization in the world in some form or another. People are no longer choosing a single database for the company, they are letting developers and architects choose the best database for the job.

This has led to an increase in the number of technologies operations teams have to support. Couple that increases in technologies with a growing micro-service ( or cloud-native ) development paradigm where every service has its own database and where all the data is valuable.

Now companies are now faced with dozens of technologies, hundreds or even thousands of individual database instances, and petabytes of data. The management of the complexity of such an environment is changing the way we look at systems and operations.

Let’s talk about the trends and tell you what you need to know about how to manage the new multi-verse of data.

This is an unapologetically radical talk about empowering individuals, teams and communities - starting with blue sky idealism, and ending on practical steps for engineering leaders.

I’ve spent the past few years focused on building tech pathways, opportunities and training for underserved communities, such as refugee, female and Black talent.

It works: they get hired by companies like Starling Bank, KPMG and Beamery.

But there’s an enormous structural issue which is still pervasive - and it’s storing up a huge problem for the future of the whole tech industry.

In this talk, I will share insights, data and tips from my experiences in tech talent development within underserved communities - including an industry-wide call-to-arms alongside practical small steps for individual engineering leaders.

As leaders at one point or another we are faced with a challenging situation and we need to improvise and lead our teams through the turbulence. During these times are when the team is tested and it is up to the leaders to make their teams resilient and motivate them against all odds. My talk aims to speak to leaders in the industry and appeal to them to be calm, empathetic and empower their teams during these times by sharing some key points from my own experiences.

This could be in different flavors ranging at different levels, project level, team level, department level or company level. Some of the scenarios might include the below:
1. Team is against a monstrous deadline and feels unable to meet it
2. Company going through financial turmoil

Some key points I would like to share as part of the talk:
1. People First - Putting people first, listening to them and understanding their concerns
2. Motivation - Finding ways to motivate people, this largely depends on the team but it could be the smallest gestures that make a difference, such as sponsored meals during crunch time.
3. Being Flexible - As a leader, being flexible to change and adapt to the changing situation, such as removing meetings or processes.
4. Clear Goals - Making sure that the team is aware of what is expected and when.
5. Remove Blockers - Empowering the teams to unblock themselves and/or helping unblock wherever they need the help.

I want to call upon all the leaders to keep some of these in mind in face of all odds.

In the world of Learning and Development (L&D), we hear much talk of ‘learning pathways’. Learning pathways are essentially curated routes toward a predetermined end state, often consisting of a series of bitesize modules or short courses that allow learners progress through a curriculum at their own pace. Learning Pathways can be really helpful when the direction is known and unlikely to change (remind you of anything? A certain process methodology perhaps?)
But life doesn’t always lend itself to set trajectories, as any agile practitioner will tell you. Often we’ll find ourselves seeking to develop and grow in multiple different dimensions at once, or our priorities will change suddenly, in which case it can be hard to choose and commit to a single learning pathway. At Armakuni we’re trying a different approach to developing our engineers, one that is grounded in the philosophies of continuous improvement and experiential learning. Not only does this approach deliver real value more quickly, but it also makes Continuous Learning an integral part of our culture.
In this talk I will explain the rationale behind our approach to L&D and show you how it is operated in practice. I’ll also explain how we intend to scale our approach as the company grows.

A platform is defined as the collection of tools and infrastructure, on top of which you can use and scale software. Over the last decade due to the increasing number of technology-driven startups and the shift towards cloud-based delivery models, platforms became mainstream and still information is scattered and ambiguous when it comes to describing team topologies and organizational patterns for platform teams in tech-driven startups. Companies are now focusing more than ever on building platform teams in order to increase productivity, promote software development standards, and reduce costs. But when is the right time to build this team? How does this team interact with product development teams?
How is platform engineering interacting with product management?
 

In this presentation we will start by discussing when is the right time to build a platform team. We’ll then explore what is the team and organizational structure to support this team and what type of engineers do you need. The presentation will then go over the important aspect of platform communication and interaction with product teams, and how you can avoid conflicts and competing priorities. Finally, we’ll see how alternative practices - like Innersourcing, can accelerate your platform journey and adoption.

In March 2020, Shopify became a fully remote company. Since then, we have also expanded rapidly, with a core focus on Europe. We've had to significantly adapt a predominantly Canadian, co-located public technology company into one that has its headquarters on the Internet. This talk presents our remote working toolbox, which is our collection of learnings, best practices and ideas for other leaders that are wishing to work and attract talent globally, but must fundamentally shift their culture to do so.

Feature flags are gaining a lot of traction and many of us are familiar with using them to roll out new features. However, there's a lot more that they can do. In this talk, I will very briefly revisit some of their standard use-cases. Then we'll talk through a number of the more creative use-cases that we've used them to solve. Come learn how you can leverage feature flags to help remove dead code, test the parity of new code, evaluate the cost of a new technology, and more.

Many software development organizations hire junior developers and train them to develop, using senior and lead developers as mentors. Thus, the developer simultaneously learns the tech stack, how to program, and how to work on a team of developers. In contrast, Rolls-Royce has many self-taught developers, many of whom are highly-educated experts in various fields, such as finance, aerodynamics, or structural dynamics. They have often worked on projects of various sizes as solo developers. They rarely need significant education or mentoring on their programming language or how to think as a programmer. However, they usually need significant coaching in the tools and practices of working on a software development team. Topics such as building a system on a different machine than it will be deployed on, using version control as a team, communication, pull requests, compromising on programming style and architecture with others, etc., are generally where they need help. Many of them are excellent programmers in some ways while having some best-practice blind spots. They are a heterogeneous group who need personalized coaching and mentoring.

This talk will outline the characteristics of subject-matter experts who have worked as solo developers for some time, and the challenges we have repeatedly seen when integrating them into software development teams. I will present some best practices for ensuring that this integration is successful and results in a cohesive, high-performing team that delivers value and helps the newer and older members of the team fulfil their high potential. These include respecting the expertise of the new team member, treating teamwork and communication as disciplines as valuable as technical ones, and choosing pair-programming partners and tasks with team-integration goals in mind.

When you really need to scale your application, adopting a distributed architecture can help you support high traffic levels. The problem is: how should you do that? When can we call a system as "distributed"?
 

In this talk, we will look at many easy examples of how a distributed architecture could virtually scale infinitely, always explaining this... like I'm five!

Any development project lasting for more than a year will inevitably need at least a few major refactors or even a complete rearchitecture to keep a good development velocity sustainable. Those major changes are a joyous opportunity to introduce newer frameworks, coding patterns, and general architecture improvements. But, they can take a hefty amount of time without any positive results to show immediately. This talk will walk you through the best -and worst- practices I've seen over the years from both successful and unsuccessful efforts.

On the happy side, we'll cover:
* Effective knowledge sharing strategies for developers across the experience spectrum
* Personal strategies for building excitement and team buy-in
* Patterns for introducing new patterns quickly without overhauling the entire project

On the unhappy side, we'll cover what happens when those break down:
* Isolated knowledge and going against framework best practices
* Losing team trust in yourself -- or even the values of refactors
* Losing stakeholder trust in the value of refactors -- or even the product

Eventually, as a manager, you will be expected to manage projects in addition to people. If you’re anything like me, I felt like I was left to figure this out on my own, mostly repeating what I had observed and picking up things from others along the way.

This is a collection of things I wish I had known when starting out and that help keep this a part-time job.

Tips
- Estimates: Effort vs. Duration = Who means what by “estimate” and how to translate effectively.
- Delivery: Cost vs. Commitment = When dealing with time, clarify the difference between the “cost” vs. a commitment
- Constraints: Scope vs. Time = Which is more important: a fixed date or a fixed scope? It’s hard to do both, so choose one.
- Right Size Fidelity = Not all phases of a project require the same fidelity; beware false accuracy.
- Plans vs. Planning = The plan will always change, planning can keep us on track.

Tools
- The Goal = OKRs, KPI, whatever, start with the goal to avoid losing the forest for the trees.
- Single Source of Truth = Choose one, socialize it, avoid death by a thousand cuts.
- Regular project reviews = Boring, but ad hoc meetings can cause anxiety (albeit may be necessary).
- (diet) Critical Path Analysis = Find, monitor, and unblock your bottleneck to accelerate delivery.
- Pre-plan celebrations = Easy to forget to celebrate the wins, make it part of the plan.

In the end, we want to help our customers and project management is a means to an end. Hopefully these tips and tools will help you be more effective, while keeping it a part time job.

Scrum, Agile, JIRA, story points, velocity, git statistics, code reviews, DORA metrics... what if we just started over? What do some of the most productive engineering teams look like, and what tools do they use to know they are productive? Just as important, what are things that they don't use and why? In this session, we'll walk through a survey on how various engineering teams work, and what approaches they have found productive. You'll walk away with insights to what developer productivity means, and approaches and tools that you can experiment with.