JJ

README

Goals of this Document

  • Reflect on my approach to leadership and help me define my management style
  • Provide everyone who works with me context that will help us build a positive working relationship.

What I think success looks like

Our colleagues view our department as one of the best, good ideas get timely investment and execution, and everyone in the department has a well-informed idea of what the most important projects and next actions on those projects are. We know how to make things better and can have fun doing it.

As CTO

How I see my role

Supporting the growth of autonomous, responsible, healthy teams that deliver meaningful results towards company goals without leaning on heroics or burning people out. Some of the things for which I'm responsible:

  • Responsive budgets and resource allocation.
  • Departmental strategic planning and organization.
  • Helping managers keep teams engaged and productive.
  • Identifying and supporting execution on complex cross-functional projects with potentially transformational outcomes.
  • Guiding changes to our systems so that the easy way to solve a problem is also the best and the safest.
  • Providing my colleagues with good, safe tools they can use to do their best work.

How I try to do that

  • Making important information readily available and engaging in open, honest communication.
  • Investing in good tools and automation.
  • Helping the team build up a shared, living, written model of the company's nouns, verbs, events, values, and opportunities.
  • Encouraging a culture of testing hypotheses by sharing context, making change easy, and fostering a considerate bias to action.
  • Treating everyone with respect.
  • Explaining the thinking behind a decision.
  • Use data rather than doctrine to identify areas for improvement.
  • Give more autonomy and authority to responsible, entrepreneurial people.
  • Treat project and product work differently. Project work has a clear, unambiguous end state, and can often be planned with high fidelity. Product work is more open-ended and exploratory, in pursuit of improvements, and can not be planned with high fidelity.
  • Look for opportunities to structure long-term work to deliver incremental value as it proceeds, rather than all at once.

Process

  • Good process helps people get more done, or prevents costly, irreversible mistakes. If you don't know how a particular process supports one of those goals, question it. We'll either make the connection explicit and written or get rid of it.
  • Process should be principle-based, not rule-based. Principles should provide you with a direction or intention, and are not strictly enforced to the letter. Everyone involved should be able to use their best judgment to make a decision about making an exception to a process principle and still be friends.
  • If you are following every step of the process to the letter and not making progress on a daily basis, it might not be a good process. Try changing your process until you are making progress.
  • Avoid cargo-culting your process: what works for Google/Spotify/Amazon/whomever might not work for you. There's always a chance it will work for you, but it's often better to understand the problem they were solving, and learn from how they iterated to a better process, than it is to try to apply their final, public version to your organization from the top down.

About Me

General ideas and approaches

  • Good-enough and timely decisions are often better than provably optimal and late.
  • There are no failed experiments – there's only data. What you do with that data is what's important.
  • It's better to make it easy to try something and undo it than it is to make it perfect.
  • Money isn't everything, but it's the one common base we can use to evaluate trade-offs in how we allocate resources. I'll try to make it easy to translate initiatives into money.
  • Set aside some time to keep your tools sharp and clean things up periodically.
  • The people closest to the problem are probably the best to solve it, so I'll prioritize supporting them.
  • Making a new rule should be the least-preferred choice for dealing with a problem. Rules don't solve problems; they put “caution” tape around them.
  • Steady, daily progress beats sporadic heroics.
  • Regular maintenance and attention to detail beats diving saves.
  • Late delivery is often caused by many small delays, not one big one. Pay attention to the small delays and minimize them.
  • Be aware of cognitive biases, and try to structure work to minimize them.
  • Be aware of cognitive load, and try to structure systems to be conceptually simple, with few moving parts.

Values

  • Empathy for users: work hard to understand their viewpoint, value their feedback, and give them intuitive, reliable, predictable systems.
  • Customer focus: I appreciate teams that can recognize when they're in the weeds, step back, and re-orient around the value they're trying to add for users.
  • Outcomes over process: we're here to make changes that help the organization, not tick boxes, schedule meetings, and send email. I appreciate people with the discernment to stay focused on GSD.
  • It's OK to make mistakes as long as it's not out of laziness.
  • If you express interest in career advancement and self-improvement – learning a new skill, taking on more responsibility – I will work hard to provide those opportunities for you, but I will not chase after you to make sure you make the most of them. Pay attention when I tell you I am giving you that opportunity and demonstrate initiative.

Communication

  • Please feel free to interrupt me if you feel stuck; I'm here to help.
  • I appreciate when someone seeking input on a decision has both an opinion and ideas about situations where the alternatives would be preferable.
  • I try to not to oblige anyone to monitor/respond to work messages outside of regular working hours unless it's an emergency, but if you are unsure if something is an emergency outside of regular working hours, I'd rather you contact me than waiting.
  • In general, I prefer written communication where possible, because it's more easily searched and shared.
  • It's OK to disagree! Please let me know if you have doubts or concerns with a plan or idea of mine. I'm happy to discuss it, and only in exceptional circumstances (e.g. emergencies) will I fall back on an appeal to authority.

Feedback

  • I'll do my best to provide timely feedback, not just at the end of the year.
  • If you ever feel like I'm getting in the way of you doing your best work, please let me know ASAP! I will never be upset.