Skip to content
Search

Project Management

lastmod 2026-05-14created 2014-02-0345 edits

Project management refers to activities aimed at the successful completion of a project. This includes planning each activity that makes up the project, drawing up schedules, and tracking progress.

Categories

Software

Milestone

A milestone is a notable event or marker in the course of a project. For example, it refers to important points that must be passed for the project to succeed, such as contract signing, kickoff, staffing, receipt of the advance payment, interim reporting, audit, completion, and receipt of the balance payment.

Milestones are used to check points that are essential for project schedule management. By checking the items essential to project success at each stage, they help manage the project so that the overall schedule does not slip and the work finishes on time. However, because milestones only check the critically important key items in the course of a project, they have the disadvantage that it is hard to grasp in detail the various elements that are not that important but still necessary for the project to proceed.

Schedule estimation tips (by LCW)

  • Read the planning document very carefully.
  • Based on the planning document, list as many of the features to be developed as possible.
  • Estimate in hours, not days.
  • Multiply the estimated hours by 2. If it is your first time, multiply by 2.5.
  • Forecast the schedule assuming a 5-day week and a 5-hour day.

Korean: 인적 자원 관리

Human resources must be managed.

Each individual's abilities should be quantified for quantitative comparison/calculation.

Work processes for systematic project management

In one line: "you have to build a system and turn it into manuals"

  • New hire training manual
  • Work manual/Company-wide processes/Work flow/Onboarding manual
  • Culture book - A guide to our company's jobs and culture
  • IR
  • <del>Financial statements<del>

Don't raise your voice; grow your system. Good processes bring good results. -> "#Work process blueprint"

Work process blueprint

  • Customer actions
  • Employee actions
  • Support

Specific points:

  • Effect Spot (the point that produces results)

Effective positioning for engineering managers

The key question for an engineering manager is how much to be involved in coding, and this is not simply a matter of personal preference or resource allocation but a matter of positioning

  • Positioning is a concept from military leadership; it is effective only when situational awareness and operational clarity are kept in balance
  • Four positioning zones:
    • Crisis mode (low situational awareness, low operational clarity) → learn & stabilize
    • Ambiguity (high situational awareness, low operational clarity) → lead by example
    • Flying blind (low situational awareness, high operational clarity) → passive coding
    • Clarity (high situational awareness, high operational clarity) → set strategic direction
  • In the long run, prioritizing situational awareness is the foundation of team success, and coding is used at certain points as a strategic tool for gaining situational awareness and supporting the team
  • What matters is not finding a fixed answer but flexibly adjusting your position as the environment changes

The concept of positioning

  • Positioning is the leader deciding where to stand to exercise command and control
  • Too far forward and you get buried in details; too far back and you lose sight of the situation, weakening command
  • Engineering managers, too, should shift the coding question from "Should I?" to "Where should I be positioned so the team can succeed?"

Positioning framework

  • Two axes: situational awareness and operational clarity
  • Four zones:
    • Crisis mode (Low SA, Low OC)
      • Both manager and team lack understanding; execution is disconnected
      • First stabilize by setting short-term goals, then gain technical and team understanding through hands-on coding
    • Ambiguity (High SA, Low OC)
      • The manager understands well, but the team is confused
      • Work directly with the team, lead by example, and build trust and accountability
    • Flying blind (Low SA, High OC)
      • The team runs well, but the manager lacks technical understanding
      • Gain understanding quickly through limited coding such as bug fixes and production support
    • Clarity (High SA, High OC)
      • The ideal state; the manager focuses on strategy, risk management, and culture building
      • Complacency is dangerous, though; limited coding involvement is possible to detect changes

Positioning is dynamic

  • The zone changes with the team's situation and the external environment
    • Sudden outage → switch to crisis mode
    • Change in business direction → move to the ambiguity zone
  • So rather than staying in a fixed position, the manager must continually check and adjust their position

The primacy of situational awareness

  • In the long run, strengthening situational awareness is the top priority
  • Clear goals and role definitions are only possible on a foundation of situational awareness
  • Coding is a useful means of quickly gaining situational awareness or directly solving the team's problems

Conclusion

  • There is no right answer to how much an engineering manager should code
  • What matters is diagnosing the team's current situation (situational awareness vs operational clarity) and taking the matching position
  • Coding is effective when used as a leadership tool rather than simply for productivity, and through it you can build high-performing teams

Guide to using AI in management work

