If you're a developer, and you're not planning to disrupt yourself in the coming years, you may be left behind. In a world where business opportunities are being driven by technology, developers who have become comfortable with operating in a traditional software delivery lifecycle will find it increasingly difficult to hide within a big company.
As organizations begin to adopt and scale agile methodologies, developers must be willing to develop and flex a variety of new skills, from effective cross-team collaboration to negotiation skills. The best developers have always had these skills. That's what separated them from the crowd.
Today, though, all developers need to follow suit. They need to be willing to reinvent themselves and disrupt their own worlds so they're set up for what's needed in the future.
[ Explain agile's benefits in an easy way: Read How to explain DevOps, agile, and automation like a golfer. ]
Out with the old role
We all know the maturity model for the traditional software delivery lifecycle: Define the work, ideate the potential technology solution, design it, have its business case approved, then move into the construction phase of the project. That’s how software delivery has always worked, particularly in large organizations that have not yet fully adopted new, agile methods of working.
As we move into new engagement models, the lines between technologists and product managers are blurring. Most technology-driven business opportunities today require managers and technologists – including developers, designers, architects and scrum masters – to work closely with one another and in a more iterative approach. The scope and solution set are regularly evolving.
In this new engagement model, the developer is no longer just waiting for somebody to tell him or her what needs to be coded. Instead, developers must understand the business and the implications of their work.
The developer’s role is evolving into more of a software engineer. The focus is on the expected business outcome, the business performance being targeted, and the various technology components needed to put that solution in place.
This means developers must have a broader understanding of the role their work has on the entire ecosystem of value delivery. The skills needed extend beyond just technology. To be successful, today’s developers must understand the nature of the business they are supporting, what the product managers are trying to accomplish, and what enablers are being developed using a software project. They also need to learn to work effectively with their counterparts across the business to prioritize based on business need.
Negotiation skills are important given the day-to-day discussions developers are having with various stakeholders across the business. There’s no one way of delivering value; the collective wisdom of the entire team is ultimately what provides value and the ability to innovate.
Putting it into practice at AT&T
We’re early in the process of implementing this new type of structure at AT&T. One way we’ve approached this is by elevating the people who have demonstrated those necessary skills – whether they’re product managers, testers, developers, or scrum masters – and broadening their responsibilities so they have ownership of the outcome from a business point of view and not just a technology delivery point of view.
Let’s say, for example, we’ve created a team that needs to focus on improving the sales of a product. They are beholden to two types of measurements for success: the traditional metrics, like defect density and defect removal efficiency, plus the new metrics – the corresponding business outcomes. We’re also working on moving to a more formal model where we hold our service providers and vendors to those same business outcomes.
This process will allow us to cultivate model developers for others to emulate. While we can always proactively train, I personally feel that people are more successful in learning and mastering new skills and methods of working better when they put them into practice.
For enterprise CIOs and IT leaders who are trying to turn the ship by developing more agile teams and honing these skills, don’t be afraid to try this. Build your support across the enterprise with all leaders. This isn’t just a CIO’s job anymore. This is how leaders at traditional companies must think to change that mindset across leadership at the highest levels of the organization.
Don’t worry that you’re behind, either. No one has truly arrived. Be hands-on, both in terms of how the teams are delivering and connecting with your business counterparts. This means you’ll have to revisit the talent that you have on your team to see who can best help make this happen. All of these elements are important for anyone embarking on this journey. This is the new way of the world.
[ How does automation help agile teams make more time for innovation? Get the free e-book: Managing IT with Automation. ]
Subscribe to our weekly newsletter.
Keep up with the latest advice and insights from CIOs and IT leaders.
The important shift in the developer perspective is that in the digital economy, you are no more responsible for writing code, but writing code that gets business results. So your job do not end, when you ship the code, but continues long after by measuring the outcomes and the product success metrics. Teams need to think of themselves as wolf packs, and are responsible for bring home the dinner. You don't have a 9-5 job anymore. Welcome to the digital economy!!
Sounds like you're dressing up the fact that you want to save money by doing away with business analysts or some other role in the process.
"The scope and solution set are regularly evolving"
This just means that whoever is responsible for gathering requirements, understanding the limits of what is physically possible and, most importantly, keeping the client's expectations in check has decided to offload their responsibilities onto the developers when they expect to be able to compensate for their disorganisation and incompetence. Sounds like a recipe for a litany failed projects and security breaches. But it OK because it's the developers' fault now - the really important people can continue to collect their bonuses.
"This process will allow us to cultivate model developers for others to emulate"
I've got a better idea. How about developers continue to cultivate their own paths they way they see fit? How about we adopt the technologies that we want to support and implement those in a way that make sense to improving the development process from a technical perspective? How about we develop products and solutions based on longer term term trends in requirements rather than client whims and managerial over-promising? How about we then engineer those solutions robustly and securely? In fact, I'll tell you what Mr Ugly Business Suit, that IS what we'll do and if you don't like it then good luck squeezing more grads out of the unis because there ain't none and those that are out there don't want to play your game.