A Quick Review …

For anyone that knows Oracle, it is no surprise that last week it filed a patent infringement law suit against Google. After unsuccessful licensing discussion with Sun, Google had decided to build Dalvik for its Android phone platform. Likely, Google did not believe it would run afoul of Sun’s Java patents, given Sun was not an ardent litigator of software patents (aside from its late nineties offensive with Microsoft). The curve ball: at the time Google made this decision, it had no idea that Oracle would one day own those patents.

So how did this happen? I believe the stage was set in the 1980′s with Sun’s nascent DNA and with free software evangelist Richard Stallman (and here).

Richard Stallman and Free Software …

In 1987 we cajoled Richard Stallman to come give a talk at our small computer science department at The College of William & Mary. Richard agreed on the basis that we would pay his transportation and feed him Chesapeake Bay blue crabs. With brown paper bags cut flat and spread open on a card table, the free software visionary proceeded to speak with us while breaking open crabs. Of course, Richard spoke of his beliefs on free software – how software should be treated from an intellectual property perspective. Yet what I want to share with you is a unique exchange during that meeting in 1987. In a small classroom with about forty of us, Richard sat cracking crabs with his long hair precariously close to crab claws.

A juxtaposed clean cut professor interrupted Richard’s commentary, “If it wasn’t for Lotus Corporation, we would not have products like Lotus 1-2-3” (Lotus 1-2-3 was a highly successful commercial spreadsheet program that boosted Windows PC sales. The professor was making the case that it was because of large companies like Lotus that a significant spreadsheet product like Lotus 1-2-3 could come into existence). Crab mallet in hand, Richard continued splitting crab legs and said, “I could write Lotus 1-2-3 in six months. The reason we can have 1-2-3 is not because of Lotus, but rather because hardware capability has gotten to the point that we can write software that performs such activities.” To my 21 year old ears, this was a profound comment – that software was the result of intelligent and motivated individuals, not the product of companies.

Sun – the early days …

Sun’s history is unique in the computing field. Bill Joy was a powerhouse programmer out of Berkeley, having authored significant parts of BSD Unix to include vi, csh, NFS. It was the first UNIX to have TCP/IP built in for networking. Bill Joy started Sun with a few other folks in the early eighties. With the combination of BSD Unix and powerful computing hardware, one could tackle heavy computing class problems with a Sun workstation or server at one’s desk. I began that journey programming Sun 2’s in the mid eighties. Through this whole debacle with Oracle, I’ve been periodically reading James Gosling’s blog. He has been with Sun since the mid eighties so many of his “wayback machine” references ring a bell. Sun was always good at hardware and operating systems. I spent most of my coding career building software on UNIX boxes – System V, NeXTOS, SunOS, Solaris, et cetera. Sun’s OS was exceptionally stable, but all kinds of service offerings overtop of the core OS were a land of near misses. The NeWS environment, printing infrastructure, Java IDE’s, Tooltalk in the mid nineties. So much technology above the OS never got traction. As a developer I learned early on not expect a Sun offering to be supported long after it was made available.

Deeply involved in programming an early analytics system built on the Sun platform, I remember a meeting of about a half dozen of us with Bill Joy, who had stopped in to visit our project. At the time Sun had adopted X Windows (post NeWS, et cetera) and we were having tenacious issues with colormaps. Sun had never been much of a graphics company (that honor was left for UNIX workstation competitor, Silicon Graphics). Bill went on a steaming rant about how MIT guys were hacking the X distribution to make some of the graphics work for games and how he no choice but to put up with the situation. When it got much beyond operating the hardware, Sun fell short time and again with its product offerings in spite of good ideas and the best of intentions. Creating sustainable business cases for technology ideas above the hardware seemed elusive to Sun.

With that said, I started programming Java systems in 1997. Java was a language then. It later became a platform which is nearly akin to an operating system, being a full up operational ecosystem. It was Sun’s third burgeoning success. Its first being the creation and sale of analytic workstations and servers in the early eighties and nineties, mostly to scientific and engineering communities. Second, was the onslaught of web servers and IT servers for the backroom, before Linux took a chunk out of that business. But Sun never really did software, I had lived it for over a decade when Java arrived. For years I owned Sun stock because I believed in the company, but I was flummoxed at how Sun could not monetize something as profound to the Internet and IT environments as Java became (and all its constituent pieces).

Which brings us to Open Source, Java and the Oracle purchase …

For the last decade I wondered who would buy Sun. In my opinion Sun needed to be bought, lest it go the way of Digital Equipment Corp (DEC) – a company of bright engineers with good product that ended up with no market and its constituent pieces sold off. My fantasy choice for a Sun suitor was Apple – they appreciate good hardware and operating systems. Apple’s market was front end computing, yet with difficulties in getting IT penetration. Apple knew how to product manage user facing computing products; I saw Sun and Apple as a dovetail marriage made in heaven. Obviously, I was the only one.

So instead it was Oracle. What did they actually buy for $5.6 billion? The engineering talent is fleeing at a rate that makes the Jews leaving Egypt in biblical times seem lackadaisical. Along with the hardware business, Oracle purchased a big chunk of “open source” – OpenSolaris, Java, OpenOffice and in the same traunch, MySQL from MySQL AB which was seeing heavy involvement from Sun. James Gosling likes to say that money is Oracle’s only metric. While Sun wasn’t necessarily focused on the “only metric” as money, they were struggling. Money is the primary metric of most large companies. Sun was different, possibly because of its inability over the years to figure out how to monetize its employees’ creations.

Ultimately, Oracle sees open source both as a competitor and a financial opportunity. A significant portion of Sun’s value was the open source it was shepherding. As much as Sun in its early days was not big on software patents, its Java patents were key to Oracle’s purchase decision. And Sun’s CEO and Board knew that. Sun was in precarious waters to survive as a company. The offering from Oracle was too good to pass up and the deal was done. As some predicted, OpenSolaris has been shelved. MySQL, an arguable competitor to Oracle, is now in its grasp – a coy move which slithered around Federal anti-trust review. Android is a big enough financial target to fire up litigation and go reap some rewards. What did Oracle ultimately want from Sun? It seems obvious. At the end of the day Sun sold it all to Oracle. To wit, even for Sun … and I hate to disagree with James Gosling in this regard … in the end money was the concern for Sun as it sold to LPOD (“Larry Prince of Darkness”).

And the lesson is … ?

Richard Stallman’s pronouncement over crabs in 1987 was correct – software is created because hardware exists which allows smart people to explore and solve problems in new ways. He saw much of the issues with software and intellectual property coming 30+ years before we did – it is the curse of intelligent minds to see the future and sometimes be right. For open source to survive, it needs to be in the hands of the community, held by non-profit organizations at best. Especially when open source products reach critical mass, becoming a core part of the computing fabric, they need to be shepherded by the independent entity of a non-profit.

Ultimately, companies are in the business of making money. Even as much as I applaud Sun for their varied illustrious contributions to a better world of computing, for the many nights I spent compiling on its hardware and living a life of bliss on its operating systems (instead of a life of hell on Windows), Sun was in the business of being a for-profit business and this ultimately collides with the community altruism of open source and free software. As its parting gift, Sun taught us a practical lesson that Richard Stallman warned us about more than thirty years ago.

My roles have included vetting out executive leaders, hiring peers on a team, team members for groups I managed, found countless people for others and even hired my own boss twice. Thankfully, many of these hires have turned out to be great contributors and, selfishly speaking, I’ve both learned a lot working with them and have come to count many of them as friends.

Building teams is undoubtedly a complex problem, multi-faceted in dissimilar topics from project goals, team personalities, to skill sets and roles. Individual hires are also influenced by organizational culture in which they must operate, the customers for whom work is being performed or even the market which is being targeted for a software product. Over the years, I’ve come to see hiring as a set of several kinds of activities; part planning, part archeology, part detective work, add a bit of marketing and let’s not forget the sales skill of closing a deal.

