Top Five Questions Founders Ask – Part 3
As a full-stack software consultancy, we at Carbon Five get lots of questions from clients past, present, and future. We’re passionate about sharing our industry knowledge, so we sat down with our leadership team and got some advice for aspiring founders and product leaders as part of an ongoing 6-part series. You can see all the interviews here.
Here, we sat down with Courtney Hemphill, partner and technical lead, to give us some insight into keeping your startup lean and functioning smoothly.
How can I find great developers to hire?
There are a couple things that I’m seeing right now that I feel like are smart plays to finding great developers. I think great developers are not people that are created in 12 weeks at a Bootcamp, I think they’re people who are really interested in solving problems, and they’ve just found that their modus operandi for solving problems happens to be in code. The equivalent holds true for design. They’re just solving problems through a visual experience versus code. Finding those people is what you want to do. That doesn’t really answer the question though so I would say that code languages are something that people get really interested in. Meaning that new languages are coming out and each of those languages can solve specific problems. 
I think great developers are not people that are created in 12 weeks at a Bootcamp, I think they’re people who are really interested in solving problems, and they’ve just found that their modus operandi for solving problems happens to be in code. The equivalent holds true for design. They’re just solving problems through a visual experience versus code.
The people that are diving deep into languages like Go, Erlang, various other functional programming languages, these people are starting to provide a lot of utility within those languages via open-source gems and software. Rails has a huge amount of gems contributed by a sizable community. For Node, it would be packages. These are developers that are looking for ways they can advance their own code community. You can actually go on Github and you can see people who are really active, and you can also find the people who are active in a language that is maybe very suitable for your specific domain space, like a platform that requires high concurrency. If you’re doing mapping, there are probably people on Github working on side project within mapping and you can see the gems they’re working on and you just reach out to them and you talk to them. Even if it’s not them, I bet they have friends that are looking for jobs that are active in that specific realm. It’s a great opportunity to reach out and find people that are excited about doing the thing that you’re doing and obviously already have an interest because they’re sparing time at 4 in the morning to code. I think it’s more about being a proactive person when recruiting as opposed to looking for a push, which is like using a recruiting service. Having said that, we definitely have some fantastic recruiters that we work with that are technically minded, and they do some of that legwork work for us. But you can do that on your own without a recruiter and you obviously save the recruiting fee.
Do I hire a design and then dev shop or both at once?
I think there are two ways to look at this. If what you’re looking for is specifically brand strategy or strategic brand development, you want to go to a design shop only – someone that specializes in that service. These are people who are going to go and do lots of investigation into marketplaces and ethnographic research. You’re going to spend a lot of money to come up with potentially a new brand, new logo, new marketing messaging- that’s not something that I think dev shops are ever going to be good at. What design and dev paired together are really great at is product focus. So the specific needs have been identified from a strategic standpoint, and you’re ready to take that and actually implement it. You get a ton of efficiencies with having design and development working together, because they’re actually designing into a technical product and a working interface. Then they’re able to rapidly put that in front of your end consumers, your end users, whoever that might be, internal or external. They can then use that feedback to really craft the design to make sure it’s simple, but effective, and you’re not building in features that are confusing or frankly not needed by the consumer.
When you hire just the development shop, this is when you need to know exactly what you want to build. That’s the idealized scenario- where you can just offshore it, because you have the very straight line-item-by-line-item, task-by-task description of what you need to build, and you’re confident that that nothing is going to change. The reality is that I’ve never seen a project where nothing changes. You’re taking a risk here, and you basically need to batten down all the hatches and make sure your plan is watertight before you can ship that thing off. Carbon Five is in the center of these options. Traditional visual design process is something that is actually hard to integrate into a technical team, and that’s the thing that we do well. Our designers, even if they traditionally come from a very strong visual background, they’re focused on product. They’re focused on delivery. They’re focused on really pushing forward the technical pieces and the innovations that have happened in that technology. They’re very capable of having frequent conversations with developers. That’s something that I don’t think a lot of designers get training for in either school or over the course of their career until they work with a company like Carbon Five. On the flip side, our developers are not just junior developers that can work really effectively against a backlog of features and a tracking program. They’re much more product focused, ergo they have the unique component of being able to solve problems on the fly as opposed to just writing code.
How do I get off this huge aging codebase and not end up in this situation again?
In the past, we’ve done our best to find services that can be carved off and specific initiatives that would be isolated from that company’s core legacy codebase. For example, if we wanted to put together an approach or a funnel to get a new chunk of customers, or if we wanted to explore a new mobile experience, we would parallelize that development completely siloed from their team and their core infrastructure. Then, we would mock out services that existed in that legacy system for the duration of our engagement, and we would be basically create a definition for API endpoints that we would need for them to implement. At that point in time, they know the specific needs on the core legacy app. So, we can slowly do that sort of experiment driven development- finding where the company wants to move, what the next initiatives are and the places they need to be- and we can then continue to build on that new, more robust, more flexible architecture, putting into place the services only as necessary in the legacy system and building out the new ones as we move forward. It allows us to do that thing that is really necessary in today’s development environment: Where you’re only building the things that are required at that moment and you’re leaving all of this legacy code, 90 percent of which, as we’ve found with previous clients, isn’t actually necessary anymore. So if you’ve got a robust, clean codebase and you can use the previous services to do that heavy lifting if you don’t want to have to start from scratch. You can actually move the business and the business needs forward without having to stop everything in its tracks.
Native or mobile web?
Again, sort of depends. Native, you have to understand whether a user is going to be motivated to download your native app and install it on their system, whether it’s Apple or Android. If you feel that you have that motivator, then native is probably good. You get better flexibility on the design side, you get less of the uncanny valley experience. However, it’s way more expensive and it’s harder to deploy and test. So if you’re going for a consumer app, where there’s a lot of interactivity and design considerations, it’s going to be a lot more difficult for you to iterate and push out versions to test with a larger user base than about 20. Mobile web has come so far. Oftentimes, if there’s still this debate, “Well, maybe we want Android, maybe we want iPhone,” we actually might push people to do mobile web, using something like the Ionic SDK that is built on top of another platform called Cordova. You can get really fantastic visualization and design animations and interactions that at one point in time you couldn’t get. So every single day, there is literally a better and better solution for the problem of mobile. The only thing that stands outside of that is when you’re talking about something like a watch or maybe the new iPad Pro. New devices will always bring another a new configuration where it’s just going to be weird to try to split the difference between the 10,000 different landscape variants on Android as well as all the ones that are now available on the iPad. So you just sort of have to figure out what you’re targeting for and then make the decision based on that.
As an enterprise company, how do I incubate a new culture to bring in new knowledge, creativity and innovation?
A lot of big companies are trying acqui-hiring; so finding a shop that does the thing that they want, process or skill set wise, and just acquiring them. You see a lot of attrition, you see a lot of arguing- basically my team versus that team. A lot of people, the reason that they were working in that small shop that got acquired was because it was a small shop doing a specific thing, and they don’t want to be part of a larger org. That’s one thing, and it has a little bit of success, but you have to bake into that acquisition this understanding that it’s going to be hard and it’s probably going to have a certain level of failure. The second option- and the one that we try- is that we recognize that people learn the best when they are learning together. So through an experience they are creating a product, they’re in the foxhole together, they’re all in the trenches going after one initiative. Because they’re one team, they’re much more psychologically aligned and willing to take those risks. You have to work together in a more cohesive manner than you might if you were coming from two separate departments. I think working toward an actual goal where the whole team is capable of seeing value and bringing that value to actual users and learning from it. You get a lot of psychological benefit and people buy into a process change much more proactively than they would if it were just told to them. It’s the equivalent thing you see in school, if you give kids a bunch of stuff but you never have them go home and do the homework or work in team together, they’re going to forget it. You have to got through the experience to learn that stuff. So that’s what we do.
Autodesk is a good example of a client who has done this successfully. They basically were having issues putting new skills into their current teams and having their teams work more collaboratively with one another. They were seeing these dev/design shops do this thing, so they wanted to figure out, “OK, how do we teach our team to do that thing?” So they brought Carbon Five in and we ran them through our process. It was a short engagement, it was probably only about 12 weeks, and we literally designed the project with their team on the fly. We needed an initiative, we needed something to focus on and a goal, and the goal was to put together a tool so that their designers and developers could collaborate on prototypes and then present them existing consumer segments. Then the data analysts and the user experience groups could all work together in service of these customers. Capital One was another, they definitely are very focused. Capital One is really proactive right now at going for a sea change in their existing process, and so they are looking at all different types of ways to work. They’re looking at strict Agile. They’re looking at Agile XP. They’re looking at Lean UX. They’re looking at design thinking and they’re trying all of those out. Having said that, they’re doing it in this manner that I described, meaning that they actually come up with the project that they feel like is a good candidate for this approach, and then they hire on the vendor that they feel like exhibits in the best manner those specific processes and methodologies. So they hired Carbon Five to be the Agile XP process champion. I won’t say it wasn’t without its difficulties in the beginning and there definitely was a lot of pushback on some of the specific hallmark parts of the process. However, the great thing was at the end of the project when the team saw the success of the product delivery and they wanted to continue doing that process moving forward.
There are still three more interviews coming your way. We will have more perspectives and advice from the other Carbon Five Partners in the coming weeks. In the meantime you can follow Courtney on LinkedIn.
