Advice

10 things CTOs wish developers knew about tech and business

Thinking

CTOs lead the organization’s tech team, and must hire and serve as a guide for developers who are actually building the products and services.

The solution to many of the conflicts that arise between the CTO and developer team is communication, said Paul McGough, CTO and founder of Qwyit.

“It’s management’s responsibility to get the job done, and to articulate the business requirements as frequently, categorically and eloquently as possible,” McGough said. “But real coordination requires something everyone should feel free to do: Ask “why.” The one thing any technology leader must foster is an open, inviting atmosphere where everyone on the dev team is encouraged to wonder about implementation, optimization, capability and results.”

Here are 10 things CTOs wish developers would understand.

1. Look at the big picture

Developers in the technical trenches sometimes have a difficult time seeing the big picture, said Ben Johnson, CTO of Obsidian Security.

“When you’re in the technical trenches, it’s often hard to see the big picture. It’s like being on the football field—individual players don’t have the view that the offensive coordinator does up in the booth,” Johnson said. “On the flip side, often the CTO doesn’t know what’s being said in the huddle or how particular players are feeling unless they communicate. It’s a team effort, one that requires game planning and constant execution to optimize and align.”

2. Stay focused on the business mission

As developer solutions get more involved and detailed, they also often get further away from the mission, McGough said.

“It’s like when there are 20 buttons on a remote control when half of that—probably even less—is better for the user experience,” McGough said. “Developers like adding ‘buttons,’ but they should first ask themselves how it serves the business goal. Whether the team is working on an expressly technical control project or an end-user software module, for example, developers often move in the direction they know: More routines, more horizontal capability. Generally, this moves the CTO further away from the business objective.”

Asking “why” before adding a new feature makes the process more clear and helps the team function better, creating a better result, McGough said.

3. Remember security

From a risk management perspective, developers need to ensure that security is baked into the software they create, through the use of good coding techniques, said James Goepel, CTO, vice president, and general counsel for ClearArmor Corporation.

“These aren’t sexy things, like new languages, or new philosophical approaches to coding,” Goepel said. “But it can have massive impacts on the company, and the developers are directly responsible for ensuring it is adequately and properly addressed.”

4. There isn’t one solution to any problem

Developers should speak up and challenge their managers’ hypotheses, because there may be a dozen potential ways to develop a product or troubleshoot an issue, said Hector Aguilar, CTO and executive vice president of engineering at Okta.

“Every developer should know that there isn’t just one solution to any given problem,” Aguilar said. “Troubleshooting is an art, not a science, and it takes communication from all team members—junior and senior—to resolve challenges and exceed goals.”

5. Wasted code is not wasted time.

Developers often write something for a project or feature that ends up getting canned, said Eric Lee, CTO of Left Field Labs.

“I’ve poured my heart into apps and games and gone through painstakingly detailed QA, only to not launch because of a last-minute change to strategy,” Lee said. “Does it suck? Sure. But what’s important to remember is that shipping product (and the congrats/ accolades/pats on the back you get as a result) isn’t as important to your career as the knowledge and experience that you gather through the process. Writing code, like playing an instrument, is something that you get better at with experience, and the time spent unseen is more formative than the time spent on stage. Don’t let a canceled show distract focus from what you will achieve.”

6. Don’t trust “magical” solutions

Young developers may find open source libraries and think that they automatically make the complex simple, Lee said. However, they need to look at the source code and see how actively it’s maintained, and what will happen if they make changes to it.

“Importing third-party libraries often comes with outsourcing understanding, and it’s a dangerous practice to simply assume that someone else thoroughly identified and tested all of the fringe cases that may come up in your application,” Lee said. “Look under the hood early on, get a sense for code quality, educate yourself where there are gaps in your knowledge, and be prepared to dive in to debug and make changes when the time comes.”

7. How to make changes across the stack

Oftentimes, engineers know how to change the components they are used to changing, and when there are features that require changes across many parts of the stack, the only way to do the project is to have many people staffed on the feature, said Sean Suchter, CTO and co-founder of Pepperdata.

“Engineers that regularly touch many parts of the stack look like ’10x engineers,'” Suchter said. “If one can enable many engineers to do this, a lot of features that seem hard to do get easier.”

8. Don’t put all your faith in frameworks

“Frameworks may save you time, but especially if you’re new to a given programming language, they can easily make you a prisoner to the inherited limitations, performance issues, security vulnerabilities, or other bloat that comes along with a given set of tools,” Lee said. “Before you go all-in with a framework, make sure that you understand exactly what it is that you’re trading for convenience.”

9. Feature complete is not the finish line

Being “feature complete” is only about 10% of the way to the finish line, said John Kodumal, CTO and co-founder of LaunchDarkly.

“As a developer you also need to think about what’s happening at runtime, and you should bake into your code the ability to observe and react,” Kodumal said. “A few years ago that was probably simple logging statements, but now it’s support for observability and monitoring tools, feature flagging, and more.”

10. There may be a reason you don’t have access to certain information

CTOs are privy to many channels of information about the health of a company, investor situations, strategic plans, imminent events, and organizational moves, said Mike Duensing, CTO and executive vice president of engineering at Skuid.

“Some can be imminent, and some are confidential. You wish you could bring everyone into what is going on, but it is not possible,” Duensing said. “The challenge is to keep your engineering teams focused to optimize their energy and continue precious momentum. A good approach to address this challenge is by communicating well and often, and giving you engineers as much context as possible about why their work is prioritized as it is.”

From TechRepublic

View post in Vietnamese

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.