Archive for the ‘Leadership’ Category

The power of tribes (The Economist)

Friday, February 3rd, 2012

In this artcile, The Economist argues that

Businesspeople need to reckon with the Anglosphere, the Sinosphere and the Indosphere.

The article goes a little further and says that

Reading a contract is useful, but you also need to be able to read people

The arguments here echo a bit some of the thoughts expressed in an earlier post of mine, in turn inspired by a discussion on comfort zones (read that post for more on that topic). I guess that’s how it goes. I found it insightful, read the full article on The Economist here: The power of tribes.

Tags: ,
Posted in Innovation, Leadership | 1 Comment »

Comfort zones and prejudices motivate people, not just with VCs in Silicon Valley

Sunday, October 30th, 2011

I read a well articulated blog posting by Hank Williams, in which he was arguing that comfort rather than racism may be motivating some of the industry movers in Silicon Valley. I think such observation is more general than he may have put it. I would argue that the sense of comfort (or discomfort) motivates most of the decisions people routinely make, and this all around the world.

As I could make out, Hank’s posting was a part of the debate on diversity raging on Twitter and the blogosphere. While I don’t pretend to understand the sensitivities around this topic in the US, I think such phenomena can be observed everywhere and this may have always been the case with human beings. This topic would fill volumes, I won’t even try.

I liked how Hank made clear that people should avoid victimisation and focus on what they can do to help themselves, and that is a really nice one that may be worth elaborating on. I have learned that if you feel and act like a victim, whatever the circumstances, then you are defeated before the battle even begin. Such attitude would seldom be exhibited by very good hackers, or geeks.

Indeed one of the traits of good hackers is that they don’t give up easily, they would look for solutions until they can find something that works. If that attitude is smartly applied to entrepreneurial endeavours, then the person has a chance to succeed. The myth of overnight success has long been debunked, just look up the history of any successful person. Some people may be looking for cheap/easy money, or just not trying hard enough to leverage their own strengths and merits, that would also be a way of victimising oneself.

Diversity is a big subject in many parts of the world, and rightly so because otherwise the human society doesn’t move forward. When the subject is cheaply tossed into every debate then that dilutes its importance and turns it into a gossip making object. Those who feel like they are on the wrong side of the diversity should stay focused. And these may be other take aways from Hank’s posting, though I don’t know if he intended it that way.

If you are into this sort of topic, Hank’s post is well worth reading.

Posted in Entrepreneurship, Leadership, Society | Comments Off

Thank you Steve Jobs

Thursday, October 6th, 2011

This man was a true genius, one of a kind. Merci Steve.

Posted in Leadership | Comments Off

How do you fill Steve Jobs’ shoes?

Saturday, August 27th, 2011

If I were Tim Cook, I would try the following:

  • Try to be Tim Cook as much as possible
  • Don’t try to fill Steve Jobs’ shoes, instead try to “stand on Steve’s shoulders”
  • Don’t try to fight for recognition because that would be a trap, I can only become a better Tim Cook
  • Don’t pay much attention to the hype, just get on with the job
Steve has done a good job at Succession Planning at Apple. The onus is now on Tim Cook to capitalise on this, and that task may be made hard by any form of obsession with past achievements.

Posted in Leadership | Comments Off

OSX Lion experience suggests that a single unified iOS is the next version

Sunday, July 24th, 2011

My experience with the upgrade and running OSX Lion is very positive so far. It feels stable, confident and trustworthy. The only surprise was that Java runtime wasn’t available right after the reboot. I had to google for a link to a separate download, I feel that was a little obnoxious of them. Other than that, I have a stable and fast OS. Since I removed Flash plugin, upgraded Skype, and now only rely on Google Chrome for flash functionality, I have a very good setup indeed. The fact that my esoteric collection of software runs so far without a glitch, without me having to tweak anything, suggests that OSX Lion builds on a solid and a stable API, most probably enabled by Snow Leopard.

It’s hard to imagine Apple maintaining OSX Desktop line and iOS in parallel, I reckon only iOS will ship in the future and the device where you run it will determine its runtime persona: mobile, desktop, server. For companies that cannot port their products to the new unified model, OSX Lion would become their Rosetta.

I’ve read a post on Windows 8 which indicated that Microsoft is already moving in that direction, a single unified OS for all platforms.

