I’d made the transition to consultant fairly early in my career.  I worked for a company while I was in college, and then when I left, I worked as a consultant for them for a brief period, and started getting contracts on my own at the same time.  I’m not very good at the marketing thing, so after a few months of that, I found a consulting firm in Charlotte, where I wanted to move, and started doing that sort of work.

Consultancy is interesting on some level, you have a specific thing you are working on, and it’s your job to put your skills and knowledge to use to help the client make good decisions, and then implement the decisions of your client.   Consultants lack the context and investment needed to make business decisions, so one of the skills is to understand when such decisions aren’t technical ones, but business ones, and to take them to the client, discuss the benefits and risks of both sides, and let them decide.  This isn’t a bad skill to have, since often you want these things separated in your code: functional technical code on one side, business rules (which always change) on the other.  Encapsulate it well, and the business side is more flexible because IT can support them more rapidly.

Eventually I started to settle down and was looking for something more permanent.  At the advice of one of my bosses, I took a job at Bank of America. It was through a consultant firm, but was a contract to hire position, something I’d not done before, but I was getting tired of the vagaries of consulting and consulting firms, and was getting to a point where I wanted to have a longer term commitment.  I had the option to stay with the consultant firm, of course; and Bank of America had the option to not hire me.  I’ve come to like this sort of hiring, both as the potential hiree, and as someone on the inside, evaluating the fit of a fellow employee.

At any rate, I got to a point were I hit one of those “business rule” things.  It was fairly clear to me what the decision should be, but my consultancy days had taught me that I needed to be sure, so I took it to my boss.  He looked at me, “What do you think is the right thing to do?” he asked.  I told him what I thought.  “Well just to that, then,” he said.  “And don’t bring little stuff like this to me anymore, if you know what is right, just do it.”

I’m sure he didn’t want to be peppered with a million little questions, and I know now that this was what my life would be like when I was hired (as I was six months later), but it was like a revelation to me.  I had the responsibility for the code — I’d had that as a consultant all along.  Certainly the direct client had ultimate responsibility to their superiors, and I was just a contractor, but it was my reputation and responsibility that was on the line.  But I’d been handed something much more important to me: trust to do it right.

I’d moved from something where I was working on a fairly narrow charter, to something where I was given broad responsibility, and trust to get it done.  This was part of the BoA culture at the time, where employees were encouraged to notice and fix problems, even if they were normally considered outside the scope of their duties.  I wound up staying there until we moved to Columbus.

There’s something good about being trusted, and earning that trust through good work.  It’s empowering and makes me wake up in the morning ready to go to work and do great things, knowing they will be allowed and have the ability to do them both with my technical skills, and in the culture of my work.  With new management where I am now, or with a new job I may find, I’ll have to enter a phase where I earn that trust again — I know that — but any place I’m happy to work will allow me to do that, and the space to do good work for them, and for me.

As I’ve thought about this now, I realize this is how I manage my assistant now.  I’ve tried to instill him (or develop with him) goals for what we need done, and set priorities.  He seems to thrive under this as well, although I suspect I’m still learning about managing people.