10 Principles for Optimal Engineering Spend, from a CTO

To set up your engineering team for success make sure you employ the fundamentals that companies too often neglect.

Guest Commentary, Guest Commentary

January 29, 2019

4 Min Read

The engineering department is the cornerstone of a successful tech company because everyone — from product development to sales — is impacted by what it does and how it performs. Arguably, no other department has such a singular impact on the organization. To ensure your engineering team is set up for success, go back to the fundamentals or commandments, those essential commitments we all know we should focus on, but all too often neglect.

Make sure everyone knows what they’re doing and why. This is the Golden Rule. At the highest level, the CTO’s job is to ensure every developer knows the “why” behind what they are working on and how their efforts will enable the organization to achieve its goals. To maximize adoption and results, consider using a framework such as OKR’s (objective and key results) or the 4DX approach.

Visualize your key metrics. Define the metrics that matter most — think release quality, unit test coverage, automation coverage, sprint predictability — and then make that operational data pervasive across your team. Choose your dashboard wisely, as it’s tempting to get carried away with graphical gimmicks. In my experience, the simpler the dashboard, the better.

Focus like a laser on resource planning and utilization. A strong PPM (project portfolio management) tool will help you tie engineering spend to product ROI, which is really just another way of saying: It will keep your team focused. When development teams don’t use PPM tools, they inevitably launch a thousand ships (i.e., unimportant projects), which destroys your ROI and deflates team morale.

Insist on world class DevOps. Successful technology companies must be able to release software reliably at any cadence, weekly, daily, you name it. (Amazon deploys new software to production every 11.6 seconds.) Here’s where the CTO can’t settle. Your goal is no less than zero downtime and push button fully automated deploys, coupled with rigorous controls that do not allow untested software into production.

Embrace an iterative, agile approach to development. Learn to love agile engineering processes like SCRUM. No agile organization should have to wait six months to get a new feature out the door. Implementing agile improves pretty much everything, from product quality to speed-to-market, and it helps establish product testing as part of your organizational culture.

Align on a common framework for development. Implementing a modern domain driven design, or component-based architecture, as the foundation of your application will enable a clean division of work between development teams. Each development team should be able to work on microservices that are independent of other services so that they can be deployed separately. Doing so will ensure that working on a particular component won’t have the potential to negatively affect other unrelated components. In other words, stay away from monolithic application and database designs.

Automatically enforce coding standards. Most coders are overworked and already under enough pressure, so it only makes sense to find as many automated ways to enforce your coding standards as possible. Make automated rule-checking part of your everyday software build process. You want tools that will not allow any code to be checked into the repository unless all tests are passed, including unit tests and security vulnerabilities. 

Separate QA from development. Recently, there’s been a move away from QA-based testing in favor of developer-based testing. You can find strong opinions on both sides, but my recommendation is to separate the functions. QA testing requires skills developers don’t have (and vice-versa). Testers tend to push applications into non-obvious functions and are confident enough to follow up until bugs are fixed. Testers keep coders honest and ask questions coders don’t think to ask. Finally, your QA process should include functional testing as well as performance and security testing.

Create a culture of learning. Give your engineers a place to learn and continuously improve. Pair new developers with experienced coders and architects. Nothing builds confidence and team morale better or faster. Code review meetings are the perfect opportunity for experienced developers on your team to spread the knowledge.

Always remember, we’re in this together. Finally, let’s take a moment to appreciate that in a highly competitive, intensely fast-paced and volatile business world, you as a leader can save the sanity and increase the productivity of your team (and your company) by making it okay to take chances and fail. Promote a culture of collaboration and intelligent risk-taking. It’s the surest way to succeed.

 

Charles Cagle is Chief Technology Officer at Paycor.

 

About the Author

Guest Commentary

Guest Commentary

The InformationWeek community brings together IT practitioners and industry experts with IT advice, education, and opinions. We strive to highlight technology executives and subject matter experts and use their knowledge and experiences to help our audience of IT professionals in a meaningful way. We publish Guest Commentaries from IT practitioners, industry analysts, technology evangelists, and researchers in the field. We are focusing on four main topics: cloud computing; DevOps; data and analytics; and IT leadership and career development. We aim to offer objective, practical advice to our audience on those topics from people who have deep experience in these topics and know the ropes. Guest Commentaries must be vendor neutral. We don't publish articles that promote the writer's company or product.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights