Why Project Management Is Killing Your Business (And What to Do About It)

Endless piles of books, podcasts and conferences have attempted to tackle the thorny issue of how you manage the massive portfolio of projects in your organization.

Countless frameworks and methodologies have been developed, yet IT practitioners have yet to reliably solve how to execute, manage and scale project management.

With so many ideas and approaches, you’d think the problems surrounding project management would have been solved; that we would have found the ‘One Way’ to manage projects.

Not so!

Some strategies tend to work better than others, but I’ve seen countless organizations that utilize strict agile development processes consistently fail on the project management front.

As we will see below, what project management failure means in practice is that you disempower your developers by limiting their autonomy and ownership.

And taking power away from the people that are driving the digital innovation you need to survive is going to kill your business!

Why Is Project Management Killing Your Business?

“If everywhere you go, it smells like crap, maybe it’s time to check your own shoes…”

The methodologies and frameworks aren’t the issue. The people aren’t the issue. The tools aren’t the issue. So what is it? I believe the problem is at a higher level: the management of project management.

Traditional project management is managed and operated centrally. Your entire organization likely has a single Project Management Office that is separate from the many diverse development teams. What tends to result is that all projects are subject to a singular workflow that specifies procedures and processes along with the centrally-owned tools that track work for organizational reporting.

The core problem is this: you cannot possibly prescribe a single method for every single task across every single development team!

This creates a host of conflicts between your organization and your developers:

1. Your developers have limited ownership of, and accountability, for their work

Many of the core tenants of modern IT revolve around an extremely critical theme: ownership and accountability. High-performance IT is directly correlated with high levels of ownership and accountability among teams.

But traditional project management separates itself from the development processes by being managed and operated at an organizational level, cutting developers off from the decisions about how they work!

2. It creates a conflicting incentives between departments

Centralizing all operations and project management at the organizational level creates a leader-follower dynamic for development activity.

The problem is that the centralized management teams (leaders) have different incentives than the development (follower) teams. Development teams are often incentivized by their throughput, or ability to release new features and respond to issues in a timely manner. Centralized management however, is more interested in ensuring process and compliance is followed, regardless of whether this negatively impacts developers’ timelines.

Misalignment is inherent in this model, because this control naturally creates friction in the system, leading to missed dates, frustrated employees, frustrated management, and frustrated project managers. Over time, this chaos causes the problems to compound upon themselves, leading to some sort of significant IT shakeup—such as reorganization, budget realignment, ownership and responsibilities reviews, etc.

3. It drives productivity into the ground!

A narrative I see time and time again is the following: “We’re using Agile and every sprint is two weeks, and every team operates on the same sprint cycle, and all tickets are tracked in this tool, and we run weekly reports of ticket velocity to management and review individual tickets with them...so you better be closing your tickets on time as tickets represent work performed!”

The disconnect with centralized governance here is questionable performance-based measurement. This creates a culture that disenfranchises the employees it oversees.

This is a fantastic way to drive actual productivity right into the ground!

Organizational metrics looking to understand velocity through tracking don’t actually have anything to do with productivity, but rather with an abstracted proxy of productivity.

In practice, this approach puts pressure on teams to react based on management opinions rather than customer needs. These metrics can and are gamed. Working this way is also a fantastic method of getting your talented developers to quit because they can’t deal with the bureaucratic overhead of the model.

How Can You Stop Project Management From Killing Your Business?

Instead, the focus of project management must be on enablement; undoing the separation and conflict that causes project management to fail.

Team enablement is critical to the long term success of any organization. Ownership is the cornerstone of enablement. If you don’t trust your developers to deliver with relative autonomy you are not only limiting them, you are also ensuring that you are not getting an accurate picture of the amount or quality of work being performed.

Your project metrics should be centered around realized business value, not how many lines of code were written, nor how many tickets were closed. Allow the teams some say into how their work is tracked and managed and the teams who care about their work will be interested in making the situation better for everyone.

In building a culture and balancing the organizational guidance for success two paradigms are critical here:

  • Alignment: Development teams must be aligned around products, not projects

  • Ownership: Work on those products must be owned by the teams themselves

It is a given that project management and organizational oversight is necessary in every organization. To find a balance between what the team needs to sustain itself and what the organization requires for oversight we find that the team must have a say in their project workflow.

What Does This Look Like In Real Life?

I often joke that the most important thing I ever did for one team was to create a new policy for how their projects and release management operated.

The change effectively gave them special dispensation from change control boards and all other centralized project management processes. I took the new policy through all the bureaucratic processes to get it officially signed off, and instantly the team’s time to production went from every two weeks to hourly. At that rate, problems don’t take long to fix and new features can be released extremely quickly, shortening the feedback cycle time between you and your customers. Now, this only worked because the team was top-tier talent and could be effectively trusted to handle this responsibility. This does not apply to every team in all organizations, but it clearly indicates what the direction of travel should be: as much autonomy as can be granted within the context of your organization.

Between centrally controlling every minute detail of how projects are managed and total laissez-faire anarchy, there must be some form of common ground that allows for accurate tracking, reporting, planning, and the like, while still allowing good teams to shine in their own way.

How to Find the Right Balance

Here’s the part of the story where I don’t give a straight answer and stick to generalisations, because how to handle this problem ultimately depends on your particular organization: its tolerance for risk, its requirements around reporting and roll-ups, how its budgets are planned, and how much it trusts the development teams. To further complicate matters, even starting this conversation internally can be portrayed as potentially insubordinate or completely impossible.

