Useful engineering management artifacts

When managing a growing organization, it can be useful to have certain document templates on hand. Here’s a collection of documents I find useful, along with some notes on how to use them, and a link to a template if I’ve got one. Obviously, you should tweak these for what makes sense for you and your organization.

Many of the linked templates have been adapted from other posts or places I’ve worked. There are plenty of other examples on google, and I’ve found AI tools like ChatGPT can be helpful in tweaking or creating new ones, but hopefully you’ll find these practical since they have been tested in the real world.

• Career development plan. Although having an unstructured conversation about career goals and so on can sometimes be sufficient, especially for those who aren’t looking to uplevel anytime soon, having a template to structure conversations around career growth can be invaluable. A template can push your conversation in the right direction: you want to understand your report’s goals, and you want them to understand your expectations clearly. I find this template helps steer a conversation about aligning personal development and company goals.
• Title Ladder. No matter how small your organization, it pays to at least be thinking about what a proper title ladder would look like. Forethought can spare you from assigning incorrect titles to early employees, inadvertently treating people unfairly, or creating incorrect expectations. Once you have around twenty engineers, it really pays to have a formal, written title ladder. The consistency a written ladder provides can align individual achievement with company goals, and can be a tool to align everyone’s incentives, reward and recognize achievements and generally foster transparency and fairness. Example Great article about title ladders in engineering
• Team Charter. A team charter is an agreement between team members about how they work together. In my experience, a team charter can help prevent and resolve a lot of problems and help teams work better together. However, because it is often not referred to after it’s written, it can feel useless. I think it’s helpful for everyone to understand that the real value is not the finished document, but rather the process a team goes through to write it together. It helps everyone buy in to the team process. It ensures everyone makes a commitment to each other about how they are going to show up. Consider revisiting the team charter regularly, and when the structure or goals of the team changes. Template
• Engineering Strategy. Some have argued that a template can be counterproductive for developing a strategy, and I agree that relying on one too much can make it too easy to avoid the hard work of developing a strategy. Nevertheless, you should have a written strategy. I don’t have a template I really like, but I do have an article on what makes strategy effective, which might help you write one without a template. Effective Strategy
• Team Roadmaps. Every team should have a clear and up-to-date roadmap. Ideally, these should all be in the same format so leadership can easily review it. I don’t have a template ready to share, but here’s an article about creating roadmaps.
• Satisfaction survey. Ideally, as a manager, you have a good pulse on how people are feeling, but there are often problems that don’t bubble up, or trends that are hard to monitor. Surveys can fill in the gap and also help provide much needed quantitative data. I like to ask questions like:
  • On a scale of 1 to 5, how much do you agree with these statements:
    • I enjoy being part of the [company name] team
    • My voice is heard when I have an idea or concern
    • I am able to get things done, and am not hindered by bureaucracy, unnecessary process or “red tape”
    • I feel like part of the team ¹
    • My teammates are helpful and supportive
    • The work I do is meaningful to me
    • I am proud of the work I do
    • My manager has my best interests at heart
    • I understand how my work contributes to the company’s goals
  • Are there any meetings you feel could be structured better?
  • Are there any areas where you need more support or feedback from your manager?
  • What are your favorite parts of working at [company name]?
  • What are your least favorite parts of working at [company name]?
• Decision Brief. Some companies have a document that addresses decisions that need to be made. This is obviously useful to CYA on a risky decision, but is also helpful for getting things done when there’s some disagreement or ambiguity, and making sure everyone is bought in. I strongly recommend every company have some process for making and documenting major decisions. A word of caution, though: I’ve seen this specific document abused more than any other. Some territorial or defensive managers (or people who have trouble communicating their concerns effectively) will avoid giving feedback and instead tell people to write a decision brief which they never approve. Don’t use documentation and process to stonewall decisions or avoid face-to-face conversations, or deliver hard news. Template
• Review Brief. I like to use this simple 3-part template when I need something reviewed:
  • List of items to be reviewed with links or attachments (Make sure everyone has access to the docs).
  • Deadline and desired feedback format (could be email, or comments on the document or something else).
  • Decisions or feedback needed (this is a great way to focus on the feedback you need not the feedback others want to give).
• Product Brief. Before you start building, everyone needs to be on the same page about what’s being built and why. The product brief materializes this effort. There are a lot of excellent product brief templates out there.
• Engineering/Tech Brief. Depending on the size of your org, you may want to have multiple versions of this for projects of different sizes / impact. In my last position, we started with a short version. Once that was passed around, we decided if we needed a longer version, or, in extreme cases, an RFC which we managed in github. This worked very well, and wasn’t too onerous.
• Engineering Post-Mortem. When an incident occurs, you want to make sure all relevant parties understand why it happened, how it was fixed, and what the team is doing to prevent the same problem from happening again in the future. I like the rule that the on-call engineer is not responsible for writing the document, but they are responsible for making sure it gets written by someone and distributed to the appropriate parties. Template

Footnotes

1. I have used feeling of team membership as my north star when dealing with remote workers, especially if there’s a mix of remote and local team members. This helps me know if they need any special treatment separately from local teams. ↩