Isn’t it just data?

There is a prevalence of news on “big data”. Almost every day, there is another story about how you can benefit from it. Despite all this, most people do not understand what “big data” means. This has resulted in my complete dislike for this term. Businesses have business questions and data. As businesses grow, they collect more data and the business questions change. This means that different methods are used for storing and managing the data; extracting and cleansing the data; and then analyzing and delivering the  results. Does it really matter if it’s “big?”

“Big data” is often defined by large volume, high velocity and wide variety. There’s no doubt that the increases in volume, velocity and variety of data has introduced new technologies and methodologies. These are not right for all businesses in all circumstances. In order to make the right choice, It is very important for businesses to understand:

  • how much data they have?
  • how quickly their data grows?
  • how much data variety exists?
  • what business questions are they trying to answer?

Once businesses have an understanding of what they have and what they want to accomplish, they can then start focusing on the tools and methodologies for leveraging what they have to get to what they need. Another consideration at this time is determining whether the tools that fit best for today are short term solutions, or whether they will grow with the business as the business needs change.

While I believe that “big data” is an overused term that many don’t really understand, I am a big supporter of businesses becoming more data driven. In order for this to be a success, businesses will need to know what they have, where they are going and what they are looking for. They will also want to evaluate the abundance of data storage, extraction, cleansing and analysis tools to determine which work best for them.

3 Hallmarks of Customer Service

I read a blog recently that discussed exceeding customer expectations in an e-commerce context. This got me thinking about customer expectations in the broader business sense. Customer service has been a huge part of my business education from my own family’s businesses as well as other successful small businesses I’ve been a part of. I do think there are a few variances to how you should exceed customer expectations in a business to business (b2b) environment as compared to business to consumer (b2c).

The most critical components of delivering exceptional customer service in a consulting environment are trust, honesty, and communication. While these all 3 go hand in hand, each should be considered a separate initiative you need to foster as your relationship develops over time.

Trust

Consulting, like many other types of b2b businesses, is built on trust. Your customers are trusting you as experts or supplemental resources. They are often sharing the most basic aspects of their business with you so you can provide a service. The entire sales, implementation and customer success experience is about building that trust. If you do something to cause that trust to be questioned, every decision you make comes into question. This ultimately challenges who the customer buyer is and what they believe.

Lack of honesty or poor communication are two ways that you can quickly and easily deplete that trust.

Honesty

I think we all know how important it is to be honest. Unfortunately, sticky business situations can often challenge our abilities. For example, the situation where you are the “expert” but don’t know the answer to the question; or where you were unable to complete one set of customer work because you were too busy with another. I have found that your best option is still to be as honest as you can. In the first example, you can say “I don’t know, but let me know find out for you.” This is generally an acceptable response. Customers tend to appreciate this more than making something up, then having decisions made based on incorrect information. It takes less effort to wait to make decisions until after you have the information than it does to have to make corrections later on.

In the latter example, it was regrettable for you to have gotten to this question at all. Ideally, you would have clearly articulated what you were going to accomplish and when, setting very clear expectations. This might have involved a discussion around urgent versus minor issues with respective response times. Depending on the customer relationship, this may have also included a more detailed discussion around your prioritization model (don’t have one, see defining your customer prioritization model).

Communication

Almost every misunderstanding comes from poor communication. This might be lack of communication or poorly articulated communication. It doesn’t matter as these are equally bad. Communication is how you are show your honesty to your customers and how you build that trust. It comes in many forms – from quick social media engagements to project engagement emails, to marketing sales contact and training materials. Your honest voice must carry through every piece of communication, in order to build and maintain trust.

Project Coordination vs. Project Management

For as long as I can remember, I have described myself as a project manager. I found it was the simplest way to explain what I did. In reality, I have been a Sybase database administrator (DBA), systems analyst, software team lead, business process manager, implementation manager and most recently, a customer success manager. At the end of the day, I get s**t done. I found that the term “project manager” was the simplest way for people to grasp what I do.

