Disclaimer, I am not a millennial, I am in that strange area between generation X and generation Y, being closer to the Y. What does that have to do with the topic, you ask? It puts me in a unique place to watch the struggle of ideas unfolding between the engineers coming into companies, and the engineers / businesspeople running corporations. This is not to say that all current executives are outdated, but in many companies, they have failed to update their model of the world to match increasing numbers of their customers, and the incoming flock of engineers.

The fundamental issue is that people who have had success in the past have a hard time considering that what gave them the success in the first place is not likely to continue producing success. As an example, existing business processes for tracking hours is typically to have each individual estimate ( after the fact ) how many hours they have worked on a specific project on a given day. The current method, as best as I can tell, is for engineers to estimate via points how much time it takes to perform a given programming task and do a post-mortem if the task takes more points. But this daily reporting is eliminated, which is a better, more efficient process. It is also one that revolves around trusting the engineer.

Another example is that it is not uncommon for developers working on a project to push out information about that project to the public via Twitter. Even down to the level of code commits. For the users of that product, they can choose to follow the official company feed or they can decide to follow their favorite engineers. The concept of privacy has been diminished to a large degree in modern companies. The benefit of this is that users become partners, not only in the debugging and troubleshooting process, but also in the development and planning phases. You can find, for just about any startup, engineers posting what features they are thinking about and feedback from engaged consumers, either providing amplifications, their own feature suggestions, or strong negations about where the company should be spending its precious resources. In such an environment, extreme secrecy is a huge liability. Likewise, within corporations, keeping the status of the company, and what the customers are saying about the products from the engineers is disastrous to engineers’ morale, as well as harmful to the level of understanding of the executives as to what is happening within the company. In more modern companies, the developers are treated like the partners of the product managers and the executives.

I think most of the fallacy in this regard comes from the manufacturing metaphors that have dominated the majority of the corporate worlds’ view of software development. When I look at the waterfall method, and some of the organizational structures around engineering departments, what I believe is being attempted is to reduce development to an assembly line with shift managers and the like. This can’t really work for software engineering for many obvious reasons, but probably the most obvious is that programmers, even self taught ones have more in common with lawyers than they do with assembly line workers. Assembly line workers can highly optimize their tasks due to the extremely specific level of requirements, as well as the consistency in their tasks. Developers, and the product people working with the developers, almost never have requirements detailed enough to complete the given task. Similarly, developers have a wide latitude to perform tasks in different ways as tools, managerial practices and or technology change, which is nearly daily at this point. While most manufacturing systems change once every 20 years or so, a particular manufacturing worker can master their skills and have that be applicable for their entire career.

Attorneys are typically highly specialized, and operate with a widely varying set of rules, like software engineers, they need to parse and execute on sets of specifications ( laws ) to the benefit of the person contracting or paying them. Their interpretation of a given law may not always be standard, but if it achieves the intended goal, then they are considered successful. This interpretation in law as in software engineering is more of an art than a science. This variability in going about the job from day to day creates odd management challenges that are being exacerbated for software engineering management as the millennials come into the workforce. To a large degree, having fewer, more productive, empowered engineers is obviating the need for traditional engineering management. Of course someone needs to be accountable, but if you have small groups of developers, the group can be accountable for a specific feature. Small groups of engineers make it easier for them to triage why something went wrong and prevent it from happening again. Failure is part of the software development process, but it doesn’t have to be a destructive part.

Millennials, and their immediate predecessors appear to be very comfortable with dealing with this sort of environment, they do not seem to need clear guidelines or even a clear goal. Many software projects that utilized the “agile” philosophy, which even itself is becoming dated, typically manage the process with smaller tasks that everyone in a company seem to be involved in creating. The new crop of engineers seem to be more comfortable with the self-taught, with it being more about what you can show than what you have done. Resume’s appear to be losing their value relative to a solid portfolio of open source work and products. My advice to people in high-school and college about to enter the work force is to work on a portfolio of applications first, or contribute to some open source projects, even more than attempting to get an internship at some big company. If they can make some money off their portfolio, all the better. The teams appear to be more distributed, with wide acceptance that each individual is working on their own business ideas not related directly to the company’s goals, or product portfolio.

All of these things fly in the face of the traditional command an control structure, however I believe that it will speed the pace of innovation, and improve the overall level of developers. Smart companies will harness this multitasking and openness and provide avenues for their developers to contribute new products under a “labs” or a “demo” banner, even if they have nothing to do with the products that the company makes. These companies will not mind as one of their “labs” projects earns more than their flagship product, and will provide the creator of that product a team and budget to see how far they can go. That will rapidly become the only way to retain talent as the cost of starting a business online continues to drop. Executives at these companies will treat their developers as peers in strategy as well as in the software development lifecycle. It will become clear that this method of structuring a business is correct when not the one, but the many startups offering services begin to completely demolish the incumbents. It is going to be an interesting ride… are you ready?