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

Our Experience With Mob Programming

I was first made aware of Mob Programming well over a year ago. While I've always felt that you can do great work in collaborative environments, I have to admit that at first I was somewhat skeptical of the idea. How could having the entire team work on one thing at a time be as productive as everyone working in parallel?  Having said that I considered myself open minded and am always willing to give something a chance. As mentioned previously, I've had great experiences working collaboratively in teams. In the past I worked on a large team making complex software, and our best work was produced after designing as a group with white boarding sessions and intensive debates about best approaches. I had also worked for a Credit Union, and worked hand in hand with the business to help come up with ideas on how to best utilize technology to solve their business challenges. Only by collaborating as partners were were able to come up with practical solutions that properly addressed...