Ever wonder why your company’s technology is the way it is? Your tech team’s origin story influences your company’s perspective, behavior, and outcomes with digital technology.

When you reflect on your company’s experience with technology over time, what comes to mind? Intractable issues? Unsolvable problems? Mixed results? History repeating? There’s a reason for all that.

The typical rogue’s gallery of known offenders aren’t wholly responsible for your long-term challenges:

• It’s easy to blame team culture, but if you’ve been at your company for 10+ years, you’ve seen the entire group turn over.
• It’s equally easy to blame leadership, but how many C_Os have run that department?
• Tools get short shrift, but aren’t they always buying new ones?
• Everyone’s quick to target process, but how many “new” methods have you seen implemented?

Although you’re interrogating a force that lives at the core of the entire organization, your tech org’s underlying nature establishes that institution-wide, unspoken behavior. Every cross-functional, interdepartmental interaction works like a contract, setting (and cementing) the expectations each side has with the other, implicitly and explicitly.

To understand the origin of your organization’s tech expectations and behaviors, unpack the current (and founding) biases, strengths, and weaknesses of your tech team:

• How they view technology work
• The methods they employ
• What they’re rewarded for
• What they’re trying to achieve
• Whether or not said goal is in their approach’s sweet spot

We describe the 5 primary working perspectives on digital technology in play today. They’re analogous to martial arts schools: similar in general practice, but differing based on focus, perspective, and behavior. One’s not better than another independent of circumstance.

Review the list below and ask two tough questions: What does your company need? What have you got? Consider these classifications “generally true”: overly-generalized, but also true! These are not person- or department-specific diagnoses (or condemnations).

The classical information technology (IT) digital technology lineage exists at almost every company. Your computers, networks, development environments, and websites are kept alive not by magic, but by these unthanked souls.

Focus: Operations.

Genesis: The ponytailed “back office” stereotypes who started their careers asking you to slide away from your keyboard later progressed to setting up Access databases and tweaking firewall rules, then worked on some huge, serious software rollouts. They’ve since become a corporate mainstay after everything got computerized. To be taken extra seriously, current IT muckety-mucks have haircuts and talk about cybersecurity threats.

Habitat: Any business that owns its own technology. Inside, IT practitioners will be found listening to endless Zoom meetings with India, poring through many tabs of open terminals, and standing up whatever fell down. They’re out there slaying problems that sales, engineers, and everyone else feels but never sees.

Behaviors: Implements software but does not build it (can be a trained computer engineer but never have made a new software application from scratch), will know networks or hardware in addition to software, quickly cuts to the heart of an issue, generally unnoticed if you work in a core area of the business.

Benefits:

• Unparalleled grasp of technology fundamentals
• Good track record for keeping things working
• Cares a lot about post-build and non-build tasks
• Understands non-functionals like performance, security, availability, etc.
• Grinds out enormous projects and asks for more
• Well-equipped to engage with legacy systems
• Can run software from the command line (unlike JS developers…😜)
• Not afraid of any new technology

Drawbacks:

• Works in months, not sprints
• Requires consensus to move
• Has never sold, built, or even used what your company sells
• Makes rookie mistakes with custom software development
• Ravenous for visible relevance, bites off more than they can chew
• Meetings spawn meetings, not outcomes
• Always has a trump card (“we can’t use Amazon because…”)
• Dashboards you to death

Fits when: 80+% of your technology is internal-facing and off-the-shelf, you need these types to build a safe playpen and step out of the way.

Doesn’t fit when: You need innovative, new technology built for your operations or product offering.

Prognosis: The more you ask of your IT team outside of their known boundaries, the likelier they are to get in over their head. If something goes wrong, they may play a trump card, and you’ll feel extorted.

Prescription: IT teams should make and control your digital spaces, but they shouldn't fill them. If your proposed tech requires less innovation and more operation, you need more IT. More innovation, less IT.

The product engineering digital technology discipline typically emerges organically from an organization's product or service demand. They’re easily spotted: as they grow, these teams retain facets of their homespun nature that don’t exist in the wider world.

Focus: Building stuff.

Genesis: In the old days, a product in development required a digital component, so an intrepid EE or ME grabbed the bull by the horns and got it done, earning trust and planting the seed for their future role and team.

Habitat: Engineered product companies and divisions, especially at family businesses and established enterprises. Until the arrival of the aforementioned engineer, “technology” may have meant the local computer company who blew the dust out of their beige desktops, the irritable guy at the ISP (or MSP), or the boss’s nerdlinger nephew who built the website.

Behaviors: Coding and working like mad, hitting or missing milestones without disclosing it, breaking things and then frantically fixing them, ducking input, getting results.

Benefits:

• Customers actually use what this team makes
• Influences revenue and CSAT for real
• Achieves “done”
• Incomparably-deep product and system knowledge
• Strong build-time capability
• Very clever solutions
• Willing to shirk or ignore other, lesser opinions

