The Organizational Layer Cake

  • Hire great people and help them thrive
  • Make sure those people are building high quality solutions to the right problems
  • Hiring: getting the right people into your organization
  • Goal Setting: picking the right problems to solve
  • Execution: building effective solutions to those problems
  • Feedback Loops: monitoring the right signals to help the organization, and the people within it, thrive
The organizational layer cake


  1. What are some of the things that come to mind when you think about valuable members of your current team? These might be things like taking initiative, good communication skills, the ability to see things through to completion, the ability to deal with ambiguity, and so on.
  2. What are some of the areas where hiring new people might help? These might include filling gaps on your current team — such as management experience, or specific technical or domain knowledge — or adding to skills that already exist, to enable an overall increase in team velocity.
  3. How will you create a high fidelity hiring process (that is, one that hires people with the right attributes, filters out people without those attributes, is unbiased, and is not overly onerous)? Many companies follow the style of whiteboard technical interviews used by large tech companies, but in my experience those often filter for wrong things, especially with more senior candidates. Much can be (and has been!) written about good hiring processes, so I won’t go into detail here, but it’s worth understanding what works for your organization.

Goal Setting

Make sure you’re climbing the right mountain (CC BY-SA 4.0 license)
  1. Who ultimately decides what goals or OKRs the team works toward? This may depend on whether your team operates in a pod structure or a matrix structure. In a pod structure, each pod usually includes representatives from each key discipline (engineering, product management, UX design), so the decision makers are relatively clear: product managers for product work, engineering leads for engineering work etc. Everyone should feel empowered to voice their opinion about all potential work items, but the decision makers for each one can be clearly identified. In a matrix structure, an engineering team may work with product managers across the organization, each jockeying to put items at the top of the team’s priority queue. In that case, the final decision maker is usually either an engineering lead on the team — even for product work — or the overall product lead of the individual product managers.
  2. How much time do engineering teams allocate to technical projects versus product work? I’ve found that it’s often helpful to set aside a certain percentage of a team’s time per quarter (usually around 10–15%) to focus on tech debt, refactoring, architecture improvements etc. The specific work that’s done within that bucket of time is, of course, up to the engineering leads and engineers on the team. You might want to adjust this upward or downward in certain quarters depending on other constraints (for example, a major architectural overhaul is nearing completion and needs more of the team’s time next quarter, or a major release is coming up and more of the team’s time needs to be on product related work).


Running on rails (CC0 1.0 license)
  1. What percent of project X is complete?
  2. What are the key blockers and what is being done to resolve them?
  3. When is project X going to ship?
  1. Does the team have the discipline to break large projects down into smaller pieces with intermediate milestones? Teams are often reluctant to do this because it takes too much effort to break everything down into a sprint sized “ticket”. However, I’ve found that it’s worth pushing to have at least some intermediate milestones, even if they are not at sprint granularity, and to check in on the progress of those milestones during your execution tracking meetings.
  2. Conversely, does the team have structures in place to work on more exploratory, long-term projects? Some projects are inherently hard or impossible to break into smaller milestones, and the team shouldn’t feel so constricted by the Agile process that they lack the ability to work on longer term projects without immediate payoff. In my experience, teams over-use the “it’s hard to break down” explanation, but it’s worth being able to recognize when that is indeed the case.

Feedback Loops

Alignment can lead to spectacular outcomes (CC BY 4.0 license)



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Abhijeet Vijayakar

Abhijeet Vijayakar

Current: Hippo Insurance. Previous: Google Assistant, Trulia/Zillow, EA, startups. Engineering leadership and navigating ambiguity. Create, learn, repeat.