You have a dev team on your payroll, they’re doing an awesome job, and it’s looking good on all fronts. Then some order comes down from the big boss or the client asking for a change.
Your team nods, says yes, but as the weeks go by, progress is grinding to a slow halt.
Your budget is running dry by the day, the app isn’t proceeding on schedule, and it’s a mystery why.
Problem 1: You don’t know why
Managers manage. It’s a lethal oversight, though, to think a manager shouldn’t know some programming...or how a dev project works. As manager, it’s tempting to think that you’ve got enough know-how to deal with any problems. But as it turns out in this story, one of those changes you asked your team had serious repercussions. Knowing why helps you avoid creating the problem in the first place.
The change didn’t seem too big but the request cascaded through the foundation code your dev team had already produced up to that point. They scramble to rewrite some code, which then leads them to rewrite more code. Now they’re spending their paid hours implementing some workaround in order to make the new change and the old foundation work together. The end result is inevitably worse code and hours wasted.
How to fix it: We don’t all have time to learn how to be a developer, but a few early course might show you the basics required for large projects. Another solution is to talk with your dev team. If you ask them to explain the problem in layman’s terms, you’re well on your way to understanding the problem.
Problem 2: You’re shifting the ball
Many web developers like to use the term ‘agile’ as a way of describing how they can easily pivot with changes given them. This, to many clients and managers, means that developers can change their website code at the drop of a hat...which is false. They begin to expect that and soon the requests start flowing.
Over time, your dev team is juggling the new changes, the retcons that need to be done, and worrying about their jobs if it’s not done well enough...which of course at this point, with all those changes, the budget and schedule can’t allow for a decent project anymore. Morale drops and it’s a sinking ship.
How to fix it: Be reasonable and be candid in your ball-shifting. Sometimes scope has to change, but you’ll be in a better position if you can work with your team. If a project gets more ambitious, be willing to compromise for a later deadline. Or if the shift would undermine a lot of previous code, maybe come to terms with how important the change is. Can you solve this problem from another angle?
Problem 3: No communication
A lot of startups think that the best way to run a dev team is to give them a plan, a timeline, and a room with a view and just...let them go wild. But then the dev teams start making decisions because they’re not getting any feedback from you and this can cause some division in the plan versus the reality. And it’s not wholly their fault. It’s important for all parties to keep in touch and communicate.
Remind yourself that you don’t know as much as them about coding, even though you’re talking between them and the client/boss. Talk to your team. Talk with them. Truth is, many developers have opinions but won’t rock the boat just in case. They may have the perfect solution. Coax it out of them and you’ll be surprised.
After taking their suggestion, make sure you have their back when you represent your team to the client. Don’t throw them under the bus. If your dev team knows you have their back and recognizes that you listen to them and are suggesting their ideas, you’ll start to form an unbreakable, cooperative web development team.
We will send you the report from our audit findings for free