Fixing resourcing

We talked about getting help in the last post. The challenge is with lack of resources for funding critical long term projects. Let’s break down the problem bit more and try to solve it in an ideal world.

Two imperatives - Architect must understand that she is building a business. She shouldn’t get attached to a particular technology. Business roles must also understand that Architect is building a business and provide the necessary support.

Our problem statement - how can we fund architectural initiatives for the long term?

Constraints

First, can we get away without doing the long term thinking? Answer is obviously no. We must get off the trap of incoming↗ to create a strategy for future value. It is worth noting that - investing on architecture remains a trade-off. I’ve been with organizations which got away without any architecture for years, simply because someone else decides the business and architecture for them and they excel at execution. More on organization structure below. We assume here that the organization has a desire to contribute more than just execute.

We cannot lower the priority for the existing stakes on the ground either. We must continue to ship value for the customer. Strategists call this part easy since it is less ambiguous. In this conversation, this activity requires significant resources. In the dotted line structure we discuss below, execution commitments forms the base criteria to build trust.

There are the organizational aspects which add up. For sake of this conversation, we will consider the dotted line structure discussed in two organization structures. The dotted line structure extends an organization based on a certain criteria - geography, business, timezone etc. Execution is owned by the extended entity and they dotted line report into the primary organization. I have introduced an Architect position in the diagram below for this discussion.

Finally, there are the human constraints. Based on my observations, resourcing forms one half of the organizational politics; other being business ownership. With that hypothesis - it is imperative to justify resourcing. When everyone’s is just looking at you for great execution; they objectify the Architect role to ship good software at amazing speed. It may seem waste of effort to spend time thinking. Resourcing brings in the pressure to ship immediately.

Let me close with a fun observation on how humans operate. If I have resources, I will try hard to encapsulate team internals and keep enough buffers built around resources. But if you have resources, holy cow, you better be shipping something and justify what you are doing with them. True story.

Solutions

If you observe the organization diagram above, the problem at hand is simple - Architect role doesn’t have any resources. Is it possible to give resources to that role for future investments (prototyping, experiments etc.).

Note that the resources must come out of the pockets of Manager role.

Let’s get the theoretically best solution out of our way.

In an ideal world, resourcing should not be a problem. Managers should be aligned well with the Director in long term thinking. They should be willing to contribute resources voluntarily.

There isn’t any order to the solutions below. I’ve put alignment at the top since communication is almost always hard yet often neglected.

Drive alignment

Everything that the Architect role is driving accrues value to the engineering teams under Managers. It makes the product better for the customer.

If I were a Manager, these are the cases against resourcing.

• Architect is unable to define the experiments. He is incompetant.
• I don’t buy into the philosophy of long term investment. I’d have used the senior individual in Architect role in a much better way.
• Architect role has a higher chance of failure. 1-2 experiments succeed out of 10. There may not be much return.
• I’ve too many burning problems, and genuinely there are no resources.

These appear to be communication problems. May be it is worth clearing this air before proceeding with other solutions. A post on tactical steps reasons over the cases against resourcing.

One of my masters taught me to always look at actions instead of words. It is easy to differentiate and root cause communication problems simply by observation.

Make Architect a Manager with specific focus

This is the next best solution in terms of charter and boundaries within the organization. This gets separate funding for Architecture as a charter. It reduces tension since the resources don’t come out of the Manager’s pocket.

Downside - the Architect role must handle people management responsibilities and deal with the expectation to deliver. She is now on the critical path, so ability to experiment reduces etc.

I must add that I do believe in an Architect role which writes code and ships prototypes to production. She excels in experimentation and continuous learning. An Architecture may be built upon theory to define the limits; but it has to leverage data to drive reality.

Create a virtual team around Architect

Slight variation of above - with the Architect not having people responsibilities. Great capability to experiment. Requires everyone to be aligned into the role and long term value philosophy.

Downside - high chance of organizational politics around resourcing.

Push Architect down the reporting structure

This will work well if the Managers are matured enough to think long term.

Downside - limits the scope of Architect to a single problem statement. Large risk of the role to perish under execution burden.

I think this post has clarified the framing and puts a perspective around few solutions. Communication and alignment would be the first options I’d try.

Thanks for reading.