Lets face it: anyone who has been in the technology game for any length of time knows that finding a bad-ass coder is tough. Doing it on a budget is even more difficult. But when you get a developer on board that has a great background in all the technology that you want to use in your products, you get excited. When it does happen you are going to find yourself facing a dilemma that could end up costing you big time.
We had just finished its first round of testing and was going live with a client the following week with a product. The user interface was fine, but had a long way to go before it could be considered a solid experience. Resources were tight, and we lacked a UX/UI designer to build out a sleek experience. What we had was fine for the first release, but the front end was ready to have a revamp.
Searching high and low we found someone who’s a proven UX/UI designer, coder and architect. His personality synced with ours and both of us were really excited to get him on the project. So before we gave him the work, my partner and I sat down to discuss his role in the project. We started fantasizing about how the new UX would engage anyone who used the product and that this new UX designer was going to revitalize the experience in a way that would bring us both to prostrate ourselves before the awesome power of the design.
But as we started putting together the notes and building out a statement of work we realized that we were about to put the responsibility of the entire front-end strategy, architecture, and future of the user experience in the hands of someone that had no insight into our business strategy, experience, or our technological roadmap.
HIT THE BRAKES!
There’s a reason that in software development you don’t let people muck with your code before you outline thoughtful and solid requirements/user stories. It’s because letting a new guy loose on your codebase is like letting a hamster fly an airplane. Sure he’s the guy that everyone likes to drink with and can make quippy jokes, but that really doesn’t qualify him for tasks outside of his wheel-house.
Now that’s not to say that people you bring into your project should need their hand held while ramping up. But don’t speed up or rush your release schedule just because you are impatient to get to market. There are enough people that try to get to market so fast that they release crappy, bug-filled, and ugly technology that everyone tries for a couple of weeks and then goes back to their daily lives of dealing with the same problems that tech was supposed to solve. If you haven’t released your product yet and you are rushing to the gate, stop yourself. Your product is still under the radar and no one knows about it. It’s much easier to recover from a delay to market than to recover from a crappy product that is released before it’s ready. Being successful in this industry is about trust. If you release a bad product that your users expect a certain level of usability and stability that you don’t deliver, you’re going to fail, and you’re going to be spending more time regaining that trust than you did developing the product that lost it for you.
That’s the quick and dirty, now for the more serious internal business problem with rushing this issue. If we were to let said UX/UI/possible Serial Killer into our code base to build out an entirely new architecture with new libraries, frameworks, and code without making sure that it followed the technology roadmap (which if you don’t have one as part of your business plan, God help you) 3 months down the road the code would resemble a Jackson Pollock painting that had been put through a paper shredder and used for confetti at a St. Patrick’s Day parade in Chicago. That may be a little dramatic, but the potential to get “scope drift” from a situation like that is huge, especially if the new guy is really excited about the project. Don’t let your tech get pulled around by that enthusiasm without some plan as to how to handle it.
Getting that new, enthusiastic developer on your team is awesome. Make sure that it’s worth it when you look at the big picture, and make sure that your whole tech team is aligned with your vision and operation before letting them loose. Just because they are quiet doesn’t mean that they aren’t dangerous.