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.
Oct 10, 2017
One of my favorite high school teachers used to say "if you want to learn about the world, read the newspaper." This is great advice because, by updating you on what is happening now, newspaper articles expose you to places, people, and histories that you can dig into more with additional research.
I feel the same way about release notes. Let's face it, people don't read product manuals cover to cover any more than they do encyclopedias. You read a reference resource when you want to learn more about something that you are already aware of. In the product world, you read the manual when you are struggling to figure out how to use a feature. But what if you don't know a feature exists? That is where release notes come in.
If you practice lean product development, your product should be constantly improving so there should be plenty of material to talk about in release notes. You should also have an engaged customer base that likes the product, wants to learn new ways to use it, and is excited to know what is coming next. Release notes are the ideal channel to educate these customers about product features and progress. So make your release notes good!
While they are not release notes in a classic sense (because they are not tied to individual releases) a good model to follow is the "What's new with Alexa" emails that Amazon Echo owners get. These emails are easy to read and have just enough information to tease the reader into trying something and learning more. They also mention older features that new users may not have heard about yet. In fact, I am convinced that some weeks those emails only contain older features. But they are still useful reminders!
The redesigned App Store for iOS 11 also has some of these qualities.
I pay a lot of attention to release notes for all of the products I manage. Here are some habits that I think make them successful.
- Write the first draft of the release notes at the start of a release cycle. That is, when the release is scoped and getting prepared for QA.
- Invite internal stakeholders (especially sales, support, and QA) to review and comment on early release notes drafts. You might learn about functional issues that were not considered during the initial design. You may also learn about how to better describe/position the feature.
- Make the release notes fun and easy to read. I find that humor are helpful in keeping the reader's attention.
- Make release notes required reading for staff. After sending out the release notes, I email managers a quiz question to ask their team.
- Keep the notes short. Focus on what the change is and the problem it solves. Talking about the "why" is critical because it helps the reader understand what the feature is used for. For more details, link to longer form knowledge base articles or product documentation.
- Include a "new to you" section that describes a pre-existing feature that is under-utilized or not widely known about.
- Copy the release notes into the Git merge commit message. This makes deployed versions stand out and searchable.
Oct 03, 2017
I honestly can't think of a better way to build products and services than the lean product development method. All of the work I have done over the last several years has followed the pattern of growing a customer base around a small simple product that evolves and matures in response to the needs of the users.
Our latest product, Lionbridge onDemand, has been a great success and yet it started out so small: we were testing whether we could build a business around a self service video translation site. We built the simplest app possible but left room for growth. We leveraged operational talent that Lionbridge already had and an entrepreneurial spirit that was not being satisfied. We tested different ways to drive customers to the site. We got just enough market response to see a path and keep moving forward. Since our first sale, we have been constantly learning, optimizing, and expanding. Now onDemand is a thriving business with a broad range of services. We translate all sorts of content (over 40 file types) into pretty much any language you can think of. We have a public API and integrations with several popular content management and commerce systems. But most importantly, we have happy customers who rely on the service.
Whenever I want to build a new product, or even add a new feature to an existing product, my plan is to start with an MVP (minimum viable product) and iterate from there. But this article, "I hate MVPs. So do your customers. Make it SLC instead" by Jason Cohen, gave me pause. SLC stands for "Simple, Lovable, and Complete" and, after reading the article, I realize that SLCs are the recipe for success in lean product development; not MVPs.
Here is the difference. An MVP is (in a pure sense) the flimsiest thing you can build to answer a question about a potential market. The emphasis is more on the "M" (minimum) than the "V" (viability) and most interpret that balance as a semi functional prototype. This kind of MVP is frustrating to customers because it doesn't solve their problem in a helpful way. It focuses on validating that the problem exists and that there is value in solving it. MVPs are selfish because they prioritize research over actual customer benefit.
If you really want to learn about customer need, and build good relationships at the same time, you should take one customer problem and solve it well. Build an SLC. I know that the line is blurry here. An MVP could be an SLC if you make lovability a requirement for viability. But often you hear bad solutions as being excused or justified as "just an MVP."
The first iteration of Lionbridge onDemand did what was needed for a successful, gratifying transaction. In particular:
- The customer could upload very large files. This is necessary because video files are big.
- The project was automatically quoted so the customer didn't have to wait.
- The customer could connect with an online sales agent through chat. This turned out to be a critical feature because we learned so much from our customers during these interactions.
- The customer could pay for the service using a credit card so he/she got the experience of a seamless, self-service transaction.
- The operations team was prepared to produce a high quality deliverable in a reasonable timeframe. The customer's need was satisfied.
While we launched the first iteration of Lionbridge onDemand quickly (less than 2 months from concept to first sale) we took the time to get those pieces right. That was a little over 4 years ago and our first customer continues to do business with us.
We are constantly adding new features to Lionbridge onDemand and every time we do, we treat it as an MVP SLC. We don't launch the feature unless it makes the user's experience a little better by solving a problem (however small) in a complete and satisfactory way.
Sep 11, 2017
Many organizations go into website localization initiatives unaware of the complexities and best practices involved. When this happens, frustration is the usual outcome. Having seen a number of localization efforts struggle, I believe that the root causes fall into the following three categories. The good news is that all of these problems can be avoided with experience and planning.
1. The website was not designed for localization
Some websites are easier to localize than others. In the worst case, it is better to start over with a new website rather than try to remediate and localize an existing site. The best time to prepare a site for localization is before it is built. You need to select a suitable CMS and
follow best practices during implementation and content development. If you didn't build the website with localization in mind, you (or your integrator) probably didn't follow these guidelines, which are usually the first corners to be cut when budgets and timelines get thin. The worst part is that you won't know how prepared you are for localization until you try it.
Don't let the integrator leave until you have successfully, published your second language. If your integrator is already gone, a quick assessment can reveal warning signs so you can get a head start on remediation.
2. No global business strategy
Multi-lingual publishing is (or should be) part of a larger strategy to extend your market into other languages and cultures. If you succeed in getting noticed by different language speakers but fail to help them get value from your products and services, you are no better off. You need to make sure your products, sales, and customer service are sufficiently prepared to serve these new customers. Otherwise your localized website becomes an expensive burden that is tempting to neglect rather than an investment that drives growth.
3. Lack of commitment
A common failing is to treat a website as a technology asset that can be neglected after launch.
Your website is not a project. If you want your site to engage with your audience, you need to stay engaged. Multilingual publishing raises the stakes by adding another dimension and cost multiplier to effective website management. If you can't justify the cost of maintaining localized sites, they will rapidly degrade into an embarrassment.
The web is littered with rotting websites. The worst examples are localized websites that have fallen into disrepair after initial translation.
Aug 26, 2016
I am writing about multilingual publishing on a new blog called "CTO Corner." This is a rich topic that many content management professionals never get exposed to. One of my hopes for this blog is to bring in experiences from others who are immersed in building and maintaining multilingual websites. Software vendor perspectives about managing multilingual content are welcome as well. If you would like to share, @message me on Twitter and we can set up an interview.
Aug 17, 2016
I never liked regularly scheduled standup meetings. They interrupt your flow. They are boring because most of what is said has nothing to do with you. When an interesting topic does come up, the standup quickly transforms into a meeting-meeting that holds uninterested parties hostage. Standups are lame.
The good news is that, thanks to tools like Slack and Hipchat, we don't need to suffer through standups anymore. For around a year, my development teams having used ChICO (Checkin/Checkout) rooms. I got the idea from this blog post by Zsolt Kocsmarszky. When team members check in, they report what they are working on, who they need to work with, and any blockers they foresee. When they check out, they report what they accomplished and their plans for the next day.
This approach has multiple advantages over the classic standup.
- It does not need to be synchronous.
People report in and read at a time that works for them. They are alerted when a new announcement is made and can check it in their next stopping point.
- It is scannable.
You can scan over information that is not relevant.
- It is self documenting.
Nobody needs to capture minutes or take notes.
- It works well for geographically dispersed teams.
Nothing is worse than a "phone standup" and, when timezones are involved, there is no good time to have them.
- It cuts across language barriers.
This may be the biggest one for us. My team's written English skills are great but the spoken word is challenging due to accents and "buffering" (when the time it takes you to decipher a word and recall it's meaning makes you fall behind). Removing that barrier has brought my teams closer together on both personal and professional levels.
Given these advantages, I am surprised when I hear about teams that still do standups. Please join me in saying no to these silly little meetings.
Jul 14, 2016
I am blogging again (sort of). Here is a post I wrote on the Lionbridge Blog about reviewing content in your CMS. Crazy. I know. But you would be surprised how many people think you should be reviewing content outside of their CMS.
Apr 10, 2015
I tend to be more aggressive than most when it comes to ending support for outdated browsers. As I mentioned in this article about ending IE6 support 5 years ago, supporting old browsers is not worth additional cost and drag on innovation.
I am happy whenever I see a big web property end support for an old browser, but I was absolutely thrilled to see that starting on January 12th 2016, Microsoft will only support the most current version of Internet Explorer available for their supported operating systems. This means:
- IE8 and lower will be practically dead. It will only be supported on some embedded versions of Windows.
- IE9 will only be supported on Windows Vista (remember Vista?), which will lose support on April 11, 2017.
- IE10 will only be supported on older versions of Windows Server.
Even better, whenever Microsoft launches a new version of Internet Explorer, the older versions immediately lose support on mainstream desktops (and probably phones and tablets too).
Thanks Microsoft! It is a lot easier to stop supporting a browser if the software vendor behind it has also abandoned it.
Apr 01, 2015
I was doing some anecdotal research about password security preferences and I was surprised to find that most of the people I talked to favored two-factor authentication (using Google Authenticator) over expiring passwords. My survey pool consisted of project managers who I think are pretty typical enterprise software users. Around half of them had not seen two-factor authentication until I showed it to them. The general attitude was that anything is better than expiring passwords — an opinion that I agree with.
Are my colleagues unusually geeky or is this a trend that other people are seeing as well? If you have experience, research, or intuition around this, I would love to hear from you. @reply me on Twitter: @sggottlieb if you have something to say.