Speakers & talks

At each of our conferences we bring you practical and insightful talks on the themes of teams, tech and tools: how to develop your team, new and emerging tech, and processes to improve the way you work.

This year's conference for technical leaders in Austin, TX, features talks on scaling tech teams, risk management, microservices, team performance, parental leave, building distributed teams and lots more!

The schedule will be announced closer to the conference. If you're booking travel in the meantime, we expect the conference to start around 9 AM and finish around 5:30 PM.

A-Z speakers

Conference chair

Meri Williams

Conference chair

Meri Williams

About Meri Williams

Meri is a geek, a manager, and a manager of geeks. She’s a CTO and also runs micro-consultancy ChromeRose, helping digital & technical teams be brilliant. An alumna of Procter & Gamble and the Government Digital Service, she has had a career spanning development, project, programme & product management and more recently engineering & operations leadership. She’s led teams ranging in size from 30 to 300, mostly with folks spread across the world.

Bug dives: bridging the gap between engineering and customer success

Annie Cook

Senior Software Engineer

Nylas

Annie Cook

Investing in your customer success team is high leverage. The more knowledgeable your team is, the more effective it can be at investigating, diagnosing and triaging customer issues. The stronger your customer success team is, the less of that diagnostic work falls to engineers and the more time the engineers have for fixing bugs. The more time they have, the more bugs they can fix, and the more bugs they can fix the happier customers will be.

Investing in your customer success team is high leverage. The more knowledgeable your team is, the more effective it can be at investigating, diagnosing and triaging customer issues. The stronger your customer success team is, the less of that diagnostic work falls to engineers and the more time the engineers have for fixing bugs. The more time they have, the more bugs they can fix, and the more bugs they can fix the happier customers will be.

Nothing that i've said is ground breaking — you are probably aware of the ripple effect that stems from the performance of the customer success team. And while you might know you should be actively developing your customer success team, that raises the question of how? How can you use your existing resources to invest in your customer success team?

I’ll share a light-weight process called Bug Dives that our company has adopted in order to increase the sharing of knowledge and debugging strategies between engineering and customer success teams. I'll describe what we have learned after a year of Bug Dives about how to make this process interesting, effective and self-sustaining. This process is sure to get the bug crushing engineer excited to share, and the customer success team eager to learn.

About Annie Cook

Annie is a Senior Software Engineer at Nylas on the product team, working to expand the features of the Nylas API. Outside of work, Annie teaches computer science at an all girls high school. She is passionate about making complicated topics accessible and helping others grow as engineers.

Guide your scaling engineering team with an architecture North Star

Hanjie Ji

Engineering Director

WeWork

Hanjie Ji

In a fast-growing, agile organization, teams are usually encouraged to self-organize. Equipped with the guiding principles such as fast iteration and frequent feedback loop with the customers, we entrust the most valuable asset, people, to make informed decisions.

In a fast-growing, agile organization, teams are usually encouraged to self-organize. Equipped with the guiding principles such as fast iteration and frequent feedback loop with the customers, we entrust the most valuable asset, people, to make informed decisions.

The agile approach may effectively maximize the value output in an individual team but it doesn’t guarantee that your entire organization is collectively building toward the same goal. This is where the architecture north star comes in. The exercise of defining an architecture north star creates alignment in the organization. With this shared direction, your team is able to be autonomous in the day-to-day decision making while building towards the broad vision

You’ll walk away having learned:

  • Why an architecture north
  • The framework to come up with an architecture North Star
  • How it’ll help your team

About Hanjie Ji

Hanjie is an Engineering Director at WeWork, where he grew from an engineer to manager, then to manager of managers in the past 6 years. He oversees an engineering team of 30, focusing on the growth engineering at WeWork.

Growing pains: how to use architecture groups to scale people and technology

Iccha Sethi

Principal Engineer

InVisionApp

Iccha Sethi

This is a joint talk from Iccha Sethi and Jony Jeyaratnam.

InVision started as a small startup several years ago with tens of engineers, small teams working independently as velocity was paramount. But as InVision grew to hundreds of engineers, all fully remote, we realized that this independence was actually slowing us down - teams resolving the same problems, inconsistent metrics, etc.

This is a joint talk from Iccha Sethi and Jony Jeyaratnam.