I have started to wonder whether I’m using the right term. As I compare my methodology to how others are managing projects, I wonder if “project manager” may not be inclusive enough. Additionally, the response I get from resources involved in my projects often is one of pleasant surprise. Their prior experiences or preconceived notions of what a “project manager” is has left them jaded and unimpressed.

A few years back I was brought into an organization by a mentor and former boss to help alleviate his workload so he could focus on raising money for the organization. Prior to my entrance into the organization, everyone did everything for their customers. There were no project managers. This resulted in project delays and the curse of constantly switching gears to focus on the biggest fire. At first there was subtle push back and doubt as to what value I was bringing to the table. Out of necessity and as a result of the influence of my mentor, the project resources started engaging me on the basics – timelines, status, meetings, etc. As I got more involved and took on more responsibility (i.e. owning the documentation, managing the communication, pursuing the missing information) those same resources started to come around to me as a “project manager.” I believe they view me as the exception rather than the rule.

More recently, I overheard a conversation regarding a project where technical resources were responsible for writing status reports and updating the project team. This very much confused me as I have always felt that this function was a core responsibility of the project manager. After probing a bit, I learned that the project manager did not understand the technical solution and therefore was unable to provide descriptive enough project statuses. I understand that the project manager is in an oversight role and will rarely understand every detail of how a technical resource plans to implement, but I don’t understand how they are going to oversee every piece of the project if they don’t understand individual components.

These are just 2 anecdotes that make me ponder whether I misunderstand what a project manager is or incorrectly associate this term to what I do. A good project manager requires equal parts operational understanding, technical skill and project coordination.

PM

Operational Understanding: To manage a project effectively, it is imperative to understand how that project fits into the big picture.

  • How does it impact the business unit?
  • What motivates the project owner?
  • How will it impact the project stakeholders?

If I don’t understand that the goal of the project is to significantly reduce costs or improve efficiencies in order to prevent layoffs, I may not see or understand the anxiety of the stakeholders or the project owner. I may also not know the right way to motivate the team or get to the root cause of disagreements.

Technical Skill: Furthermore, it is crucial to have an active part in the technical conversation.

  • How do you step in to test or troubleshoot?
  • How do you mitigate disagreements between technical resources?
  • How do you translate between technical resources and the business owners?

Technical skill allows me to get my hands dirty when required. It is the reason that I can play “cardboard batman” to work through complicated project issues. It also allows me to step in and mitigate disagreements between technical resources, and pursuasively communicate decision “whys.”

Project Coordination: Lastly, it is critical to know what goes into running a project.

  • How do you estimate a project task?
  • How do you allocate resources and make sure milestones are met?

This is the nitty gritty of running the project. It’s the logistics – status meetings and reports, milestones and gantt charts, task estimation, etc. These are the basics you need to know. Unfortunately it is not enough to make sure project successful. Only by combining the basics of project coordination with technical skill and operational understanding can you truly get s**t done.

Is it bad to be smart?

I started writing this blog post about a year go. At the time, I had just come across a blog that introduced the idea that in business it is bad to be described as smart (In business, it’s actually a bad thing to be called smart). The author differentiated that it wasn’t about just being smart, but “being smart as your primary value.”  His premise was that people who were smart or talented as a primary value tend to get exploited more than anything else. “To call someone smart implies their other skills don’t measure up and, in business, people want solutions that work and productive relationships, neither of which require intelligence. What people usually describe as intelligence is what I call abstract problem solving.”

At first I was a little taken aback by this notion.  In general, I highly regard intelligence.  I have surrounded myself with smart people.  Not all of these people could be considered rocket scientists (although that applies to some), but they have intelligence across many different facets of life and have proven that time and time again. After I thought about it some more, I do get the point the author was trying to make. Being smart is just not enough. If someone is solely smart, they are marginalized to only the tasks that keep him/her in a bubble. Generally, we don’t want to interact with someone who can’t interact with us in return.

A good friend from graduate school coined the term “stupid smart” for people who were too smart for their own good. It describes people with high intelligence, but not enough common sense or other redeeming qualities. We often used this phrase to define personal decisions where we had overthought; missing a fairly simple ,often better solution.

