3 Signs You Need to Fire Your Development Team
The team with the best players wins.
In each company’s unique path to growth, there comes a moment when someone needs to decide if technical development should be handled internally, or outsourced to a development firm. If the CEO is making the decision to outsource to a development firm, that usually means they’re doing so as a consequence of a mistake – a mistake that has potentially put the life of the company on the line.
The mistake could be one of many things. They’ve unknowingly bled the company’s revenue by funneling too many resources to their internal development team, or maybe the client-facing product the internal team has built is poor quality. Whatever the reason, now the company realizes they are lacking expertise that can only come with repetition and refining of processes. This is the benefit of outsourcing to a development firm.
I’ve come to realize from conversations with other business owners that this is an important topic to discuss. Many business owners may not feel confident enough in making a decision to hand development over to someone else.
Based on my experience, I’d like to highlight 3 signs to look for in your internal development team that could be causing problems:
1. Lack of Critical Thinking Skills & Team Agility
A common issue in development projects we’ve taken on here at Blue Stout is problematic internal devs who cannot problem-solve. Any roadblock in development leaves them paralyzed instead of challenged and ready to pivot.
“Tunnel vision” in a developer is not always a bad thing, but inside the technical demands of a scaling business, a loss of peripheral vision can mean failure. You need your team to be able to deviate from the game plan, should your business strategy require it.
For example, let’s say you run an ecommerce company and are launching a subscription model soon. Your internal team has been working on building the infrastructure for the subscription model, and you have a deadline in place for your launch. And then, one week before launch, you find a programmer who is obsessively tinkering with perfecting the responsive design of one small, pesky element while the integration of your backend to frontend still remains incomplete.
Tunnel vision is the inability to focus on the most important things – the big picture. Make sure your team members can prioritize.
2. No Development Workflow
If your company has a flexible infrastructure and workflow in its development team, then you shouldn’t be experiencing technical overhead. However, not having the correct processes in place could be the problem. That’s our second sign of poor internal development: lack of workflow.
In any successful development project there should be
- a deployment schedule
- style guidelines
- code reviews
- quality assurance
- communication
There should be a clear pipeline the work flows through in order to hold team members to deadlines, as well as to make sure development is going as efficiently as possible. Establishing a streamlined workflow increases your ability to quickly develop new products or services. This is a great advantage in one-upping your competition with speeding up your time to market.
3. Don’t Adhere to a Coding Standard
The purpose of upholding a coding standard is NOT that the code remains easy to read or bug-free. Yes, these things are ideal, but a standard serves a higher purpose. A coding standard serves as a measurement and declaration of the purpose of the product you are building.
The end-goal of the product needs to be reflected in every piece of code. If you’re not a programmer, this doesn’t mean you should skim over this section. Understanding the importance of upholding standards is a fundamental business practice (we’re just looking at it through a technical lens).
Have you ever worked with someone who just half-assed everything? Everyone had that friend growing up. The lazy one. The complainer. The guy or girl who didn’t want to put in any effort until the very end, throwing together something at the last minute. Obviously, they weren’t proud of their overall product and thought very little about it until the deadline. Maybe their end product looked cooler than yours, but the minute it went through any type of testing, it broke. Pure aesthetics. Pure shock value. Nothing foundationally strong.
Ever met a developer like that? If there’s one on your internal team, they’re definitely sucking funds straight out of your business. You’re pumping resources into a person who probably avoids these key things:
- Development Tests
TDD, or Test Driven Development, is a practice that’s been around for a while, but was recently made popular by the surge in agile development or SCRUM fanatics. Put simply, implementing TDD ensures that your developers are checking their code by writing tests to check their code before the actual code is even written. Check out this diagram for a visual:
Obviously, this isn’t a strategy that can be halfway implemented. The learning curve needed to adapt to this line of thinking could be a further waste of your resources. Outsourcing to a development team who already has this process implemented could be a more efficient choice.
In a blog about firing your internal QA team, author Mike Gualtieri quotes British author Samuel Johnson:
“The prospect of being hanged focuses the mind wonderfully.”
When developers know quality is their responsibility and not another department’s, they will focus more on coding to standard and excelling. There’s no one else to blame. Whether you have a separate QA team or you already entrust that responsibility to your devs, trying to motivate a developer after he or she has already been working in their set style for quite some time is difficult. If you can get your team on board – more power to you! Try to consider, though, how much time you will need to invest in that initiative and if it is truly worth it to your business.
Developers get comfortable. They’ve worked really hard to achieve a level of programming where they could be considered great, even an expert. The sad thing about this is that technology doesn’t care. It goes on. You’re a Python expert, but guess what? Ruby works just as well and is more friendly. You must adapt, or get left behind.It’s common in internal development teams that developers may be attached to a legacy language, platform, tool, etc., and will continue to build with these solutions. This is not ideal for your business development. In order for you to be able to compete on a higher level, you will have to keep up with technology as best you can. Many business owners trust their internal teams, but are unaware of the dangers and costs associated with legacy solutions. You can hack something together for a short-term solution, but two years down the road you’ll be stuck with a mess.
The above 3 criteria are critical in determining if your team adheres to a coding standard. Evaluate each member to see where they fall in adhering to a standard. Do they test? Do they check their own work quality? Are they developing for stability or for bragging rights? Can they still be useful outside of their comfort zone?
Numbers Don’t Lie
I’d love to say, “trust your gut, you can make this decision off of pure intuition” but I’m not sure that’s the best advice. Once, you can see the actual hours or dollars (or both) you’re losing because of internal development issues, you’ll know it’s time to make a change.
Hopefully, it won’t come to this and you’ll be able to recognize the need for change beforehand.
Fore more tips on running a profitable ecommerce business, sign up for our newsletter and follow us on LinkedIn.
Header image courtesy Gage Skidmore