Drawbacks:

• First answer to everything: “it depends”
• Worthless documentation
• Useless or missing estimates
• Routinely surprised by post-launch iteration tasks and support costs
• Poor run-time team skillset
• Hard-coded beliefs bordering on superstition
• Insatiable resource hunger
• In-club politics
• “Green-to-red” behavior

Fits when: There’s a new or revised product that needs building.

Doesn’t fit when: You’ve grown past product or product line into digital ecosystem (2-n) that requires non-product technology experiences.

Prognosis: Continued pandemonium, frustration, people feeling out of the loop, ballooning then miraculously-contracting budgets, ultimately resulting in finished products. You’ll get your technology done, but it’ll cost a ton and feel chaotic.

Prescription: This team will always produce results. Resist the urge to bridle them, but instead aim them very specifically while removing the annoying blockers/interference that causes their reactant behavior. You’ll notice the temperature reduce dramatically and their output increase even further.

The marketing technology digital discipline was typically onboarded by a host business 10–20 years ago to modernize its retail, commerce, or audience outreach. This team reshaped the business, but increasingly finds itself up against non-marketing challenges.

Focus: Business metrics.

Genesis: Upon the rise of the consumer internet in the early 2000s, throngs of marketers reskilled away from their copywriting, accounts, and design jobs to become technology experts, and corporations vacuumed them up as they fled agency life. They didn’t forget their old advertising tricks, either. Some are still anchored to them.

Habitat: Corporate digital orgs and martech teams, innovation/intrapreneurial/venture units, design orgs, anywhere you find cool glasses and/or bike commutes.

Behaviors: Pitches, spec work, workshops, designing the next big thing, huge meetings, equivocation, the word “just”, producing occasional cringe material, chronically depressed by Google’s recent SEO changes.

Benefits:

• Genuine concern for and attention to business health
• Strong aesthetic and brand opinions
• Likely track record for effecting organizational change
• Frequent reminders of important market and business subtleties
• Fully grasps that building tech doesn’t matter if nobody engages it
• The different subdisciplines from this lineage can be extremely useful (content, engagement, research, marcomm, social, etc.)

Drawbacks:

• Weaker-than-required understanding of technology itself
• Attraction to pre-code panaceas like Design Thinking or other Current Thing(ing)
• Aversion to engineering and operational nitty gritty.
• Comes undone when user and machine functionality become core
• Struggles to make complex decisions
• Conflates “commodity” with “efficiency”
• Misunderstands scaling, run-time, DevOps, and resultant expenses
• Rarely truly understands the customer holistically despite claims
• Overly-hopeful, overly-simplistic solutions
• Shoehorns techs where they do not fit

Fits when: Your company-wide digital needs and your digital marketing needs are mostly the same thing.

Doesn’t fit when: You’re building tools for yourself or others, tech is part of your core product offering.

Prognosis: Depends heavily on the team’s decision-makers’ competence with modern digital beyond marketing and their managerial ability to enforce uncomfortable imperatives. Inflexible perspective and cavalier expertise cause real harm in 2024, so beware. Inexplicably mixed results likely.

Prescription: Use these creative types to amplify what you’re doing in your market. Unless you have credible evidence that your ex-marketers have the holistic breadth and applied depth needed to tackle your big problem, don’t use them to make products or build internal-facing tech.

Whereas the previous 3 disciplines execute tech work like a high-expertise craft, the pure digital discipline industrialized and commoditized software development. The first cohort bred for a world where technology is an end, not just a means, this group trickled in throughout the 90s and arrived in force by the late 00s.

Focus: Software itself.

Genesis: True digital natives who grew up punching commands into DOS, GS/OS, or Slackware before they could drive. Got started taking middle school comp sci, modding games, and writing early websites. Today, they’re the ensemble cast of tech bros who know the ins and outs of software construction and operation as part of an organization. Fewer of these types are being created today (far more young people consume tech instead of tinkering with it—the novelty’s gone).

Habitat: Any institution that needs custom software built for it, or in the professional services firms that serve them. Currently, these are your primary footsoldiers creating web applications, games, and mobile apps. Identifiable if an institution has a full-cycle, systematic separation of development concerns, roles, and tasks. Found less often in leadership than you might expect.

Behaviors: Codes ceaselessly while wearing headphones and hoodies, proselytizes methodology, overthinks problems and undertests solutions, pets dogs in the office, produces impeccable software.

Benefits:

• Firm discipline
• High expertise
• Huge experience
• High throughput, can really crank out work
• Intense opinions
• Can handle product, operational, and marketing technology
• Concerned with the role software plays
• Appropriately skeptical of innovation
• Knows software support subdisciplines (BA, UX, QA, PM, etc.)
• Can mix internal and outsourced, second most likely to use staff aug

Drawbacks:

• Frustratingly process-focused
• Believes in software solution to everything
• Becomes disaffected easily, if not outright whiny
• Opinions route to rabbit holes and intractable positions quickly
• Occupy uninformed ground quickly
• Incredibly jaded and battle fatigued
• Unexpected departures
• Demands seat at grownup table despite being non-core sales or product
• Believes they cannot be outsourced
• Never gets to done, but can reach done enough
• Does not understand the business because they've not worked in sales or product
• Tries to bend the org into software world
• Colossally wrong when wrong

Fits when: You need complex software, you're becoming a holistic ecosystem, you need to scale your tech group, or you’ve expanded beyond a singular operations, marketing, or product focus.

Doesn’t fit when: You have a pure marketing, operational, or product problem, or when you're unsure if you want to solve your problem with software.

Prognosis: The nuclear option in many respects. If constructing software can solve an explicitly-targeted problem for your business, it will get solved hard. Doing software correctly puts incredible strain on the rest of your organization.

Prescription: Contain and nurture. The intrusive, righteous demands of this approach can grind everything else in your company to a halt and soak up all your margin. If you’ve got a team like this and it’s not producing results, aggressively contain its operational impact while nurturing its positive outcomes.

The SaaS digital discipline wields technology like a hammer against a market problem. SaaS types iterate until they achieve PMF at a sufficient ACV, then exits and repeats. Embodies a hard-edged transactional approach to digital.

Focus: Iteration.

Genesis: Arose after two advents: 1. software could be built by smashing together external webservices and 2. software products could become the whole business itself, from awareness to purchase, to usage. Software is the product, unleashed dog of war, people who built a business around a SaaS thing, conflate software value with what it does for people

Habitat: SaaS companies obviously, startups, #meetups, and established industries with lucrative niche tech scenes like medical and manufacturing.

Behaviors: #rising, #grinding, #hustling, image crafting social media posts, churning out innovative successes and me-too failures with a discomfiting mercenary vibe.

Benefits:

• High energy
• Inhuman resilience
• Sometimes high speed
• Can zig and zag, strong cornering abilities
• Polyamorous with technology choices
• Course corrects quickly, great at tradeoffs
• Gets things stood up
• Overindexes on efficiency and scale
• Fast talent onboarding
• Most likely to find revenue independent of surrounding business context
• Most likely to accidentally have a good idea or a new line of business
• Good for test-driving tech, like AI
• Kicks ass at documentation
• Aggressively/toxically positive

Symptoms:

• Build for themselves, try to growth hack it into prominence
• Difficulty committing to a tech stack
• New feature= improvement
• Frequent releases
• Their effort matters more than their outcome
• Actual results may vary by measurement
• Least likely to understand customer, most likely to think they do
• Needs external input otherwise continues coal-shoveling
• Iterative overbuilding, not disciplined enough to live with something long enough to learn from it conclusively
• Talks to customers…once
• Self-exploitative, self-destructive

Fits when: You need something new and need it to find product/market fit, trying an offering in an adjacent market, just testing ideas, need to discipline chaos, or rapidly meet unique customer requirement.

Doesn’t fit when: There's a due date and a strict budget, a long commitment, a large technical architecture, or when cross-functional interdependent programs have to hit a date together.

Prognosis: Bumpy, jarring progress that feels gambling at a poker table where you don't know the language. You can build winning software, but the house will take a lot of chips along the way.

Prescription: This type of organization runs on feedback—feedback it chooses to see. To keep things on-track, force-feed it useful perspective and prevent it from fixating on pointless data.

When there’s a mismatch

Now comes the part we’ve heard a million times:

“We need to be better at technology. We’ve changed X, Y, and Z over and over again. I mean, remember when ___? Why haven’t our changes worked?”

Your changes fail in part because they only break one leg of the stool at a time. Also, parts-swapping changes always forget to modify the behaviors and expectations in the upstream and downstream departments. New leaders, new “A-player” workers, cure-all org re-structurings, and Agile/Scrum/4DX/EOS wondermethods get consumed and metabolized by the org as mean reversion sets in.

There are three preliminary steps to making a change this deep:

1. Get really, really square on what you want.
2. Change the operating environment. Explicitly define strategic outcomes and your desired tactical upstream and downstream functions and interactions between groups, altering their expectations and deliverables. The most deleterious organizational impact that tech teams make (and suffer) is not knowing where one person’s job ends and another’s begins. The whole org has to change its perspective on what its technology teams should be and should do.
3. Change components of the team. A course adjustment for your tech team itself will require less than you might think: a new ask, a new success metric, or a new leader will probably be enough to cleanse any inherent issues prior to future contamination.

And one final, critical step: enforce the new paradigm long enough to break old habits. It’ll take months of daily attention. To expect your tech team to just perform after tweaking a few dials and knobs and walking away is to abandon them to their fate.

Simple, but not easy. Or fast.

---

Next Mile leads organizational refits and adjustments that genuinely work. Contact us if you’ve got a big change to make.