A Business Technology Place

Using history to organize your teams

What does the history of man and the advancements of civilizations have to do with business?

I recently followed a recommendation to read Jared Diamond’s book Guns, Germs, and Steel: The Fates of Human Societies. The book was the winner of the 1998 Pulitzer Prize for general non-fiction and provides theories and supporting arguments for why some civilizations throughout history survived and conquered other civilizations. Diamond supports the idea that societies persist and spread based on geographical and environmental factors rather than racial genetics.

Do business organizations parallel human societies?

On page 457 of the book Diamond explores the questions he received from many business leaders after they read his work. He sets-up the question as:

“What is the best way to organize human groups, organizations, and businesses so as to maximize productivity, creativity, innovation, and wealth? …. Should your collection of people be organized into a single group, or broken down into a small or large number of groups?”

Ah yes, one of the classic modern business dilemmas. Businesses are in a constant see-saw between a centralized and decentralized organization. Centralization is pushed to provide more standardization, economies of scale, and reduction of expenses. Decentralization is pushed to provide more innovation and closer customer relationships.

In his book, Diamond suggests that some level of fragmentation (decentralization) helped European advances in history because it created competition which led to innovation. Contrary to this, the unification of China appears to be a factor why it fell behind Europe in innovation during the colonization period. But India, which had even more fragmentation than Europe, didn’t advance as rapidly as Europe with technological innovations and colonization. That’s a very simplified look at Diamond’s discourse on the subject, but it leads him to suggest that the most optimal organizations have some level of decentralization in them.

The trick is to determine the right level of balance.

I promote a balance in a number of areas in the IT organization that I manage. This includes the number of in-house developers vs contract and “off-shore” developers, centralized software tools vs solution specific tools, and centralized processes vs sub-department processes.

photo credit: Leo Cullum

photo credit: Leo Cullum

A few things are certain with any approach:

  • People will point out the faults of the current organizational design and suggest that a change to another model is needed (based on the other model’s merits and not faults).
  • There is usually some level of second guessing by team members as they experience organizational results and look for ways to tweak the team setup to perform better.
  • There is a natural pull (almost like gravity!) that says we should organize differently. It’s the “always a better way” and “continuous improvement” approach to organization and processes.

I believe the answer depends on what you need from each sub-group in the organization.

IT, like other business departments, is further divided into group based on the type of service provided to customers. I believe groups like desktop/voice services and networking are best setup with a more central approach. This allows them to set to standards for equipment, general office software, voice equipment, etc. I look for this group to provide a consistent and predictable service to the organization. Less variety in what they support allows them to scale better.

The software development groups are tasked with providing innovation and helping the company be more competitive in the marketplace. As such, I like to have the software develop teams setup in a more decentralized organization. This gives them freedom to innovate and compete.

The project management, business analyst, and quality assurance groups benefit from a centralized approach as it helps them to reduce their toolsets and simplify processes. But they also benefit from a bit of decentralization so they can better match their processes to the software development teams.

The problems of any organizational design are always in the forefront to discuss, break-down, and analyze. I’m OK with that. As I said above, I think that’s a natural activity as we constantly look for ways to perform better. It’s neat to see correlations between Diamond’s study of human organization through history and the modern business world.  If you haven’t read Diamond’s book, it’s worth your time at least to skim and take-in some of the main theories.

Onward and upward!

2 Server Patching Approaches

Server patching is one of those infrastructure tasks that most business owners and infrastructure managers don’t link to the eCommerce portfolio. Operating system patches, virus scanner updates, database patches, etc. are all system level software not directly related to the code line of the eCommerce team. Infrastructure managers can certainly create a patching strategy independent of the eCommerce development process, but I like two methods that keep the current version of eCommerce code in the forefront to help minimize risk and make the patching process more efficient.

1. Follow code line promotions

The premise behind this approach is to install and promote server patches in same sequence of non-production environments as the code line increments. So for example a shop might have an environment sequence for code something like this:

Development ⇒ QA ⇒ Beta ⇒ Production

Let say there is a code release version 2.2 that is currently in development. Then as version 2.2 is deployed in sequence to each environment the infrastructure manager would additionally apply all new patches.

