Software development is one of the most expensive endeavors a company can add to their portfolio of capabilities. How do you make sure you are getting the right value from the money invested in your team? Are you really getting what you pay for? I look to explore common problems I've experienced in companies of all sizes and provide some questions to ask yourself in order to assess development effectiveness.
Over my time in the industry, I noticed a weird trend. Development was getting more expensive and less results were being delivered. The features I am tasked to work on are increasingly small and inconsequential. People in the sky said development was cheaper and easier than over. The reality on the ground was quite different. As with all vague categorizations, the truth is murky. Both sides had merits and valid points.
Every tool in the development space is becoming open and more reachable. Open source libraries today offer capabilities to new programmers they would have never had access to before. When I got started in development, getting access to a server to practice on was a challenge. Now every platform has free computing with way more capabilities than I ever had. In the past, the cost of deploying these technologies ensured that you really needed to know what you were doing with them. With lower costs today, these technologies are being deployed for solutions that could be built with much simpler tech. And so thus presents a general problem among software developers today. It's easy to get swept away in the latest and greatest when in reality, it's just needs the 'old' tech.
Are you talking about how tech will solve your problems or what problems can the tech solve?
And so the first question. Is your dev team talking about tech or about how they will change your business? I don't mean dev teams should never talk about technology. Dev teams shouldn't talk about technology to non-tech people is more apt to what I mean. Your dev team needs to translate how their technology solutions are going to impact your business and presenting various options with pro's and con's. Unfortunately what is more common is a conversation that goes along the lines of "We don't have X today, we really need <insert language|framework|upgrade|rebuild proposal> and then we can scale to massive piles of money". Crucially lacking is how, why and alternatives.
There is nothing wrong with using cutting edge tech. But one must realize that remaining on the cutting edge has a very high cost. The second question to answer if you want to be on the cutting edge is if it's worth it? Is there something that you really can't do today? Perhaps better phrased, is there something you are working on that has not been done before? Sure, the combination of elements that comprise your business is unique. The underlying components are not. It's perhaps a hard truth to realize that most companies labeled innovative aren't truly innovators but simply assembling and applying existing solutions in new ways. The lack of innovation is so entrenched in the industry that it's become the day to day lingo. Innovators proudly declaring to be innovative and then go on to pitch their product as "The not innovative idea for innovative new market", or "uber for pets". If you're innovative, shouldn't it be hard to explain your product? It hasn't been seen before. Why would people understand it?
Innovative products have to be seen to be understood. Sure, fundamentally the iPhone wasn't that innovative if you look at any individual component. Perhaps even without the iPhone we would have gotten to the spot we are today. But in the original product announcement of the 'smart phone' as we know it today, Jobs kept iterating that it's a "phone, music player, and internet browser" in one device. It couldn't simply be defined as a smart phone. People didn't quite get that what that meant. The smart devices were unwieldy and annoying. Innovation happens when a new idea is cemented into the audience.
And so if you can accept that most businesses are not pushing the envelope, it becomes a question to ask why do you need tech that pushes the envelope? Are you selling e-commerce? That's been done well for over 20 years. Are you building a social network? That was easily doable in the early 2000's. Are you building business optimization software? Welcome to a long history of companies with over 50 years to study from. Older solutions do not always become invalid with new tech. The new tech is for different problems that have now become accessible to the masses. Could your company leverage this? That's up to you to decide if it provides value.
Are you discussing how to improve your product or how to rebuild your product?
Is your product evolving or is there constant rework? Companies will get stuck on reworking the same thing over and over again to get slightly different problems. The word 'tech debt' has become a nails on the chalkboard word for me. It's largely become the go to corporate excuse for not getting things done. Developers see a complex area they are not comfortable to change and go to tech debt. Product people don't understand the product so they cover lack of documentation with tech debt. Tech debt inevitably runs to the rebuild discussion. This will end up with a partially implemented v2 version of the product that is now causing more problems than the original and while some problems might be solved, an equally difficult different set of problems arising.
A rebuild is the absolute worst thing a company can do if they want to be cost effective. A company needs to build value. Value in a software company could be said to be derived from product features. If you keep spending money on the same feature, how much is that going to set you back from new features? Was your product team so far off base on requirements that the system is completely wrong from the ground up? Perhaps. But I haven't seen it yet. Usually the 'core' issues are much smaller than the development teams make it out to be.
Think of software was an investment. The longer it lives, the more chance it can return money. If you develop a new product every two years that replaces the old one, hopefully it's a hardware product you get revenue on. Good companies treat software like an old wooden ship. At some point, all the original wood will be replaced. Is it the same ship? I suppose that's for you to draw your own conclusions. They get a product right, extract value, and only replace a component when it's required or unsafe to continue sailing with it in place.
Are you talking about why your process isn't getting desired results or are you talking about which process is best?
Chances are when you started you had a small tight knit dev team that was shipping frequently and life was good. It was time to scale up and so new team members were added. And then things start to slow down. Perhaps the old original team becomes dissatisfied and departs. New people are brought in to replace them but it never feels like it did in the beginning. Forward progress is being made but at much steeper time, and thus money, invested. The management leans into scrum, the development team makes fun of scrum. The status quo continues.
Discussions start to set in. Developers dislike scrum, they want scrum with no meetings or what they call 'kanban'. And while this might be an interesting discussion to think about, it misses the reality that the team is really doing neither process. Sure, it might have a 'kanban board' or do 'sprint plannings' and 'refinements'. And it's not like those things are bad or wrong to do. They can be quite good when utilized correctly.
What's missing is the discussion of why things aren't working. You can 'improve' any team by simply making them talk more. Then make them talk about the right things and step back and listen. There have been successful companies using just about every process under the sun. In the end, it's the company discussing their motivations and boundaries and then selecting the process that fits. Scrum is probably about the limits for most developers. It allows a high level of dev performance but still provides some time flexibility. As production speed increases, margins for delays and errors get thin. There's a small group of people that like to perform on the edge of the envelope but that's not the vast majority of people. Managing these type of teams require ensuring your players are rested or they will quickly burn out. While waterfall processes have the pace of a baseball team, kanban processes require ice hockey style rotation of players.
A large cultural discussion of what work should be is ongoing. In the tech community the traditional start up culture that is celebrated is often criticized. Getting lost in this leaves opportunity lost. Both styles have their place for different styles of development. In mid to large sized companies, why would one not cater to both? Not everything your company does requires fast paced, iterative development. There's probably some parts you never want to stop iterating fast on. Having a good base of slower paced and skilled work is a great way to identify and grow talent within your organization. For the ones that find they enjoy performing at a higher levels, they have an internal place they can learn from and aspire to join.
Success comes down to finding what people want from a company, what you desire from them and then determining if it's a match. If you're building a company with a great family culture, highly competitive employees might create internal conflict. If you want to build the storied 'top 10%' type of team, adding people that see work as only a paycheck may cause your top performers to feel they are carrying weight. From those constraints, and discussions on where your process is going wrong, you can begin the journey to a productive team that makes everyone happy.
Are your devs talking about your industry or their industry?
What people talk about tells much about that they are focusing on at that point. Developers will always talk about tech. It is their job after all. But do you hear them talking about your industry? Are they experts on your industry? Do they understand the problems of your industry? I've rarely heard a manager that says no to this. "Of course they know!" or so they say. But when talking direct to the devs, only a cursory understanding given by a PM in a planning is known. Most don't know what they are doing or why but taking a set of orders from execs or PO's.
This is never going to work. Okay, never is strong. If you know exactly what you want it might work. Most people don't know what exactly they want. Not even close. Take a moment to picture your dream house? Got a good image? How many stories is it? Does it have a basement? What finish is the bathroom? How many bathrooms? I could ask thousands of different questions about all the decisions that go into a basic house. Everyone that reads this probably also pictured a different house. If a dev only knows to build "their dream house", by the time they get to a delivered product they will deliver a wrong product even though they did exactly as they were told! How dare that bad dev for not reading PO's minds!
Your developers need to be industry experts. The more they know, the more tools to leverage to solve your problems. If they aren't talking about gritty industry problems, they simply don't know your industry. If they don't know your industry, how can they change your industry? Do developers not care about your industry problems? Then they probably shouldn't be at your company. Personally, I like problems. Any problem. Every industry has problems so I love jumping around and learning different domain areas. Some devs want to focus on one or a few specific problems. Nothing wrong with that, just make sure they line up!
To conclude
Start tomorrow by listening. Don't listen to the specifics of what people in your company is talking about. Listen to what they are talking about. Are they talking about the right things?
Once most people are talking about the right things, the inevitable process of iterating to success will start to take form and traction will begin. Well received features will start to generate growth, growth generates money, money can, and should be used more, to reward employees. Incentives and feeling of making a difference make happy employees. Happy employees make great companies.
I know I'm concluding with a soft conclusion. Not very actionable. Could I give concrete process steps to drive down cost? Absolutely. But the techniques I have are for one extreme end of the spectrum. How to make development as cheap as possible? Stay tuned for some more specific posts on this if you're interested. If you try to apply these techniques to existing teams, they are often too large a departure. I personally prefer to build teams around a mentality. It's hard to go against seemingly way more experienced developers. It's easy to just accept the status quo as the best. The key here is to do better each day. Some teams will start more efficient than others. That's fine. Some teams will stop optimizing their efficiency earlier than others. That's fine too. Hopefully these four questions start you on your own journey to optimize your efficiency.