14 architecturalist papers: the imaginary architect

One of the trickiest parts of the job is how to start. If it’s a brand new system, at a brand new company, I am not sure I have any useful advice, and more practically, that’s not the kind of role this blog series is trying to describe.

After all multi-product system architecture of a single product with a single engineer is putting the cart before the horse.

Over the years, this process of how to become productive has tortured me through a series of jobs. In fact, in 2009, I almost got pushed out of Zynga because I hadn’t figured it out. And in 2008 I got my worst professional review because I hadn’t figured it out.

The crux of the problem is that when someone hires a very senior technical person, what they are hiring is an entire leadership org chart. They don’t realize that at the time. Worse, they don’t even realize how many new people they will have to hire. And worse the woman being hired has no clue as to how many people she will have to hire or fire.

At Zynga we had a high infant mortality rate with senior folks who would quit the company relatively quickly because we had a really bad on-boarding process. We paid them like they were senior, but they didn’t operate as senior folks because they lacked context and we didn’t help them get the context.

When I arrived at Zynga, Michael Luxton whom I mentored in the past, helped me. He basically told me the following: On the day I arrive I am an MTS 2. And should be given MTS 2 tasks. In about a year, I will be doing the job he hired me to do. It turned out to be a little bit faster, not because I was particularly capable, but because circumstances and luck made it go faster.

It was a bitter pill. And I almost didn’t swallow it. In fact, I was so frustrated that I almost walked out of the company one fine evening, frustrated that I was failing. But another great engineer talked me out of it.

At Juniper, and later at VMware, my bosses who were great VP’s of engineering provided a lot of structure in my onboarding and basically followed the same process.

But before I get to the process, let’s talk a little bit about what the problem is. The problem is that you don’t know where a company is on the technology curves. Is it a bleeding edge company that needs you to go invent something radically new? Or is it a laggard that needs you to fill feature gaps? Can your team write code but can’t architect? Or can it architect but not write code?

Put pedantically: can they write a block of code correctly? Can they write a function correctly? A module? A system? A product? Depending on where they are, the problem is different.

Is the problem not the code being written, and the architectures being proposed the release process? The build system? The schedules?

Is the problem the set of features the product team wants?

Does the team have the people who can build the features the product team wants? If you want to build a distributed system where you need world-class distributed systems engineers, and you don’t have them, you have the wrong team or wrong product ideda.

And they only way to figure that out is to get down and dirty.

So here’s the process I used for myself and I use for people who join the team. This is a process that my bosses codified when I joined VMware and Juniper and Michael Luxton intuited and mentored me through.

An architect is an imaginary architect – meaning she’s done nothing for you. And an imaginary architect can’t possibly be trusted to do anything. So step one is to make the imaginary architect do something that is not imaginary, for example, deliver code. The next step is to deliver a feature. The next step is to architect something. The next step is to sell something big they want to build. And to remind them every step of the way that they are imaginary until they accomplish all of the above. 

In general, my perspective is every new architect should spend a month fixing bugs in the core product they are working. They should fix a bug, check it in. Ideally several bugs. They should attend the scrum’s, the etc. And they shouldn’t pontificate but they should prove to their team that they can fix the bugs and do the work that an engineer can do. 

In fact at VMware, I only started to be taken seriously when I showed folks I could use a debugger. I remember one of the architects looking at me: WOW you know how to use a debugger. And I almost exploded in frustration because of course I know how to use one. But then realized that maybe if I had done that on day one, I could have saved myself some grief.

Once the architect has crossed that threshold, then and only then can we expand their scope.

Meanwhile we are feeding her the fire-hose of everything they need to do.

Let’s get even more granular.

After the architect has been hired, settled into their desk, you tell them: you don’t have any credibility with anyone on my team. Worse, you have anti-credibility because it means someone who thought they had the job no longer has it.

To get that credibility you need to go fix some bugs on product X, Y, Z. You need to own a feature in that product. You need to prove to people you can ship shit.

Until she does that people won’t take her seriously. 

She need to demonstrate you understand more about the system than they do. In pedantic detail.

The next step in my mentoring process is to tell the imaginary architect that she needs to get the team to buy into building something new. I tell her, “I don’t care what it is.” As far as I am concerned, the technical team must want to build the next thing you are selling.

Thirdly you need to sell to product management the thing you are building. 

And if they can’t sell to product management, tell them “I won’t overrule product management .” And if they say: What if I can’t? Like George Washington told Alexander Hamilton the only correct answer response: Well I suppose we’ll have to find an architect who can. Go figure it out!

And at that point, you no longer have an imaginary architect, you have a real one. And guess what during that entire process, the architect has been delivering value, gaining credibility with the team, and learning the corporate values and when they tell the team go left, the team is willing to follow them.