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.
How healthy is my codebase? Can I rewrite it, or can it be nursed back to health?
A hundred percent of the time, your codebase can be nursed back to health. In my experience, ninety-five percent of the time, that’s the path you should take. This is making one assumption, that there’s a product already built and in use. The bigger the codebase, and the longer it’s lived, the more likely that it has features or bugs or whatever, pieces of code that are in use, that people are relying on, but nobody knows about at the company. So whenever you talk about rewriting a codebase to be the same as an existing codebase, you are opening yourself up for a world of pain because it’s very likely that there’s nobody in the world that exists who knows all of the requirements. If you ever decide to rewrite a codebase, you have to start from first principles and say, “We have to start from the very beginning and define what this new product does, and as a basis, we’re going to use this old product, and we’re going to say this is our starting point.” The same way if a client came to us with wire frames and said, “This is what I want,” we’d say, “Well, we’re going to use this as a starting point, but we’re still going to go through our personas exercise, and our experience map, and our story mapping, and our story writing, because we need to understand all that in order to build this product.” If you can do it that way, then rewriting is actually completely doable. I’ve discovered that even though it can be a lot of work to nurse a codebase back to health, if the functionality is there and fulfilling the needs of the users, then to continue to fulfill the need of the users without any interruption, you gotta nurse it back to health.
A hundred percent of the time, your codebase can be nursed back to health. In my experience, ninety-five percent of the time, that’s the path you should take. This is making one assumption, that there’s a product already built and in use.
How do I hire and retain great developers?
This is a little bit of a chicken-and-egg problem, because I think the best way to hire and retain great programmers is to have great programmers. The number one thing that I’ve discovered that people look for is to work with a team of people they respect. People generally want to be able to learn from their coworkers and teach something to their coworkers. Nobody wants to be at the very top or the very bottom. If you can build an environment where everybody thinks they’re at about the 30th percentile, you’re doing it right. So if you don’t have a team of great programmers already, then you need to go to your next weapon — making it personal. You need to create a relationship with the people you want to hire really quickly, as a manager relationship. You need to show that you are the type of manager that is going to build this organization around that person. For your first hires, it’s all about showing you’re going to build a good environment and be a good manager. After your first handful of hires, it’s all about the people you hired, and they’re going to do all the selling for future hires.
OK, I have my first product team. What now?
I think to be a good manager, it helps a lot to also be a practitioner. If your employees can respect your ability to do the work that they do, that’s a huge asset. It’s not mandatory, and it’s not always possible; it’s totally possible to be a nontechnical manager. I think a lot of the same things apply, as long as you prove that you can understand the value and the challenges that people face in their day-to-day work. You must show true empathy, meaning you are truly trying to address pain points and enhance the good parts of your employees’ roles. That is really all you can do. In a concrete manner, that comes down to figuring out how to understand what those pain points are, what people like and dislike about their job, and doing actionable things about it: Show that you’re actively trying to make progress, and eventually that you are making progress. If someone is trying their best but ultimately not doing anything, people are going to leave, not angry at you, but they’ll leave nonetheless. Being a practitioner of the same thing as the people you manage helps you with that understanding and that empathy quite a bit, but again, it’s not mandatory.
How can I keep my Agile practices alive and effective with my team when we leave Carbon Five?
This one is tough. If Agile is going to be successful and sustained in an organization, you need two things. First, you need highly respected evangelists from the bottom up, grassroots sort of evangelists. If you can have your most respected practitioners, whether it’s your developers, designers, product people, whatever, who are evangelizing Agile, that is very valuable. Second, at the top of your organizational hierarchy, you need people who understand their role and the roles of the people below them. You need people who understand what it means to play a management role in an Agile team, and they need to be willing to give the resources and issue the edicts that are necessary. The motivation has to come from the bottom, and the operational feasibility has to all come from the top. That’s part one.
What’s part two then?
Once you get a successful Agile process running smoothly, and everybody’s kind of bought into it, it’s actually very easy to keep it in place. I’ve found here at Carbon Five, we’ve never had a problem maintaining our Agile processes, because new people come and that’s just the way it is. There’s no alternative. Once the process has inertia, it’s going to be a lot harder for somebody that’s new to come in and say, ‘Hey, I really wanna buck the trend that this company is working in and institute a waterfall process,’ they have to really believe in it. And if they do, they should try their best to institute it– maybe it’s not waterfall, maybe it’s some new cool thing that we’ve never heard of before, and then hopefully they’ll have success if it’s better. But the thing that I’ve seen that kind of screws up Agile when clients leave Carbon Five is that the management doesn’t make it a priority or it doesn’t find its way into job postings and company meetings and all the other stuff that indicates to the company that it’s a company-wide strategy. Then people slowly drift back to where the corporate memory is. You gotta stamp out that corporate memory a little bit.
How long will it take you to build this thing that I want?
Interestingly, people ask this all the time way too early. I tell people that projects tend to fall into three categories of scope: small, medium and large. A medium project for us (which is a typical project for Carbon Five), when we’re doing full service, meaning product definition, design and development, is a team of five for three or four months. You can tell me nothing about your project, if you say, “Uhhhh, I don’t have any code written yet, it’s a new product, it’s not overly complicated, but it’s got some interesting features,” I’d tell you it’s a medium. A medium is three to five core features built really well and defined, designed and built really well, a version 1.0. They would have to say, “My product’s really simple, it’s one flow, it’s barely a product and more like a feature,” I’d say maybe it’s a small. That would be maybe a third to half the scope of a medium. And a large is just anything else. Anybody that can’t narrow their focus down to the core nut of what they want to do, that’s a large. A large is seven digits. Some way, shape, or form, it’s going to cost you a lot of money; so much money that, if I were you, I wouldn’t want to spend that much money just to get my first glimpse of a product.
We have more coming from the other Carbon Five Partners in the coming weeks, so keep an eye out. In the meantime, you can follow Mike on LinkedIn.