Engineering Ardor
“Science is the study of what is. Engineering builds what will be.” — Theodore von Karman

There He Was… Gone

I’ve switched jobs again. Actually, I went back to my previous employer. That in and of itself is of no use to you, so I’ll skip over it. There are, however, some lessons from my now ex-employer that are worth learning if you want to retain your employees, or I suppose, if you want to drive them away in droves.

Integrity Matters

My ex-boss had a bad habit of lying to potential customers. (I only say potential because we didn’t actually have paying customers. I only say lying because his statements were untrue.) Need something to manage all your data? Our product does that. Need something to predict the effect of your manufacturing shop changes? Our product does that. Need something to translate between eight file formats? Our product does that. Need something that will train transportation security workers? Our product does that. Not gettin’ any? Neither is our product.

Point is, he then expected his employees would trust and have confidence in him. Even though the quarterly bonus program he kept promising for nine months never got off the ground. Even though the upcoming business projects and prospects he described never materialized. Even though he instructed me to falsify a time sheet on a federally funded project. For the record, folks, there’s only one acceptable answer to that last one: “Boss, Kansas gets too cold in winter to end up in Leavenworth.” Suffice to say, my time sheet remained unchanged, accurate, and legal; our conversation has since been reclassified as a misunderstanding.

If you don’t act with integrity all the time, where does it begin and end? Do you start acting honorably when you leave the house in the morning? On the drive in to work? When you clock in? Only after your second coffee? When talking to your own people? Existing customers? Potential customers? When you preface your words with “Simon says?” If you don’t display good character and integrity at all times, why should I trust that you’ll act uprightly when dealing with me?

Responsibility, Accountability, and Authority

Authority is the delightful creamy center sandwiched between the dry chocolate wafers of responsibility and accountability. Consider:

If you have accountability and authority, but no responsibility for something, you get Not My Job, syndrome. I see this all the time in engineering organizations. The design engineers are held accountable to some degree if the product is terrible and they have authority to make design changes, but it’s “the ilities” job to make sure the system is reliable, safe, and of sufficient quality. It’s testing’s job to find the bugs. It’s usability’s job to change the neon orange eighties era airline seat color scheme to something pleasant.

If you have responsibility and authority without any accountability… well… look at most of the United States federal government for good examples of this.

If you have responsibility and accountability with no authority, you have the job I just left. It was my responsibility to make sure we ended up with a high quality product that delighted our user, and it was my behind on the line if that goal wasn’t met. However, I also had to comply with all the detailed design decisions of our VP of engineering, ensuring I had no authority to design a successful product. Unfortunately, his decisions bring us to the next point.

One Size Fits None

“To a database person, every nail looks like a thumb. Or something like that.” - Jamie Zawinski

I am told that by quoting jwz, I will make myself appear to be one of the cool kids. Or something like that. Undeniably, the man has a point. We had a data storage infrastructure that had to be used for all data storage needs of the software: application data, cached calculations, user preferences, everything. Worse yet, not only was the data storage mechanism one size fits none, but it came with a preexisting data structure, which the VP of Engineering was dead set against changing or expanding in any way. Need a concrete example? We were working on software that needed to control access to certain data using access control lists and permissions. The One True Data Structure had no such construct. The VP of Engineering reasoned that because permissions were initially assigned during the process of creating an account, we could create an instance of our workflow engine and store the permissions on an event thrown by the workflow engine during account creation. To retrieve, we merely needed to instantiate the workflow engine and sift through all the events it had thrown to find the permissions for a particular user.

A Blunt Butter Knife Is Not A Scalpel

We had few tools, but we made up for it by using them poorly. Even with CVS, it shouldn’t have taken six different checkouts from two or three branches to get the code for one of our projects. With all the free alternatives available, we could’ve had a more sophisticated bug tracking tool than a pad of legal paper. And the clay tablets, why oh why did we leave them in the oven so long. They came out brittle and cracked.

What I Want

Keeping me happy, and using Proof By Arrogance I will claim other engineers as well, is not so difficult.

  • Give me smart people with integrity with whom to work.
  • Give me an interesting problem to work on. (Note, some people will be very happy to work on a boring problem with a pleasing enough work environment and paycheck.)
  • Give me the accountability, authority, and responsibility to work on that problem.
  • Give me a decent environment and tool set to use, or even better the authority to select my own.
  • Get out of my way so I can get things done.
  • Share and Enjoy:
    • Digg
    • del.icio.us
    • Reddit
    • StumbleUpon
    • Technorati
    • Furl
    • NewsVine

One Response to “There He Was… Gone”

  1. Cian Says:

    I really like those rules a lot. The ones I would add are ones that I have had issues with, and generally affect the larger organization. If you have these problems in a small company you are in real trouble.
    1. Incent everyone to work toward a common goal.
    2. Don’t create systems with conflicting objectives and then ask/expect people to be team players.
    3. Either have managers who have the authority to make decisions, or take out a bunch of layers.
    4. Don’t stop listening to the people that actually do the work.

Leave a Reply

Subscribe without commenting