Yes, we’ve all done it.
I’ve done it. My previous managers have done it. And most likely, it’s the default setting for many battle-worn team leads.
In those crisis moments when expectations are high, everything is going off the rails, and the deadline was yesterday, all new tech agency owners will utter one fateful sentence.
It would be so much faster if I just did this myself.
Then they pick up the IDE, close the office door, and retreat into the code.
What they don’t realize is that they’ve just kicked off a chain reaction of negative work practices that will plague their team for months.
It’s up to you to anticipate the inevitable before it happens and make a firm, conscious choice not to try to code your way out of a crisis.
The most significant shift comes with the realization that you’re no longer a production unit, but you’re still working in an industry that values production. If you’ve always taken pride in the tidy transaction of being paid for your output, management is a strange new world.
The programs you created could keep manufacturing production humming or bring it to a standstill. Entire businesses hung on your creations.
Now you’re dependent on other people to create the code that works this magic. And making the switch from creating your own technological incantations to supporting other people’s efforts really feels awkward for a while.
But you really get triggered by array of new expectations staring at you, like:
-Figuring out your clients’ agendas
-Assigning work to peers or former co-workers
-Dealing with morale speed bumps
-Steering through software quality problems–as the person who’s supposed to have all the answers
Adding a management role to the rest of your responsibilities can feel like stepping into a plane’s cockpit without any flight training. There are all these complicated, unfamiliar dials and gauges you don’t understand, and you don’t know if that blinking light means an engine has failed or the coffee’s ready.
In order to escape this anxiety loop, many business owners new to management fall into one of two patterns:
1. Code less, but indulge their coding desires by putting out fires and debugging whenever possible.
2. Code even more intently, blocking out team members and undermining their credibility as a leader.
Each of these positions is a pattern that will cause you to fail.
Let me say it again. Retreating to the position of “I’ll do it myself” isn’t going to save you any time or frustration. It’s only going to crank up the problems.
If you follow through on your natural desire to just do it yourself, you’ve chosen to avoid doing the following critical items:
“Why bother?”, they think. They lose their drive, you lose their trust, and projects start to suffer.
It’s like a conductor wrestling the tuba away from the tuba player
You’ve just traded away hours of non-replaceable time and energy that should have been devoted to doing the job you’re hired to do. And when you get back to the work that’s been piling up on your desk, you’ve got to dig out all over again.
A “quick fix” always takes much longer, turning your one-hour job into six hours (or more!) of panicked coding. While you code up a fix, your resentment and exhaustion build, and you’re teaching your team to depend on your last-minute efforts to bail them out instead of their own skills.
Trust me. Take a chance, drop the IDE security blanket and interact with your team instead.
Sure, you just scratched your itch by getting involved, but you’ve also established much-needed rapport and created up a teaching moment—for both of you.
Once again, you’ve opened lines of communication and placed your focus on the overall project, not just your team’s to-do list or your stress.
I cannot emphasize this enough. If you absolutely, positively can’t resist, then choose a project that is on the back burner. You don’t want to muck up a project in process.
Remember that your purpose as an owner-manager is to create a team that is capable of producing excellent code.
In those instinct-driven moments, especially in beginner’s panic, please take a step back. Avoid this classic management blunder.