In 2004, I entered the profession of software development. Working in a small information technology department for a large company; half of my day was spent coding small applications to support our functions, and the other half was piecing hardware together to keep servers running. We actually reported to the accounting department because they depended on us the most. It was the Wild West.
In the years since I’ve worn many hats. Like my colleagues, I’ve experienced the highs and the lows of the profession. The rush of putting an application into production that elated customers. And, alternatively, working countless hours on code to find it fell flat. I’ve held leadership and servant leadership roles where I’ve butted heads with others in charge. Worked with and on development teams that have lost sleep over the fear of failure, and I learned the finer art of customer and stakeholder interaction.
These ups and downs, evened significantly for me when I began iteratively building software; both architecturally and with process. My coding tactics had to evolve, and so did my ability to interact with customers and stakeholders. I became in tune with the business direction, and software was getting to the customer more frequently and with higher quality. Working iteratively with more customer touch points allows for fewer surprises, less dread, and less disappointment. It did also cool the rush I felt getting software to production, but I accept that tradeoff over dissatisfied customers.
There is no doubt that we, the software development community, have come a long way since I’ve entered the profession. The tools we use to develop and deploy applications are significantly more robust, and most companies are working to become more efficient with their processes. I think I can safely say that very few software development departments report to accounting anymore because software has come to the forefront of everything we do.
Even though we’ve evolved significantly over the years, we as a community are still going through hardships. We can still have disappointed customers, sometimes low-quality products, data breaches, long delays in releases and other impediments. There is still much room to improve.
The Next Catalyst: Forming New Expectations
How do we look towards the future and rid ourselves of that disappointed feeling? How do we organize and deliver the next phase of improved products? In my mind, it comes down to expectations. We need to change expectations inside our world and the world around us. Software development is not an exact science where all inputs and outputs are explicitly known throughout development. There are many moving parts, conversations, and decisions being made across a large breadth of an organization as development ensues. If expectations are not aligned, and transparency is lacking, then we risk having that disappointed feeling again.
If software development continues evolving as it has over the past 15 years. If we’re truly innovating and driving for efficiency, then I believe the following is what the future will look like:
Business and Information Technology divisions stop trying to get along because they no longer have to.
In many corporations I’ve been in, there is a strict divide between business units and information technology leaving expectations up to an intermediary force. I picture a future where there are business units with cross-functional skill sets that allow them to meet all the demands of their customers (including software development). The divide between business and IT is spoiling expectations and creating unnecessary friction. We must figure out ways outside of traditional hierarchical structures to remove this divide.
I picture software development teams embedded in business units that are aligned by the value for which they are bringing the customer. A world where communication handoffs aren’t a department or meeting away but the desk right across from me.
We start funding people not resource because people build software.
The software development world changes so fast that, no matter how talented you are, it is easy for skills to erode. Expectations of a person working at a company should be centered on their drive to learn, experiment, and fulfill an explicit purpose continuously.
Traditional annual review processes don’t work in this context. The cycle time from one review to the next is too long to create an environment where people are raising the knowledge level of an organization and the review processes are too often “one size fits all.” There are low budgets to send people to training, conferences, buy them books, and create communities of practice which can leave your organization stagnant and obsolete.
Let’s take salary out of the equation and pay people what they deserve. Then let’s give them the opportunity to grow into the profession no matter how long they’ve been a part of it. It is time to modernize expectations between a leader and a person they are leading.
Vendors are fired when they do a bad job because they are vendors!
I have witnessed many different situations where, for one reason or another, vendors have a complete stranglehold on an organization. Vendors should embrace the opportunity to work with companies not just for dollars and cents but for the ability to positively impact the outcome a company is trying to achieve.
Contracts with vendors are often too explicit with little room for change. This causes bad behavior and often leads to a lack of transparency and organizations getting stuck with a product based on a contract developed months or even years before that no longer match their needs. Expectations with vendors in the future should be that of a partnership charged with transparency, openness, and a willingness to change. If a vendor is continuously underperforming, it should be easy to part ways and find a better fit. If it is a solution that is tightly coupled to a company’s infrastructure than competing vendors need to develop better solutions to replace their competitors.
Customers drive outcomes, not arduous productivity metrics.
There are still many organizations that, in their search to be more predictive in software delivery, implement robust tactics to measure employee productivity. These tactics don’t work because software development is difficult and unpredictable where more is unknown than known. Let’s come to terms with the fact that plans predicated on a date, fixed requirements, and a budget don’t work in our industry.
What often falls by the wayside is aiming to understand what makes a customer tick. Then, when we have a hypothesis, acting on that to make it tick louder. Expectations in the future must shift to outcomes that we can gather data on and have conversations about by getting software quickly to production.
Failing is no longer a bad word.
Some of the most valuable lessons I have learned in my career have been from failures, not successes. These failures have prompted me to go outside of my comfort zone and do things that I would never have before. Expectations should change around failure; we should start viewing it as a positive path towards a continuing journey, rather than hang on to an idea so long that it breaks the backs of everyone involved. We should build in methods to recognize failure and learn from it, not yell about it.
Let’s Get Started
From under the accounting department to becoming an essential part of all human interaction, there are always impediments to overcome in the profession of software development. There are always ways to improve, and it is imperative that you do. I know you’ve been frustrated by divisions between IT and business units, a lack of support to learn and grow, bad acting vendors, arduous productivity metrics, and the pressure never to fail. I believe we can improve these and many other areas by firstly being direct about the issue.