The advantage to this approach is that as the code line is tested in each environment the patches are part of that testing. This prevents the team from having a duplicate testing event just for patch validation and should provide a more thorough set of testing before production deployment. Testing patches for potential system incompatibility is always the biggest risk to production deployments. So this approach tries to mitigate the risk by having it tested by various groups in different environments.

A disadvantage to this approach is that the need for server patching may arise independent of the release schedule. Emergency vulnerability patches may arise due to a hacker exploit or some other industry event.

2. Snapshot and test

The idea of this approach is to make a copy of the environment that you will patch and then install the patches to the copied environment. The test team will then validate that there are no code incompatibilities by testing against the new environment. Once approved, the infrastructure manager can promote the patched environment to production or patch the original production environment.

The advantage to this approach is that it can run at intervals independent of code releases. That could be useful if there is an emergency vulnerability patch and the next code release isn’t scheduled for production deployment for another four weeks.

The disadvantage to this approach is that it requires more administrative overhead and management. Depending on how it’s executed you could duplicate tasks. Additionally it creates a separate testing event for the validation team that is independent of the normal test validation associated with code installs.

In practice, it may be best to use both approaches. Following code line promotions is a risk mitigation approach that doesn’t duplicate testing efforts and would work for a routine patch update schedule. The snapshot and test approach works for off-cycle patches that have a more urgent requirement for deployment.

Social commerce is gaining momentum

I love the idea of social commerce.
I’ve worked for years in and around eCommerce operations and expect to continue to do so for the remainder of my working days. eCommerce is an engine that drives revenue for a business while providing a touch point for customers to a brand and a set of products and services. The technology, platforms, and interaction styles will change over time. But with each change eCommerce blends into different variations of electronic commerce that center around marketing, media, and operations.The Social Commerce Blend

One such area that is starting, and I expect will grow as well, for retailers is social commerce. The big idea behind social commerce is to get consumers to collaborate while shopping online. The consumer becomes part of the eCommerce engine by helping with product creation, marketing, and even sales. All of this is the result of blending social media, digital media, and eCommerce.

In many ways the growing influence of social commerce for retailers is similar to the impact social media is having on the news media.  Media outlets are now using consumers to spread viewership to articles, videos, polls, etc. by sharing the links with their friends and family. Retailers will try to follow this trend by allowing consumers to be brand advocates, designers, and sales engines within their own spaces.

Would you buy a hip Converse shoe designed by your kids?
Paul Chaney of Social Commerce Today discusses a good example of all this with the article  Converse Facebook app for designing a Converse tennis shoe. The test is to allow the customer to design the tennis shoe and then open a store within Facebook to sell it to their friends.  Can’t you see this working with middle school aged kids where everyone wants to be the same and not stick out in the crowd? It also opens the door for thousands of more ideas and expands the reach of what the existing designers and sales group within the company could do.

Reality catalogs?
Another example is from online fashion retailer Zara called People!. The idea is to create your own look by posing with items from the Zara catalog and then submit your picture back to them. If the contributors photo is selected it is published online and the contributor is paid.  People like reality TV because it shows more everyday people in situations that might be real. I can see the catalog photos acting like this as well. Show me someone that looks like me rather than a fully staged model.

This is a healthy evolution of digital social media.
I realize brand advocates and referrals are not new to a marketing strategy for a business.  The difference here is the use of interactive digital media to scale the reach of the customer. In the past word-of-mouth referrals happened one-to-one based on conversations. With social media sites, the customer can get a message reach to hundreds/thousands of connections all at once.

Does this get us closer to answering the discourse about the ROI and financial contribution of social media? It certainly helps when there are activities that are trackable and revenue that is measurable. Expect more brands and marketers to try find the right combination of getting their customers to be a revenue producing connection with social media.

What do you think about the growth potential of social commerce?

How marketing technology, agile marketing, and Marissa Mayer are influencing the future org chart

An engineer turned CEO is a story that attracts attention.
The recent news that former Google engineer Marissa Mayer is filling the role of CEO at Yahoo! is a great example that traditional career paths in a functional silo are becoming a thing of the past. It should come as no surprise that company leaders today need to be well versed in both business and technical principles. It’s the result of the role of advancing technology and the digital world. Logically, it makes sense too. The most diverse leaders will be those with experience in multiple areas of the business.