InVision started as a small startup several years ago with tens of engineers, small teams working independently as velocity was paramount. But as InVision grew to hundreds of engineers, all fully remote, we realized that this independence was actually slowing us down - teams resolving the same problems, inconsistent metrics, etc.

We created the architecture group which was aimed at being a guiding committee for the engineering org to help set standards and best practices, be forward looking for the company, and identifying architecture inefficiencies that spans multiple squads/zones/product areas and drive improvements to it. To simply state it, our mission was to drive architecture alignment across a fully distributed workforce.

This talk will cover the various aspects of setting up the architecture group - from the membership model, and how to measure the success of such a group and prevent it from becoming an ivory tower. It will cover some of the strategies employed by the architecture group like working groups, architecture reviews and architecture projects and also the engagement model with the rest of the company.

This talk will provide details of the group's workings, challenges faced and concrete takeaways so it can help you think about how to address growing pains in your engineering organization.

About Iccha Sethi

Iccha has been in the tech industry for several years and has worked on several challenges ranging from large scale open source projects to micro services and event driven architecture. While working on a team, she is always looking for ways to be a better team and grow as a team. In her free time, which is increasingly less as a new mom, she enjoys reading science fiction/fantasy and cooking new recipes.

Growing pains: how to use architecture groups to scale people and technology

Jony Jeyaratnam

Director of Engineering

InVisionApp

Jony Jeyaratnam

This is a joint talk from Iccha Sethi and Jony Jeyaratnam.

InVision started as a small startup several years ago with tens of engineers, small teams working independently as velocity was paramount. But as InVision grew to hundreds of engineers, all fully remote, we realized that this independence was actually slowing us down - teams resolving the same problems, inconsistent metrics, etc.

This is a joint talk from Iccha Sethi and Jony Jeyaratnam.

InVision started as a small startup several years ago with tens of engineers, small teams working independently as velocity was paramount. But as InVision grew to hundreds of engineers, all fully remote, we realized that this independence was actually slowing us down - teams resolving the same problems, inconsistent metrics, etc.

We created the architecture group which was aimed at being a guiding committee for the engineering org to help set standards and best practices, be forward looking for the company, and identifying architecture inefficiencies that spans multiple squads/zones/product areas and drive improvements to it. To simply state it, our mission was to drive architecture alignment across a fully distributed workforce.

This talk will cover the various aspects of setting up the architecture group - from the membership model, and how to measure the success of such a group and prevent it from becoming an ivory tower. It will cover some of the strategies employed by the architecture group like working groups, architecture reviews and architecture projects and also the engagement model with the rest of the company.

This talk will provide details of the group's workings, challenges faced and concrete takeaways so it can help you think about how to address growing pains in your engineering organization.

About Jony Jeyaratnam

Graduated from University of Waterloo with Software Engineering degree and spend almost 10years at Amazon both as an engineer and manager in 3 different countries (US, Canada and UK) working and building teams in fulfilment logistics and advertising. Lately running multiple engineering teams at InVision on a mission to build the Operating System of Digital Design. Aside from work, I am an avid traveller having visiting over 40 countries foodie and enjoy being out in the nature. Also a proud father of a 9 month old rugrat.

Managing risks together: stop your business shooting itself in the foot

Dr Jonathan Graham

CTO

Transaction Assurance Group

Dr Jonathan Graham

Communicating risks, particularly to our non-technical colleagues, is a challenge and by not doing it well we suffer pushback from the business. The risks are varied and at all different levels, but can include technical debt, skill gaps, team burnout, and more.

Communicating risks, particularly to our non-technical colleagues, is a challenge and by not doing it well we suffer pushback from the business. The risks are varied and at all different levels, but can include technical debt, skill gaps, team burnout, and more.

In this talk we will look at how to clearly, concisely, and consistently communicate and prioritize risks, and how to use this to negotiate plans with the wider business. We’ll look at examples from the team, the department, and the business level, and how to rollup risks through these levels.

Because of the difficulty in communicating risks, there is a risk that you will get pushback on making the changes you know are important, resulting in damage to your team and the business. Mitigation strategy: come along to this talk and get the knowledge you need to start giving risks the priority they deserve.

About Dr Jonathan Graham

