On a related note, in an article on February 7th from VentureBeat about Microsoft potentially cleaning house to make room for more technologists on the Executive team, this particular quote from an Analyst in the article resonated with me:

“You see the engineering team ascending because Steve is realizing that there is a need to execute on a vision and in order to do that you have to actually understand how software is built,” said Wes Miller, an analyst at the Kirkland, Washington-based research firm Directions on Microsoft, in an interview with Bloomberg Businessweek. “It’s a whole other thing to be able to say, ‘I’ve been at Microsoft, I understand software, and what you are saying will or will not work.’”

The underlined portion is of particular interest to the Marketing Technologist - in order for Marketing departments to execute on a vision, an understanding of the technological underpinnings for that vision and the end-user experience it delivers is vital.

The Era of the Marketing Technologist

More importantly, you don't have to be a software company like Microsoft to require this expertise. For more in-depth discussion on the topic, read Scott's post on The Rise of the Marketing Technologist.

Making the Case for an Embedded Marketing Technology Team (E-Business)

In my interview, I make the case that Marketing departments should even have their own technology arm - at our organization we call it the E-Business team. E-Business drives multichannel sales, new customer acquisition, brand recognition and loyalty, and customer retention. For more on E-Business, read on.

I prefer a cadence of every-other-week 1-on-1 meetings with direct reports. Your mileage may vary depending on number of direct reports, geographic location, etc.

Commit to a schedule

Whatever you do, when you schedule these meetings with your direct reports, don't reschedule them, and reschedule them, and reschedule them.

Nothing says "this conversation is not important to me" more than a meeting that repeatedly gets pushed back days or weeks after its originally scheduled day and time.

Depending on your position on the organizational chart, there may be a lot of preparatory work that your direct reports go through prior to a 1-on-1 meeting. Your availability may also be a premium, so your direct reports may queue up important discussions for that 1-on-1 session where they have your undivided attention that they would otherwise not be able to get.

Fish or cut bait

If the meeting is destined to never actually take place, then don't bother setting the expectation that you will meet in the first place -- it'll save time for everyone.

During this time of year especially, when everyone is busy, make the time to invest in meeting with your direct reports. After all, they are supporting your objectives and ultimately make you successful.

Furthermore, where these groups align is also a pressing question, and it's something I've been searching for best practices on to understand how others are doing it successfully so we can position our organizational talent with career opportunities as well as establish a smooth operating rhythm.

Forrester's E-Business Organization Research

Forrester has put together a handful of articles on this very topic in the past 24 months and have been the only research firm I've found specifically dedicating analysts to the topic of E-Business. A Google search on E-Business org charts leaves a lot to be desired, so I'm compiling this list of the most valuable Forrester Rsearch I've found to date:

Most recently, Best Practices in Organizing for eBusiness, finally provided examples of E-Business org charts at different companies. A couple older articles include Building Best-In-Class eBusiness Teams and Dissecting High-Performing eBusiness Organizations.

In the End, Org Structure Doesn't Matter; E-Business Maturity Does

Forrester's eBusiness Maturity Model was published in the Is your eBusiness Team Ready for Prime Time? article and is essentially what E-Business executives need to use to evaluate the strength of E-Business in their organization. The maturity model is broken down into four primary buckets:

1. People, organization, and culture
2. Business and technology process
3. Channel integration
4. Measurement and metrics

E-Business teams must essentially be tailored for how your organization does business. There is no right or wrong structure provided it meets your business needs and you consistently build upon the above four maturity areas.

For example, I work for a consumer products company in which we do a very small portion of business direct-to-consumer online but in the end, relationships with our retailers are what ultimately matters. Therefore, our E-Business team is typically focused on "ease of doing business" initiatives, marketing our products online, and learning how consumers shop online.

On the flip-side, a retailer who sells multiple branded products would have substantially more online merchandisers on its staff because their goal is to sell products.

Three Spheres of E-Business Execution

Now, when it comes to execution, there is a right and wrong way. Borrowing from Jeremiah Owyang's Three Spheres of Web Strategy, these same three spheres of web strategy expertise are essentially the pillars of E-Business execution:

1. Community
2. Business
3. Technology

For reasons outlined in Jeremiah's diagram, you can't be missing one of these components and still have a successful execution.

The Secret Sauce for your E-Business Organization

Forrester's 4-maturity-area model is an essential tool in long-term planning and growing talent in your E-Business organization. Jeremiah's 3-sphere tactical model is where the rubber meets the road. E-Business can be a strategic advantage and you want to use these two models as guides for properly positioning E-Business within your organization. What works for another company may not work for your business and go-to-market strategy.

The single most important facet will be aligning with a C-level executive who either has a background or a willingness to learn and leverage E-Business as a competitive advantage. Without this, the E-Business team will fall into a rut of taking orders from business units without guidance on which projects are more important than others. The end result will be a resource-strapped, burned out team with no clear path for growth and no definitive business value to the organization other than "keeping the lights on."

What's exposed when businesses merge

Previously, Amerock was grouped under a different Global Business Unit and run independently of operations at Levolor and Kirsch. The merging of these business units has presented an interesting challenge from a website strategy perspective. The challenges are not unique to us and the purpose of this post is to not outline the specific challenges we faced but rather to focus on the high-level areas that mergers and acquisitions will eventually uncover:

Business processes, software platforms, job responsibilities, and online strategy must adapt to the new environment.

Enterprise E-Business must be scalable

