In the ever evolving world of technology, 18 years can feel like several lifetimes—but it’s also just enough time to gather invaluable insights that only experience can teach. As I reflect on nearly two decades, six employers, and scores of clients in the digital services arena, I've encountered challenges, breakthroughs, and countless lessons. These experiences have not only influenced my professional journey but have also shaped my views on leadership, innovation, and organizational culture. If you or your company are involved in developing technology-based products or services, this post could offer valuable insights for you. Listed below are the most important lessons I've learned along the way, presented in no specific order.

Let your business define your process

Organizations tend to invest too much time and money trying to find the "right" engineering process from the sprawling process marketplace. Processes like SAFe, Scrum, Kanban, Lean, Test-Driven Development, and Behavior-Driven Development get pushed heavily as a cure-all and can come at a heavy cost. By design, however, I believe processes like Agile, and all of it's many mutations, out of the box are extremely broad and lack the necessary subtleties to effectively address the hyper-specific challenges faced by businesses. Moreover, the commercialization of process training and certification should be viewed with more skepticism. Organizations that invest in certifying Scrum Masters, PMPs, and SAFe Agilists are consumers of these processes no different than they are consumers of any product or service being marketed to their company. Just like any other product, these processes (and requisite certifications) are sold and marketed as a quick-fix to solve all the problems your organization is encountering. Remember, if it seems too good to be true, it probably is.

So, what's the move then? How should technology thought leaders define a strong process that doesn't slow them down and/or tank morale but includes the appropriate guardrails to ensure efficiency and quality? To me it's the same as treating a headache. When your head hurts you take 2 Aspirin, not the whole bottle. When your process shows gaps, glean insight from a combination of your intuition and the larger collective of institutional processes and tweak one or two small things. For example, lets say you've been running into issues with defects reaching production, the answer probably isn't ditching your existing process and dive headfirst into Test-Driven Development. In this example, maybe the answer spending more time on "Definition of done" and "Acceptance criteria". Maybe a weekly meeting with your QA lead to ensure they believe requirements are being defined clearly. Make continual improvement and retrospective your most powerful process tools. Identify the gaps and make small tweaks to address them; avoid seismic shifts and you'll find the sweet spot over time.

Talent reigns supreme

The technology sector revolves around people and there's no substitute for elite craftsmen. Tooling, process improvement, and a strong team culture can only get you so far. Ultimately your ceiling is defined by the talent your organization has compiled. Talent, as I view it, is a blend of the following attributes:

• A combination of academic knowledge and hands-on experience

• Inherent problem-solving ability

• Team-focused attitude

• The ability, curiousity, and drive to learn areas outside of one's immediate purview

Talent is the ultimate deodorant. It masks team and process imperfections. Talent picks up the slack when others are struggling. Talent solves problems rather than escalate them. Most importantly talent understands that products need to be carefully woven together to be more than just the sum of their parts. In other words, if you make compiling talent, at all levels, your top priority the rest generally finds a way of working out. If you're curious, I share my guide to finding and hiring the right talent here.

Tool selection is hard; tool adoption is harder

Choosing the right tools in the technology vendor marketplaces is a daunting task especially given the overwhelming number of product offerings, variance in pricing models, integration concerns, and risk of vendor lock-in. Compounding that, and an area where many companies face challenges lies in getting teams to adopt and integrate these tools into their daily work. In far too many cases CIOs and IT leaders spend countless hours (and boatloads of cash) on analysis, evaluation, procurement, customization, and ultimately roll-out of tools that, digitally speaking, end up collecting dust because they go unused or under utilized. Some examples I've seen: Spending top dollar on a CRM platform but the sales team is still relying on spreadsheets to manage deal intake. Purchasing a ChatOps tool and everyone is still using email and WhatsApp for day-to-day collaboration. Getting a shiny new DevOps platform but developers aren't checking code into the right branches. In essence, the presence of new tools fails to establish a new norm the business was hoping for.

The trick is that the rank-and-file of an organization will always struggle to adopt a new tool if all they did was purchased a tool/platform and roll out some training material. It needs evangelism from within the ranks and its value needs to be broadcast. Organizations are in the best position when they're able to get middle and lower management working with them to nudge along adoption. "Our client wants to expand? Great news, can you update that in Salesforce?". "The document is ready for review? Perfect, send it to me in Slack.". The simple day-to-day drumbeat from team and project level leadership is a simple and effective approach to increase adoption and meld a new way of doing business into team culture. Transparency is also an effective weapon. The company purchased X because they want to accomplish Y. People tend to be more responsive when they understand the rationale behind decisions. Things like: "We're trying to identify some key markets to invest in marketing campaign. We need teams to use CRM correctly in order to gather the right data". People can get behind logic, but that logic needs to trickle down through every rank of the organization.

