engineering-management-101

Summary of all things related to management or self-help

Project Management

Management 101

Team Leadership

Project Management

Phoenix Project Summary

Concepts

The Phoenix Project is a wonderful introduction to several key concepts.

The Four Types of Work

Erik starts by sending Bill on a journey to uncover the four types of IT work. Bill identifies the first three types reasonably quickly but finds the fourth type more elusive. It isn’t until the damaging nature of the fourth type is understood that the team can start to turn the tide.

• The first type of work is Business Projects, which help drive business processes and initiatives. These generally involve new features aimed at providing new capabilities or efficiencies for customers. These are driven by business leaders and can be managed as projects, and are usually not tracked centrally, but instead managed by individual budget owners.
• The second type of work is Internal Projects. These are generally smaller bits of regular work that accumulates over time: maintenance and upgrades of existing systems, retiring old technology, security patches, and so on. This is the work that keeps the company functioning. These can also be planned and run in a queue of work.
• Changes are the third type of work and encompass bug fixes, version changes, and any improvements that are generated by the first two types of work. These are the routine updates and support that arise from the simple existence of more applications and infrastructure.
• The fourth and most damaging type, Unplanned Work, is work that is necessary because other work needs to be redone, and it throws different types of work into chaos. This is the insidious, invisible work that makes other planned commitments impossible to meet because it slows or blocks other kinds of work. Due to its detrimental effect on the other three types, Unplanned Work needs to be avoided at all costs. The point of this journey is to make it clear to Bill that making work visible is the first step in starting to make sense of it all. If existing commitments across the organization are not understood, it can’t be coordinated to ensure that the priorities of the broader company are being met.

Work in Process (WIP)

Erik teaches Bill that WIP is one of the root causes of chronic problems with delivery and quality. Failure to control WIP results in the slow, inevitable death of productivity within organizations. The Phoenix Project is a study of how concepts like Lean Manufacturing or the Toyota Production System are much more pertinent to modern software development than most software engineering professionals may think. This has proven to be accurate as a generation of software engineers have adopted those ideas and made considerable gains in terms of productivity and quality. Many Agile software development methodologies, such as Scrum, incorporate these concepts as well. WIP boils down to focus — or lack thereof. Instead of working on multiple things at once, work on one thing at a time, and do it well the first time. That way, fewer mistakes are made, and the less work needs to be redone. Any action that has to be repeated is deemed “waste” because the work performed the first time must be discarded. Lean is organized around the idea that organizations should continuously reduce waste so that the resources saved from that can be redirected to other endeavours, such as making the process more efficient, improve tools and procedures, and conduct experiments to create new features or products. The Phoenix Project just scratches the surface of Lean, as it merely demonstrates how these practices can be applied to software development.

Kanban Boards

Bill and his colleagues eventually counteract the effects of excessive WIP by creating kanbans around their teams, thereby making work visible and allowing them to prioritize the most valuable work. In particular, Brent’s time is carefully guarded so that he can work on the right task. Kanban roughly translates to “signboard” in Japanese. The basic idea is to create an easily visible board with every phase of your process marked from left to right. Each work item is represented by a card associated with the person(s) doing the work. As the work gets completed, the card moves to the right until the work it represents is completed. The idea is that making work visible allows the team to see the big picture around the work being done. Doing so makes the process very easy to follow, fosters better collaboration, and makes WIP very obvious.

Ten Deployments Per Day

As the efficiency gains and improvements to the development pipeline accumulate, the Parts Unlimited team gets to the point where they can deliver much faster than the quarterly releases they started out with. However, ten per day still seems out of reach to the team. Eventually, they come to realize that small increments of work that are delivered frequently allow the company to maximize throughput and creates the flexibility to respond to customer demand quickly. “Ten deploys per day” is a famous rallying-cry of the DevOps movement. It refers to the ability to deploy changes to production multiple times per day, as opposed to quarterly, monthly, or weekly. It’s not meant to be taken literally, but rather as a milestone indicating that an organization is on its way to reaching a competitive pace of delivering changes into a system. Unicorn companies such as Amazon and Google are famous for releasing thousands or hundreds of thousands of times per day. One nuance is that this doesn’t necessarily mean actual deployments, but rather the ability to. Continuously deploying may be rare with new features, but bug fixes or critical patches are kinds of updates that need to flow through the system quickly and safely. Overall, The Phoenix Project lightly touches on this concept by illustrating the problems that arise when deployments are a significant undertaking versus smooth-flowing work when this milestone is achieved.