Dr. Jonathan Graham is the CTO of Transaction Assurance Group, a company driving transparency and efficiency within the supply chains of wholesalers, buying groups, and retail chains. Some key clients are in the pharmaceutical space, where Jonathan draws on his experience working in drug development for GlaxoSmithKline.

Jonathan continues to support the mission of Mined Minds Foundation, the non-profit he co-founded to bring software development opportunities to communities suffering from economic depression, and has co-founded and run a software development consultancy. He has spoken at international conferences on a range of subjects, including in-depth technical topics, scalability, control of quality, and developing agile teams. You might also have seen him live-coding music on stage, or performing a stand-up set. For the fun of his two giant Newfies, Jonathan is regularly taken for walks along the lakefront and through the beautiful city of Chicago.

Flying Lessons

Rebecca Murphey

Front-End Core Engineer Lead

Indeed

Rebecca Murphey

In October of 2008, I'd been unemployed for about four months. I was doing some consulting work, but still feeling entirely uncertain about my ability to make a living, so I did the obvious thing: I decided it was a good time to learn how to fly a plane.

In October of 2008, I'd been unemployed for about four months. I was doing some consulting work, but still feeling entirely uncertain about my ability to make a living, so I did the obvious thing: I decided it was a good time to learn how to fly a plane.

Over the course of many months, more than a few bad landings, and even a wee bit of engine failure, I learned some stark lessons that have stuck with me even today. Those lessons — about being new at a thing, finding a way forward when you're lost, knowing when it's time to give up and regroup, and so much more — have turned out to be oddly relevant to my journey in engineering management, too.

About Rebecca Murphey

Rebecca Murphey leads the Front-End Core engineering group at Indeed. In her 3.5 years there, she's built a global team that enables Indeed teams around the world to build and experiment on products that help people get jobs. After five years in Austin, she lives in Durham, NC, with her partner, their son, a dog, and a new flock of chickens.

Splitting the monolith

Jimmy Bogard

Chief Architect

Headspring

Jimmy Bogard

After years—even decades—on the existing legacy mainframe, we pitched a plan to migrate a company to a new, microservices-based architecture. Convincing management seemed easy, but now we have to deliver: Take the years-old legacy system and break it apart into smaller services and systems we can actually maintain.

After years—even decades—on the existing legacy mainframe, we pitched a plan to migrate a company to a new, microservices-based architecture. Convincing management seemed easy, but now we have to deliver: Take the years-old legacy system and break it apart into smaller services and systems we can actually maintain.

But where to start? How do we decide what gets migrated first? How do we define our service boundaries? And how do we make sure everyone involved—from users to operations—is on board and excited about the new system when we’ve most certainly moved their cheese?

In this session, we’ll look at strategies to bust apart the monolith, from the front-end to the back. We’ll also review database refactoring techniques that help us keep our risk down. Finally, we’ll explore analysis tools that guide us through the tangled web of dependencies in legacy code so we can deliver robust new systems without breaking the old.

About Jimmy Bogard

Jimmy is Headspring’s Chief Architect, evaluating potential technologies and bringing the most cutting edge to the table. For over 13 years, Jimmy has delivered solutions ranging from products, enterprise e-commerce applications, modernization efforts, and Agile Transformation for Fortune 100 customers, leveraging his vast experience both consult and train clients.

As a renowned technologist and thought leader who understands technology’s power to transform organizations, Jimmy is in high demand at conferences across the world. He is a Microsoft Certified Application Developer (MCAD) and an active member of the .NET community, serving as President of the Austin .NET User Group. He’s led multiple open source projects with millions of downloads, launched book clubs on technology topics, and even wrote the book on pragmatic MVC-based web development, ASP.NET MVC in Action. Jimmy has earned Microsoft’s Most Valuable Professional (MVP) award for ASP.NET every year since 2009.

The four components of high performing teams

Lisa van Gelder

VP, Engineering

Meetup

Lisa van Gelder

Do you have a great team & a great mission but don't understand why the pace of delivery is so slow? Architecture & tech stack is only one part of the story.

Do you have a great team & a great mission but don't understand why the pace of delivery is so slow? Architecture & tech stack is only one part of the story.

