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

A presentation at MIDCamp 2026 in May 2026 in Chicago, IL, USA by Kurt Trowbridge

I work for GW, an agency started in Lansing, MI that has built websites and mobile apps since 2009, now mostly in Drupal
Started at GW in 2015 as a front-end developer, as first job out of college

Consulting agency, so working with a number of clients across industries—high school athletic associations, transit, higher education, legal aid
As a developer, I enjoyed implementing designs and getting my hands dirty in solving client problems while learning a lot

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

There are four sections I’ll cover this morning:
Alt: How your skills shift when becoming a manager
Delegate, or really, Delete and Return: Letting go of tasks while letting others learn and grow
Ctrl: Focusing on systems over tasks and processes over “hero” work
Esc: Taking care of yourself, so you can take care of your team

What changes when you go from being a developer to a manager? How are your responsibilities different, and how does your measure of success change?

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

No one had been in a developer management role before at my company, so there wasn’t a training to attend or past experience to lean on
I turned to books, webinars, and articles, along with conversations with my manager
Books I particularly liked included Camille Fournier’s *The Manager’s Path*, Sarah Drasner’s *Engineering Management for the Rest of Us*, and Kim Scott’s *Radical Candor*
I’ll mention others later in the talk, but they had a lot of good insights that I’ve taken into management, from having tough conversations to advocating for the team’s needs
I also leaned on articles and webinars from the LeadDev community in particular

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

As a manager, you’ll be getting more feedback, from all levels of the organization
Feedback is a gift, and feedback from your team is a sign of trust
They may not initially feel comfortable giving feedback, so solicit it where possible—we used to use a tool called Officevibe that sent regular surveys, and I’ll follow up any announcements with a request for questions
If you disagree with feedback or can’t implement it, context is helpful to ensure someone still feels heard and willing to provide feedback again in the future
*Your* team is now really your fellow managers, so working with and getting feedback from them helps the organization run more smoothly

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

After our acquisition, we all took a CliftonStrengths assessment, which shows what your most natural strengths are and which ones you rely on less
My top strengths were almost entirely in executing and strategic thinking: getting things done, learning new things, planning ahead, and otherwise being disciplined and responsible
Not that I wasn’t also communicative or empathetic or adaptable, but I didn’t reach for those as readily
The facilitator asked me to identify one particular goal to work on, and my easy answer was delegation

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

Had to get more comfortable with delegating tasks that weren’t perfectly planned and making them growth opportunities for the team
From Lara Hogan’s *Resilient Management*: “The best gift you can give your teammates is a messy, hard-to-measure, unscoped project. This kind of project creates the biggest opportunity for someone to grow as a leader.”
Providing that context helps team members understand why the work is coming to them and I think helps them push themselves for success

One blog post I read early in my career stuck with me, from a developer who, when he got stuck, forced himself to try for another 15 minutes, then ask for help
I took to that as a developer, but I’ve also taken that into my management role as advice for my team that I try to quote regularly: do your due diligence in looking for a solution, but when you’re stuck with no next steps, don’t wait too long to ask others for help
In the interest of building the team, I try to recommend they ask the rest of the team first, not just me—I can then use that as a signal that if the full team struggles for an answer, it’s an area where we can all grow as a team

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

I talked about setting up “better writers” instead of “better writing”—so how do I approach that setup for my team to succeed? How do I use my time effectively to help build and support the team, without micromanaging team members or bottlenecking work?
Part of that is doing less direct work of my own than I used to, or picking smaller, shorter-term projects that I can move in and out of
A larger part of that is setting up systems to help my team do good work without getting in their way

Delegation is about loosening control over the work being done: you can’t necessarily control outputs from other team members, nor would you want to if you want to encourage fresh thinking and innovation
You also can’t control emotions: how people react to communication, change, and their work can be unpredictable; we’re all human
In the same way, you can’t tell people what their opinions are, and a healthy team encourages differences of opinions and offers a safe place to debate and determine the best path forward
As consultants working with a large number of clients, we also can’t control when a fire comes in and disrupts our plans for the day

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

Development task planning is another process I’ve introduced that helps me provide some structure for the team’s website process while not making myself heavily involved in every project
Introduced a spreadsheet where developers can break down dev needs by feature, add notes, and estimate with confidence levels
PMs also like this because it helps them know work is broken down and planned, and they can use the estimates to schedule the work
I only built the system—it’s the team runs with it and makes it successful

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

To help address work in the upper half of the quadrant, I protect some “maker” time, but have shifted more of my time to “manager” time than I did as a developer
I block time for project work that I need to complete myself (Q1) and work that I’m uniquely suited to take on, but try to keep that to a minimum
I block time each week for professional development that helps make sure I grow
To help with work I’m delegating, I document routine processes and tasks that can be delegated, and share that information in writing and through team meetings
I have check-ins with the team and leave some slack for unplanned team needs that pop up

You’re now moving your unique work forward, keeping an eye on the work of your team, and building strategies and systems
You’re looking out for personal needs on your team, identifying areas for efficiency, and doing work at a higher level in the organization than before
All of that can be a lot for one person to juggle
How do you come up for air and make sure you’re taking care of yourself too?
When I started in this position, it was one of the first things I wrote down, following an article I’d read: I need to take time for myself in order to be a good leader

Right after starting at Gravity Works, I remember my boss saying that consulting work is like drinking from a firehose—there’s always something else to be done, and you’ll never fully clear out the to-do list
That can be stressful, especially when you’re now thinking about the to-do lists and needs of an entire team, not just your own
Easy to fall into a pattern of working late and long in an attempt to “catch up,” even though it’s futile

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

In summary, if you’re a developer coming into a manager position:
Understand that it’s not a promotion, but a role change, and learn what’s different about it
Lean into delegation, trust your team to execute, and support them through coaching
Add systems and processes to help with guidance and oversight, not micromanagement
Make sure you put your own oxygen mask on first: sustain yourself, then support your team
Back to that second-grader who strives to do his best, he still can, just for the sake of his team, not just himself

End Thank you! Kurt Trowbridge GravityWorksDesign.com 35

Kurt Trowbridge
@kurttrowbridge

1 / 35

I began my career as a developer, where building websites for clients and learning development best practices were my primary responsibilities. As I became a team leader and manager, I quickly learned that my job now had a very different set of objectives, priorities, and keys to success. Instead of solving technical problems with code, the most important parts of my days became addressing more ambiguous “people problems” and coaching my team members toward growth.

This session will cover how I shifted from a front-end development role into management, and the lessons I’ve learned that can help other developers thinking of making a similar move. I’ll detail how delegation was my biggest struggle and greatest help, the importance of clear communication and expectations, and how to support my team while building their skills, not just my own. I’ll also touch on the differences in feedback loops between development and management problem-solving, along with how to stay technical while spending less time directly working on code.

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

Link for this presentation:

HTML code for embedding:

Share on social media:

Video