Archive for the ‘Communication’ Category
Rob Koplowitz of Forrester recently posted, Why Tibbr Matters. He provided some examples of where an activity stream across a network like Tibbr could add value, and some examples where it couldn’t. I responded with a comment and I wanted to elaborate on my comments here.
Activity streams tied to your company that are available through tools like Chatter, Yammer, and Tibbr have potential for adding value, but there’s some big barriers that must be overcome. In my experience, I’ve used email, Sharepoint and other other internal portals, and Yammer inside of a corporate setting, and there’s two simple objectives that these tools should have, at a minimum:
- Moving information from the privileged few to a broader audience.
- Making new information available that previously wasn’t.
On the first item, a challenge that probably every organization has is getting the information to the right people. The information exists, but it only spreads through word of mouth or to people that the information holders think need to be aware of it. The twitter model is the right approach for addressing this, by allowing people to follow people or topics of interest (either via saved keyword searches or hashtags), rather than having to wait until it is explicitly sent to them. In order for this model to work, however, all information must be public. As soon as private, directed messages come into play, that information is now hidden. I don’t see this as the bigger of the two challenges, however, as at least the information exists, it’s just not getting everywhere it needs to go.
The second item is the greater challenge. If there is information that simply isn’t being communicated, there is no tool that is going to magically make that information appear. The more information sources you have participating in the network, the greater potential you have for getting value out of that network. Why does everyone join Facebook? It’s the network with the greatest participation, and therefore, the greatest potential value. There’s a catch-22 here, because you want participants to get value quickly, so they stay in the network, but once you get over the hurdle, the growth will come. So how do we do this?
In a corporate setting, the participants are not just your employees. The participants must include your systems. This is why Tibbr is potentially in a good spot. Tibco’s background is not in collaboration or social media, it is in system integration. Unfortunately, all of the web-based request/response systems over the past decade have gotten us away from the asynchronous, event-based system design of the past. Even SOA tends to imply a request-response paradigm in most people minds, meaning I have to know what to ask for in advance. Both our systems and our people need to expose items of interest without any preconceived notion of who might be interested. Yes, we need to be cautious about signal to noise ratio, but I don’t think that problem is any different than trying to manage redundancy in an application or service portfolio. As part of your deployment process, get a list of the events/messages that are available, categorize them, and manage them effectively. If the Twitterverse can quickly come up with accepted hashtags, why can’t we do the same inside our corporate worlds?
Since I’ve previously asked for this year to be the year of the event, let’s do so in a way that allows these events to feed into our internal activity streams and social networking tools, and start getting real value out of these technologies.
I read this report from GigaOM and it got me thinking about the challenges of trying to create a successful Facebook-like environment in the enterprise.
Challenge #1: Smaller community. Facebook has over 400 million active users. Your company will have thousands. You can assume that only a portion of those will be active contributors, and that within that smaller group, those people will be split into smaller communities of interest. This leads to a trickle of information flow, which isn’t going to keep people coming back. Even within Facebook, I wonder how many users are just playing games, versus having interactions with friends. The Facebook statistics page does not provide this information. This is important because…
Challenge #2: Enterprise apps do not exist as part of the social platform, and there will be a long migration for existing companies before that changes. If anything, the trend today is to put social networking features into the app, rather than building the app within a social networking platform. That’s not a surprise, as what platform would you choose?
Challenge #3: The browser dominates the deployment model. I try not to generalize my personal preferences, but if I am going to interact with something on a regular basis, it needs real estate on my desktop. That’s why I use Seesmic Desktop for Twitter/Facebook messaging. It’s always open. A browser takes up too much real estate, so eventually that page is out of sight, and out of mind. I think a push model is the only way to go to be successful.
Challenge #4: The enterprise does not have a culture of sharing. I don’t know the root cause of this, but in general, I have found that most enterprises only share information when it is required to get a task done. Rather than seeking out interested parties, information owners sit back and wait for information seekers to come to them. This results in a lot of wasted time and effort in finding out those information owners. In general, I think there are way too many barriers that prevent information sharing, whether due to corporate culture, legal and regulatory environments, internal politics, or many other reasons.
So what do we do? You’ll have to read my next post where I will try to ofer some suggestions for addressing each of these.
A challenge for virtually any position with “Enterprise” in the title, but especially so with Enterprise Architecture, is to continually show that they are adding value to the organization. Why? Because typically enterprise architects are not directly associated with delivery. In most IT organizations, things get delivered through projects, and enterprise architects don’t typically play the role of project architect. At best, there is an indirect association with delivery.
First off, the organization must understand that there is a need in the organization for non-project activities. It’s funny how there’s plenty of positions outside of IT that have indirect relationships to business delivery, so it’s still a bit surprising that there is still resistance toward Enterprise Architecture in many organizations. This post isn’t about how to convince management of the need for Enterprise Architecture, though. It’s about the two paths that you can go once you have that management support.
The first path is all about enforcement. Someone in senior management is upset about the decisions that are being made on projects, and as a result, they put a police force in place to review project activities. That police force is Enterprise Architecture. A personal pet peeve of mine is when the police force is put in place, but the laws are not. When that happens, project teams are at the mercy of the individual that is reviewing the project and whatever their personal interests are. Those personal interests may have nothing to do with what senior management wants, or what the project team is tasked to do. If you’re going to put a police force in place, you first need to have laws. Anyway, the point of this is that a police force approach can result in a lot of animosity. On the plus side, Enterprise Architecture does get visibility into all projects with the power to influence their direction. Also, sometime it is necessary to put a police force with a very big stick in place to force some change on an organization, but it does so at the expense of corporate culture and can result in a lot of ill will.
How do you avoid this? By remembering that as an enterprise architect, your role is not to audit, but to assist. Everything you do should be done with the thinking that your are helping to deliver, helping people to make good decisions, and helping to make their job easier, not more difficult. If you take this approach, you may still have to review projects, but your focus should be much more on communication, education, and evangelism. If you are setting standards, you should be communicating the standards, the justification for them, and the expected results to see when they are followed. If those results aren’t achieved, you should be working with the teams to understand why and get them back on the right path. Another pet peeve of mine is when someone says, “No, you can’t do that” but fails to follow up with instructions on what the right way is.
In short, if you are in a role that is normally not assigned to project teams, you must remember that you are still part of the delivery team, and everything you do should contribute to the successful delivery of a solution that meets the goals of the project and the goals of the business. It’s about being helpful, not a hinderance.
All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.
A succession of tweets between Forrester’s Gene Leganza and Clay Richardson along with Brenda Michelson of Elemental Links caught my attention this morning. At Forrester’s Enterprise Architecture Forum next week, Clay will be reviewing a few case studies for Social BPM. It’s too bad that I won’t be there, because this sounds very interesting.
I haven’t seen any definitions yet of what socially-enabled BPM is, so I thought I’d throw together my own thoughts. First off, let’s take two dominant social technology platforms, Facebook and Twitter. I’ve previously posted that an internal Facebook for the enterprise could be revolutionary for inter-company communication. I’ve also previously posted on the role of Twitter as an information bus. So, now combine the human-facing communication of either platform’s news/event stream, the application platform of Facebook, and toss in some process modeling, orchestration, and universal task management capabilities on top of it, and I do think you have socially-enabled BPM. What could be most compelling is if there’s a way to combine the communication features of the social technology platform for “ad hoc” processes with the more formally modeled and managed processes that are the strong suite of BPM platforms to get a better view (and hopefully better management) of the processes in the enterprise as a whole.
I look forward to hearing what others think about the case studies Clay will be presenting. This is definitely an emerging area where there are opportunities to lead the back and be revolutionary.
Update: Here’s two posts from Clay on the subject that he forwarded to me. It looks like my thinking is consistent with what he had previously written on the subject. The first is titled “Social Technologies Will Drive The Next Wave Of BPM Suites” and the second is titled “BPM Promises ‘Simplicity’ In 2010. Is This ‘Hope We Can Believe In’ Or Still A Pipe Dream?”.
All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.
I participated on a panel discussion on communication and enterprise architecture, hosted by Bob Rhubart of Oracle. Part one is now posted on Oracle’s Technology Network, with parts 2 and 3 to follow soon.
Back in March of this year, I asked “Is Twitter the cloud bus?” While we haven’t quite gone there yet, Tibco has run with the idea of Twitter as an enterprise messaging bus and announced Tibbr. This is a positive step toward the enterprise figuring out how to leverage social computing technologies in the enterprise. While I think Tibco is on the right track with this, my pragmatist nature also sees that there’s a long way to go before these technologies achieve mainstream adoption.
The biggest challenge is creating the robust information pool. Today, the biggest complaint of newcomers to Twitter is finding information of value. It’s like walking into the largest social gathering you’ve ever seen and not knowing anyone. You can walk around and see if you overhear someone discussing something interesting, but that can be a daunting task. Luckily, however, there are millions of topics being discussed at any given time, so with the help of a search engine or some trusted parties, you can easily begin to build the network. In the enterprise, it’s not quite so easy.
When looking at information sharing, here are two key questions to consider:
- Are new people receiving information that they would not otherwise have seen, and are they contributing back to the conversation?
- Are the conversation groups the same, but the information content improved in either its relevance, timeliness, quality, preservation, or robustness?
If the answer to both of those is “no”, then all you’ve done is create a new channel for an existing audience containing information that was already being shared between them. Your goals must be to enable one or more of the following:
- Getting existing information to/from new parties
- Getting new information to/from existing parties
- Delivering more robust/higher quality information to/from existing parties
- Delivering information in a more timely/appropriate manner to existing parties
- Making information more accessible (e.g. search friendly)
The challenge in achieving these goals via social networking tools begins with information sources. If you are an organization with 10,000 employees, only a small percentage of those employees will be early adopters. Strictly for illustrative purposes, let’s use IT department size as a reasonable guess to the number of early adopters. In reality, a lot of people IT will jump on it, as will a smaller percentage of employees outside of IT. A large IT department for a 10,000 person company would be 5%, so we’re looking at 500 people participating on the social network. Can you see the challenge? Are these 500 people merely going to extend the conversations they’re having with the same old people, or is the content going to meet the above goals?
Now comes along Tibbr, but does the inclusion of applications as sources of information improve anything? If anything, the way we’ve approached application architecture is even worse than dealing with people! Applications typically only share information when explicitly required by some other application. How many applications in your enterprise routinely post general events, without concern for who may be listening for them? Putting Tibbr or any other message bus in place is only going to be as valuable as the information that’s placed on the bus and most applications have been designed to keep information within its boundaries unless required.
So, to be successful, there’s really one key thing that has to happen:
Both people and applications must move from a “share when asked” mentality to a “share by default” mentality.
When I began this blog, I wasn’t directing the conversation at anyone in particular. Rather, I made the information available to anyone who may find it valuable. That’s the mentality we need in our organizations and the architecture we need in our applications. Events and messages can direct people to the appropriate gateway, with either direct access to the information, or instructions on how to obtain it if security is a concern. Today, all of that information is obscured at a minimum, and more likely locked down. Change your thinking and your architecture, and the stage is set for getting value from tools like Tibbr.
This is another blog on the subject of a service-based view of Enterprise Architecture. Previous posts focused on the actual service definitions (here and here) and a general view on communications, this one focuses on the actual management of those services, specifically on the notion of reporting.
In my experience, as teams try to transition to a service-based view, a key challenge is in moving from an inwardly-focused view to an outwardly-focused view. In other words, shifting to a focus on the customer. An easy way to encourage this shift is to think about your communication to the customer. If you think of examples of great service, it goes beyond the communication associated with service execution. As a simple example, think about your credit card. There are credit cards that simply allow you to make your purchases and then send you a bill. Some cards, however, send you a report every year that gives you information on how you’ve used your credit allowing you to make better financial plans. So, how can we take this same approach to the EA (or any other) service offerings?
The simple part of this is to make a commitment to communication with your customers. At a minimum, think about reporting to your direct customers and their management. In all likelihood, you’ll need to add two additional audiences to this. First, is senior management over EA. Depending on where EA sits in the organization, this could be senior IT leadership or it could be senior enterprise leadership. Second, is the group most people are used to dealing with, and that’s internal management of EA. The more complicated part of this is figuring out what to report and how frequently to report it. I hope to cover this in more detail in a future post, but for now, think about how you can add additional value to the relationship. Rather than simply reporting status of engagements, provide additional value through an analysis of activities, added information from EA research services, or some transparency into the activities occurring within Enterprise Architecture.
This seems to be the topic of the week with excellent posts on the subject from both Leo de Sousa and Serge Thorn. This has been on my to-do list since a meeting with Bruce Robertson where we discussed both my thinking on EA Services and Gartner’s, which also resulted in a blog post from Bruce. In that conversation, Bruce convinced me that communication should be a top level EA service, rather than an implied activity within all other EA services, as was my previous stance. This was also challenged by Aleks Buterman in our discussions on Twitter.
Bruce’s stance was that communications was essential to everything that EA does. If your EA team can’t communicate effectively, then their chances of success are greatly diminished. By defining it as a top level EA service, it emphasizes its importance for not just the EA team, but everyone who utilizes the EA services.
Given that assumption, what does the communication service look like? I think Leo gave a great start at a communication plan. In reality, the EA communication service shouldn’t be very different than any other communication service, the only difference is the subject being communicated. Therefore, let’s learn from practices of the communications experts. Leo relied on a communication plan created by a colleague that is used for many things, not just enterprise architecture. I’m trying a simliar approach, initially based on a template from ganthead.com, but has now been customized quite a bit. In the plan we capture a number of items. You’ll see there are many similarities to what Leo had to say, plus some additional items I think are important. The plan is a simple Excel spreadsheet, with each row representing a unique “audience.” These audiences do not have to be a mutually exclusive, in fact, it’s quite common to have one row targeted at a broad audience, and then other rows targeted at more narrow subgroups. For each audience, the following things are captured:
- Questions to answer / Information to present: In a nutshell, what are we trying to communicate to the audience? What are the two or three key items to present?
- Sensitivies: This one isn’t on Leo’s, but I think it’s very important. What are the biases and background that the audience has that may positively or negatively impact the effectiveness of the communication? For example, if your organization has tried the same initiative 5 different times, and you’re proposing the sixth, you should know that you’re walking into a room full of doubters.
- Mechanism: How will the communication be delived? This can involve multiple mechanisms including presentations, podcasts, webinars, blogs, whitepapers, etc.
- Objective: What is the objective of the communication for the audience? This is different than the information to present, this instead is the expected behavior you expect to see if the communication is successful. Obviously, the communication alone may not achieve the objective, but it should represent a big step in that direction.
- Author(s): Who will create the communications collateral?
- Presenter(s): Who will present the information?
- Delivery date(s): When will the communication be delivered, and if it’s an on-going process, at what frequency? If there are mutliple delivery dates, when will the last delivery occur?
- Evaluation Method: How will we evaluate the effectiveness of the communication? There may be multiple evaluations.
- Follow-up date: When will follow-up occur with the audience to gauge effectiveness and retention?
This may seem like a lot of formality, but I’ve seen the benefits of it first hand, and the risks associated with ad hoc communication efforts. My experiences with ad hoc have been hit or miss, but when the time was taken to develop a formal plan, the efforts have always been successful. I hope this helps you in your efforts.
James McGovern, in one of his parting blogs (only time will tell if that’s really the case or not), asked some questions of me. Here’s his comment:
Todd Biske: I can count the number of peer enterprise architects from Fortune enterprises who are credible bloggers on one hand and I must say that your blog is the gold standard in this regard. Could you make your next blog entry on the topic of why you blog but more importantly provide a sense of why in a way that will encourage some of our other industry peers to come out of hiding? Please also share what other topics are of interest to you besides SOA? Curious to know if you have drunk the Kool-aid on $$$$ ECM technologies that really should cost $ or whether you have ever attended an OWASP meeting, etc?
First, thanks for the compliment. While we definitely have different styles, the fact that your blog exists is a continual incentive for me to continue to do so, as it is a sign that there are practicing EA’s who are also willing to share publicly. Furthermore, your efforts in calling attention to other bloggers through your blogs popularity helped a number of other corporate IT bloggers to build an audience which is critical for keeping the information flowing.
The reason I blog has always been very simple- sharing information. I have a hard time believing that there aren’t other people who are thinking about the exact same problems that I am. There are plenty of paid services that can provide access to “the network,” whether its buying a vendor’s product, paid analysis, consultants, etc. I have no problems with them trying to make a business out of it, but I also think there’s no reason why we shouldn’t be sharing information with our fellow peers for free. While there will always be work that must remain private for competitive reasons, how much of what we do every day really falls into that category? Does my recent post on EA services reveal anything private about my employer? No. Can the comments and discussion in public Internet forums help make those definitions better? Absolutely, and many organizations are already doing this, only through closed, paid networks. These networks provide great information, but you have to pay to join the club. So, that’s a long way of saying that I prefer to be an example of public sharing, and allow people to learn from my experiences in the hope that they’ll share some of their own. It’s been far more giving than receiving, but I’m 100% okay with that.
To your other questions… other topics of interest to me: anything of strategic nature with regards to the use of IT. I’m a big picture thinker, and always have been interested in the application of technology rather than the technology per se. I did a lot of work in usability in my early days for just this reason. I’m also very interested in the human aspects of things, taking a social psychology angle (just heard that term on a podcast and really liked it). Outside of that, the rest of my time revolves around faith and family in one way or another. On ECM technologies, I haven’t had to do a ton of work in this space, but I do know I haven’t drunk any Kool-aid. I’m fortunate to do some work for my kids’ school which has to leverage IT on a shoestring, so I’m able to keep an eye on some less expensive tools, including ECM recently. On OWASP, I have not attended a meeting, but have spoken with a colleague at work who wants to get a St. Louis group established. I will put him in touch with you to get some advice on getting the group going.
James, I hope you continue share your wisdom, and I’m sure you will, even if it’s not through the blogosphere anymore. Thanks for your part in making my blog better and building my audience.
I just read the Forrester document, “Inquiry Spotlight: Building An EA Practice, Q2 2009,” written by Gene Leganza and Katie Smillie, with Alex Cullen and Matt Czarnecki, and there’s one line that really stuck out for me.
When creating EA artifacts, you should focus on “building what sells” more than on “selling what you build.”
I think I should take that line and make a poster out of it. This consumer-first thinking is really, really important. I’ve seen too many things that were written for the convenience of the author rather than the consumer, and it never is as successful as it should be. This applies to EA artifacts, to user interfaces, to services, and just about anything else that’s supposed to be consumed by someone other than the person who wrote it. If you don’t make it easy to consume by the intended audience, they won’t consume it at the rate you desire. The trap that you can also fall into is to fail to recognize that you have more than one audience. If you assume a single, broad audience, then you wind up with a least common denominator approach that frequently provides too little to be useful to anyone. While some “100-level” communication is a good thing, it must be followed up with the “200-level” and “300-level” communication that is targeted at particular audiences and particular roles. For example, if you’re planning your communication around an enterprise SOA strategy, you may create some 100-level communication that is broad enough to wet the appetite of project managers, organizational managers, and developers, but not enough to tell any of them how it will impact them in detail. Follow that up with pointed conversations targeted specifically at the role of the project manager, the organizational manager, and the developer to get the messages across to them, and them only.
Finally, getting back to EA artifacts, consider not just the roles, but also the context in which the artifacts will be used. If the artifacts are used in project activities, then structuring them so the appropriate information is provided in the appropriate phase of the project is a good thing. Organizing the artifact to where people must hunt all over for the information they need at a particular point in time is not a good thing.
Once again, take Gene and Katie’s words to heart: Focus on building what sells more than selling what you build.
Presenter: Scott Bittler, Gartner
Another presentation from Scott, this time over breakfast. The bulk of this talk was focused on the importance of what he termed as “Next State Architecture.” If we have the future state and current state architectures documented, the challenge that exists is if we can’t achieve the future state architecture in one step. If that’s the case, then there’s a gap in the prescriptive guidance needed for project teams. If they know they can’t get to the future state, and don’t have guidance on how they should move from current state, they’re likely to stick with what they know. Good advice.
There were some specific nuggets outside of this core topic that I also wanted to call out. First, he said that the most important EA deliverable is principles, because it’s those principles that lead to consistent decision making. The talk wasn’t focused on this, so he didn’t go into depth, but some examples of these principles would be good. I definitely see the importance in these and agree with his statement. I’ve been in many situations with two (or more) compelling options where we seem to be at a stalemate. The principles need to assist in getting decisions made.
Second, I liked the fact that he said that EA’s role is to provide prescriptive guidance so that appropriate choices are made on projects and programs. This emphasizes the point that I was hoping would be made in his governance talk yesterday. Provide the policies, and anyone can make the right decisions.
Finally, the last comment he made was that with the advent of EA-focused web sites, etc., any team that claims ignorance when confronted with non-compliance (“I didn’t know I was supposed to do that”) is unacceptable in this day. Here, I disagree. I make extensive use of RSS feeds in my work so that I get information pushed to me, but I know many of my colleagues do not. A web site is still a pull-model, and there’s very few people that I know of that have the discipline to regularly check common web sites. EA has to be accountable for the communication effort and ensuring that it gets pushed out to the people who need it. Putting it on a web site isn’t enough. So, this one I disagree with. I think if EA is serious about achieving compliance, then they should be serious about pushing the information out. Create a formal communication plan and execute it.
In this session, Bernadette Rasmussen, Chief Enterprise Architect at Health Care Service Corporation, gave a case study discussing their efforts to establish a future-state architecture. The highlight of this session for me was the fact that a deliverable of their future state architecture was a formal communication plan, and then the actual communication activities articulated in that plan. This included large presentations for lots of people, DVDs containing an overview, development of on-line training, formal communication to senior IT leadership (who in turn had them communicate it senior leadership outside of IT), and more. I’ve had the opportunity to work on one enterprise-level effort with someone who was passionate about communication and had us develop a similar plan, and I think it was a huge contributor to the success of the effort. Developing the artifacts is one thing, but if people don’t know they exist, they won’t get used.
Jeremiah Owyang, Senior Analyst at Forrester Research on Social Computing, has a very interesting post titled, “How Companies Respond to the Risks of Personal Brands.” As a corporate practitioner with a public blog and a decent enough following to claim a “personal brand,” I thought I’d share my thoughts on this topic.
Jeremiah stated that his personal brand helped him get his current job, and that was the case for me as well. When I originally started blogging, I was a corporate practitioner, however, I did my best to keep those worlds separate. The blog did help me enter the world of consulting, where I knew it wouldn’t be an issue since the company’s CEO blogged, but then when I went back to the corporate world, it was very interesting having this very public view of my thoughts. Like Jeremiah, I think my blog played a key role in me getting my current position. I also hoped that I would be able to continue my public blogging and made sure I discussed this during the interview process.
Jeremiah went on to call out the potential risks to a company, however. He listed three risks:
Risk 1: The personal brand is a cost to the company: Why let employees build their own brand on the dime of the company or leveraging the brand of the employer?
Risk 2: The now popular employee is likely to get poached: Perhaps a common concern I hear is that competitors can easily identify the stars, and hire away these folks along with their market reputation and google juice.
Risk 3: Employee exits leaving a chasm to fill: In the modern workforce, we hear less of lifetime employees seeking pension than we do of job migrants, or career gypsies that move from company to company every few years. As a result, after they’ve built up trust with the market using social tools, they leave the company, and a gap is left that the brand can’t fill.
In my case, I drew some lines in the sand to make sure that risk #1 would not be an issue. I don’t blog from work or even using my work laptop if I have it at home or on the road. I will record ideas for blogs on my iPhone when I run across something in my RSS reader, but I follow those RSS feeds for work purposes. As for getting “poached,” it may be true that someone with a very public persona may get more calls from headhunters. Perhaps I don’t work my network well, but I get a lot more cold calls from headhunters due to talking at Gartner than I do from my blog. Personally, I think blogging may incrementally add a few more cold calls, but LinkedIn has made candidates so readily available, I don’t see this as a big deal. The real mitigator for this risk, however, is the fact that I’m very happy with my current position, and the culture of the company fits both what I want to do as my day job, as well as allowing me to maintain my personal brand. To me, that’s the best scenario. It’s a win for me, and it’s a win for the company. I believe that my blogging helps attract great candidates to my employer. The only reason this works is because there’s a mutual understanding and respect, and a cultural match. It would be a mismatch if a company hired me based on my blog, but then wanted me to stop all outward communication. There may be a time where public blogging isn’t that important to me, but for now it is, and finding a company that is supportive of it is the way to go.
I’ve always tried to be conservative with what I discuss. Regardless of whether you avoid mentioning your company’s name on your public blog and have disclaimers like I do, it’s still very easy to find out who my employer is. I completely understand that I am a representative of my company, regardless of whether it appears on this blog, and that people will associate me with them. If I screw up here, that can impact my employer. If I do well here, that impacts them too. Discuss this with your employer and establish some ground rules. For example, I avoid talking about vendors except in very general terms. Positive or negative comments can damage vendor relationships. In general, my view has always been to limit my topics to areas that I would be comfortable sharing at a local user group or at a conference, avoiding anything that even comes close to proprietary information or anything that could be company confidential. If you’re working for a consulting firm or a vendor, you may be a bit more free to blog, but keep in mind that you have to preserve the confidentiality of your clients. Even if you make things anonymous, someone can perceive that public posting as something similar to secretly recording a phone call but then bleeping out people’s names. If someone did that to me, I wouldn’t be happy.
So, my advice is to find a company that matches your needs but also one that you can contribute to their success. Think about how important your personal brand is to you, but also think about the importance of job security and stability. Find the right balance, get a win-win situation, and don’t assume anything. Be upfront about your desires, what you’ll do to preserve your integrity and the company’s, and establish some ground rules with your supervisor. If you do this, that personal brand can be a win for you, a win for your employer, and lead to a long and successful career.
A thought occurred to me today as I was walking into work. Why is it that the first place I go, and probably most of my coworkers, when I want to find out something is the Google search box in my browser? Why don’t I use the search box on our corporate intranet?
There’s certainly no doubt that there’s a wealth of information out there on the internet. What’s interesting is that one of the reasons I started this blog back almost 3 years ago is I thought there were things I was encountering in my research for work that others might find valuable. It was probably about 6 months after I started blogging that someone at work did a Google search on something SOA or governance related, and up popped my blog in his results. It seems rather silly that a colleague at work had to go out to the public internet to find something that I had to say.
Being an Enterprise Architect, I create my fair share of Visio diagrams, PowerPoint presentations, and Word documents. In this day and age, there’s absolutely no reason that these things can’t be put into something like SharePoint and indexed so there are available via the search box on the intranet page. Unfortunately, not everything I do at work winds up in one of those documents, so I need to apply the same principles I used in creating this blog to what I do at work, and start making some of those discussions available internally, as well. What’s nice about internal blogs is they can be put into your RSS reader right along side external feeds. That won’t happen with search, unfortunately. This is actually one situation where I think it could be useful to have a company-specific version of the major browsers that would first direct searches in the default search box to the internal engine, and then follow that up with general search results from Google or somewhere else.
I encourage all of my readers who work in enterprises to think about how they can make more of their knowledge available to their co-workers through their intranets. If you don’t have internal support for blogging, wikis, and a decent search engine, it may be time to make the investment.
I had the opportunity to attend a great presentation from Stephen Young, Founder and Senior Partner of Insight Education Systems. The talk was around the concept of micromessaging, which can be further broken down into MicroInequities and MicroAdvantages. To understand these, Stephen started with the difference between denotation and connotation. Denotation represents the words we use, while the connotation behind those words reveals the true meaning of what is being said. This can involve body language, inflection, tone of voice, and much more. As he pointed out, humans (or humanoids) have been communicating for hundreds of thousands if not millions of years. The written word has only been around for a fraction of that time. Therefore, so much more about how and what we communicate is conveyed by more than just the words. He did an exercise with us where we tried to describe what a dog does when it is happy. While most dog owners know within a fraction of a second the mood of their dog when they walk in the door, trying to convey that recognition process to someone else solely through words is incredibly difficult. In other words, our brains are very well tuned to picking up on things outside of the words in a conversation.
Getting back to the concept of micromessaging, MicroInequities are all of the very small things that we do in a conversation that have negative connotations, such as folding your arms, losing eye contact, giving a “ho-hum” response to the work of some individuals while lavishing excessive praise to others when the outcome of each was similar, etc. In contrast, MicroAdvantages are positive micromessages. The FAQ at the Insight Education Systems page does an even better job of explaining this. A very simple example of MicroInequities was the use of apologies in the workplace (and elsewhere). How often have you heard someone say, “If I offended you, I’m sorry.” Right off the bat, the use of the word “if” makes it a qualitative apology, and not a sincere one. Stephen said, “If you step on someone’s foot, do you say, ‘If that hurt, I’m sorry?’ No, we simply say, ‘I’m sorry.'” He used the example of Michael Nifong, the former attorney in the Duke lacrosse team case. His apology contained this:
To the extent that I made judgments that ultimately proved to be incorrect, I apologize to the three students that were wrongly accused. I also understand that, whenever someone has been wrongly accused, the harm caused by the accusations might not be immediately undone merely by dismissing them.
Analyzing this, we see that the apology immediately starts out with a qualifier. It then uses the terms “that ultimately proved to be incorrect” which connotes “I still think I was right.” His apology is only directed at three students, who he does not name, which excludes the impact to Duke University, the coach who lost his job, the team who lost their season, the families of the players, etc. On top of that, he didn’t even show enough respect to mention the players by name. The gist of this was that apologies should be about the impact, not the intent.
The talk went on to demonstrate the impact of our body language when listening and how it causes speakers to behave differently even when conveying the same or similar information, as well as the differences (and similarities) in different areas of the world. Already today, I have stepped back and adjusted the wording in an email I was composing as a result of this talk. I plan on putting his book on my Amazon wish list and encourage all of you to do the same, and, if you have the chance, hear him speak or bring him to your organization for a workshop.