Notes
  • Blockchain
  • About this repository
  • References
  • Carret Position
  • Loggia and Balcony
  • automobile
    • Motorbike
  • computer
    • Kubernetes Event-driven Autoscaling (KEDA)
    • Protobuf
    • [[Amazon]] [[Identity and Access Management]] ([[IAM]])
    • Apdex
    • Architecture Decision Record
    • Audio
    • [[Amazon Web Services]] (AWS) Lambda
    • Blockchain
    • C/C++
    • Cache line
    • Caching strategies
    • Database
    • Design Patterns
    • Docker compose
    • Event Driven Design
    • False sharing
    • Git
    • [[Go]] common mistakes
    • [Go] [[subtests]]
    • Go
    • Janus
    • Jest
    • Kubernetes
    • Log-Structured Merge-tree
    • Media server
    • MySQL: Charset, Collation and UCA
    • Netflix
    • Opus Codec
    • Process, Thread
    • ReDoS - [[Regular expression]] Denial of Service
    • Rust
    • ScyllaDB
    • Shell Functions
    • Signals (The GNU Library)
    • Solidity
    • Sources
    • SQL
    • Transmission Control Protocol (TCP)
    • Ten design principles for Azure applications
    • Transient Fault Handling
    • twemproxy
    • Video
    • Web2 vs Web3
    • WebRTC
    • Microservice architecture
      • 3rd party registration
      • Command Query Responsibility Segregation (CQRS)
      • Access token
      • Aggregate
      • API Composition
      • API gateway/Backends for Frontends
      • Application metrics
      • Audit logging
      • Circuit Breaker
      • Client-side discovery
      • Client-side UI composition
      • Consumer-driven contract test
      • Consumer-side contract test
      • Database per Service
      • Decompose by business capability
      • Decompose by subdomain
      • Distributed tracing
      • Domain event
      • Domain-specific
      • Event sourcing
      • Exception tracking
      • Externalized configuration
      • Health check API
      • Log aggregation
      • Log deployments and changes
      • Messaging
      • Microservice architecture
      • Microservice Chassis
      • Multiple Service instances per host
      • Polling publisher
      • Remote Procedure invocation
      • Saga
      • Self-contained service
      • Self registration
      • Server-side discovery
      • Server-side page fragment composition
      • Serverless deployment
      • Service Component test
      • Service deployment platform
      • Service instance per Container
      • Service instance per VM
      • Service mesh
      • Service per team
      • Service registry
      • Service template
      • Shared database
      • Single Service instance per host
      • Transaction log tailling
      • Transactional outbox
  • food-and-beverage
    • Cheese
    • Flour
    • Japanese Plum liqueur or Umeshu
    • Sugar
  • management
    • Software Engineering processes
  • medic
    • Desease, disorder, condition, syndrome
    • Motion Sickess
  • others
    • Elliðaey
    • ASCII art
    • Empirical rule
    • Hindsight bias
    • Outcome bias
    • Tam giác Reuleaux
    • Luật Việt Nam
  • soft-skills
    • Emotional intelligence
Powered by GitBook
On this page
  • Chief Technology Officer ([[CTO]])
  • Head of Engineering

Carret Position

Chief Technology Officer ([[CTO]])

CTO is an executive role:

  • focus on technology vision and "whats next"

  • communicates vision / confidence to external stakeholders

  • plans technology direction based on business plans and market trends

  • decides high-level strategy

CTO is responsible for vision and communication

CTOs job is to communicate confidence to external stakeholders about the technology choices and the engineering organization, security and scalability

CTO is responsible for knowing the market, growth & marketing plans, so that they can change the technical direction as necessary

CTO is responsible for defining the high-level architecture/structure/culture

CTO is responsible for procuring technology related resources

Of all the technical decisions that are on Head of Engineering plate, CTO is responsible for evaluating which ones to elevate, decide on, and translate that reasoning down

Some ways to evaluate success of CTO:

  • Is the organization able to secure funding and partnerships?

  • Is the organization able to attract and retain talent?

  • Are people within and outside of the organization excited about the technology vision?

However, CTO also shares responsibility for all the success criteria set out for the Head of Engineering

Head of Engineering

Head of Engineering is a manager role

  • focus on people success and operational success

  • plans technology based on team and available resources

  • implements technology direction

Head of Engineering makes decisions based on team and technology, and plans to release deliverables when they are ready.

Head of Engineering executes on the decision that CTO defined (the high-level architecture/structure/culture).

Their job is to setup engineers for success, mentor and motivate them, identify & escalate problems, ensure that deliverables align with the CEOs/CTOs vision, and that deadlines are met. They know how to estimate work units, how to manage the development process, and how to get the most of the team. While these are the core responsibilities, Head of Engineering is likely to also be involved in product strategy discussion, research or any other number of activities that make up the organization.

Some ways to evaluate success of Head of Engineering:

  • Do you have a smooth recruitment process?

  • Do you have a smooth onboarding process?

  • Does everyone receive mentoring?

  • Do you have visibility over performance of the engineering organization?

  • Is the engineering organization tight? (efficiency, collaboration, respect)

  • Are deliveries coming out on spec, on time and on budget?

  • Are the services running reliably?

The relationship between CTO and Head of Engineering is symbiotic. Virtually all of their activities may be overlapping. It is important to have some success criteria for each role, however, these roles do evolve and overlap over time. "people management" on its own is not a thing if you do not have the right strategy, processes, technology and product in place. Building a healthy engineering organization is a collaboration.

PreviousReferencesNextLoggia and Balcony

Last updated 2 years ago