Feb 06, 2020
I have been reading some articles on digital transformation and change management and I am surprised about how little attention is given to the notion of comfort. The reason why change is hard is that it makes people feel uncomfortable. And when people are not comfortable, their confidence, morale, and productivity suffers.
At the very least, there is the loss of familiarity. Habituated routines that once hummed along on the edge of our consciousness all of the sudden require direct attention. Tasks take longer to do. Mistakes are made. The confidence of mastery can feel threatened.
There is always a group of people who benefited from the old way of doing things even if that way was inefficient or dysfunctional. Dysfunction can create jobs or mask poor performance so don't assume that everyone is onboard to eradicate it.
There is great advice for assessing change readiness and rolling out change. But be aware that the resistance that you feel is a primal tendency to seek and preserve comfort. In addition to your conventional change management best practices, focus your attention on people whose comfort will be the most impacted. These will be people who have developed mastery over specialized skills and knowledge or have accumulated power from the current dynamics. Think about what benefits would be the most motivating for those groups to buy in. If you don't have their support, you can count on their interference.
And remember to measure the impact of a change after people have had a chance to re-equilibrate and form new comfortable habits.
Nov 17, 2017
It is fairly typical for a consultant or new leader to walk into an organization and see nothing but silos. These leaders regard silos as a barrier to efficiency and make them a target for change. What they often wind up doing is replacing organically formed structures with new ones that look better on powerpoint than in practice.
Why does this happen? Let's start by digging into what a silo is. "Silo" is usually used as a derogatory term to describe a grouping that you don't like. But groupings are important in large organizations because the number of possible point to point connections makes communication too noisy and prioritization too difficult. If everyone is talking to everyone all the time, nothing gets done. Teams naturally form to confront this challenge. Complementary capabilities are assembled and scaled in highly focused work groups. Process is continuously refined because of a tight feedback loop.
To the outsider, trying to navigate these structures is confusing and frustrating. People seem unaware of what is happening outside of their group. They appear oblivious rather than focused. The reactionary impulse is to criticize the duplication of what appear to be identical functions. The ego feels good when you think you see obvious dysfunction that nobody else recognizes. It certainly feels better than having to slog through complexity that everyone else understands.
But there is great risk in introducing sweeping plans to achieve synergy before really understanding how these teams function. Even if the reasoning is valid, it is incredibly disruptive to blow up any working system and make it re-form under stress and uncertainty.
Before eliminating "silos," you need to understand why they formed. Were they imposed from the top down in order to make the organization easier to understand from the top? Or did these structures develop naturally to solve operational problems related to coordination and focus? Can the same benefits be achieved more efficiently?
You can't fix a working system until you fully understand why it is the way it is. You need to understand what is working right now and what obstacles stood in the way from the system naturally adapting to solve its broken parts. When you hypothesize dysfunction, you need to introduce your corrections scientifically and measure the results. But most importantly, you need to find the best parts and figure out a way to expand on them.
Oct 23, 2017
As a long time remote worker and manager of both distributed and co-located teams, I think about virtual teams a lot. While I have had great personal experiences with remote teams, there seems to be little consensus about whether it is a good idea. You have some articles touting the health, retention, and productivity benefits of letting people work from home. And you have other articles, like the recent Atlantic piece "When working from home doesn't work," that indicate a shift back to traditional office environments. Based on my own experience, I find it hard to imagine large companies succeeding by dictating enterprise-wide policies around remote workers. The effectiveness of distributed teams depend on critical factors that will vary from team to team. Here are three things that undermine the effectiveness of distributed teams.
1. Hybrid teams do not work
A team should be either all colocated or all remote. A remote member of a predominantly colocated team will always be neglected. It is unavoidable. Co-located employees build habits that depend on seeing each other. They look around the room to decide who to include in a discussion. They respond to visual clues that a colleague may be struggling. The interactions that are available to remote team members tend to be restricted to events that are either boring (like standing meetings) or stressful (like performance reviews). But relationships are formed in between these two extremes when people can be themselves and have the space to curious about each other and build trust.
2. You can't convert a colocated team to a distributed one
A team is not just a collection of people. It is an ecosystem that is shaped by individual talent, chemistry, goals, and an environment that presents constraints and opportunities. The environment plays a huge role in how people interact. And by interact, I don't just mean communication (although that is part of it) but also how responsibilities are divided and handoffs happen. If all of the sudden people start working remotely, you need to treat the group as a new team. You need to establish new norms and ways of working together. Roles will change. You need to use different methods to develop camaraderie and create an engaging work experience.
3. Not everyone will thrive as a remote worker
It takes a special type of person to be an effective and happy remote worker. Their work environment has to be conducive to productivity. They need to be goal oriented and invested in the success of the team. They should be committed to their craft and want to build mastery by continuous refinement. I have also recently begun to appreciate the importance of being in the right phase of one's career. At some point in your career, it is helpful to go into an office to do things like: build professional social skills; find a mentor; bond with people; try different roles; get lots of feedback; and have the general sensation that you work for a company. It is harder for remote workers to advance into new roles because they don't get to see other people doing those roles. Personally, I am grateful that I got to work at a number of different kinds of offices and I have some great professional connections from that time. I think I would be a wreck if my early managers had to deliver feedback over phone and email without being able to modulate tone and provide support based on my reaction.
Based on these three observations, a smart executive will not dictate working style based on business journal articles or office leases. Instead, he/she should empower teams to construct and distribute/consolidate themselves for optimal efficiency.
Mar 18, 2013
Over the past year, I have had the opportunity to work with some excellent technical freelancers. These relationships have been both professionally and personally rewarding. However, I also understand that for every one freelancer success story, there are many disasters. In fact, as a consultant, I have made a living out of cleaning up freelancer messes. Here are five tips to help you be more successful with your freelancers.
Don't use a freelancer to bring in a skill that you don't' already have in your organization
If you hire a freelancer to do work that your team doesn't understand, you are setting yourself up for trouble. First, you will have no way to evaluate his/her level of skill and the quality of work he/she produces. Second, you will not be able to maintain the code or systems that the freelancer builds when the project is done and she moves onto other projects.
Use a publicly hosted distributed source control system (DVCS)
Host your project on an externally hosted Git or Mercurial repository. This will allow you to try out freelancers with minimal risk. They can fork your repository and take on some development tasks and you can review their work before merging it into your own repository. If a new freelancer doesn't work out, just disable access.
Cast the net wide and filter
The only way to really get a sense of skill and compatibility is to start working with someone. People who look great on paper and can talk a good game are not always as competent as they appear. It is also easy to dismiss diamonds in the rough. Some of my favorite freelancers were very shy when I started working with them and would have been easy to overlook. With a DVCS and the ability to review work, you can assign development tasks to several developers and see who rises to the top. Just be sure to assign meaningful work and pay freelancers for their time.
Respect, trust, and communication are all critical to any relationship (personal and professional). Even though your working relationship with them may be shorter, treat freelancers with the same respect that you would give to a full time colleague. If the freelancer comes from another country, you have a great opportunity to learn a little about his/her culture and make a friend in a far away place. From my work with freelancers, I have seen a side of international current events that I would never see on CNN or the BBC. When you have these strong bonds, you get better commitment, better product, and a more enjoyable working environment.
Learn comfort zones
Everyone has their strengths and weaknesses. In a new working relationship, it is natural for anyone to underplay their weaknesses. Who starts a job interview by listing all the things that they stink at? The only way to understand someone's strengths and weaknesses is to assign a variety of tasks and see what comes back. Usually, people will start with the work that they feel most comfortable doing. Once you have recognized a few strengths and built a level of mutual trust, you can have more candid conversations about comfort zones. Some people like to focus on work they have the greatest confidence in doing. Others like the challenge of learning new things. The greater understanding you have about personality and comfort zones, the better you will be able to assign work and also evaluate work product. For example, if one particular developer likes to stay inside his comfort zone, you should just assign tasks within that skill area and you can be confident that the work will be done well. If a developer likes to learn new things, you can assign him challenging problems but you better have more rigorous quality controls.
I honestly feel like this is the future way of working. Through strategic and effective use of freelancers, you can make your organization more nimble and responsive. Companies that are not able to use freelancers will be slow to start new initiatives or avoid doing them altogether. On a personal level, you can learn so much by working with a diverse set of freelancers with different experience and styles. It is also nice to build new friendships — it's even more fun than having a pen pal.
Jul 21, 2009
Even in this down economy, finding technical talent can be extremely difficult. Résumés are worthless. It comes down to this: programming is a craft but we don't get to see the craftsmanship and creative process when we hire programmers. At least not before we narrow down the application pool of thousands to a short list of real candidates. After that, during the interview process we can do things like logic questions and programming exercises to see how the programmers solve problems.
The issue of finding talent is a very real concern not just for start-ups but also for established organizations that are selecting technology (like a CMS) that they must staff up to support. The natural tendency is to go by the numbers. Choose a technology with a "household name" like Java, .Net, or PHP where programmers are a dime a dozen. You are bound to find a needle in a haystack that big. Where this logic breaks down is that when a technology is so widely known and used, everyone seems to have it on their résumé. You can't tell if the candidate just spewed out a few hundred lines of crappy code or if they have immersed themselves in the technology to the point where they understand the core principles and philosophy. You can't tell if they are a talented craftsman and are able to learn new things. By selecting a household name (commodity) technology you have just made the haystack bigger without necessarily adding more needles. It is hard to find a Jamie Oliver by putting out a search for people who can make a hamburger.
When it comes right down to it, a language is just syntax that lets you do things like assign variables, create conditionals (if statements), and loop through lists. Learning what is available in libraries is the true learning curve when it comes to a technology and those libraries are constantly changing. So a good programmer is always learning. One of my favorite books about programming (The Pragmatic Programmer: From Journeyman to Master
) recommends learning a new language every year to expose yourself to different approaches. The best programmers love the challenge of learning a new language or framework. They read books on different technologies and practices. If I was hiring a PHP developer, I may get an even better result if I found a great Java developer who is open to working in PHP. Of course, then I would have to find a great Java developer. If I was looking for a great Java developer, I could see myself looking for people who have worked in Python, Ruby, Groovy, or even Scala. That would show that they are committed to learning new things rather than churning out code the same old way.
When you look at it this way, the relative size of the "talent pool" should not drive you to a technology choice. You want to choose a technology that has proven itself to be more than a fad so that it will continue to evolve and mature. You want to work with a language that has good resources for learning (like articles, books, IRC, and mailing lists). But you don't want a technology just because a majority of technologists claim to know it. Most importantly, you want a good programmer. If a technology is sound and effective, a good programmer will be able to learn it and be productive with it.
Apr 28, 2009
I often tell my clients that every website needs a "product manager." This is the person who ensures that the website is meeting the needs of the customers (the audience). A product manager understands the customer and prioritizes the enhancements of the technical platform as well as the production and maintenance of the content. The product manager may not have deep technical experience in software architecture, information architecture, writing, or graphic design but needs to bring these disciplines together to create a product that is useful.
I have recently come across two very good articles on product management. The first is Program Manager by Joel Spolsky. He calls the role a "program manager" and narrowly focuses on the discipline of software development. His program manager leads a small team of developers to build an application (or a subset of a large application) by writing a functional specification that defines the product's vision and behavior. The article nicely describes how the product manager communicates with and manages a technical staff.
The second article is Internal CMS Product Management by David Hobbs. In his article, David focuses on the web content management system as the product and the users of that system as the customers. This role is particularly visible during the initial CMS implementation but is important throughout the system's lifetime to keep it relevant and useful. Requirements always change — not just when the business changes but also when it learns and learning is inevitable with a disruption like a new CMS that may streamline processes and create opportunities. People change too and they may need different training and/or encouragement as their responsibilities change. Too many content management systems fail from post deployment neglect. Always budget for continuing maintenance and enhancement of the system. Practicing the advice in Hobbs's article will help you avoid those pitfalls.
But, as I mentioned earlier, I think that the real product is the web site itself — not the content management system. A great CMS is worthless with bad content. We manage content because it is (or should be) valuable to an audience. A CMS doesn't make good content, people make good content. The best a CMS can do is eliminate some of the barriers that prevent users from making good content. There are plenty of other barriers that the CMS can't eliminate: no time, no interest, no incentives, no skills, etc. The product manager needs to address these as well.
I don't think that I am asking too much for a product manager to guide the technology and help content producers create good, well organized content. Wikis are a good example to look to. Wikis that continue to be successful after their novelty wears off usually have an evangelist that is constantly tracking content updates and giving feedback to authors (Is this page redundant? Does the title make sense? Is the information still accurate? Is it findable?). When you really think about it, this is the role of an editor in a media and publishing company. Maybe all companies that manage content (even for internal purposes) should think of themselves as publishers and have editors that push their contributors to produce a worthy product.
Mar 09, 2009
You have probably heard people talking about "dotted lines" in organizational charts. That is when someone has partial accountability to someone other than his direct manager. An org chart notation that I would really like to see is a "flashing red" line. I would use it to show when someone reports to a manager who has no clue what he does.
Any reader of Dilbert knows that this happens all over organizations but the case that I am the most keenly aware of is when a technologist reports to a non-technologist (or, perhaps worse, a former technologist). As a consultant, this is the area where I am regularly deployed. I am often hired by the non-technical manager to help him validate and/or understand what his technical staff are doing. I am also often hired by the technical staff to validate and explain their strategy. Consultants get put into this position because this is an area where companies struggle on their own. They need an outsider to facilitate and verify because communication and trust is so compromised. While I do love this work and would be happy to perform this role at your organization, here is some free advice to get you started so you can make some progress on your own.
Communicating to a non-technologist
Your manager doesn't really understand what you do despite your best attempts to explain it. You suspect that he doesn't care. Maybe he doesn't want to understand. Maybe he can't help that his brain just locks up when you say words like "refactor." You don't feel appreciated. You are about to stop trying.
When talking to your non-technical manager, don't try to dumb down what you say but for every detail mention, make a very clear connection to something that matters to the business. That usually means cost (short term and long term), quality, and impact. By impact, I mean things that will benefit the business: time savings, competitive advantage, etc. Provide inputs for any financial analysis he wants to do.
Don't get bogged down in numbers. Instead, draw comparisons because the units are probably meaningless. At the end of the day, the non-technical manager wants to be reassured that progress is being made and nobody is making "unconventional" technology decisions. An example of the former, is saying that you are "doubling storage" rather than "adding a 500GB RAID 5 storage array." For the latter, say "companies like EBay use MySQL" rather than "MySQL is a fully ACID compliant database."
More important than anything you say is how you listen. Listen to his concerns. Figure out what kind of proof will alleviate these concerns and provide it. Prototyping is a great way to show a technology in terms that a non-technical person can relate to - much better than UML.
Communicating to a technologist
Admit it. You are a little afraid of your tech guy. He has strange working habits and speaks in a language that you only barely understand. Even though you manage him, you have very little visibility over what he does. Unlike with other people who report to you, your advice to him is pretty much worthless because you both know that you have no idea what you are talking about. Whenever you ask a question, the answer just confuses you more. You just stop asking. The scariest thing you can think of is that your tech person leaves and, after drifting helplessly for weeks, you learn that your entire infrastructure is in chaos and about to collapse. What is going on in this technical empire he has built under your nose?
If you don't know anything about technology, you should start learning. Unless you are retiring in the next couple of months, you can only expect technology to become a more important part of the business that you are supposed to run. Have your technology guy help educate you. Ask him about the technical details underneath what you see as a user. But don't just listen to your internal technology people, listen to what is happening outside of your organization. Talk to your peers at other companies and learn about what they are doing. Read stuff online. Hire a good consultant. Share what you are learning with your technical staff in a non-confrontational way. Don't go in with managerial bravado. You are the student - be humble. It is a warning sign if they get defensive when you show a genuine interest.
The best approach for making technology decisions is to describe what you need in very clear terms (your technical person will call that requirements gathering). I like usage scenarios as a way to communicate these things. Ask your technical staff to put together their best solution and schedule time to review its viability and sustainability. Have an open dialog about the implications. Meet regularly with the team - not just at the end to "sign-off."
More important than anything you say is how you listen. Treat the interaction not as manager but as a partner and teammate. You both have the same goals. When the technical discussion gets out of your depth, don't shut down! Instead, connect it to something that you do understand and that matters to your responsibilities. Share the insight that you have about the company's needs and what your boss will ask for.
Nov 26, 2007
There has been an enormous amount of writing and discussion about building a business case for a CMS and I don't have much to add other than to say that most of what I have heard is totally wrong ;)
The conventional approach to the problem is to focus on process and efficiency. There is usually some spreadsheet that promises time savings from better tools for editing and accessing content. The estimates are usually wild guesses that have been adjusted to make a particular point. The uncomfortable reality is that most companies are under-investing manpower in managing content. You can't save money by saving labor that you are not applying in the first place. A slightly more reasonable approach (especially in the advertising based industries such as media and publishing) is around the volume of content: more content means more indexed pages that may translate into more search engine traffic that leads to more page impressions and potential for ad click-through. If your content stinks, the equation doesn't work.
In my opinion, the business case discussion should be around the content itself - not the technology used to manage it. This is a difficult conversation to have for a number of reasons. First of all, the human effort required to manage content (no matter what tools you have), while very costly, does not have a big spending event that triggers an ROI conversation. The expenditures from managing content (or the cost of not managing it) happens in drips and drops but it can really bleed a company. Secondly, there is a misperception that all content is good and worth managing. CIO's like to say that "disk is cheap" but it really isn't. The cost of disk drives continually declines but the operational cost of managing the information is actually going up. I don't have any hard data to back this up but I think it is obvious. For every byte on a disk, you need to back it up, you need to organize it, and you need to scroll past it when looking for something else. Most importantly, you need to find it and combine it with other bytes to make actionable information; otherwise, that byte is worthless - less than the cost of saving it no matter how cheap the cost of the disk drive is.
Estimating the value of content is hard and frequently complicated by sentimental or otherwise irrational feelings. A person's content is typically more often more valuable to him than it is to others. Not just because he was interested in the topic but also because he feels the need to justify the effort that he invested in creating the content (or paid someone else to do it). There is also a timing aspect. The value of some information goes up over time, while other information goes down. For example, there was a time when the most important piece of content for me was the master's thesis that I was writing. Now, I don't even know if it still exists in paper or digital format. Two years later in the corporate world, I was submitting a purchase request for $8,000 to recover the data off of a 3.5 inch floppy disk that was sitting in some ooze at the bottom of someone's desk drawer. It may have had an old financial report that was needed for a taking the company public. I will never know because the $8,000 recovery attempt failed.
At cmf2007, Bob Boiko's keynote talked about how we are not yet in the information economy because we have a hard time determining the value of content and the markets for trading information are primitive. Content managers are put into the subservient role of having to post everything that they are given. I would tend to agree with him. I do not feel like companies are any better at deciding what content to keep than the parent of a prolific three year old artist. In fact, I feel like the parent has the edge because he has a finite amount of refrigerator door space.
The next time you are looking at a new CMS because you are drowning in content but starving for information, ask yourself "is this CMS just a bigger refrigerator door?" "If i just dump my content into another CMS am I really solving the problem?" " Do I really understand the problem?" Those questions are hard to answer without understanding what content you have, what it is worth, and how could be made to be worth more. Here are some questions that I like to ask.
- How often are these assets requested?
- How often are they revised?
- What is the value of the business processes that this content enables?
- What is the cost of the content being wrong? This may have to do with brand image, misinformation, etc.
- What would you pay to recover this content if you thought it was lost?
- How much would another company (maybe a competitor) pay for this information? Not saying that you would sell it, but if you were selling it.
You start asking these questions and all of the sudden, content starts looking like the most important asset in your company. It probably is... either that or the people. Just like with people, you can get more out of content by retaining and investing in the right content (and either improving or letting go of worthless content), creating better processes, and providing an environment (or repository) where the content is more productive (accessible). I have never heard of a company trying to calculate the ROI of moving from one office to another. Most companies accept that they need good office space that does not interfere with people doing their jobs. Physical office space is considered a cost of doing business that has very real but complex and difficult to estimate value. It is never considered a substitute for good people or good processes. I wonder if a CMS should be valued in the same way. A CMS will not solve your content management problems but it will make your life more pleasant while you are doing the work. A little like a nice office.