I am fortunate to manage a team of people who are eager to take on new challenges and responsibilities. What we quickly discovered as it related to our Online Platform was that it had all been built around a single business (blinds & shades). This meant some of the software was specific to business processes unique to Levolor and Kirsch but more specifically, our business processes were very tied to Levolor and Kirsch.

When Amerock was infused into the mix, we had to re-engineer several areas (listed below). I won't go into how we modified these processes but at a high level, these were the core areas impacted:

Enterprise E-Business must function on repeatable processes

I cannot stress this enough particularly in the past few years in working in a Fortune 500 environment after coming from a small business of 20-25 employees. The enterprise is too massive for any one person to "know it all" so processes must be rigid, repeatable, with good people employed to manage through the processes and modify the processes when they identify deficiencies.

Tribal knowledge is acceptable in small business and is what enables small business to be agile. Tribal knowledge contaminates the enterprise, especially in the E-business arena. If an enterprise process cannot be repeated by more than one person without significant "hand holding," then it is not a repeatable process. A merger or acquisition will quickly expose deficiencies in processes.

Scalable, repeatable processes does NOT equal inflexible online experience

Perhaps one area where IT folks get it wrong most often is deploying a scalable, repeatable process that limits creativity (particularly as it relates to an online experience). Scalable and repeatable processes must inherently have a mechanism for dealing with unique business requirements and the ongoing management of these "exceptions." This is all the more reason why the E-Business/IT group needs a seat at the (business strategy) table. Without knowing the direction of the business, it is impossible to anticipate every possible scenario and build scalable, repeatable processes that will last.

As a part of ongoing career development at our organization, we have the benefit of meeting with an outside consultant specializing in coaching leaders, managers, and product teams. The end-goal is to broaden your horizons in the way you approach critical thinking situations related to internal projects and consumer-facing products (ultimately within the team or business unit you are part of).

Relationships management is different than project management
In my one-on-one discussion today, the question was posed to me: What percentage of your time is spent managing projects and what percentage of your time is spent managing people? After I thought about it for a minute, it dawned on me that the majority of my time is really managing relationships, not projects. This doesn't necessarily equate to direct reports who you "manage," but simply people/piers who you interface with on projects. It's an important distinction to make because relationship management is considerably different than project management.

Relationship Management in a large organization
My previous job was at a small business with less than 25 employees (where I worked for nearly 8 years). A larger corporation is different in that you have to deal with a larger number of people (and personalities) to the point where you are focusing on relationship management more than anything. To get any large-scale project done (like a consumer e-commerce site), being able to work with the various departments the website touches is a critical component to success. Taking that a step further and understanding other departments is an important component to relationship management and what separates it from project management.

Managing Relationships is Good for Business
It's interesting viewing the different styles of project managers in any business. Some are focused exclusively on the tasks of the project and at the end of the day, they measure themselves on their ability to complete those tasks regardless of what it took to get them done. I have seen this lead to major bridge-burning and damaging relationships with individuals/departments. While this may not affect the short-term health of an organization, it certainly does affect the long-term health and the ability to effectively work with each other.

Others are focused on getting what they need to get done while building relationships with other people and departments. Because when it comes down to it, you will probably need their help again in the future. Guess who's going to be more responsive to helping you out or going that extra mile for you -- the person who you steamrolled to get your project completed, or the person who you developed a relationship with? I know I am more inclined to help someone who will return the favor down the road.

Tying it back to online strategy
As online strategists, marketing managers, and even web developers, it's important for "us" (I group "us" together as the people that build/manage/maintain/oversee websites) to communicate what websites can do for the company and develop relationships with internal departments so they keep the website top-of-mind.

A business that operates with the website top-of-mind values the efforts of the online team by viewing them as a strategic department, rather than a cost center. Strategic departments have the perception of adding value to an organization. Cost center departments have the perception of costing the organization money. Operating under the umbrella of "strategy" is much more healthy (and fun) for everyone involved as opposed to a "cost center."

I'm currently reading Only the Paranoid Survive by Intel's former CE, Andrew Grove. It's interesting to read this book and read about how innovative and cutting-edge Intel is described, so naturally you start picturing what their facilities and culture are like. The Conan video makes office life at Intel look very drab and uninspiring.

How would your business look if Conan toured your facility? Would you even let him?

The end-user savvy developer & designer
Having developers who are usability-savvy and having designers who are development-savvy (may not be experts, but understand the general concepts of abstracting out CSS classes and approaching it like a developer would) is the perfect blend of talent. It's why I'm also not a huge fan of completely separating design elements from development elements in the code on a site.

A designer who's primary responsibility is interface design and usability is of much higher value to me if they know some code and can navigate around some of the simpler concepts with languages like PHP. Likewise, a developer who understands the value of making an effort to build a usable application is also highly desired. It's less work in the long-run for everybody.

It's hard to go into too many specifics without divulging our internal projects, but the above article was a really great overview as to why you've got to encourage collaboration and hire individuals who take interest in what the other aspects are of web design and development. Sprinkle in some marketing savvy amongst the designers and developers and you've got a very efficient team. It gives the project manager more time to spend with the individuals to brainstorm ideas rather than being the "bridge" between design and development.

Silos are bad in many areas of business, web development is just one of them
I prefer working with people who themselves don't act like their job responsibilities are in a silo. This is true in many aspects of business, not just web development. It's a concept that many developers don't fully realize and as a result, they may be limiting their potential growth within their organization/career path.