How We Taught Our Children the Value of Money

How We Taught Our Children the Value of Money

It used to be when our three children were all under the age of 10 we gave them an allowance based on their age and ability to perform certain household tasks. It was meant as a way for them to understand the value of earning and saving money and paying for things out of their own pocket.

What we soon realized was they needed another way to have a more positive relationship with money. And I do mean relationship. If my husband and I taught them anything it is that money, while inanimate, can have a positive or negative effect on how you live your life.

The first thing we did was stop giving them an allowance from our own pocket. We cut that cold turkey. First of all, what did that teach them? That we were their bosses? That taking out the trash and doing regular household chores has a dollar value? As a mom I don’t get paid for cooking and cleaning, why should they?

So the next thing we did was help them find ways to earn their own money based on their age and level of responsibility.

My 12-year-old was able to find babysitting jobs immediately. Fortunately we live in a neighborhood full of young families. My daughter’s reputation grew and soon she was babysitting for five families. She was making much more than the weekly allowance we used to give her. She was also discovering her earning potential and felt proud that she was doing something her friends we not, creating a little business for herself and watching her bank account go up and to the right.

Our two younger children were always begging me to get a puppy. I always said “No” to that request because I knew I’d become the main caregiver. One day I realized that if I kept saying “No”, they would miss out on a great experience. So it was during this time that we all came up with the idea to create a neighborhood pet sitting service. Not only did we have a neighborhood of young families, but it was also a neighborhood with lots of pets.

At the time my two youngest were seven and 10. That may seem young, so I was very involved at the beginning and supervised most of their jobs for the first few years. We developed marketing tools, balance sheets, client forms and even business cards. We learned through some mistakes what to do better the next time. For instance always carry the house key on a lanyard around your neck so you don’t accidentally leave it in the neighbor’s house and lock the door behind you. That was our most costly mistake because we had to break a back window (and pay for it) to get back in.

Their experience taking care of pets taught them to be responsible and they learned how much they really wanted a dog of their own. So when they earned enough money they were so proud and excited to get a Golden Retriever puppy. All three of them chipped in with their hard earned money. They even paid for the veterinary bills and the food!

My children are now 13, 16 and 19. They all have a great relationship with money. They have learned that they can create their own small business doing the things they love and make money in the process. They save a lot, spend a little, and we also make sure they donate to a good cause once a year. My eldest has saved up enough money to pay for her first year of college. That would never have happened had we continued giving them an allowance.

Start small. Jot down some hobbies that can be turned into a small business. Consider tutoring, babysitting, petsitting and mowing lawns.

Systems Engineering in the Entrepreneurial Space Industry

Systems Engineering in the Entrepreneurial Space Industry

If any of you have ever worked in a “garage works” type aerospace startup (and I hope you have because it’s an eye-opening experience!) you will have been exposed to a staple of entrepreneurial, rapid engineering development which I like to call “design by email”. Small groups of smart minds generally don’t like being slowed down in expressing their creativity by formal design processes – and neither should they. One of the key reasons that entrepreneurial aerospace has gotten a leg up on the establishment is this ability for nimble, creative, and rapid development. The company culture within these small and highly productive aerospace companies – who have now become the new hope of the Obama space policy initiative – prides itself on getting things done quickly and at lower cost than the establishment ever could. In the entrepreneurial mindset, the term “system engineering” is a dirty word; it describes a way of doing things that is overly burdened by formal processes; dominated by endless meetings with configuration control committees, attended by suits who blabber on about “six sigma this” and “house of quality that” and wouldn’t know lefty-loosy/righty-tighty if you shoved a screwdriver right up their collective you-know-whats.

It’s fun being the underdog, and cultivating this in-your-face attitude of showing the big boys how to do it right makes your work that much more enjoyable. However, as a startup becomes increasingly successful and grows the size of its technology team, this approach will start to show its limitations. Engineers who get 100+ emails a day will read the ones important to them, which aren’t necessarily those important to overall project success. Even worse, as there is no centralized technical interface for your customer to interact with, the technical team gets increasingly bombarded with requests for information by the customer, slowing them down in their important design work and often returning inconsistent messages (“yes, our payload interface can deal with a 5% increase in payload mass” vs. “current vehicle performance projections will allow for a 3% growth in payload”). Once an aerospace organization reaches this point, a critical transition is about to take place. The challenge is to overcome the existing bias against systems engineering (there’s that dirty word again), and introduce an effective yet lightweight set of processes, which will meet the team’s needs without killing that innovative edge and agility that has served them so well to get here in the first place.

The first step in that process is to clearly identify the problems faced by the team on a daily basis, and make it clear how judicially implemented systems engineering could improve the situation. The term “systems engineering” can mean very different things to different people. For a small startup trying to overcome the growing pains of transitioning to the mainstream, systems engineering generally has two dominant functions: (1) aligning the work across all contributors in the technical team, and (2) successfully capturing and communicating customer input. Once you’ve succeeded in bringing an understanding to the team that systems engineering will reduce their overhead burden and let them get back to what they like best (focusing on technical development), the battle is pretty much won. From here on, you just have to deliver on that promise, and focus your implementation of systems engineering tools and practices very precisely on their specific identified needs.

So let’s talk specifics then; implementing some new systems engineering process usually implies introducing a specialized tool – while “systems engineering by spreadsheet” is possible, it won’t get you much further than “design by email”. In a small startup where cost is an issue and technical team members are quickly turned off by “enterprise level” solutions, I look first and foremost to Free Open Source Software (FOSS) solutions. Not only is the cost and time to implementation attractive, but any aerospace engineer agile enough to thrive in an entrepreneurial startup will have enough IT skills to tweak the code until the it works exactly the way you want. The first function your team will ache for is distributed / configuration controlled file access. When you work with a team of eccentric individualists, who put in hours at any time day or night and at any location from private boats to coffee shops, a web based document management system is pretty much your only choice. Rather than going with Microsoft’s behemoth (and expensive) Sharepoint services, consider excellent free offerings like Owl Intranet Knowledgebase (http://owl.anytimecomm.com/). No VPN needed, but SSL security and unlimited growth with a minimal Linux based server hardware are strong selling points.

To achieve the functions of “team alignment” and “customer input capture” you’ll need a requirements management tool. When choosing your tool, the most important rule is to select a tool that accommodates how you want to work, not a tool that forces you to accommodate how it works. Aerospace industry mainstays such as IBM’s Rational DOORS software are not only ridiculously expensive, but have evolved over many years to cater to their largest clients – using exactly the kind of overly formal practices you are trying to avoid. Instead, consider web interface driven tools which evolved from the people who know software best (the software development industry). Jama Software’s Contour tool (http://www.jamasoftware.com/) is my first choice, exceptionally capable at enabling a team of engineers to stay in synch, while also giving your customer real-time insight into how their input drives your efforts. It acts as the direly needed inbox-filter for teams suffering from “design by email” without placing any extra levels of bureaucracy between the technical team and the result of their labor. In addition, it is highly flexible to your way of doing things, and all but guarantees that no customer input will ever fall through the cracks again.

Having made the transition from “garage-works” to “company” a couple of times myself, I’ve learned that the biggest success factor is acceptance by the technical team. Choosing your tools carefully, and implementing systems engineering practices in a sparse incremental fashion will make all the difference between project success vs. open revolt and subsequent mission failure.