Separation of duties

I recently had to consult with a structural engineer about the foundations of my house. It's made of concrete blocks and the footing is exposed. The house is old, and winters get cold.

The engineer told me that the only option was to lift the house, destroy the old foundation, and build a whole new one. A project that would cost well over a hundred thousand dollars.

Every other option, to him, is hacky and unsafe.

He's not wrong. His plan is the only kind of project he can deliver with a full guarantee. His arguments were sound. His explanations honest. But something didn't feel right.

This is interesting, because it has nothing to do with his ability to deliver. In fact, his firm has a stellar reputation for doing quality work.

But as much as I could appreciate his advice, I couldn't bring myself to trust it. I knew he had something to gain. His business card even says "specialist in house lifting".

There is this intuitive sense that you can't rely on a biased statement. It sounds so obvious, too.

And yet, in most software shops, the IT department is responsible for IT security.

That's not an issue when you're getting started, because everybody trusts each other. You know you can believe your sysadmin when they tell you there is nothing weird in the logs. You trust that evaluation, because of who they are. You trust them.

But as you grow, roles change and tasks get delegated. You hire, and soon, the organization is three times the size. The sysadmin is now a small IT department. And the fox is guarding the hen house.

Growing is messy. And we have to trust each other if we are to work together. Administrative controls get burdensome, so keep it simple.

1. Divide critical functions among different members of your team.
2. Ensure no one has enough access privilege to cause damage on their own.
3. Review job responsibilities and work contracts on a regular basis.

When the engineer tells you, "Let's do this right", you won't have to think twice.