Let go
The DIY spirit of the MV industry is also its Achilles Heel. People need to learn when to hold on and when to let go.
This is primarily about application developers who wrote their app many years ago, had some success selling it, but then found with the coming of the GUI that sales started to drop. They’ve tried to learn what they could, tried some products and quick solutions, but nothing has really worked yet. They’re stuck with the best application in the world that no one will buy because it looks like it was written in the last millennium … which it was.
The Pick guy wants to do everything on his own. He feels it’s all on him to save the day because that’s what he used to do. He knows that he needs to put a modern UI on his app in order to get more sales. He knows he needs to do some marketing to get people to buy the app. He believes that he needs to do all of this, and when he can’t, those necessary things like modern development and marketing simply don’t get done. The Pick guy accepts this, and becomes comfortable being a decent-sized fish in a tiny pond. He decides it’s OK that his business isn’t growing, but there’s always that nagging worry about whether the MV market will dry up before it’s time to retire – or if retirement is even a possibility given the state of this sub-industry.
(BTW, references to “guy” and “he” are for convenience. I know there are a few women with MV apps and small companies out there, but let’s face it, not many. I’m talking about you too, but mostly about those other guys.)
We’re all about the tech side of the software business here. But if you want real growth of a software business, beyond being a one-man shop, you need to be a Manager, not a Developer. That requires delegation. It means recognition of one’s own limitations, especially as we get older, and employing or partnering with people with knowledge to achieve your goals.
The problem isn’t technology, it’s letting go. It’s the belief that since we did everything before that we should still be able to do it all now. It doesn’t work like that. Every new creak in your bones tells you that. The tech industry changes in exponential increments. We can’t possibly keep up. We (and I do include myself) all need to fall off some of the waves at some point, until eventually we ride the final big wave. Embrace that process. You see where you are after fighting it for so many years. Let go.
Every single “larger” Pick company I know has a one-time developer who hired people to make his business grow, and while most of them regret not getting their hands dirty so much anymore, in general they’re living the life they envisioned when they started writing their small application. Growing a business is the goal, not writing better BASIC code. Code is the means to achieve the goal, but people enamored with the code and the database miss that over time.
Many of these “larger” companies don’t really consider themselves to be “Pick companies”. After they get a few more people on-board, MV is just one tool in their stack, occasionally re-evaluated as a possible impedance to growth. These companies are inclined to consider letting go of the MV platform as they look forward to growth. Of course the rest of us prefer they don’t do that, but the point is that they’re thinking about what’s good for the business, not what’s familiar or convenient.
<Digression what-is=”Larger”>
By “larger” I’m talking about multi-employee shops with a few developers, some sales people, etc. Of course you can laugh at this if you work in a shop with dozens of developers on several products and you have dozens of sales people and a huge tier of management. I dare not say “successful” because many one-man shops consider themselves to be successful, which is a subjective evaluation that just evades the topic at hand. There are also “larger” shops where the key developer is the original author. In these cases, it’s about 50/50 whether the business is suffering because the key person is writing code, or whether it’s doing better because the founder has delegated the responsibility for growth to hired managers. Again this depends on how much delegation the founder does in the best interest of the business – on how much he has let go of the small stuff so that everyone can focus on the big stuff.
I don’t want to get into a session on business development but it’s a recognized paradigm that the transition from a one-man shop to 2 or 3 people can be hugely traumatic, and many companies don’t survive it. This trauma is part of what keeps a lot of one-man shops as they are – code jockeys don’t want to deal with that stuff. Then there is the transition to 4 to 10 where at some point a company that had nothing but developers now needs dedicated managers. Then there is the next transition where C-level people have mid-level managers … and so it goes.
The overall point there is that someone must take the initiative to grow the business, or that business and eventually this industry will simply die. That’s what we’ve been seeing for years. Some companies have successfully made the transition, many are still struggling, and others have just gone away.
</Digression>
It doesn’t matter what technology you use as a phase-one to add a GUI to your app. It doesn’t matter if you use mv.NET, FlashCONNECT, Pavuk, DesignBais, Viságe, AccuTerm GUI, WebWizard, or a dozen other tools out there. They all get you to the same place. There is no right answer here. Of course you want to start with the right tool, and ensure that it grows with you, but the truth is that there are no guarantees. They’re all good but they’re all subject to the same questions of long-term viability – in part because most of them are run by people who are still struggling with the concept described here. As a Manager, as stated above, you need to choose a stack of tools and always re-evaluate them for the sake of the larger business concerns. You can hope that the one GUI development product you pick is going to be the last one you’ll ever need, but get comfortable with the idea that at some point you may want to transition to something else – and code accordingly.
So just do it. Get it out there, make some sales, and get people to help in the process. Funding is always the issue and “chicken and egg” comes into play. You don’t do one and then the other. Getting people and improving the software need to be done gradually and simultaneously, with some changes fueling sales to get the cash to get more changes… This is another part of letting go. You’re not going to get a positive return without giving something up. You don’t need to sacrifice. You don’t need to give up your code or your clients. You don’t need to scrape up a huge amount of cash. You can partner with people, give them a little now and a small percentage of what comes later (within reason). You can find people who are smart with technology but have no business skills or experience. You can combine your strengths with others to make a greater whole.
And now comes the point where I say you should do as I say and not as I do. Yeah, I have a one-man shop where most of the bread and butter comes from the time I spend with clients. I have a small team of associates and contractors for occasional efforts but I’m still the primary developer and they are not employees. While “successful” at what I do, this is not a “larger” shop. And with an improved economy I’m now so busy at times that I can’t get out of the tree to see the forest. I haven’t had time to work on the myriad of products and consumer services I’ve created because I want to keep the hourly gigs flowing. I recognize that this isn’t the way to expand the business but getting out of the rut requires a mental leap that I haven’t yet been successful in making. I need to let go. And that’s where a Lot of us are. And that’s why I’m writing this.
Recognition of the problem is the first step in solving it. I’ll do what I can on my side. How about you?