Eric Pearson: in Motion

Big data in the age of the telegraph

2013-04-06T13:53:00.002-07:00

In 1854, inundated with the amount of data coming from the telegraph, Daniel McCallum created the Org Chart to better organize the flow of information from the field back up the organization. What this article shows is that the proper handling of data at the "edge" of the enterprise, enabling remote decisions and consuming only useful data centrally, has not changed in all the years between the introduction of the telegraph to today's Big Data initiatives. This is +GlobeRanger's founding vision. McCallum called it "a proper division of responsibilities", we call it the Edge... decentralizing real time decision making and shielding the enterprise from the vast amounts of raw data generated at the edge absolutely vital.

Big data in the age of the telegraph - McKinsey Quarterly - Organization - Strategic Organization »

Daniel McCallum’s 1854 organizational design for the New York and Erie Railroad resembles a tree rather than a pyramid. It empowered frontline managers by clarifying data flows. A McKinsey Quarterly O...

RFID Gives Richardson, Tex., Officers More Time for Police Work

2013-04-04T19:19:00.003-07:00

The police department is utilizing a solution developed by GlobeRanger that features its GR-AWARE PD software. GR-AWARE (GlobeRanger Asset Watching and Reporting Engine) is built on GlobeRanger's iMotion platform (available as both an on-premises and cloud-based solution), and is designed to work with a variety of RFID and/or bar-code hardware. GR-AWARE PD is tailored for police departments, explains Eric Pearson, GlobeRanger's director of engineering, but the company also offers a GR-AWARE solution suitable for a broader range of industries, including retail, as well as a GR-AWARE FD version for fire departments. In addition, the firm offers GR-AWARE Hazmat, designed for the hazardous materials industry and currently being used by the U.S. Department of Energy.

Favored Sons and Bastard Stepchildren Don't Work Well Together: Zuckerberg abandons second-class developers

2012-10-29T21:05:00.000-07:00

Perhaps he hasn't abandoned the developers themselves, but Facebook has announced that their product teams, the teams of first-class developers making all of the “cool stuff”, would now be responsible for monetization of the products they create, such as the News Feed or Messaging.

Profound Shift In Zuckerberg's Attitude - Business Insider

Where they used to have a separate team of developers doing the icky work of advertising while the product teams had all of the fun, Zuckerberg has finally realized what so many software companies figured out long ago: you can't isolate teams from each other and expect their end results to work well together.

Part of it is the Founders’ Passion, but it may come from elsewhere in senior management, and many software companies have seen it. Teams of elite developers are isolated and shielded from the “business” while another team is isolated and ignored like annoying stepchildren.

Sometimes this happens to work out well; you may have your cash cow team slaving away, all but forgotten while other teams work on all of the cool stuff that will bring tomorrow’s business and are showered with perks. That was what happened at Apple. As Guy Kawasaki is fond of saying, the Apple II division made all the money while the Macintosh division spent it.

However, that mentality is especially toxic when the results of these two teams are supposed to work together in the wild, just like Facebook’s advertising and product teams. The cool product stuff took up most of the page, and they left a little side bar for ads to run on. This is very different from the cash cow that is expected to be replaced someday, the two teams’ fates are joined; the ad team does not exist without the products, and the products cannot exist (anymore) without the ads (they could early on, before that ugly word “profit” came into the picture).

I've seen this story play out myself. It’s the perfect example of the right hand not knowing what the left hand is doing.

Sure, you often have to have separate teams. But, when their fates are so connected and the product of their labor expected to work together to support the company, their goals have to be shared from the beginning. Sometimes this means merging teams. Sometimes it means rotating people between to give everyone a holistic view of the forest. Sometimes it takes creating a more collaborative environment.

Take a look around and see if this describes your environment. It’s a problem with many solutions, but often goes unnoticed by upper management until it’s too late.

Kill Your Business Model Before It Kills You - Ron Ashkenas - Harvard Business Review

2012-10-25T07:25:00.001-07:00

"Peter Drucker reportedly once said that the biggest curse for any business was twenty years of success"...