At the end of the day, I want to be seen as someone who gets the job done well. This may mean solely managing it day to day, or getting my hands dirty to delivery. My passion lies in solving complex business problems leveraging different technologies. While that might make me smart, I do think there are adjectives I would rather see used to describe me first.

 

Defining Project or Customer Prioritization Models

I’ve come to appreciate the difficulty of project prioritization.  Historically, my teams only ever really had internal customers.  In some ways that makes the decision easy – you focus on the biggest revenue opportunities or impacts first.  Operational issues came first, with development coming second.  This problem becomes exasperated when you are in a consulting situation where there are multiple customers, with multiple customer teams and often, conflicting priorities.

At the end of the day, people want to do the right thing.  Ultimately what happens when you combine a lack of project prioritization with people who are striving to “do right by the customer” is time spent on non-priority tasks or employee burnout trying to meet everyone’s needs.  Neither one of these outcomes is optimal for teams.

In our personal lives, we make prioritization decisions everyday. Most often we put things we need to do (i.e. eat, take care of children, work to support family) before other things (i.e. sleep, exercise). This may not be the best long-term decision, but it is the best decision we can make at the time it comes up. The nature of business complicates this problem significantly as ever customer needs to be treated with respect. Each customers’ problems are the most important to them. If every organization had infinite resources, dedicated teams could exist to service each customer.

Unfortunately, resources are limited and you have to make trade-offs. People do understand this. They may not like it, but it ultimately comes down to how well you set and manage those expectations. An organization should evaluate their core values and align their prioritization methodology to it. While large and small customers should not necessarily be treated the same, it is important to make sure that you have a strategy for handling both sets of customers. This exercise must be re-evaluated on a regular basis. Some common prioritization considerations include: customer size, project duration, complexity, strategic project nature.

Customer Size: This really comes down to revenue. Your largest customers bring the most money to the organization and therefore need to be kept happy. Sometimes, some creative solutions might need to be introduced. This might be dedicating a team to customers over a particular size, or providing on call services to these select. As I mentioned before, the downside of this is you can’t do this at the expense of all your other customers. They won’t be ignored.

Project durationIf you can focus on a project, get it done quickly and make a big impact, there is value to making this a priority. There is a risk to constantly pulling resources in and out of new projects. You might want to consider a roaming “quick-hit” resource squad to rotate through these types of projects. It can be a great way for more junior resources to learn and grow, continuously being introduced to new case studies. Duration can also negatively impact prioritization as covered by complexity.

Complexity: Complexity is an interesting consideration. Who defines it and how does this impact how you use your resources? A project might be considered complex if it is something you have never done before; or it has quite a few moving pieces and is expected to take a really long time to complete. Additional complexities might have to do with hard deadlines outside your control. One way to minimize the impact of complexity on prioritization is to separate a complex project into more manageable mini projects. You can then prioritize based on your other factors. There may be a few cases where you will need to evaluate project complexity as a factor. This may increase prioritization of the project in order to meet strict deadlines, or it may reduce prioritization of the project given the state of other business and projects.

Strategic Project Nature: We all are aware of opportunities that come along and introduce us to a new market, technology or methodology. These can come from the large customer looking to push the limits, or a small customer willing to take a gamble on us. The upside of these types of projects can be significant, but if things go wrong the project could impact project duration, revenue, and resource allocation.

Once you have your prioritization factors, you need to decide how to weigh them. Giving each consideration equal weighting does simplify the process, but that may not work given your customer and project mix. You might be in the middle of a pivot and need to put greater emphasis on the strategic project nature than you do on customer size. You also need to determine your scale for assigning value for each prioritization factor to each customer or project. This can be as simple as rank order for the number of projects or customers. It could also be a simple 1-n scale, with n equal to 5 or even the number of factors you are using. For both weight and scale, make a decision and move forward.

