In some discussions regarding Windows 8 and Surface, it has occurred to me how miserably Microsoft has failed in advertising the Surface.
Check this ad:
There is no substance to their message. You can watch this ad 100 times and not understand what is being sold here.
Look at Apple's ads for the iPad or i-Anything.
"Hey, look at how simple this is!"
"Look at how you can do all the things you want to do easily!"
Their recent ads for the iPad mini are brilliant in its simplicity: just two tablets side by side with people video chatting, playing games, playing apps, etc. They've effectively communicated "Hey, it's the same thing, only smaller" (whether this is true or not) and "It's so easy, even your grandmother can use it" and "Look, you can stay in touch and communicate so easily with your loved ones!".
This is what consumers want. Whether iOS is actually easier or not is another debate, but great advertising creates the perception that iOS is indeed the easiest to use. Consumers can connect with this advertising because it is simple, straightforward, and effective in communicating a brand image and embodied that brand image: "It's so simple, we don't need gimmicks to sell it."
What has the Microsoft campaign given us? What is the message? What is the key selling point of the Surface according to these ads? How is Microsoft capturing the market? A bunch of folks dancing around clicking a tablet into a keyboard dock. Is this ad selling me the dock? Is this an accessory? Why do I want to buy this hardware? Does it come with great software? A consumer can't tell based on that ad. Microsoft has literally given consumers the song and dance -- a gimmick, if you will.
This would not be the first time that Microsoft has failed miserably in designing a marketing campaign lest we forget the abomination of those Seinfeld commercials. They had a pretty good stint with Windows Phone, the "I'm a PC" campaign, and the a few clever bing commercials as well. Their tablet marketing campaign has been lackluster and has failed to differentiate themselves from the competitors. They have not demonstrated a reason to choose a Microsoft tablet over an iPad or Android tablet when they could have easily done so with an effective campaign around the software.
There have been many defenders of Microsoft online in various forums, but I'm not sure why there are so many fervent Microsoft defenders when clearly, the Win8 release has been a mess on nearly every possible level from the software architecture to the hardware to the marketing. "Yeah, but it's perfectly fine if you do this and that" is not a good defense because the operating system should be usable right out of the box.
It occurred to me that enterprise social is kind of like holiday parties -- AKA: enterprise socials.
When you go to a holiday party, you probably primarily interact with and socialize with the group of people that you work with on a day to day basis anyways.
But more importantly, according to recent studies, while 9 in 10 companies plan to have a holiday party, only 1 in 20 employees actually want to have a holiday party.
In my opinion, this more or less mirrors top down enterprise social initiatives. Employees would probably rather have better communication and collaboration tools and don't actually care about social tools (I make the distinction because you can have communication and collaboration without social).
It is the leadership that crumbles to the sexy sales pitch of enterprise social, failing to make the distinction between communication, collaboration, and social. Give your employees more communication and collaboration and skip the social.
Every once in a while, I'll talk to a colleague and the topic of SharePoint and "social" will come up. I mean literally, every iteration of SharePoint adds some other "social" feature or another. It always leads me shaking my head.
You see, Microsoft really talks a great game when it comes to social and SharePoint. It's the next big thing! It's all new! Look at all this cool stuff that you can do!
But all you have to ask yourself is whether Microsoft has proven themselves in any aspect of social. The answer is simple: no. And social for SharePoint is no different.
There is a very fundamental reason why it's a non-starter: social for the enterprise is stupid.
"But doesn't NewsGator make millions of dollars?"
Sure, but social for the enterprise is still stupid.
"But didn't you hear? They purchase Yammer!"
Yes, but social for the enterprise is still fundamentally broken. Never forget: Google once offered Groupon $6 billion -- doesn't mean that it was ever a good idea.
At the core of why social and the enterprise is fail, it's actually pretty simple as it comes down to one main issue: Portability.
Of course, for most people, their social networks often include a nexus around co-workers and professional acquaintances. The perfect case for social for the enterprise, right? Wrong! Because LinkedIn already has that covered and, more importantly, a professional social network on LinkedIn is portable. If I leave the company, I can still stay in touch with all of my contacts and connections at my previous companies via LinkedIn whereas my investment in a closed network is entirely thrown out the window the moment I leave a company.
A closed-system, non-portable social network is a useless one; it's a non-starter.
Aside from the major flaw of lack of portability, there are a few other shortcomings that come to mind.
The first is that, in a large company, I simply don't care about 99.5% of the people in the company; I'm only connected to these people because we happen to be employed by the same company, but that could change at any moment. In a small company, I will already have everyone added in LinkedIn or Facebook. What good is a closed-system social network when the people in that network would largely be people I already work with on a daily basis?
The second is that, in my opinion, what is of more value to teams are not social capabilities, but collaboration capabilities. Social is like the antithesis of task-oriented collaboration capabilities. Teams would get more value out of an investment collaboration capabilities than an investment in social capabilities. What I need from my enterprise platform is not social, but tools to help me and my team get things done. You want to know what other people are working on, but usually in the common context of a project or such so tools that are focused on communication and collaboration in the context of project workgroups seems much more useful and practical an investment to me.
The third is that many companies include a forum or discussion type system in their social initiatives. I saw this at CSC where Jive was deployed. But this kind of circles back to the closed-system problem: if I have a question or if I'm working on a hard technical problem, am I more likely to find an expert within my company? Or am I more likely to find an expert within the global community? This approach makes sense maybe within Microsoft or Google, where the concentration of highly specialized subject area experts is high. But in a consulting company, for example, it is less likely to be of any value as the global community will include a greater breadth of subject matter experts with a more extensive depth of knowledge.
Microsoft and social -- especially in the enterprise -- is pretty much a pointless endeavor, in my opinion.
Reflecting on the past year and a half, I've come to some conclusions on how development teams can be successful in delivering software. I don't think any of them are major or relevatory, but I think each team and each project has a different take on the same ideas. Here are mine:
During our active build phase, we release a new build every week and each build is functional software that incrementally incorporates requirements and defect fixes from previous builds. This has given us the benefit of allowing our customer to preview the software and help us identify flaws or areas requiring additional clarity in the requirements continuously and early in the process.
It might sound insane, but it is possible to release weekly builds because our solution incorporates a heavy dose of automation where it counts on many levels.
- We've removed raw SQL from the equation, relying purely on FluentNHibernate and NHibernate to automatically generate our schema
- We've invested in building tools to automate the export and re-import of configuration and data, allowing us to easily and quickly reset our development environments entirely with standard test data (bonus: the same tool allows us to move configuration and data from environment to environment)
- We've invested in idiot-proofing our installs so that they are boiled down to a few scripts
- We've built automated build scripts that package everything up neatly and even FTPs a build to our integration and test environments
- Our domain data model is 90% generated automatically from content schemas (SharePoint content types) which we have to create anyways.
Because of the automation, tasks which would otherwise be expensive are cheap to execute.
It also cuts down on mistakes and missed steps.
Our team is 100% geographically dispersed with developers and team members in Vietnam, Mexico, Virginia, New Jersey and California.
But relatively speaking, we meet very infrequently. Two development team meetings a week: one at the start of the week -- our "A" meeting -- and one towards the end of the week -- our "B" meeting. We use the "A" meeting to discuss our deliverables for the week and the "B" meeting to discuss the outcome of our weekly sprint walkthroughs, any adjustments that need to be made, and so on.
We also use these sessions as show-and-tell to let everyone see the progress and changes being made by different team members as well as to inform of upcoming breaking changes and mitigating actions required downstream.
Otherwise, developers are encouraged to have long spans of uninterrupted work time instead of constantly being pulled into meetings. One-on-one sessions and communications occur as necessary, but this recipe has been very successful in minimizing the amount of time the team spends huddled up in conference calls and gives everyone more time to solve problems.
Meet with a Purpose
Every meeting should have an agenda and an outcome (an action, decision, or an issue for followup). Demand a bullet-listed agenda when someone sends you a meeting request and provide one if you need to schedule a meeting. Ensure that the goal and outcome of the meeting is clear for all parties and schedule new meetings to resolve items not on the agenda or do not contribute to the outcome.
Additionally, create a record of every meeting. Who attended? What was covered? What was not covered? What was left open? What are the action items? Ensure that this record is easily accessible (wiki or forum system is perfect for recording these details) and email a copy to all participants and other relevant parties to ensure that everyone has the same understanding of what was just discussed. This basic task can often clear up misunderstandings before they become systemic issues. I take the burden on myself to record and followup with major bullet points from the meetings and it's saved my butt many times when following up with customers.
This is the simple art of not running a terrible meeting.
Lead by Example
A bit of career advice for those with a passion for software development: never remove yourself from the process of creation.
I have witnessed it as the career ladder moves individuals up and up, further from the pure act of creation that is software development. For those of us who feel invigorated when we solve a difficult programming task, for those of us who feel a great rush of exhilaration when a machinery of thousands of lines of code executes in harmony, it is our burden to tinker, to learn, and to create.
When you "ascend" from developer to architect or team lead or such, never leave your passion for creation behind; authority flows naturally from understanding, knowledge, and mastery -- not just a title.
I was inspired to reflect on this by an interview with James Dyson in Wired:
Wired: Now that Dyson is a sprawling, multinational corporation, how do you keep the spirit of innovation alive?
Dyson: We try to make the corporation like the garage. We don’t have technicians; our engineers and scientists actually go and build their own prototypes and test the rigs themselves. And the reason we do that—and I don’t force people to do that, by the way, they want to do it—is that when you’re building the prototype, you start to really understand how it’s made and what it might do and where its weaknesses might be. If you merely hand a drawing to somebody and say, “Would you make this, please?” and in two weeks he comes back with it and you hand it to someone else who does the test, you’re not experiencing it. You’re not understanding it. You’re not feeling it. Our engineers and scientists love doing that.
As a team lead, never just be a middle man with the developers and requirements; be an active participant in the process. Work on the hard problems. Understand the creation process and understand the challenges of the team from the bottom up and build your authority from your ability to innovate and solve problems.
If you watch shows like Iron Chef or Chopped, every one of the judges and every one of the Iron Chefs can be considered the vanguard of their craft and it is from there that their authority flows. You would not watch Iron Chef if all the Iron Chefs did was design the menu and then watch their team cook. You would not trust the judges on Chopped if they weren't great chefs in their own right that understood the ingredients, the techniques, and the skill required to pull off a dish.
The better you understand the system, the better you understand your team, the more effective you will be in understanding the root cause of an issue and how to route defects within the team.
Push Your Team Incrementally
As a young developer, I always found great satisfaction in solving new problems and new challenges. I think it's important that throughout the process, you push your team members and give them tasks that challenge their knowledge and abilities to push them just a little bit.
Of course, there will be plenty of mundane code and defect fixing, but don't box in your team members intellectually. Understand their capabilities individually and push them to try things that are just beyond their current level of capability, understanding, and comfort zone. This will keep them engaged and improve their skills to boot.
Invest in Code Quailty, Especially Early On
It's a lot easier to write good code earlier on in the process than it is to come in and try to refactor later on. Additionally, code written early on tends to be reused more often and patterns and solutions are copied by other developers later on. So early in the process, it is important to keep code quality in mind and correct bad behaviors since the most influential code will be written earlier in the process rather than later.
What this means is that detailed code reviews are far more important at the beginning than at any other time in the project. If you can correct bad programming practices or show a developer a better, more modular way of writing a piece of functionality early on, she will carry that knowledge throughout the project.
We rarely do code reviews now (1 year in) as I focused heavily on working one-on-one with developers as they joined the team to ensure that the code was up to standards. I frequently rejected code and asked developers to rewrite whole pieces of functionality to help them understand why one design was better than another.
Put Your Best Developers on Your Least "Visible" Code
What this boils down to is the framework level components. Your best developers should be working on the deepest innards of the system that power what the rest of the developers do at the presentation and business logic layers. This code will be the most invoked and the most reused so it is important that it is:
- Easy to use and as intuitive as the platform you are working on
- Well structured and object oriented to reduce repetition of code and code complexity
- Well documented with abundant examples -- your best developers must embody and practice whatever best practices have been designated
Do not waste your best developer's time with defect fixes (unless there is sufficient bandwidth), even if they can do it better than anyone else on the team because it will throw off the balance of the team (your more junior developers might not be able to fix a low level defect as quickly, but there are many design issues and higher priority defects that they cannot solve effectively yet).
Document, Document, Document
Early on in our process, I had to decide between a wiki system or a Word document for our documentation. Because of the fast, iterative nature of the project, I decided to use a wiki/forum system as it was more flexible and -- in a sense -- more "visible".
While our formal documentation is trailing, it is easy to assemble it from our weekly sprint guides which document every new feature with screenshots, details, and examples.
But at any given time, our customer and our delivery partner can load up the wiki and see exactly when we delivered a feature, how to install and configure the feature, how to use the feature, and so on. By putting it all out there in lock-step with the weekly delivery, it is easy to ensure that the entire team is aware of the status of the project and progress being made and allows test teams to progress iteratively so that by the end of the project, most features have been tested for weeks.
Mid ways through the project, we moved from "status" focused meetings to "demo" focused meetings where we would do a weekly writeup and walkthrough of what changed, what was added, and what was fixed. It also allowed for open forums for test and business teams to ask questions and get clarifications.
This approach has allows the customer to see progress and the customer will never be surprised at the end of the project as they will have seen the progress and documentation update on a weekly basis.
So far, we have done well with these basic guiding principles.
I'm sure I will revise and add to my own lessons learned as the project continues, but I think that this is a good starting point!