Very true. When companies that have seen wild success in the recent past begin to fall on hard times, they often try to figure out what they're doing now that took them away from that model. The fight begins to get back to the good ol' days of high growth, looking inwardly to see where they slipped up.

This violates basics of good strategy because it fails to do two things. First, it fails to properly monitor the external environment for changes that threaten the business. Secondly, it fails to monitor and alter the current strategy to adjust to that changing environment.

The failure to monitor the environment and the unwillingness to change what's worked in the past is a deadly mix.

Kill Your Business Model Before It Kills You »

Why leaders wait too long to change, even when failure is imminent.

"First is to remember that no business model lasts forever. The most dangerous trap that any manager can fall into is complacency. Peter Drucker reportedly once said that the biggest curse for any business was twenty years of success. Markets, environments, and technology can change so quickly that no amount of profit today guarantees success tomorrow."

Innovation, Introversion, and Space Planning: A break from conventional wisdom

2012-05-31T21:32:00.000-07:00

I’d like to explore a concept I have about space planning and introverts. I welcome comments.

As a background, there is a school of thought that engineers and other knowledge workers work best when isolated, free from distraction. Everyone-gets-an-office is a popular theme. One push for this need for isolation is the introverted nature of many engineers.

The other school of thought, open space planning, feeds on collaboration as the driving force behind the space plan. In this concept, gone are the 6-foot high cubicle walls. Gone is the everyone-gets-an-office mentality. People should be able to see each other, and interact freely.

The Conventional Wisdom of Introverts and Isolation vs. Interaction

There is a conventional wisdom that introverts thrive in the isolated environments. This is actually true.

Let me give you some personal background. My name is Eric, and I am an introvert. I’ve been called introverted at a clinical level. When I was an engineer, I did thrive in the confines of my high-walled cube or closed off office (complete with tape over the motion detector to keep the light off at all times). I get it. I also feel I speak from a place of knowledge. Many introverts find themselves underrepresented in these media.

The problem arises when the introvert is expected to collaborate at a high level.

Let’s explore the introvert needing to approach a coworker. If he (and I will use the term ‘he’ as a gender-neutral pronoun, political correctness be damned, it’s shorter) has something to talk about which he values at a 50% on the must-discuss scale, he may go through the following list: social anxiety sets in, he wonders how busy the other person is, he imagines having to round that corner, knock on the persons cube or office, hope they’re not busy, and hope they care about what he has to say or ask.

This is a chain of events that the introvert avoids at all costs, unless the encounter is absolutely necessary or they already have a good rapport with the other person.

Open Space Planning as a Collaboration Facilitator

Now let’s explore an open space planning environment. The introvert is still given their isolated space, but it is isolated at eye level while sitting, and you can see people once you stand up.

For the walk-up-to-a-coworker scenario, if they need to collaborate with someone, they can poke their head up and soon see what the other person is doing (or, walk by the area where the other person is). No corner-rounding to announce themselves into an unknown environment.

Let’s take the join-a-conversation scenario. In a closed space planning environment, if an introvert wants to join a conversation they hear in passing, the have to go through the same steps of walking over, rounding a corner, announcing (by their presence) that they are now joining, and they then have an awkward time of figuring out when it’s OK to leave the conversation and walk away. In an open space environment, the introvert is privy to a lot of conversations by eavesdropping. Ever has beers in a large group with an introvert? They’re likely to sit there quiety, listening, until they have something to say. If they’re allowed to apply the same principle (perhaps without alcohol), they can eavesdrop on the conversation, absorb the knowledge exchanged, and poke their head up if they have something to say, and seat themselves again very easily. No “do I approach” or “is it OK to leave” consideration there.

How These Affect Collaboration

High walls and isolated offices provide the aforementioned hindrances. The introvert, in his blissful isolation, is likely to isolate himself days at a time. This is great for pounding out really imaginative and efficient code, but severely lacks the element of collaboration and free flow of ideas.

Introverts thrive on isolation, but in an innovative organization, they still need to collaborate and exchange ideas on a regular basis.