The implications of this change in the industry, lead by Apple, is that the AppStore model will become prevalent. When we reach that point, organisations with large IT teams dedicated to platform support will start looking derelict. Those would still remain the largest number, but they may find it really hard to remain competitive.

Why is it that Apple is seemingly succeeding with a vision that once was actually Microsoft’s pioneering idea: one platform for all your computing needs? They surely didn’t have more money or available potential talent than Microsoft.

Looking a little further, adding Facebook and Google to this mix, the battle for control of the consumer mindshare and purse (indirectly corporate mindshare and purse) is truly exciting. I think most of the mainstream press would have us believe in a zero sum game, which I think is just the same game really: seeking control of the mindshare. Analysing the full spectrum of all the tech titan battle grounds is beyond this posting. I’m only looking at the front where Apple is causing a storm in at the moment.

With all this going on, I have hard time engaging in debates about the definition of things like architecture, enterprise, business, any combination of those. I’m not sure what problem such debates will solve, especially when denial is ingrained in many contributions. I think the only viable debate to be had is the one about “the future of computing“, and that gets my attention.

Posted in Computing, Innovation, Leadership | Comments Off

Why is it so hard to give Apple a little more credit for the iPad?

Thursday, June 30th, 2011

I’ve quickly skimmed through the latest wave of tablet review here, and a nice review round-up here. The single common trait to many of the reviews I’ve seen is that “Despite some nice features on the device…, H-P and other tablet makers have yet to introduce something that compares to Apple’s tablet.” (MarketWatch quoting Mozberg).

To me, perhaps the pundits should give more credit to Apple, as their achievement seemed to have left just about every one else in the dusts. Repeating myself, a strategy that bases itself on “me too” is often going to stutter if not simply fail. Maybe there’s just too much of that going on, more so than say acknowledge how hard it can be to deliver a solid tablet (mobile?) experience.

On an entirely different register, I can’t wait to see the reviews on Google+. It’s all nearly too predictable.

Posted in Innovation, IT Industry, Leadership | 3 Comments »

Microsoft Lync and Skype

Wednesday, May 11th, 2011

The news that Microsoft bought Skype made me wonder: what is happening with Lync (formerly OCS)? Is it going the Zune way? Is this a tacit admission that Lync would never have succeeded?

Tags: , ,
Posted in Innovation, Leadership | Comments Off

Information Systems Architects should write solid code. Part 1, Why?

Thursday, April 1st, 2010

I believe that, in Information Systems environments, an architect should be first and foremost a very good programmer. The architect should write code on occasions, it would be better if writing code is actually a habit. When this is the case, the Architect is able to bring a positive influence to the organisation. When this is not the case, the Architect would most probably be less efficient and will find himself/herself regularly stuck in unproductive discussions. Unfortunately, a non-negligible amount of inefficiencies stem from the Architect’s lack of awareness of the application platforms and code and the engineering activities surrounding them.

This can be proven ab absurdo, but I will provide a simple case to illustrate the point.

In this and subsequent postings, I plan a multi-part posting, I will be using the term Architect to refer to anyone who has responsibility in capturing user requirements and translating them into instructions for programmers. This broad definition includes business analysts and application designers. Though infrastructure architects and designers play a key role in shaping up the IT environment, I will classify them as programmers in this discussion because they are often at the receiving end of something specified by someone else.

Those who have needs and ask for something to be done with the IS/IT systems are users.
Those who translate user needs into work instructions are architects.
Those who actually execute the tasks of creating or modifying IS/IT systems are programmers.
The expression write solid code designate the act of creating an artefact that can be unambiguously understood as machine code, when used in a modelling context these are formal model artefacts, when used in a programming context these are program source code.

I know there might be a million other definitions out there. I think, at this point, someone could take offence and quit reading. That would be too bad. I am not interested in definitions and titles, I want to make a point and I need these specific working definitions. They work fine in this context, take my word for it.

Let’s give a simple persona to our IS/IT Architect,  Kermit. Kermit is a man in his mid-thirties, he works for a company called Trotters Fresh Dairy Products  Ltd (known as Trotters).

Say that Kermit does not write code, whatever the reason. This means that Kermit is not familiar with coding issues because he doesn’t deal with them regularly (so Kermit actually knows a programming language? good for him, but he is not involved in coding at Trotters and that that’s the point here). Kermit only talks in concepts, not related to code.