I believe high performing teams need four things to be effective:

  • Mastery - The skills & knowledge needed to do a great job, and a clear path to get to the next level.
  • Autonomy - The space to figure out their own solution to a problem & how they want to work
  • Purpose - A clear sense of direction, and the knowledge of how what they’re working on fits into the big picture & helps their team succeed.
  • Safety - A team that is afraid won’t take risks or experiment, a team that is afraid of finger-pointing won’t learn from mistakes.

In this talk I’ll explain why those four things are key to teams being successful and give examples of how I’ve turned teams around by fixing the lack of one or more of them. Attendees will leave with practical examples of how to diagnose & change their teams.

About Lisa van Gelder

Lisa has been in software for almost 20 years, working in a wide range of companies from early stage startups to large media companies like the BBC & the Guardian newspaper. She used to debug code, now she debugs teams for a living. Lisa is currently VP, Engineering at Meetup. She is mostly powered by coffee.

End of loops: an intro to functional programming

Manju Vijayakumar

Full stack engineer

Salesforce

Manju Vijayakumar

Expressions are the most basic form of human interaction! Programming languages are trending more towards using expressions rather than procedural statements, adopting the declarative paradigm.

Expressions are the most basic form of human interaction! Programming languages are trending more towards using expressions rather than procedural statements, adopting the declarative paradigm.

In this talk we will see how we can shift our mindset from procedural programming to functional programming. We will replace loops with lambda expressions and work through fun code examples. At the end of the talk, you will come away awed but not fearful of the reduce function! All code samples will be shared on GitHub. No prior experience in functional programming is necessary.

About Manju Vijayakumar

Manju is a full stack engineer at Salesforce, where she works on Einstein Voice Assistant, bringing the best in class artificial intelligence capabilities to Salesforce CRM. Prior to Salesforce, she worked in a breadth of roles solving complex problems at Google, Goldman Sachs, NVIDIA and Akamai. She holds a Masters in Computer Science from Texas A&M University.

She is a new mama to a baby girl and loves outdoor adventures, reading and blogging in her free time (joke! there is no free time as a new mom).

Returning from long parental leave: what to expect when everything goes right

Matt Newkirk

Senior Engineering Manager

Etsy

Matt Newkirk

As more companies offer longer parental leaves and other leaves of absence, managers and their teams are learning how to handle them successfully. Extended leaves are an amazing benefit and highly valuable to the individual and their company. Preparing for leave comes with its own set of risks and challenges, but many people neglect to prepare for the challenges that arise on returning from leave.

As more companies offer longer parental leaves and other leaves of absence, managers and their teams are learning how to handle them successfully. Extended leaves are an amazing benefit and highly valuable to the individual and their company. Preparing for leave comes with its own set of risks and challenges, but many people neglect to prepare for the challenges that arise on returning from leave.

You will learn how to deal with the concerns you may experience as you re-integrate into your workplace, including:

  •  Am I still good at my job?
  •  If my team succeeded while I was away, do they still need me?
  •  Everything is the same!
  •  Everything is different!
  •  I gave away my Legos, now what?

Leaders will learn how to help their reports return to work effectively and positively. Teammates will learn how to support and empathize with their teammate returning to work. Those who’ve taken such a leave will nod along, knowing that they are not alone. This talk will provide actionable insights into what it’s like to return to work after an extended leave, the challenges one may face, and how to overcome them.

About Matt Newkirk

Matt gets a lot of pleasure from helping people work through their challenges. He currently does that as a senior manager responsible for Localization & Translation at Etsy, on his path of learning to manage managers. Prior to Etsy, Matt worked as an infrastructure and test engineer and as a QA Manager where he caught the leadership bug. He occasionally writes about what he’s learned on his website mattnewkirk.com when he isn’t exhausted from parenting his two awesome children. Matt recently returned from six months of parental leave and is always game to share his journey with you.

The race to Mach 2.0 at scale

Nickolas Means

Senior Engineering Manager

GitHub

Nickolas Means

When Chuck Yeager became the first pilot to fly faster than the speed of sound, he set off a race around the world to do the same with a plane full of paying passengers. The United States, Russia, the UK, and France all wanted a piece of the inevitable fortune to be made building aircraft to cross oceans faster than sound itself.

