Reading more efficiently

In IT, we have to read a lot. For instance, understanding how to set something in Azure or Okta or vSphere may mean we are consuming 5 or more “articles” to get the gist of what we need to do. The better we are at reading and extracting the information pertinent to the task, the faster and more accurately we can accomplish our work.

If you’re still pretty much a word-by-agonizing-word reader (with apologies to Jeff Moden and RBAR), the following may help you read quicker and retain the information better:

How to Read a Book a Week by Peter Bergman (Harvard Business Review)

Architecture – Commonality is an accelerator

In IT, commonality is an accelerator. When I say commonality, I mean commonality of:

• Components, like libraries
• Object models
• Interface definitions
• Tools

Let me give you an example. Imagine I have 3 different scrum teams, each supporting 3 different but interconnected applications. They each need to develop API calls for their system to talk to the other 2. The typical approach is for developers on one scrum team to have to learn the APIs of the other 2 systems. However, while I’m learning the APIs of those other 2 systems, I’m not working on my own system’s product backlog. Wouldn’t it be great if there was a standard API which all 3 systems implemented? Standardized methods with standardized parameters would mean each team could simple call to the standard. There wouldn’t be any wasted time having to learn the internals of a different system. That would be definitely accelerate work and deployment of features for each team.

Is there some additional work for each team? Yes. They’ll have to take their APIs and build an interface layer that maps to the standard. However, that does two things:

• It ensures the folks who know the system the best are the ones building the interface layer, rather than a team supporting a different system trying to figure things out.
• It also ensures each team is familiar with the standardized model, meaning their ability to implement interfaces with other systems should accelerate.

Think about if each team had to learn the other teams’s systems. We actually lose more time than just the learning. We also lose time due to the following:

• Troubleshooting errors due to not having a full understanding of the other system. This is for both teams: the team learning and the team supporting.
• The supporting team effectively has to mentor each learning team. This isn’t something that’s easy to put in the product backlog. So it usually shows up as untracked/unplanned work.

Commonality reduces the time spent on those two things. So overall, if I have a standardized API interface, if I have commonality on my systems, I should be able to build faster and ship faster.