Here’s the generalized analogy…
If a major fast food chain can be run for many years with the ability do the following:
- Know what they do well. If your main competency is Burritos, Tacos, Ruby, or .NET you admit you need training or an outsourced company to build a handglider.
- Know what the REAL menu items are. “Products” are just a remix of ingredients (like meat, beans, tortilla or bun type, cheese, vegetable options, types of APIs, web services, etc.) and delivery method (here, togo, wrapped, in a shell, web, mobile, kiosk, software)
- Acknowledge the quality of ingredients and refuse to serve it raw just to get it out faster. That’s obvious.
- Have a concept store to test new products that push boundaries of their menu. I wish developers wouldn’t wait until business or Marketing dreams up something big. Test out the stuff that Technology can do.. regardless of whether it makes sense initially. A smart Marketer can see values and spin features. That’s what they are good at.. mixing up opportunities — not prioritizing Technical work!
- Iterate style and design of storefronts independently from menu items. Technology should have their own funding, resources, and projects to fulfill the infrastructure requirements without immediately affecting Business and Marketing.
- Point out when alternate sources may offer a better variety for consumers instead of viewed as competition. Want Pizza Hut or Long John Silvers with your Taco Bell!? Perhaps technology should realize when using another tech entities api would make more sense than building every aspect inhouse. In the past, I have seen more of these types of decisions result from a sales pitch made to Business. (because business, sales and marketing speak the same language and known pain points suffered from Technology restricting their menu)
- Have a simple dialogue about a collection of feature options. What was life like before combo meals!? Give Product Managers a simple vocabulary around different combinations of Tech services. API Type A + API Type X + checkout = product Configuration #1 with a set of foundation features pros and cons.
- Have the option to substitute features. Tech should present options to Business like “Supersize your features with API Z” or Combine with our limited time Beta release of xyz feature!
- There is no play-by-play announcement for how a menu item is made. We know where hamburger meat is from, but we don’t need details on how its made! Somehow, Tech ends up explaining development details to Managers that really only speak “feature” language. Don’t blindly trust that Product Managers can make the mental leap from how your technical steps translate to features that meet their goals. They are smiling, nodding, and doubting you. Once the estimate comes through, they will be on the phone to their “feature-speaking” salesman and paying for a contractor. Instead, Go from concept to prototype or industry example. Business and Marketing need moving pictures.
I just think that if Technology had better control system on their technical components (“ingredients”) and release schedule (window order speed), then they would be able to produce more sound technical systems. Systems that offer a better collection of remixed configurations (or combo meals). At the end of the day, the goal is to widen delivery options of a product which equate to more exposure, distribution, traffic and money!
Want examples of how that could work? It’s the essence of a service-oriented architecture. Open source mashups are also a prime example of ultimate configurability. Why do big companies struggle with this? They have all the resources — cash, equipment, and man hours. I know why…
Sadly, big companies tend to have lengthy, clandestine approval processes for technical development which is driven by the quarterly desires of feature-speaking generalists. They approve tech development dollars project by project with the only measure of success being a release date.
In the end, big business twists the technology around their owns interests and tradeoffs; then, Business blames developers as if its their incompetence for why features are not portable or able to release features. Well, actually it is! But not in the way you think.
The incompetency is in a complex problem…
One – Its the lack of understanding what Business REALLY wants with their feature speak (somewhat like mind-reading, but accomplishable by some). Tech people have to trace these needs to a myriad of deliverable systems that meet the goals… and that’s flexible enough for what business and marketing will imagine next.
Two – It’s in the inability to proactively manage their own release schedule. That is controlled by finance and upper level management, mostly. Even if Tech creates their own roadmap many times the resources get exhausted in delivering some project promised by the “Silly Wild Ass Guess” (SWAG). That seems the most unfair, but for Techs that spend their whole career in this environment, even handing them a blank check doesn’t solve the problem.
Three – It’s almost impossible for most people to stay motivated in an environment where perpetual brilliant hacks that keep Business happy in terms of “ROI”, and the “right” way to do things (meaning a better use of resources that can enable more things later than a short term fix) can be seen as slowing down progress.
Four – Technology is viewed as a service that develops a product (really a project with a specific implementation and testing effort). When actually technical services should be deemed true Products.
It just doesn’t make sense… Why do mashups and web services seem exclusive to web 2.0 and startups? Large companies wastes some serious resource talent. Is that measured?
So glad I don’t work for a big company anymore! 🙂
Blogged with Flock