Kermit communicates his concepts to the programmers Robert and Marie-Louise using diagrams and explanatory notes. Kermit also communicates with business stakeholders using diagrams and explanatory notes.

As software is written, there will inevitably be mismatches between the application release(s) and user expectations – malfunctions are particular kinds of mismatches, changes in user expectation are also forms of mismatches. Resolving any such issues involves representatives of users, programmers and architects. At the very least, Trotters IS/IT will be facing a number of challenges due to the combined effect of the following factors:

  • Kermit made his architecture decisions based on his extensive knowledge of widely used architecture frameworks and standards, papers from industry analysts and discussions in architecture communities, his own perception of what the business is about and what matters most to Trotters business and organisation
  • Kermit’s architecture was interpreted by the business according to their knowledge, their perception of IT and software (often shaped by external influences and people background), and their evolving needs
  • Kermit’s architecture was interpreted by the programmers according to their knowledge, the platform and programming tools they are using and the resources that were available to do the work.
  • Coding was constrained by a number of factors including technology platform, programming tools, resource availability, Robert and Marie-Louise are not aware of everything that might be possible with the tools in their possession. Some of Kermit’s suggested principles were not feasible due to these constraints, choices had to be made on-the-fly.
  • Changes constantly occur in Trotters’ business environment, with them people adjust their perceptions and their expectations, it is very hard to convey all those changes in a usable and timely manner to all stakeholders. So people make assumptions that they feel comfortable with and won’t necessarily validate such assumptions.
  • Business is always pressed for time, competition is fierce in Trotters’ industry, financial constraints are ever present, decision makers are dealing with compromises all the time

Arguably there is more to say about the factors that influence complexity in the organisation, the above seem sufficient to make the point here. Let’s analyse the impact of Kermit’s lack of awareness of the code:

  • Industry architecture best practices, analyst white papers, none of this make sense until they are cast into the reality of a specific organisation. This cannot be done efficiently without intimate knowledge of the platform and the way the application is being (or supposed to be) coded. With Kermit, Trotters organisation will be learning this reality casting process the hard way
  • Even if perfectly drafted, the architecture can quickly become stale because the business reality would have moved after Kermit issued his blueprints but before the applications could be fully built and released.
  • Kermit couldn’t coach Robert and Marie-Louise efficiently, because he wasn’t involved in the coding. Even if Kermit would work closely with the programmers, since Kermit can’t write solid code, then a significant amount of the programmers’ time would go into educating Kermit on coding issues and practices
  • The numerous micro-decisions made during the software construction contribute to a non-negligible change in the initial promises of the architecture, such changes will not surface until an application release is available to the users.
  • Kermit misses the chance of bringing any lessons learned back into his architecture vision, because the feedback loop is not present or is poorly executed. Conversely, Kermit has little or no way to ensure, thus guarantee, that his vision is actually been executed upon. If the vision wasn’t correct, that fact is not properly reflected everywhere. If the vision was correct but was poorly executed, there was nothing to prevent that from happening
  • Vendor platforms evolve, so any knowledge built on a particular set of vendor solutions is likely to become obsolete and require refreshing before it is put to use after a certain amount of time. This constant knowledge renewal typically doesn’t happen, sometimes because it cannot be afforded, but also partly because people tend to get stuck in their routines and fail to notice that their knowledge is becoming obsolete. There is nothing in place to validate that knowledge at Trotters’ is adequate and aligned between the architecture practice and the programming practice
  • Kermit probably know some technology platforms very well, but there is no telling that he knows the particular platform that is part of the solution at Trotters, or perhaps the platform has evolved since the last time that Kermit did any hands-on work on it.
  • Kermit cannot assess the experience of Robert and Marie-Louise on the platform either. Conversely, Robert and Marie-Louise have no effective way to find out about each other’s strengths and ensure they are complementary. Trotters’ organisation has to trust that things would work out somehow
  • Sometimes people do notice that their knowledge might no longer be sufficient, some could then become defensive and would fight to keep any blind-spots from the open. This is human, it can be fought but it should mostly be managed. Users, architects and programmers at Trotters are facing the same dilemmas, they might not even be aware that this could be motivating some of their actions.

We can go on and on about the factors that could be causing mismatches between user expectation and application releases, but the above is sufficient to derive a pattern and draw some preliminary conclusions.