Performance Assessments

  • Performance reviews feel hard because many managers are not yet proficient in management fundamentals
  • Writing performance reviews is a core activity that tests a manager's precision of expression and empathy, and a key training process through which managers grow
    • A great manager should be able to deliver feedback improvisationally and smoothly, like playing jazz
    • This ability is the product of long-term training, formed through thousands of hours of awkward and difficult conversations, polishing sentences, and the stress of trying to communicate precisely
  • A performance review document is a microcosm of management that demands precision, empathy, and strategic thinking all at once; handing it off to AI is like taking a shortcut that skips the workout, a choice that reduces the manager's own growth gains to zero
  • Relying on AI gives the team plausible-looking documents, but the manager loses a real training opportunity
  • Performance reviews are not only a tool for the growth of direct reports but also a means of improving the manager's leadership skills
  • Resume screening: AI use recommended; once rules are set, it is effective for screening large numbers of candidates
  • Recruiting (selling/persuasion): A core management skill that must be done by a person directly, and repetition is essential
  • Process design: Most workflows are generic frames, so AI drafts can be used; this is a repetitive, standardized area
  • Process operation: Some automatic notifications and compliance checks can be automated, but running meetings and managing the backlog are important opportunities for the manager to learn the team's rhythm
  • Performance management: An area that must be done by a person; feedback is close to craftsmanship
  • Career growth guidance: Use AI as a sparring partner to gather ideas, but final design and execution are up to the manager

Core principles

  • Use AI only for repetitive tasks with clear right answers
  • Managers can only grow by experiencing and wrestling with situations involving ambiguity and human behavior themselves
  • AI is only an assistant; there are areas where it cannot replace a manager's leadership and growth experience

The Product Engineer

Software engineering in the traditional sense is coming to an end, and an AI-based product engineering paradigm is emerging

  • A product engineer is a hybrid role combining product manager and full-stack developer, an autonomous, outcome-oriented builder responsible for the entire cycle from planning to deployment
  • Based on AI-native, T-shaped skills and KPI-driven thinking, they are organized by feature rather than by team and take end-to-end responsibility for things like onboarding, payments, and notifications
  • In the product phase they do ideation, market analysis, user research, and product design; in the engineering phase they handle architecture, system design, and frontend and backend development
  • AI becomes a powerful tool especially in definable and deterministic (D&D) areas, and organizations are likely to evolve from the existing PM-designer-engineer triangle into a product engineer + AI collaboration structure

What I learned running Toss's 140-person frontend chapter

People make an organization excellent, but systems make it last

  • A write-up of experience running a large organization, reflected on over two and a half years as lead of the Toss frontend chapter
  • The Toss frontend chapter is a large organization: 250 people counting the community, 140 in the core chapter alone
  • Argues that the rules of the game are different at 10 people versus 140, and that the lead's role must change from "caring for people directly" to "building systems"
  • Presents a 6-stage flywheel for building an excellent organization (inflow → metacognition → providing opportunities → recognition → contribution → branding)
  • Concretely introduces the systems actually in operation at each stage (skill tree, Next F-Lead program, open source committee, etc.)
  • The key message is that "building an organization that runs without me is true sustainability"

As scale grows, the rules of leadership change

  • At 10 people, the lead could directly understand each member's strengths, growth curve, and motivation
  • At 140 people, there are cases where you don't know who is in the chapter even though it is the same chapter
  • A lead's personal effort covers it to some extent, but as headcount grows further, a moment inevitably comes when it becomes impossible
  • Information about individuals becomes fragmented across several leads' heads, and depending on whether they interact with a lead, some people become more visible and others less so
  • So the author concluded that the lead's role must change to "building systems that make the organization excellent on its own"

Designing the 6-stage flywheel

  • Applies the flywheel effect from product development to running an organization
    • It takes a lot of energy at first, but once it spins, momentum lets it produce big results with less and less force
  • 6 stages: inflow → metacognition → providing opportunities → recognition → contribution → branding
    • The final stage, branding, connects back to inflow, forming a virtuous cycle

8-step roadmap for building company manuals

Step 1: Prioritize which tasks to turn into manuals

  • List the repetitive tasks the CEO does
  • Score them on 4 criteria (frequency, pain, impact, simplicity)
  • Write manuals for the highest-scoring tasks first

Step 2: Classify tasks into 5 core functions

  • Sales/marketing: Work that makes money (scoring goals)
  • Operations: Service delivery and fulfillment after the contract
  • Finance/administration: Contract management and money management
  • System management: Manual management and HR
  • Planning: Setting the company's direction and vision

Step 3: Set the overall skeleton of the manual

  • Together with the people doing the work, simplify and structure the work process into 3–7 steps

Step 4: Write manuals that get results no matter who follows them

  • Core principle Write it so that anyone off the street gets results
  • State the purpose of the task Provide context on why this work is done
  • Triggers and completion criteria Clearly define the start and the end
  • Use concrete language No guesswork words (e.g. 'thoroughly' -> 'until no moisture remains')
  • One-step action principle Break it down to an almost childish level
  • Use action verbs Describe in terms of actions, such as 'click' and 'enter'
  • Use video If video is faster than text, record it and link it

Step 5: Test it

  • Give only the manual to an employee who doesn't know the task and have them do it
  • Revise until no questions come up

Step 6: Follow it ruthlessly, as an iron rule

  • Follow the manual ruthlessly, like a constitution (no compromises)

Step 7: Improve it flexibly

  • If there is a better, more efficient way, reflect it in the manual immediately

Step 8: Strengthen the system; fix root causes, not symptoms

  • When a mistake happens, don't blame the person; fix the system (the cause)

See also

Favorite site

author Zer0 sitemap