The following presentation shares the perspective and approach I’ve come to use in successfully working through the team building process. Some of these ideas are my own and many are learned from the best of what others had to offer. As with any presentation, the voice over is more valuable than the talking points, but the presentation does provide a sense of the key factors …

In the first article I briefly discussed some core factors around practice based organizations and introduced the first four key benefits of such organizations. Four other benefits are valuable, especially when considering some of the challenges seen in Organizational Design (OD) for larger organizations …

When I worked in either small product or professional services companies, teams were peer based. As such, there was very little organizational pomp and circumstance around communication, information sharing and competency. Productivity was high and success was frequent. While I could wax nostalgic to the simple values of small groups, the reality is that larger organizations exist for a variety of reasons and they, too, must find ways to be productive and effective.

One of the key challenges when managing large organizations is knowing what is happening on projects. Today’s CIO best practice is the PMO dashboard. This is the latest Exec-u-speak for the air conditioned box seat view of what’s going on in the field. This is not to say that dashboards are not useful, but the essence of this situation is simple. If 20 projects are running simultaneously there is no way a leader is going to know what is going on in 20 projects. Red, yellow and green blinking lights are insufficient. Sure one has to trust people, but still information necessary to run the organization is lacking. Metrics only reveal so much of what is happening.

Working with Tom DeMarco, he once told me, “metrics, at best, are mediocre”. Surely, the weakness of metrics comes from a desire to make the complex … simple. To take an analog world and make it fit into a digital picture. If a project is struggling or a key delivery hedges on a go no/go around a certain bug or condition (is it critical or not) … no metrics are going to provide that kind of real-time feedback. Simply, the chain of communication needs to be open, down several paths, and you need to be talking with folks on a continual basis. If one is going to have the challenges that come with a larger organization, one should leverage the benefits of a larger organization.

Specific to the comments above, in the first article I discussed Organizational Transparency through multiple communication paths of the practices. As we see in the following benefits, a less obvious but just as potent set of factors are the ability to quantify, drive and proliferate practice activities in the organization. The more one knows about the capability of their organization, the more capabilities are developed and matured, the better one can assess the potential issues and solutions. So with that said, let’s look at the other four benefits of practiced based organizations:

Key Benefits to Practiced Based Organizations continued

5. Proliferation of Best Practices

The First Rule of Productive Solutions – they are always developed as close to the actual problem as possible. Not in a vacuum in the center of an organization, where someone who use to do real work is going to fashion up a generic solution to a perceived general problem. First real problems on projects should be solved by people with skin in the game of the project. Generalization happens when one adapts a solution to the second project with a like problem, determining what is similar and what is different. Then the third and so on. This activity establishes a best practice. Anything else is a headache masquerading as a best practice. How does one know when there is a best practice? It’s not when someone is selling a solution to others; rather it is when others recognize that the way something is done works for them. Part of the practice and management role is to recognize where these opportunities lie and thusly to help nurture their development.

In a portfolio of projects, certain teams will have glaring issues that are high priority for them to solve. As a result they are willing to invest time and money to solve a problem. Their investment to an ultimate solution then allows other projects to be downstream benefactors of the legwork performed – other teams will still have a cost in adopting a solution and tailoring it to their situation, but the cost is greatly reduced from a ground start approach. This is especially the case with testing regimes, CM and Build infrastructure, deployment capabilities, and development environments.

The function of the practice is to support those in the projects developing the solutions, help maintain those solutions (and some times those solutions end up being owned by the practice, such as a test suite or continuous integration platform) and find new benefactors of these solutions in the form of other projects in the organization.

6. A Natural Path for Practice Maturity

Let’s say you are responsible for an organization with ten or fifteen projects underway (or twenty or thirty!) and someone asks, “What is your QA capability?”. With fifteen projects underway obviously there are specific answers for each project in the details, but you wouldn’t want to give fifteen different answers at a high level. Rather one would want to be able to quantify one’s QA capability for the organization – “Our QA organization is comprised of about 35 people working with fifteen projects. Test leads are heavily involved at the onset of the project, determining the nature of the system and how verification and validation will be performed. All projects have test plans which outline the critical needs and strategy for V&V. Bugs and issues are tracked to closure using JIRA. Our continuous integration platform supports NUnit and JUnit for unit testing. We are currently working with several teams to drive our unit testing to 90% coverage and hope to be there by year’s end.”

Practices have road maps with goals to improve practice capabilities and services to the teams. Those roadmaps can include formalizing a best practice, owning a platform capability in the practice, introducing new capabilities in projects which can stand significant benefit from a new approach, communication around the practice and even metrics and reporting on both project activities and practice level activities. Instead of senior management attempting to get 15 QA leads on 15 projects to perform an activity by mandate, the practice lead works with the QA leads more closely focusing on the value the projects need as activities become adopted as a whole.

7. Counteract negative attributes of stove pipes

Larger organizations tend to have challenges combating insular behavior. It is valuable for teams to be insular – they are focused on their needs (and the needs of their customers). A larger organization has needs beyond the specific customer of a project; but more importantly a larger organization can provide additional help to projects through resources and a larger community fabric.

Insular Challenges: ~ Problems can be solved (or often not solved) in a vacuum and with no more resources than what the project bears. Typically projects build walls around issues they can’t tackle. ~ Stovepipes make it difficult for individuals to grow by moving to new projects on a periodic basis. ~ Insular groups also suffer GroupThink: they often conclude they know best, when outside perspective can often challenge internal assumptions and create new and effective ways to improve or address issues.

Leveraging Standards: Complete lack of standardization not only costs the organization but also the project (if everyone had to build their own CM system and support it, how much of a pain is that versus adopting one of two standards in an organization that come with 24 hour environment deployment, standard templates and some experts in-house that can help get things going?)

Balancing Message Management: Stove pipes often manage information coming out of the pipe, as a form of protection from outside forces (read, management and customers). This is in part caused by poor experiences by team members with prior management; it is also caused by a natural tendency to not want to deliver bad news and deal with the consequences. Stove pipes can become very adept and managing the message. A part of message management is necessary – one wants to give teams a chance to work – a certain level of transparency is apropos as is a certain level of opacity. With Practices, multiple channels of communication open up, both horizontally and vertically. Anyone in a management role needs to pay careful attention to how that information is used – it is important to respect the team and give them opportunities to right courses, make mistakes and learn. At the same time, the multi-dimensional view provided by project managers and practice leads can be the difference between seeing projects in color versus black & white.

8. In-House Surge, Contraction and Augmentation Support

On a final note, practice based organizations can be critical to maintaining facets of capability both in surges and contractions. During a surge, additional resources beyond the immediate project (or upstart) can be leveraged, some times from other projects or from the practice lead directly. The practice will have a pipeline for talent outside the organization; they are well plugged into the community and expert at finding people.

During downturns, practices can help keep the best people and ensure that practice capabilities are considered when having to perform reductions. Practices can also identify opportunities for projects and the organization to accelerate standards and normalization to help increase efficiencies to take on a contraction in funding.

Finally through a practice, projects can get specialized or fractional support: the former for things such as automated test engineering or UX design. For the latter, many small projects can not support full time resources for certain activities (say CM or deployment). In these different situations, practices can help ensure an overall stability in the facet of their expertise by helping to provide or remove resources as needs change.

Matrix management is not uncommon in larger organizations. Most of us have experienced its negative use – namely confused accountability and frequent moving of people from project to project resulting from poor management planning. Practice based organizations employ matrix management, yet the key focus leads mostly to improving the quality and capability of project teams. When executed with the following principles in mind, projects and teams yield significant benefits …

Practices are the various skilled facets of an activity necessary to accomplish that activity effectively. In software projects they include (but are not limited to) software development, architecture, data, project management, quality assurance, configuration management and infrastructure engineering. Depending on an organization’s needs, any number of other practices may be added, from usability (UX) to business analysis or deployment or customer support or …

