Skip to content

Karma: What’s it all about?

I’ve been having a wonderful time thinking about Database Sherpa. I am grateful to have the time to develop a process that will work for all organizations. Maybe a little history would help for those new to my concept.

It started about 20 years ago when I was running my business, Hopper Business Solutions. Hopper was the embodiment of my dream to run my own business, be my own boss, and to change the way women were viewed in technology. In the beginning, Hopper provided Internet consulting to emerging businesses, but over time, turned into much more.

In addition to creating new databases, I started modifying existing databases for small businesses and nonprofits—systems created by another consultant prior to my arrival. Whenever I began a project, I always found a mixture of disgust, frustration and anger with these systems. I never enjoyed walking into a place with such negative emotions. I often heard these complaints:
  • “The consultant never listened to us and did their own thing. I don’t know why we have to capture the client’s (shoe size, favorite color, etc.). So we don’t and leave that field blank.”
  • “The reports don’t give us what we need. We fill in all the information, but the reports are missing a lot of information that is in the database. Our data is trapped.”
  • “The consultant never finished the database because we ran out of money (or worse, they stopped helping us and moved onto another project). Plus, they worked too much on what they felt was important, and not on our immediate needs.”
This litany is probably no surprise to organizations that have probably at least one such pain point with their former or current system. Let me just say this: It’s NOT just the consultant’s fault.
How can I say this? When I began working with unhappy clients, at some point they say that they had forgotten to mention something to consultant, emphasize the deadline, or take control of the project when things got out of hand. Blaming the former consultant was an easy out.
But, these are mistakes that happen. Even to the best consultant. I wondered, what could we do to make these complaints a place in the past? How can we, as consultants, pass on our knowledge and skills so that the client is now capable of doing the work needed? How can the client be put in the driver’s seat and the consultants be the guide? How can we make our clients happier—and more productive—than when we began with them?
My search for these answers lead to the birth of Database Sherpa where we have a simple value: Bring compassion and joy to our clients, all the while helping them achieve good database karma. (Thanks to DVQ Studio for that fun word combo).Yes, I said JOY. Database work can be tedious and boring. Sometimes it’s even downright frustrating. There is enough frustration in the world, and we have a strong desire to change that. So we approach every project with a positive attitude and encourage lots of laughter and fun to bring back the smile! Now, about that database karma thing, I’ll get to that in a sec….
So, what brought about this thinking about going the extra mile to bring joy into work? Well, recently I’ve been in dialogue with another consultant who has also gone down a similar path, albeit for much longer than I. She has lots of great stories and results, and she’s quite a guru who is becoming a dear friend.She feels it’s important to meet the client where they are at the time they contact her. She told me, “I want to work with clients whose missions I feel strongly about, that I want to support. It’s important that I meet the client where they are, not where I am.” She’s quite compassionate to her clients, and I am sure I can learn more from her as time goes on. And I am in complete agreement with her. We could all learn a thing or two about compassion! She makes a compelling case that makes a lot of sense to me.

We should all help those that reach out to us. Give them the guidance and tools they need so that they are more capable and empowered to drive their mission in the right direction.

But, before you run off sharing your wisdom with everyone you cross paths with, I’d like to offer a caveat. While it’s important to help organizations that to seek change, it’s also critical to make sure they align with your core values.

A key core value at Database Sherpa is to help build good database karma for organizations (I said we’d get back to that). What is this database karma and how does it work? Well, it’s not the karma from the eastern philosophies, or from the TV show, “My Name is Earl.” It’s about destiny to a small extent, but karma is more about action than anything. (And as an aside, I’d like to say there is really nothing “good” or “bad” about karma; it just is.)

Taking this concept one step further, we also believe you cannot outsource your karma. You can’t blame your karma on a long-gone consultant. Good database karma is the result of organizations investing energy to create its database and taking ownership of its long-term maintenance and evolution.

