This post summarizes how I think about engineering excellence and culture. It is not the “only” or the “best” way, but I’ve seen it working in the past in many stages of several companies in different spaces, and I believe it can be generalized to a majority of engineering teams. 

Engineering culture is a sum of established practices for software development, code contribution workflow, and product delivery process. It is helpful to think of engineering culture in terms of three primary dimensions: technical leadership, project management, and people management. In most organizations, each of these dimensions have an organizational leader, and they all roll into the CTO. In smaller organizations, the CTO may wear all three hats until the org is large enough to hire individual leaders for each of these three functions. After splitting these functions into individual roles, it is critical for each function to make decisions in coordination and communication with each other. Every single decision will impact the other dimensions. 

I have broken down the decisions at each dimension to three level:

• Strategic decisions concern the “Why” of doing things, and are more philosophical. “Good strategy is opinionated”, so these decisions are influenced a lot by the experiences, opinions, and mindset of the organization leadership.
• Tactical decisions lay out “What” actions and management practices to implement at the organization. These decisions depend a lot on the team structure, company size, and the talent pool.
• Operational decisions focus on “How” these individual management actions will be undertaken. These decisions are sometimes made more locally, by each team’s managers. But there is still a case for coordinating these decisions at the company level.

(a) Tech Leadership

It is useful to think of technical decisions along three different levels of abstraction: strategic, tactical, and operational decisions. 

Strategic decisions

There are a few fundamental decisions that give a technical direction to the engineering team. These ideas build a foundation for the software architecture, and amount to what engineering teams call “Our Way”. These strategic decisions help teams make tactical and operational decisions much faster and more consistent. These decisions include:

• Microservice vs monolithic architecture. Those who have worked with me know that I am a fan of microservice architectures. Many successful engineering orgs have migrated to microservice architecture, and have shared their journey in posts like this.
• Serverless vs traditional infrastructure. I have shared my views on this topic here.
• Continuous delivery vs traditional deployment. Continuous Delivery is a tenet of high-throughput engineering teams. Convoluted and manual deployment processes create a risk of single point of failure due to dependence on a single resource or a small set of individuals who know how to deploy the applications. One of the better resources I recommend on this topic is the DevOps Handbook. Other recommended readings: The Phoenix Project, and Accelerate. 

Tactical decisions

The tactical decisions are not as fundamental as the strategic decisions, but still have impact on a range of different activities. They should be taken in coordination with the strategic decisions, and with the goal of making day-to-day activities more efficient.

• What languages and frameworks to use. I recommend keeping the languages across the stack to 3-4. This enables a better economy of scale since developers can use general boilerplate code across the projects. Also makes swarming and team mobility much easier since everyone can learn 3-4 languages to work across the stack. And it makes code review multiple times faster and of higher quality.
• What deployment stack to use. Containerized? Terraform? GitHub Actions? The most important point is that we need to move towards full Infrastructure-as-Code to enable faster, more secure, more stable product releases. 
• How to design APIs. REST, GraphQL, RPC, etc. Teams should pick one framework based on the needs of the product, and commit to it. 
• Build vs buy: do we need to buy a service to do XYZ or should we do it in-house? And while reviewing build-vs-buy decisions, also take a critical look to cut back on spending on services that are not solving real business problems. 

Operational decisions

On the operational level of technical decisions, we are looking at specifics of code contribution and DevOps. 

• Code Style. Code style decisions are influenced by personal preferences. The trick is to understand that it is more important to be consistent than to be “perfect”. There are plenty of good style guides out there. Engineering teams should pick one as a team and iterate over it and make it their own over time. 

How tech decisions are normally made

Engineers are opinionated and reaching consensus on every single item is very time consuming and counter-productive. A single person should orchestrate the decision making process. This is usually the responsibility of the CTO, Chief Architect, Principal Engineer, or Staff Engineer. A good CTO would listen to everyone and try her best to facilitate a consensus, but also understands the value of making timely decisions to keep moving. I really like how Camille Fourier has approached this issue in her book, The Manager’s Path.

(b) Project Management

Strategic Decisions

On the project management side, there are a few fundamental decisions:

