A Tale of the Flip Floppers. From Engineer to Manager and Back Again

Rate this content
Bookmark
Slides

I've flip flopped between engineer and manager three times already. I'm quite aware that this is not an unusual thing to do. There's a heap of flip floppers out there! At Atlassian I'm in a new managers group. Interestingly there are many managers in the group that have previously been managers but joined Atlassian as an engineer.
So what's wrong with us? Why do we keep changing our role? Is it boredom? Are we crazy? I think there's actually method to the madness. Each time we make a change it's intentional and there's a purpose, and whilst some say it can hurt your career, I'd like to take you on a journey to explore why flip floppers are a very valuable breed!

7 min
12 Dec, 2023

Video Summary and Transcription

This talk explores the experience of flip-flopping between being an engineer and a manager in the software development field. It emphasizes the importance of maintaining hands-on technical skills for effective engineering management. The talk also highlights the value of managers having recent technical experience and the importance of leadership from both managers and senior engineers. Overall, the talk encourages those considering a transition to management to go for it and emphasizes the unique role of an engineering manager.

Available in Español

1. Flip-Flopping Between Engineer and Manager

Short description:

Hey, I'm Matt Coleman, an engineering manager at Atlassian, excited to talk about flip-flopping between engineer and manager. It's a good career move. Started as a developer, became a manager, learned React, missed being a manager, became a manager again. This talk is for flip-floppers, those considering management, and managers who miss coding.

Hey, I'm Matt Coleman. I'm an engineering manager at Atlassian. And I'm so excited to be here today at React Day Berlin to talk to you about flip-flopping back and forth between engineer and manager. Now, that's something I've done many times in my career. I've probably got a few more in me to be honest. But I'm not crazy. You know, this is something that people actually do. And I want to talk to you about how it's actually a really good career move.

So, let's have a look at my career. This is it, in a picture. I started at Blake as a And about two or three years later, I got offered a promotion into management. And so there I was running about four developers and that turned into 10. A really great job. I loved it. But I started to miss the code a little bit. And I was very interested in React. So, I went over here at Play Up, and I learned React. And then a few years later, I kind of missed having the impact that a manager has. So, I moved to domain as a manager. Then over to Atlassian as a dev, where again, I learned some new technologies, GraphQL, Relay, a bunch of other different things that I didn't know about. And then once again, I got offered a role as a manager. This time it was a sideways move at Atlassian. And at Atlassian, the sideways move is quite encouraged. So, there's a lot of flip-floppers at Atlassian.

Now, who is this talk for? Well, it's for the flip-floppers, of course. And also, you know, if you're thinking, I might be a good manager, I'm not sure. Then this talks for you. Or maybe you are already a manager and you kind of miss being a dev. You miss the code. So, this talk's for you.

2. Dog Lovers and the Role of an Engineering Manager

Short description:

Dog lovers, this talk's for you. The best frontline eng managers are never more than two to three years removed from hands-on work. The best individual contributors are the ones who have done time in management. If you're managing people and writing code, you're doing a poor job at both. If you're managing three devs, then you probably should be writing code. If you're managing eight devs, your velocity is no longer significant. There are still reasons you might write code as a manager. Becoming an engineering manager is a completely different role.

Dog lovers, this talk's for you. I mean, this talk's got something for everyone.

Now actually, the second time I did a flip-flop, a friend of mine said, oh, have you seen the engineer manager pendulum blog post by Mipsy Tipsy? And I hadn't, but I checked it out. It's a two-minute read and it's fantastic. I mean, it really resonated with me when I read this blog. And there are some great quotes here. Let me read one out for you. The best frontline eng managers in the world are the ones that are never more than two to three years removed from hands-on work. Full-time, down in the trenches. The best individual contributors are the ones who have done time in management. I couldn't agree more, go and check it out. It's a great blog.

All right, things that people tweet. It is still called Twitter, and it is still called a tweet. So if you're managing people and writing code, then you're doing a poor job at both. Have you ever heard this one before? Look, it's a great tweet, but Twitter lacks a lot of context. So, you know, it's actually maybe not a great tweet. It's kind of confusing for some people. I would say if you're managing three devs, then you probably should be writing code, because you won't have enough work to do otherwise, and you'll probably just spend your time annoying the three devs. So you keep writing code. However, if you're managing eight devs, then you have to understand that your velocity is no longer really significant. You've got enough devs to write code. So, you wouldn't write code for velocity. But there are still other reasons you might write code. Simply put, if the best thing for you to do that day is writing code, then you should do it. So, you might have a really difficult deadline, or you might want to pair-program with someone to build relationships or to learn. There are still a bunch of reasons why you can write code as a manager. And I say go for it. Becoming an engineering manager is a completely different role. It's a career change.