When there is any significant distance between the architects and the actual solution building and delivery, inefficiency tends to creep in very quickly and organisations don’t get the most of their assets. It does not help when those who specify what needs to be done and outline how it should be done, are removed from the actual construction of the solution. When the architect has no idea what code was (or is being) written, he could be talking about concepts that only exist on his slides and documents but actually never materialised. What would be the point of that? The above is the rationale behind my statement that An IT Architect should write solid code.

In next settlements I will elaborate on how an architect could be writing solid code, increase his effectiveness in the organisation and ensure that his vision of the solution is as close as possible to the actual solution. I will call this Say it in Code.

PS:

I am an IS/IT Architect, I could be subject to the same shortcomings described above. This is one of the lessons that I have learned over time. I’ve always felt this to be an issue in my job, I try to minimise any gaps between the vision and the realisation that was made of it by staying close to the code.

Posted in Architecture, Leadership, Programming, Uncategorized | Comments Off

Failure with Enterprise Systems: why we don’t learn, and what we can do about it

Saturday, January 9th, 2010

Tim Bray wrote a great article with the title: Doing It Wrong, in which he is sharing his insights on the perennial IT failures and how other’s manage to succeed despite ignoring the enterprise mantra. Tim made a lot of good points, the reactions to it where mostly great reading of their own. I thought my reaction warranted a blog post of my own, since otherwise it’d be a long comment lost in the jungle.

I won’t paraphrase Tim Bray here, his original posting is well worth reading: http://www.tbray.org/ongoing/When/201x/2010/01/02/Doing-It-Wrong

At this point, I must warn the reader that most of my parabolas are best understood when situated in the context of mathematical set theory, and loosely, in probabilistic terms: the chances of, and the lack thereof. Thinking in terms of sets, matrices, stochastic and probability, provide a great foundation for abstracting and considering IT complexity.

My take-away from the examples of successful web sites is that they have one great attribute: solving one problem at a time. The trick is that, as they solve one problem, they learn and discover new unanticipated solutions and they can leverage that immediately in the resolution of the next problem. The result is that these endeavours end up achieving success in lots of areas that they never imagined when they started, that is the second great attribute. There are certainly more great attributes, and no doubt plenty of shortcomings, but I live in “glass half full” land.

Examples?: Google started with search, Facebook was about college students, Twitter wanted people to catch up (in their breaks) on what their friends where doing. On a micro level, the examples are innumerable and would make this posting longer than necessary.

In my view, the attitude of, solving one problem at a time, is applied to all aspects of the endeavour, not just technical.

The combined effect of the solving one problem at a time attitude, and the two great attributes cited earlier, embody the following tacit admissions:

  1. nobody is perfect,
  2. an organisation, just like a person, will never be perfect,
  3. it is wasteful to attempt to control everything from the get go, change occurs at a faster pace than our inventory and learning process
  4. we know what we want, but we never know where the events might lead to.

This type of discovery and progressive enhancement is not witnessed in enterprise systems environments, simply because it’s being preempted by stubborn short-sightedness and often times by analysis-paralysis.

With enterprise systems we insist in having a complete oversight before building things, but without knowing it we keep missing important pieces all the way and all the time, from start to finish.

There’s a paradox here: in the frantic attempt to achieve complete and total oversight, we become short-sighted and fail to notice numerous key signals. The signals take an inordinate amount of forms and they are well grounded in the context: business context, organisational complexity (human nature, entrenched interests, etc), technical complexity (how we fail to design and code what we are really thinking/imagining, how we fail to grasp the technology for what it really is), our span of control, our span of attention, the target solution lifespan, the limits of collective wisdom, etc, the list is endless. In my interpretation, a huge array of overlooked problems stem from human organisation shortcomings, by far the most insidious and  difficult to master: things like feeling, fear and uncertainty about one’s position or career, attention deficit, unexposed incompetence and mediocrity in the ranks, etc.

If we learned anything about architecture, we should know that it’s impossible to make an exhaustive list of every single factor that could become a part of the problem or the solution. If we can’t identify all potential problems and potential solutions, how can we possibly build something that caters for everything (which is what Enterprise System is supposed to be, a system that addresses all)?