Practice based organizations typically group specialist into practices either through direct reporting to a practice lead (and then individuals are matrixed to projects) or through practice groups which meet periodically to work on aspects of coordination and improving their specialty.

Practice based groups should be run by practice leads – people with deep experience in the specific practice. Along with that experience, they should demonstrate three other key attributes:

1. A proven track record for coaching others in their field.
2. An attitude of service, as the focus of the practice lead needs to be the betterment of projects that do not belong directly to them.
3. An outgoing personality, as the success of their practice largely relates to the lead’s ability to go out and understand the projects they serve and the people on them.

Individuals from practices should generally matrix into projects for long term engagements. Teams need to build stability so cohesion and productivity increases as the team works longer together. How does accountability work? Individuals matrixed to a project are operationally accountable on a daily basis to the project leadership, which includes their tasking and subsequent performance.

From a quality and competency perspective, the individual reports to the practice lead. It is the responsibility of the project leadership to ensure productive use of the resource. It is the practice lead’s responsibility to ensure that individuals on the projects perform admirably on the project, implement practice standards on the project and bring back lessons learned and best practices to be shared with others in the practice.

With that brief introduction, the following list reflects the benefits I’ve focused on when shepherding a practice based approach. I will continue with the latter four benefits in a subsequent article:

First 4 ( of 8 ) Key Benefits to Practiced Based Organizations

1. Everyone is a First Class Citizen

As a software developer for many years across many projects I often found that developers are the “first class citizens” and many of the supporting roles are second class citizens. Ask any QA person and they’ll say, “Oh yeah I’ve experienced that! Story of my life …” When looking at the maturity of software development teams, higher productivity teams typically know how to leverage more facets of the software development activities. Practices help the organization elevate the importance of the “other” specialists beyond the developers.

Practices not only provide a voice for QA or CM or … but also an advocate through their practice lead. For example if a QA person can not agree with the project manager as to the criticality of an issue with regard to a deliver/no deliver decision, the QA person is no longer squelched in a reporting hierarchy; they can speak with the practice lead who can intermediate and resolve or decide with their project management peer that the issue needs to be escalated for resolution.

Secondly, specialists tend to place greater value what they know more than what they know less. As an example, a project manager is more apt to focus on current impacts on budget, schedule and customer commitments. Quality and risk become the trade-offs in software design, CM shortcuts or QA issues for example. By establishing teams where the project manager is the hierarchical lead, one ensures that budget, schedule and commitment will almost always win out over any other issue.

2. Experts Hire Experts

A typical stove pipe team will have the project manager or project lead hire the team members for DBA, QA, CM, SA, et al. Of course any project manager or software development lead is likely to say, “I know what I want in that person.” Well of course they have an idea, and their needs are very relevant to hiring. But the reality is that few project managers have been a QA lead for 10 years; they are not expert in the field.

In a practice based organization, Practice Leads work with key stakeholders on the project team to staff the right people. This begins at the onset of the staffing cycle, understanding the project, its challenges and what kind of practice based approaches could be most effective. The Practice Lead will typically take lead for finding the individual and bring candidates to the team. Ultimately the hire needs to be agreed upon by the Practice Lead and key stakeholders on the project – everyone has skin in the game. In an organization with many projects, this approach can ensure greater practice quality and capability consistency across projects. For the project team it can provide higher quality candidates with an expert view of the project’s need from the Practice Lead.

3. Organizational Transparency

Larger software organizations struggle with visibility into projects and their activities. Visibility solutions are often mediocre and include monthly project reviews, milestone based reviews or worse yet senior management parachuting into projects when rumor indicates something is wrong. A yet worse solution is an audit group that independently communicates project activity. Modern day versions are smoothed over into PMO’s (Project Management Offices) and can ostensibly perform the same activity. These groups are typically fraught with, “those who can do, those who can’t police.”

The executive miss in organizational design is not understanding that different practices employ people with different perspectives. Project Managers message manage – it’s part of their job. Developers, most of them, will write more code if given the chance. DBA’s will forever find data problems in a world that is never quite perfect. These all have inherently positive contributions which sometimes also have negative side effects.

Practice based organizations recognize the value of all these activities and also provide multiple natural communication paths up the management hierarchy. In this way there is organizational transparency as well as a manner for resolution for different perspectives to occur through management peers in the hierarchy. For senior or executive management, broader visibility through expert eyes surfaces important opportunities and risks, versus canned monthly presentations or auditors or PMO members lacking deep expertise.

4. Birds of a Feather

It is not unusual for all but significantly large projects to be staffed as follows – several developers, maybe a data person (or two), a QA person (or two), a CM person (part time), one project manager, maybe an architect. Of course smaller projects have people performing multiple roles (e.g. dev lead is project manager and architect). But for anything but very large projects the issue I’ve consistently experienced is that developers often have one another to commiserate and problem solve. The other folks are onesies on the project. I experienced this first hand when I went from being a developer to a project manager. The only person I could really get perspective on project management was my boss.

With a practice based approach, specialists now have a greater community in which they can interact, build relationships, share in both challenges and successes. Without a practice approach, specialists could still reach across projects but may have to cross priorities and political boundaries. The practice approach facilitates community and sharing with specific activities intended to help connect its specialists, raise awareness of the activities across the organization and promulgate the state of the practice’s art.

(Click here to see Part 2 of this article)

A while back I brought in a coach to work with a critical team in an organization. Key stakeholders were in a extended set of exercises working around their project mission; I participated with the team throughout these activities. Staffed with several conservative individuals who were bright and capable, team leaders continued to observe how operating outside their existing status quo was not feasible given a larger corporate culture, even though they saw significant enough opportunity for the team to shine if they did so.

People spoke of improvement metrics … better delivery, less bugs, blah blah blah. I finally spoke up specifically addressing the two senior members of the team with the following suggestion -

“Folks I’ll give you my metric. How much fun are you having on this project? All the stuff you’ve been griping about – is it fun? Are you enjoying it? No of course not. You have the power to improve your project, your software and your work environment. You have much more power than you recognize. And your attitude is contagious. If you believe you can’t do anything, your team will believe it can’t do anything. But if you believe you can do something and you work at it, your team will ultimately work with you. As for management, sometimes they can be laggards. I guarantee you that if your team becomes more productive and is having more fun, your management will also catch on to the positive buzz. You have more power than you know!”

A team’s ability to build momentum and culture is very powerful. While management and customers can facilitate a team’s ability to improve, improvement NEVER builds top down. Even without support, a team can improve significantly bottom up, though it takes a few strong and willing people seeded in the team. There is no such thing as top down improvement. Only top down support. Improvement that endures can only be built bottom up. Did I say this enough times?

As a manager or executive with teams in one’s realm, how does one facilitate bottom up improvement?

1. Be Honest - There is an old saying in marriage – when there are difficulties the first person that needs to change is the one in the mirror. The single greatest impediment to change is management. Change is going to cause a lot of work, it will invariably mean political coin needs to be spent. Sometimes work will slow down before it improves and speeds up. If one does not have a strong enough mandate or desire to walk the path of continuous improvement, do not make the mistake of taking teams down this path – one can do more damage than good. There will often be team members that leave, or members that ultimately need to be removed. Continuous improvement is messy business – the rewards are huge but they are also proportional to the commitment required.