In order to bring positive database karma to organizations, it’s crucial that they be open, be willing to spend time and learn, and be capable of making their database work for them. Good database karma is not as simple as importing data from a spreadsheet. It requires being patient, practicing compassion, facing your fears and doing it “self mommy“.

So, my friend will continue to exhibit compassion for her clients, encouraging and guiding them—even after they’ve started working with her. (A workstyle I greatly admire.) Compassion can have a powerful outcome. It could change the world by making us active, rather than passive learners. (If you read my last post about compassion, you’ll see why I’m such an idealist now.) Ultimately, we desire the same outcome: To make our clients successful with their database systems and increase their knowledge.  My friend has already achieved that, achieving great success and admiration from her clients. That is a wonderful feeling and one she is very proud of.

As a Sherpa, I dream of a day when my client will outshine me and go on to do great things in the database community. I bow deeply to my new friend who has given me food for thought and opened my eyes to other possibilities.


Self Mommy… Letting Go!

Being a parent of a toddler, I sometimes find myself doing for my daughter. But, most of the time I let her do it herself. As she likes to say, “self mommy”, which translates to, “I got this mom”. I’m encouraging her to be an independent being. One who feels like she can take on anything that life throws at her. While it’s difficult to watch her struggle, fail or succeed without me, I know it’s necessary. Even at the tender age of three. She needs to learn to do it “self mommy”.

The other day, after receiving an email from a Database Sherpa client asking a very specific question: “How do I find the IP address for a user?” I found myself typing a very specific answer “Click on this… then do this… and then you’ll see the IP address. You can do this when you find it and then ask them to try again… blah, blah, blah…” Then, my daughter popped in my head saying “self mommy”. I realized, in that moment, I was enabling bad behavior. Reliance on me! I needed to help the client, no doubt, but I didn’t need to spoon feed the answer (like I don’t need to put on my daughter’s shoes for her). I saved my draft and began composing another email which loosely said something like: Think about it like this, where can you find the information about each user in the database? So, my long winded email, that would have been printed out and followed like any directions, turned into a single question. Like when my daughter asks me which foot a shoe goes on, I ask her “is that the left or right shoe?” Knowing that might lead her down the right path. That was my hope with the question I composed.

I know that such emails can be frustrating to the receiver, so I also wrote “I’d like you to be able to figure this out yourself because it will give you the skills you need, long term, to answer these types of questions without me. I know you can do this as you’ve been so good at finding things and figuring this out with such little guidance on my part. You have the ability, just take your time and look at all the places it could be. It will be clear then. If you’re still struggling, shoot me an email and I’ll give you another hint.” I had already thought of my next hint too (just like I do with my daughter).

No response. A few days passed, still no response.

I found myself having serious doubts…

What if she’s po’ed at me for keeping the answer from her? Really, this was an easy question. Maybe I should have just told her how to do it! Dang, sometimes our brain can be quite a nasty creature.

Then, in the back of my head, I hear my daughter saying “self mommy”. I listened to the doubts and said back, “let’s see what happens. I can always explain to the client what I was attempting. I like to let things play out and learn from them later.” My doubts listened and I blew them away during my meditation.

Our call came about two weeks later, I was doing a lot of doubt blowing! On our call, she started with explaining why she’d asked about the IP address. She had a user that couldn’t access the database and she thought it was because the system wasn’t recognizing his computer’s IP address. Anyway, she had gotten my email and decided to put it aside for a few days and enjoy some vacation time. When she got back to it, she thought about it and decided to try a few things. While in the database system, she found herself in the user section. So, on a whim, she clicked on his name and sure enough, she found out his IP address. And, in the process, also learned it wasn’t the IP address, but rather a wrong password he was typing. Once she realized that, she reset his password and he was in the database in no time.

As she recounted her ordeal, I listened to her and realized that she was happy…not upset, HAPPY. She had figured it out. She had done it “self mommy”. After our call, I digested what had happened and what I learned.

