The 6 Core Elements of Exceptional NetSuite Development Operations

In my 12 years of NetSuite development, I’ve had the opportunity to observe, build, manage, and advise dozens of SuiteScript teams. Through those opportunities, I’ve honed in on six foundational aspects that I believe make for successful NetSuite development operations:

1. Hiring
2. Onboarding
3. Career Progression
4. Continuous Improvement of Code Quality
5. Version Control
6. Documentation

Hiring

Hiring new NetSuite developers can be a laborious, time-consuming process. The relative smallness of the niche makes experienced NetSuite developers on the job market as rare as fossils. A “bad” hire becomes exceptionally expensive when it can take months to find a fitting candidate.

For me, hiring has always been about looking for problem-solving ability and attitude fit more than technical skill. A well-organized and collaborative technical team can teach technical skills rapidly, so it is far more important for me to identify and hire candidates who gel well with the existing team and processes, but bring in a different perspective and background that we can learn from.

Once upon a time, I strictly followed the hiring process outlined by Joel Spolsky in his book “Smart and Gets Things Done”. I still believe that is a good foundation to start from, but I’ve since softened a lot of the rigid lines in Joel’s process. Because it is so hard to find existing NetSuite developers, I prefer to focus my hiring on finding a good personality fit for the team, and then I shift the burden of technical and organizational competency to the Onboarding process and the other ongoing support processes I provide to my employees throughout their tenure.

I’ll post a dedicated article about Hiring, join Salto’s newsletter to get notified when it’s out.

Onboarding

Once I’ve offered a position to a candidate, and they’ve agreed to join my team, my job as a leader is beginning, not ending. Onboarding is the time to make a great impression, to impress the culture of your organization, and to teach required technical skills to new employees. I want them to feel welcome, supported, engaged, and valued on Day 1 and on every day thereafter.

I onboard new developers with a training program that closely mimics their day-to-day work, but without the pressure of making a mistake in Production. Most NetSuite teams I see simply have their new members fill out some paperwork and immediately get to work for a client or users. I want them to instead work out their growing pains in a safe environment. New jobs come with plenty of stress, anxiety, and uncertainty already. I don’t need to add to it by throwing them to the wolves immediately. I give them time, space, and support to complete a project alongside their team, following all the processes and using all the tools they’ll see in their Production work. This phase provides a smooth transition into the organization and sets them up for a long, successful tenure with me.

I don’t leave it up to schools and other employers to make the employees I need because it’s literally impossible for them to do so; I create the employees I need through solid training and consistent support. Good employees are not made by the hiring process or by the schools or jobs in their past; they are created in the Onboarding process and nurtured in the Career Progression system.

‍

**

Career Progression

My leadership responsibility does not end with hiring or training a new employee. Once I’ve brought them into the organization and up to speed with their team, I now need to help them define what success looks like for them, and then provide continuous guidance and support to help them advance their career and our organization. In order to do that, I need to first decide what sorts of advancements are relevant to my organization and in my capacity to support.

I decide that by developing well-defined career paths. These paths are effectively a sequence of job titles and descriptions, laid out in a logical sequence, with clear requirements for attaining each one.

Not all developers want to stay developers forever. Some may want to become architects or sales engineers or managers, or any number of other roles. Additionally, not all developers want to reach the end of the path; many will be quite satisfied to stay in their Senior Developer position and write code forever. It’s my job to decide which of those paths are viable and valuable for my organization, to provide clear communication about the available paths I can support, and to facilitate my employees’ advancement toward their goals.

‍

Continuous Improvement of Code Quality

I always want my team members to be dreaming up ways to improve the quality of the code they deliver, improve the processes by which they deliver it, and improve their quality of life while they’re at work.

There’s no faster way to alienate an employee than by dismissing their ideas, or never hearing their ideas in the first place. I want my employees to have ample opportunity to share their ideas and concerns, and implement them. To facilitate that, I:

• convene the entire development team consistently and frequently to discuss improvements and failings in the status quo. Bi-weekly or monthly sessions usually give plenty of opportunities to identify and plan improvements while also allowing for time to actually implement them.
• encourage the team to develop coding conventions and standards. A “style guide” developed by the team members themselves will produce more by-in and will form the backbone of our code review process.
• require all code to be reviewed by at least one person who is not the author before it can be released to Production. Reviewers focus on the consistency, the functionality, and the maintainability of the code using the team’s style guide as their rubric. This also has a nice side effect of distributing the responsibility for any particular piece of code among multiple team members, helping us avoid toxic blame games for any Production problems.

‍

Version Control

We can’t do code review (easily) without some form of version control; it is one of the most crucial and foundational practices to add to any software team. It tracks the history of our codebase, it forms the basis of our collaboration, it helps avoid overwriting each others’ code, and it is the foundation of future automation.

Version control is not the source of truth for what is deployed in any particular NetSuite account, particularly in accounts where the dev team is not responsible for every change to the account. I have seen team after team try mightily and fail to force their git repository to match Production or Sandbox. It inevitably causes only pain and strife.

Version control is the source of truth for the state of our code. I use branches to isolate and distinguish code that is in active development from code that is approved and awaiting deployment from code that has already been deployed.

‍

Documentation

Code is the communication and implementation of a solution to the target system and to other developers working in that system. It describes what the system should do under specific conditions, but it does not (and should not) describe why the system should do that, who it does it for, or what alternatives were already considered and rejected. This is where our documentation comes in.

I teach my teams and advise my clients that good documentation is a perpetual habit, not a task to be completed. Good documentation is alive; it changes and evolves right alongside the corresponding software.

Documentation is always highly contextual. Documentation must be discoverable from the point where it is most relevant. A developer should be pointed to the relevant documentation about a piece of code by that piece of code. Links to external documents provided in comments are a dead simple way to ensure this contextual access.

However, incorrect documentation is worse than no documentation, and so it should be seen as just as problematic as incorrect code. I incorporate documentation standards into the team’s style guide as well, and documentation gets reviewed right alongside the corresponding code.

‍

Outro

Stay tuned! In the coming weeks, I’ll elaborate on my advice for each aspect individually to give you a robust approach for leading a successful team of NetSuite developers.

‍