When Chuck Yeager became the first pilot to fly faster than the speed of sound, he set off a race around the world to do the same with a plane full of paying passengers. The United States, Russia, the UK, and France all wanted a piece of the inevitable fortune to be made building aircraft to cross oceans faster than sound itself.

In the end, though, only one design ever flew passengers in significant numbers, the Anglo-French Concorde. Why? What set the work of British and French engineers apart from competing efforts and allowed them to succeed where other nations failed? Let’s see what we can learn about constraints and compromise from this remarkable story.

About Nickolas Means

Nickolas Means loves nothing more than a story of engineering triumph (except maybe a story of engineering disaster). When he's not stuck in a Wikipedia loop reading about plane crashes, he spends his days as a Senior Engineering Manager at GitHub. He works remotely from Austin, TX, and spends most of his spare time hanging out with his wife and kids, going for a run, or trying to brew the perfect cup of coffee.

How to scale yourself as a first-time leader

Poornima Vijayashanker

Founder

Femgineer

Poornima Vijayashanker

When you're a first-time leader it's hard to transition from being a problem solver to leading a team to solve problems. It's often tempting to step in and solve problems for your team. However, the more often you step-in, you end up stripping your team's autonomy and neglecting your own work. Ultimately, this makes it hard to scale yourself.

When you're a first-time leader it's hard to transition from being a problem solver to leading a team to solve problems. It's often tempting to step in and solve problems for your team. However, the more often you step-in, you end up stripping your team's autonomy and neglecting your own work. Ultimately, this makes it hard to scale yourself.

Instead, you need to learn how to train your teammates, delegate problems to them, trust they'll be able to resolve them, and develop an intuition for knowing when it's appropriate to step in and help solve a problem.

In this talk, Poornima Vijayashanker will be sharing a framework for scaling yourself and building a self-sufficient team.

About Poornima Vijayashanker

For more than a decade, Poornima Vijayashanker has led teams through recruiting, onboarding, retaining technical talent, and going from idea to shipping product to successfully exiting.

She is currently the founder of Femgineer. Previously, Poornima was an entrepreneur-in-residence at 500 Startups, a mentor-in-residence at Techstars, a lecturer at Duke University's Pratt School of Engineering, and the founding engineer at Mint.com from its prototype to acquisition in 2009. She has also authored: How To Transform Your Ideas Into Software Products and co-authored: Present! A Techie's Guide To Public Speaking, given a TEDx talk, and hosts Build a weekly web show.

Poornima holds degrees in Electrical and Computer Engineering and Computer Science from Duke University's Pratt School of Engineering.

Your remote company can hire junior developers, too

Romina Suarez

Software Engineer

Ushahidi

Romina Suarez

You wouldn’t hire a senior developer without giving them any support or possibilities for growth, would you? Of course not!

You wouldn’t hire a senior developer without giving them any support or possibilities for growth, would you? Of course not!

We always try to do our best for the people we hire, and yet, many companies hire seniors and refuse to give them the opportunity to be a mentor to juniors, or at the very least, people significantly more junior than them. What’s worse is that everyone seems to be doing it out of a fear of the junior people failing, of not being able to support them in a remote environment, and not out of a genuine dislike of hiring junior people and letting them grow in the company.

I think we are trying to protect juniors from the difficulties of remote work and in doing so, we are not only limiting the career options of those people new to the industry, but also limiting the pipeline of excellent, empathetic technical leaders in our own companies. I’ll give you this and other good reasons to bring more juniors into your remote organization, with real-world examples of how juniors were critical to my career and the careers of other people I worked with closely over the years.

I will go into other reasons why your remote teams would benefit from having more junior devs, (it’s not just mentoring!), what the common blockers to hire them are, and how to get over those blockers.

About Romina Suarez

Romina Suarez is a Software Developer at Ushahidi where she helps support their main platform and build the next generation of Ushahidi apps. She is passionate about open source software, leadership, and finding better ways to work as a team to deliver value to our users.

My most important meeting of the week: crafting effective 1:1s for distributed teams

Spencer Norman

Director of Engineering

Reaction Commerce

Spencer Norman

Creating relationships with the individual humans on your distributed team is difficult since you rarely get to see them in person! But a team is much less likely to be effective and successful without a foundation of interpersonal relationships and trust. How do you build those when you live zip codes, time zones, countries apart?