So, my learnings are that (1) even if I think I can help with a simple email, it may not. That’s okay; (2) it’s important to give the client challenges along the way. It’s not about spoon feeding, but it’s also a fine balance. Sometimes I might need to spoon feed. It’s about compassion.; (3) I like to help others, I like to see them succeed, but I also have doubts about Database Sherpa; (4) this was as much work as giving her the answer.

Then, when thinking about the client, I realized she learned much as well. That: (1) it’s good to take a break, walk away and come back with a new perspective; (2) her original reasoning was incorrect, it wasn’t the IP address; (3) resetting the password for a user is easy; (4) she figure things out herself, without me!

Look, as a Sherpa, I want to continue to grow and learn. All of my clients do as well. This was a win-win situation.

Well, except for my doubts. They were not so happy, but they will return and try again… they always do 🙂

So, just like when I watch my daughter dress herself, I felt joy and heartache at the same time. Joy that my client is growing and learning without me and heartache that they will need me less and less. I’ve grown to really enjoy our talks together and one day, I know the talks will cease and they will not need me anymore. But, that’s a post for another date!

Letting go is never easy. Frankly, it’s one of the most challenging thing in the world, but it feels good. Knowing that I was some small part of the learning and the growing. It gives me great joy. It’s what compassion is all about!

Bold Goals for Database Sherpa

As I mentioned before, I’ve been working with a great marketing firms, DVQ Studio. The company is run by two amazing women, Emily and Gretchen. Brilliant and nice.. combinations I admire.

Anyway, the process started with a lot of questions and note taking. It forced me to think about the future of Database Sherpa. This was interesting, because I’ve been really taking it one day at a time. I don’t like to think too far ahead because I tend to get distracted by the big pictures and move to that before I’m ready.

But, I know that thinking about the future is important. It keeps the momentum moving forward. But, I need to focus on the here and now. So, while those big dreams about the future of Database Sherpa are buried in Emily and Gretchen’s notes, I wanted to share some of my current bold dreams:

  • Bringing joy and compassion to database development.
  • Blending yogic and Buddhist principles into consulting.
  • Bringing in another Sherpa.
To make these dreams happen, I need to get busy. Soon, you will be seeing my newly transformed web site and materials that outline how joy and compassion can be brought into database development.
Secondly, I’ll be documenting the practice of being a Database Sherpa. My advisor, Veronica, will be helping me along the way.
Finally, by the end of the year, one Sherpa project will be lead by Veronica to refine the process and documentation.
This is a very exciting time! There is much change in the horizon, but change that will come with compassion and love.
I can’t wait to share this with you all as things are completed. So, until that time, I wish you peace, joy and love.

Facing fear… fighting back

I have always been a very cautious and practical person. It’s not my nature to run into things full bore without having a plan in place. I always looked at this as being fearful. Fear of failure.

During yoga, I find myself coming back to that feeling. Fear of failure. So, I try that handstand, but I can’t get up. It’s not so much what others think of me, but what I think of myself. I can get into that self-loathing place quickly. That fear keeps me from trying or pushing myself forward.

Then, the question becomes: How can I ask my Sherpa clients to be fearless if I cannot do it myself? That’s a really good question. What can I do to face my fears? Another good question. One way I have faced my fears is to fully embrace the Database Sherpa model, to the point of being a little nutty about it (if you meet me, be prepared to hear about it!). Another thing I’ve done is to hire a company — DVQ Studio — to help me brand and develop the model (more will be unveiled as it is developed). Finally, my good friend, Veronica Waters, is now an advisor to this work. So, I’ve put my reputation, money and friendship on the line.Why? Because, I’m not going to hide from my fear anymore, I’m facing it head on! Is the fear gone? No! I see it from time to time, visiting me again and again. I let it sit for a bit and then blow it away. Goodbye for now, I’m sure you’ll be back!