Addressing these types of issues is daunting. Even if you have the authority to dictate a new process tomorrow, that will only introduce more chaos and headache. The best way to approach any change of this type of scale is to experiment and continuously adapt your approach as you expand it across your business:

  1. Pick a team: identify a productive and forward-thinking team to test approaches with

  2. Start small: identify an area of limited scope to improve, for instance, change control processes

  3. Work directly: determine the best path forward directly with the team and allow them to experiment with varying approaches

  4. Iterate: learn from each change you make and incrementally improve over time

  5. Scale: expand best practices and learnings to other teams

  6. Gathering insights from your developers on the ground is a crucial step in figuring out where to begin. Here are some questions to guide you:

    • What issues do they have with the system?

    • Do they believe that their productivity is fairly communicated to management?

    • Do they even know how the metrics work and are being communicated?

    • What processes cause the most pain?

    • How would they prefer to work?

    Compromise with the governance team and the development team. Get a special dispensation to change the way work is tracked, and then continue to work with all parties to understand what is working and what is not. If a team wants to stop using the centralized ticketing system, is there a way to obtain a similar metric from the team (story points completed per sprint, for instance) that can be communicated in a similar fashion to the other metrics?

    Try a few strategies out and see what works. Then you can begin scaling to other teams and eventually change your whole organization!

    Don’t let the management of project management kill your business!

    The Risk Management Paradox: Enable Your Teams By Giving Up Control
    Also available on Medium.com

    Everyone is familiar with the phrase “if you love something, let it go. If it comes back to you, it’s yours forever. If it doesn’t, then it was never meant to be.” IT Risk can be a lot like that, it sounds crazy but hear me out for a second. Organizations today are desperate to get to a better place in their IT shops, by adopting Agile, DevOps, utilizing Big Data and ML/AI. Most of these companies barely dip their toe into the depths of each of these concepts, while leadership touts their “modern IT practices” to anyone who will listen. The good news is that most professionals understand the generic direction to take an organization, but almost no one knows the details of how. This blog is going to go into one aspect of that how: managing risk and enabling teams.

    Adopting modern IT industry best practices is an exercise in enabling teams. To do this, you must maximize the ownership and control of the things that are within that team’s perview. Many teams today have very little ownership and control over their day-to-day.

    Here is an exhaustive list of the things many development teams fully own and control:
  7. When to take coffee breaks

    Things development teams do not own and control:
  8. What to develop
  9. The timeline
  10. The budget
  11. The tech stack
  12. Architecture
  13. The development tool set
  14. Infrastructure
  15. Dev/test/QA/prod environments
  16. Code pipelines/Continuous Delivery
  17. Data layer/log management/reporting
  18. Security controls
  19. Operations/maintenance

    It seems fairly simple to define the narrative of how we got to this state. In an effort to grow their IT capabilities, companies had to hire a lot of people. Some of those people will naturally not be as competent as they should be, and as a result, bad things happen. Unknowing executives, in an effort to save budget, traditionally throw development tasks to outsourced third-parties that crank out code with just enough quality to run—for now. Months or years down the line, something inevitably causes an emergency, such as a critical security vulnerability, extremely antiquated environments (just how many Java 1.4 environments are out there, exactly?), desire for new features on a tech stack that no one knows how to deal with and many more! Now, part of this problem I blame on finance, which treats everything in the IT space as a project and not a product (I recommend the book Project to Product by Mik Kersten), and as such, the main objective is to produce a working deliverable and I don’t have to worry about the maintenance or ops of that thing because by the time it breaks, we’ll all be long gone on a different project, making the same mistakes over and over again. Then, naturally, IT gets a bad rap since the optics make it seem as though everything in their wheelhouse is poor quality and breaks all the time. So, obviously, we have to put controls in place to ensure these emergencies stop happening!

    Solving Quality with Policy

    Here comes the policy parade. We’ll spend months creating sound, foolproof documents on how “vendor A must meet requirement X,” and “developers can never have any access to any production environment,” and “the tech stack will be standard across every team so our maintenance team can be cohesive and deal with only one type of problem.” Before you know it, you have silos engrained across the entire org and employee fulfillment and happiness breaks through the floor and into the sub basement. At least everyone can show off to the CIO about how we all have a handle on the situation though, right? Except whoops, it never works out quite that way, for multiple reasons:

    Vendors will either lie about their ability to meet requirements, or do the absolute bare minimum in those areas that are visible to their clients to prove compliance and end delivery may or may not actually be compliant. After an initial review and signoff by the compliance teams, they will be free to do whatever they want.
    There is usually no procedure in place to perform any auditing—nothing is revisited.
    Tollgate processes aren’t staffed with people who are competent with what they’re being asked to review (policy people reviewing highly technical deliverables).
    Standard, shared environments have multiple teams with different objectives all hitting them at the same time, causing environment drift, fracturing and outright destruction.
    Developers are less efficient with the standard tool sets rather than using what they are familiar with.
    Project lead time shoots through the roof. Everything must be passed off to the silo owner. Change of a database field? Lead time. Passing off to QA for validation? Lead time. Bringing changes up to a change control board and getting signoff? Lead time.
    Code rollouts are all bundled up and shared across multiple development teams, ensuring that there will be merge conflicts, massive regression test suites and long nights of pushing code to production and sitting there for hours to ensure nothing goes sideways.

    At this point, I’ve hopefully gotten at least a few head nods out of my readers. Much of this is a standard cancer that infests these “robust, secure” organizations. So robust, so secure in fact, that little gets done. Risk teams are often not risk averse, they are risk nullifying. I often joke that we should be so risk averse that we go take an axe to the datacenter power lines. At least that way we can’t be hacked.

    How To Get Started

    To get out of this hole, something has to give, and realistically the only possible thing that could give is risk. That means some measure of control has to be given up by centralized IT and handed back to the developers. Yes, that means that developers could potentially break something. Yes, that means that technically a developer could install something the company didn’t have a license for, creating legal risk. This means that you must empower your developers to such a degree that they can potentially cause harm. If that scares you so far out of your wits that you couldn’t imagine such a future, then maybe you need to take a hard look at the quality of developers you’re contracting with or employing. Strong developer empowerment cannot happen when developers are not worthy of that empowerment, and for the longest time developers have been treated as throw-away products, simply code monkeys to take the requirements of the actual smart people (your architects, security professionals, etc.) and then churn out the “stuff that makes the app go.” We come to a bit of a dilemma here, because I don’t assume it is even remotely possible for an IT org stuck in this type of reality to pull itself out by removing all poor performers, then finding the budget to hire absolute top talent, thereby mitigating the risk of developer empowering. To practically address this problem, we need to first take a look at “what is possible to lose control of?”

    It is not wise to completely remove all semblance of centralized control overnight; your development teams—and even the management layer on top of them—would have no idea how to handle that much responsibility all at once. Therefore, a nuanced approach is required. Furthermore, it will depend on the capabilities of your org to perform the necessary auditing requirements to ensure that enablement doesn’t run away from any semblance of process and control. Here’s an example of a good way to handle enabling a team:

    Let’s take a competent development team that has no control over the dev suite they’re dealing with. Perhaps the organization has specified Eclipse as the mandated IDE, even though a substantial portion of the team is more familiar with IntelliJ. While the licenses for IntelliJ cost money, it’s a massive sign of goodwill for an organization to reach out and offer to pay for a tool that the developers really enjoy using. This would measurably increase their productivity and work happiness. The risk here is extremely low because the code output of Eclipse and IntelliJ is not demonstrably different.

    Another example that actually does increase risk, is allowing a development team to own and control their own development, and even test environments. While you can simply put down the new mandate that teams are now in control of their own environments, doing that and nothing else increases your risk factor more than is acceptable. For instance, now you run the real risk of having so significant of environment drift across teams that the practice becomes untenable. To mitigate this risk, it is important to not only have policy in place (“anyone who opens port 22 to the public internet will be fired”), but have some form of automated (or at the very least, manual) auditing procedures in place to check that these policies are actually adhered to. There are tons of ways to automate environmental policy. The reason tollgate owners are so risk averse is because it’s their butts on the line if they let something through that shouldn’t be, so the default behavior is to say “no” to everything. This is incentivizing the wrong behavior. Policy admins should not be permitted to say no to proposals, they should rather be empowered to determine the best way to ensure adherence to policy via automation and tools.

    Some Examples

    Let’s take that list of things developers don’t control and go through some quick examples of how an organization could potentially address each item:

  20. What to develop
    Bring developers into the ideation phase, give them a voice. Change the way the “what to develop” comes about. Get ideas from developers, and put them in charge of getting data about their applications that will help guide these decisions.
  21. The timeline
    Trust that developers are telling you the truth when they tell you how long something is going to take; if everyone is saying it’s going to be 9 months to crank something out, and leadership has given you a two-week challenge, it’s time to have a chat about expectations.
  22. The budget
    Give developers a financial “andon cord” that allows them to voice concerns about the budget, and allow them to suggest other vectors of how to handle the problem. Do your developers have a say in potential ways to save money? By challenging the current direction on infrastructure and architecture is there an ability to mitigate cost?
  23. The tech stack
    If a team just really, really likes Go, determine if there is a way to actually allow for this. Is this team going to own the maintenance of the project/product going forward? (hint: they should) If everyone got hit by a truck tomorrow, could you hire more Go experts?
  24. The development tool set
    Give devs the ability to pick their own development tools. If the team wants to utilize Docker on Macbooks, then get them Macbooks and let them install Docker. New tools can absolutely go through a vetting process where things like tool licensing and risk can be managed. Doing this also has the added benefit of encouraging your developers to learn about new technologies, which could potentially be adopted by the rest of the organization.
  25. Infrastructure and architecture
    Modern DevOps is not highly paid senior architects dictating how an application should function, it requires collaboration at all levels. This isn’t to say every developer should be involved in every strategy session, rather that there must be a method to collect feedback, a path to address concerns, as well as empowerment of the development teams to provide input into architectural decisions. As your organization gradually adopts a DevOps mindset, certain teams will be able to show themselves as masters over their own domain, and are therefore enabled to make key infrastructure and platform decisions. I.e.: instead of EC2 instances, we’ll be utilizing Lambda, SQS, and DynamoDB for everything, thanks infrastructure team, now you have no ops to worry about.
  26. Dev/test/QA/prod environments
    Standardizing environments does not mean what most people think it means. To standardize an environment, you should be able to completely destroy/terminate/delete an entire environment, utilize an automated job to create a new one and configure it with everything that is needed within minutes. Once you get this in place, you can turn the development teams over to their own environments, knowing that they all mirror each other. This also has the added benefit of allowing for timed automated destruction of environments, ensuring that no server hugging is going on and potentially cost savings by spinning everything down after hours. Teams should also have the ability to muck around in their non-prod environments, with the expectation that any critical changes go back to whatever team is managing the environment templates for discussion, approval and adoption.
  27. Code pipelines/Continuous Delivery
    If a team owns their own environments, it only makes sense that they would own their own pipelines to those environments, right?
  28. Data layer/log management/reporting
    Teams should have agreed upon SLAs for communicating with other systems. By loosely coupling the various systems, and each team being treated as a black box (I give you this request, you send me a certain response), we allow each team to do whatever crazy middleware they want. Where possible, data should not be siloed, it should be generated in a team, the team controls that data and if it is needed elsewhere it can then be shipped to a centralized location.
  29. Security controls
    As mentioned earlier, while teams should be enabled to make bone-headed moves, those bone-headed moves must be immediately caught and remedied by automated monitoring and alerting platforms. This is a paradigm shift in the way your security/DevSecOps organization works. The security org must not only make policy, they must have mechanisms in place to automatically detect things that are outside of that policy and have procedures in place for remediation.
  30. Operations/maintenance
    Ultimately, an enabled team owns their own deliverables. This forces your teams to eat their own dog food and encourages them to produce clean, defect-free code, since ultimately they’ll be the ones called to fix an issue at 1AM.


    Every time you give ownership of something to a team, you lose traditional centralized control. Most organizations are so caught up in losing control that they don’t realize is that if they changed the way they look at control, they’d find that they would actually have more control, rather than less. By enabling your development teams in an iterative fashion, coupled by changing the way your compliance teams operate, you can provide significant autonomy to your entire org and realize an absolutely unfathomable amount of increased productivity out of your teams.

    The Problem with Purchasing DevOps
    Also available on Medium.com

    As everyone already knows, the IT domain is an extremely new addition to the cumulative total of professions in the world. The success of IT-based companies and career successes of it’s practitioners naturally garners a lot of attention. Just recently, large enterprises are being forced to consider their IT shop as something other than a mere cost center that sits there and sucks up highly-coveted funding dollars. Many leadership teams understand that they have to “do better” with regards to their IT practices, but the definition of better isn’t defined, much less how to get there. Companies are desperate to modernize their IT shops, looking for change from within, adopting best practices across the board, and throwing middle management at every buzzword that one can find in a modern IT media piece.

    On the surface, this all makes sense. After all, if a business needs a physical building to conduct operations, you say “I want a building here, Mr. General Contractor, please make it to these specifications, and here’s how much money I have to make it happen.” Then, usually, it just happens. Sure the budgets and timelines may be in flux, but ultimately there’s a reasonably clear plan, and all the steps to get to the goal of having a functional building are known in advance and can be planned for. IT isn’t like this; in fact it’s practically the antithesis to the idea that known inputs provide known outputs. The introduction of unknowns naturally creates confusion and frustration; individual contributors are mad that they’re getting told by management to adopt [insert new industry concept/tool here] with no roadmap provided, and less budget than it would take to actually do anything truly transformational.

    One of the terms I’ve heard thrown around more often than I’d like is “DevOps.” Now, DevOps could be replaced with just about any other buzz-wordy term that floats about in the IT domain, for instance: Agile, Big Data, DevSecOps, Containerization, even “older” terms like Cloud to this day don’t conjure up a visual in non-IT people. This makes it extremely hard to bridge the gap between business goals and drivers, and IT practices and tools. Desperate to get a handle on IT modernization, management flits from practice to practice, tool to tool, over and over again in an endless effort to “reach IT nirvana.” And by golly if we could just have DevOps we wouldn’t have to worry about anything, right? The visual I always get when I hear these types of efforts coming from leadership teams is a well-meaning, but clueless person writing out a check with “DevOps” in the “to” line. “One DevOps, please!” this nameless executive says, throwing the check across the table. The expectation is that, once I pay this money, once I simply purchase DevOps, I’ll have what I want and my IT shop will be more stable, people will be happier, I’ll get a fat bonus because stuff will be better; granted, I have no idea what better entails, but better is the focus.

    This is a trap! It’s certainly a great sales and marketing gimmick that many companies that are either selling a tool or consulting services can take advantage of: “if you purchase [insert thing here] then you too, can have DevOps!” This is the equivalent of eating a kale salad for lunch one day and declaring that you’ve suddenly gotten healthy. Organizational health is just like bodily health. It requires constant vigilance and care. Purchasing a home gym won’t get you healthy, just like purchasing a new tool won’t get you DevOps. It’s a lifestyle change, it’s a total paradigm shift, and many orgs are simply not prepared to make that shift. At least not overnight.

    Here’s the part that sucks: just like getting healthier, you have to start small, and you have to stick to your regimen. There are multiple different ways to start on this journey, and each organization is different, but the overarching theme across all DevOps transformations is that you have to identify what area/team/project/product/etc is doing the most DevOps-y stuff, and work with them to get better at operating under a DevOps mindset, and come up with plans on how to continue to upskill those employees, and spread those learnings to other parts of the org.

    Typically, it’s usually easy to find at least one person or team that’s preaching DevOps from the mountaintops in an IT org, and if you don’t have that, it’s probably time to find one. After that, the road to organizational health is obfuscated. Perhaps you have long-standing architects that still advocate for bare-metal builds, running custom-compiled binaries because “it’s more secure this way.” Perhaps most people in the org understand the best practices and have an idea of where the org should go, they just haven’t taken full advantage of the existing toolset and knowledge base. Regardless, there’s varying levels of change you’ll need to prepare yourself for. If an organization is so set in its ways that change has been repelled time and time again it may be time to completely toss the pieces in the air and see what happens when they come back down. Before you go down the reorg route, it’s important to understand what it is your future IT organization looks like though. What is DevOps to your org? For instance, when every org says “we’re doing Agile,” what does that actually mean? Do you just want your teams doing Agile, doing DevOps, or is it better to say that you want your teams to be faster to market, produce better quality products, and have more fun at work doing so? I’d say it’s the latter. DevOps is a toolkit to utilize to foster and maintain this type of transformation, it is most certainly not a product you purchase.

    The conclusion here is that your journey to DevOps won’t be realized through a purchase; whether tools or people. Tools and people certainly have a place in this journey, but be wary of anyone that says “you’ll have DevOps if you start checking boxes on this list.” DevOps, much like other industry terms is a methodology, a mindset. Getting help on how to be successful on that journey can be an accelerant to change. Employees want to work in a healthy organization, and many of them already know that they, too, “want DevOps;” they want to work in a DevOps styled shop, and maybe they even know some of the steps of how to get there. Often times, it’s difficult to take the feedback of these employees as they’re often individual contributors who are telling you to completely change the way the entire IT org operates. Working with a knowledgeable outside firm to help you figure out what that game plan needs to be can be helpful. Regardless, your focus should be on starting small, identifying where the good individuals and teams are, and enabling them to light the fire elsewhere in the org.

    Consumer 360 whitepaper

    Note: The industry's accepted term for this initiative is Customer 360, however GE Appliances' initiative isn't focused on our big box customers, but rather our end consumers, or owners and as such is labeled Consumer. For the purposes of this paper, "consumer", "customer", and "owner" are considered interchangeable.

    The Consumer 360 program objective is to "know the owner." The first problem statement we discussed was the case of an owner registering their product with us, thereby giving us their name, phone number, address, install date, etc. This is all extremely valuable data that we can use to service the product and owner better in the future. However, when the owner called in days later to schedule service for a problem they were having, we suddenly didn't know who they were. Why? As is the case in many organizations, applications and data are located in logistical and physical silos. Registration data goes to the registration team. Service doesn't have access to registration data. Most data sources are in silos, unless an actual project has been completed to tie the two systems together, which is typically a massive effort of figuring out how to tie together two completely different balls of twine. This scenario gave us our first insight into the bigger issues surrounding data availability and data quality, and led the team to proposing three distinct phases for our Consumer 360 initiative.

    The Three Phases

    There are three distinct project phases that allow for foundational growth when it comes to knowing your owners. They are as follows:

    Phase 1: "What data do we have, and who needs it?"
    Phase 1 is essentially what I consider as "catch up." Most organizations have very good data and information, it is simply stored and accessed in such a way as to make it not useful outside of individual application silos. The objective of this phase is to present a logical view on top of that data to provide it to all the functional areas of the business to allow for greater internal consumption of the data. This is not saying that all data needs to be migrated to a singular repository, with various complicated ETL/batch jobs to replicate, annotate, and move the data. The model for this phase is focused around black box microservices. These services will logically hit all the various sources of truth throughout the company, and structure replies that make it seem as though all the data was actually in one place, when in reality there are a myriad of real-time queries and other API calls going off in the background to pull the data when it is requested.

    Example: let's say we have a call coming in from an owner to a call center. Today, that phone number may be looked up in a local database that only has a footprint of the call center in terms of data storage. That means that even if the owner has provided data another way (through product registration for instance) that local database would not have a record of it, and therefore the owner would be expected to supply information they have previously given us yet again. This fosters an exhausting customer service experience. In order to address this gap, the Consumer 360 initiative will develop APIs that call not only the local CR databases, but also query in real-time the product registration database(s) wherever they may be. In addition, there should be real-time lookups to all other systems that may have any owner data, such as parts ordering, delivery, etc. This presents a more complete picture to CR agents allows for quicker resolution to owner issues, and makes the consumer less likely to get frustrated due to the agents not knowing something the consumer feels they should.

    The (what should be simple) act of providing data across silos--creating a rudimentary enterprise data bus--immediately drives immense value to organizations with segregated data. The simple act of creating a service that allows for quick part number lookups, versus the current flow which is to literally pull up a terminal for mainframe access, type an archaic command and then parse tens, maybe hundreds of line items to find what you want, will immediately save around 5, 10% handle time for many service calls. By focusing on these small, immediate wins, the team proves its value, and gains momentum for the larger steps that are to come.

    Phase 2: "What data do we want, yet don't have?"
    This phase gets a little tricker: we need to know what we don't know. What data points around owners can possibly be valuable if we want to "know our owners?" Does square footage of a consumer's house provide us any value? Is it easier to market larger, more expensive products to those families? Speaking of families, should we know the size of your family? What about your hobbies and interests? Initially it sounds silly to think of an appliance manufacturer wanting to know personal details about consumer's lives, but if we knew that you liked activities that got your clothes extremely dirty, we could potentially raise awareness of a special clothes washing cycle that is tailored just for your active lifestyle that you probably didn't know about.

    Getting the data in this phase is complicated. We can spread our own internal nets, and develop tools and modifications to existing consumer portals to attempt to collect that data, and we can go our and purchase data as well; but when to do that? We have millions upon millions of consumer records, and purchasing a large dump of data would command an astronomical cost. More than likely, the approach will be to supplement our internal data in real time when a request comes in. When calling into our questions department, which is typically done pre-purchase, we probably want to know what existing brands you are familiar with or like. Companies like Neustar provide APIs that would allow us to query consumer likes, dislikes, brand familiarity, and more simply by providing a phone number. Would pre purchase agents be able to suggest the best product if we already have a handle on the type of consumer you are? Absolutely. Experience call center agents are extremely versatile and able to make quick decisions with limited data sets. The more meaningful data we can provide to them, the better decisions they can make, and the happier our consumers will be with their purchasing decision.

    Phase 3: "What do we want to know, and how do we change our business processes?"
    Phase 3 is where things get fun. We now know our owners, and have a series of services that allows the entire business to tap into that knowledge base. Our internal teams are more efficient and have easier access to data they didn't have before, so now what? There's two mini phases here: high level big data analytics, and business process enhancements.

    Traditional "big data" analytics, while technically in scope for the C360 initiative, is already handled by an existing team. From the very beginning we are feeding all incoming owner data into their data lake, and then siphoning the data we care about off of that into our own transactional systems. Important point here is that analytics should be happening from the very beginning, so while phase 3 is logically a separate phase, it is occurring in some capacity throughout the entire project. As a quick follow up post-phase 2 (getting more data), it will be critical to have a burst of effort in analytics, by working with a team of PhD-level data scientists to play the big data cauldron stirring game. At this point we will have access to our existing consumer data, new consumer data retrieved in phase 2, among data captured through other projects going on at this time, such as individual part SKUs and serials tied to manufactured products. All of that data can be poured into a giant cauldron, and it is statistically impossible that we won't learn something valuable after performing the actual analytics (I won't get into R queries here). It is at this phase where a lot of hypotheticals come up, and we can begin gaining some insights that we previously didn't even know were possible.

    Phase 3.2 here is where things really get fun. We're utilizing our data with more mastery, and now we're learning more about our product, our owners, and how the two work together. With the insights from phase 3.1 we're asking better and better questions, and now it's time to act. With our new insights in hand, let's change the business in fundamental ways. This goes way beyond simply marketing to consumers better, such as identifying brand history as it relates to average household income in a consumer's neighborhood and tying that to likelihood they'll respond to a phone call or an email to upgrade their appliance; this is more of answering the question "should we even manufacture a product that has this mode?" or finding that a particular batch of parts put into a series of SKUs is 20% more likely to fail in the next three months, so we should ramp up service capacity in preparation and send out communications to the owners to inform them of the proper procedures to follow if they experience a problem. These are all things we can't do today. The momentum of the successes of the project should provide the inertia required to uproot long-held (50+ years) business practices. It will be one of the first times in company history that IT will be driving massively disruptive changes to the functions. In my opinion this is the absolute end-all-be-all must have metric of Consumer 360 success. The team will get a lot of kudos and celebration with completion of phase 1, but that ultimately is solving something that we should have solved a decade ago. With a successful phase 3 we go from market contenders to superior market leaders. We don't guess what features our consumers will want, we authoritatively know what they want, when they want it, and how best to communicate to them about their wants. When they call, we know what they are calling about and know how to address their concerns immediately. Decades of "that's the way it's always been done" get blown out of the water, and new processes and procedures are introduced to reduce cost, increase quality, and make employees and consumer's lives much easier. That's what Consumer 360 means to me and my team.

    Docker: From Months to Minutes

    Here is a video of myself and Tom Barber presenting at Dockercon 2015 in San Francisco about how GE utilizes Docker to manage its environment.

    Many business problems are actually easy to solve

    I feel as though I've worked on enough projects that I can definitively declare that a few certain processes work, and others don't. For instance I know--for a fact--that teams are more efficient when they are co-located. I know this not only because I've seen it work internally, but also reports that it works, and other successful companies (that we want to model ourselves after) stating that it works. So the "problem" statement is that we're not maximizing team efficiency. The proven (perhaps partial) solution to the problem is to co-locate the teams. However I haven't seen co-location actually happen across the entire org, because it's simply perceived as too complicated of a problem to face. The reasons for not tackling the issue are various, but fairly standard:
    "That's just not how we're modeled!"
    "People don't like change and that's a lot of change!"
    "What about process x, y, z, q, etc?"
    "We'd need to run every number and report about how this would effect variables a, b, c."

    Effectively what business does is become so risk adverse that they ensure that they can't improve or innovate anymore. We fall into this comfortable mediocrity that allows us to just assume that the way we're doing it is the best way because otherwise we wouldn't have started this way. We become biased. This bias in effect is a cancer on any organization: business or otherwise. Enforcing biases limits our scope, and--I think Orwell would be with me here--limits our thought as well. It puts us in a box.

    Businesses always say they want to act like small startups. "Startups are cool! They get things done! How do they do all that so fast?" We say we want more innovation, faster innovation, increased velocity. Of course what you actually see is a bunch of panicked employees working longer hours, only to run against the same barriers they already had. Resources become even more stretched and you start seeing employee satisfaction plummet as they realize that they can't make the business happy.

    "So what about this whole "easy" thing?" you ask. How do you solve that? It really is as simple as not assuming your way is the right way. It's about riskier behavior. It's about saying that even if we don't have a concrete solution in mind, we know that our current process or org is sub-optimal and we're going to just try a new way of doing things, recognizing that we could be completely wrong.

    Let's take my earlier example about co-location. As a business we want to increase our team efficiency, and we're pretty sure a good way to do that is co-located teams. We have global employees so it makes it difficult. At this point it's as simple as holding a workout session for a day with leadership and running through all the possible ways to try to make it work: redefining team responsibilities, getting webcams so remote employees can still be "in the room", completely blowing away the org and redefining teams so that members of a team are always geographically in the same place; now pick one or a mixture of a few, and then go do it. Seriously, just go out of that meeting and do it. Make an announcement that there's going to be this massive change, and it might suck, but by golly we're going to try it and see if it works. Then, we're going to find the pros and the cons of the change, and then change it all up again next month. Keep up this rapid iteration cycle until you get to a good state--and then keep changing. Over time the changes get smaller and smaller because theoretically you're making sound decisions that are actually working.

    And then something happens. An assumption you had at the beginning of this initiative breaks. Maybe a business requirement requires that your organization suddenly support this whole new thing that you're not prepared to support because of your current structure. Everything's gone wrong! Panic!

    But don't, because this is actually easy again: it's time to pivot. Take whatever piece of your solution is or will be broken by the change of environment and throw it out and re-do it all. Seriously. All the time and effort is now sunk cost and you have to lop it off. By the way, the pros at doing this is Google. They'll take something that has cost them millions of dollars and hundreds of thousands of man hours and huck it out the window--even if their user base likes the product! What?! Think of your company doing that: taking something customers actually like and just murdering it because that it wasn't conducive to your longer-term success. Brutal, but it works!

    By constantly shaking your assumptions of your business world, and through rapid improvement you see shorter cycle times and then a miracle occurs: your business gets better at making changes. Suddenly every week, every day even, something will change for the better. A new feature on an application gets added, in a day, because you're used to making changes!

    This all requires a fairly substantial paradigm shift on the part of literally everyone in the organization: CEO to Jr. Analyst. And what's more, there's a few prerequisites as well:

    1) You have to hire and hold smart people. Yes, that means you may have to offer higher salary packages to attract those people.
    2) Trust these smart people. This means removing barriers from your employees and opening yourself to risk. Sure, technically, if you have these eight approval steps before someone can push code to production you're getting 6 Sigma levels of removing risk, but you've also taking something that should only take 5 minutes and turned it into a month long nightmare. Which, by the way, means that your smart people you're paying all this money to are not only being less productive, but they're probably pissed off about it too.
    3) Embrace risk. Like point #2, you're going to have to change your process. This should be easy if you're following the message of this blog which is to stop being so biased. Remove barriers for your smart people to do their jobs, even if it means you might get burned. Then, if you do get burned, find out what happened: was it not actually a smart person but dumb one you hired? Find him a new role or cut your losses. Was it actually a process oversight that should be addressed because we absolutely cannot afford to have this problem again? OK, now add in a barrier. If you can intelligently and objectively determine appropriate barriers for risk at the beginning of a process then all the better, but you should constantly be evaluating those barriers and go back and remove them where acceptable.

    Even still, with these prerequisites, and all of this paradigm changes, this is all still very very easy to do in any business environment, you just need the gumption to shake the modus operandi up. You have to tell yourself "let's just do it." Just go, just try, worst case scenario you've managed to make things worse in which case you just go back to the way it was. That's the beauty of the philosophy behind not being biased, is you can always say "oops, nevermind."

    Organizational Approach to High Priority Initiatives

    This is a short whitepaper I've whipped up for General Electric, but I like the message so I'm posting it here for public consumption.

    The purpose of this whitepaper is to explain the current environment within General Electric and propose arguments why it would be beneficial to The Company along with Technology and Services to organize the creation of a "SEAL Team" consisting of four or five highly specialized members capable of being applied to virtually any problem given a specific time frame drive to completion of the goal.

    The Birth of the SEAL Team
    "President John F. Kennedy, aware of the situation in Southeast Asia, recognized the need for unconventional warfare and special operations as a measure against guerrilla warfare." (1)
    The nature of modern warfare had changed after the end of World War II. No longer was trench warfare between two behemoth military complexes the norm. Small, lightweight battles were seen, engaged, and run to completion within the minutes and hours, not the days and weeks. We see a similar shift in the approach of problems internally to GE, and, indeed the entire Information Technology paradigm.

    The "New" Paradigm
    The paradigm of technology in the past decade is changing much like the warfare paradigm changed around the Vietnam War. This change is manifested in the speed of battles (or initiatives) and the organizational makeup of the military force (or teams). Guerrilla warfare ("little war" in Spanish) is made up of small groups of individuals utilizing military tactics in order to achieve a small objective (plunder a camp, assassinate a target, etc). The term "guerrilla" was first used within the English language as early as 1809. However, Guerrilla warfare can be traced back to Sun Tzu in his The Art of War (6th century BCE) Some authors argue that his example directly inspired the development of modern guerrilla warfare. (3)
    Similarly, within the IT space, we have seen a shift from large, leviathan forces (ERP excluded!) and technology stacks to smaller, quicker, lightweight implementations. Within GE we considered the adoption of PHP as one of these "contained" initiatives; where there wasn't a lot of bureaucratic overhead around the technology itself; TAS simplly "let" the business utilize a common PHP stack in their own environment to achieve their goals. Technology is changing at an increasing rate (something all talking heads have been babbling about forever), but just to visualize it, here is a Linux distribution timeline (the beginning being 1991).

    The knowledge required to understand every line in that graph is shocking. This graph is only displayed as an example of the shift in number individual solutions available to the market. Similarly there are similar data points in every domain that we at GE care about: mobile apps and OS's, web technologies, storage capabilities and data structures involving NAS, SAN, Hadoop, Vertica, NoSQL concepts, etc. Each new technology addresses a particular need, but the ability to fit it all together*and then use that knowledge to address future problems*is a daunting task. Each new initiative is (typically) no longer about large changes which effect every facet of technology and our day-to-day MO's; but rather we have a series of encapsulated problems, which while the decision of which technologies to utilize is extremely important, it becomes less important as many technologies play together well when architected in a way where the control and governance mechanisms are more abstract and holistic.

    The SEAL Team concept is not new internally at GE. In the past we have utilized the concept of a highly knowledgeable, 100% dedicated team coming together to solve problems. The formation of these teams is typically temporary, with at most one or two of the members staying to handle capacity requirements after the initial objectives have been completed. I personally have been involved in multiple SEAL initiatives which have usually been an enormous success and completed with no budget other than the usual cost of employee rumination. As an example, here are just a few of the internal SEAL-type initiatives that we have internally performed as an IT organization:
    o IT Asset data collection (found the majority of computer assets in the organization)
    o Project Transformer (mobile POC which paved the way for GEAppliances iPhone app)
    o NewFi (revolutionized the way service technicians service Mission 1 appliances)
    o Mobile Scanner app for M1 products
    o Mission 1 Tiger Teams
    o GE Cloud
    o Black Friday capacity and testing initiative
    o Superbowl preparedness
    o XMPP (Nucleus effort)
    These are even only the initiatives that immediately come to mind, and within the past few years. Each would have cost a lot of money and time to outsource, and we had the internal resources necessary to handle the initiatives in-house. It must be noted that even though these initiatives went well, there was still a catch up time for the members to "meet" each other, agree on roles, and begin to work in harmony. With a dedicated SEAL team, this warm-up time is unnecessary, and allows for the team to hit the ground running.

    100% Dedicated
    The SEAL Team must be 100% dedicated to the initiative at hand, as this is critical to the entire concept of the team. SEAL Teams in the military may have multiple objectives during a particular mission, but that mission is still for a fixed timeframe, has very specific goals, and is in a single geographical location. Likewise an IT SEAL Team may have multiple things they are trying to accomplish, but they would all have one fixed timeframe, specific CTQs and deliverables, all for a single overarching initiative.
    Justification for this is the same justification the military uses. Highly specialized, dedicated groups of individuals when put into a close-knit team where they eat, sleep and breathe together learn to act as a single entity; and when that force is correctly applied to a single goal, there is a great chance of success.

    Organizational Makeup
    The decision of who becomes a SEAL is a critical decision as the SEAL members will be put through high stress situations and be critical to the success of Category 1 initiatives. The highest priority items which will dictate the success of GE will be in their hands so it can be no small step to become a SEAL member. The military approaches this from a similar standpoint:
    "SEAL training is extremely rigorous, having a reputation as some of the toughest anywhere in the world. The drop out rate for SEAL training is sometimes over 90 percent." (1)
    Internally within GE, the members of the SEAL team should be voluntary. Allow all members to apply for SEAL team membership. Then put them through a rigorous testing process and weed out all those who do not meet the cut. For the first team, key architects and executives should own and operate the screening process. This screening accomplishes two things:
    1) You are ensured the highest level of quality for the members of the team
    2) Other individual contributors in the business don't see the SEAL team members as "Ivory Tower" workers, who loaf around, not contributing.
    Another thing critical to the success of the SEAL teams is geographic proximity. This is quite possibly the biggest political detractor within our organization, but it has very real consequences. The SEAL team must be in the same physical location. There could arguably be one exception per team, but out of a four or five man team, all but one must be physically together at least in the same building, preferably in the same room so that they can always have quick access to each other as they will all have different skillsets each of which is critical for operational success. Of course to combat this, we could argue that each location need its own SEAL team simply shuffle the size and members for locations we deem non-critical; and allow the SEAL leaders and champions to facilitate the communication between SEAL teams, allowing them to all act as a single unit when required.

    Rotation of SEAL Resources
    Eventually SEAL members will wish to roll-off, or leave for other opportunities, so the makeup of time plays a critical role into the team's success as well. There must be processes in place to immediate backfill members who may leave the SEAL team; in order that the team may get back into the "one-mind" method of operation as soon as possible. Of course, as in the military's special groups, operatives don't stay in the field forever. There must be a plan for retirement from SEAL teams, which could be accomplished through a few mechanisms:
    o Have each SEAL team for a pre-determined amount of time
    o Each member, upon acceptance signs a contract for three to five years to work on the SEAL team. At the end of that time served they have the option to "re-enlist", or return to "normal active duty"
    o This approach also allows for the creation of a new team a year or two prior to the old team being disbanded, allowing the new team to get up to speed before the old team rolls off, ensuring a constant internal capacity.
    o Have a rolling team with rolling members
    o Harder to accomplish due to the fact that more processes must now be put in place to handle knowledge transfer between old and new team members, along with the financial and political problems caused by backfilling.
    o Team dynamics will naturally suffer because the team now has a little more warm-up time getting to know each other and how each other operates.
    Life after SEAL
    The CIA's highly secretive Special Activities Division (SAD) and more specifically its elite Special Operations Group (SOG) recruits operators from the SEAL Teams. (1)
    It stands to reason that a member who completed a successful SEAL stint would be looked at as a role model within the organization. These members should advance in rank either up the technical or leadership career paths. While this is not an avocation for automatic promotions, the mark of an IT SEAL should be seen as a tremendous boon which would boost an employee's EMS ranking and put them in line for more important duties going forward.

    Operational Duties
    Just as the purpose of the military's SEAL team isn't to "occupy Iraq", the purpose of the IT SEAL team is not to "implement ERP." The SEAL team must be available for small-to-medium sized high priority initiatives at a moment's notice. This may mean that the team does not have a "hopper" of initiatives lined up to constantly work on. The team may be idle for a good chunk of time throughout the year. However during this time they will be responsible for many critical aspects which constitute a good team:
    o Continuing training in all aspects of business process and technology
    o Learning to work together as a single unit through activities, events, and challenges
    o Following up with old initiatives and capturing any lessons learned that they can apply to the next initiative
    From an actual SEAL team operative: "There is no typical "day at the office" for a Navy SEAL. SEALs constantly learn, improve and refine skills working with their teammates. Their office transcends not only the elements of the Sea, Air, and Land, but also international boundaries, the extremes of geography and the spectrum of conflict. A SEAL's day usually includes physical training to ensure he is kept at a peak fitness level as well as whatever training or operations that are required of his particular unit." (2)
    Politically this is the most critical of concepts which is that the SEAL members may be doing "nothing" in the eyes of their fellows. This must be managed from both a top-down and bottom-up approach.
    Top-down: Senior leadership must continually be bought in to the value that SEAL teams drive, and communicate that value to their teams. Team members will not usually be directly helped by the SEAL teams, but will themselves assist the SEAL teams. Leadership must always communicate the wins of SEAL teams and their initiatives to drive positive perception.
    Bottom-up: There must be a desire to be a part of an elite group such as a SEAL team. Such a desire will naturally foster an element of respect for members who can make the cut to become a SEAL. The rigorous testing and screening procedures outlined in an earlier section will be a part of this, but there can be other "good-will" things the SEALs could do to place value at the individual contributor level such as assisting with the spin up of a new environment during a severe downtime. Such decisions would be left to the leader of the SEAL team, or the commander.

    Agile Mindset
    The introduction of Agile certainly stirred up quite a pot, and began the process of many organizations beginning to question how they were structured organizationally*and how they approached initiatives and problems. An (un)intended benefit of a SEAL organization is the ability for that team to approach problems utilizing a pure agile approach; bringing the benefits of agile to a large, complicated organization. SEAL members would be trained in agile and SCRUM/Kanban, and bring that mindset and pack of tools to each objective they tackle. The agile approach also allows for quick updates to staff and other stakeholders on a weekly or biweekly basis at the end of each sprint, and allows for leaders or even internal team members to assist in the prioritization of the next sprint's stories and objectives.

    The Commander's Duty
    In the military's SEAL teams, there is a large organization that supports a core group of operatives.
    Each SEAL Team is commanded by a Navy Commander (O-5), and has a number of operational SEAL platoons and a headquarters element.
    A SEAL Team has a Staff Headquarters element and three 40-man Troops. Each Troop consists of a Headquarters element consisting of a Troop Commander, typically a Lieutenant Commander (O-4), a Troop Senior Enlisted (E-8), a Targeting/Operations Officer (O-2/3) and a Targeting/Operations Leading/Chief Petty Officer (E-6/7). Under the HQ element are two SEAL platoons of 16-20 men (two officers, 14-16 enlisted SEALs, and sometimes assigned non-NSW support personnel); a company-sized Combat Service Support (CSS) and/or Combat Support (CS) consisting of staff N-codes (the Army and Marine Corps use S-codes); N1 Administrative support, N2 Intelligence, N3 Operations, N4 Logistics, N5 Plans and Targeting, N6 Communications, N7 Training, and N8 Air/Medical.
    Each Troop can be easily task organized into four squads, of eight 4-5 man fire teams for operational purposes. The size of each SEAL "Team" with Troops and support staff is approximately 300 personnel. The typical SEAL platoon has an OIC (Officer in Charge, usually a Lieutenant (O-3)), an AOIC (Assistant Officer in Charge, usually a Lieutenant (junior grade), O-2), a platoon chief (E-7), an Operations NCO/LPO (Leading Petty Officer, E-6) and other operators (E-4 to E-6). The core leadership in the Troop and Platoon are the Commander/OIC and the Senior Enlisted NCO (Senior Chief/Chief). (1)
    Within GE's organization, we can attribute the entirety of IT (and even potentially outside of IT if the initiative require it) as support for the SEAL team. For instance, if it comes to pass that during a critical operation the SEAL team requires the Compute team to spin up an instance of Oracle Linux then we should be able to count on TAS to support that decision, and make the spin up of that instance top priority for resources on that team. It is the duty of the commander of the SEAL team to ensure that these support lines stay staffed, and that engagement of the various teams and sections of the business are top-notch.
    The key duty of the commander is to keep the SEAL team engaged on their initiative. The commander must ensure that the SEAL team is maintaining 100% dedication to a single initiative, and no other. If a higher force in the business comes down and demands the SEAL team's presence then the commander must be sure to handle these priorities, and if the new priority takes precedence over the other then the team must drop everything they are doing for the other priority and focus on the new one. The commander must be sure that outside influences don't affect the work of the team, and allow them to operate as they should.
    The commander must also not be present during operational activities outside of status checks and normal operations such as in the Agile approach to problems, the end of a sprint and the activities associated with it. In other words, the commander should never be in the weeds with the SEAL team operatives, and must allow them to operate on their own as an autonomous unit while at the same time providing an umbrella to shield the unit from anything that would hinder their goals.

    Action Items
    "Well, I'm on board," you say. Let us now consider the practicalities of a SEAL team, and how we might go about creating this internal capacity. Our approach is divided up into a few sub-groups:
    o Recruiting members
    o Finances
    o Political cruft
    Recruiting members
    As stated earlier, entry into a SEAL team must be voluntary in most cases (in a true emergency, conscription is perfectly valid). This provides soft benefits of knowing which individual contributors are looking for a new challenge in their jobs, regardless of whether or not they pass the screening process. After rigorous screening, we can decide on the team of four or five members and begin the on-boarding and training processes for the team.
    Possibly the most daunting of challenges, employee remuneration will measure ~1M a year; which will be difficult to justify when it is possible (as stated) that the team may have a "large" amount of downtime. We must use previous precedence and constant "wins" to justify the expense. There is of course another benefit here which suggests that we are investing in our employees as well. Also to be considered here is the pay of the actual SEAL members themselves. As the SEAL organization is of the "one body, one mind" philosophy, great care will need to be taken into what the members themselves are paid; as the comradely of the members increases, we can expect salary to become one of those topics which is discussed, and all SEAL members are equally valuable to the organization.
    Political cruft
    This must be attacked*aggressively*from the very beginning. Any individual which is on board with this initiative must pass along the value of such a team at any chance they get. If the creation of the team goes ahead then every champion for the team (those besides the team "commander") must constantly be communicating the wins from this team at every chance they get. Only after a few years of proven success will the team be looked at as a true value-add.

    I hope the case has been made for the creation of a SEAL team, or at the very least some form of dedicated internal capacity to handle emergency issues and initiatives as they arise. The cost when you compare it to other initiatives that are underway is extremely minimal, and the benefit is very high. I encourage those that are bought in to this initiative to talk about it openly in internal forums and private discussions, and communicate that feedback to the author or other champions you may know of.

    Naming Conventions
    What is a SEAL team named internally? SEAL stands for Sear, Air, Land Teams but perhaps that name doesn't translate well internally. While not critical, it is entertaining to come up with a few possibilities:
    Special Information Technology Team (SIIT)
    Information Technology Tiger Team (ITTT)
    Software, Process, Infrastructure Team (SPIT)

    (1) Wikipedia article United States Navy SEALs http://en.wikipedia.org/wiki/United_States_Navy_SEALs
    (2) FAQ of SEAL members http://www.sealswcc.com/navy-seals-frequently-asked-questions-faq.aspx
    (3) Wikipedia article Guerrilla warfare http://en.wikipedia.org/wiki/Guerrilla_warfare

    What is good in tech these days

    Given the somewhat dreary nature of my last blog, it would be nice if I talked about all the things that are right in the technology landscape. I had the pleasure of being one of the 6000 developers attending Google I/O this past week; and as Google is one of those companies that likes trying new things and seeing how they work after the fact (a style I'm very fond of and I've heard referenced as "Ready, Fire, Aim") I was excited to see what they had in store for the world this year.

    Fortunately, I wasn't entirely suprised by the more major announcements. Project Glass was the major reveal that us HUD geeks have been salavating over for the past few decades. The reveal at the first day's keynote (video: http://www.youtube.com/watch?v=D7TB8b2t3QE) was obviously widely talked about, being arguably one of the best consumer product introductions ever put on. Glass is turning out to be one of the most hyped products ever, and it is still around a year (or more) until expected release. Which actually is good timing for the next critical item in the upcoming Google tech stack which is...

    Google Now. Now is a new service by Google basically promising to target the functionality of Apple's Siri. Siri being based off of Wolfram Alpha for its logic, Google so far is using proprietary voodoo magic to provide quite possibly the most frightening--and helpful--bit of technology ever: intent. Google will take everything it knows about you (sports team searches, Google Plus +1's, travel history, GPS data, etc) and perform extremely complicated analytic processesing on that information, and then provide important and pertienent information to you when it is needed. For instance, lets say each day around 5 PM you go home via I-65. Google knows your typical timing of movements, and they know the route you take, so 4:45 PM Google Now will display a card showing the traffic to your house, and suggest alternate routes should something be wrong with your normal one. These two points are interesting when taken together because as Google Now gets better at predictive analysis, and the hardware is spec'd out appropriately for the Glass, we see a magical merger of two technologies when taken together makes everyday life that much easier. I would expect with the small display for the Glass (however exactly it works is still a secret), you will need to present very limited data on that real estate. If you take predictive analysis, and intelligently determine which information is actually important, you've suddenly created a way to maximize benefit and minimize useless cruft. I am extremely excited about these two technologies and their effect on everyday life.

    The rest of the conference didn't turn any worldview I had on its head. There were some valuable talks about design, and a few things to learn about organizational manipulation and how to compare organizational environments and weed out good and bad practices. Something that has definitely stayed with me is the notion that if you treat someone like a child, they will act as a child. Conversely if you treat individuals like adults, they will (usually) behave as such. Paraphrased, this means don't wall in your garden and put up unnecessary artificials boundaries. People that you lead in an organization do not need to be micromanaged, or be restricted. Instead enable your employees and co-workers to be more efficient. If you remove boundaries you can expect a much better return on your investment.

    I don't have a lot more to share on the topic of I/O. It was certainly worth the trip across the country to be in what I would consider the heart of technology. Google as a company has many new technologies that are pretty exciting, and a few potentially earth-shattering. In typical Google fashion I expect the first releases to be buggy but generally an improvement over the existing tech stack. As time moves on I expect Google's philosophy and devices to become an even greater part of my daily life. That said, it certainly feels as though Google does not have all the answers. Some of their services simply seem average, and not particularly impressive. That's OK of course considering almost their entire line of product offerings are relatively new, and in new markets. I am excited to see what they do going forward.

    How Oracle ruins job satisfaction

    Oracle. Now that's a name that strikes fear into the hearts of many an IT architect (unless of course you are an Oracle architect). ERP. Now that's an acronym that strikes fear into the hearts of company accountants. Both of these together make me realize that Harvard Business Review and CIO magazine are forces to be reckoned with; and that these imagined, arbitrary benefits are very hard to realize, and can also have more hidden negatives than they do positives. I will attempt to detail some of my problems with Oracle and ERP-type systems, but realize that I am not suggesting that Oracle is a bad organization or ERP systems are a bad idea for companies; it is simply the case that I see the same things in Oracle products and ERP as I did with the big outsourcing craze years ago: the quality is often suspect, the benefits exaggerated, and there are always hidden "costs" that aren't realized or accrued until years--if not decades--later. So sit back and let me try to take you through my thought process, I'm sure it will be a fun ride.

    Let's get the nit-picking out of the way first
    First I want to get all the petty, stupid junk out of the way. You know, that stuff that isn't in any way intellectually satisfying, and can't really be applied in any other way than to be childish complaints. With that said, let's get going!

  31. Oracle contractors are outsourced and I don't like it
    First off, by "outsourced" I don't mean foreign. I work with some Indian and European teammates, and they've gotten me out of so many jams, I'm quite sure I'd be fired by now without them. I was even landlord to a wonderful friend who had to move back to India to be with his wonderful wife. My life is changed for the better thanks to him. In this case "outsourced" means Oracle went out and purchased their talent, gave them a quick bootcamp on whatever product they were to become "experts" in and threw them out into the field. At least that is what it seems like. My team has performed more work and gotten more knowledgeable in the Oracle products than the Oracle consultants that have come in to install and configure these products. Granted, after a month of failed implementations, and complaints from management, Oracle finally sent in some experts who got the job done; but the fact that those tens of thousands of dollars were spent on sub-par expertise leaves a bitter taste in my mouth.

  32. Everyone businesses are hiring to take care of Oracle / ERP matters are getting better pay and benefits than the veteran employees.
    This irks me like I'd imagine it would irk any professional. In America it is explicitly taboo to talk about salary, benefits and the like. I disagree with this practice for various reasons, but I certainly understand why corporations discourage the practice. The professionals I work with become privy to the information as to what these new consultants and direct hires are receiving for their Oracle / ERP expertise, and the result is indignation and resentment. Even when those coworkers are performing the same work and working at the same level as these new individuals, their relative compensation is much less, and it makes these professionals feel less valuable. This actually goes further beyond pay and even into perceived value of employees from the business--as these new ERP experts are receiving all the attention and guidance from management, leaving the existing professionals to participate in whichever way they can.

    Like I said, petty complaints which I hope are very specific to a few limited organizations, and they don't have any real implications except where detailed later in this blog. It's also a bit immature, but never let it be said that I'm not honest with everything that I'm contemplating.

    You don't need to purchase ERP
    I don't know how Oracle did this (if I knew I'd be a lot better off I'm sure), but they managed to practically trademark ERP. You hear ERP, you think Oracle (or perhaps SAP!). That's marketing. However, ERP is not a purchase, ERP is a series of processes, governance, SI's, etc. I actually like Wikipedia's definition: "Enterprise resource planning (ERP) systems integrate internal and external management information across an entire organization, embracing finance/accounting, manufacturing, sales and service, customer relationship management, etc. ERP systems automate this activity with an integrated software application. Their purpose is to facilitate the flow of information between all business functions inside the boundaries of the organization and manage the connections to outside stakeholders." (link)

    Oracle sells ERP as a thing which addresses every aspect of your enterprise, but the gaps are so large and so numerous that you'll still be customizing your development, and determining your own process so that you can handle the cluster that is the Oracle suite. A thousand purchased 3rd party modules that Oracle attempted to mash together and slap their logo on doesn't address all the needs of a Fortune 10 company. I'd be surprised if they could address a Fortune 200 (disclaimer: this doesn't mean Oracle and ERP are worthless, I need to keep iterating that).

    This brings me into my next point: a very alarming trend that I am seeing is the substitution of definition of two words: process and technology. During a conference the other day the discussion quickly led to a need for some kind of governance around an Oracle product (SOA if you were interested) and the absolute first thing that was brought up is that we should purchase a new technology module that Oracle offers that is supposed to address our governance needs. Governance is a process. Technology can enable these processes, make them quicker, better, slower, more or less bureaucratic, etc, but it is never a substitution for process. The concept that you can purchase governance (and not a governance tool) is a very misguided one that will ensure that you spend more money than you need on products that you will either not use, or at best use poorly. Despite the direction of many businesses around make or buy (and the overbearing direction towards buy only), governance is something that cannot be bought. Each team/group/body needs its own set of governance that it must generate itself and with the help of management. It is an organic approach, and while you can purchase consultants who will tell you how to rightfully govern and create process, purchased services cannot govern for you so long as you hold employees on your payroll.

    What does the future hold?
    What happens a decade from now, well past the MTBF for most of the machinery that we are installing this software on? I see a few potential scenarios that could unfold, depending on how many CEOs get sick of seeing inflated IT budgets with little operational benefit.

    Organizations are purchasing previously organic work as a service, which disenfranchises existing workers. This is not a problem in itself (because if it were then standardization would be a bad thing), but on a grand enough scale (i.e.: when all important work is completed outside of organic methods) you create a large rift between leadership and individual contributors. When you discourage organic growth, and treat employees as workhorses to push out these prepackaged solutions, the result is that they feel worse about their jobs. Sure, maybe leadership isn't communicating their vision as to why Oracle contractors and ERP experts are descending like locust on your campus; but honestly even if the communication was impeccable, people don't see individual, personal value in the business saving $X / per year or whatever arbitrary figure was thrust in front of the CIO/CEO by some Oracle salesman or magazine. I've seen plenty of TED talks and other research that suggests that employees need a reason and justification for their work more than they need salary. Oracle and other (major, enterprise) purchased solutions remove that personal justification for the individuals responsible for their installation and development. I cannot see organizations that perform this way retaining their top talent. Sure, they'll be able to hire any old "engineer" which can read a spec sheet and comb through documentation to install whatever new module is required for this quarter, but they're not going to enjoy it, and they will only be doing it for the paycheck. The innovators: the Bill Gates and Steve Wozniak's of the world aren't going to stick around in that type of environment, because it is not intellectually stimulating, it is simply too dull.

    Is there a point to all this?
    Short answer is no, not really. I really want to simply put these thoughts into "print" form so maybe 10 years from now I can look back and see if my predictions rang true. Maybe if they do I can send out a few emails full of red, size 72 font with "I told you so" a thousand times to a few people.