Ctrl+Alt+Delegate: Keys to the shift from developer to manager

To give a bit of background: Gravity Works started in 2009, and when I joined in 2015, I was part of a front-end team of four
In my time, the team has gone from as few as two FEs to as many as ten; we’re currently a team of eight, myself included
Became longest-tenured developer in 2018, which gradually moved me into an informal team leadership role
Reorganized into cross-functional teams in early 2020; I moved out of a production team to more officially oversee FE in summer 2020
Acquired by MFB in 2021, when I officially became a team lead/manager
I want to acknowledge that I check a lot of boxes in terms of privilege, I’m at a consultancy instead of a product team, and work is a lot different now than it was a decade ago (remote work, AI, etc.)—I hope you can learn from my journey, but it may not be yours

When I was in second grade, I was somehow featured in my town’s newspaper as a “class act”
My teacher’s quote that “Kurt strives to do his best” has always stuck in my mind, for better or worse—I’ve always tended to be the kind of high-achiever, organizer, and planner who likes solving problems and getting things done, often independently
That’s good for development, but management means letting go of some of that, and striving for my team to do its best, not just myself, but guiding the team through leadership
One of my earliest lessons was that I’d taken a lateral move, not a promotion—I needed different skills in order to succeed as a manager than what I’d relied upon as a developer—and that my job had a new definition of what it means to do my best

“What makes you a successful developer won’t necessarily make you a successful manager.”
I remember that my first annual review after becoming a manager shifted so that I was evaluated based on my team’s performance, not just my own output, making it all the more important to focus on building my team
Not every good developer is cut out to be a manager—the skillset is very different
You use your emotional intelligence as much as, if not more than, the technical intelligence you’ve built up
You’re also now managing people who used to be your fellow team members, and make decisions that can affect their well-being and livelihood, as well as the overall culture of your team
I try to keep the gravity of that responsibility in mind, but also use that to remember we’re still a team and can work well together

One of the biggest changes I felt was that my work became less tangible than it was as a developer
As a developer, it’s clear when you fix a bug, your tests pass, and your deployments finish—you get instant feedback with a success message or a completed task, and that builds clarity and confidence
As a manager, the feedback loop is slower: sometimes you’re giving feedback that will play out over months or years, and you’re doing work that has a gradual impact on the entire careers of your team members
A lot of managerial tasks—relationship-building, improving communication, building trust—are things that are never done, so there’s no immediate satisfaction or dopamine rush of checking it off your to-do list
You have to be comfortable with uncertainty, which can be hard, especially if you’re a planner and an organizer like I am

On giving feedback: I’ve learned that I’m naturally confrontation-avoidant, but that means I have a tendency to shy away from giving my team feedback
In Radical Candor, Kim Scott talks about “ruinous empathy,” when you spare someone’s short-term feelings by avoiding necessary critical feedback
She points out that it can be a kindness to give feedback that helps someone grow or addresses behavior
I try to give praise in public and criticize in private—also a kindness
Set good expectations, and communicate quickly when they aren’t being met—and make sure you actually communicated them
Don’t wait for an annual review: feedback in an annual review should not be a surprise, but a reinforcement of feedback you’ve already been giving
I’ve also learned that timing is important with feedback: when someone’s fighting a fire, it’s probably not the best time to criticize the minutia of how they do it, but following up afterward can help smooth the process next time
Multimodal feedback can also help ensure it gets heard: I’ll often address something in a call and then follow up in writing
Don’t forget to celebrate the wins too! Talk to your team about what kind of recognition they prefer; not everyone likes a big public spotlight, but a quiet thank-you can also go a long way
Overall, all of these practices increase trust with the team; feedback helps them grow and helps our team produce results

