Tektalker Advisory

Operational & Tech Diagnostics

A targeted, two-to-four-week assessment of your engineering or operations function, done through asynchronous review of documentation and a small number of focused conversations with key stakeholders across the organisation.

At the end of this you'll get a report outlining risks, bottlenecks and opportunities, followed by a dedicated session to discuss the findings and map out practical next steps.

Best for:

  • Leadership transitions where an incoming executive requires an objective, independent baseline of an inherited team.
  • Situations where delivery or momentum feels slow, but leadership cannot isolate the root causes of the friction.
  • Preparation for a major scaling phase where you need to identify hidden vulnerabilities before they cause friction.
  • Pre-acquisition or merger due diligence requiring a discreet assessment of an organisation's health.

You can see details on what the assessment usually covers below.

Strategy

Goal setting and alignment

Look at what the (tech) strategy is, how it was developed and its alignment with the Business' objectives. Explore how visibility and accountability are fostered in the team(s) and how that's working so far.

Examples of what we look for:

  • written objectives and strategy statement
  • known and living OKRs/KPIs/etc (billboards, dashboards, comms)
  • frequent leadership communication with appropriate detail and transparency
  • cross departmental visibility and buy-in

Guiding principles and tenets

Look at the guiding principles and tenets of the department across several categories. See how they were developed, how they evolve, the level of awareness around them, and how they align into the mid->long term goals of the Business.

Examples of what we look for:

  • written and easily referenced (ie: living) doc/wiki of principles and tenets, where possible written as "X over Y", covering categories/topics such as:
    • build vs buy
    • cost centred vs cost conscious
    • future capability vs current capacity
    • delivery speed vs quality (incl. usability) vs cost
    • etc

Decision making and accountability

Look at how decisions are made, the quality of them, commitment to follow through and get to "done".

Examples of what we look for:

  • appropriate level of analysis (or lack of it) based on the impact, cost and reversibility of a decision (quick when possible, due diligence when needed)
  • individual VS collaborative decision making VS democracy
  • command & control VS autonomy VS anarchy
  • any record keeping of decisions (ie: ADR for architecture? history of commercial ideas requiring pivot etc)
  • follow through VS sunk cost
  • is the way of making decisions (who, how, based on what) documented and accessible to all in the Business?

Processes

Delivery

Take a wholistic look at the process end to end, then drill down into each stage of the deliverable lifecycle:

ideation → planning and selection → implementation → commercialisation, support and broader day2ops → retire and decommission

Look at what these processes are, how they were developed, and their alignment with broader Business needs -- exploring limits, bottlenecks, potential friction points, inherent ability to pivot (and the cost of it) etc

Examples of what we look for:

  • feature factory vs product team
  • documented process, DoR, DoD, flowcharts, value stream map etc
  • who, how and at what points can insert into the delivery pipeline?
  • explicitly built-in ways to:
    • ensure process evolution over time (ie: retrospectives)
    • foster accountability (and so reputation building towards the Business) (ie: demos)
    • intra team comms and visibility (ie: daily syncs)
    • engage stakeholders
  • process metrics: cycle-time, work quality, waste, etc

General support

Look at what the process for fielding support queries is from internal (system alerts, CEO, director, product manager etc) and external (prospect, customer, user) sources

Examples of what we look for:

  • monitoring and alerts for proactive support; appropriate channels (email, slack, forum etc) for reported issues
  • documented process, flowcharts, value stream map etc
  • triage and its efficacy ("ignore nicely", put on backlog, escalate into incident etc)
  • defined 1st/2nd/3rd/4th line (where needed; who, what, when); on-call rotas;
  • explicitly built-in ways to ensure process evolution over time (ie: retrospectives)
  • process metrics: time-to-first-response, time-to-resolution, time-to-close
  • comms SLOs and defined comms approach

Incident response and review

Look at how the team responds to an incident. Headless heroics or disciplined firefighters? Look at how the team learns from incidents.