This is an evolving process, so define a few prioritization factors as a starting point. Once you choose your weight and scale, you have a solid prioritization methodology. Apply this to your customers and projects. You should start seeing the benefits within a few weeks. Projects should finish and your ability to set and meet expectations of your customers should improve. Feedback from your customers will deliver the biggest set of data points. Adjust accordingly.

 

A different path..

In my last post I wrote about teaching my younger daughter about arduinos and my dad’s change of heart on whether I sit on the edge of technology or am an active participant.  I wanted to explore this idea a bit more this week, especially as I watch my older daughter sit on the fringe.

My older daughter, Cayla, is 16 years old and typical in many ways. It’s difficult to find a time when she isn’t on her phone, or iPod or computer. She has taken some very basic computer classes in school, but has never expressed an interest in learning to code or playing video games other than the ones on her phone. Cayla likes science and math, but has been struggling this year with geometry and biology. In many ways, this is not unlike my own experiences.

We got our first computer when I was 7 years old. My dad taught me the DOS prompts to be able to get to do what I wanted and I was a pretty avid “Where in the World is Carmen Sandiego?” fan. I was placed into an advanced math class in 7th grade, but then had to drop it because I was too busy with dance and other after school activities. In HS, I enjoyed my sophomore chemistry class and took the only advanced science class I could take. It was that Physics class where I got so frustrated with the instructor that I took it out on my father by throwing the book at him. Poppa John still holds this over me.

Despite my early exposure to technology and my dad having an education and experience in chemical engineering, I did not even consider engineering as an option. It was the constant learning and growing that inspired me to pursue my advanced degree and go the business route. That said, that technological interest fostered early in life has carried me to some unique opportunities. I was involved in internet at a dotcom in the late 1990s, then moved to telecom/software company and then most recently worked at a big data analytics company. I have been able to combine my soft business skills and technical interests to be a strong project manager and business analyst. I am able to get in the weeds with my team and work through fairly technical problems. I am able to discuss big data and algorithms with data scientists and less technical customers. I am also able to be that cardboard batman when my husband is having one of those moments. I do all this while writing about and networking with other women in technology (or those too hanging on the fringe). I am also able to get my hands dirty writing some SQL, programming that arduino or learning enough HTML, CSS and Javascript in a 2 week period to take my younger daughter to an app development workshop.

IMG_2937At the end of the day, I believe that being involved with technology will provide better lives for my daughters, and a bigger impact on the world. While Cayla isn’t ready to sit down and program a website, she is willing to support her sister. I have brought them to a couple recent STEM symposiums and showcases. Cayla does a great job encouraging Ana and stepping in when Ana is feeling a bit shy and overwhelmed. I hope that Cayla continues to appreciate the technology and become open to the possibilities. Let her be her sister’s mentor and advocate. We all have our own path’s to technology.

P.S. Cayla agreed to learn about data analytics and R as her internship this summer. May the journey begin.

Raising a Women in Tech

I recently went on a trip with my dad, Poppa John and my youngest daughter Ana. This was the first time I traveled with my daughter separately from the family. She negotiated this trip to Disney World for spring break and was quite persuasive. That said, I knew I wasn’t going to spend every day for a week at a Disney theme park. Ana is very interested in technology – she’s the daughter who wants to learn to code, immerses herself in Minecraft and has participated in app development summer programs. Our entire family encourages this and Poppa John indulges her.  For this trip, Poppa John purchased a couple of Arduinos for us to play with during some downtime. He also compiled a selection of really cool things that Arduinos can be used for and got a book for kids, written by a kid on how to program our Arduino.

My husband is the programmer of the family. He started when he was 14 and has made this his career for the last 20+ years. I have had a much more diverse career supporting technology – project and product manager, analyst, customer success manager and software team lead.  To my father, I was sitting on the fringe of women in tech and needed to get motivated to lead Ana on her quest. If we sat around waiting for Carson it would be slow going.  These Arduino projects we had planned were as much for Ana’s benefit as it was for me to step up to the challenge.

