How Project Management Will Make You A Better Tech Lead

Every company, startup, or business is a collection of projects. A project is a planned, logical unit of work with some expected outcome that contributes to an overall vision or strategy. It’s how we organize ideas, tasks, and even our personal lives.

Everyone should understand how to manage projects to some extent, particularly if you are in a leadership position. We’ll review some techniques to plan and organize projects, set them up for success and measure that success along the way.

Every Leader Is A Project Manager

There aren’t many companies where there is someone with the official title of “Project Manager”. In reality, any leadership role handles the team’s projects, so any leader is a project manager.

Engineering managers have many roles and responsibilities. We are planning technical roadmaps, hiring engineers, coaching, and expanding our team. And we are ultimately responsible for our team’s projects. Engineering managers should be able to organize and drive projects to success. Most of the time, engineering managers have to work with product managers, business managers, and program managers. Since your team is responsible for the execution, prepare to take full ownership and accountability of the project output.

For a project to succeed, you need to identify the right problem, sponsor, team, and process.

12 Principles

1. Understand The Basics

As a leader of your team, you have some control over the projects you’re committing to. Before taking on any project, you have to answer some basic questions:

• Why do we need to work on this project and why now? How does this project contribute to the bigger mission or goal? How does the output fit in our long term roadmap?
• Who are the stakeholders, sponsors, and customers? What expectations do they have, what concerns and problems do they want to solve with this project?
• What are the scope, expected outcomes, and output? What does success look like to you and the stakeholders? What is everyone’s definition of “done”?
• When do we start and finish the project? Is there a desired timeline for the entire project or specific milestones? Is it a hard deadline, meaning we can’t miss it no matter what? If it is then we need to understand why that’s the case — are there legal consequences, or a public announcement?

2. Know Your Frameworks

There are a few frameworks to organize a project, keep track of its progress, inform the stakeholders, and identify blockers:

• RACI. “Responsible, Accountable, Consulted, Informed”: Know your stakeholders, sponsors, and customers.
• 5 Project phases. Initiation, Planning, Execution, Tracking, Post Mortem, and Reporting.
• Agile. Scrum in particular — use prioritized backlog, organize the execution in sprints, deliver changes or features often. I recommend the book “Scrum: The Art of Doing Twice the Work in Half the Time” book to become familiar with the process.

Know these frameworks and understand how they can help the team, stakeholders, and yourself to organize, estimate, and deliver projects and manage expectations. Being organized and knowing all the details about the project’s current status is critical for engineering managers.

The most critical time is before the project has started. It’s the easiest time to influence its output. Good planning also includes identifying the risks and communicating them early on to keep any surprises to a minimum.

3. Motivate The Team

If planning is a shared effort, the execution is ultimately your team’s responsibility. They will architect it, write code for it, fix bugs, and will maintain the project for a long time. Engineering managers should support the team and create an environment for the team to succeed.

The team should be excited to work on the project. Otherwise, it’s just another boring task they have to complete. Your responsibility as a leader is to sell the project to the team and get their buy-in and support. When your team understands why this project exists, they can better understand the level of impact on the overall vision or strategy. They should see the connection between the project and the whole business.

Once they understand this part, they should come up with how to do it, as this gives them full ownership of the architecture and execution plan. You need to trust them and rely on them to get it done properly and on-time.

Create a culture of ownership and accountability. Give your team leverage to make decisions and push back on product and business if there is a disagreement. Only by being a stakeholder or a partner in the project is someone truly motivated to get it done. If it’s a top-down command, the motivation won’t be as strong, if it exists at all. Trust your team and be available to support them when needed.

4. Assign The Right People

Depending on your team’s structure, you will be responsible for assembling a team for a specific project. More and more companies use the project crew structure where engineers are part of a small crew to help stay focused for a period of time or until the project completed.

Some managers make the mistake of assigning their strongest engineers to critical or high profile projects to make sure it’s getting done. This may work for some time but is not always sustainable in the long term. By doing this, you’re burning out the strong engineers and not creating an opportunity for others to grow. Instead, consider putting more thought into who should be working on a specific project.

As a manager, you should know people’s strengths and weaknesses, as well as their career aspirations. Every project is an opportunity for engineers to learn, explore new areas, mentor others, and show some leadership skills. Pairing up strong engineers with less experienced ones creates a good balance and opportunities for all.

5. Kick It Off

A successful project starts with a proper kick-off meeting. Usually, it’s driven by a product manager. It’s your and the team’s opportunity to ask clarifying questions. Get on the same page about what success looks like, as well as the scope, timeline, and milestones. Challenge some of the decisions and assumptions. It’s also a great opportunity to put everything in writing. One-pagers are a great way to have centralized documentation about the project but remember it’s a living document and any new decisions or changes should be reflected appropriately.

6. Prioritize Backlog

A project is a collection of tasks, stories, and meetings. It’s important to have them written down and organized in a way that can be easily searched and tracked. Your team, including you, should work with your PM to finalize the milestones and create specific tasks and stories.

Estimating software projects is hard. It’s as close to guessing as you can get. That’s why you should avoid estimating entire projects, especially up front, with little context. Instead, as you create stories, estimate each one individually. There are different methods: T-shirt size, Fibonacci method, Numeric scale, etc. The goal of this exercise is to have an organized and prioritized backlog of estimated tasks.

Over time as you track the velocity, you should know how many points your team can finish in a sprint, month or a quarter. Your backlog is the execution plan, which you can track and measure at any moment. It is important to focus on the most important stories first. The features that provide the most benefit to your customers or business shouldn’t be delayed.

