In a traditional store, paying by credit card involves swiping the card through a swipe machine, which reads the data stored on a credit card’s magnetic stripe.  The data includes a few key bits of information, namely:

• The account number and expiration date of the card
• The account holder’s name
• Some provider-specific data for verification

For a typical online transaction, the magnetic stripe on a card is not used.  Purchases are made by entering account information manually, along with verification values not found in the magnetic stripe.  This is acceptable for most people, as few computers come with magnetic card swipes.

However, what if someone wants to use an online system to run in-person transactions?  With ThunderTix, many of our clients use our system for ticket sales on site.  Typing every bit of data for each customer is slow, and tends to make people in line cranky.  Fortunately, the magnetic stripe comes to our rescue.  The first part of a magnetic stripe’s data looks something like this:

%Bxxxxxxx^LASTNAME/FIRSTNAME ^yymmzzzzzzzzzzzzzzz?

where the

xxxxxxx

is an account number,

LASTNAME/FIRSTNAME

are the account holder’s name,

yymm

is the expiration date, and

zzzzzzzzzz

is additional numbers.  Using the standard format to detect a card swipe transaction, we can extract this information to expedite order processing:

if credit_card_number =~ /^%B(.)*?$/
card_fields = params[:cc][:number][2..-1].split(’^')
card_number = card_fields[0]
name = card_fields[1].strip.split(’/')
first_name = name[0]
last_name = name[1]
expiration_year = card_fields[2][0,2]
expiration_month = card_fields[2][2,2]
end


A few bits of additional data (magnetic stripes do not contain the verification values used for online transactions), and we’ve managed to cut each patron’s wait time significantly.

During a conversation with a large national client, two of their staff members made the implication that their “boss”, the executive director, was out of touch with what was going on in the trenches, and he should not be consulted on important decisions.   Though I agree that the director may be unaware of the day-to-day minutiae of staff work, as the person who signs the check that pays me, the director’s feedback from a high level was important to us.  When I hung up the phone, I asked my office why such a common misconception existed–an employee’s belief that management lacks an understanding of their work?

Bad managers do exist, but the vast majority of my clients have exceptional leaders–including the aforementioned director.  Most are intimately aware of the roles their employees play in their success. A good manager shouldn’t have to know the details of an employee’s job; inherent in any position is a trust that sound decisions are best made within one’s area of expertise. Those organizations are profitable, successful, and forward thinking businesses indicating a healthy understanding of the roles of their staff.

As a business owner, I also allow a certain latitude within an employee’s job. Our web sales is efficiently handled without my input; ThunderTix has been cultivated under anothers purview; and our programmers would not benefit from my code reviews. WIth them, I have been pleased to see growth in our sales and profitability each year of our eight year history.  But watching over those financial markers does not translate into an all-encompassing focus on the bottom line or lack of insight into my employees’ respective roles.

Yet I and our executive director share something in common. Despite our efforts, our employees have both publicly disparaged our leadership. A former employee wrote:

Someone running a business isn’t as focused on the institution.  To generalize, their primary focus is simply on generating money.

That’s a pretty haughty generalization from someone who has not walked in the shoes of a business owner.   The fact is, most company leaders are focused on a whole lot more than generating money.   For us here at Thunder Data, a primary driver of our own success lies in client satisfaction and responsiveness, and it is the single most lauded trait we hear in feedback from clients.   And in what I’ve hoped was a demonstration of my understanding of employee needs, I’ve been proud of the fact that I’ve not been afraid to let my people test the waters with new languages, products or processes to help feed their collective hunger for staying on top of the latest trends in tech. 

One of my goals this year is to expand employee decision making while balancing with client expectations.   It requires mutual trust and respect of what each of us brings to the table. When we recognize an individual’s role, we’ll succeed individually and collectively.

Today, we received a client request to improve a page’s load time while in the midst of making major aesthetic improvements to another site.  When I suggested we switch gears to help the client, I was met with resistance in the form of frustration that the new project was being interrupted.

This gave us opportunity to have a long overdue discussion that probably would not have taken place if we hadn’t had recent staff changes to our programming team.   The crux of our talk:  our recent past will not dictate our future.

For the last year, we have followed agile development practices that offered remarkable improvements to how we scheduled and executed work.   Though the scrum master’s philosphies dramatically differed from my own, I  allowed a fundamental shift in how we operated our business.  The biggest change lay in our responsiveness to client requests for bug fixes and improvements which were increasingly  pushed to the back burner so as not to disrupt weekly sprints or programmers who were “in the flow”.

At some point, I began to realize that the way we practiced agile centered on how we could keep the development team happy.   But they weren’t happy.  And neither were the project managers.  Worse, our clients were not getting the attention to which they were accustomed and deserved.

Despite my knowledge that our practices were not benefitting our business or clients, in lettng the programming team to dictate our business process, I was essentially allowing the tail to wag the dog.  It was during one sprint meeting when I asked a question that I got my wake-up call.  Why, I asked, are we focused on how we could improve the programmers’ jobs, but no one is interested in how to improve our jobs as the primary contacts to the customer?

The answer was telling:  ”We don’t even know what you do.”

So this morning, we talked about change to our collective mindset.  I explained that I meet with a group of professional women every six weeks.  Virtually all of them have fallen victim to the recent economic climate.  Separately, two of the women indicated that we must be doing something right:  in their minds, we seemed to stand apart as a business that is profitable and growing despite the downturn.

I told the staff that our success didn’t happen by chance.  Before this past year, we’d put our clients first.   Today, I stood firm:  from here on out, we stand second to our clients.  If they are our priority, we cannot help but succeed.   The cool thing is, they will, too.

Every Monday morning our team engages in a sprint planning meeting.  Starting with a retrospective of the prior week, we discuss problems, successes, and ideas from individually posted notes on each topic  Intended to be frank discussions, we are openly enthusiastic about the good things that occur, but our challenges and frustrations are generally veiled.  The goals of a retrospective aim to improve the team’s flow, but if we aren’t honest about the challenges we’re facing, they are simply a waste of time.

During a retrospective six weeks ago, my Post-it note read:  “We are a dysfunctional team.”

For a couple of weeks, I felt frustrated and unhappy with the office atmosphere.  No one was complaining, work was getting completed, and there was no list of dissatisfying issues.  But there was a palpable sense of unhappiness among the team.  My posted note opened a long closed Pandora’s box, and so began our first real steps to re-creating the team.

We are not alone.

At SXSW, no less than four panels tossed around the subject of developer/staff relationships.  The consistency of the theme was surprising.  Two questions begged answers:  what factors lend themselves to these difficult relationships, and how do we change team dynamics?  I was on a quest to find answers and work on fixing our own team.

To start, we discussed what we collectively felt were the primary requirements of a <i>functional</i> team: trust, honesty, partnership, and commitment.  We were failing at all of them, and the negative pall cast on the office was tangible.

Each month, we’ll share the changes made and the results realized as we attempt to overcome the obstacles that prevent us from realizing our potential