Our downtime fun started a bit slow, with Ana not really understanding what an Arduino was and why she should care. Her attitude swung to the other extreme once she figured out that she could build a car with lights and sounds. However, she just didn’t understand why she had to do the basic lessons and not jump straight to the car. Since Ana doesn’t like to be left out, Poppa John and I started connecting the Arduino and making it light up and sing. This at least got Ana creeping over to the computer and looking over our shoulders. We knew we had her attention at least for a little while when she took her spot front and center on Poppa John’s lap.

We took a very simple approach to this, using the existing open community scripts for making the light blink or the song play. We then took the next logical steps to add blinking loops, change the speed of the blink or the manipulating the time between the blinks, slowly making the code a bit more complicated. I took my pretty standard approach of asking Ana the engaging questions, but having her work out the details with Poppa John. I also stepped in to help troubleshoot or explain something when mistakes were made.

It was during this time that Poppa John was surprised. He claimed I was holding out on my women in technology-ness. How was it that I could never have had coded anything (expect sql during my brief DBA days) but yet could read the code and make suggestions and resolve issues? In each one of my diverse opportunities working for technology companies, I have always been hands-on. When issues arise in my projects, I worked very closely with my technical team to walk through the business requirements and the code to figure out the best way to resolve these issues. I have always been willing to lend a helping hand and truly get my hands dirty. Apparently I have picked up a few technical skills.

We ended up having a lot of fun with something new. We made our Arduino blink SOS and play music. We also turned the Arduino into a finger flute. Ana still wants to build her car and thinks it’s pretty cool. Ultimately, I taught my father that I was a women in technology and had the skills to teach my daughter to be one too (in any capacity she wants).

IMG_2752

Are you truly confident?

I recently met up with a friend who I have known for almost 20 years now.  I consider this woman very successful.  She grew up in NJ and has degrees from Duke University and a law degree from University of Pennsylvania.  Since she got her law degree, she spent 7 years at a top law firm and then she was corporate counsel at a Fortune 100 company.  My friend just started a new job for a global company that is considered one of the most admired in the US. What struck me as most interesting this visit is when she acknowledged doubts recently about whether she could do this most current role.  Not only is this women smart and talented, she is also the epitome of a confidence, social butterfly.  Of all my friends or colleagues who have doubts about themselves, I would never have considered that this applied to this friend too.  My friend’s experiences align pretty closely to what I have been reading about women in technology, leaning in and other topics at the forefront of my interests.

This also very much ties into a book I just finished and a keynote that one of the authors just gave at the U.S. Chamber of Commerce Center for Women in Business “The Science of Success” Conference.  Claire Shipman, author of The Confidence Code gave a great overview of a challenge that definitely exists for Women, in technology and other industries.  I had purchased the book prior to seeing Mrs. Shipman speak, but didn’t read it until afterwards.  This is a compilation of my thoughts on the book and notes from her speech.

I think it is now common knowledge that diversity is key and that soft skills are becoming more and more important in the workplace.  There was an HP experiment conducted that highlights the confidence gap.  Women tend to apply for jobs where they have 100% of the skills required for the job, while men apply for jobs when they have 60% of the skills required.  Another research study at Berkeley shows that confidence is a better measure of success than competence.  Women tend to hyper focus on competence.  If this is the case and women are so focused on being competent that we’ll only stretch ourselves when we believe we have met 100% of the requirements, those opportunities just may not be available for us.  It’s imperative that women start treating confidence like a skill and incorporate into our professional and personal play books.

One of the most interesting pieces of The Confidence Code was learning that confidence is at least partially hereditary.  The majority of the brain is the same between men and women.  However, women and men differ in how the brain fires its neurons and also in the risk taking versus worrying areas.  Men have more testosterone and therefore tend to take more risks while women have more estrogen and tend to overthink or ruminate preventing the brain from building the confidence.  The good news is that the significant developments in neurology have taught that we can train our brains – the science known as brain plasticity.