We might be able to make a very good list at the start, things change as we list them. Say we overcome that hurdle, we usually don’t have sufficient control over everything in that list to be successful. If we manage to get sufficiently extensive control, there is still the hurdle of exerting such immense control for the length of time that it takes to build everything that is necessary. Say that miracles exist and that we manage to cross that last hurdle also successfully, then unless every stakeholder (internal and external) could be robotically piloted to perfection some things will go amiss.

At this point you might think I’m exaggerating the challenges, I probably am for many cases for sure. But if I were to underplay the hurdles, that also would not be the honest true because any one of the cited area of challenge can take a life of its own unbeknownst to or beyond the control of IT management. When such devastating change occurs, we enter another phase: denial for the sake of our own survival (the lies that cover the mother of all lies). That is a key aspect I want to point out. Christopher Alexander‘s seminal books provide a good background on the complexity of getting designs right (design in an extremely wide sense of the term).

There’s one more paradox: we are all quick to admit that “nobody is perfect”, we also know that an organisation is also a “body” and is a reflection of the humans that comprise it, yet we still think that we can build a “perfect organisation” (be it a project, an IT, a business, a program, a solution, or whatever structure or impersonation we give to our organisations).

The short-sightedness with Enterprise Systems is the result of insufficiently applying learnings, which is unfortunate since we really have plenty of opportunity to learn. Take any industry or knowledge domain that we love to paraphrase in our enterprise system endeavors, they all learn and apply knowledge incrementally. We’re the only ones, the IT industry, who think that we can learn everything and apply it all in one go. Our mistakes start to accrue in the problem and solution scope inventory phase: a lot of unaccounted for biases are introduced as we seek to segregate the invariants from the variable elements of the enterprise systems. From there we just keep compounding blind spots, until someone eventually pulls the plugs or that the project collapse under the sheer weight of the endeavour.

If we can’t get control over everything that matters before building successful enterprise systems, should we give up trying and forego all central control?

I’m not suggesting that we forego control and planning, that would imply that I know the magical answer, which I don’t and won’t ever claim to. I too, like many in my profession, am in my quest for the nirvana and I’m under no illusion that it exist or is achievable. And that last point is a suggested take-away: keep dreaming and reaching for the nirvana, but be aware that you might never achieve it.

At the beginning of this post, I cited one behaviour and two attributes, as expressing my take-away from what makes some web sites successful. With this I will be first to admit my own limitations: I am interpreting things with my own background and influences, someone else could have other equally plausible biases. The reader is entitled to his/her own bias. The important message is that we should learn to read signals and adjust our actions accordingly, achieving total control is rarely feasible or even desirable.

The odd saying goes like this: ” a fool with a tool is still a fool”. I’d fancy a positive version of it, glass half full type, like this: “a smart with a tool is a super smart”. In my experience, aptitude should be matched with an equal measure of attitude, they’re both in limited supply and should be consumed with moderation. Whenever the combination lacks of balance, failure looms. There’s a lot of preaching the good message, there’s far fewer demonstrable examples of doing it successfully. The range of tools and methods are wildly varied and have evolved tremendously over time. What’s remained virtually constant is the involvement of human organisations. Success still remains by and large elusive. Anyone claiming to have all the answers is definitely deluding. Awareness is the starting point, then actively doing something with the learning is the only essential positive ingredient.

I’d appreciate any learning from you, if you care to share.

Tags:
Posted in Architecture, IT Industry, Leadership | 1 Comment »

Doing Things Half Right for Better Results, a little story.

Monday, November 23rd, 2009

In this post, I intend to share a learning point drawn from my personal experience, as you might recall if you’ve been following my tweets. I would appreciate any comments you might have. If you would share your own experience, that would be wonderful. I have reopened the blog for comments, the threat of spams having been largely contained by recent WordPress updates.

For a start, I should clarify what the title means: this discussion is really about intentionally half-baking solutions with the purpose of encouraging people to take ownership. It is about leaving room for someone else to blossom. To give another analogy, my local supermarket sells half-baked bread, when put in the over at home you get a deliciously fresh bread that gives you the illusion that you made it yourself. This post is not about doing a bad job, it is not about hiding behind excuses or avoiding getting one’s your job properly. This is about a good leadership practice when success depends on people taking onwership of parts or parcel of an initiative or a project. I hope this clears any potential misunderstandings.

Now, I would like to give you a taste for my personal experience, trying my best to keep it anonymous and neutral. I’ve boiled it down to one example, to keep the text focused and prevent any direct link with specific events and people.