Creating relationships with the individual humans on your distributed team is difficult since you rarely get to see them in person! But a team is much less likely to be effective and successful without a foundation of interpersonal relationships and trust. How do you build those when you live zip codes, time zones, countries apart?

1:1 meetings - these are the backbone of a successful team. The constraints present in remote 1:1s can be frustrating, but the right approach can result in some great 1:1 habits.

This talk will give you the tools you need to craft effective 1:1s for your distributed team. You’ll learn some ground rules for remote 1:1s, which details are important to get right and which ones aren’t worth sweating about. We’ll discuss what to talk about during your 1:1s and how to use these meetings to build more trusting and productive relationships with your team.

Done right, 1:1s will be your most important meetings of the week.

About Spencer Norman

Spencer is the Director of Engineering at Reaction Commerce, a distributed-first company building open source commerce software. He leads the product engineering team which is distributed around US, Europe, and Africa. Prior to his role at Reaction Commerce he managed a small engineering team remotely for GetOutfitted, an online rental company built with open source software. Spencer lives in Colorado with his dog Sawyer.

Say yes to the mess: Delivering imperfect software

Stevi Deter

Senior Software Engineer

PSJH Digital Innovation Group

Stevi Deter

We all want to deploy the best software possible to delight our customers and please our product owners. There’s always one more feature, another performance improvement, and code we just wish we wrote better. If we ship imperfect software, we may lose our customer’s trust. But if we never ship, we will never get feedback from actual users to learn what really needs to be improved and what already works fine. Knowing how and when to say yes to shipping imperfect software is a challenge at all levels, especially for new leads.

We all want to deploy the best software possible to delight our customers and please our product owners. There’s always one more feature, another performance improvement, and code we just wish we wrote better. If we ship imperfect software, we may lose our customer’s trust. But if we never ship, we will never get feedback from actual users to learn what really needs to be improved and what already works fine. Knowing how and when to say yes to shipping imperfect software is a challenge at all levels, especially for new leads.

I want to share strategies and tactics I’ve used to get software out the door, in all phases of the development lifecycle. How to work with product owners to arrive at a true minimum viable product. How to work with fellow developers to minimize risk while maximizing productivity. How to negotiate with QA on what are true show stoppers. And how make users our partners throughout the entire process.

It’s possible to ship messy software and feel great about it!

About Stevi Deter

Stevi Deter is a senior software engineer with over 20 years experience. She’s currently with the Digital Innovation Group (DIG) at Providence St. Joseph Health, There she’s technical lead on a team focused on the caregiver experience for on demand virtual and at home health care. Before DIG, she spent over 10 years as a software engineering consultant for clients in a wide range of industries. She has focused on integrating complex systems to provide new tools and experiences to serve customer needs.

On motherhood and leading engineering teams

Tara Feener

Head of Engineering, US

WeTransfer

Tara Feener

Navigating any new personal scenario while leading a team can be extremely challenging, but last summer I found myself nine months pregnant and leading our engineering organization through an acquisition while preparing for the birth of my son. On the day he was born, I got the news that the acquisition had been finalized.

Navigating any new personal scenario while leading a team can be extremely challenging, but last summer I found myself nine months pregnant and leading our engineering organization through an acquisition while preparing for the birth of my son. On the day he was born, I got the news that the acquisition had been finalized.

Transitioning back to work wasn’t just transitioning back to work: I was coming back to a new company, with a new leadership role and with a new set of external pressures that I needed to navigate every day. The experience really taught me a lot of quick lessons around both how we as engineering leaders can prepare ourselves for transitioning into parenthood, but also a lot about how we can coach our teams to support parents and new parents in the workplace.

In this talk, I’ll walk through strategies and techniques that I’ve used to make work work for me in my new world as an engineering lead who also now has to consider the mom side of her brain. I’ll also walk through what we can do to educate and prepare our teams to help create a culture more supportive of new parents, leading up to the parent going on leave, during leave, returning from leave and re-integrating into work-life.

About Tara Feener

Tara Feener is the Head of Engineering for the US at WeTransfer in New York, where she leads distributed engineering teams creating creativity tools: Paper and Paste. Before WeTransfer, Tara worked at FiftyThree and Adobe where she amassed 10+ years of experience in the creative tools space building, shipping and leading teams. Tara is originally from Newfoundland & Labrador, and has since called San Francisco and now Brooklyn home.