Bench policies and talent retention

*This one is only relevant to the service industry and customers of the service industry. If the inner workings of tech service vendors isn't important to you, feel free to skip to the next topic.

The single most catastrophic policy impacting talent retention in the technology service industry is the bench policy. A brief description: when engineers (and other billable employees) roll off contracts due to project completion, downsizing, or client attrition they're placed on what's commonly referred to as "the bench". A waiting room of sorts where non-billable team members are lightly engaged in training, R&D, business development or, in the worst cases, internal job hunting to fill the void in between client engagements. The challenge is that since they're not billing, these benched employees exist on the corporate ledger as a liability due to the fact they're no longer drawing revenue. In order to predict and hedge these losses, many companies put caps on bench time. After a certain amount of time employees are "benched out", which is a polite industry term for laid off because they couldn't get paired with a client on time.

Like everyone else in this world, engineers (and other tech talent) enjoy job security. When individuals are aware that completing a project might lead to potential job loss, despite their performance, they tend to seek opportunities that provide a more stable outlook. In my experience, tech service organizations with stringent bench policies typically do not attract and retain the same caliber of talent as those with more flexible bench policies. Personally, I've been through four acquisitions wherein our company was purchased by a bigger company with a strict bench policy. In each case, I'd estimate that at least half of the client-facing talent moved on within 2 years. If you're looking to join a new company or looking to solicit services from a third party organization, check to see how they manage their bench. It can be a good barometer for the type of resourcing they'll bring to bear.

Build over buy is risky business

Build vs Buy is a classic decision faced in the IT/product world. In other words, should companies buy tools and platforms to perform vital business functions or should they develop those capabilities on their own using a combination of open-source frameworks and already procured tools in-house? From my experience, electing to build generally ends up being more time consuming and costing more money over the lifecycle of the application(s). Reason being is two-fold: labor and support. Customizing a platform, no matter how simple, ramps up in complexity fast once the rubber meets the road. Scope creep is a near certainty as edge cases and unforeseen requirements pile on throughout the development lifecycle. Security, reliability, and non-functional requirements are easy to underestimate. Resultantly this heightens the demand for labor and increasing costs whether it be from hiring or contracting resources to augment capacity. Second, the support model is often overlooked. If a company develops an internal platform using some manner of open source language or framework then they're at the mercy of their own devices when an underlying flaw is exposed. Security vulnerability? You'll be patching that yourself. Memory leak? Buy more compute resources. Things stop working when you update a library? Your team might be working this weekend.

I'll caveat this with one notable exception. Build over buy can be the right move when a company is building a something wherein their organization qualifies as a domain expert. Example would be: a product company with a wealth of talent in a given open-source framework building a back-office tool in that same framework, or a service organization specialized in a certain application of technology building a similar application internally. A recent example, I worked with a very large company in the cyber security space helping to augment their PHP development workforce. In this case they were building a internal PHP-based platform to dynamically manage network traffic. 9 times out of 10 I'd advise a client to invest in a tool to do that for them however this client in particular happened to develop market-leading products for IT/Network security controls, all built on PHP. They were well equipped to scope work and predict their project timelines and run rates with great precision given their wealth of experience in this hyper niche domain. Moreover, they had all the requisite infrastructure in place to sustain this application over time. In this scenario, and the few cases like it, it can make sense to cook your food at home, so to speak.

Continual Improvement: Retros and Action Planning

I believe that retrospectives are the most important part of any technology development process. It gives the team an opportunity to take a look in the mirror and figure out what's working and what needs improvement. The challenge is, while cathartic, retros can often function as a form of group therapy and less so as an instrument of change. In other words, often teams will call out areas for improvement but nothing will be done to remedy said areas over time. The companies I've seen that are terrific at adapting and improving process all have very regimented action planning following retrospective. Process improvement should be thought of like a project within a project. Think of your retrospectives like requirements gathering sessions and follow up with action planning to identify the what, when, and how to improve in the areas called out. One company I worked at was very good at this. Their strategy was to create a small Process Improvement Team with leaders from each different department in the company. This team met monthly to pinpoint and fix the issues raised during retrospectives. Together, they worked on clearing the backlog of improvement tasks and kept things moving in the right direction.

In closing, I hope you're able to utilize some of my lessons learned rather than learn them the hard way like I did in far too many of these examples. Remember: Tool adoption is crucial but getting teams to use them effectively is the real challenge. Process should align with business needs, not the other way around. Bench policies significantly impact talent retention in tech service organizations. Building over buying can be risky and costly. Continuous improvement through retrospectives and action planning is key for successful technology development. Thanks for the read and don't hesitate to comment beneath if you have any feedback.