Of course there are innovative individuals. But, true innovation comes from questioning, discussing, mixing ideas. You can only squeeze so much out of a truly isolated individual. To get the best, you have to provide the isolation while removing barriers for collaboration. You can’t force collaboration on these people (watch them head for the exits), so removing barriers must be the focus.

* As a note, I don’t wish to lump Tom DeMarco and Timothy Lister of PeopleWare into either camp, because they advocate balanced approaches, like 3-4 person offices, or similar concepts and not isolation.

Death of a Coder: Moving from Developer to Management

2012-05-28T18:55:00.000-07:00

There is a career path as a software engineer that takes a person along a journey of Developer, Senior Engineer, and Team Lead. For some, the progression takes a sharp turn into Development Manager. There is a harsh reality at the point of the latter transition into Development Manager. That reality is that the long-time software engineer must do something unthinkable: RETIRE FROM CODING.

As a new or mid-level Developer, your life has a pretty well defined purpose: to write software. You participate in design, perhaps developing with little direction, but your purpose in life is to write software. As a Senior Engineer or Team Lead, your identity is still well defined by the programs that you produce. You now have additional responsibilities: architecture, mentoring, and being responsible for the output of others. You still come to work each day to produce software born out of your own heart and constructed with your own sweat. Ok, constructed with your fingers and tools, if this makes you sweat you need to crank up the A/C or move to a company with a lower stress level.

For some, duty calls to fill the role of Development Manager. What many engineers don't realize is this requires one to leave behind what they once were: someone that writes software.

As a developer, writing software is what has always defined them, what they came to work to do. They took pride in what they produced, took offense at bugs they deemed insignificant, and their heart beat was measured in key strokes. They could remain in their cubes most of the time during development process, emerging at various points for collaboration, and at the beginning and end of the cycle. Occasionally something wasn't clear from management and they sent out an email asking their manager for clarification or some other assistance removing a road-block. What they lived for was the in-between, the days with no interruption when they could produce their masterpiece.

As a manager, now they wake up one day and find themselves in a completely different world. They are now the Rosetta Stone between organizations. Their days now filled with meetings, customer calls, vendor discussions. They are the one responsible for removing those road blocks, forcing decisions. If there was a problem, raising the flag was no longer enough. Solving that problem was now their responsibility. Finding themselves immersed in the beginning, middle, and end of simultaneous projects, lull time no longer exists. What's more, that time that the developer lives for, the time when they could be left alone and work on their masterpiece, the time that defined them, no longer exists. They are no longer working on the masterpiece, other people are doing that, and it's their job to be on the side and enable their developers in every way possible.

The manager can still find ways to get satisfaction in producing software, but they had better realize that their tools for doing so have now changed. Their tools are no longer IDE and keyboard, but people. Rather than ensuring their latest query language is efficient as possible, the new manager must ensure their developer has as little constraints placed on them as possible.

A critical understanding that the development manager must realize is that producing code themselves is likely to HURT the organization. Software developers that have been around for a while realize the perils of context switching during development. Taking focus off of one area to work on a completely different one really hurts productivity. They work most efficiently if they can work on one area for as long a period as possible so they can remember all of the subtleties of the current problem. They wrote one method and realized how it related to another so now they need to add some synchronization code and before they do they need to check this interface, etc. Moving to another project causes them to lose some of this mental context, so they must either capture what they were about to do or risk forgetting some of it and having to re-learn it.

Now imagine that same development process can only be worked on for a maximum of 15 minutes at a time. If a manager is trying to produce code, they will be interrupted 40-50 times during the day with other things that need their attention right away, and the mental shift back into the code comes at a huge expense. Quality suffers, bugs increase, and it's impossible to predict when that piece will be complete.

The manager must leave this all behind. It's not his job anymore. He must realize that the intention of helping out and contributing on this project is likely to do more harm than good. His piece becomes the critical path that everyone is waiting on. When a bug comes back that's part of his code, and he's going to be in meetings for the rest of the day, everyone ends up waiting. Even more, the more time you spend trying to write code for one project, the less time you have to devote to your other projects. You can't play favorites here.

So to the new manager: RETIRE FROM CODING. You're not a programmer anymore. You now work for programmers. Realize that they are going to have that fun, and it's your job to enable them. You are starting a new life for yourself, and like someone moving on from a past love relationship, you have to let go. Wish them happiness, and focus on your new life.