But every career path doesn’t have to end with CEO.
The Real Story Group recognized the Rise of the Enterprise Marketing Technologist from recent research on the growing trend of digital marketing tool sets. A marketing technologist is a growing role in organizations even though they may have different titles the point is that the boundaries between marketing and technology continue to blur. Even my title is currently composed of “marketing technology”.

As I look back at the eCommerce organization mind map that I created, I can see the same concept there. Ecommerce management leaders have responsibility in software development, content management, merchandising, demand management, etc. Ecommerce is truly a melting pot of technology, sales, marketing, and operations.

Agile principles will further influence this trend.
Scott Brinker created a nifty diagram showing the Renaissance Career. The term may be a good description of the change that I believe will start to grow in the business world regarding career paths. That’s because the idea of agile development methodologies for software development is spreading to agile marketing methodologies.  Agile thinking values responsiveness over planning and focuses on interactions between functional areas more than passing large documents between them. Yeah, that means you might have the marketer and IT programmer at the same table. Lingos, language, and understanding will blend and blur.

This is good news for all of us. But what does it mean for “functional” departments in the company?
This means opportunity. It means rewards for those who seek to understand how technology solves business problems. For some it means advancing to an executive leadership role with more knowledge of how the enterprise operates. For others it means finding opportunities to serve in areas where they would not have ever imagined themselves.

Do you think this will lead to removal of functional groups in the enterprise such as marketing, IT, and sales? Will the future corporate department be organized around products and services more than the functional groups we know today? This means a more customer centric alignment rather than work type alignment. It allows the blending of our current functional roles into roles such as a marketing technologist.

Hmm. That would be a renaissance. What do you think?

Attacking process waste

I don’t like process waste.

Who does? But how many of us really try to change processes to eliminate or reduce waste? In my experience this is a tough topic, and I dare say an unwelcome one, most of the time. The problem is that in an organization processes are tied to job existence and security. So the people in charge of setting the processes and administering them really don’t see the incentive to make adjustments.

I’m nearing my 20th year of software development experience, so I’ve observed and talked to many practitioners about software development process philosophies and techniques. Process waste starts to build when the people within the organizations place more importance on the process steps (requirements, estimates, and schedules) instead of the process output. The ultimate goal of software development is to make money by producing output. Waste takes away from the output.

Business case modeling and estimates are a common area for waste.

Let me start by saying that business case modeling and estimates are a necessary part of software development. The problem arises when the business case and estimates begin to consume a large percentage of the organizations time and a large percentage of the work is rejected. All of the work becomes throw-away because it has not created a return. Ironically the entire point of the business case is to prevent waste. We don’t want our organizations to produce product that does not yield a financial return.

Think about it. If the software development team is constantly estimating and scoping projects that are not approved then it reduces the amount of usable output created for the business.

The theory of constraints is a critical teaching to understand.

The Wikipedia entry for the Theory of constraints quotes Eliyahu Goldratt.

The underlying premise of theory of constraints is that organizations can be measured and controlled by variations on three measures: throughput, operational expense, and inventory. Throughput is the rate at which the system generates money through sales. Inventory is all the money that the system has invested in purchasing things which it intends to sell. Operational expense is all the money the system spends in order to turn inventory into throughput.

In a perfect world, everything the software development team touches is processed into work output that generates money. We don’t live in a perfect world, but we do want the throughput of the system to be optimized. So it should produce money making output as quickly as possible. Work that is started and later thrown out is like throwing away inventory and only increases the overall operational expense of what it takes to get good output.

You have to work the constraint.

I’m a strong advocate that software development needs to focus on features, not projects. Projects are by definition unequal in size and length. Features are smaller in size, easier to understand, quicker to estimate and assist with providing more consistent system output. Bloated projects tend to have large price tags, take weeks to estimate, and are more likely to be rejected by management.

Think about the project approach. A team may spend two weeks creating a business case to review with management. Then the development team spends another two weeks estimating umpteen features. If the project is rejected then there is four weeks of effort that creates $0 of sellable output. The exercise devolves into a discussion about a single cost to build and the the time required to do so. It’s all or nothing and the focus on the goal of making sellable output is lost.

So if we want to work this particular constraint in the system then we need to evaluate each feature on its ability to achieve the end goal. Everything else is really just noise waste.  I hate waste.