An architecture decision that was so much more
Fifteen years ago I made a decision about software architecture almost by accident. I mean to say that I felt like I had thought thru the issue intelligently enough, but I didn't know what I didn't know.
So I had no idea how powerful this decision would be.
Nor would I have guessed that it's become one of the core components of a methodology that has impacted how I think about technology, architecture, staff on-boarding, training, complexity, and product development.
The decision I was facing was related to object-oriented design, and a new architecture we were developing for an enterprise software product line. The question was whether we should put our own wrappers around a set of libraries. There were many reasons to consider doing this (at the time) and another set of reasons to suggest we should do it.
Members of my team were fighting on both sides. And remember, this was fifteen years ago. So there were still a lot of lessons we were still learning about everything object-oriented.
I made the decision with a simple rubric I created on that day. It was a question that I posed to my team. I asked it this way:
Assume that we were to hire someone skilled in the technology we're using. Skilled in terms of best practices that are understood out in the rest of the world. Would they be able to come up to speed on enough of our technology to be productive in two days?
The Two Day Rule
This question—of whether someone skilled in the right way could be productive within two days —because the core of what I now call my two-day rule.
It's pretty simple. A lot of technology companies I know (and I'm not talking about WordPress companies, in case my friends are wondering) are proud of the fact that the time it takes for a new senior engineer to get up to speed on their technology stack, process, methodologies, and toolsets is measured in weeks or months.
Think of what that means from a business perspective.
It suggests that an organization has created so much secret sauce that someone who already is an expert in the technology that a company is using, is simply dead weight and highly expensive for weeks or months without being able to contribute to the bottom line.
What a waste!
Before you start the debate…
Now, I know you may want to debate the merits of how complex your specific situation or domain is. I get that. But I'll use one of my favorite examples in culture diffusion—the Ritz Carlton—for just a second. This is an organization that has to get thousands of people to all interact in the same way, while making all their own decisions, with financial freedom to spend corporate funds, and all delight their customers—and they have a short training program along with daily 20 minute meetings.
They have their own secret sauce (not so secret) just like anyone else. But they get people productive in days, not months.
Now, again, I understand that different companies do have their own cultures, processes, procedures, and methodologies. I get that. But all of those big system things all start out pretty small.
Think about how these all start…
Rarely do you hear someone say, “I'm thinking about building an architecture for this next project that will require new senior engineers months to study up and learn before they can be productive.”
Instead, what you find is that lots of little decisions are made.
- “Why don't we add….?”
- “What if we were to….?”
- “I think it would be cool if we….”
Big systems—from software architectures to business processes to toolset methodologies—don't often start big. They start with small, tiny decisions made often by the people closest to an actual situation.
But those same people may not be the ones who are thinking about the financial or long-term consequences of that decision. They may not have the perspective of several projects, or histories with all different kinds of clients.
And that's why I started my two-day rule
I didn't start the two-day rule as a law or some crazy sort of religion. I didn't use it as a rigid constraint that would limit our freedom or constrain our ability to act (or serve customers).
I started it as a guideline for every single person on my team making tiny little decisions in the little places where they were at. They would simply ask themselves:
If a new expert joined our team, could they get productive in two days?
And it would shape all sorts of little and big decisions. And impact how we onboard staff. And shape how we train people. And determine what tools we choose. And suggest the kinds of architectural simplicity we embrace.
And to be clear, I'm not suggesting that new employees can become fully leveraged and completely independent in two days. Nor am I saying that they can do anything within our systems and architectures.
But I am saying they can start adding value. They can start contributing. Within two days.
What about you?
Like I said, I'm on vacation on a cruise ship. So I didn't expect to hear any talk of software while I was here. But while I was sitting at the Starbucks (yes, they have one here—Brian Gardner would be happy) I overheard two guys talking about work.
They were complaining about how hard it was to hire someone. They were complaining about how long it took to get projects out the door. I so wanted to turn around and interrupt them. But I have no standing with them. Plus, I'm pretty sure my entire family would have killed me.
But now, as they sleep, I thought I would share my two day rule with you. It's been an amazing tool that drives simplicity into all of our work, and has done the same for some of the folks I've coached.
What about you? Would it help you?