We should not get too bogged down in blaming our genetics as there are also societal impacts that influence confidence in girls.  We subconsciously initiate the confidence gap for girls by raising our girls to be perfectionists and people pleasers.  Girls are taught to follow the rules, be good listeners and do what they are told.  Boys are given a bit more leeway to try things, take risks and ultimately fail.  Ultimately as women transition from school into the workplace, it becomes very difficult for them.  They are still seeking the rewards and praise they got in school, whereas the workplace is really recognizing the confidence, risk taker who is willing to take on increasingly more responsibility.

There are a few recommendations for what we can do differently.

  • Fail fast – do, learn, move on.  Start acclimating yourself to risk taking.
  • Act more, think less – ruminate less. Come up with an explanation that is not a failing on your part.
  • Be authentic – this is critical.
  • Play competitive sports – there is a huge link between confidence in girls and competitive sports.  Not everyone is a winner.  You need to work hard, develop competency and ultimate become confidence.

Confidence is what turns your thoughts into action.

 

Why do you need a cardboard batman?

I am not a software developer.  I do have some training as a database administrator, most of experience is in managing projects and teams for highly technical initiatives.  This ranges from shopping cart and credit card integration for an e-commerce site in the early stages of the Internet; the creation of automated renewal subscription processes; billing systems; customer portals; complex billing processes for publicly traded companies and legacy to SAAS migration of critical business software.  I raise my experience here as I want to talk about the principle used in software development called “rubber duck problem solving”, but which I have been using and calling cardboard batman for my entire career.

“Cardboard Batman” refers to the act of clearly articulating a technical problem and in the process solving it, without any help from the person you talked to (real or fake).  I have to thank my husband, Carson, for introducing me to this concept. I met my husband 20 years ago at a small, e-commerce startup.  He was the programmer and I was the project manager.  At the pinnacle of the dot com bubble, our days, nights and weekends were often filled with work towards an aggressive deadline.  This often meant that Carson would be sustaining himself on mountain dew and pizza and I was constantly asking “are you done yet? is it ready for me to test?”

Inevitably an issue would arise late at night with no seemingly easy solution.  After Carson would spend some period of time trying unsuccessfully to debug his code, he would call me over to explain what he was doing. This usually involved walking me through software code in the language du jour and trying to step me through the problem – both what customer problem he was trying to solve and what issue he was running into.  This is where my lack of programming skills became an asset.  In translating between the customer problem and the software code, more often than not, the issue would become obvious.

Over the years, I have incorporated this methodology into my project and product management.  It forces you to step back and rethink the problem you are trying to solve and the current solution.  In many cases, it has exposed a different, better way of doing something.  It has also allowed me to manage highly technical developers, database and system administrators, without necessarily having that classical training.

So, Do you have a cardboard batman (or rubber duck) readily available?

While we call it something different, the cardboard batman method is real and sound.  You can find more at this blogyoutube, wikipedia and even urban dictionary.

When does “jack of all trades” become “broadly experienced”?

I recently transitioned out of my most current job and have had an interesting perception shift since the last time I’ve done this.  Throughout my career, I have had opportunities to do a wide-range of activities and fill very diverse roles.  This has worked well for the small, growing organizations I have been a part of, as well as my own lifestyle and growth.  This did not work as well during times of transition when it was time to pursue other opportunities.

While my resume was full of successes and statistics, it lacked focus and singular, sellable skills. I was not a database administrator or a certified project manager or a business analyst, however I had filled each of those roles for some period of time.  The first time I recognized this, I supplemented my work experience with an MBA.  Re-entering the workplace in a startup as Director of Technology & Billing, as a doer and overseer, allowed me to leverage the skills I had.  This role further broadened my experiences in managing international teams, selling a company and global billing systems.  I would not have had these opportunities without the diverse skill set I brought to the table.  But this was a specific case of a specific company who was looking for my specific skills.

This time around, I feel the conversations are different.  I now have enough experience that my expertise is my diverse background in small and growing companies managing projects, processes and answering business intelligence questions.  I have found that the tone and questions I get from people during this transition are more about figuring out what interests me  and aligns more with my interests, than what specific skill do I have.  I am no longer the “jack of all trades master of nothing”, but rather someone with broad experience.