Tiers of Development
I was going to name this article "Stages" of Development, but one of the main points is that they are tiers. Not everyone gets past the first tier. I guess instead of stages I wanted to give the impression of height (tiers), rather than a road (stages). Although, the road is a good analogy. Because development is a road.
So I’ve screwed my own article before beginning. Ha.
You can substitute Stages or Levels or any kind of describing word that measures stepping points in wherever you see "Tiers" in this article.
To begin. In this article I have put down four tiers. Each of the four can most definately be broken up into more, especially the third. But to keep them concise, four will do.
When we look at development, how do we approach it? When working on a project, where do you come in? At the beginning, or at the end? How much of the project do you get to be a part of? Development has such a far-reaching area of influence.
This is biased more towards the small developer (development house) who’s livelyhood depends on each and every one of these tiers, but working in larger groups you would still come across at least the first tier.
- The Functionality
This is where most people start. The idea breaks upon your mind like the new dawn. It is such a massively ground-breaking, earth-shattering concept that even Google themselves would quiver at your feet.
It’s also the place where most people get bogged in.
"I’ve got this awesome idea for a piece of software / hardware / tech-savvy-functionality"
I’m convinced that most people think about software companies in an upside-down way. The common belief is that when you’re building a software company, the goal is to find a neat idea that solves some problem which hasn’t been solved before, implement it, and make a fortune. We’ll call this the build-a-better-mousetrap belief. But the real goal for software companies should be converting capital into software that works. If you understand this, it’s easier to make the right strategic decisions.
The key is to understand what makes money, what the need is, and convert that into software. Being strategic often requires dumping the craziest newest funnest idea for something a little more mundane to begin with. I can’t count the number of awesome ideas I’ve had that have been (after some groaning on my part) archived for use when I’m using 100 dollar bills for tissues.
It’s more important to build an environment where Development can be fostered and grown than just coming up with a great idea and throwing a few workers at the "idea".
"How do I support this Project?" re: the Customer/Client
When you get to this stage, it’s a big change. Gone are the days/nights of coding for ten hours straight. Well, you’ll most likely be having to do them AND develop a system of Support. This is not just putting together a bit of software to manage phonecalls. We’re talking about strategy again.
How can you let the Customer/Client know that they are valuable? And that you are actually taking their concern seriously?
Then, how can you get the Customer/Client to voluntarily give praise? That is, not just on a Support Call well done, but just because everything about their dealings with you gives them joy, and they tell others about you.
The initial software query is important though. It greases up the scotsman, so to speak. The better your software, the more you can do for your Customer/Client because you are freed up from debugging why the Support Team’s phone logs are tallying wrong.
Another important point here is that of compartments. Working in a small development environment, I’ve seen that it’s very easy for the programmer, if they know enough about the System you’re supporting, to become a Level 3 Support person. They’re getting flack for not fixing bugs, while having to answer the hard support calls, while struggling to maintain any kind of job satisfaction because what they’re doing basically … sucks.
This is easier to manage (I would imagine) in a large company where your resources are more concrete and distinct. The trouble in a smaller arena is that sometimes it cannot be helped. So the key then is to manage everything.
We are getting into other areas here too! When you believe in the importance of a community when developing, then burnout becomes something to address. Job satisfaction is so very important. Especially for the guru who’s been with the company for twenty years, since the program was dos single entry old-school. But that’s for another article, another day, in another dimension perhaps.
- Marketing, Demonstrating
This is where the rubber hits that black road of business. You get this right, and BAM … guru status. Client’s are willing to pay you good money for your product. You get it wrong, and BOOM … bad press and word of mouth will kill your chances of success.
This tier is very hard to get right because it’s so far removed from coding and putting together functionality. It’s a different beast altogether. Going up in front of thirty hard-headed company execs will require becoming something else entirely.
You have to become fluent at public speaking, you need to be an engaging speaker, and someone who will get to the point without offence. You have perhaps a few spare moments to convince the person/people that what you have is better than what they have, and anything else that is out there. You will give them something unique, your product will help them in some unique way.
In my first experiences with this, on my own, I had a Freight System (logistics, Truck companies mostly) which was pretty good. Of course, that pov was coming from having not much idea at all about the competition, and having two clients. Count em. One, Two. I went through the yellowpages online, put together a quick client system that held their details, how many times I’d contacted them, how I contact them, and then got to work.
One hundred flyers (and a letter) went out. I began making phonecalls three days after. Here’s the breakdown.
1. One person rang me off their own steam.
2. Of the other ninety-nine I could actually contact, Zero were interested.
Now, 1. was an interesting experience. I travelled a couple of hours to speak with the potential client. He was a gruff, loud and cranky fellow, as are most truck-drivers turned business-men, because they have to be to get anywhere. After telling me about the last software guy who screwed him over (and who he pulled his shotgun on), I was pretty much a wreck. I had no real experience, and no real confidence.
Confidence is what makes or breaks the marketing and demo-ing. You must make the people believe in what you have. My problem was that I knew all the problems with the software, how much it couldn’t do.
2. is easy to break down. I learnt a lot about phone manner. Most people could be convinced at least to have me come and give them a demonstration. But because of my (as above mentioned) inherent confidence issues, I let them off way to easily. Persistence is important. Not being annoying, but persistent.
- Sales, Advertising
This tier joins with the previous one a lot. The purpose of tier three is to make the potential Customer/Client believe in what you have.
This tier is about getting over the line. And then pushing to the next one.
Having a robust sales strategy (business plan) is vital. Whether it’s a monthly fee, or one-off, or yearly … whatever, make sure you’ve nutted it out. Show it to people, send it to the people in the know.
Licencing is part and parcel with developing software today. You should not sell your software, but a licence to it. There is also a need to teach (graciously) the Customer/Client of the truth that just because you have a product now, doesn’t mean you aren’t going to conitnue to work on it. A one off fee might sound okay, but getting a monthly fee seems smarter to me. After all, you don’t just stop working after you’ve sold the product. Coding still goes ahead, as does Support. There are exceptions to this, no doubt. But generally speaking, it’s the way to go.
As I finish this article, it’s become more real to me that even four tiers is too simple. There is so much that could be written about development. But hopefully you have had an enjoyable read. Maybe disagreed (and commented your disagreements). Maybe laughed. Maybe cheered wildly and proclaimed Dev Dawn to be the Pinnacle of Truth. Maybe.
Puffed yet? This was a mammoth effort, particularly because most of it came off the bat.
But thankyou for reading. It is much appreciated.