Engineering Should be the Operational Center of Your Digital Transformation
Originally published as part of, “The Day Before Digital Transformation” by Phil Perkins and Cheryl Smith
Organizations built on digital technologies have typically been founded by engineers. Both the early and emerging technologies require knowledge of software, hardware, electrical, mechanical, industrial, and chemical engineers, with dozens of subcategories such as telecommunications, audio, and video expertise. The early digital technologies are primarily infrastructure in nature, and we recommend them to be the responsibility of a strong IT staff. But the emerging technologies, the technologies that must be inherent in the products and services offered by the organization are primarily the responsibility of the business.
Making great engineering the operational center of your digital transformation, then building the rest of the skills needed around it, will be a change for many business leaders. Emerging technologies and the engineering talent required to understand them is your innovation hub and it should not be an afterthought to the strategy. In fact, it is one of the most critical components of the strategy.
Recruiting great engineering/technology talent is more about culture than salary. Do not waste time randomly trying to attract quality engineers or individuals with emerging technology skills through resumes to put butts in seats. Many organizations complain about their struggle to attract top technical talent, but this does not need to be the case. When recruiting strong engineering and technology talent, it is important to know that these individuals typically are highly tribal. They want to make sure they are working with other strong engineers and technologists in an environment that supports them. Over the course of their careers, they tend to stick together and follow leaders they respect and who respect them.
Note: we use the terms ‘engineering’ and ‘engineer’ throughout this section to include a multitude of disciplines that will be required in the business units, including but not limited to: electronic engineers, communication engineers, software developers, hardware experts, etc., depending on the product and emerging technologies under development.
To build a great engineering core team, you must invest time in networking with and understanding engineering leaders. If you can create an employee value proposition that will attract a tribe leader, then others will follow.
Attracting good engineers begins with understanding the basics of today’s development methodologies. The Waterfall methodology was designed for managers; Agile was designed for engineers. Great engineering talent wants to work in an Agile environment, because it lets them maximize their focus and productivity on the technical problems at hand.
Waterfall is a top down methodology that attempts to give managers a sense of control by defining a set of business and technical requirements before starting development. The requirements take on a near contractual obligation by the development team and its stakeholders. During this time of trying to define a perfect scope that has buy-in from everyone in the organization, the engineers sit idle and the organization is delaying the development of capabilities that are already agreed upon as critical.
As the project starts, that sense of control turns out to be artificial. Stakeholders begin to realize that the original requirements are not exactly what is needed. To control the change, the Waterfall methodology creates a robust change control process to maintain that artificial sense of control, which eventually turns into “change control hell.” As business stakeholders and project managers grow increasingly frustrated with each other, the engineers get increasingly pulled away from their core job of writing code to continuously re-estimate changes. Every time an engineer gets tapped on the shoulder, it will take them about 20 minutes to get back into the zone, so tapping an engineer on the shoulder twice a day for a 30 minutes discussion can actually reduce their productivity by about two or more hours per day. Not only are engineers not coding during this time, the project timelines do not change, so the engineers end up on a death march to simultaneously write software and build systems while supporting changing management expectations.
This ultimately leads to missed deadlines, management disappointment, and ultimately a loss of faith in the engineering team. At the end, management feels they were clear in their expectations of the team and the team feels like management does not know what it is doing.
No one wins.
Engineers love to build systems a lot more than they like to estimate and manage expectations. In the early 2000s, about a third of the way into the Digital Age, a small group of software industry leaders got together in Snowbird, Utah and invented Agile by bringing together processes that seemed to work well with software developers. Agile is a bottom up approach that focuses on maximizing individual developer productivity by giving them six hours of daily development time on average. More time building systems means more system capability development.
Understanding and operating an Agile development approach is often uncomfortable for novice digital leaders, and a powerful tool for experienced digital leaders, because it lets the digital leader avoid the cost of delay and adapt the system to feedback the organization is getting from the market. It can be difficult to get to executives to agree on an entire scope of work, but they can almost always agree on what needs to be done in the next two to four weeks. Digital leaders who can change their mindset from trying to fully define a digital effort up front and control every step of the effort, to adapting to market feedback and maximizing developer productivity, will create significantly compounding returns over time.
With great power comes great responsibility. Agile provides few tools to manage expectations on longer-term scale, which can be terrifying for executives who want to know exactly what they are getting for their capital investment. Inexperienced Agile teams without a longer-term roadmap can sprint a digital effort off a cliff and never delivery anything. Experienced digital managers adopt a mentality of “we can deliver something impactful by the deadline” versus “we will deliver the exact features believed to be important at the start of the effort.” Experienced digital leaders receive and deliver significantly more value over a 12-month period by accepting some of the perceived lack of control of Agile.
One note on the Waterfall and Agile methodologies. Some organizations and consulting firms are attempting to sell the concept of a methodology they are calling ‘Hybrid Agile.’ They claim this is a compromise between the Waterfall and Agile methodologies. As we have noted, both Waterfall and Agile have their place in development, and experienced technologists know which one to use and when. While Hybrid Agile claims to pull together the best components of both methodologies, it actually pulls together the worst elements of each methodology. It does not provide the level of management control that exists with Waterfall, and it does not provide the speed or adaptability of Agile.[i] Hybrid Agile may sound good on paper, allowing executives to try to pass off a diminished approach to Waterfall in disguise on digital efforts. If you are using Hybrid Agile in your organization, you are probably doing your digital transformation wrong.
In addition to adopting Agile management practices, organizations should consider other common factors that create a culture of engineering including:
- Continuous learning. Many organizations have adopted programs for book reimbursements, regular lunch and learns, and budgets to attend conferences.
- Continuous feedback cycles. Agile approaches have continuous code reviews, security reviews, and team retrospectives built into the process, but many organizations do not commit to keeping these meetings and let them fall by the wayside.
- Commitment to a balanced week. Coding quality significantly degrades as engineers work more than an eight-hour day, so the organization must commit to eliminating death marches. Motivated employees will always step up to hit deadlines, but there must be a give and take with the organization that eliminates scope as fast as it adds new scope to the product feature backlog. The market for engineers is small, and they have many choices. Once an organization has a reputation for death marches due to poor decision making, it will be unable to attract top talent in the future.
- Commitment to keeping quality code. Research has shown that for every 1,000 lines of delivered code, there are 15 to 50 errors. The reason good programmers introduce fewer bugs into the codebase is because they can solve a problem in significantly fewer lines of code than a bad programmer. An inexperienced engineer can introduce code complexity that can cut the speed of experienced engineers by 80%. Many organizations try to use quality software engineers for new development and lower cost software engineers for maintenance since both sets of programmers work on the same code base.
- Commitment to refactoring old code. All code has bugs, and all engineers must take short cuts to hit deadlines which creates technical debt. Technical debt builds up over time, which slows development and results in higher bug counts. Organizations must commit to giving engineers time to go back, fix, and streamline the current code.
As we have said before in this book and will repeat in later chapters—it is not technology that makes digital efforts fail, it is people.
[i] Conclusion based on experience of the authors and feedback from users.