Part of giving feedback is managing performance issues on your team, something that’s definitely new when going from developer to manager
Industrial psychologist W. Edwards Deming’s 85/15 Rule said that systems are often to blame (85% of the time), not people (15%)—so before managing individual feedback, make sure there aren’t systemic changes you can address first (clearer communication? improved processes?)
Remember that not everyone wants to be a rockstar—and that’s OK (do they just want to do good work and go home? do they want to specialize in one area?); unfair to expect your team members to all follow in your footsteps
In that same vein, not everyone wants to be a manager; try to find career progressions that let good developers uninterested in management continue to grow (ownership over a wider part of a project? new skills e.g. back-end dev or dev ops? shadow you in pairings?)
With that in mind, when managing performance, make sure you’re giving clear, continuous feedback and setting very clear expectations—including what needs to change, by when, and how you’ll gauge whether issues have been addressed
Even when team members have been unhappy about performance-related conversations, I’ve found they’ve been appreciative when they come with clear expectations and an obvious understanding of how we’ll know when something has been satisfactorily addressed
Remember too that you’re punishing your high performers by not helping your low performers, because they’re being saddled with extra work—again, avoid ruinous empathy and have the tough, but necessary, conversations

Speaking of feedback: a few years ago, I read a Twitter thread from someone who described two types of team members who give feedback, First Alert and Final Warning
A First Alert teammate gives you feedback early and often
A Final Warning teammate keeps their head down unless something really needs to be addressed
Feedback is often one of those intangibles that’s hard to get, so both are examples of useful feedback about the team’s overall health:
First Alert teammates show you quickly where issues might be only starting to crop up, letting you address things quickly
Final Warning teammates make the severity of an issue blatantly clear if even they are speaking up about it, meaning it needs action ASAP
I’ve been fortunate to have both types of team members on the front-end team over the years

It was very important for me when I started at GW to find somewhere that I could be open about what I didn’t know and strive to learn
I’ve tried to keep that as one of the main tenets of the front-end team ever since; we have weekly team meetings
Maintaining culture that isn’t ego-driven and values learning and sharing
Especially on small teams, every change can affect its culture
When hiring, make sure candidates meet your values, but think about what they can add to the team; go beyond culture fit
Involve your team too—it’s their team too, and they’ll have valuable perspectives on what they’re looking for in a teammate, as well as what you’re looking for as a manager
We’re a remote team, but sometimes a full team event isn’t in the budget or doesn’t work logistically, so we use conferences like MidCamp and DrupalCon as a way to bring some of the team together if we can’t do a full-team event in person

“If you want it done right, do it yourself” doesn’t work when your job is to build a team
It’s a quick path to burnout if you don’t balance—or replace—your old development habits with your new management responsibilities
In The Manager’s Path, Camille Fournier talks about making a choice about how you spend your time, and that you can’t fully do both development and management: sucking at being a developer is one thing, but sucking at management is a choice you inflict upon other people
Delegation is the way forward, but it didn’t (and still doesn’t!) come naturally to me
Early on, I was also worried about becoming ineffective by not developing as much anymore; instead, I appreciate when other team members introduce new techniques and solutions

A few strategies and tips I’ve learned about how to delegate effectively:
Don’t just hand off a task and wash your hands of it—it’s still your responsibility to make sure your team member has the information they need to be successful and to follow up about it
Make sure it’s clear why the task is being given to them—is it to help them learn something new? is it to start taking over a routine process? is it to level up with a growth opportunity?
To help free up your own time, consider handing off tasks you’ve mastered (so someone else can too) and document what you’ve learned for others to take after you
The One-Minute Manager Meets The Monkey talks about avoiding reverse delegation, in that book, “the monkey” is a task that gets passed around you and stays on your back when it’s your responsibility to do; when a team member gets stuck with something delegated to them, you keep it off your back by ensuring you coach them through the task when they’re having trouble, rather than just taking it on yourself
As a manager, there’s work you’re uniquely suited to do (higher-level strategy work, sales, interpersonal management)—protect your time for that

I’ve been skeptical of the idea of the “10x developer” that was a popular idea a few years ago—usually the type of developer described is the move-fast-and-break-things, ego-driven type
I do see my management role as being somewhat of a force multiplier, that empowering and helping my team lets us move faster than on our own
On certain projects, I have weekly developer check-ins to help work through problems, problem-solve on requirements, or discuss relevant past experience
On others, I leave time on my calendar for ad-hoc pairings that developers can book through Calendly
I think those pairings are most beneficial when my pairing partner leads with what they’ve tried so far, I teach instead of just telling them what to do, and they leave with clear next steps
MSU Writing Center: making better writers, not better writing—setting team up better for the future