2. Plant Seeds -  Teams need a mix of people, but most importantly those that will set pace and lead the team in a desire to continuously improve. Teams that have not yet substantially embarked on continual improvement are always hierarchical, hence this person will be a development lead or technical project manager. A team member may already exist with the right qualities. Hiring such a person is tricky – plenty of people talk the talk (“agile”!) but few have gone through the messy transformation of teams firsthand. A successful candidate is one that can talk about transformation and improvements situations in the past with all the gory details and difficulties. They will have battle scars from this kind of leadership. They should be able to describe what they’ve done wrong. Be leery of people that focus only on how upper management and the organization didn’t support the activities. While this is often true, someone who believes the problem is everyone and everything else is one that has not begun their own journey of continuous improvement! The role is less evangelist and more leadership by example. If you don’t have deep experience with such people, get help finding them with someone that does have the experience. Oh, and the experienced candidates will frankly gauge your commitment to improvement because they will have been burned in the past.

3. Participate - People trust one’s actions not one’s words. Communicating something is important and not backing that up by commiting one’s time and energy means the topic is a) not important after all, and b) that one gives lip service. One is better off saying nothing than behaving disingenuously. I don’t know how many times I’ve seen people in leadership roles say something is important and have everyone else focus on it. If a leader says something is critical, they should roll up their sleeves and be involved. Note, I did not say micro manage. Treat one’s team as peers. Be involved and put skin in the game.

4. Create a Safe Environment - Teams solve the problems that are easy to solve and build walls around what they can’t solve. Breaking down those walls and exploring what is hard pushes against individuals’ limits. Often in the sociology of a team, the psychologies of individuals establish those walls. Individuals need to be encouraged to tackle hard problems, as do teams. They also need to pick the right hard problems to tackle – those that impede compelling goals for the team. A safe environment is one where issues are tied to accomplishments which are important to the team, where members shows vulnerability, honesty towards others and empathy of what is hard for them. Every team has at least one white elephant in the room. Therein lies a treasure trove of improvement.

5. Pour in encouragement - not in a disingenuous way. Verbally note victories or positive qualities. Reward effort, not just success. Demonstrate in your actions and words that you believe in a team’s abilities. Technical environments are full of problem solvers. Problem solvers first tend to identify problems and communicate about them. Celebrate victories. Sometimes it’s about accomplishing something big. But often it is about sucking less. Businesses and technologists deal with enough hard problems that we really need to establish a culture that balances out the constant battle of challenges with more genuine acknowledgment of the improvements we make. No, not tenure awards, not bonuses … sure those are fine things. Rather, we are talking about the every day culture. Not just the once in a while atta’boys.

Some members of the M3 SIG have made the point that one can’t build the E30 M3 today. To an extent I would agree. But really what are we talking about? The exact car? Obviously not. Such a comment begs the question – what does it take to build a car of such hallmark impact?

The more difficult issue is one of inception conditions than one of current automotive market. The E30 M3 was borne out of a unique set of circumstances with a unique set of people. Anyone who has been deeply involved in building something of significant capability and beauty intrinsically knows what I mean. If one does not have such experience in one’s background, then I suspect my words are near meaningless. Can such an accomplishment be formula – an assemblage of specifications and parts?

The E30 M3 is an automotive experience. Like the trite saying, the whole is greater than the sum of the parts, a superb automobile is not a bunch of nuts and bolts. Nor is it created by merely picking the right nuts and bolts. That would imply a simplicity which belies the complexity of creating such a special thing. As I often like to say, art is science with too many variables. The creation of such things is high art form practiced by those with deep engineering chops and superlative craft skills.

The real questions are:

1) Is there a team of people that (as the TV show, the A-Team would say), “have the jazz” to make something special?

The once Technical Director of BMW Motorsport, Paul Rosche, was a special breed; he had a knack for many things, including not suffering fools. He assembled outstanding teams. His leadership is rare and its impact profound. Anyone who has been in such a situation, being led by such an individual (that experience places one in a small minority), knows the potential for accomplishing great things.

2) Is there a strong enough unifying goal to keep the team focused to the end product?

Winning Touring Car championships was the goal for the E30 M3. Its homologation circumstances (along with its strict rules around aerodynamics and such) gave us the street going version, with minimum deviations from the race car to make it street worthy. 60 national titles for the BMW M3 between 1987 and 1992 tells of its success.

3) Can such a project be pushed through, without significant outside mucking about?

The above #1 & #2 play significantly into #3. If 1 Series M Coupe is a marketing exercise, I will not discount the possibility to produce a like car, but I’d put short money on the bet.

In the early 1970′s, the coveted BMW 2002 arguably launched BMW’s modern vision of the Sedan. Many BMW 2002 owners see the E30 M3 as a car much influenced by the 2002. Not the same, mind you, but a car they’d want in their stable next to their 2002. I believe this is where the 1 Series M Coupe needs to target if it is to meet the goal claimed by BMW M Boss, Dr. Segler.

From a pure accounting perspective the E30 M3 was likely a money loser for BMW. Not so much because BMW was trying to lose money, but rather because the priority was not that of a typical production car where mass production recoups investment cost. In those days the E30 M3 was hand built in a special BMW Motorsport production facility. E30 M3 production ceased in 1991. In the early to mid 1990′s BMW Motorsport began work on the second generation E36 M3. BMW did not want to bring the second generation E36 M3 to the USA for fear of financially losing their shirts. Remember the M-technic 325is of 1994? Or how about the official version of that 1994 car, called the E36 M3 in 1995? Not true M3′s in the USA (while europe did receive a true E36 M3) but badged and optioned cars to look like the real thing.

I’m not suggesting that an E30 M3 inspired BMW can’t be in the black; what I am suggesting is that BMW has not experienced a money making market for such a car since the BMW 2002. Significant circumstances are required to build something so special. Yet ironically for BMW, the 2002 and the E30 M3 became the respective foundations for BMW’s economic prosperity both in the sedan market and in motorsport.

I’m a Python fan, which isn’t saying much as I’ve only coded a half dozen example programs in the language. Having come from a Perl / C / C++ / UNIX background with lots of data processing, I appreciate Pythons power and elegance. In the geek community, Python is a well respected language with some functional programming capabilities. The SEC choice could be far worse – much of this kind of work is done in Excel with VBA embedded in spreadsheets and cells.

So let’s consider a few questions …

Is SEC specifying a computer language to represent financial waterfall models a prudent idea?

If I was going to choose a language to tie a waterfall model for public consumption, a better choice than Python would be hard to find. Python is generally well designed with some functional programming capabilities. It is open source, platform independent, stable and reasonably mainstream. As alternatives, Perl would likely see more obfuscated coding examples, C/C#/C++ lacks interpretative benefits and the other choices are too far off the mainstream to consider (name your favorite functional programming languages which are the rage in Europe or logic programming languages like Prolog).

That being said, while pulling the waterfall model out of a 100 page ABS prospectus may be a step in the right direction, burying the model in code has its issues:

• Which is legally correct – prose or code? Given the textual description of the waterfall in the prospectus, there are now two representations of the waterfall.
• Regulators should specify objective, not method. Tying disclosure to a specific language platform specifies how companies are to represent the waterfall at a very specific level. While I understand the prospectus is likely to be required as written in English – we standardized on the English language in the USA by de facto, if not for the founding fathers documents being written in that language. In Computer Science, such standardization has very different implications.
• Now the waterfall is locked in code. While the data is in XML and can be culled and operated upon by any downstream software, the waterfall (which is ostensibly a set of mathematical functions) is locked into a programming language. What’s the basis for legal interpretation of algorithm? Should make for an interesting legal reality of Gödel’s first Incompleteness theorem.

Would a logic and control flow specification provide the same class of transparency? If so what would be the downside?

A better representation of the waterfall might have the following characteristics:

• Referential transparency which programmatically speaking means no side effects. Functional programming can be performed in Python, but few languages limit side effects, and while some have gained more popularity in Europe they are obscure in the USA. A declarative specification would address this issue.
• True portability, versus just open source. If one considers XSLT as an example of declarative specification allowing operational end states to be realized as desired.
• Before the waterfall model was buried in prose. Python means the waterfall is buried in code.