The Theory of Constraints

It isn’t until Bill begins to grasp The Theory of Constraints (TOC) that he begins to point the organization in the right direction. This is because many of the remedial actions his group takes are only temporary — without changing the way that the org works, the same problems will eventually occur. By applying the TOC, they identify the actual bottlenecks in the system and introduce the practices and processes to continually improve the flow of work and shift to a more strategic approach. The TOC can be broken down as the continual identification and removal of bottlenecks in any given system. To be able to apply this, an understanding of the system itself must be acquired, which means understanding each step in the process. This is deceptively hard because these steps are often hidden in peoples’ heads. Until those steps are listed, understood, and mapped out in a sequence, it’s tough to establish a repeatable process that results in consistency and quality. A practice called value-stream mapping is often the first step in applying the TOC. This is precisely what Bill and his colleagues use to understand the flow of the work. From there, they are able to unblock the system enough to accelerate the flow of the work.

The Three Ways

Erik spends much of the book mentoring Bill through the understanding and application of The Three Ways, which is the underlying model that makes The Phoenix Project so powerful. One of the authors describes The Three Ways as:

…the principles that all of the DevOps patterns can be derived from, which we’re using in both the “DevOps Handbook” and “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.” We assert that the Three Ways describe the values and philosophies that frame the processes, procedures, practices of DevOps, as well as the prescriptive steps.

To understanding the model, imagine all work, from inception to delivery of the final product, as a series of steps that flows from left to right. This work represents the delivery of any value to customers. The notion of “value” is fluid: it can be an app, a service, a physical product — basically, anything that a customer finds useful. This flow is referred to as the value stream. The Three Ways are a way to approach maximization of value delivery by optimizing the value stream to the customer, gaining faster and deeper insights by putting monitoring mechanisms in place, and by improving and finding new values via experimentation. The Three Ways can be broken down as:

• The First Way — Continuously find and implement ways to improve delivery. This is synonymous with the concept of Kaizen.

• The Second Way — Get fast feedback and work from strong failure signals to ever-weaker failure signals to get advance warning of quality issues.

• The Third Way — Use the efficiencies gained in The First Way and the safety enforced by The Second Way to introduce rapid experiments that help create qualitative gains. The idea is that by following The Three Ways, your company will outpace competitors by orders of magnitude and will win in the marketplace by creating value for customers superior to its competitors.

Management

Managers Path Summary

Chapter 1 - Management 101

What to expect from a manager:

• Grow your career:
• Help find the training/conf/books.
• Find “stretch” projects.
• Feedback.
• Figure out what you need to learn.
• Understand what to focus on and enable you to have that focus.
• Take your manager’s job.
• Find a sense of purpose in day-to-day by connecting what you do with the overall picture.

1-2-1 purpose:

• Create human connection.
• Discuss privately.
• Not a status meeting.
• Must be regular.

Feedback:

• Public for praise, private for criticism.
• Behavioural feedback.

How to be managed:

• Spend time thinking about what you want.
• You are responsible for yourself.
• The only person you can change is yourself.
• Asking for advice is a way of showing trust and respect.

Chapter 2 - Mentoring

• Listening is a precursor to empathy.

Chapter 3 - Tech Lead

• Not a point in the ladder, but a temporal role.
• At least 30% time coding.
• Main new skill: project management.
• Learn how to balance your time of tech work vs management work.
• If you want autonomy over your work, you must gain mastery over your time.

Tech Lead roles:

• Software developer.
• System architect.
• Business analysts.
• Project planner.
• Team leader.
• Expect the tech lead position to be a big increase in responsibility and workload.