3. Flipping Between Dev and Manager

Short description:

Moving from dev to manager is not a promotion. It's a sideways move. Skills learned in one role are transferable to the other. A manager with recent technical experience can have great conversations. Leadership comes from both managers and senior engineers. If you're thinking about flipping to management, just go for it.

Dramatic? I think it's too dramatic. I mean, it's a different role. But if it's a career change, then I've changed careers seven times already, and I don't feel like that's the case. My skills in both roles are still very similar. So I wouldn't call it a career change at all. Don't be scared by that one.

Moving from dev to manager is not a promotion. It's a sideways move. An angry tweet. I've seen this one before. Look, you know, it really depends. Companies do it different. And I think it's a really good thing that companies do it in a different way. Because as you can see in my career, I did both. I had the promotion to get into it. And I probably never would have discovered management if it weren't for the promotion. However, at Lassian, we've got the sideways move, which is a really nice thing to have. And it doesn't encourage management for the wrong reasons.

So skills I've learnt as a manager that make me a better developer. There are a bunch. Again, I'm just trying to tell you about how it might actually be a great thing for your career to go back and forth. You're just improving different skills, but those skills are always transferable over to the other role. Same thing, skills that I've learned as a developer that make me a better manager. So there's a bunch there. I've always appreciated a manager with recent technical experience. You can have great conversations with them. That's just my preference. So whichever way you flip or flop, I think you do really come out as a super manager or a super engineer. And I've heard at Atlassian, people actually asking for, I'm trying to hire a senior engineer with prior management experience to boost the leadership in that team. Remember, leadership doesn't just come from the manager. It comes from the senior engineers as well. So if you are thinking about flipping over to management, then I say, just do it, go for it.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
26 min
Principles for Scaling Frontend Application Development
Top Content
After spending over a decade at Google, and now as the CTO of Vercel, Malte Ubl is no stranger to being responsible for a team’s software infrastructure. However, being in charge of defining how people write software, and in turn, building the infrastructure that they’re using to write said software, presents significant challenges. This presentation by Malte Ubl will uncover the guiding principles to leading a large software infrastructure.
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
React Day Berlin 2022React Day Berlin 2022
25 min
Building High-Performing Cross-Cultural Teams
Everything we do, from the way in which we write our emails, to the method in which we provide negative feedback and evaluate performance, governs the performance of our teams. And understanding how culture impacts our efficacy as a team can drastically improve our day-to-day collaboration. In this session you'll learn: How different cultures communicate, How different cultures evaluate performance and give constructive criticism, How different cultures make decisions, How different cultures trust, How different cultures perceive time.
React Summit 2022React Summit 2022
21 min
Scale Your React App without Micro-frontends
As your team grows and becomes multiple teams, the size of your codebase follows. You get to 100k lines of code and your build time dangerously approaches the 10min mark 😱 But that’s not all, your static CI checks (linting, type coverage, dead code) and tests are also taking longer and longer...How do you keep your teams moving fast and shipping features to users regularly if your PRs take forever to be tested and deployed?After exploring a few options we decided to go down the Nx route. Let’s look at how to migrate a large codebase to Nx and take advantage of its incremental builds!
TechLead Conference 2023TechLead Conference 2023
27 min
A Quick and Complete Guide to Measuring Your Tech Debt and Using the Results
Hardly any people in Tech like when there's a lot of tech debt. And most of us would like when there's not too much of it. But how do we understand how much exactly we have of it? Where exactly does it sit? Which part of it is actually the most annoying? What would be the benefit for us if we spend time getting rid of it? When it comes to planning how you tackle your tech debt, all these questions deserve answers. Especially when we're asked about the ROI on our efforts to eliminate some annoying legacy stuff and build a new shiny module or service. Also, when we work on tech debt, we do want to tackle the most impactful parts of it first, don't we? This talk is about all of that: how we measure our tech debt, how we interpret the results of these measurements so that they give us the answers to the right questions, and how we guide our decision making with those answers.