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

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...

Let's Get Moving With Software Development!

Recently I was reading a discussion on Twitter about software projects, and it reminded me of something. Many years ago I had a conversation with my dad about moving. After just having moved, he wasn't too pleased with the moving experience. He mentioned that there was essentially two models that movers operated under. The first was you paid a fixed price for the move. I don't remember the exact details, but the movers quoted a price most likely along the lines the square footage of the house, or some similar metric. The other model, was simply to pay the movers for their time. If it took them 20 hours to complete the move, you paid for those 20 hours. Now the catch was, as he described it, if you paid for a fixed price the movers didn't really put a lot of care into the move. They simply wanted to get the job done as quickly as possible. I seem to recall that if they broke something, they would reimburse you. However, that wasn't a pain free process. More importantl...

The Cost of Meetings

Meetings ... love them or hate them they are a part of everyday business life. I've had multiple bosses that detested meetings, saw them as a waste of time, and would dissuade us from having them. On the other end of the spectrum I've worked for organizations that had countless meeting, many that were of little relevance to me, and left little time in the day to accomplish my other duties. In this posting I aim to examine the cost and benefits of meetings, and also touch upon what it takes to have effective meetings. As someone that has worked as a software developer, team leader, and manager of developers over the years, I'd like to think that I've seen the good and bad side of meetings. Let's start first with the cost. Everyone would agree that a 1 hour meeting requires at least an hours worth of time for everyone that attends. Add to that the need to break ones focus from what they were doing, and regaining that focus after the meeting, you may even raise that ...