The downside to specification based codification is more up front complexity and less mainstream adoption both for the SEC (versus simply specifying that a prospectus must have a waterfall Python program, it would now have to establish specifications) and the corresponding ABS originator (who is now dealing with something likely even more obscure than coding directly in Python). This would take years to sort out, whereas specifying Python places the onus on the ABS originators who have the financial means and motivation to produce the code.

In short the choice of a mainstream, portable language seems to be a brilliant trade-off of real world factors.

Does code really solve the problem?

It definitely seems to help. Transparency should increase as should the ability for investors to more easily create scenarios – the issue is not so much who gets paid but the likelihood of who is paid how much and when.

Writing a prospectus that is either obfuscating or interpretable benefits the ABS by operational wiggle room – code may help determine where this occurs. Or not. Provability in software is difficult but I believe the greater issue here is simply providing the greater transparency.

The SEC proposal to codify ABS waterfalls has received lots of kudos, from programmers contemplating the possibilities to professors who have been critical of wall street and regulatory ongoings. In spite of some of the issues I note above, I agree that the SEC proposal is a step in the right direction both in intent and in speed in which it can be executed. The shortcomings of specifying a programming language is likely outweighed by the benefits of having a solution now which provides more transparency sooner with almost no risk to achieving the transparency.

From the prior article about second order harmonic, we’ll now go on to explore some examples which will help frame the kinds of dialog that should be in an interview.

(hint: this technique’s value is hardly limited to interviewing. Next time you have to figure out what’s going on in a project or company, try applying these approaches in your questions – you’ll get some very telling information!)
 
 
 

Example #1 ~ Don’t ask direct questions.

There are two predominate reasons for this approach. First of all pat questions deserve pat answers. And you’ll get plenty of them. If one was to ask, “Do you believe code should be documented?”, what kind of answer am I going to provide? What did we learn about my thoughts on documentation? Exactly. Nothing.

As a specific example, as a hazard of my vocation I am well versed in development methodologies. I will never ask someone what development methodologies they use or believe in or have been successful with. Never will the words “agile”, “iterative”, “waterfall”, “XP” come from my mouth. In fact I won’t ask the question in such a way that those words can be used as an asnwer. “What type of development approach do you find most effective?” is a fruitless question.

I’ll start a methodology discussion asking a question such as, “If you had a funded project with a business customer and a project vision, but no team, tell me about how you would start?” One cannot just answer “Oh, I’m agile”. From that point on, all the questions will be around what is being done, why and how. They will discuss what they do first, second, how they’d build the team, engage the customer, set up the project, and many of the lifecycle activities. What they don’t discuss will be equally telling. Through that conversation, we’ll draw in parallels from previous work experiences (e.g. I may ask, “did you do X on a previous project?”). After 10 minutes of dialog in this area I will have a very good idea of both their experience and their approach to development. That is the second order harmonic. I will have a deeper understanding of their methodology and philosophy through what they chose to focus on and how it paralleled their work experience; that is, deeper than someone telling me they are “agile” and explaining how and why.

Example #2 ~ What matters in a work environment?

My interviews are easy, most of the time. Why? Because the goal for me is to extract as much information as I can with a candidate. For that to happen, they have to be comfortable and conversant. I often ask questions which have no right or wrong answer, but rather reflect on someone’s experiences and philosophies. I’m not advocating avoiding hard or specific questions, mind you. I’m going to assume (maybe incorrectly?!) that asking such questions is obvious. Best to ask direct and difficult questions once the interviewee is relaxed and conversant.

Back to the example, pose the following question to a candidate – “Say you managed a team where 1/3 of their compensation was potentially paid in bonus. You have to base their merit on just two factors in the workplace, what would those factors be?”

There is no right answer, but their response becomes the entry point to valuable conversation. Why? Their answer will invariably reflect what they’ve either seen to be most valuable in the workplace OR what they believe to be most valuable but have never experienced. The latter actually implies quite a bit about the individual. But nonetheless the second order harmonic will be unique insight to what has mattered in their work experience. How is it second order? The first order information is on the resume – responsibilities, roles, experiences which you would otherwise read through and discuss throughout a typical interview; with a second order approach, the dialog which ensues will go well beyond the information on the resume. In fact you will thematically discover what the candidate believes their most important contributions are as well as their most important traits or attributes. Rarely does someone provide answers which do not reflect what they perceive as their own strengths.

Example #3 ~ What are the most significant contributions you believe you’ve made?

Not long ago I interviewed a senior architect. He had been internally referred and was known to be a reasonably capable guy. I spent some time discussing his contributions in the workplace. People love to talk about what they think is important. By following through and asking for more contributions, a theme began to emerge which demonstrated a strong desire on his part to organize interactions with outside groups, such as auditors. After several examples which he chose, it became clear that he viewed his architectural activities more in the realm of what a PMO may do in a large organization. Of course his resume did not read that way. Nor was he specifically looking for such a position. Why is this important? Recall the organic jigsaw puzzle – if one is looking for an architect to tackle those kinds of issues, then this could be your man. But if we are looking for someone who is going to dive deep and drive what a technology team needs to successfully build software, this guy may not be the one.

Most roles are multi-faceted and someone will fill certain facets better than others. Said another way, the best way to know if someone likes chicken, beef, fish or vegetables is to ask them what they want for dinner across several evenings. See what they choose. That is not to say if they choose beef in general they don’t like chicken. But someone who consistently chooses beef is not the person I’m going to typically ask to be the fish expert. The second order harmonic in this situation – rather than directly asking a candidate what is most important in a role they might take, we learn what they believe matters most by observing patterns in their contribution, then tying those patterns back to their work experiences.

http://www.reynoldsguitars.com

I tend to frame topics in analogy – this helps shed the lesser relevant details and focus on the essence of a situation. So it is with analogies and the second order harmonic.

We’re probably all familiar with the term, “pinging” or “engine knock” – when our automobile engine makes that funny noise and the car stutters just a bit. Modern cars do this less frequently in part because emissions regulations from the mid nineties have required engine manufacturers to sense “pinging” and retard the engine timing. (pinging occurs when hot gas is compressed to a point that it begins combustion in the cylinder prior to the spark plug igniting the gas charge). But unfortunately the engine is a noisy place. Sensors listening for that pinging sound incur many false readings. To solve this problem, engineers went to the second (and third) order harmonics of the pinging sound. It turns out that much less noise exists at the higher harmonic frequencies. The sensors can determine engine knocking with much greater accuracy.

Interviewing has much that same issue of signal to noise. There is too much information in too short a period of time. Let’s face it – you’re going to make a decision to hire someone that you will spend 5 days / week with and rely on for many things. That decision is made with a scant hour or two of exposure. We often take years to know someone before we marry, but living with team mates is a interview time flash in the pan. In that short time we look for the experience needed for a role on the team. Have they coded XYZ types of systems, do they know, have they led small teams, … . These are all the first order criteria. One should discern these core issues, but that is not where most of the time should be spent.

The second order harmonic is about really understanding the interviewee. What is their nature? How are they going to fit in? How are they going to contribute? What is going to be problematic for them? These answers are not right under one’s nose. Not only that, it is the job of the interviewee to put their best foot forward – if you attempt to figure out these topics head on, you’ll be challenged by separating the best foot from the other foot. The key to the second order harmonic is to get into discussions that don’t necessarily relate to work, or address worked related topics indirectly. After all it is not just what they know that matters – how they think will really impact the workplace.

Where are these places? Discuss hobbies. Find out what makes them excited. Ask questions that tell you more about their values than their knowledge – “If you had a group of people working for you and 1/3 of their salary was based on performance of two criteria which you set, what two criteria would you bonus on?” – there is no right answer. Those are the best questions … it’s an analog world. Let them explain what they’d choose and find out why.