In the early days of my carrier, I had the impression that I needed to have anwers to any technical question that came my way. I couldn’t help it. I would feverishly research and prototype technical solutions, work long hours to find answers that I could show to my colleagues (I still research as thoroughly as I can, but I’ve just learned to work better on the communication side of the equation). I thought that was the only sure way to gain respect and recognition amongst my peers, my reportees and my managers alike. I thought it could be damaging to my career if I failed to demonstrate knowledge and proficiency in technical matters This attitude served me well whenever I was directly responsible for designing or programming a solution, I could just show off my abilities quite easily.

At some stage though, as I got more and more project responsibilities, I was often annoyed to see that I sometimes failed to get sufficient support for my ideas even though I had checked everything and thought I had good answers. This was even more puzzling and frustrating when, in a leadership position, i would get the impression that people were simply ignoring me or refusing to see the light. Worse!, I had the impression that some managers were prepared to steal my ideas but seldom prepared to empower me, oh the outrage such feelings gave me!

Then one day, something happened that taught me a lesson: someone (higher up in the pecking order than me), rephrased and presented several ideas of mine, in my presence, without giving me credit (I had presented him my ideas and he rejected them). I was boiling during the whole presentation, but somehow I managed to stay calm and showed no emotions throughout. At the end of it I simply left the room and made no comments to anyone about the subject. The presentation was well received, the person in question did not dwell on it. I was so upset that I had the worse of thoughts for this person and didn’t wish to have anything to do with him again, if I could help it. A couple of weeks later though, as I ran into this person at the coffee machine he simply congratulated me on my contribution and left. It was clear that he knew how I felt, I took it as an indirect apology, but didn’t make much of it as I had moved on. The episode made me ponder a bit however, I realised that I would rather be associated with a success story than staunchly defend some bragging rights. This accidental epiphany would serve me again and again later on, as I stepped into leadership roles and I often worked with bright people. I tried to remember my story and control my instinct for bragging about, something that is generally against nature for technically inclined folks.

I had spotted a learning pattern that I have been trying to nurture ever since: to successfully collaborate with people, particularly in a leadership position, it is good to try and show humility and give others some room to grow. Nobody wants a superman-like figure around, especially when he (or she) is the boss. Appearing to have all the answers (or a lot of it) can easily breed resistance and cause projects to fail, if only because other people could be overshadowed and would have no motivation to take any ownership.

Despite what one might think, it is always beneficial to hear other people’s perspectives on issues. When I got humbled the way I did, it also made me realise that I had always thought people have a lot more potential than they give themselves (or are given) credit for. In my urge to try and grow, I was often loosing sight of my own belief and surely would not be able to lead had I continued on that path. I had learned to change in an accidental shock therapy.

If you manage technically savvy people, one of the things you learn is that unless you gain their respect you can’t effectively lead people. To gain their respect, you often have to have demonstrable superior technical ability. In any case, you have to allow them to express themselves as freely as possible, you have to pay more attention to egos as people take pride in what they do. The matter becomes more complicated if you are a consultant and that you are trying to demonstrate your abilities to your client stakeholder groups, conflicts can easily arise with the technical recipients of your work. When the recipients don’t buy your solution, it won’t add any value and your endeavour kind easily end up in failure.

The lessons I’ve learned:

  • Do not be afraid to see some of your ideas “getting stolen”, at the end of the day it is better to be part of a success than otherwise
  • Even if, as a leader, you can bring about all the answers that are needed, doing that would be a show of poor leadership and a demonstration of a lack of delegation skill
  • In a technical leadership position, it helps to be comfortable in giving others some space to grow. This doesn’t threaten a leader’s position, on the contrary the leader gains more respect from others, others would more easily take ownership

Credit & disclaimer:

This blog post was inspired by an article I read on HBR by Peter Bregman, under the title Why Doing Things Half Right Gives You the Best Results, http://bit.ly/31DI. I wouldn’t be telling this story, had I not read this article.

I tried to keep this discussion as general as possible. Should the reader recognise any event or people or any particular situation in this text, that would be entirely fortuitous and a simple demonstration that nothing is really unique under this sun: it’s all been done before, I’m just one guy talking about something that happens regularly everywhere. So there should be no surprise there.

Tags: ,
Posted in Leadership | Comments Off