This way of fighting back is a process, but one that will better equip me to help the Sherpa clients fight their fears. And it’s already working on changing me and how I work with my Sherpa clients. The most current Sherpa project brought me to the place of learning about resources available to use after the project ends. This particular client was given specific work to accomplish using the Google Group, to find answers to very specific questions. They were tentative and fearful at first, but I explained that I only wanted them to look and find. So, with that knowledge, they faced their fear of the unknown.

After visiting the Google Group and finding the answers, they looked around further (you know how that happens when you are searching on the Internet). What they got was so much more than mere answers to questions (which had been my hope). At one point in our conversation one of them voiced, “I could even answer some questions.” My immediate response was, “go ahead and respond next time; see what happens.” She giggled with delight at that suggestion and said, “oh, now I get it – I can get involved and help too. They need me and my time as well.” Now, she faced her fear, saw what she could do and now feels empowered to do something about it. WOW, that was pretty awesome.

With the support of my good friends at DVQ Studio and my special advisor, Veronica Waters, my confidence level has been given a boost and I feel like a better Sherpa.

Who knows what will come next?!

Practicing Compassion

Being a database consultant has given me the opportunity to see organizational change up close. Change can be very difficult for the individual, which, in turn, can greatly impact the organization. I’ve been advocating for a fundamental change in consulting that will incorporate yoga principles with database development. As I’ve mentioned in previous posts, I intend to share my thoughts on how this weaving might work best.

Most recently, in my yoga class, my mind wandered (what else is new) and I realize that if someone took a snapshot of our room during a specific pose, it would look like a picture of my ballet recital when I was three years old. We’d all be expressing the pose in our own way. That’s the beauty of the practice of yoga. Expressing your uniqueness is not wrong, it’s beautiful. Why? Because each person is in their own place in their practice. But, we all come together. Work together. Support each other. How wonderful and spectacular.

My dream is we could see this about database development as well. Your organizational readiness for a database is not necessarily going to be the same as another organizations. Just because you hear that an organization is using a donor database or, doesn’t mean the database will work for you. Heck, a DATABASE might not work for you at all… (oops, did I say that?!) Okay, I’ll say it again:

no database

Isn’t there a saying:

“you are perfect just the way you are”

Maybe, just maybe, there is a case for keeping your systems the way they are, no change. In my experience, before you jump into the pool with everyone else, ask yourself these two simple questions:

  • Will this database be created because I need to measure or do something required by someone else? For example, if you find that your main reason for creating the database is because a funder has asked you to report on a specific data point regarding your clients, then it is the outside force that is driving the decision to create the database. It might be just as easy to modify an existing spreadsheet to collect those data points rather creating a database which is being driven because of this funder (an outside force). Outside forces drive the decision.
  • Will this database be used to track specific requirements to help with making decisions about my organization or help me with the operations of the organization? For example, your organization is trying to make a strategic decision about the individuals whom you serve. Your existing system of collecting data doesn’t provide the information needed to make these key decisions that will drive programming and volunteer needs. Decisions come from within.

Do you see the key here? It has to do with whether the decision is coming from inside or outside. It’s much better to allow systems to grow organically, through critical thinking and decision making. Growing from the inside and making decisions based on actual need will make for the best systems – those that are embraced by everyone in the organization. These systems will succeed and thrive.

If you see an organization with a database (donor, client management, etc.), don’t presume that you need one too (remember, those outside forces?!). Like, when I look my neighbor who can get into a headstand in the middle of the room. I look in admiration at the skill and ability of this yogi. I don’t attempt to do a headstand in the middle of the room (okay, maybe I do, once, but then never again…). Seriously, the outside force doesn’t get me to do the headstand, instead, it was my body telling me “I’m ready”. You’ve got to be willing to listen to your organization to hear “I’m ready” — because my decisions are coming from within.

Don’t look at your peers who have a highly functional database with jealousy. Realize that they worked hard to get there. Appreciate where they came from and where they are now. Look at them with admiration and love! Yes, with LOVE, this is the compassionate sector, right?!

Change your organization from the inside with love, appreciation and admiration for yourself and your peer organizations. That’s the only true way change can be embraced in your organization.