Observability that matters

Tom Oketch

Quality Advocate

ThoughtWorks

Tom Oketch

The term observability has recently earned somewhat of a cult status — rapidly ascending to the ranks of “agile”, “digital transformation”, “microservices” and other such highly regarded (and perhaps often misused) labels. Suddenly every team wants to incorporate the pillars of observability into their ecosystem.

The term observability has recently earned somewhat of a cult status — rapidly ascending to the ranks of “agile”, “digital transformation”, “microservices” and other such highly regarded (and perhaps often misused) labels. Suddenly every team wants to incorporate the pillars of observability into their ecosystem.

But observability for observability’s sake has no inherent benefits. What is the goal of being able to dissect your services or trace transactions across multiple service boundaries? How do these newfound principles and practices translate into meaningful actions and outcomes? And how can you make sure you’re not falling into the trap of the bandwagon fallacy?

This talk explores some of the emerging anti patterns around observability, their pitfalls, and how to avoid them. It also explores how teams can focus on achieving the right kind of insight into how their systems are performing and being utilized - observability that matters.

About Tom Oketch

Tom is a senior technologist at ThoughtWorks who routinely works with delivery teams to foster a culture of collaboration, trust and shared ownership of quality. He has a penchant for getting things shipped, as well as bridging the gap that often exists between ops and engineering.

Managing for an inclusive project solution: the intersection between technology, humanity and social responsibility

Yvette Pegues

Chief Transformational Officer

Yvette Pegues

Corporate Culture is an ecosystem and diversity is the air we breathe. As such, how a project/delivery team cultivates its culture impacts the entire project, client relations and end-user experience. Therefore, intersecting architecture with technology, humanity with social responsibility and abilities with assets pivots the solution in the direction of inclusive access to systems, SLA’s and SOP’s with minimal disruption to the fragile ecosystem for which it’s being built.

Corporate Culture is an ecosystem and diversity is the air we breathe. As such, how a project/delivery team cultivates its culture impacts the entire project, client relations and end-user experience. Therefore, intersecting architecture with technology, humanity with social responsibility and abilities with assets pivots the solution in the direction of inclusive access to systems, SLA’s and SOP’s with minimal disruption to the fragile ecosystem for which it’s being built.

This session will demonstrate how strategic advocacy pivots the solution to find a productive way forward for all.

In this session you'll learn to:

  • Be “Hard on the problem, soft on the people” when building an Inclusive Project and/or Development Team
  • Create building blocks for strategic advocacy and harmony on a multi-ability project solution
  • Master necessary skills to leverage team player abilities and assets
  • Leverage full-disclosure for harmony in a harsh environment
  • Avoid zero-sum distractions at the project's expense

About Yvette Pegues

Yvette Pegues is an Ed.D. Candidate, former IBM Networking/Cloud Engineer and Digital Project Manager turned Worldwide Program Delivery Manager, Corporate Disability/Diversity Consultant, sought after International Educational/Inspirational Speaker, Special Populations Trainer, Published Author, Disability Advocate, ADA Advisor and Product/Brand Ambassador. She is most proud of the intersections of her Faith, Family and Philanthropy.

After a life-changing Traumatic Brain/Spinal Cord injury, she successfully aligned adaptive technology with disability, diversity and difference for clients around the world. Today she cultivates and educates corporate clients on how to lean-in to $10 trillion in revenue gaps and opportunities in the growing disability sector. She is a master storyteller, unafraid to leverage tragedies to create trajectory in business and relationship management. Learn more at www.YvettePegues.com

Sponsors

Thank you to our fantastic partners for their support to help the conference possible.

Would you like to connect with community and improve your brand awareness? Contact us for our 2019 sponsorship offers.

Yelp

Platinum Sponsor

uShip

D&I - Live Captioning Sponsor

ShipEngine

Silver Sponsor

Test Double

Silver Sponsor

Automattic

Silver Sponsor

Austin Technology Council

Media Partner

Keep up to date

Sign up to our newsletter to receive news and updates. To find out more about our newsletter content and how the data is handled check out our Data Promise.