Let me end with a story on an interview I performed some time ago. We were looking for a VP of Software Development. I met with a possible candidate, someone who had been in the business for twenty years. Good degree background, worked in a few prestigious organizations. We discussed fundamentals about software engineering, teams, people, architecture, et cetera. His answers were reasonable. Toward the end of the interview I tell the individual that I’d like to discuss their technical background from when they were hands on (writing code), prior to becoming a technical manager. I let him know I was aware his hands on experience was some time back – I’d be gentle. He explains his last coding position was in the mid nineties, spending 18 months writing C code ingesting data on UNIX servers. I ask, “Did you consider other ways to code and ingest data, other than using C?” He looks at me quizzically. Assuming my question was unclear, I elaborate, “Well you mentioned you were on UNIX; there are other tools for manipulating data, for example.” His answers immediately, “Oh I was not a UNIX admin.”

There is the second order harmonic. Why do I say that? Any serious developer on a UNIX platform knows UNIX like the back of their hand, especially doing back end work. No self respecting UNIX geek would ever say they weren’t an admin. They not only want root access to the dev boxes, they probably run some UNIX equipment at the house. His answer told me he was not a deep geek but a task oriented programmer. As a VP of Development one is going to have to discern very fundamental technical issues without having one’s fingers dirty. Not to mention knowing how to successfully create and maintain teams with people that know how to build software projects successfully. Deep knowledge in software is required for such a role. To make the right calls on the direction of work, and to know on whom to rely and why, one needs the deep technical experience. The trajectory of this person’s career was typical – several years of light development work followed by a career managing people. Undoubtedly he did the latter well, but I was not going to trust his judgement when it came to the software jewels for which he and his teams would be responsible.

For a few more detailed examples, see Questions in the Second Order Harmonic.

Let’s face it – “A” players are high maintenance. They have ideas. Even worse, they have ideologies. They don’t like to sit still. They struggle to suffer fools. If you’re managing “A” player’s you’ve got your hands full. So why on earth would you want them?!

Imagine you’re the general contractor, having a house built. One carpentry crew manages to put up 3 studs each day. Another carpentry crew, the “A” team, puts up 3 rooms each day. The “A” team engages you and the architect early and frequently in the project, builds jigs and tooling, knows how to subdivide the job. The “A” team is making progress fast, causing work for you because they are moving fast. You have to keep materials supply in stock, get other sub contractors ready to execute their tasks, review work being completed to ensure it aligns with what is desired, sort out details of design in the work to be completed. On the other hand, at 3 studs each day, the former team will give you plenty of time to relax, leave work early, enjoy two hour long lunches as nothing is occurring with speed.

So everyone wants “A” players – and “A” team, right? After all, it’s great to move into one’s house 3 months after construction. In the case of having one’s house built that may very well be true. In the case of software it is more true with product companies and small companies. The rest of the great expanse of IT, not so much. Why?

When needing a place to live, one is truly motivated to get the work done. There is a compelling goal – get the a house built over one’s head before the money runs out. That will get most people’s attention. A software product company is in a sprint: little money and a market that barrels ahead full of competitors and changing landscape, irreverent of the company’s grand plans. Even a small services company having only a few clients and a month of work backlog: if the customers are less than very impressed, the small company will quickly have no income as work vanishes into thin air. Both of these situations are compelling for its participants. Most of these folks know the only way to play against such odds is by stacking the deck with “A” players.

In the vast land of IT, there is a fair bit of “kick the can down the road” / “cost containment is priority one” perspective. Hardly the place for people that will ferret out problems, raise them for the purpose of solving them and drive change in otherwise static or at-equilibrium environments. If you’re a CIO shepherding such an environment, read no further.
So what are the characteristics of “A” players in software development? They typically exhibit a significant number of the following characteristics:

• Motivated. Evident by their accomplishments. Don’t make the mistake of just focusing on their professional career. See the next characteristic.
• Multi-disciplinary. “A” players are curious. They typically have significant expertise in other fields. Not a passing fancy – but significant expertise, to the point that professionals in other fields would consider them worthy of employment in that field.
• Research and Explore. Delving into subjects, “A” players achieve expertise by knowing how to leverage the work of others. Legends in their own minds are rarely to be considered “A” players – their facsimile of “A”-hood will ultimately backfire, often at significant detriment to the endeavor. That said, there are legends worthy of engagement – but one must have significant technical management chops to employ such characters.
• Opinionated. Everyone has ideas, but “A” players are often ideological – they have “a way” and they can tell you at length why that way is the better way. This isn’t about being pigheaded or myopic. Rather it is about a contextual grounding in deep experience from which they operate.
• Curious. They ask questions. They may not agree with the answers, or they may probe further. “A” players are inquisitive and engaged. Not necessarily extraverted. In fact often not.
• Collective. “A” players tend to hang out with other “A” players. This matters because often the chain of contacts can be worked to discern the “A” players. Even “A” players that have different ideologies from the person in question will acknowledge another’s capability regardless of that ideology. This collective is important – in a craft, people don’t define themselves as experts – the greater community defines people as experts.

What can one count on, with “A” players?

• They will attract other “A” players. They will want to remediate or shed “B” players from the team. They will outright open an offensive on clearing out “C” players.
• They will get work done. You had better be engaged as they will run ahead based on what they understand should occur. They will also make you look bad when they’ve accomplished all the work on hand and you’ve not stepped up your game to line up the next set of compelling needs.
• They will leave when either no compelling achievements lay ahead or their presence is aggrevating an otherwise complacent work environment.

Better Web Application from Didiet Noor on Vimeo.

I had some issues with the representation, though it probably has some reasonably accurate observations in spirit. First of all, the setup – the project at NOAA was a total miss. If they
were doing it as described, the technology picks were kind of a miss. I was building stuff just like that in that time period. When we built apps on top of NeXTStep, I coded UI’s with Interface Builder on the NeXT with my customer sitting right next to me. Flip a switch and see basic functional UI, changes in moments.

In that time frame, you would parse data with SED/AWK … and depending when you were starting Perl came into being. Any text mangling for impromptu analysis was done with Emacs macros. Hardcore folks in various corners used LISP and variants. Doing this stuff in C++ was the answer to a question no one ever asked. If pressed, there were some add-on libraries should you have no choice but to do it in C++. Roguewave had some libs, as well.

So to frame up the problem NOAA had in terms of the solutions they chose … and the fact that the guy framed that as a basis of comparison doesn’tgive me much confidence in the discernment department. There were better ways in 1990, though the issue of composite applications as he described back then had other problems around IPC and high coupling.

Moving into the present set of examples, he would have done well to just skip the Hello World details, instead of the time tracker app. Modern coding environments are built to deal with a lot of contextual hair, not the least of which that apps running inside of HTML … no wait, Javascript … is an architectural hell. As if there weren’t enough problems before the three tier madness began (and with the last tier being most decrepit). The “Hello World” apps tell us not so much that our codingenvironments have gotten more complex, but that our computing requirements have gotten more complex in such a way that we don’t have clean and simple solutions for them.

I am not a fan of the complexity often seen in these solutions today. I doubt most of us are. But these simple apps can easily miss the point. These environments are targeted for certain classes of problems. J2EE is not targeted to deal with Hello World apps. It wants to be everything to every one. It is the pseudo-open source version of Microsoft; but even more complex, largely because MSFT lives more religiously within a one company box!

As I look more at applications today, especially in the enterprise, I’m becoming convinced that one key issue is how many places the data model needs to be represented, and how often the data has to be transmogrified (a Calvin & Hobbes term) for its next state of use. Let’s see – we have

1. an input form or data file/stream spec (data model)
2. software to ingest form/data file/stream (data model)
3. an OLTP data store (data model)
4. data movement to longer storage ODS/DW or … (data model)
5. ETL (data model) between OLTP and ODS/DW
6. OLAP/DataMart store (data model)
7. ETL (data model) to OLAP/DataMart
8. App queries (data model)
9. App rendering (data model)
10. Inter-app communication (data model)

