Sewing the web

The “web” is the underlying layer of processes, decisions, and people that make a good company function. They serve as guidance, safety, motivation, stability. But what are we actually talking about when saying that there needs to be something “holding teams together” to become a well-oiled organization?

I’ve put this into these categories (not in priority):

• Strategic planning
• Product vision
• Technical architecture
• Transparent communication
• Knowledge distribution

We sometimes laugh about there being a “north star” to reach in a company. It’s mostly an elusive one. “That’s what management is always talking about, but we’ll never get there!” - I’ve heard this quite a few times. Though sometimes being the target of jokes, this holds a very important role in the “web”. It gives stability. It shows people across the company that we know what we strive for, we know what we put blood, sweat and tears into in our day-to-day. This is what we look at if we feel at a loss, if we’re trying to figure out the next most important milestone. This guides product vision, priorities, resource needs.

This north star shouldn’t just appear in the sky, this should be the outcome of meticulous meetings, discussions, inceptions, and strategic planning. This needs to be chosen carefully, needs to be concrete enough, so people can believe they can reach it, but needs to be flexible enough to be resilient to internal or external changes over the period it is set for. Having this right is not an easy feat.

I can already see comments, that is not how it works for small companies, for outsourcing-type companies, but it is, as this north star could be anything, but it needs to be well-tailored to the specifics to the company. It could be a financial goal (if you’re open to honestly sharing financial details with everyone in the company), could be a resourcing or a product goal.

Product vision is more relevant to certain companies than others. Due to trying to keep this post shorter, I’ll write this part from the aspect of a product company having a product north star, though this could be tackled from a number of different aspects of different company types and north stars.In our case the product vision is all connected to the “north star”, all product goals are stepping stones, showing the path towards the north star. It's usually easy to communicate to the company, easier to be understood by individuals, and can be drawn in detail, explained with clarity. All tactical plans can be aligned to this, all discoveries, investigations, technical decisions can be weaved to this plan.

In the center of all of this is the “product team” they have ownership over the full plan, which means they have a lot of burden to bear. They need to have good communication lines created, they need tooling that allows them to track progress, they need to work together not only with their engineering counterparts, but within the product organization, and surprisingly this is lacking most of the time. For some reason, might be trivial for some, product people work closer together with the delivery teams, have a more transparent collaboration with them, then within their own organization across the areas of product. It’s not a bad thing, but needs to be balanced, as both aspects are necessary. When information runs smoothly within the product organization and decisions are made on the lowest levels that they can be made, that becomes a cornerstone of the “web”.

Is talking about technical architecture goes against the original article? Does it go against agile as a whole? This is sometimes controversial, but in my experience, having a solid guidance of technical architecture leads to exponential delivery speeds. We should have a clear governance of technologies to be used from an overall perspective. This means that it should be possible to move teams from one area to the other and technology knowledge should not be the biggest obstacle to do so. It should be possible for a newcomer to understand the building pieces, why those were chosen and how they work together. There should be a process to look for optimizations either by using newer, stable versions of the same technology, or to look into and create PoCs for the same challenge by using different, maybe more specific technologies or architectures. There should also need to be a financial and resource budget within that process and the ownership of this has to be clearly defined.

Transparent communication is a topic of its own, and this might be the next post in the series, but has to have a place here as well at least as a mention. For a team to be able to do quality job, it needs to understand what is the goal they should work towards, they need to decide how they’ll work on it and people need to be there for them to support if needed. So to be more concrete, a person from the product team needs to communicate clearly, what are the next milestones and why. The team needs to figure out how to do them and what’s the timeframe they can be done in quality. Engineering management needs to be there to clear any obstacles, resolve conflicts, manage change along the way. The “web” will never exist without transparent communication, this prevents people from working in silos, it prevents confusions, adds confidence, adds motivation. Having transparent communication top-down, bottom-up and across areas within a function leads to success even without clearly pre-defined milestones. Fixing a broken communication strategy can strengthen or save a company, it can prevent a lot of fluctuation in the workforce.

And yes, the good old topic of knowledge transfer, documentation and clean code… :) It’s always a controversy, it always strikes heighted discussions, but it’s a thing of necessity, it’s not optional and there are a few good reasons for it even with agile being the buzzword for a while. I’ve heard many times that creating documentation just for the sake of documentation doesn’t make sense, and even though the words sound correct, it’s never for just the sake of it. One needs to think about a variety of things why documentation (some kind of) is a necessity. Some of these are onboarding, accidents, vacations, organizational changes, expansion of the company, and we could go on and on. And yes, it’s not just about the creation, but the maintenance of the documentation, so it’s helpful to think about the way, the structure, and the usage of these documents before starting to do it, create a process for it and based on that organize the already existing ones at some point and stick to the process.

On a partially different note, having different levels of knowledge transfer sessions regularly contributes as well or can serve as a way of sharing knowledge. The regularity should be decided based on the level of the sessions, is it a team-internal one, a cross team one, an organization or company level one. The higher level you go the less frequent these can be and will be talking from different aspects. Having these practices set up and kept will speed up delivery, mitigate a number of risks in the organization, but should be acknowledged as cost.