As both engineers and managers reach mid-career levels referred to as career or terminal levels e.g.Senior engineer, Senior Manager levels in many technology companies, they are often faced with uncertainty and ambiguity on possible next steps in their career.

This talk offers some strategies to think about careers at this stage. Some questions we will address: How do you think of your career goal outside of the usual career ladders? How do these change as you get more senior? What are traditional vs non-traditional IC and manager paths you can explore? How do you think about the engineer vs manager track? What are some variations on the above for underrepresented groups?

Uma has supported engineers and managers in multiple engineering teams of various sizes through career growth in different environments, from large company environments to startups. If you are someone navigating the mid-career stage or thinking a few steps ahead, this talk is for you.
 

At the early days of Skillz, our web applications fully built using Ruby on Rails, since it is a framework that helps us quickly create and iterate. As our company grew larger, we demanded more and more dynamic functionality, especially on the frontend. Our existing toolset was no longer sustainable. We searched for the right framework to build around, and eventually decided on React, and later implemented TypeScript as well.

This is a talk about the evolution of Skillz web application from Rails to Rails/React to Rails/React/TypeScript, the decisions we made along the way, and some mistakes and learnings.

It's expected for the structure of your teams and organization to change as you grow. This is also true for the processes and communication channels you need in place so that everyone remains highly effective. What works well for a team of ten engineers falls short once you have thirty. You adapt and then feel some friction again when you get to a hundred. Rinse and repeat. At Intercom, we’ve iterated and been through this process a few times having grown engineering from one team of four engineers sitting together in the same room to 160 engineers in 30 teams across three countries and two time-zones.

I’ll share how we’ve been successful at empowering engineers to drive organizational change. Their unique perspective being on the ground allows them to identify, solve and own solutions to the challenges they face.

We’ll go through the journey of how we identified and solved a problem with internal knowledge sharing in Engineering. In doing this we’ll shed some light into the following questions so that you’re better prepared to take on these sort of challenges: Why was it important to iterate? What was unique about it that didn’t apply company-wide? How do you identify when you've outgrown your current setup? How do you set yourself, and the org, up for success? You should be able to take some of the ideas and answers to these and apply them to existing or future problems your teams might face.

You didn't get that cool programming job because you're a great programmer. You got it because the company you work for wants to make money and they think you can help. It's easy for us to feel like our worth/value/capitalist expression is tied to our employment, but it's also useful to flip that narrative and talk about how our companies need us, and how we can use that understanding to be more valuable employees and even better humans.

What is the value that you bring to your employer? Can you articulate it? Can you expand it? Can you take that value and use it for your own purposes?

What can you do today to reinforce your dedication to support the marginalized? I’ll be sharing 10 tiny microallyship patches we can apply to our environment to support our folks, starting right now!

"I'm waiting for the right opportunity.”
"I need to have more experience before I can do that.”
“I don't even know if I'm doing a good job.”
“If I ask for help, people will think less of me.”
“I'm not responsible for that change.”

We all have different limiting beliefs and voices that hold us back from the leader we want to be and the impact we want to have.

We'll identify 5 most common limiting beliefs — and the empowering mindsets that great leaders replace them with. We'll share stories of how these beliefs held us back — especially in leading without authority.

Team velocity is one of the most abused and misunderstood concepts in software development. This talk will demystify team velocity and understand the various antipatterns of velocity through practical examples and how to leverage it to drive positive culture and delivery.

Our current methods for measuring a developer’s career progression are broken. At best, we count the number of days someone’s been paid to write code and massage that into a title. As a result, there’s no consensus as to what a given title means, leading to frustration for everyone.

We’ll discuss focusing on a path centered around autonomy. Walk through the three stages of a developer’s life: The Implementer, who’s just learning the ropes and needs careful attention. The Solver, who tackles ever-bigger problems - and needs the responsibility to match. Finally, the Finder, who will revolutionise how you do work but only if you let them.