Sunday, December 14, 2014

Some thoughts on managing teams of engineers and engineering-team leaders.

Give them autonomy and authority to make decisions & execute
 - No micromanaging. Tell them what the product is, and leave it to them to figure out how to get it done. (See below for more on this subject),
 - Teach process, techniques and tools for achieving success, and teach how to be on the lookout to prevent catastrophic and systemic failures,
 - Teach them how to efficiently and effectively recover from general failures (transient bugs, regressions, errors in interpreting product requirements not avoided by normal process & procedures),
 - Let your reports figure out the resourcing needed to execute. Do teach them how to be as efficient as possible, but too few developers on a project is almost as bad as too many.  (The work will get done, eventually; but timelines for delivery will stretch to unacceptable lengths and your too-small team will eventually wear-out).

Ask them to accept accountability for those decisions
 - To themselves,
 - To their product manager,
 - To each other: reports and peers,
 - To you, their manager,
 - Accountability as personal responsibility and pride in the work -- not as an instrument of fear: fear of failure, fear of losing their jobs, etc.

Provide tools with which to be accountable (if they don't have the tools already)
 - Tools for planning of work, tracking of work, measurement of success (as defined by the product team), tools for forensics and for quick and efficient recovery from failure.

Everyone should think and lead with solutions, not problems, especially in communications.
 - Define work caused by change as tasks to be done, and not as problems preventing progress:
    "Moving these systems will cause a whole bunch of tasks, which we'll identify and estimate."
    "There are a lot of problems caused by moving these systems. We don't know what we'll run into."
 - Recognize and teach the difference between proactive and reactive responses to change.

The answer is always "Yes".
 - The answer to (almost) every request for work is "Yes - and it will take [time] and [resources] to deliver by [date]."
 - Create a few options for the stakeholder: split the project into pieces, add or change some resources, etc.
 - It's crucial to provide stakeholders with the information with which to make informed decisions. Don't make the decisions for them by saying "No",
 - You may need to teach your teams (and yourself!) how to more accurately estimate work.  Estimation is a challenge for most developers to get right with regular frequency.

Teach them how to teach others
 - Help find the most effective teaching method that works for them.

Do not micromanage.
 - Find ways to help your staff make better decisions & to execute more efficiently & effectively,
 - Look for opportunities to improve every day,
 - "Make better mistakes tomorrow",
 - Get out of the way and let brilliant people be brilliant. You'll find out very quickly who's not up for the job & you can replace them when necessary,
 - Remove roadblocks, and no "back-seat driving",
 - Tell them what needs to be done. Do not tell them how to do it.
 - Trust your team-mates; start from a position of trust and respect and go from there.

Nothing happens if it is not planned, executed, and measured.  
 - Get the plans from the Product team. Ask questions, discuss, and agree on deliverable(s) and date(s). Plan!
 - Planning is a team sport - it is an ongoing conversation between Product and Engineering,
 - If it's not in a story/on a card in a project-management tool, it doesn't exist,
 - If it isn't assigned to a person, it does not get done,
 - All technical-debt gets a card, and debt-payment is considered for action in subsequent planning,
 - QA (Quality Assurance) is an engaged part of the product development process; "execute" isn't just programming, it's quantitative QA (automated QA testing and automated execution of test-scripts), qualitative QA (testing by human beings), and "UAT" ("User Acceptance Testing") by the representatives of the stakeholders: the product manager(s).
 - Measurement of bugs, regressions, ticket-completion velocity, and other engineering-internal metrics (some are more valuable than others, and YMMV),
 - Measurement of product-related key-performance indicators.

No comments:

Post a Comment