HBR: Stop Inbreeding Innovation

2012-05-08T14:49:00.001-07:00

Exactly right. You cannot expect great innovations inside a bubble. The greatest innovations come from questioning, experimenting, networking, and trading ideas.

Stop Inbreeding Innovation »

It's a topic that perhaps would only appear on the pages of The Economist: an effort to establish North America's first elephant sperm bank. As the article notes, a single elephant named Jackson has "...

Why Google+ will become Google's only product - Computerworld

2012-04-24T18:38:00.001-07:00

More interesting than the Google+/Facebook topic is the evolution of "products" becoming "features".

Why Google+ will become Google's only product »

Google will integrate its best products into a single super product, Google+, that marginalizes smaller rivals and clobbers Facebook with total superiority

12 Lessons Steve Jobs Taught Guy Kawasaki

2012-04-22T06:09:00.002-07:00

I think Guy Kawasaki's best speech. Being the day after Steve Jobs' death, Guy was off his normal path. It was good to see a speech buy Guy that had not already been given 500 times. This speech also takes a lot of Apple's 'magic' and states it in philosophies that can actually be emulated.

Moving away from what's hot, towards what's inevitable: How CEO Rich Templeton is Reinventing Texas Instruments

2012-04-20T05:24:00.001-07:00

In moving away from what's hot (smartphones, etc) and focusing on what's inevitable (analog chips), Texas Instruments has "a chance to sell something to every customer in the world. The number of companies that can say that are pretty limited.”

I've discussed with others.. what would Big Data be to the real world without the means to collect that data? To feed Big Data, to enable things like Smart Grid, you need analog to collect it. You need processing at the edge to make sense of it, and transform data into Information, so you can feed it up to Big Data.

D CEO : How CEO Rich Templeton is Reinventing Texas Instruments »

Learning of my quest to find out more about the man who leads Texas Instruments Inc., he adjusts his sport coat at his Dallas headquarters and jokes that the Goldman talk in January was “easy stuff” c...

Picking a fight with a giant... Disruptive Innovation - Clayton Christensen (Part 3) - YouTube

2012-04-20T05:22:00.001-07:00

Picking a fight with a giant...

In Facebook Deal for Instagram, Board Was All But Out of Picture - WSJ.com

2012-04-20T02:56:00.001-07:00

Amazing. Will this news take the steam out of the IPO? Forget what everyone thought about the $1 Billion purchase of Instagram, but considering the board was "told, not consulted"... amazing.

In Facebook Deal for Instagram, Board Was All But Out of PictureFacebook Board Little Involved in Deal »

By the time Facebook CEO Mark Zuckerberg brought his board in on the plan to buy hot photo-sharing service Instagram for $1 billion, the deal was all but done.

Pictures from my ride to Mena, Arkansas and the Talimena Scenic Byway

2008-04-13T14:53:00.000-07:00

Just got back from my ride to Mena, Arkansas via the Talmena Scenic byway... WOW this was an awesome trip!!! I didn't think I could scrape my pegs doing 35mph And I sure got used to downshifting to 4th gear at 60mph, either for more power going uphill or for the compression to slow me down downhill.
From Dallas to Mena, I ended up taking 75 to Oklahoma 43 (detoured) -> OK 2 -> OK 1 to the Talimena Scenic Drive from Talihena through Mena, AR. On the way back I took Talimena drive back until I hit 259 south, which was a thrill itself, then 259 -> 70, down to Paris and back to Dallas. About 640 miles logged on the bike total.
Hopefully I'll be doing this again soon!
That's my Honda Shadow VT750 C2 marking my territory. I'd just gotten the Kuryakyn Dually offset pegs the night before, so took my tools and made a few stops to adjust them along the way. VERY NICE now for a 300+ mile day's ride.

I actually got stuck in the mud trying to get to this sign..

The highway is actually BRAGGING here!

HEE HEE!!!!!!!!!

... oklahoma was a bit waterlogged

Just outside Paris on my way back, had to snap a shot