Examples of what we look for:

  • "Incident Playbook", aka. documented process covering:
    • what is and is not an incident
    • severity levels and what responses they get
    • incident roles: what they are, how they get assigned and to whom (ie: the standard triad of commander, comms lead, ops/tech lead)
    • incident call etiquette
    • comms expectations (ie: updates hourly even if it's to say "still looking...")
  • documented history of incident reports and post-mortems
  • regular fire drill exercises

Risk register and Disaster Recovery

Check how the team(s) capture (known) risks factors and what happens with the captured risks. Look at disaster recovery preparedness.

Examples of what we look for:

  • documented list of risks (risk register)
  • is the register looked at regularly even if the risks don't get addressed? What we care about here is that any inaction is considered and deliberate ("Yeah we accept the risk and potential consequences") as opposed to ignorant ("I wasn't aware we should prioritise that")
  • "Cookbooks", aka. detailed tactical procedures (ie: "in case of fire...")
    • accessible and practiced (fire drills)
  • key scenarios (not meant as a complete list since it's highly business dependent, but for the sake of example):
    • major data corruption, leak or loss
      • have backups and practice restoring from backups regularly
    • crucial 3rd party dependence outage
      • cloud outage: it happens to major players like AWS too, so need to plan for it, even if it says "communicate to customers that we’re waiting on an upstream provider ..."
      • critical service outage, ie: if the product is a wrapper around one of the LLM providers and that goes down/times out etc

Recruitment

Look at the recruitment process: role adverts, interview stages, who's involved, how the final decision is made

Examples of what we look for:

  • team members are involved and influence the final decision
  • practical tests that are relevant to the role and company (ie: no leet coding...)
  • interview gives the candidate close to first hand experience of what the day-to-day would be like (ie: it's not an interrogation where the interview focuses only on what the Business needs from the person)
  • process documented for transparency and consistency

Employee on & off-boarding

Look at the two crucial bookends of the employee lifecycle, from a tech team perspective: grant/revoke access, make them feel welcome and equipped to deliver, integrate into the team, hand over tasks/responsibilities and knowledge.

Examples of what we look for:

  • (automated) access cookbooks
  • pre-start welcome comms with useful info and setting the scene for relationship building (ie: signalling openness to chat if they want to even before first day, option to visit the team for lunch etc)
  • first day->week->month schedule (with appropriate granularity)
  • time-to-first-meaningful-contribution KPI

Department and team setup

Department design

Look at the structure of the department: how are people organised into teams, what skills and responsibilities are there.

Examples of what we look for:

  • written roles and responsibilities
  • clear reporting lines
  • written team charters
  • limited silos, shared incentives
  • teams VS groups of independents
  • single points of expertise (aka: “the bus factor”)
  • gearing and capacity to grow

Employee performance and advancement

Look at how people are assessed and if there are advancement opportunities within the department. Are expectations ("what good looks like") clear to all? Is the progression and the way to get there clear ("How do I become a Team Lead?")?

Examples of what we look for:

  • written roles and responsibilities
  • employee KPIs and/or goals
  • incentives that make sense and support team->department->business goals (as opposed to drive "local optimisation")
  • regular, clear and transparent conversations about performance, progression
  • (informal) mentorships (senior-junior etc)
  • coaching of high performing employees (by manager or manager's manager or dedicated/external etc)
  • decisive and fair management of underperformance without lingering non-performers
  • active management of employee burn-out risk

Team health

Look at how team health is evaluated and how the information is used by leadership?

“A healthy team is a happy team, but a happy team is not necessarily a healthy team”

Examples of what we look for:

  • regular assessment done, by team or at least with team input
  • includes context and narrative but doesn't hide behind them (ie: qualitative and quantitative aspects)
  • transparently presented by a representative of the team to leadership/internal forum
  • covers:
    • execution: quality, impact, delivery (capacity allocation, hit rate, speed)
    • horizon on what’s coming (aka plans, agility)
    • people dynamic
    • morale & sentiment: "pawns or players", general drag etc
  • trend over time

Technical

Architecture and component quality

Look at the architecture of the system(s), assess trade-offs made, potential limitations, and appropriateness for the Business' goals. Similarly, assess the technical quality of key components.

Examples of what we look for:

  • any unnecessary complexity
  • is service responsibility and ownership clear?
  • technologies used and skills needed to develop & admin the estate of components
  • baked in operational telemetry
  • baked in commercial telemetry
  • level of 3rd party reliance
  • how enabled is product experimentation via the setup? (ie: ability to A/B test)
  • how much can it scale at what cost? is that too much/too little/just enough?
  • performance, resilience bottlenecks
  • technical quality of design
  • are there charts and diagrams?

Infrastructure

Look at the infrastructure of the main product and its key environments (dev, pre-sales, prod etc). Assess trade-offs, risks, costs, limitations.

Examples of what we look for:

  • any unnecessary complexity
  • cost to maintain, run and support (expertise required, running costs)
  • how gated does it need to be (ie: dev self serve <> all locked down by infra team)
  • observability of system behaviour (dashboards, alerts, logs)
  • cost to scale
  • resilience, performance
  • are there charts and diagrams?

SLAs and SLOs

Look at whether there are appropriate SLAs and SLOs in place, agreed to by all parties based on trade-offs to achieve and maintain them.

Examples of what we look for:

  • transparently and regularly published hit rate
  • regular reviews and empowerment (+ accountability) to make sure they are met
  • no aspirational figures (for too long). If there's a target that's not achieved within a reasonable time frame then it needs to be adjusted (or all hands on deck to achieve them). Let's not teach people that it's ok to ignore red lights.
  • agreements consider costs and business and customer needs. (triple nine is expensive to achieve and maintain, let's make sure we don't do it unless it's commercially needed and is viable)

Tektalker Advisory

hello@tektalker.com