Being in the Cloud.. You can take it with you!

This post is really musings… ramblings… please bear with me on this, it might make sense in the end.

Just the other day I had a wonderful conversation with a new client who left the workforce after her kids were born, just during the cusp of mainframe transitioning to the client server model (she’s a fellow techie. YAHOO, another female techie!!). Now, her kids have grown up (the youngest heading to college) and she looks across the IT vast land and sees something very similar to what she left.

The reality is, the cloud technology embraces both the mainframe model (centralization) and the client server model (de-centralization). It reminds me of the harmony between the muscular energy and organic energy in yoga. The balance between them makes a pose feel wonderful! Just like I’ve fallen in love with yoga, I’m falling back in love with technology. In particular, databases. So much more than Access or FileMaker Pro. It’s just wonderful!

So, as she and I were discussing the topic, an analogy came to me as we discussed the multi-tenant model of (she was quite concerned about her data being mixed up with others AND security, remember, she comes from a very centralized place) So, I had her visualize an empty condo. The rooms are all laid out: outlets, cable hook up, washer and dryer hook ups, water, etc. The layout is all there for you. Now, all you need to do is add your furniture (data) and maybe a little design (paint on the walls, rearrange things slightly), but the basic floor plans remains. The condo association maintains the building, all you do is live in your space and call when there are problems (help desk or forums). You have your own secure space with a key and lock (password and encryption). You’re able to rearrange as you want and you can even change some fundamentals if you get condo association approval (adding your own code to customize and build out Salesforce). Then, when you want to move, you pack up your furniture (keep in mind, the paint stays on the wall, it’s temporary anyway, as does any build out) and you find a new condo (like moving from to another cloud based or maybe internal database). It’s like that with Yes, you can take your data with you! You’re not stuck with them forever. Can you imagine? Changing software systems that simply? Yes, it takes time to get things in order, but hey, you are not beholden to any one company! What a wonderful and freeing feeling.

So, what we have now, is the ability to do our work using the best of all worlds. The client server model (yes, I can download my data, work off my servers at the office, etc) AND the mainframe model (having access to super fast machines, centralizing the hardware maintenance for the heavy lifting, etc). And, the cherry on top is that we can MOVE SYSTEMS. I can take my data anywhere I want. This is just wonderful and feeds my yogic mentality.

NOTE:  I have another post coming about moving from Google Apps to another Google Apps (different domain name) and the process that took. It was not easy, but it was do-able.

Patience is critical to learning and teaching!

Recently, I had breakfast with a good friend, mentor and supporter. While we were chatting about politics, the state of our economy and other light topics (HA!), we brushed up on her organization’s implementation (they were in my first cohort). They’ve lived with this system for about 18 months and it’s been serving their needs. During this time, my friend (who happens to be the executive director) has had a few ah-ha’s that I think are very relevant and important to share:

  • Don’t throw the database out with the bathwater! It’s really true. She recounted an example where the database did not have a specific field. During the designing phase, they were capturing the work done by the volunteer, hours and client served. No volunteer name was captured. What they learned, as the system was put into the flow of the business, is that the volunteers wanted follow up with clients but the staff couldn’t find volunteers since the names were not put in the database. She laughed and said, “before, I would have said let’s throw this database away. It is poorly designed!” But now, she realizes that THEY CAN FIX IT. They are empowered by being able to make the changes on their own. There is power with this sense of freedom and realization that systems are made to be flexible and fluid. Organic!
  • Reporting is more than just numbers. She laughed as she told me about their reporting mechanism. Someone would send a request to the system administrator who would create the report. Pretty simple, but what they realized is that they were not providing her a good definition of their needs. What they saw were that the numbers looked wrong in the reports. Now, they knew the data was entered correctly. So, as they dug deeper, they realized that it’s not simply pulling numbers from the system but really understanding the basic underlying structure of the database. Here is an example of what I’m talking about: getting a list of active clients should be easy, right? It’s just a list of all the contacts in the database, right? But, when the requestor is given the list of “active” clients, he/she realizes there are some “inactive” clients in the list. And, as they dig into the system to understand why the “inactive”clients show up, they realize that the definition of “active” client was not properly given to the system administrator. So, what would have been better is the following: I need a list of contacts that have had activity in the last 12 months. This gives the system administrator the ability to pull the data appropriately from the system. But, here is the thing, if the requestor doesn’t understand how the system was built, they cannot even begin to know what to request. Since this organization created their database, their understanding is much deeper. The requestor and the system administrator can have a conversation in data lingo and understand each other. It’s wonderful and amazing to see this growth and learning.

