tag:blogger.com,1999:blog-190387562024-03-13T14:07:23.257-07:00Liquid PerspectiveThe Business of Life through the eyes of a trained negotiator and experienced entrepreneur.Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.comBlogger92125tag:blogger.com,1999:blog-19038756.post-37609208894713349812016-04-18T12:16:00.004-07:002016-04-18T12:16:48.092-07:00Security or Something Like ItAn interesting conversation happened around me today about all the high-profile data breaches that have occurred and could they have been prevented. There was of course, the one lunatic who was valiantly arguing they could have but weren't because of some grand conspiracy.<div>
<br /></div>
<div>
The unfortunate thing was that at the core, he was correct. Security is possible, and not nearly as hard as we think. Just harder than we would like.</div>
<div>
<br /></div>
<div>
As I organized my internal retort I realized that cause and cure, like many things, are very much related. So I wanted to write my thoughts while fresh, for your amusement.</div>
<div>
<br /></div>
<blockquote class="tr_bq">
The crux of making security <i>accessible and easy</i> is reducing the factors and the bits involved. The crux of making security <i>robust and reliable</i> is by increasing factors and adding through division to increase the number of bits involved.</blockquote>
<div>
<br /></div>
<div>
Let me explain through gratuitous use of some over-simplification.</div>
<div>
<br /></div>
<div>
When logging in with a name and password I only have the two bits and the one step. If that login grants me access to a system that lets me access customers and their details and transactions that is easy for me to use.</div>
<div>
<br /></div>
<div>
If you want to hack me, just get my two bits and go to town on everything. This is vulnerable.</div>
<div>
<br /></div>
<div>
Today, the big thing is to add an additional factor, for two-factor authentication. This is just one part of the way to three-factor authentication is which about the most you can ask for with today's accessible technologies. A simple way to explain three-factor authentication is that requires <b>something you are, something you have, and something you know</b>. In modern two-factor, we use a phone or fob as the "something you have" and the password is the "something you know". This is because we haven't really gotten wide adoption on "something you are" like fingerprints, retinal scans, or other bio-metrics. Some of you may have experienced with this for passport or other controls where they've taken your fingerprints or retinal scan but this isn't exactly day-to-day for most people.</div>
<div>
<br /></div>
<div>
When there is only one step, the authentication part is addressed by adding these factors and so they make it harder to use. If you want to address the other aspects of security, you also need to add more bits.</div>
<div>
<br /></div>
<div>
Going back to our example, suppose if I had split the data such that customer data was saved in one system and transaction data was saved in another. I've divided the data which adds more bits. Or I could separate the work into two steps (request work, commit work) done by two different actors. This is on the way to the Four-eyes principle which requires two people collaborate to complete an activity. Notice, they're both addition by division, one is data the other is people.</div>
<div>
<br /></div>
<div>
You could extend this again to real-time audit and detection systems that use the same technique to determine if the work being performed matches some normal profile. This works by dividing control into normal processing and oversight. It adds bits but catches discrepancies between systems.</div>
<div>
<br /></div>
<div>
In the end, it's easy to throw more encryption and say that it will fix any security vulnerabilities that might exist. In reality, unless the number of bits involved doesn't change, you're just pushing the vegetables around the plate. You can add factors to reduce entry vulnerabilities, or use addition by division to increase the number of bits and change your overall vulnerability profile.</div>
<div>
<br /></div>
<div>
You can have it easy, secure, or fast. Pick two.</div>
<div>
<br /></div>
Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com1tag:blogger.com,1999:blog-19038756.post-84928425603185677332015-10-08T11:14:00.000-07:002016-01-08T11:14:44.814-08:00On Being A ConsultantI've been an engineer for multiple decades. I've been a consultant for more than a decade. I've only been a great consultant for a few years.<br />
<br />
It took me a few years to become an master engineer. It took me decades to become a master architect. It has taken me longer to become a master consultant.<br />
<br />
Growing up through the ranks of Microsoft and shipping products such as Visual Studio can teach one the value of delivering technical excellence, but not necessarily the soft skills and relationship management to make the process smooth and experiences positive. In truth, surrounded by anti-social geniuses it was as easy to learn bad business habits as it was to learn set theory and how write <a href="https://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/" rel="nofollow" target="_blank">elegant code in one pass</a>.<br />
<br />
Becoming capable as a consult required an unlearning of many aspects of the engineering value system. Similar to the <a href="https://en.wikipedia.org/wiki/Nash_equilibrium" rel="nofollow" target="_blank">inspired theory</a> made famous in "A Beautiful Mind", it requires solving for more than one definition of the right answer. Which inherently invalidates the idea of getting something right the first time without any interaction.<br />
<br />
As I learned to find a balance, I realized that I enjoyed the <i><b>process of finding this balance</b></i>. That bringing together strictly technical elegance and the wider spectrum of elegance in business was in itself a unique type of challenge that I found rewarding. Which is why I have not found myself particularly at home in large corporations doing maintenance on legacy systems year in and year out. Or even within the same enterprise solving and re-solving the same problems over and over for incremental refinement. Instead I am most at home when I can bring together seemingly unrelated solutions to craft evolutionary advancements where the impact can be significant. For example, using the same sophisticated algorithms that solve just-in-time manufacturing problems but applied to slotting seats and routes for an airline. These problems are many but they are intrinsically non-repeating. And therefore making a consistent income from this type of interesting work requires exposure to many industries and many clients. If one wants to keep doing innovative work for innovative companies, one must always be searching for the next bit of innovative work. And therein lies the rub. While I am working, I prefer to be focused on my work, not on finding the next bit of work that will bring me income once this current bit of work is completed.<br />
<br />
Which leads me to the online marketplaces and project boards as a means to expand the pipeline of available opportunities. Recently I decided to start working with some "new" agency types as a means to extend my network. While my social and client network has no seeming end to the need for talents such as mine, there are indeed limitations and the idea of increasing my pool of opportunities from a much larger perspective is enticing. Previously I have been reluctant to post my profile in more publicly trafficked spaces because of the lack of oversight and proper vetting. My time is valuable and my talents unique, so it makes sense that I would employ a buffer between my time and the deluge of clients who don't appreciate that I am not the best choice to build the <i>[landing page|brochure|insert mundane UI here]</i> for their <i>[flower shop|dry cleaners|insert small business here]</i>.<br />
<br />
After a few experiences I have concluded that these "new" types of agencies are really the same old staffing agencies and development shops in disguise. The worst of these has been TopTal which is really just a bunch of elitist shysters who have found an interesting marketing approach to increase their margins while providing no additional value.Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-39737279262002113382015-05-08T11:12:00.000-07:002016-01-08T11:13:35.251-08:00The Iron TriangleThere is a concept in technology known by some as the Iron Triangle. I tend to approach it through the simple adage:<br />
<blockquote class="tr_bq">
You can have it fast, cheap, or right. Pick two.</blockquote>
What this tries to make clear is that building anything requires a trade-off between how quickly you want it done, how much you are willing to pay, and how important it is to meet a need completely. The first tends to be obvious, because everyone wants everything as soon as they can get it, preferably now. The second is also straight-forward because everyone tends to think that everything should be low cost, preferably free. The last one is where things start to get complicated.<br />
<br />
Do you value performance? Accuracy? Precision? Reliability? Maintainability? Scalability? Everyone has their own ideas about what "right" can mean, and sometimes they don't even bother to understand what they think "right" might mean before they start making assumptions. In the same way, we just assume everything is free and everything will be done right away, we blindly assume everything we produce will scale easily, work repeatedly and be easy to maintain. We might be asking for a very intricate algorithm, but we don't even bother writing down the nuances of all the conditions and error cases.<br />
<br />
How can anyone accurately estimate the effort to build something without having a solid definition of what "done" means? If you can't take time to write down your expectations, it seems unreasonable to get upset when these hidden expectations aren't met. Simply put:<br />
<blockquote class="tr_bq">
A lack of planning on your part, does not constitute an emergency on my part.</blockquote>
It's good in theory. But in practice, people seem entirely comfortable being completely unreasonable on a regular basis. Which I suppose keeps consultants like me in business. So no complaints here, just observations.Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-6590143005036499592014-11-11T20:53:00.001-08:002014-11-11T20:53:14.191-08:00Spotify = Evil and Un-American<div>I read this: <br><a href="http://www.engadget.com/2014/11/11/spotify-ceo-taylor-swift-payments/?ncid=rss_truncated">http://www.engadget.com/2014/11/11/spotify-ceo-taylor-swift-payments/?ncid=rss_truncated</a><br></div><div><br></div><div>And wrote this:</div><div><br></div><div><div>So Spotify licenses 20M songs. Assume half are never played. The remaining songs split amongst the 2B they've paid out means they're paying an average of $200 per song. Total. To date!</div><div><br></div><div>So assume a top seller is earning 100 times that and pocketing 20k for their song and most are earning in the $2 range. Obviously the artists are upset and they should be.</div><div><br></div><div>Spotify is the Walmart of streaming music; creating an unsustainable consumption model of greed that is a blight on the earth and the enemy of anything that is decent and just.</div></div>Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-55603732392211970502013-11-25T09:57:00.000-08:002013-11-25T09:57:26.181-08:00Reference vs Master<div dir="ltr" style="text-align: left;" trbidi="on">
Had an interview this morning with some industry analysts who were researching Enterprise Architecture subjects. Per usual, the subject of Master Data Management came up. As sometimes happens, I verbalized something quite important that I previously hadn't had a chance to write down.<br />
<br />
In the conversation, we went through the last eleven (11) master data management initiatives I've been involved with and looked for the common thread. In every engagement where I was called in because they were failing and in every engagement where we collectively failed, it was because Master Data was attempted before Reference Data. In every case where the engagement went smooth or where we were able to get things back on track, it was because we prioritized a single case of Reference Data and then iterated.<br />
<br />
This seems glaring obvious in retrospect. Prior to this impromptu postmortem, I hadn't realize our collective experiences painted such a clear picture of how not to screw something up.<br />
<br />
If you are thinking about Master Data Management, you first need to build good Reference data. The underlying reason is that most people, even architects, don't fully understand and recognize the difference. Since we don't always separate these types of data, we don't always prioritize properly and then we are focusing on a moving, complicated target and this increases the likely of challenges leading to failure.<br />
<br />
Reference data is non-volatile, exists independent of business process and interactions, and is globally identifiable. Master data is slow-changing and can exist independent of a business process. A geographic location (lat/long) is reference data, whereas a physical address is master data. An address, like many kinds of master data, is built from reference data. For example, an address may include a geographic location. The name of the building might come from master data but the name of the region or country would come from reference data. Why is a country name reference data but the name of the building is not? Because of the global identification. If the globally identified data comes from an outside source, managed externally, then it is reference data. Understanding which components of your data constructs are reference instead of master is the first, most crucial step.<br />
<br />
Why did the prioritization for reference data become a leading indicator for success? Because reference data is non-volatile and can withstand the winds of change within an organization. It gives an immovable target with quantified, known complexity that can be addressed. And like other forms of data it needs to be published, consumed, syndicated, replicated, secured, and so forth. Rather than figure out how these functional and technical capabilities must be delivered and iterated within your organization using volatile data of potentially unknown complexity, you can first provide these functions using data constructs of known complexity and fixed definition. Only once you have a tried and tested cadence for the cyclic functions, and proven templates for the iterative functions, can you then embrace more complex and volatile master data.<br />
<br />
A real world anecdote is from a conversation I had a few short months ago with a colleague struggling to get traction on a Master Data Management engagement. This organization had multiple sources of customer data and like many organizations had determined they needed a master customer record. But how to wrangle twenty-seven (no joke, they have 27 customer relationship management systems!) and their dependent systems into all using a single master. To start with they all have different formats, fields, and definitions. They had many different ways to identify a master record and many allowed multiple records for a single customer for various purposes. When you expanded to include the down-stream systems that relied on those CRM databases the number exploded to over a hundred. No one wanted to take on the challenge and I don't blame them.<br />
<br />
We made a plan, which they followed and they are now on they're sixth successful iteration.<br />
<br />
Rather than try consolidating the entire records straight away, we just started with customer name. They created an extremely simple reference data-set of all customer names by pulling extracts from all systems. Every entry was given a unique key that matched the key from the system it came from. This list (10+ million records) was run through de-duplication and data quality software. What resulted was a single list of unique names with unique identifiers. Each unique identifier had alternate keys attached for as many of the source systems as had references for that customer. Then we published it at a fixed location and made it available in several ways (SQL, XML, CSV, etc).<br />
<br />
Each system then undertook an exercise at their own pace of reconciling their data with the master list. Some used replication and pulled the master list nightly just making the single list their new source. Others used a combination of queries and manual entry to reconcile. By calendar week 8, 30% of the systems were using the customer name master list as a fully integrated data source.<br />
<br />
It only took two weeks for the data mastering crew to clean and prep the customer name master. Which they handed off to the support team who helped all those systems with consuming that data. By calendar week 6, the data mastering crew handed over an address master to the support team. By calendar week 12, 30% of the systems were using the address master lists as fully integrated data sources.<br />
<br />
By calendar week 8, the data mastering crew handed over employee and organization master lists to the support team. By calendar week 12, they had handed off office, contact information, and account.<br />
<br />
The organization is 5 months in and they have 90% integration across all systems for customer, address, employee and organization. Along the way they have established and iterated patterns and processes for replicating data, auditing compliance, publishing secure feeds, and publishing secure subsets of data by organization. They even decommissioned two smaller systems just by cleaning and securing access to a single list of list. There are 11 more planned for decommissioning over the 6 months.<br />
<br />
They got their footing by focusing on reference data. Every time they take on a new set, they first start with the reference data. Allowing them to separate this means they can separate the application from the data just enough to make progress. Once they get the pattern in place, they iterate to add complexity and features and expand the data set. It's methodical and direct and mostly non-threatening.<br />
<br />
At the time, I didn't have a codified reason for why starting with reference data was so important. Now I've written down why it was good advice.<br />
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-91414278823670863622013-08-26T09:53:00.000-07:002013-08-26T09:53:17.513-07:00Quantified ALM<div dir="ltr" style="text-align: left;" trbidi="on">
In most good consulting approaches, they start by pointing out that the way to effectively change something is to first measure it. If you can't measure it, how will you know it changed? By how much? For what reason?<br />
<br />
Being able to measure is a cornerstone of any good management approach. It's the cornerstone of the quantified self movement which is built around the premise that once you measure something, being able to change or maintain becomes much easier.<br />
<br />
With software and technology, this is no different. When it comes to the application lifecycle the ability to measure is just as necessary. Unfortunately, ALM tends to evolve at a fairly slow pace. While there are pockets of innovation, true change only happens inside big, slow, enterprises that are typically not being managed by the most *cough* technically astute. As such, they might ask for measurements but this largely for show. If you don't understand what you are measuring, how relevant can the measure be?<br />
<br />
The gents over and McKinsey took a swipe at this in a recent article:<br />
<br />
<a href="http://www.mckinsey.com/Insights/Business_Technology/Enhancing_the_efficiency_and_effectiveness_of_application_development?cid=other-eml-alt-mip-mck-oth-1308">http://www.mckinsey.com/Insights/Business_Technology/Enhancing_the_efficiency_and_effectiveness_of_application_development?cid=other-eml-alt-mip-mck-oth-1308</a><br />
<br />
While I think just substituting Use Case Points as the answer to how to measure is an easy thing to propose, it is certainly not the only or most obvious choice for addressing this significant need. The article does, however, break down the aspects of the problem and exposes some of the challenges that have created the situation in the first place. It is a good contextual read and likely to provide at least one uncommon perspective on something we take for granted but shouldn't. Definitely give it a read.<br />
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-42608043533322107252013-04-23T09:19:00.000-07:002013-04-23T09:22:24.050-07:00Component Interaction Diagrams<br />
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
If you are going to
work with other people to build something, you need a way to communicate
clearly about what you are building.
From ages past, the clearest way to do that was by drawing pictures. With software, we do the same thing. Most tools, and methodologies have different
techniques, diagrams, and types of illustrations that are central to their
documentation approach. I'm familiar
with most of them. Over the years, I've
refined the best parts of each to construct a set of diagram that follows the
Key Principles and allows me to Move Quickly In the Dark.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
The first is called
a Component Interaction Diagram, and the second is a Process Flow Diagram. In reality, all of the documentation formats
across the various methodologies and approaches have their strengths and weaknesses
and are proposed by smart people for varying reasons. With a Component Interaction Diagram (CID)
and corresponding Process Flow Diagram (PFD) we attempt to focus the diagrams
so that it provides the maximum value with the least effort and stays relevant
for the longest amount of time to the widest possible audience. Rather than try and justify the format up
front, I'm going to explain the how you create them. As we discuss each aspect of the diagrams and
the guidelines for them, the reasons for each will become apparent. If they don't, perhaps you'll find clear
reasons why you prefer whatever documentation you have chosen. </div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<span style="font-weight: bold;">Component Interaction Diagram</span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
A Component
Interaction Diagram (CID) has a singular purpose. It is depicts the components utilized in a
particular solution scope and the points of interaction between them. How it does that, the information that can be
layered on top of it or derived from it, and the variety of ways that it can be
utilized are all secondary considerations.
The way in which we meet the primary purpose is what will allow us to
use it to maximum advantage for the widest audiences. So as we go through the guidelines and
process of creation, consider all the downstream impacts and you'll understand
why it requires such rigid precision.
You'll also uncover areas where you can forgo precision or formality,
and the consequences of choosing to deviate.
In many cases, you may be perfectly happy with only reaping some of the
benefits, a decision which would merit following an abbreviated process.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Okay, with the
disclaimers and background out of the way, let us begin with the guidelines. </div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<ul>
<li><span style="font-size: 11pt;"> A given CID should have a clear, identified
and immutable scope that is independent of time.</span></li>
<li><span style="font-size: 11pt;"> Use symbols to represent the components in
scope for a given diagram.</span></li>
<li><span style="font-size: 11pt;"> Use lines to represent interactions between
the components in a given diagram.</span></li>
<li><span style="font-size: 11pt;"> The consuming or external components are
placed in the left most region in a given diagram.</span></li>
<li><span style="font-size: 11pt;"> The persistent storage or most granular
processes are placed in the right most region in a given diagram.</span></li>
<li><span style="font-size: 11pt;"> Do not depict containment.</span></li>
<li><span style="font-size: 11pt;"> Do not depict state, sequence, or
directionality.</span></li>
<li><span style="font-size: 11pt;"> Do not depict the flow of data or process
logic.</span></li>
<li><span style="font-size: 11pt;"> Environmental or grouping boundaries are an
accepted practice.</span></li>
</ul>
</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<ul>
<li><span style="font-size: 11pt;">Use different symbols to represent
components of different types.</span></li>
<li><span style="font-size: 11pt;">The set of symbols in use should be
consistent across a given set of diagrams.</span></li>
<li><span style="font-size: 11pt;">Symbols should not contain other symbols.</span></li>
</ul>
</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br />
<ul>
<li><span style="font-size: 11pt;">Every component should only exist once in a
given diagram.</span></li>
<li><span style="font-size: 11pt;">Every component should have a unique
identifying label in a given diagram.</span></li>
<li><span style="font-size: 11pt;">Classes, tables, and other structures
containing state are represented as separate storage components.</span></li>
<li><span style="font-size: 11pt;">Methods, functions, and other processing
constructs are to represented as separate process components.</span></li>
</ul>
</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<ul>
<li><span style="font-size: 11pt;">The should a minimal number of formats for
lines in a given diagram.</span></li>
<li><span style="font-size: 11pt;">There should only be a single line between
any two components in a given diagram.</span></li>
<li><span style="font-size: 11pt;">Every interaction line should connect
exactly two components in a given diagram.</span></li>
<li><span style="font-size: 11pt;">Interaction lines should not have labels,
but line format may indicate classification.</span></li>
</ul>
</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<ul>
<li><span style="font-size: 11pt;">Utilize call-outs to describe details in
common language about a specific component or specific interaction.</span></li>
<li><span style="font-size: 11pt;">Utilize note boxes to provide context for a
set of components or to describe the interaction semantics.</span></li>
<li><span style="font-size: 11pt;">Utilize note boxes to provide rationale for
the approach, usage recommendations, or exception semantics.</span></li>
<li><span style="font-size: 11pt;">Always provide a legend for symbols and line
formats if there are multiple.</span></li>
</ul>
</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<span style="font-size: 11pt;">Since the guidelines
are fairly rigid, let's discuss the intent and reasoning for the common areas
of concern.</span></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
A diagram should
have a particular scope independent of any particular processing state. Ensuring that every component only shows up
once on the diagram allows the diagram to serve as an inventory. By ensuring
there is no state or sequencing this allows us to track completion against the
inventory independent of the orthogonal or cross-cutting nature of the
components. Simply put, a component is
complete for a given diagram when it satisfies the interactions present on
given diagram. Enforcing that each component only shows up once allows for an
accurate depiction of multiple dependency and ensures that polymorphic or
iteratively developed components and functionality libraries are properly
decomposed.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Adding state,
sequence or flow to a diagram requires the introduction of time which modifies
the scope. The nature of state, sequence and flows means the diagram would not have a clearly delineated scope.
Introducing time information to a CID requires that the user understand the
particular pre- and post- conditions to validate the scope of the diagram. This
will inevitably complicate the diagram, often requiring multiple diagrams and
that the audience makes assumptions about the nature of the components or
interactions. All of these side effects
will allow a single diagram to have multiple interpretations which can all
appear accurate. For these reasons and
others this information should be represented separately in a Process Flow
Diagram using the symbols and components from this diagram. </div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
For a particular set
of diagrams to be consumed easily by a variety of audiences, the information
needs to be presented consistently.
Therefore positioning components consistently within a diagram provides
the ability to perform comparisons between diagrams and to follow interactions
through symbols across different diagrams.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Components on a
diagram need to stand independently so that the their attributes can be
granularly managed for inventory, tracking, and validation. Containment makes calculation and attribute
management very difficult and can introduce artificial assumptions about
scope. Decomposition becomes unwieldy
and harder to validate with the introduction of containment. The use of bounding boxes or shaded
backgrounds for grouping is an accepted alternative but should be used
sparingly to reduce complexity and ease consumption.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
The two major
classifications of components that are appropriate on a CID are components for
storage and for processing. Decomposing
processing components are usually self-explanatory with the only challenge to
find the appropriate level at which to stop.
Reasons to decompose below the assembly or interface boundary include
tracking the contributing teams, the use of different skill sets, or when
implementation is iterative. Consider
that every decomposition increases the barriers to construction and
consumption.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Deciding which
storage components to decompose can be challenging. As a general rule of thumb,
only persistent or shared data structures need to be present on the diagram as
storage components. For example, a class
that is used to transmit data across an interface isn't appropriate because it
is transitive (not persisted) and is only accessed by the components
independently. Alternatively an
in-memory class that manages thread state and is monitored by a controlling
process is shared but not persistent and therefore still meets the criteria for
placement on the diagram. A file which
receives log updates or a table which is updated as the outcome of a process
are both persistent and therefore meet the criteria for use on the
diagram. In any case, all data
structures for which you desire tracking can be included. Transitive structures
are strongly discouraged because of the complications involved with fitting
them into the diagram. Again, the trick
is to balance the desire to track at the most granular level against the ease
to construct and consume these diagrams.</div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
<br /></div>
<div style="font-family: Calibri; font-size: 11.0pt; margin: 0in;">
Since my examples
are generally scrubbed for particular purposes you'll just have to contact me
if you'd like one.<br />
<br /></div>
Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-72511527078946597362013-03-27T01:30:00.000-07:002013-04-22T09:45:11.528-07:00Not for Nothing<div dir="ltr" style="text-align: left;" trbidi="on">
As someone who is often championing nimbleness and agility, people are often surprised at the level of importance I put on planning and writing things down. In the typical situation, we are discussing some objective or goal and there is just this ambiguous laundry list of tasks, activities and milestones that spews out. I insist on proper organization, writing down the relationships, and in general having all the elements of a formal plan laid out. The reason why is purely for selfish reasons based on historical evidence.<br />
<br />
Most people can't hold the complex elements of a plan in their head and manipulate it effectively. For collaboration, all parties can function no faster than the slowest member. So writing down the elements of the plan means that when we start trying to optimize everyone can follow along. This is particularly necessary when you start to execute against a plan and need to recall the reasons behind your decisions.<br />
<br />
One aspect of the plan that I typically insist on clarity about is the roles and responsibilities. Often more than just needing to understand what your outcome looks like, you need to understand why it looks a certain way, and whom is driving those criteria. This is embodied in one of the tenets:<br />
<br />
<blockquote class="tr_bq">
Learn the who and the why before the what or you will end up creating nothing for no one.</blockquote>
<br />
If you are going to react to tactical considerations while you are executing a strategic plan, you need an awareness of more than just what the criteria for success look like, but also who is defining and evaluating the criteria and towards what purpose.<br />
<br />
If you are dealing with a fickle audience, an unknown solution, or a unique innovation, the definition of a successful outcome might be sufficiently ambiguous that you won't be able to effectively optimize without a rapid feedback loop. Obviously being able to bring outcomes to an audience or test rapidly is helpful but not always practical. Being able to provide a preliminary evaluation of success without the cost of involving your constituency is crucial for agility and nimbleness. It doesn't replace the need for frequent and rapid testing, but it does mean you can often discard unusable alternatives more quickly.<br />
<br />
More important than being able to do your own work more efficiently, by grounding your criteria with their source and rationale, you validate outcome in context. There is nothing worse than doing something difficult and amazing only to realize that the impact is only felt by a fraction of your patrons. Take the time upfront to make sure you know who you are working for and why what you are doing will matter to them. More clarity with these things will help ensure you keep asking the right questions at the right times.<br />
<br /></div>
Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-83261137307105588992013-01-31T09:20:00.002-08:002013-01-31T09:20:31.225-08:00Control, Governance, and Management<div dir="ltr" style="text-align: left;" trbidi="on">
If you've ever gone through an oddly-structured, ill-timed, poorly-communicated reorganization (and who hasn't?) you are familiar with how screwed up something as simple as roles and responsibilities can become. Over the years, I've developed a simple way of helping clarify things. At least it has worked for me and others I've share it with.<br />
<br />
Let's start by clarifying the nature of the oversight being discussed. This starts, as so many things do, with getting the terminology down. <b>Our thoughts always follow our words.</b> So here is some terminology that I have used. The specific terminology isn't important, call things what you like. What is important is the way providing a definition dissects the differences in how we think.<br />
<br />
Two of the critical natures that needs to be isolated are financial and authoritative. Borrowing from industry, these are generally referred to as <b>Controls</b>. There is usually a financial Control in place to authorize incurring a cost or paying a debt. Someone is always looking after the money. They control the finances. For small and medium organizations this is also the role providing the authority or direction. While the specific authorization varies by size of organization, the distinction of control is between the <i>intent</i> and the <i>action</i>. For example, a corporate board would give <i>intent </i>and parameters of activity to an executive but would not actually oversee the carrying out of the <i>action</i>. Similarly your boss might ask you to fill out a form but isn't going to stand around watching you do it or shuffle it off to human resources on your behalf. They express an intent and parameters for action and leave the actual activity to you. Controls are the means we express intent, set parameters for and evaluate the results of actions.<br />
<br />
Moving from the abstract down to the most concrete is another industry term referred to as <b>Management</b>. These are the boots on the ground, the supervisory hands and feet of the structure. This the guy in the hard-hat watching as the workers actually dig. It is how contributors get their activity assignments and to whom they report status and completion. <i>Management </i>brings life by way of action to the intentions of <i>Control</i>.<br />
<br />
The middle is where things tend to get complicated but if you've made it this far, you can likely see that we've set things up to address the middle quite cleanly. In translating intent to actions, there is an additional role that provides the decision-making, priority setting, and so forth necessary to ensure that the Management actions are achieving the intentions within the parameters of activity established by Control. This middle structure, which in industry parlance is often referred to as <b>Governance</b>, provides this necessary translation. It absorbs the feedback from failed or variant activity, and provides corrective and deterministic input to the actions as they progress. The provide a means for multiple types of activities with potentially conflicting agendas, skills, and maturity to cohesively fulfill a given intention.<br />
<br />
Consider that a single intention ("build website") can have multiple approaches ("hire firm to build" vs "hire employee to build") and diverse activities ("create look and feel" vs "code database"). In even simple cases multiple contributors ("graphic artist" vs "sql developer") can be directed by multiple managers ("creative" vs "development") and they might have conflicting opinions on how to interpret the intention and parameters for the activity ("build website cheaply" vs "build website quickly" vs "build website with lots of bells and whistles").<br />
<br />
Management addresses the differences in a specific interpretation ("build website as quickly as possible using our existing graphics and software"). Governance addresses the differences in the interpretation and the parameters of activity for the intention ("build website with this many bells and whistles and without buying new graphics or software"). Control addresses the differences in intention ("build website within this time frame and for this amount of money").<br />
<br />
If you use the right terminology you can figure out the kind of conversation people think they are having during the confusing times. If they are trying to exert control, you can express that you believe control belongs somewhere else (or with you). If they are trying to exert management, you can express that you believe management belongs with you (or somewhere else). The point is that you don't have confront the <i>content </i>of their position, only the forum for discussion and resolution. This will often make it evident the different thinking about roles and responsibility. Once that issue is out and you are aligned, typically knocking out disagreements about how to move forward becomes vastly easier. Right or wrong, we might rarely be able to settle our differences on smaller issues ("the what should we do") if we have different ideas on the bigger issues ("the when and how we should do it"), or the large issues ("the why we do it").<br />
<br />
Interestingly enough, the inverse of this technique is how we ensure we are able to evaluate the performance at each level.<br />
<br />
Clear as mud?<br />
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-85086415655572750442013-01-19T09:14:00.000-08:002013-01-19T09:14:26.918-08:00Management vs Leadership<div dir="ltr" style="text-align: left;" trbidi="on">
One of those planning conversations that so quickly goes off the rails into parts unknown, recently wandered into a discussion about management styles and corporate culture and odd assortment of other loosely connected things.<br />
<br />
Along the way, there were several references to management styles and writings about the same. From time to time, someone speaking about a management style would reference a book or article about leadership and vice versa. The seemingly accepted interchangeability of these two concepts baffled me. To my mind, they are vastly different if loosely connected. Much in the way a wedding planner and a bride can often be interchanged but you wouldn't want to confuse one with the other.<br />
<br />
An example of this was a reference to the style known as Management By Walking Around. There was an implication that the more face time managers have, they are not only more productive but more loyal. Which I totally disagree with. In my experience and extremely limited tracking on the subject I do agree that the frequency and depth of personal connection with contributors will increase productivity, provided that connection is about more than productivity. Should there fail to be an exhibition of leadership during these engagements, then a tipping point emerges where the contact becomes an inhibitor to productivity. Especially in areas requiring significant creativity or innovation. Prior to the tipping point for productivity being reached there can be observed a decrease in the attributes signifying loyalty.<br />
<br />
The roadmap follows like this: too much face time without leadership makes employees feel over-managed and under-supported. They lose their part of the connection to the business objectives, they cease seeing their contribution being impactful. When they don't feel connected, they care less about their own productivity and eventually the productivity falls away. It's hard to stay productivity when you aren't inspired.<br />
<br />
From the other direction, if you exhibit leadership too infrequently and with insufficient management, they might do their best to be productive but not know how to measure or account for what they do. They will then get frustrated at the disconnect between their hard work and successful business outcomes. In this case, business failings which is the summation of productivity, will be the precursor to diminishing loyalty. It's hard to stay loyalty to a leader in the face of failure.<br />
<br />
Giving clear instruction and frequent oversight is management. Having actionable metrics and attainable objectives is good management. But these are nothing without inspiration, encouragement, a sense of purpose and a clear, personal connection to business outcomes. Ensuring people understand why they are working hard and have a transparent view of the impact they, specifically and personally, are making, that is leadership.<br />
<br />
You can lead to long-term failure, you can manage to short-term success. Without leadership, your management won't have longevity and without management your leadership won't see results.<br />
<br /></div>
Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-19038756.post-42354341582776877812012-10-24T11:01:00.000-07:002012-10-24T11:01:00.199-07:00Start Off Big <div dir="ltr" style="text-align: left;" trbidi="on">
One of the most often heard requests for advice I get is from leaders who are trying to establish or grow a development organization. This makes sense because building an organization that can effectively deliver technology solutions isn't just hard, it is one of the most difficult types of organizations that exist.<br />
<br />
Especially with the entrepreneurial types a common approach is try to do things on the cheap. They try and get the lowest cost resource who can do just the minimum type of work they think they need to get their idea of the ground. They think if they just had a guy who could do X, they'd figure out all the rest. And couldn’t that resource somehow grow into someone who can do X and Y? As if acquiring good technology talent is like finding a great pitcher. Not even close.<br />
<br />
Finding a player for a team brings together skills of the various team members based on who they are <b>now</b>. Bringing together a world-class technology team is about finding people who will become fundamentally different when they are successful. You cannot see them for who they are, or even who they will become as they grow. You need contributors who perform in certain ways when things are failing, when needs aren't being met, when you are clearly not having success. You need contributors who won't necessarily compensate for the weakness of others to drive to success, but leverage those weaknesses to change the business or the circumstances. It's not always about success, sometimes it is about managing the failures. It isn't always about finding someone who can be successful, but identifying someone who will tolerate and grow even when objectives aren't being met.<br />
<br />
These are hard truths but let me come at it from a different angle.<br />
<br />
If you found someone who could very easily do what you need to do today to make the system run smoothly, they would likely be bored tomorrow once the system is running smoothly. They wouldn't necessarily have the motivation to seek the optimum solution, the unreasonably good approach to the circumstance. You don't want someone who knows your problem and only your problem and has done it a thousand times and will do it a thousand more. This person is a technician. They are a commodity and you should bring them in only for point-in-time consultations. Otherwise, they'll be bored and they won't think outside the box.<br />
<br />
Finding someone who clearly hasn't done what you need and is willing to try something new is risky but might be worth a shot. The upside is you get someone who is willing to grow and learn. This is always valuable but brings with it some chance of failure. After all, they might not be successful in the direction they choose to take. You can mitigate the risk if you have some expertise available to stop them from going off the rails, but if you had that expertise already you wouldn't be in the position of seeking someone new.<br />
<br />
What you want is someone who has done something similar, who can bring the lessons in their successes and failures to bear in the problem-space you find yourself. They can challenge the status quo, but recognize that most new things are variations on the patterns that have gone before. You want them over-qualified for the job so they learn the trivia of the circumstance and challenges the assumptions and your execution. But you want them demonstrable capable of adapting to the change as the solutions mature from idea to sustainment.<br />
<br />
So like a good real-estate investor friend of mine once told me, go for the house just a little more than you can afford. You'll have to really work at it in the short-term, but very quickly you'll grow into it. You'll pay more for the big gun when you start off, but if he's good he'll have your organization growing very quickly and then you'll need someone with his experience to manage the technicians you will bring in as well as the young bucks who will need mentoring.<br />
<br />
<br />
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-14690888361889682022012-10-23T07:33:00.005-07:002012-10-23T07:33:44.536-07:00Pushing and Shoving<div dir="ltr" style="text-align: left;" trbidi="on">
Building a team isn't something you do every day. Choosing what kind of leader you want to be absolutely is something you need to do each and every day, many times a day in fact.<br />
<br />
As we interact with our people and amongst ourselves we are continually faced the challenge of how hard to push them and how much to compensate for the realities of a market, industry, location, or culture. In the end, I believe that not pushing people to excel is actually hurting them <i>and</i> the organizations we support.<br />
<br />
If you allow people to repeatedly come up against the wall and back down, you are depriving them of the opportunity to grow and stretch. To get better, to add more value, to do more than the ordinary. If we aren't setting an expectation that walls are something they go over, that no challenge is insurmountable, then we allow them to fade into mediocrity. It is a slippery slope. One made more I feel by the way in which we evaluate and give feedback.<br />
<br />
As a consultant I've been privileged to work inside and alongside employees from literally dozens of corporations. From Fortune 100's with thousand of employees, to small finance companies that made billions of dollars with only a few hundred employees. In every organization I've worked in, for, or alongside of there same basic model was followed. For the most part individual performance is ignored until some arbitrary review cycle in which supposedly all the good and bad was dumped into a morass of feedback that was tied in some convoluted way to compensation or promotion. This process involved everyone dredging up events and commentary from the months prior in a flurry of anxiety trying to capture some meaningful thread to rationalize decisions about who is performing that were mostly already decided. Once the process was complete, everyone tucked the papers in a desk and safely ignored them until the next arbitrary cycle kicked off again to repeat the insanity. Of course, I'm sure in your unique/special organization this is entirely different and everyone just loves and thrives under your evaluation process.<br />
<br />
This model of ineffectiveness is perpetuated at least in part because of our inability to provide routine feedback and challenge our people and each other in a more interactive fashion. Why on earth should we be having a conversation about my performance three months ago, if I'm effectively delivering enormously critical objectives right at this moment? If I screwed up yesterday, why on earth are you going to wait multiple <b>months</b> to help coach me on how to be better? It's really quite absurd when you think about it.<br />
<br />
As leaders it is our responsibility to ensure all our employees have an opportunity to take on new challenges, knowing full well that the likelihood of missing the mark is ever-present. If we allow our employees to think that not meeting a challenge is a bad thing, we give them permission to rise to each challenge and face them head-on. Don't get me wrong, not delivering on expectations shouldn't be the norm. But neither should we operate out of fear. In the same way, willingness to take on challenges should be the norm, and the ability to exceed them regularly should be especially rewarded. We all need to try, we can't always win. Everyone gets points for trying, everyone should win sometimes. Some should get more points for winning more frequently or overcoming bigger hurdles, but not making a good try should be grounds for dismissal.<br />
<br />
Each day you go through as a leader that you aren't giving your people feedback is a day you are letting them down. Don't steal their opportunities to improve. Don't deny the competent ones room to grow because the incompetent ones don't get corrected. One of the hardest parts of leadership isn't just knowing who to push for growth, it's also being willing to give some of them a shove. . .right out the door.<br />
<br />
<br />
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-45330398488169001992012-10-09T06:29:00.002-07:002012-10-09T06:29:46.554-07:00Sometimes Growing Is Hard<div dir="ltr" style="text-align: left;" trbidi="on">
I was reviewing some notes about a company I worked for quite some time ago. This organization was struggling with several issues including retention of their most creative and capable resources. At one particular leadership meeting I heard the message of helping people grow repeated multiple times. However, what I never heard was a desire to <b>train</b>. We spoke often about helping people to <i>learn</i>, but very little was said about how to improve the ways in which they were <b>taught</b>.<br />
<br />
At several opportune moments I interjected that perhaps we needed more formal training. That we needed a model to deliberately and consistently teach each level of the organization what we expected them to know. It was met with head-on disapproval. If we spend time teaching, we impact productivity. If we make the learning and evaluation more rigid then it would discourage creativity and individual development. What a bunch of nonsense. Oh, I get that there is a very real cost to training and teaching. I understand that with a guideline and criteria against which people can be judged there will inevitably be those who cannot measure up. Which means difficult decisions and even harder conversations.<br />
<br />
What about our culture of individualism, self-improvement, and the environment of empowerment we try so hard to foster? I fail to see the relevance. How many times have I seen leaders with the passion and desire to be better, but lacking the skills or ability. Countless. Why do we feel that just because want to allow people to figure out how to be mentors, how to be leaders, how to encourage improvement and quality, we must also refuse to give them tools to d that effectively. Why do we fail to give them criteria or a standard by which to measure this growth?<br />
<br />
To build a world-class organization you need to provide specific tools and training so that the people we expect to lead have the <i>ability</i> to match their passion. They need to be measured on multiple aspects of their leadership and held accountable for their ability to improve and grow others, not just delivering tactical objectives. Those who need more help should be able to get it. Those with the desire to be leaders need to be equipped to be leaders. It is not acceptable to simply assume that the smart middle-management will be successful at supporting an environment or a culture where people encourage each other. It takes iron to sharpen iron. Sometimes you have to be trained to do the things you want to do.<br />
<br />
<br />
<br /></div>
Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-25305593602074760662012-10-05T10:48:00.001-07:002012-10-09T06:28:44.547-07:00And Now We Dance<div dir="ltr" style="text-align: left;" trbidi="on">
It started with a conversation on how to accomplish some tactical
<br />
needs. Like a ton of bricks it hit me in one timeless moment. The
<br />
world has spun.
<br />
<br />
The typical circumstance I'm faced with is how I can help people tactically fix their problems or accomplish some time-boxed goal. Sometimes this requires that I help people become better at what they do. But my impact always has a clock; there is always a time limit. My influence is typically predicated on the underlying assumption that I won't be around very long. That any habits or new ways of thinking will probably only continue for the limited duration of my watchful gaze. But that is all changed now.<br />
<br />
I have people to invest in. My first priority is helping the people in my organization to be better. To grow the people <i>while</i> we accomplish our objectives. When your timeline changes, then your measures of success can change. When your measure of success changes, your strategy and therefore your tactics will also change. And by extension the conversations will change.<br />
<br />
If you know me at all, you know how deeply in my psyche the desire to see others become better is rooted. Helping others seek improvement without judgement is hard. It is a struggle to be consistently encouraging and accepting while simultaneously striving daily to champion quality and excellence. Acceptance of reality so easily slips into complacency. And to my knowledge no one has ever called me complacent. But then we all have gifts. One of my very few just happens to be juggling multiple conflicting agendas simultaneously. Living for the now, richly reveling in the present, and the relentless pursuit of excellence don't always play nicely. And that's why my heart skipped a bit mid-conversation. The fantastical realization that this role is uniquely suited to my particular strengths.<br />
<br />
It's one thing to believe I can do a job. There have been many undertakings and opportunities in which I knew with certainty I could be successful. It is another thing entirely to confront with eyes-open a circumstance that was seemingly crafted just for me. To feel a resonance from the marrow of my bones that I've been brought to this role and it has been fashioned for me alone. That my wonderful diversity, like a perfect puzzle piece finally fit in place, might actually be home.<br />
<br />
I'm looking forward to the growth. To becoming better as I flex those muscles so often underused and under-appreciated until now. I'm ecstatic and excited and impatient and so many other things. But one thing I'm not is nervous. Because this is going to be awesome.<br />
<br />
Just you watch.</div>
Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-32596939500696006472011-07-15T12:44:00.000-07:002011-07-15T12:45:11.373-07:00Big Teams are not Small Teams<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 240px;height:162px;" src="http://neodiem.com/img/crowdsourcing.jpg" alt="" border="0" />
This is a continuation of the <a href="">Moving Quickly In The Dark</a> series. I know the title seems blatantly obvious. But in reality, this is a commonly forgotten axiom and the success of an engagement often hinges on whether the behaviors demonstrated are in alignment with the size of the team.<br>
<br>
If you are on a big team that is operating like a small team, you have probably noticed more chaotic behavior or felt a sense of isolation at one time or another. Ever have that feeling like you don't know what all those other people on your project are doing? Maybe spending a lot of time in meetings that aren't relevant to getting your job done? Then getting blindsided by changes because of decisions in meetings that happened without you, but actually impact your job? These are signs you are on a big team that's pretending to be a small team.<br>
<br>
If you are ever on a project and someone says "We're all staying late and we're just going to get it done." or "That'll only take 10 minutes, can't we just do it?" you should recognize a person who thinks they are on small team. If the team is large, that person is probably going to make things much worse before they make anything better.<br>
<br>
Small teams. . .<br>
<blockquote>
. . . can have clear objectives.<br>
. . . can have lower cost of communications.<br>
. . . can change direction more quickly, with less effort.<br>
. . . can share responsibility among team members more easily.<br>
</blockquote>
When what is being done requires multiple teams, the objectives are the teams are rarely aligned. For example, the marketing department has a goal to attract consumers while the finance department has a goal to contain spending. These are clearly competing goals. Balancing them takes work. This is an extremely influential reason that you need to manage big teams differently than small teams.<br>
<br>
With small teams the communication is generally so chatty (read: high frequency) that the relevance of the communication becomes the same for all members. For example, when the entire team sits in the same room it is easy to ensure everyone knows about a big win or a big challenge. If they're in two cities (or on two different continents!) a little more logistics is required. You begin to count the cost of the phone calls or time it takes to write lengthy, detailed emails.<br>
<br>
Even with small teams of specialists where the relevance of all the information to all members might actually be low, the interfacing cost is generally also low because of the frequency.<br>
<blockquote>
[subtext] Assuming that every contributor on a project needs to know the all same information as every other contributor, demonstrates small team behavior.
</blockquote>
This low cost to communicate means getting and keeping everyone on the same page, or even changing the page for all team members should not require significant effort. Having clear objectives supported by high frequency, low cost communications is the key to having a nimble team regardless of size. Because smaller teams generally have these "nimble" attributes it becomes possible for team members to share responsibility for meeting the objectives of the group.<br>
<br>
When the objectives need to be balanced, the communications cost is high, or the frequency of communication is low, the team becomes less nimble. This lowers the likelihood that team members can share responsibility for meeting objectives without formal process and controls. You wouldn't want the marketing department to have unrestricted access to budget, wouldn't you? For the same reason the quality assurance team is often separate from the solution team.<br>
<blockquote>
[subtext] Assuming that information on Activities or process is reactively sought out, instead of proactively published, demonstrates big team behavior.
</blockquote>
The less nimble the team is, <b>regardless of actual size</b>, the more process is needed. We need process because it keeps other teams and team members in the loop on the changes we are making <i>when those changes impact them</i>. A good process should allow for collaboration and control while allowing the team members to contribute to the objectives in their own way.<br>
<blockquote>
[subtext] Reserving communications for impactful changes, demonstrates big team behavior.
</blockquote>
When you implement controls ineffectively, we call this Bureaucracy. When you do it effectively, is called Adaptive *wink*. The effectiveness of a process translates into nimbleness and is a function of how much priority you place on communicating at the connection points (or interfaces) between team members.<br>
<br>
The reason Adaptive methodologies can be so powerful is because they focus attention away from the internal processes of the different groups and onto the interfaces <b>between</b> the groups. For example, Adaptive encourages the implementer of a system to simply ask of the business, "What do you want to accomplish, right now?" This is instead of trying to learn the intricacies of the business and translate from their own understanding of the business. Adaptive encourages the users of the system to evaluate "What do I need the system to do? Does it do that?" This is instead of trying to understand how the system does what it does or what is needed to implement the system. The focus is on how the teams <i>connect</i> to create a solution, not how each team <i>functions</i> internally.<br>
<blockquote>
[subtext] Adaptive is a good choice when the information gap between two groups is large and the schedule is constrained.
</blockquote>
How you fix a big team that is acting like a small team is another post entirely. Hopefully this will help you identify situations when you are on a big team acting like a small team. Or perhaps the opposite.<br>
<br>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-60789685838443234152010-03-18T09:50:00.000-07:002016-03-11T09:50:17.385-08:00Unlocking The Key Principles<img alt="" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYy__B0yT1zMc6pt3Rkykuc_9-ONA-IVSDQ1BpxNGJCrIkobIwx9JwBhYa_mtui-nnfBepSEPwUOM0Rp7npa2poZ3Rkk2iXfeMnyd327xPmm3CysRQd_uDLL1OlGt-_4DcAJ-A/s320/future-hotel-key.jpg" style="float: right; margin: 0pt 0pt 10px 10px; width: 320px;" /> I've been doing a ton of writing lately and throughout the drafts I reference many different concepts which I refer to as the <b>Key Principles</b>. I've written about many of these at length, but I've never publicly shared my personal list. Even after this entry, I still haven't. But I'm publishing a small sample that will show up in many upcoming posts so they can be used as a reference. I'm including just a small description of each for context. Perhaps I'll find time to cross-reference them with the larger posts on each topic. (uh huh) This entry will get updated if needed to reflect the links in the upcoming posts.<br />
<br />
This also introduces a couple of conventions I've started using in my drafts. An example is the use of [subtext]. This tag will summarize and restate the previous section, usually in axiom form or slang.<br />
<br />
<b>Manage Up, Drive Down</b><br />
The people you are <b>responsible for</b> should be aware that you take responsibility for them. How their actions reflect on you should be a significant part of their decision-making. Keeping them focused on following your agenda as foremost will recursively embed this principle.<br />
<br />
The people you are <b>responsible to</b> should be aware of which responsibilities you are taking on and those which you are not. Focus on understanding and following their agenda. Clearly articulate when you see conflict in their agenda and support them in resolving it (read: time, attention, information). If it fails to be resolved, be clear about the implications of not addressing that conflict.<br />
<blockquote>
[subtext]The things which interest my boss, fascinate me. </blockquote>
<b>Praise in Public, Criticize Quietly</b><br />
This only applies to personal accomplishment or growth. Performance that affects a team or behaviors that can be observed by people you wish to influence are excepted. When you are trying to influence others (for example teaching), you need to acknowledge individual performance in view of those who need to learn. See: Communicate Consequences Clearly.<br />
<blockquote>
[subtext] Allow people to save face and time to absorb bad news privately. </blockquote>
<b>Often Wrong, Never In Doubt</b><br />
Leaders who are indecisive aren't leading. If you don't have a vision, you need to get one quickly. Ask for help, solicit options and opinions, then make decisions. Once you've committed, stick to what you've decided. If it becomes evident that a wrong choice was made, own the decision and fix it promptly. But until that point, you need to act like you have the answer.<br />
<blockquote>
[subtext] The more confidence you have, the more confidence others will give you.</blockquote>
<b>If It Isn't Written, It Isn't Real</b><br />
[alternative] If you didn't measure it, you didn't do it.<br />
[alternative] If you didn't write it down, it didn't happen.<br />
Talking and waving hands is fun and easy, but is not a replacement for writing things down and having people review it. When it comes to setting down standards or communicating expectations, having a written record will flush out conflicts and allow individuals to preemptively check their standing so they can save face. Because writing takes work, it encourages you to focus on efficient communication. To avoid challenges to your writing, focus on quantifiable metrics and hard facts.<br />
<br />
<b>Trust, But Verify</b><br />
We need to trust to move quickly. But blind trust is another word for an unverified assumption and it can set us up for failure. Give your resources the benefit of the doubt, but don't hesitate to ask for proof of the facts. If you ask others to trust <b>you</b>, give them ways to check <i>your</i> facts independently and without a having to ask. When it comes to successful collaborate, most of trust is perception. If you display a lack of trust in someone (say, by second-guessing) be prepared to find that the reciprocal trust is eroding as well. See: Rely on Tests, Not Opinions.<br />
<blockquote>
[subtext] The more trust you show towards others, the more trust others will show towards you. But don't be stupid.</blockquote>
<b>Everything Temporary Becomes Permanent</b><br />
Change always has a cost, and we only make temporary things to save costs today. We usually underestimate the future costs because we forget about the costs of dealing with the temporary until the future arrives. When it does arrive, we've usually sunk so much cost into it and built so much around it, that it becomes cheaper to simply leave things alone. Don't fight this, just plan that any road you go down, you will likely stay on for a while. This means don't show things to users or customers unless you are willing to ship or start supporting them as they stand.<br />
<br />
<b>Communicate Consequences Clearly</b><br />
Always be broadcasting your expectations so that those you work with know how support you. For those who work <b>for</b> you, ensure the examples of consequences (positive and negative) are frequent and obvious so they will factor into their decision-making. If you reward generously, this should be well understood. Make sure the results of bad behavior are well understood. This is not always the same as explaining the outcomes from failure, because there are many times that failure is an acceptable result. See: A Process Is Not An Outcome.<br />
<blockquote>
[subtext] Always show the horse the carrot <i>and</i> the stick. Which to show first, depends on the horse.</blockquote>
<b>Something Is Only As Simple As Its Explanation</b><br />
[alternative] You only know that which you can teach.<br />
[alternative] If you have to write it down, it is too complicated.<br />
[alternative] If you can't explain it <i>simply</i>, you can't <i>simply</i> program it.<br />
[alternative] The likelihood of failure is equivalent to the ambiguity of your expectations.<br />
There are several versions and applications of this principle, because the concept is so foundational. When you need something done, you should be able to explain it in clear terms to the uninitiated. If you can't do that, don't expect them to understand your expectations. If you are working with someone who can't explain their expectations succinctly and clearly, you should be careful.<br />
<blockquote>
[subtext] Don't expect people to be successful at a task that you can't easily explain.</blockquote>
<b>Rely on Numbers, Not Opinions</b><br />
When possible, make decisions with objective information not subjective perceptions. Asking someone if they are making progress is different than asking what percentage of the tasks are complete today. Instead of saying the build is complete, publish the number of projects compiling/components deployed/tests passing. We all have good days and bad days, we guess with varying degrees of accuracy, but numbers are precise. The way to get numbers is by using tests and quantifiable metrics, anything else is just opinion.<br />
<blockquote>
[subtext] One good test is worth a hundred opinions.</blockquote>
<b>A Process Is Not An Outcome</b><br />
In the age of commodity, this is borderline heresy. If the desired outcome can be obtained by a rigid process, it should likely be automated. When it comes to anything requiring higher intelligence and creativity, blindly following a process is a quick way to fail. This is not to say that intelligent and creative individuals do not need boundaries, conventions, and standards; they surely do. But following a process is only managing to failure. Only the least creative and the unskilled will tolerate a process that mandates how those skills are applied. Allow individuals to find their own way by giving them clear criteria for success. They will likely surprise you and surpass those expectations.<br />
<blockquote>
[subtext] Choose good people, give them clear criteria to succeed, and stay out of their way.</blockquote>
<br />
<br />
There are quite a few more and much can be written about each of these, but that is for another time.<br />
<br />
Comments welcome.<br />
<br />Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-65877213445903911102010-03-04T09:33:00.000-08:002010-03-04T09:42:02.049-08:00Getting Somewhere<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 240px;height:172px;" src="http://neodiem.com/img/corporaterestructuring.jpg" alt="" border="0" />
A friend of mine recently got promoted to a CTO job for decent-sized technology company. As is sometimes the case with big undertakings, we sat down for a beer to bounce some ideas around. Part of why he's as good as he is at his job is because he asks for advice from those with experience.<br>
<br>
Through the course of the evening I found myself coming back to some earlier post-mortem writing I'd done about some large corporation restructurings. We also compared the results of some big reorganizations of which we'd been on the side-lines, to their present day situations and what we could find of the road they traveled. Eerily enough, the steps the successes made weren't that different from my Creation in Chaos checklists. The paraphrased version goes something like this:<br>
<br>
<b>Head Down</b><br>
When it comes to earning trust, the quickest way is with results. Your walk talks and your talk talks, but your walk talks louder than your talk talks. So start walking. Don't publicize your plans, don't invite dialog outside of those conversations in which you absolutely need to engage. Save your energy, kill idle speculation, and don't give room for rumors. You were chosen for the job for a reason, so start proving people right. If you don't have a vision, make crystallizing it your first priority but keep that process to yourself. Be direct and transparent with your organization, be direct and opaque with everyone else.<br>
<br>
<b>Assemble the Team</b><br>
What you need most are the resources marshaled around you to get things done. So find out who you can count on, who has skin in the game, and who needs to go. Pick some champions, equip them well and unleash them. To do this you need to have a clearly defined inner circle. Set clear priorities, make sure they know and respect the ground rules of the new game. Give them regular and consistent chances to provide input and a forum to keep your thumb on their pulse. This will mean reducing the layers within the organization and if necessary trimming the organization. The evidence in history shows that you will have to do these reductions anyway, one way or another. So it's best to be upfront about what it takes to be in the inner circle, and eliminate those who aren't. Give them packages, help them along as best you can, but do it quickly and transparently. Your long-term success relies on this.<br>
<br>
<b>Find a Focus</b><br>
This step needs to be done in parallel with the previous one. Success is <i>always</i> predicated on focus. Pick the 3 or 4 things that are already driving your (and the organizations success) and reinforce their priority. Make sure your team is in the loop to identify this list, and align the troops and the funding around these items. At the same time, pick the 4 or 5 things that are impeding your goals and find out how to bury them. Whether it is sucking time, money, or attention, the worst of this lot need to get bullets in the brain, fast. Again, get the team in on the process to identify these, but don't let them run the show. Don't get side-tracked by history, sacred cows, or personal agendas. Keep laser-focused on hard facts, raw data, and make note of anyone who isn't slicing the fat alongside you. Chances are they should be the next neck under the axe.<br>
<br>
<b>Lower the Bar</b><br>
When it comes to planning and setting goals, keep them simple and attainable. Nothing will impede your forward progress like unrealistic goals, or worse, goals you fail to hit. Until you have your feet under you and track record behind you, under-promise and over-deliver. Give your people soft pitches that they can knock out of the park. Let everyone claim some successes so the mood can recover. Give people time to refine the basics, learn the new game and become efficient at delivery on the focus items.<br>
<br>
<b>Rinse and Repeat</b><br>
When you have some successes, and the situation begins to improve, it is time to publicize the results. Go back to the beginning, examining the team, the focus items, and the success criteria. Raise the bar a little, add some new items to focus on, grow the team, and give your people new challenges. Remember that it is a process and each step needs solid footing so you don't fall.<br>
<br>
<br>
While these may seem to apply only for organizations, they are the same steps we follow when constructing a life plan or any self-improvement process. I welcome your comments and success stories.<br>
<br>
<br>Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-71335778055992210302010-02-02T16:15:00.000-08:002010-02-02T16:17:11.701-08:00Brain Cramps - Information Overload<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 240px;height:240px;" src="http://neodiem.com/img/informationoverload5.jpg" alt="" border="0" />
Over the next several posts I'm going to be reflecting on several concepts that are shaping our world, specifically how we are dealing with technological advances. The first couple, you'll recognize immediately. Once we dispense with the obvious, I'll delve into the more obtuse. Along the way, I'll provide some pointers to the various techniques I've investigated for handling the brain cramps that can occur.<br>
<br>
The first concept is <b>Information Overload</b>. This phrase was made so popular by <a href="http://en.wikipedia.org/wiki/Alvin_Toffler">Toffler</a> that we all think we understand what it means. At the core, this condition arises when we have too much information to easily digest or understand. While problematic, there are many techniques for dealing with an onslaught of data. The real issues arise in the follow-up problems for which this is just a precursor.<br>
<br>
If it was just about handling a stream of consistent data, we could apply lots of ways to survive and possibly thrive. It is when the information coming at us is always changing, always new, and therefore increasing in complexity and depth that our normal coping mechanisms start to break down. For now, let's just understand some techniques for managing Information Overload.<br>
<br>
If you want to be success and handling large volumes of information, the first step is to <b>Be Deliberate</b>.(If you've read any of my previous writing, you probably knew what I was going to say.)<br>
<br>
Like any activity, you won't be nearly as efficiently successful until you have clearly defined intentions. With your goals understood and an end-result in clear sight, our natural ability to focus, prioritize and assign value kicks in and easily let the irrelevant fall away. With practice you will learn to be ruthless in determining if the incoming information flow is supporting your intentions and ejecting that which doesn't.<br>
<br>
Once you have some sort of filter in place, you can then identify those sources where the signal-to-noise ratio is unduly high. The STN ratio is a measure of how much usefulness or relevant information is received from a source in comparison to how much useless or irrelevant information is presented by that same source. A new show that only has 1 story out of several hundreds that supports my intentions has a very low STN. Conversely, a blog that posts infrequently but routinely has excellent information relevant to my intentions, has a high STN.<br>
<br>
So the next step is to <b>Limit Information Sources</b>. Prune away those sources where the STN is too low. If you can't remove it completely, find a way to consign it to less impactful or interruptive times during your day. Ideally, only review those sources during your down or idle time.<br>
<br>
Adjusting the information by limited sources is easier when you <b>Define Touchpoints</b>. Set aside different areas and tools for doing work that are different from the areas and tools where you interact with others. For example, I use a separate computer for IM, personal email, and social networking then my work computer. When I'm on one device, I create different accounts and workspaces to keep things separate. Set a work schedule and stick to it. If people know when you arrive and leave work, the times of day you respond to email or IM messages and so forth, you'll have a better chance of them respecting your work times.<br>
<br>
Lastly, <b>Forget Useless Information Quickly</b>. No matter what you do, the flow of information will continue and you will be presented with too much information that is vying for your attention. So learn to ask some questions of each new piece of information and if it doesn't meet your criteria, dump it. This is one of those behaviors you will have to practice to become ruthless and deliberate about, but the rewards are significant.<br>
<br>
An interviewer once asked Albert Einstein why he didn't know his own phone number. Einstein replied "Because I don't use it." How much information are you carrying that you don't use? Much of the information we keep only has limited time value anyway. By the time we need it, the information will have changed or been outdated. So ask yourself:<br>
<ul>
<li>Do I really need the information? If it doesn't support your intentions, get rid of it.</li>
<li>Is this information I can get somewhere else? If there are other ways to acquire it when needed, forget it right away.</li>
<li>Is this information time-sensitive ? If it will be obsolete before you'll be able to use it, dump it.</li>
</ul>
<br>
In the next series of posts, we'll talk about the other derivative issues that arise from the increasing speed of technological advancement. As always your comments are coveted.<br>
<br>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-30661172819226097172010-01-13T09:59:00.000-08:002010-01-13T10:04:40.302-08:00Dealing with Doody-heads<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 225px;height:225px;" src="http://neodiem.com/img/doodyhead.jpg" alt="" border="0" />
It's been way too long since I've had half a moment to organize my thoughts for a post.<br>
<br>
In all fairness, I should probably be doing something besides working on this post right at this minute. But like a riot in the heart, sometimes you just need to get your thoughts out of your head. So let's begin...<br>
<br>
We have all had to deal with crazies, sillies, and douche-bags in the workplace. My personal area of frustration right now though, is a the doody-head. That guy who is nice but slow. He's reasonably smart and probably educated, but utterly un-pragmatic and has no critical thinking skills in evidence. He insists on dragging everyone along on whatever wild tangent of drivel that currently occupies his limited field of vision. He's naïve about risks and costs, and blindly bumbles around like a cheerleader at a frat party, which is basically the role out of which he's never grown. When she drops your shiny new cell phone into the punch bowl, she just shrugs and says "Sorry" before stumbling off to puke in the bushes. Ugh, the doody-head.<br>
<br>
So how does one handle having a doody-head in the workplace? Can you be productive? Can your team be productive in spite of their propensity to flutter after every shiny idea that floats past? Sort of.<br>
<br>
Firstly, you need to recognize that they will not change. Just like a douche-bag is always a douche-bag, and a crazy is always a crazy. Once you are clear that you aren't going to change their spots, you can get down to figuring out how to entice, lure, seduce, and otherwise cajole them into a safe place where they can't accidently set fire to the backseat of your Mercedes.<br>
<br>
Pay attention to their common interests and be prepared to use anecdotes and trivia to distract them from their subtle slide into irrelevance. Laugh at their jokes, and give them plenty of opportunity during the small-talk time before meetings to let them ruminate. Help them feel important by letting them spew their verbal diarrhea in out of the way forums and hallways. Give them tasks that involve spreadsheets, diagrams, process flows, and lots of writing. Make a big deal of out these special research projects. If necessary, let them present their findings during lunch meetings so as not to detract from actual work time. This has the added bonus of allowing you to look engaged as you plow through a turkey sandwich. And of course, the team will love you for the free lunch!<br>
<br>
Lastly, you need to always have a backup plan. What happens if they notice that you aren't really listening to them anymore? If that small glimmer of awareness manages to clue them in that they aren't actually in the loop, you don't want them self-destructing and turning into a crazy. So keep an area or set of tasks that are actually relevant but are simple and already well understood. You wouldn't want a doody-head getting creative. That's a recipe for disaster.<br>
When figuring out which types of tasks and roles work best, it helps if you can tie the tasks to external team dependencies. This way, they'll have meaningful work that should amount to following a pre-laid path. Put them in the driver seat of the train. As long as you've laid the track first and have other teams with an interest in keeping the train on the track, you should feel free to toss them a conductor hat and let them blow the whistle to their hearts content.<br>
<br>
It's important to realize that there two things for which you never want a doody-head to be responsible. The first is planning. It's fine to let a doody-head drive a train or the backseat of a tandem bike, but not your speed-boat or even your tiny remote control helicopter you got at the mall. They will invariably face-plant into or run right over the largest, most expensive, thing it is possible to destroy.<br>
<br>
The second to keep doody-heads away from is interfacing with other teams. It's fine to give them work that another team requires, or have them take the work another team produces. You just don't want a doody-head being the line of communication you have with that other team. Getting teams to talk effectively is a little like playing telephone even on a good day. Adding a doody-head is like putting the office gossip who's just a little bit tipsy in the middle of the chain. Everything coming through will just end up sounding dirty and not making any sense.<br>
<br>
I hope these tips help you handle your doody-head. Try not to get any on you.<br>
<br>Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-73531060711034317032009-02-19T10:50:00.000-08:002009-02-19T10:52:02.137-08:003 Tenets to Being Better<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 240px;height:119px;" src="http://neodiem.com/img/pieratdusk.jpg" alt="" border="0" />
Lately, I've found myself having to teach a lot of beginner-level engineering techniques. Any time I work with people who are just getting started in their chosen fields, the same type of conversation occurs. They inevitably want to know how to get better. In some cases, they want to know how to be the best.<br>
<br>
The funny part happens with those who take a while to get to the point of asking for help. You see, the good ones usually have achieved some small measure of success already. So they're feeling particularly competent and capable. And faced with demanding situations, where they find themselves out of their depth, they don't always immediately recognize it. And even if they do sense the impending doom, they don't necessarily want someone else to <i>help</i> them. They want to try and swim a little on their own first.<br>
<br>
So whether they are really good, or they just think they are, they ultimately end up having to ask for the opinions of more senior people in their field. The more they flounder, the less helpful I can be. The less they struggle, the more help I can give them in specific situations.<br>
<br>
Now the truly gifted ones don't just ask for help with a specific situations, they want to understand the principles involved. They want to know how to <b>become better</b>, which is more than just <b>sucking less</b>. <br>
<br>
Over the years, I've found myself giving a lot of the same specific principles that are built on only a couple of foundational tenets.<br>
<br>
<ol>
<li>Learn the basics completely and comprehensively.<br>
Reading voraciously. Read everything you can get your hands on from people who are actually doing the type of work you want to do. Know the conventions they use, learn the language, the vocabulary and the slang.</li>
<li>Build up your style, your repertoire of techniques, and stick with them.<br>
Pick the tried and true methods that you prefer and practice. Have defensible answers for your choices, so make them deliberately. Keep the number of techniques manageable and deviate as little as possible. Don't switch without overwhelmingly compelling reasons.</li>
<li>Fail fast and when failure is cheap do it often.<br>
If you are doing something new, don't be afraid to take risks. Just make sure they are recoverable and inexpensive. Prototype, mock-up, white-board, sketch, and pseudo-code as much as possible. If something has the potential to go down, get to the stress point as quick as possible so you can address it quickly or get passed it.</li>
</ol>
<br>
A few things to consider about these tenets is that they aren't just about <i>learning</i> quickly. They are about <b><i>unlearning</i></b> quickly as well. You can't embrace something new until you get past your hang-ups from your history. When you can <i>un</i>learn quickly you will be more creative and nimble in your solutions going forward.<br>
<br>
Being deliberate in your choices means you will be more consistent and reliable in the majority of things you do; specifically the things that matter. You'll know the choices that matter because they are the things you chose early and from which you rarely deviate. When your choices can withstand fads, trends, and the stylistic preferences of others, you'll know they are well chosen and important.<br>
<br>
There is more to just making quick choices. Your choices need to either fail quickly or last a long time. This is usually measured as effectiveness. To make more effective choices, you need focus, creativity, and deliberation.<br>
<br>
This notion of making deliberate choices and sticking with them is an aspect of <b>mindfulness</b>. In the <a href="http://www.sciam.com/sciammind/?contents=2004-01">2004 edition of Scientific American Mind</a>, the first issue, you'll find some great technical details about the notion of mindfulness from a neuro-scientific standpoint.<br>
<br>
I just know that people who are more mindful are more effective, and being the best is usually about being the most effective.<br>
<br>Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-64247146944692526962009-02-09T14:24:00.000-08:002009-02-09T14:25:48.485-08:00Just Beyond<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 240px;height:136px;" src="http://neodiem.com/img/reachingforball.jpg" alt="" border="0" />
Do you have friends that are continually pursuing the same goals? They have something they want/need and they talk about it all the time but never seem to get it? They might want a better job, to be in a relationship, more time, more money, or less stress. And with this friend, it doesn't matter what they do, the goal is always eluding them. Sound familiar?<br>
<br>
I certainly run into my share of individuals like this. They always want advice, or help, or a connection. With enough practice, these individuals are easy for me to spot, even when I'm not very familiar with them. The trick for me is to notice the inconsistencies in their presentation. It's a bit general, but usually when the non-verbal signals get really disconnected from what's being said, it's a good sign that it is the words can't be trusted.<br>
<br>
When our internal maps gets messed up, it can be hard to realize that about yourself. And if you are trying to help someone like this, you have to be aware that you can't necessarily trust what they say about their maps either. That's why being able to reconcile the physical signs and the spoken words is so important.<br>
<br>
In cases like this you can do real damage if you take the words at face value. I have a colleague who has been switching jobs for years. He was never satisfied with the work, or the peers, or the bosses, or this or that. He would talk about his "dream job" all the time. Within weeks of taking any position he would invariably start to find all the flaws and unravel why this job wasn't perfect. Within months he'd be looking for a new job no matter how well he was performing, or how much was going "right" about the current job.<br>
<br>
Over the years, I've done my best to help him with connections, references, etc. After all, you want competent, good performers to be successful. And for those years I was always listening to the words. One day I was distracted for some reason I stopped listening to what he was saying. That's when I noticed what he <i>wasn't</i> saying.<br>
<br>
This prompted a round of questions to help figure out what was on his internal map. When we spoke about his current job, he reverted to a different verbal map and physical representation. After a few conversations exploring his maps, he was able to bring his maps into alignment and has been very happy in his latest job for quite some time.<br>
<br>
What was difficult in this situation is that I'd spent so much time providing my friend what he <b>asked for</b> instead of what he <b>needed</b>. I was missing something so simple, so natural, so obvious. It was too obvious. And that's the quickest way to identify this situation, the sheer simple obviousness of what's being requested.<br>
<br>
If the goal is so straightforward but the language and presentation aren't in alignment, there is usually something twisted in the maps underneath. Let me restate this with a few examples:<br>
<ul>
<li>What's being asked for is the same thing as what they want. They want a better job so they'll . . . be in a better job.</li>
<li>What's being asked for can't be clearly stated. They want the "right guy" but describing what that looks like is vague and uncertain or changing.</li>
<li>The weight of the request is significant enough they have to change state to make the request. They have to change posture, stance, or level of fixation.</li>
</ul>
<br>
Once you've identified a misalignment with the underlying maps, you can take steps depending on the specific maps. <br>
<br>
If you are finding yourself cycling on the same issues over and over, or just can't seem to reach that goal that is always just out of reach, try doing some map work. Make sure you aren't missing that crucial symptom that's just too obvious for you to have seen already.<br>
<br>Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-60073726906074011362009-01-28T20:03:00.000-08:002009-01-28T20:05:08.731-08:00It's The How, Not The What<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 220px;height:240px;" src="http://neodiem.com/img/asunsetinsnow.jpg" alt="" border="0" />
I am a big believer in visualization. I have found it to be an instrumental driving force behind change. In many ways my livelihood hinges on my ability to harness or create change within people and organizations, and I have often relied on the power of visualization in my work.<br>
<br>
There is however an aspect of visualization that can be both subtle and startling. For me I bump against this tenet whenever I'm discussing future plans or goals. Especially when they are other peoples future plans or goals. I find myself talking more about how they are going achieve their desires, more so then about those specific desires. This actually works to my advantage because quite a few people only want to talk about the car they are going to drive, they aren't interested in what it takes to acquire it, so they learn to stop talking to me about it. ;-)<br>
<br>
<blockquote>
The Process is more Powerful than the Product<br>
<br>
</blockquote>
<br>
Have you ever heard someone say "It's the journey, not the destination."? This is a common sense way of explaining this same tenet. How you are going to go about doing something is more influential to your success than what you are trying to accomplish. How to use a tool is more important than acquiring one. The way you go about solving your problems will limit you more than the solutions you may or may not find.<br>
<br>
This is a fully loaded tenet so I'm going to go into some more detail about how I apply this every day. When I'm talking to people who have goals, I don't start by asking them to visualize their goals. Instead I ask them to visualize the <i>process</i> of achieving those goals. I don't ask them what they are <b>willing to do</b> for their success. Instead I ask them what they are <b>NOT willing to do</b>.<br>
<br>
This sounds pretty counter-intuitive until you realize that it is our <a href="http://blog.liquidperspective.com/2005/10/limiting-beliefs.htm">limiting beliefs</a> which truly rule our mental maps and models. Consider that guy you know who wants a bigger house. He wants the house, but he isn't willing to move to the middle of nowhere to afford it. That new car? But not willing to work an extra job. Fame? But not willing to wait tables and suffer the humiliation of auditions. Lose weight? But really enjoy dessert. They want to stop being hung over? But won't give up the weekend binge drinking.<br>
<br>
Does any of this sound familiar to you? It isn't just about focusing on the limits. It's also about realizing that breaking down the limits is a process of change. It's fine to set a weight loss goal for 6 months out. But if you don't change your lifestyle in your little decisions every day, you likely won't meet your goals. If you want to have a comfortable retirement, but you are only contributing the minimums to your 401K, you'll likely not reach your dream. Afraid of speaking in public? Want to improve your self-image? Focus on the internal processes you use to restrict and limit yourself. When you can see the process you use you can change it.<br>
<br>
The same is true with those people who want to talk about that better job or more money. When I tell them what they'll have to do to get it, they always do one of two things. They give themselves permission to do the necessary, or they realize they don't really want to do the necessary and they can finally stop obsessing over some future state and enjoy what they really have.<br>
<br>Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-30092583092092918942009-01-22T09:01:00.000-08:002009-01-22T09:02:36.954-08:00How Bad Do You Want It?<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 240px;height:208px;" src="http://neodiem.com/img/success_failures.jpg" alt="" border="0" />
The grind I currently find myself participating in has its advantages. Namely, the problems are complicated and haven't been solved by numerous other "smart" people who have tried for extended periods of time. I've had a week and been slowly making progress.<br>
<br>
As is often the case with tremendously screwed up situations like this one, even some progress is met with skepticism and distrust for a while. I'm carrying the baggage of all the months and host of people who were here before. To cope with this I've been repeating another foundational tenet.<br>
<br>
<blockquote>
You haven't failed. You've only gotten feedback.<br>
<br>
</blockquote>
<br>
The trick to really complicated problem solving is realizing that you don't have to boil the ocean all in one go. You can take steps and make progress, sometimes just by ruling out things that clearly <b><i>aren't</i></b> the answer.<br>
<br>
Thomas Edison has a good quote on this, Benjamin Franklin has one, and so does Albert Einstein. There are numerous other versions and misquotations, but they all can be paraphrased in the same supporting tenet:<br>
<br>
<blockquote>
You can only fail if there is a time limit.<br>
<br>
</blockquote>
<br>
Specifically in my situation, I have people who have already tried quite a few alternative solutions. So when I ask them to proceed down a path they believe they've already wandered, they resist. They fight every step of the way. But as is often the case, I'm able to point out something in <i>the way that they failed</i> which sets them on a new direction. Yesterday we had a breakthrough because I insisted on making someone follow my instructions even though <b>we both knew it was going to fail</b>. We needed to see <i>the way it failed</i> to clearly develop an alternative to the process. Once we saw that, I was able to twist the problem and put him on a path to success. Which in very short order he achieved.<br>
<br>
When you feel like you are beating your head against the <b>same</b> wall, perhaps you need to consider. But if you continue to learn and improve even though you fail repeatedly, don't give up. Acknowledge the success of your feedback, twist the problem, and keep going.<br>
<br>Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-31907780780248865102009-01-19T18:29:00.000-08:002009-01-19T18:30:37.479-08:00We All Have Good Intentions<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 180px;height:240px;" src="http://neodiem.com/img/snowchairs.jpg" alt="" border="0" />
Here's another basic premise I had to recall today. Interestingly, it wasn't because of anything at work but in a personal relationship.<br>
<br>
<blockquote>
Behavior always has a Positive Intention.
</blockquote>
<br>
This is one of those blindingly obvious things that just eludes as all from time to time. Basically, the point here is that anything someone is doing is because they are trying to achieve some goal for themselves. From their perspective, there is a reason and a motivation for their behaviors. Even in cases where those reasons or motivations seem irrational to us, or are hidden from them.<br>
<br>
Our whole intellect is designed to pursue our desires and achieve our goals. Even in cases where we aren't aware of what those desires might be. For example, we see this in our preservation instinct and our self-defense mechanisms. Our brain resolves all the inputs and formulates responses that will further our internal goals. This is why some people are spenders and some are savers, some people are aggressive and some are timid, and so forth. Internally, they have goals in mind which motivate and drive their behaviors.<br>
<br>
When you understand that people are never just acting in a vacuum, and are always acting in alignment with their goals, it becomes easier to empathize, understand, collaborate with, or even control them. When you are aware of their goals and motivations, you can predict or rationalize their behaviors. When you witness their behaviors, you can derive their goals.<br>
<br>
To take this a little further, consider people watching a sporting event or chess match. It's easy to assume each player or coach just wants "to win". But the reality is that they have other goals which dictate the constraints and subordinate goals to winning. For example, they might want to manage exposure to risk, protect certain players or pieces, or have a preference for certain techniques or plays. These constraints and subordinate goals will impact their decisions and behaviors. So when people ask "Why'd he call that play?" or "Why did she try that attack?" they are only verbalizing that they don't understand these other non-obvious motivations.<br>
<br>
The twist on positive intention is due to the nature of perspective. Often I would substitute the word Purpose instead of Positive Intention. This is because most people understand positive to "good" or "beneficial". In reality, the only person that is true for is the one demonstrating the behavior. It might very well be painful or hurtful or "bad" to others. But in their mind it's serving a purpose. Perhaps hidden and subconscious, but very real.<br>
<br>
To put this in practice, pay attention to how people behave when the goals are very public. You will still see them act in unique ways which gives you clues to their hidden goals and motivations. For example, watching people shop is a great way to get a view into their psyche. Do they check prices first or follow colors? Do they check sizes before saying they like something? These are simple examples but they can be extrapolated to how people order food in a group, the questions they ask about the news, or how they act at a party. Are they thrifty, self-conscious about their weight, a leader or follower? The key to unlocking most peoples inner picture of themselves starts with simple observations like this.<br>
<br>
In every situation, we are individually running all the inputs through our internal goal-seeker and deciding on a response that best gets us what we want. Watch what people do when the goals are obvious and you'll find out all those other hidden goals they don't even know about themselves.<br>
<br>Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0tag:blogger.com,1999:blog-19038756.post-75007686040429164382009-01-16T12:45:00.000-08:002009-01-16T12:47:15.917-08:00You Get What You Put In<img style="margin: 0pt 0pt 10px 10px; float: right; cursor: pointer; width: 240px;height:240px;" src="http://neodiem.com/img/talking.jpg" alt="" border="0" />
I'm starting a new endeavor and as usual, I need to review some of the things I've learned to make sure I can be successful. I'll be posting some small snapshot entries as I unpack my toolset for the days to come. Here's one I typically start with:<br>
<br>
<blockquote>
The meaning in a <b>Communication</b> is the <b>Response</b> you obtain.<br>
<br>
</blockquote>
This is one of those that most people think they understand until it slowly unravels in their mind. Here's another way to perceive this concept: Consider that you are trying to explain a concept to someone and they insist they understand your point but their words don't align to prove they actually do. If you continue making the same points with the same language they may very well shut down with "I don't want to have the same conversation again." then you've learned how to end a conversation with that person. This can be a valuable resource, especially for when you need to slow an interaction down.<br>
<br>
Consider a different scenario in which you offer to help someone with something (say some action items they are responsible for accomplishing) and they abruptly retort "I can take care of it." then you have garnered a valuable response. You now know how to get them to snap at you if the need for that arises. You'd be surprised at how often being able to evoke a response is useful.<br>
<br>
These are both negative responses, and I use them intentionally, because the positive ones are easy to ignore. To get inside both cases, you have to come to the realization that you are responsible for your own communication. Because of that, the response you get is something you can impact. If you aren't getting the response you desire, it's up to you to change your communication. If at all possible, change your words. If you can't change your words, change how you are saying it.<br>
<br>
You might find these intrinsic in your own understanding, but if you are like me, you forget to keep these clear in your mind from time to time. So a refresher on how to have an impact with my communication was just the ticket.<br>
<br>Tempus Fugatehttp://www.blogger.com/profile/11837079658924039253noreply@blogger.com0