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.

Finally Some Usable Storage

I've tried a boatload of different synchronization tools and finally found one that actually works as advertised and meets my needs: Dropbox. Since I'm a very picky consumer (read: perfectionist), it is rare that I say a product is very good.



So what makes this product unique? It works simply, works quickly, and it is free for normal consumption. Considering that my definition of normal is anything but the norm, that's a big statement.

Basically, you install the Dropbox client on your machine (Windows, Mac, Linux, what-have-you) and set the location for your Dropbox files. Anything that shows up there is automatically updated on the server. By using multiple clients with the same account you get real-time-enough (that's a technical term) synchronization across multiple machines.

I use Dropbox for all my OneNote notebooks. And my work documents. And some source code. And some pictures. Pretty much anything I want to have A) backed-up automatically and B) available anywhere.

Your free Dropbox account is limited to 2GB of data, and even for a storage hog like me this is plenty. And did I mention that the synchronization is fast? That's because it looks inside and synchronizes parts of files.

I use a notebook, a netbook, a Mac, and a desktop PC throughout every day for work. As I was typing meeting notes into OneNote on the netbook I noticed it synchronizing in the background. Every few minutes the alert on my desktop popped up that updates were downloaded. Talk about peace of mind. When I'm done for the day, I walk out with my netbook knowing all my machines have the same information on them. I can edit any file on any of the machines and they all just stay in sync about as fast as I can switch from one to the other. When I type a new article on the plane, as soon as I get home, my laptop syncs. In the span it takes for my Mac to boot up, my files are already being downloaded. I can get right to work knowing I'm using the latest versions of the files, hassle-free and worry-free.

For a while I was using the Gladinet software but it wasn't reliable, was too slow, and expensive. The GoodSync tools are really slow. In addition, it won't run on my desktop PC because I run Windows Server (boo!). With both of these, as with most of the sync solutions I've tried, the synchronization algorithm doesn't look inside the files so I was able to confuse the client with multiple updates and then lose some data. Inevitably this happened and pissed me off. And of course both of these cost money too.

Among other things, I keep a Box.net account, a SkyDrive, a private FTP server, and heaps of both Amazon and Google Storage. Most of this is for work and collaboration, and I use them for encrypted back-ups too. But none of these make moving my data around easier than Dropbox. If Box.net (my previous favorite), or any of the big boys wants to know how to do synchronization right, check these guys out.

And no, I'm not paid for this, I'm not affiliated in any way with Dropbox et al. I just rarely get the chance to toot the horn of something truly great and with such mass appeal.

The Gorilla in the Clown Suit

In my line of work, you deal with all sorts of different "leaders" and "managers". Typically, they've achieved their position through some confluence of skill, opportunity, and luck. They all have their positive and negative attributes, depending on the needs of the situation and your vantage point.

The one I find most fascinating though is the Gorilla.

The Gorilla type of leader is epitomized by being unruly and unpredictable, beating their chest when things are rough, blundering around leaving banana peels for others to trip up other people, and applying brute force to solve any problems they can't avoid by putting their hands over their eyes. Oh, they seem intelligent enough at first, but don't forget that their typical response to even minor irritations is to start flinging feces.

When trying to identify a Gorilla, watch for them to put their hands over their eyes. You will notice this by listening to how they handle ambiguous requirements. You will often hear them using phrases like "I interpret this to mean. . ." and "I think what was intended. . .". They will insist on asking everyone to estimate their completion dates, but are totally uninterested in keeping track of the actual work required to hit those dates.

Because they don't actually manage risks (or a traceable work plan) their project will inevitably have unexplained delays. They handle this through beating of the chest in more meetings about the dates and the issues. In these meetings they studiously avoid detailing the actual work involved or assigning any accountability. Unless of course, they think they can pin blame on some small monkey. At this point, they jump right on top of the unsuspecting ape and demand a full accounting.

While this chest-beating occurs, they routinely change the process and expectations. This creates wonderful opportunities for others to fail in meeting these new expectations or realigning to the new process quickly enough. These little banana peels are perfect for tripping up the unsuspecting. These little slip-and-falls usually provide them with several potential candidates for assigning future blame.

With all this mayhem occurring, the delays generally get worse, which means they now need to apply their brute gorilla strength in an effort to get things back on track. Since they haven't really been paying attention, and there are banana peels everywhere, this is harder than it sounds. So of course, now they get frustrated and voila! the feces flinging commences.

If you find yourself working with (or heaven-help you FOR) a Gorilla, keep these simple rules in mind and perhaps you'll do okay.

First, don't look them in the eye. Calling out that the endless meetings is a bad idea and unproductive is like poking the gorilla with a stick. It will only get you labeled as "uncooperative" or "not a team player". Instead bring your laptop and get your own work done if you have to be there in person. If possible, make it a conference call so you can put yourself on mute and get something done while the gorilla beats his chest.

Secondly, watch the ground for banana peels. If the rules are constantly changing, give yourself plenty of time to do lots of non-value-add work aligning and re-aligning. This means get your monkeys up in the trees away from the gorilla so they can do the real work. Keep them isolated so that if (or more likely when) you stumble into one, you're the only one that gets hurt and your team stays productive.

Lastly, find and maintain a poncho. Inevitably with a Gorilla there will be flung feces and finger-pointing. Make sure you've cataloged and highly publicized your risks and issues while maintaining transparency with your schedule, dependencies, and work plan. When things do turn nasty, keep your cool and trust in your poncho. If you've kept your poncho in good repair (being transparent and publicizing early and often) you should be prepared for the worst of it.

In closing, it's worth pointing out that Gorillas aren't all bad. They are especially useful in death marches and suicide missions. When what is being undertaken is just completely unreasonable or the situation will likely require someone's career if it is to be successful, a Gorilla is a great candidate. When the situation is already beyond repair and you are just trying to salvage something, then chest-beating and brute force are great strategies for maximum gain. As a leader of multiple teams, unleashing a Gorilla to work for you is a quick way to identify which teams have their feces together and which people on which teams are worth saving. Good resources will escalate around a gorilla, and good peers will already have their ponchos firmly in place, rendering the gorilla ineffective.