7. Focus On Architecture

As soon as you merge a feature or project codebase, it becomes a legacy code and eventually a technical debt. Not all technical debt is bad, but having too much of it can be deadly to your product. Like with financial debt, you have to pay interest. Too much debt and your finances will struggle because all you do is pay off your interest and not the principal.

As an engineering manager, it’s your duty to know how much debt you have and aim to minimize it all the time. Use every project, business initiative, and product objective as an opportunity to improve the health of your software. This means every single project has to have a portion of the architecture and refactoring in its scope. It won’t be easy to convince your business and product stakeholders on the importance of this. That’s why constantly educating how technical debt accumulates and affects the software is important.

In the business and corporate world, everyone has their own agenda. The business department wants to improve sales and revenue. The product group wants to get more customers, improve conversion rates, make the product more useful, and add new features. Engineers want software quality, stability, performance, security, and maintainability.

Nobody will raise their hand and ask you to write more unit tests. As a technology representative, you should keep pushing your agenda and make sure there is a balance between business, product, technology, and process. Don’t forget software is enabling business and product. Don’t chase the new shiny frameworks, and make sure there is a real benefit to the business. Avoid technology for the sake of technology.

Rather than asking to take your engineers away to refactor the code, it’s much easier to use the existing business and product goals and attach the technical work you need to perform. Asking for big refactoring projects indicates you haven’t been doing a good job maintaining your software.

8. Know The Status

Engineering managers are in constant communication with different people in the company. Anyone at any time may ask what’s the status of a specific project. You should know where all of your projects are at any given moment. It won’t be easy, especially if your team is bigger than 8–10 people.

To avoid questions or concerns, proactively resolve the blockers before they arise. It could be a conversation with some stakeholders, getting a piece of infrastructure set up for testing, or getting your project on QA engineers’ schedules in advance (before they get too busy).

The smaller your team, the more details you should know about your projects. For bigger teams, you should rely on tech leads for details and know the summary and potential blockers and issues on a weekly basis.

9. Negotiate Flexibility

Another way to think about a project’s success is expectations. The formula for success looks like this: success = results - expectations. In other words, underpromise and over-deliver. You have to manage expectations all the time—before planning and during the project execution. Always leave some room for unknowns and communicate the risks.

If you overpromise or commit to a project with a deadline that your team finds difficult to achieve, you’re putting a lot of stress on your team. Teams end up working nights and weekends to meet difficult deadlines because managers fail to negotiate and manage expectations. In most organizations deadlines and budgets are negotiable. It’s your job to negotiate reasonable goals with some breathing room. Engineers need time to work on unexpected things. Let them learn and experiment without fear of missing a deadline or failing the project completely.

10. Measure Success

When planning a project, start at the end. Understand what success looks like. If you don’t know what it looks like, it will be hard to tell when you get there or even if you’re moving in the right direction. The phrase, “eat the elephant one bite at the time” comes to mind — you can’t and shouldn’t execute projects in one bite.

Break down every project, even a small one, into small sub-projects or milestones and then further down to tasks or stories. We covered this process in the “Prioritize Backlog” section. Pick the process that gives a project status snapshot at any given time. Tools like Jira, Asana, and Basecamp have specialized views for that.

When measuring a project’s progress, there are five important metrics you need to keep track of:

1. Percent Complete. Are you moving fast enough to meet the target deadline?
2. Quality. Are you sacrificing quality for speed?
3. Budget. Are you adding more people to move faster?
4. Expectations. Are you working to produce the expected output?
5. Project outcome. Are you working towards the desired outcome?

Outcome doesn’t mean output. The project output is the final deliverable. The project outcome is the impact of the deliverable on the business.

11. Resolve Conflicts

Leaders are often driving change. This change could come in many different forms, such as total tech migrations, refactoring, changing the culture, re-organization, etc.

Whenever there is change, there is almost always resistance. Having conflict in a project is inevitable. The sooner you accept the fact that conflicts are normal, the better off you will be.

A difference of opinion is a sign of a healthy and diverse culture, as long as the conflicts are not personal and there is an opportunity to talk and defend one’s position. Managers can play a mediator role to control the conflict so it doesn’t spiral out of control. And don’t allow conflict to be a blocker. Sooner or later, a decision has to be made. If your team can’t agree on something, then it’s your responsibility to either pick the best choice or bring in an expert to make the call.

In fact, you should worry when your team never disagrees. This could be a symptom of fear-driven culture, a team’s disengagement, or their lack of interest in a specific subject.

Companies are designed to create conflict. Product, business, technology, marketing, and other departments have their own goals and priorities. Make sure you understand the other side’s priorities and goals. People rarely argue for the sake of arguing. Take the time to have a conversation and align their priorities with yours as much as you can. The goal is to have a win-win for all parties involved.

12. Be Retrospective

You can’t improve what you don’t measure. Retrospectives are your opportunities to look back, collect feedback, and use it for future improvements. Constantly seek direct or indirect feedback from your team and stakeholders. Remember not everyone is comfortable delivering negative feedback directly, especially to their manager. You need to make some extra effort to get constructive feedback, concerns, and suggestions.

Summary

An engineering manager wears many hats. One of their core responsibilities is to create an environment for their teams to thrive. Success, in the organizational context, usually means delivering the projects on time and on budget. Engineering managers must be able to plan, organize, and drive projects to succeed.

You can find me on Twitter https://twitter.com/netxm if you have questions or just want to say “hi”. And check out my personal blog.