• The engineering management methodology: Agile is proven to be the most effective way to manage software teams. However, the main question is to what extent do we want to adopt Agile. Agile is implemented by its “ceremonies”, so the main decision is which ceremonies to observe. These ceremonies include:
  • Weekly planning
  • Retrospectives
  • Demo 
  • Backlog grooming
  • Etc.
• Work allocation method: Two main camps: Push (scrum) vs Pull (kanban). Do we schedule the work in advance, or do we prescribe what needs to be done, and have the team pick up action items one at a time.

Tactical Decisions

• Project management tools and platforms. What tools to use to monitor and report progress? Burn-down chart or burn-up chart? Gantt charts? In some cases, the choice of tool and platform to use impacts the availability of certain metrics or communication charts. For instance, monday.com has better Gantt chart capabilities for roadmap design, Linear has a better tagging system for grouping tasks, and Jira is better suited for projects that can be broken down into almost-independent sub-projects (Epics).
• Metrics. Teams need to define metrics to bring more awareness into their engineering throughput. There are several frameworks that define very helpful metrics (I am a fan of DORA and Flow metrics). The point is to provide a measurable way for the team to assess their own performance and create a feedback loop, not a rigid framework to stress over and spend a ton of time on meaningless data collection. I.e., the engineering metrics should be in service of reaching a higher goal, and not the end goal in themselves.
• The optimal breakdown of effort. Normally Keep-The-Lights-On, and then 60-20-20 allocation to “new features, improving existing features, fixing bugs”. This article explains this framework well. 

Operational decisions

• Meetings.  How to run meetings and Agile ceremonies: synchronous or asynchronous (Slack), frequency, etc.
• Work estimation techniques. T-shirt size, number of days, difficulty level – everyone has their “favorite” way of estimating how long tasks take. The inherent difficulty of estimating the duration of engineering tasks is a major reason why kanban method has such a fervent following. If you are doing scrum (push), this is a hard decision that the engineering managers need to make and stick to as much as possible.

How project management decisions are made

Designing the project management system for an engineering team is normally within the scope of the VP of Engineering or Director of Engineering. In some cases, the Engineering Managers on each team can be given the responsibility of making some decisions at the team level. 

One of my favorite resources on engineering management as a craft is Systems of Engineering Management.

(c) People Management

Strategic decisions

• How to encode motivation and build resiliency in the team. I have shared my thoughts on this in this post.
• Team structure. Centralized decision making or decentralized? DRI model? Camille Fournier in her book The Manager’s Path eloquently describes why team structure and levels are important. She later qualifies that opinion by writing about how leaders should embrace some level of discretion and imperfection in the team structure (i.e., there are no hard and fast rules in setting up the team structure).
• Career ladder. Make sure to have equally-rewarding and equally-challenging ladders for technical and people management tracks.
• Titles. Titles have a few important functions:
  • They are external signals that indicate the level of responsibility and ownership to the outside world. 
  • They help build a career trajectory and narrative for individuals. 
  • They are internal signals that guide and enable decision making.

Tactical decisions

• Metrics. Set up specific metrics, measure them across teams and across different seniority levels. Share the metrics as much as possible. Some important metrics: Diversity, Retention. 
• 1-1 meetings. 1-1’s are very important; there are tons of articles about why managers should take 1-1’s seriously and not skip them. Here is my favorite. 
• Career Development , performance evaluation, feedback, etc. It is very important to hold regular performance review meetings, with at least one annual meeting that the career development and promotion path for the individuals are discussed. It is helpful to create a template for performance reviews, so individuals get a sense of continuity of feedback even when their managers change. Geergely Orosz has an extensive blog post, with lots of good ideas about how to prepare and run performance review meetings.
• Hiring. I have written about this in this post.

Operational decisions

• Taking the pulse of the team. Regular check-ins, anonymous feedback are important to get a pulse of the team. Are they burned out? Are they bored? 
• Team building. Hackathons, happy hours, shared activities, etc. are important and create a sense of belonging. 
• Balance of WFH vs in-person. “Products can be built remotely, but relationships need to be built in person”. Facilitate in-person interactions via planning company events and sponsoring smaller group interactions.

How people management decisions are made

This depends on the team structure. However, in most cases, most strategic and tactical people management decisions are made by the engineering leaders (CTO, VP Eng, Dir Eng). The operational decisions can be made locally by the engineering manager. There are plenty of good resources on how to approach this issue. My favorite is Managing Humans.