Skip to main content

Productive forces

Software development methodologies have evolved significantly over the past several decades. They once involved a lot of upfront, detailed planning sometimes taking more time than actually writing the software. Today the focus is on building software in small increments, in part to quickly validate assumptions. While some level of planning does occur, we assume less and validate more. When done right, it focuses on maximizing value and as a result eliminates waste.

Another significant change is a shift from top down, command and control style project management, to self managing teams. Teams work with a product owner, and in many ways are equals in terms of suggestions and ideas on how improve the product. While the product owner most often has the final say, it is considered a collaborative effort. For best results both parties need to work together to form a cohesive unit. This in stark contrast to the team simply following orders from above.

The need to be able to deliver software frequently and efficiently has led to a need for better engineering. In order to support continuous delivery, code needs to be testable, processes need to be automated, and systems need to be properly abstracted in small interworking parts. All of these needs increase the bar for engineering, and in turn increases the demand for highly skilled developers. 

To put it in real terms, in order to create a successful business all one needs is a vision, a skilled dev team, and a small number of supporting staff. According to Bloomberg WhatsApp had a company of 55 before they were sold to Facebook for $19 billion. Out of the 55 employees, 32 were engineers. While most companies are not in the business of selling software, it does illustrate that order to create great software you don't need much more than great ideas and a great software team.

In my observations over the past few years, businesses are also slowly coming to this realization. Skilled software developers are highly sought after, and wages are reflecting this. Another observation is many teams don't have traditional project managers, analysts, etc. Great leaders and visionaries are still highly sought after, but in terms of numbers the supporting cast seems to getting smaller. 

So what does all of this point to? The biggest impact of all of this is that the people creating the product are the ones that are producing the most value. Some of the older structures and methodologies required a larger supporting cast, although that was a result of less efficient processes. While many people were doing great work, a lot of that work would now be considered waste. 

Perhaps another equally important aspect of this is that the team needs to be empowered to make decisions and be allowed to think strategically. This means removing bureaucracy and impediments, and being allowed to focus on what they do best. This doesn't require layers of management and directors at all. In fact it requires little outside of being provided the right tools, work environment, and a clear understanding of the product vision.

Why do I bring all of this up? The traditional thinking was/is that to order to be successful one had to rise the ranks of management. We've already started to see some organizations get rid of the idea of hierarchy. Ultimately we should measure success by the amount of value that one provides. More specifically in the tangible value that your customers benefit from when they use the software everyday. So perhaps it's time for us to evaluate how we think of success. Leaders are of course important too, and we definitely still need them, but leadership doesn't need to come in the form of management. A software team member can exhibit leadership, and by doing so provides additional value.

So let's reevaluate at how we look at things. Slowly but surely organizations are evolving, just in the same way that software development methodologies evolved. Let's recognize this. Perhaps most importantly let's recognize people for the value that they produce, and encourage them to continue to produce that value. We don't need more managers, directors, or executives ... we need more people that produce value.

Comments

Zach Bonaker said…
In referencing management, you conclude that SW organizations need less of "them" and more non-management, value-producing people.

In light of this, I'd like to simply give an open-ended question that both supports--and challenges--your post:


--> What is the lesson in that?
Attila Buturla said…
Thanks for commenting Zach. What I'm suggesting is that value comes from people and the roles that they fulfill; not from titles. I'm also suggesting that there's a lot of room for improvement in efficiency in most orgs, when it comes to how they are structured and run. We've begun to see some movement in this area, but it's still relatively new.

If our goal (as an economy) is truly be efficiency as possible, then we need to look at the areas that can have the most benefit. Unfortunately what I've seen is that many only look at small things while most often missing the bigger picture. (Layoffs, increasing hours, decreasing pay, etc.) It takes both courage and vision to try be bold and try new things, but they can offer the biggest rewards as well.

I hope that answers your question.

Popular posts from this blog

The Retrospective From Hell

Over the last 17 years of my career I'd like to think that I've learned a lot. I've learned from positive role models, from experience of what works well, by studying my craft, and from my own trials and tribulations. However, I believe the lessons that I have learned that had the biggest impact is learning from failures. One such failure occurred at a previous employer. By telling the story of a past failure, we can reflect and see what can be learned from it. No names will be mentioned, no embellishment or poetic license will be will used. As a matter of fact, I will make every attempt to be objective and accurate as possible. The truth of the matter the story doesn't need it; it speaks for itself. Some time ago I worked for a company that, among other things, had a software product. There was a small team of software developers, and someone that acted as the manager of the team. I was brought on board, as a software engineer, to help with the software product as

Value and Quality over Schedules

According to a study by CEB Research, 70% of software projects are delivered on time, but only on 38% meet stakeholder's expectations. In most cases the people that use your software will not even be aware of internal project deadlines. Case in point, think of all of the software the you use everyday. You are rarely aware of what the due date was. However, what you do notice is how well the software does it's job. It's it's of low quality, you'll very likely notice right away. Even if it appears to be of high quality, if it doesn't provide any major value to you, chances are you still stop using it. With that in mind, then why do many software projects today have a set scope and a hard due date? When building software for a customer, it's only natural for them to what to know what exactly they are going to get and what is will cost them. That is a very reasonable thing to want to know. Even when developing software internally, there are often similar expe

How to run your IS department

Over the course of being a software developer for the past 10 years, at 5 different employers, I've noticed a reoccurring problem at these organizations. The business leaders simply don't understand what IS does and the value that they can bring to the company. (The one exception being a software consulting company, where IS was their business.) Most organizations tend to see IS in a similar light as brick layers or plumbers. They are simply there to keep things working. Additionally they are there to build what other business leaders have envision. In this analogy the business leaders are the architects, coming up with the grand designs, while the software people are the construction workers, putting the pieces together. What the business often fails to realize is that role of IS is to help the business run more efficiently, increases company wide productivity, and most importantly be a strategic asset to the company. In all of my working experience, the software