As she recounted these stories, I could feel myself swell with pride for this organization. I am so very proud of how far they have come with their education. The education that they have given themselves is more than I could have ever hoped for… it’s simply amazing what they have managed to do themselves. It goes to show, if you give individuals the education they need and crave, they will surprise you.

This organization has come such a long way in their understanding. and it happened on their terms and in their time. That is the beauty of teaching database development in this way, it teaches you patience, persistence and focus. Through this comes knowledge and through that will come wisdom.

It’s a privilege and honor to be given the opportunity to teach and learn beside these individuals. It’s very humbling.

Database Principles — do they always apply?

During my yoga practice I try to keep an open mind. Being willing to throw out my traditional learning and try something new. Call it experimentation or being flexible or open minded. My database education began at Michigan State University (Go State!) and learning about relational database design (very traditional). Let’s just say that there are very specific principles to follow (normalization, uniqueness, keys, domains, etc.). This is my traditional learning. Something engrained in my psyche. Seriously .. engrained! But, hang on, this isn’t about database principles! I want to discuss the importance of these principles and understanding them for the nonprofit organizations that I’ve been teaching. Could it be that some of these principles don’t make sense for the needs of some organizations?

I tend to find myself wandering to the normalization portion of the principles because I find it much more challenging to explain to others. Just as with yoga, we tend to focus on the poses (exercise) although yoga’s basic principles are much more. Maybe it’s because the results are immediately. Anyway, it’s only natural to gravitate to something.

That being said, please bear with my fixation on normalization and listen to this musing… maybe there are times when normalization just doesn’t makes sense. What do you think? Could this be true?

Thinking about this further, I have found the platform quite solidly built. A system built with all the database principles. Organizations build on top of this solid system. So, maybe the rules don’t matter. That being said, what is the big deal if they end up with three fields that say something like: Child 1, Child 2 and Child 3? Do they really need to normalize by creating a separate related table to hold each child’s name? I guess the question is, are they okay with recording only up to three children? What if they need more? Are we stuck? Actually, with it’s not a problem. We just create another field. Yes, it’s really that simple…. I would ask more questions, but I do think my purist mindset has shifted! I still struggle with this shift. My mind wants to go back to normalizing since it’s my nature. But, the shift has begun as I now question myself when I start to normalize.

Another principle I’ve seen in action is related to duplicated data (uniqueness). I’ve seen some individuals at organization completely freak out about duplicated data, and that is good. This principle has been fully embraced, but I have been wondering about this principle too. Maybe we need a shift here too.

For example, what if we already have a contact in the database with their work information but we also interact with this individual at their house? The reality is that we have two separate communications to them. We want to snail mail to their house AND work with different information (think board member vs donor). So… maybe it makes sense to put their information into the database (dare I say it) TWICE. So, we duplicate their data…. BUT, the data isn’t really duplicated. This person is really TWO DIFFERENT PEOPLE (well, not really, they wear two different hats, but you get the picture). But, we want to know that they are the same person. How to do that? Well,’s Nonprofit Starter Pack offers something called Relationships. So, you can create relationships between two contacts. There, all better, right?! What do you think?

So, it’s really not important to always normalize or de-dupe your data. It is important to understand the impact of your decision. In other words, how will I be able to report this information? Does this mean more updates of data? What do I need to do to import my data? Do I need to do anything special to my data to make this work?

