Don't Get Bullied

In dealing with multiple groups that have sometimes conflicting agendas, and almost always conflicting value systems, confusion can reign. After one such recent encounter, I wrote an opinion piece to help a beleaguered business analyst fend off some bullying by some techie types. Here's a sanitized version of that email:

Generally speaking, I notice people tend to either speak too high level or too detailed. It usually a function of the point they are trying to make that coincides with their particular opinion. ;-)

Getting an accurate answer without excruciating detail can often be achieved through a discussion about groups of attribute behaviors (which can be called a class). Regardless of many attributes or few, attributes can usually be grouped into a manageable number of groups by their behavior. These groups (or classes of behavior) are much easier to manage because they are specific, distinct, and typically much fewer in number. Any attribute under discussion can then be placed in a group, which means we don't have to know about every specific attribute up front, or even be correct about which attribute is in which group. By talking about these groups (or classes of behavior) we can all stop confusing each other with overly specific or overly general examples.

So what defines these groups (or classes of behavior)? The location and process by which an attribute is created or maintained is usually a good starting point. For example, some attributes (say product SKU) will come from ERP and cannot be edited outside of the ERP regardless of how it is consumed downstream. All attributes that come from and are maintained only within ERP share the same behavior and are therefore part of the same class (they are in the same group). For simplicity, we can consider these primary or core attributes.

If we further consider that some attributes will need to be created and maintained only by a downstream consuming system, we see that these attributes share a class. We can consider these isolated attributes. Perhaps some group of attributes are created in the ERP but can be edited or over-ridden in a downstream consuming system. These attributes also share a class. We can consider these to be extended attributes.

While this small number of classes (primary, isolated, extension) already cover our current needs, should we have additional behavior combinations (say sourced in ERP, and only over-ridden but not edited) we can certainly introduce additional classes. In practice, usually only a very small number of behaviors is required.

By disconnecting the discussion from specific attributes to the groups of attributes, it is possible to manage the risk that whichever way the schema evolves, the technology to support the different necessary behaviors will be supported. For example, knowing that we must support both isolated attributes and extended attributes ensures the schema will be able to express the difference and our replication and management processes must respect that behavior. Our solution will suffice, regardless of which (or how many) attributes ultimately end up classified in this way. More importantly, we can stop getting off-topic with discussion about specific attributes.

What prompted the email was watching a vicious cycle repeat wherein the business asked for a capability that was complex, the technologists offered a simpler solution for specific cases, the business came up with yet another different complex example which prompted the technologist to revise the solution, etc. Both parties grew frustrated. The business didn't think they were being heard and worried about what they thought of as unknown gaps in the future solution. The technologist were struggling to create a high-level solution approach while constantly responding to low-level assumptions of how their solution should be implemented. Getting both sides to stop pushing an agenda is difficult but can be easier if you introduce terminology that is new to both parties. When they both have to take time to translate their opinions into a common vernacular it becomes clear which points are significant and who might just be causing trouble.

The primary-isolated-extended pattern above is a very real pattern that I use in my every-day to help make sense of extremely complex enterprise-wide data flows. It really works. From the most advanced techie types, to the simplest business types, it is a tool that they can all understand. So now when they are bludgeoning each other in meetings, at least they are all using the same patterns to do it.

Talk More, Write Less

In some recent conversations, I've been helping a client to optimize their software development processes for a large, mult-site delivery. As we discussed how these resources who were used to working on small teams were going to be impacted by now working as a big team, a point of contention was the method for collaborating.

When working with big teams, I try to structure the collaborations to be proactive rather than reactive. Namely, I set expectations that all team members should proactively seek out the information needed to do their jobs instead of establishing large-format, formal information publishing channels. Until now, I've never had the empirical evidence besides years of experience to substantiate this position.

The gang at MIT in Human Dynamics was obviously struggling to promote this position and conducted a study to prove it. The study is actually really insightful in lots of aspects of workplace productivity, but especially in the need for high-touch collaborations.

The study used cool devices they call sociometric badges that are equipped with infrared sensors, accelerometers, and microphones. These devices trace proximity, tone, gestures, and so forth. They paint a much more complete picture of face-to-face interactions.

The results of the study supported a couple of conclusions that speak directly to how experience has shown we should organize our teams and the communication processes.

For the study, they put these special sociometric badges on a team of 23 employees who work for an IT company in Chicago designing server systems. Over the course of a month they tracked everyone through about 900 jobs. The jobs ranged from little activities of 5 minutes to larger efforts requiring multiple days, all told they tracked about 1900 hours of work. They monitored time spent on the job, each activity, every interaction and a host of other variables. The interpreted result is that the most connected employee was 60% more productive than the least connected employee.

[aside] The badges are powerhouses of information gathering and include accelerometers to gauge movement and speed, microphones which can discern tone and cadence, radios to capture proximity to other badges and location information, and much more. Can you say Internet of Things?

Read more here.

But just being connected is only the start. The point in time that disruptions happens is also important. If disruptions came while trying to accomplish a task, productivity dropped. Lack of disruption between tasks also resulted in decreased productivity.

Boiled down it revealed that an increase in the standard deviation of network cohesion by 1 resulted in a ten percent increase in productivity. The more they collaborated, the more productive they were.

This is not a license to gossip at work, but it is good evidence that going to lunch with colleagues, management by walking around, frequent breaks, socialization amongst peers, and self-service learning and systems are the keys to maximizing productivity.

These highly productive behaviors are all proactive behaviors. They are successful because they set expectations for individuals that they need to participate in the group and seek out connections and information. These behaviors reward collaboration and penalize isolation. If your organization is constantly seeking for the right way to spoon-feed information to individuals instead of asserting individual responsibility for learning and connectedness, you aren't working in a high-performance organization.

If you want to recognize the potential for productivity, looking for these behaviors (or their antithesis) is a good place to start.

It's Been A While

Today I saw a software architect at work. It doesn't happen very
frequently. Coming across someone that actually 'gets it right' and
demonstrates the true behaviors of a software architect is sort of
like winning a sweepstakes. Or more likely a local charity raffle. It
does happen, but it is pleasantly surprising nonetheless.

An architect has Vision.
An architect has Will.
An architect has Influence.

Like most good communication, it starts with a picture. For an
architect, this picture starts in the mind. It starts by listening,
and asking questions, and collecting the liquid perspectives of the
contributors and decision-makers and audiences and consumers.

Once there is a Vision, and sometimes before, a true architect relies
on their Will to align differing agendas, find common goals and
messages, and establish direction, approach and criteria for success.
In many situations Will must be exerted to extract necessary
information, expose individual perceptions, and uncover truth.

The exercise of Will to realize a Vision through the efforts of others
requires Influence. This is distinct from manipulation because it is
transparent and all parties are aware of the exchanges and the goals.

Until you acquire a Vision, your Will is pointless. Without Will, you
will have ineffective Influence. Without Influence you will have a
hard time achieving anything, and what you do achieve will be
inefficiently gained or comes only at personal cost (time, integrity,
relationships).

Today I actually saw an architect at work. It was a beautiful and
inspiring thing to witness.