This representation of data throughout the processing model is painful. Couple that with extremely crankly end user computing model and we have the current set of solutions in front of us. Folks love Rails, for example. The word I hear is for classes of simpler apps, it’s great. Complex stuff, different issue.

Portals – everyone I’ve known thus far either complains about them, or codes around them or minimizes their use. I’ve not had the privilege to code with them, so can’t speak first hand.

The backend coding doesn’t seem as rough as it use to be. Talking to multiple platforms we use to have Big and Little Indian problems (then solutions got baked into stuff like RPC), we saw a plethora of solutions that were considered acceptable to code interconnections. Some of that has grown in a somewhat respectable fashion with web services technologies, as least in that realm.

Unfortunately the industry believes everything should be obliterated into a relational model, save the text search weenies. This seems long standing, but add insult to injury it seems like it has become a given that any software system must have an RDB somewhere and some SQL buried somewhere. I wrote a lot of software and I can count on one hand the number of times in my life prior to 1999 for which I had to write SQL. If I was still writing software on a daily basis, I doubt I could make the same comment a decade later.

And to the worse point … the UI’s in the main stream just haven’t done well. Shall we forget that MFC (Win32) was a spaghetti pile? And before we can even throw our usual stones at MSFT, that XWindows was an over-engineered nightmare? To write UI’s for a living, you had to gronk the COMPLETE O’Reilly X Windows book set. If one skated on MOTIF knowledge only, or some layer on top like OIT I assure you that one’s work was superficial.

IPC between apps was not much more pleasant I suspect than portal programming today. And for all the threaded apps I tore apart and rebuilt, reducing the threading – threads were a nightmare in user facing systems which I had the “privilege” to remediate.

So let’s look at the heritage 20 years ago to now:

• proliferation of the data model has increased, due to a) more layers and b) more end points for data usage.
• data models are still RDB-centric. We use XML more for transport and interface than for comprehensive model representation (store, traverse, search).
• networking has gotten easier (whew … at least some wins?!).
• languages, IMHO, are no better than 20 years ago, but often struggle to go from “language” to pseudo-operating-system-development-lifestyle (e.g. Java). But frankly I don’t see algorithm as our core problem, so languages are adequate at worst.
• UI’s have been a train wreck for the last 20 years. Sure there are examples of better worlds, but the main stream has been ugly.

Compute and network power hasn’t helped us in this regard – Moore’s law makes us have even more freedom in a world of computing that we quite frankly have lost control of shaping complexity. Don’t believe me? Then why are iPhone apps better than equivalents on machines with 10x the power/display/connection? Try to use the eBay app on your iPhone, then on your desktop/laptop and get back to me. All of us on this distro are old enough to know how parsimony comes with limited resources.

And ironically, with the massive resources available today, J2EE authors still manage to create object instance storms that grind servers to a halt.

We need some disruptive innovations in my opinion. Compute cost for corporations has gone up in the past twenty years – while more of the business activity has gotten increasingly in bed with the corporate computer, I also believe that some of this has come from the tangled gordian knot of the above diatribe. After all if that was not the case, explain why a company like Google would GWIT their way to abstraction of JavaScript in hopes of never having to deal with its consequences again ….

level integrations anyone?

Whenever someone asks that question, akin to “what do you want to do when you grow up?”, the answer seems to start with a pause and a breath. So I replied …

“I’m looking for a situation where there are one of two things – either a big pain to solve or a significant desire to achieve something. Now against that if there is no substantive vision to address the challenge, that’s great and I’m glad to help shape it. If there is a reasonable vision already in place, I’m fine with that.”

I’ll pause for a moment. Most people at this point guess that I want to tackle something challenging, sink my teeth in, get recognition, maybe a career growth path. Fame? Fortune?! (we’re getting delusional now). Here is the rest of the answer I provided:

“So I realize the above challenge and vision piece is abstract to begin with, but let me explain why that’s important to me. Selfishly speaking, I like to work with people that are smarter and better than I. Smart people are a pain in the ass. Why do I say that? Well they get things done. They have ideas. They are motivated. They are passionate. They don’t suffer fools or people without motivation. They have ideologies. They like to collect more smart people, with that comes with more of the same. These people cause work for others. They cause change. Most people don’t want change. So the only ecosystem that will support them is one where there is a big enough pain or challenge to achieve, such that people in the ecosystem will endure the discomfort of change and innovation in return for getting something they ultimate see of great value to them. When that challenge is achieved, often those smart folks aren’t so tolerated – or they get bored. Either way, they leave.”

My high order bit is creating and nurturing such environments because, selfishly, I find them tremendously rewarding – they not only raise my bar but create an environment where real and worthy accomplishments occur. Isn’t that what work is supposed to be about?

It’s 1988. I’m a freshout, having been minted with a CS degree from William & Mary. During college I spent 2 years with an elite group of hackers (in the old school meaning), much of what I learned about teams, computers and software came from a group of about six people. Most of them prodigies in their own rights – at age 16, one successfully hacked admin rights to a unnamed company’s DEC server from a dial-up line, which landed him his first paying job; others went on to receive Ph.D’s and some today run high tech startups.

For a first real job, I decided to find work on UNIX machines, for the simple reason that I was fascinated with UNIX and the hardware on which it often ran. Having played with AT&T 3B2′s, Sun 2′s, a taste of C, scripting and pipes – I was hooked.Fast forward to a number of interviews: I end up at a small company having met a senior engineer over beers; he discovered that I had apprenticed to a Master Craftsman while in college – his father was a carpenter. Six weeks later he called and asked if I was working yet. A quick “no” followed with an invite to interview with the team. When I asked if he needed a resume, he said he knew all he needed to know about me from the discussion about working with the master craftsman. Turns out the guys at this company had hired each other from past gigs. Half way through an interview with two of them, they segue into a heated discussion about the software they are working on. The interview is in suspended animation, as if I’m not there. They were an eclectic bunch – one an artist growing up in Santa Cruz with no CS degree, another blind and having designed hardware and drivers to support computer interaction without sight. Add in others with backgrounds in atmospheric physics, and two that went to high end colleges at age 16 and had masters degrees in comp sci by 22. This is the place I want to be – at the bottom of the totem pole and soaking like a sponge.

Between 1988 and 1992, there were 6-8 people on the team. We built an early BI system involving text search, document image rendering and other capabilities. The data storage on the back end was large for its time, in fact argued to possibly be the largest based on Sun and Arix multi-processor UNIX servers. We also built and supported a OCR pipeline to convert data from paper to digital which was fully staffed and operated 7×24. Given the sensitive nature of the work, data conversion had to be 99% correct – no small feat in 1988. Our search system was a stateless client/server where we wrote software for four platforms – Windows, Sun and NeXT – and the System V server. We created our own build environment, our own deployment and delivery system. We specified, designed and ran 3 hardware/network/storage environments: development, OCR pipeline, and the operational analytic environment which included a data center. 20+ scientists with PhD’s worked with our software. Coding was some times done side by side with the users. We lived with our users and the consequences of our errors. Making critical recommendations based on data analysis and correlation with our system, the scientists didn’t appreciate errors as it sullied their reputations. We wrote all the data handling software, drivers for optical jukeboxes, the test harnesses for the API’s as well as extensive data validation software. The online operational system was monitored by software we wrote which checked the status of all operational points and provided up-to-date reports.

Our team had a boss. Good guy. We never got an assignment. The team knew what it had to do. We divvied up the work amongst us and went at it. We spent hours pairing up on subjects. Acceptance tests were often written before we ever designed any code, simply so we focused on the target functionality. Never was a core design implemented without someone else looking at it. Not because we had meetings constantly scheduled, but because that was how work was done. There were never meeting ceremonies, which seem so prevalent today in IT Land. Team meetings occurred frequently and informally and were short and sweet. With a group of people all within 20 seconds of each other, communication was fluid and constant, yet not distracting. You knew when people were knee deep (because you knew what was going on). UNIX chat was used by some of us to exchange information while working together from different locations. If someone had to be out of town for a week, one or two people would know the absent person’s code well enough to continue progress and solve problems, albeit not at the same rate of the primary developer.