Project management is a necessary pain:

• Break deliverables into small tasks.
• Sort task in the most efficient way.
• Push through unknowns.

Successful team leads excel at communication:

• Read/write.
• Speak/listen.
• Note taking.

Chapter 4 - Managing People

New hire:

• First 1-2-1 questions.
• Create a 30/60/90 plan.

1-2-1 styles:

TODO list:

• Professional and efficient but cold.
• Forces to think beforehand.
• Items to discuss should be worth the face to face time.

Catch-up:

• Listen to what report thinks is most important.
• Careful with too much complaining.

Feedback meeting:

• Quarterly enough for career development.
• Review process towards goals.
• Progress report (when managing managers).
• Get to know your report at a personal level.
• Take notes in a shared document.

Delegate effectively:

Do not “intervene” if:

• Team is making progress on its goals.
• System’s are stable.
• Product manager is happy.

If a team has no goals, use what you want to monitor to help them create one.
Gather information yourself from system instead of asking the team.

Continuous feedback:

• You must know your people.
• Forces you to pay attention to individuals.
• Makes it easy to foster talent.
• Practice tricky conversations in the small.
• Weekly for everyone who reports to you.
• Start with positive feedback.

Performance reviews:

• Include the whole year: summarize the 1-2-1.
• It is not a one hour process, but much longer.
• Use concrete examples to avoid bias.
• Spend plenty of time on accomplishments.
• Keep the areas of improvement focus.
• Real potential in people show itself quickly.
• Keep an eye out for opportunities for your team members to stretch themselves and grow.

Chapter 5 - Managing a team

New set of skills and challenges.

Engineering managers:

• Must be technically credible to get the respect of the engineering team.
• Keep contributing to code so you can see the bottlenecks.

Dysfunctional teams:

• Not shipping: Tools/processes poor.
• People drama: negative, brilliant jerk, gossip.

Unhappiness due to overwork:

• Pay tech debt.
• If time-critical release:
• Play cheerleader.
• Cut features.
• Push back date.
• Contribute.

Collaboration problems:

With other teams:

• Regular catch up with peers to work through issues.
• Actionable feedback.

Within the team:

• Team building activities.
• Learn enough about the product and customers.
• Long term vision of technology and product.
• Create a safe environment for disagreement to work itself out.

Managing conflict:

• Don’t rely exclusively on voting.
• Set up clear process to depersonalize decisions.
• Don’t turn a blind eye on simmering issues.
• Don’t take it out on the other teams.
• Be kind, not nice.
• Don’t be afraid of conflict.

Psychological safety:

• you are willing to take risks and make mistakes in front of others.
• Don’t hire brilliant jerks as it is too difficult to get rid of one.
• Get rid of the people that don’t respect you as a manager, or the team.

Non-communicator:

• Raise his habits asap.
• Find the root cause of the hiding.

Advanced project management:

• Use agile for short term.
• 10 productive weeks per quarter.
• Budget 20% for tech debt.
• Cut features as deadline approaches.
• Spend time planning and estimating.

Chapter 6 - Managing Multiple Teams

• No more coding. You will miss coding.
• Be fluent in at least one programming language before taking this role.
• Manage your own time: Eisenhower Matrix.
• How much time did you spent on non-urgent but important tasks?

Delegate:

• Simple - Delegate (if Frequest) Do it yourself (if Infrequent)
• Complex - Delegate carefully (if Frequest) Delegate for training (if Infrequent)

Delegation is essential for career growth.

Ways to say no:

• “YES, AND …” state what would require to say yes or what it will impact.
• Create policies that clearly define what is needed for a yes.
• “Help me say yes”: ask questions.
• “Not right now”: you must do something later.
• Ask a peer to say no in your behalf.
• Don’t delay saying no.

Your technical focus at this level is to improve the system of work that your developers are operating within.
Durable teams are built on a shared purpose that comes from the company itself, and they align themselves with the company’s values.
As a manager, your first team is not the people that report to you but your peers.

Ask yourself:

• Can I do this faster (by cutting scope)?
• Do I need to be doing this at all?
• What value am I providing with this work?

Chapter 7 - Managing Managers

• Same as managing multiple teams, but an order of magnitude bigger. New set of skills.
• Things are obscured by the additional level of abstraction.

Skip-Level meetings:

• Critical to build trust and engagement.
• Either quarterly 1-2-1 or group lunches.
• Prompts in page 129.
• Open-Door policy does not work. Managers should make your life easier, by bringing clear problems before they turn into raging fires.
• Make managers accountable for their teams.

New managers need a lot of coaching:

• How to do 1-2-1.
• How to let go previous work.
• How to not become a control freak.
• Find external training.
• Management is a very culture-specific task,
• Hence is better to promote people that has been in the company for long and already understand the culture.
• Culture fit more important than industry-specific knowledge.

Hiring managers - Page 140:

• Do reference checks.
• Managing outside your skill set: be curious, ask questions, learn. Boring meetings are a sign of dysfunctional teams.
• People need to feel an understanding and connection with the purpose of their work.
• Your technical responsibility is to optimize tech investments by matching it to future product or customer needs.

Chapter 8 - The Big Leagues

As tech senior managers, we bring a willingness to embrace and drive change as needed.

Be a leader; your company looks to you for:

• What to do.
• Where to go.
• How to act.
• How to think.
• What to value. Make hard decisions without perfect information.
• Understand current business landscape and plan for possible futures.
• Hold individuals/teams accountable.

4 tasks:

• Information gathering or sharing.
• Nudging.
• Decision making.
• Role modeling.

Possible roles:

• R&D.
• Tech strategy.
• Organization.
• Execution.
• External face of technology.
• Infrastructure and tech operations manager.
• Business executive. CTO must care about business and shape business strategy through the lens of technology.
• CTO without management responsibilities will have little influence.
• To make something top priority, ou need to explicitly kill or postpone in-flight work.
• You need to communicate things three or more times before it sinks.

Setting strategy:

• Improve operational efficiency.
• Expand features.
• Grow the business.

It entitles:

• Tech architecture.
• Team structure.
• Understanding direction of business.

Delivery of bad news:

• Do it by individuals or small groups.
• Must be in-person.
• Don’t force yourself to delive if you cannot stand behind it.
• Be honest.

CEO as a boss:

• Getting 1-2-1 time is a challenge.
• Bring topics, set up agenda.
• Bring solutions, not problems.
• Ask for advice.
• Don’t be afraid of repeating yourself.
• Be supportive.
• Look for coaching and skills development in other places.

Your team:

• Peers in other functions.
• First focus on the success of business, then on their departments.
• You trust them as experts in their areas.
• You trust they are not trying to undermine you.
• Disagreement in leadership team is ok, but once a decision is made, team shows a united front.

You need to detach from your previous team:

• Avoid having favourites.
• People to take you seriously.
• People will copy your behaviours.
• Your presence will change the behaviour.
• Do not discuss uncertainty with your old peers.
• Care even more about individuals.
• True North: core principles that a person in a functional role must keep in mind as he does his job.

Chapter 9 - Bootstrapping Culture

• You need an hypothesis to learn from new processes and structures.
• Structure allow to scale, diversify and take on more complex long-term tasks.
• We learn the most from failures: examine failures to decide what structure needs to be added.
• Culture is how things get done, without people having to think about it – Frederick Laloux.
• You will be measured against the company’s values.
• If your values are not those of the company, you will struggle.

Culture:

• Map company values to tech team, maybe adding a couple that are specially important.
• Reinforce by rewarding people that exhibit the values in a positive way.
• Use when hiring.
• Create a career ladder - Page 202.
• Process is risk management.

Conclusion

• You have to be able to manage yourself if you want to be good at managing others.
• You need to understand yourself.
• Masters of working through conflict.
• Meditate.
• Get curious.
• Look for the other side of the story.

Team Leadership

Five Dysfunctions of a team Summary

https://internalchange.com/5-dysfunctions-of-a-team-summary/