There are different types of delegation that you can use in different situations
Mentoring: sharing your own experience as background for a new problem; I use when sharing work I (or someone else) did in the past as an example for someone to pick up on or to point them toward inspiration
Coaching: more open-ended; guiding, asking questions, and waiting for the pairing partner to come to their own conclusions instead of giving answers directly
Sponsoring: recommending someone for a growth opportunity—often something more high-visibility or technically complex that provides a growth opportunity and chance to prove their skills
Lara Hogan’s Resilient Management also mentions that underrepresented employees are often over-mentored and under-sponsored, so give them a platform and the support to grow and shine

A way to provide some control, without micromanaging, is to introduce processes and systems for the team to use—a good use of my planning and organizing preferences from being a developer
It’s also a good way to stay on top of technical advancements without tying yourself up in complex, time-sensitive client work where you could become an unnecessary bottleneck
We’ve been improving our starter setup for new sites, now using a set of Drupal recipes instead of the more complex distribution we’d been using; I’ve been spearheading that in my weekly professional development time, and it’s a good way for me to help move the team’s processes forward
Documentation and sharing progress in meetings are vital to building team understanding and adoption

I like using the Eisenhower Matrix to help guide what I spend my time doing
It breaks work down into four quadrants based on whether it’s important and/or urgent
Work in the first quadrant—important and urgent—is work I should focus on completing right away
In the second quadrant is work that’s important, but not urgent—it can be scheduled and can be more flexible on my calendar
The third quadrant has work that’s not as important, but is urgent; that’s good work to delegate
The fourth quadrant is work that’s neither important nor urgent; consider dropping this work if it’s unnecessary
Sometimes everything seems urgent and important, so this framework helps me scrutinize whether that’s true, which then helps me be less likely to be overwhelmed
Not everything will fit so neatly into these boxes—does anything?—so also prioritize things that are uniquely yours to do

At DrupalGovCon a couple years ago, Bree Benesh gave a keynote where she brought up the book Leaders Eat Last
She noted that while leaders eat last, starving leaders don’t make great decisions
I’ve noticed that in the past five years I’ve officially been a manager: when I spend too many late nights working, get into periods of higher stress, or go too long without time off, it changes how I interact with and support my team, not for the better—fuse gets shorter, “compassion fatigue”
I’m also an introvert, so spending a lot more time in meetings and interacting with others, I need to recharge my batteries more often
Revealing for a hard-working, get-things-done developer like I was, and I value my team too much to burn myself into the ground and take them down with me
It has made the importance of breaks, time off, and self-care even clearer

This is a picture of a campsite at Getaway, now called Postcard Cabins after its own acquisition
For each of the past three years, I’ve spent a week here as an opportunity to fully unplug, get outdoors, and get away from screens (other than my Kindle)
I know enough about myself to know that I’m not great about taking time for myself—see my earlier mindset that I “strive to do my best”—but I need to benefit from it and model positive work-balance for the team
Vacation is also a good test: have I delegated enough that things move forward while I’m out? Have I documented and shared and coached enough that others can take on work without needing to contact me or getting stuck? If not, I have work to do; if so, I can rest easier on the next trip

When I can’t get away regularly, I remind myself that there are other ways to build recovery periods into my days
I try to practice guitar over my lunch break; I bought an indoor bike in January to get a workout and get away from my desk; I never go too long without a new LEGO set; I watched all of Survivor last year
Even when still working with Drupal after hours, side projects are a good, low-risk way to try new things and keep up with advancements with tech—and when you’re your own client, you can do what you want with it—I’ve noticed that my batteries feel more recharged when I can work on it
Overall, I make sure to give myself opportunities to quiet my work brain, touch some grass, and come back and tackle big problems at work with a clearer head