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.

The Thunder Data dev team was represented at this year’s RailsConf in Las Vegas, and we learned quite a bit.  We’re starting a series of RailsConf Retrospectives to delve into some of the topics covered at the conference.

Testing

One of the most pervasive themes at RailsConf was that of testing and Test-Driven Design, principles that have been embraced in the Rails community for good reason.  When done properly, TDD yields a suite of automated tests that can be run at any time to ensure the integrity and production readiness of an application.  But what exactly is testing, and how does it yield such boons?

Red-Green-Refactor

The essence of TDD is the cycle of Red-Green-Refactor.  Start by writing a high-level test describing a bit of functionality that fails, write code until it passes, and then clean up and improve the code.  This continuous cycle results in not only cleaner, more robust code, but by its very nature produces a set of tests that describe the entire functionality and operation of the application as a whole.  This process also forces tests to be written and debugged first, so that any errors later can be properly attributed to the application code, not the tests.  At the end, you will have a test suite that both defines and monitors the functionality of the application.

Fixing It Up

What happens when it comes time to rewrite that particularly nasty controller?  With TDD, have no fear!  If an application has a good set of tests, refactoring is a snap.  Simply make whatever changes you need and rerun the test suite.  If everything comes back green, you may proceed.  If not, track down the failing tests and fix the application code that is causing failure.  Over the lifespan of an application, a comprehensive set of tests for general use and edge cases alike will allow for any future development on any particular part to proceed without a hitch.

Stay tuned for more articles as we continue our RailsConf Retrospectives series.