Please note, I’m not suggesting we throw away our principles. Of course, we are building on top of a very well constructed database. One that is following the rules. I only suggest that while I try to blend my yoga and database education, maybe it makes sense to change the view a bit and rather than labeling something as a wrong, we just look at it again and see if it’s truly bad or will it fit the users’ requirements and make it easier for them to continue on their learning path.

So, with a yogi’s open mind, I welcome all discussion on this topic of database design. I am very interested in hearing from everyone and anyone on this as my learning will expand with your input and viewpoints.

Beginning again…

Being a yogi, we learn that we are constantly beginning again, thus, I begin again this blog. My musing will be focused on databases, yoga, women in technology and general thoughts about society.

So… with that, I bring you my first post for the year and hope to post on a regular basis (note, I didn’t give a time frame here, so I don’t box myself in…. ah the beauty of yoga).

Our lives have taken a sharp turn, and it’s wonderful. A new being in our lives fills us with joy and much work. I’ve decided to begin a new chapter as full-time parent and part-time database consultant. As you might know, my focus has been with and working primarily with nonprofit organizations. My goal is to teach rather than do the work for the organization, thus building the organization’s capacity to continue to maintain and manage their own database. I would say that mostly it has been a success, by mostly I mean that sometimes I find myself going back to the place of “doing the work” rather than “teaching how to do” primarily because it’s easier for me and the person doing the work at the organization. I do catch myself, which is good, and put it back on them to finish it up.

It’s been at least two years since I have begun this work and there are a few things that keep popping up to me over and over again. These are some of those issues/things that have come up:

  1. Turn over of staff: This has probably been the most challenging issue to deal with in this teaching model. I have been of the mindset of teaching two staff at the organization (thus one is a back up for the other), but have found on a couple occasions that both individuals leave the organization, leaving a gaping hole! I’ve had one organization actually say to me that they wished I had built it for them and then they could just have come back to me. Oh well, I guess the point is that 2 in 20 isn’t bad. But turn over is an issue that I need to address somehow…. I’m still mulling this over. I’ll get back to you later on this one, but I’m open to any suggestions you might have.
  2. Understanding process: On more than one occasion, I have asked someone who works at the organization how they manage a process (whether it be intake of clients or managing events or accepting donations) and I get this blank stare and sigh. For example, when asking the person who manages events, “how do you do it?” I get the big sigh and then a stream of consciousness on how they do it. Nothing solid, a lot of ums, ahs and such. There process is called “by the seat of their pants”. This is always a sign of problems for success with a database, BUT, there is always a solution. When this happens, I usually have them diagram the process for me (usually a handwritten flow chart or steps) with a detailed explanation (where I can asks tons of questions). This does get us closer to understanding their “stream of babble”. And, in the process, they are helping their organization to document and clarify processes. I love this part of the design phase! It’s so… so… neat and tidy. I think database people like neat and tidy (although we often get curve balls, but that’s another story for another day).
  3. Focus: In this education model, I’ve found that many individuals wander into other territories. What started out as a volunteer database ends up being a volunteer, donor and client management database. Which isn’t a bad thing, in the long run, but NOT TO START. It’s important to focus in the beginning because of the learning and doing process. Since I am a yogi, this is an important learning for me and for my friends learning with me. I always try to bring them back to the focus and remind them that the other pieces will be waiting along the sides. But, to stay focused on this for now… until you are ready to move on. And, you’ll know when that time has come. But, during this beginning phase, focus.
  4. Time: As a young yogi, I always believe there is more time, but I forget about roadblocks that might come up (such as other work, a special event, illness, etc.) thus I ALWAYS underestimate the time it takes to get through the beginning stages of learning. I am learning. I am getting better at this. After all, it’s not a perfect science and we all (come on, you know you do this too) guesstimate the time.

So, these are some of the key things I have learned since beginning this journey in combining my yoga practice with database development. I am so excited to continue this path and hope you will join me on my journey!