We loved Post-It’s. Work product was described on them and moved from door to door on the hallway as we worked on items. We dropped software into production every month or two. We wrote designs in e-mails and 1-2 page documents, work snippets on Post-It’s and documented anything necessary from as-built software. Acceptance Test Plans were written in advance – that is, we determined with our customers what core tests the system had to pass before we designed it.

When we had to hire, it was on consensus. If everyone didn’t agree, the candidate didn’t see an offer. We hired the right people as best we could, and as a team dealt with the consequence of being short and carrying the load until Ms. Right came along. The team was responsible for decisions as a team and accountable to one another as a team. We never fired anyone – we didn’t need to. If someone didn’t pull their weight, team members would help them out. If they didn’t come up to speed it was not a comfortable place to be. Not pulling one’s weight and being accountable to a whole group of people, versus just one boss, was an untenable social situation to sustain.

That characterizes my first four years building and running systems. I never knew there was any other kind of work – where one didn’t interact with customers, or build software at their side, spec the hardware, build it, fix it, run it, write test code. The word “done” meant it was in production solving the customer’s problem. My time coding between 1988 and 1998 was always like that. I didn’t know work could be done any other way. It’s only in the latter half of my career that I’ve been to other environments and come to see the more hierarchical (command and control) team models.

So when people talk about Scrum and Agile practices such as Self Organizing Teams, Pair Programming, Test Driven Development, User Stories and say that early agile process folks formalized pre-existing practices and gave them names, lots of people don’t understand what that statement really means. Hopefully the above description gets specific enough to give a sense of what “agile” was like in 1988.

His entrepreneurial spirit and creativity combined with his other traits make him the competent “wearer of many hats” that many organizations so badly need.

Filippo is a seasoned, thoughtful professional with deep experience both in business and technology. He successfully operates both at the senior, strategic levels of the business and with the troops at ground level and knows what it takes to build successful organizations.

Filippo is a game changer whose work in recruiting and organizational development is most impressive.

His wide range of skills (be it technical, interpersonal, managerial, etc.) enable him to relate in successful manner with everyone. As a result, Filippo’s insights and decision making process most often result in a positive outcome.

• (n.) Opt-in instant messaging spam.
• (v.) To make oft inconsequential chatter.

The buzz around singing praises, like Ed Yourdon, who made me aware of Alex de Carvalho’s vid.

Now before you shoot this messenger and characterize me as a Luddite (okay I could be a stick in the mud, given I’m about to celebrate the 15th anniversary of my 28th birthday), I am one of the more connected people I know. I started and run a company with several online communities, I participate in numerous other online communities, have four active e-mail accounts, an iPhone with unlimited calling. I have a Facebook account. And LinkedIn. And SMS. And Forums. And Mailing Lists. Accounts with Yahoo, AOL IM, MSN Messaging. Is that enough? I forgot to mention, I also have accounts in MySpace. Plaxo. Oh and how could I forget this blog or my twitter account?

So I was glad to find that I’m in good company, as a recent study at Harvard seems to expose the much ado about nothing hype. In a recent memory, the buzz around twitter is akin to when Orkut first came out. Arguably Orkut had more meat around the bone, support from Google and enough media buzz to require a battery of flyswatters to beat back the blogosphere hype. But at the end of the day Orkut didn’t go global but headed to Brazil. As Tom Lehrer would say, Orkut is now in the “Where are they now?” files. Nonetheless, Social Junkies greater than I seem to embrace all social networking fads and put them to work.

While twitter could be a Flash in the Online Community Pan, it could stick just … because. Yet what does it provide that is really so earth shattering? Solving which big pain? Like many people, I’ve signed up to find that signal to noise ratio is deafeningly slanted toward white noise. At Google IO we watched presenters answer questions from audience members who stood up as well as those that put tweets up on the wall (a screen in the room). Huh? For crying out loud, just stand up and ask the question.

As a friend would say, “this is the answer to a question no one ever asked.” For all the fascination, even by visualization statisticians, no one is putting meat on these bones. It doesn’t stop people from trying to rationalize value, even to CIO’s as Abbie Lundberg has weakly demonstrated by writing an article in CIO magazine touting twitter’s value in such a murky way as to leave its readers wondering why the article was even written. Until I see someone present a cogent explanation of the need which twitter is filling or can fill, how its sound bytes and pub/sub model suits that need, I remain firmly in the “It’s hype” camp. Who knows, maybe Google will buy them just to own the Noise-o-Sphere.

As for Iranians being able to twitter during the shutdown of Internet services and web sites in Iran, the media has somehow portrayed that twitter uniquely enabled this capability for outbound communication from Iran to the rest of the world. That’s simply bunk. Had twitter not existed, there are hundreds of other ways to post information to the Internet, not to mention rapid indexing by Google which makes up-to-date information discover possible. Best of all, one could communicate with more than 140 characters, which is like trying to sip steak through a straw.

In that regard, coincidence is often used to note the perceived unlikeliness of a relationship. From the root word coincide (co meaning “together” and incidere meaning “to fall upon”), two very different meanings derive in practice, the use of coincidence being somewhat idiomatic:
     Coincident: the fact of sameness.
     Coincidence: the chance of sameness.

Coincidences – that is, where things coincide – are often outliers, where opportunity often lies. To be successful in the stock market is to determine causal factors and act on them: maybe the desirability of a certain product in the market place coinciding with a superlative company product offering, or a macroeconomic shift having an undesirable impact on a certain industry. What is coincident to one person may be coincidence to another.

Let’s take a closer look at the area of overlap. In the diagram below, coincident relationships are shown toward the center of the overlapping dimensions. In other words, those are the obvious relationships as their overlap is deep and evident. Coincidence is toward the outer boundary of overlap, where correlation is less obvious. To this point I’ve noted that we often use coincidence in the vernacular of chance. In this diagram, I don’t mean to say that all correlations have causal relationship, but rather as we move away from the center there are less evident yet invaluable relationships between dimensions.

A second form of coincidence lies in a new relationship which was not originally thought to be related. In this case someone discovers a new contributing factor influencing an outcome or behavior. Whereas in the first case of seeing coincidence in the periphery of relationship, discovering new relationships requires out-of-the-box thinking and observation.
In both of these cases, coincidence is often described in the realm of “sixth sense” – we can’t easily put it in words, but our senses, memory and thinking processes make connections which we perceive. While I wouldn’t suggest acting on every intuition, being in tune with these feelings and pursuing them is worthwhile. The current master of coincidence certainly must be Malcolm Gladwell. In his recent book, Outliers, he tells us of an Italian community of Roseto in Pennsylvania which defied classic medical and scientific expectations. Heart disease was non-existent in the community. In spite of research in diet, work stress and other medical factors, nothing seem out of the ordinary. I won’t provide the reason (in case you’ve not read the book), but Gladwell provides story after story of coincidence.

In the workplace, the ability to see coincident relationships has a profound impact on one’s ability to communicate and act effectively. This blog is about the coincidences I observe, act on and articulate when working with others. Mind you, not in the vernacular of chance but rather in the deeper principle relationships that can be all too easy to overlook. Many of these are a sixth sense for me. In writing them here over time, I hope to mute the voices a bit and hopefully provide some insights which may prove valuable to you.

Oh and for the questions set out at the onset, we’ll get to those in the coming entries.

He deals the cards to find the answer
The sacred geometry of chance
The hidden law of probable outcome
The numbers lead a dance

Sting – Shape of My Heart, “Ten Summoner’s Tales”