216ways.net

For the last 3.5 years, I've used Trello to manage product development projects. When used properly, I've found that Trello gives transparency into a development process and gives early warning of possible pitfalls.

But there are tricks to using Trello well. Though its concepts are simple, they can be applied in many ways, some more effective than others.

The big idea is to use Trello to organize detailed tasks in a way that makes sense at a glance. I've found this organizing process to be faster with Trello than with tools (e.g., JIRA and Asana).

Below, I'll cover some tips for how I've used Trello to manage projects.

Defining columns

The columns on a Trello board should represent the stages of your process. I've generally found it helpful to have a Backlog (or Next Up) column, an In Progress column, and a Built (or Done) column. Some processes also expose the need for other columns.

Tips

• Don't let your columns get too big! Big columns indicate that too much is happening at once, and they are a leading indicator of delay, which is surprisingly expensive. Surfacing these sorts of traffic jams is the most important thing that Trello can do. Don't start new work if your columns get too big. Unblock stuck projects and get them done! See this series for more information.
• Columns should represent your true process and not the process that you wish you had. If every feature gets tested manually, then you need a Needs Testing column. If that column explodes regularly, it's a good sign that you either need to staff up on QA or automate testing, or both.

Defining cards

Each card should express a customer-visible deliverable.

Tips

• Cards should make sense to the whole team, including designers and managers. "Launch scheduling notifications" is a good card. "Add push_server to constants.py" is too detailed.
• Split cards when their scope gets too big. Delivering some functionality sooner is usually more valuable than delivering a lot of functionality later. Splitting a big card into small cards focuses the team on delivering sooner.
• Split vertically when possible. Splitting "launch scheduling notifications" into "API work for scheduling notifications", "web work for scheduling notifications", and "notification pipeline work for scheduling notifications" is a horizontal split of work. Finishing one of those cards doesn't allow you to ship anything sooner. "Launch scheduling notifications by email" and "Launch scheduling notifications by SMS" is a vertical split. Each of those sub-cards can deliver something valuable to customers.
• Allow multiple people to work on cards. The team's focus should be on delivering results and not on "getting my work done." When multiple people work on a card, it's likely that team members are working together to deliver something.

Checklists

Checklists capture low-level tasks. I encourage people to track everything that needs to be done on a checklist. The audience for a checklist is the author and collaborators. People who aren't actually doing the work don't need to understand each checklist item.

Tips

• Individuals should track their tasks. It's so easy to add, edit, and complete tasks that individuals should always keep them up to date. Managers shouldn't need to maintain checklists for a team.
• Look at the trend in the number of incomplete tasks. This trend gives you a good sense of when you'll ship. Initially, most projects start with a small number of tasks — say 5 tasks, of which 0 are finished (5 incomplete tasks). As work begins, the team quickly discovers new tasks and adds them to the checklist. Perhaps that list of 5 balloons to 20 items, of which only 2 are finished (18 incomplete tasks). When the number of incomplete tasks is increasing, the team is still understanding the problem and you aren't close to shipping. When that number is decreasing, the team is polishing and getting close to finishing.

In summary

• Columns represent the structure of your workflow. When they get big, they predict delay. So don't let them get big!
• Cards should be understandable to the whole team, including managers.
• Keep cards small and "vertical".
• Multiple people can (and often should) work on a single card.
• Checklists tell you a lot about when a project will be done, if you keep them up to date.

It's common for first-time engineering managers to assume "player/coach" roles. They're doing all the activities of individual contributors, including writing code. But they're being evaluated as leaders.

This transition is a tough one. Despite continuing to do all the things that individual contributors do, player/coaches need to master a new set of activities. And they have to adjust to being evaluated on their team's performance and not just their own. It's tough to know when you're ready for the transition and it's tough to know when you're succeeding.

An indicator of success is whether people are choosing to follow you. Leaders are people with followers (credit to Joseph Ansanelli for expressing that simple definition to everyone at Vontu).

Getting followers requires putting your team above yourself. You need to ask yourself, "Why should somebody follow me?" Do you have a vision of success? Can you articulate it in a way that inspires others? Do teammates believe that you elicit their best thinking and best work? Do you help them get better at what they do? Do you help them feel proud about what they accomplish?

I think that some people are intuitively good at getting people to follow them. I'm not. I've found that I need to invest a ton of time and to think very carefully through those questions. That effort is entirely invisible to others and so it's sometimes hard to realize that it ever happened.

Followers are different from admirers. As a high performing individual contributor, you can rack up admirers for working quickly or for making good decisions. That's certainly evidence of high ability and good judgment, but it's not sufficient to attract followers.

When you commit to putting the team before yourself, you'll find that you acquire followers. And when you focus on your team's impact before your own, you'll get great results.

Though I worked with great VPs of Engineering at Vontu and Symantec, I had little idea of what they actually did every day. I'd read Mark Suster's classic post on the subject. Everyone should read it. But I didn't understand what kept the VP of Engineering up at night.

When I became the VP of Engineering myself, I realized that I am measured in three ways:

• Is the team delivering value?
• Is the team lowering risk?
• Does the team attract and develop talent?

To answer those questions, I find myself obsessing about 4 things:

1. Developing the team.
2. Creating alignment.
3. Ensuring fast, reliable execution.
4. Advocating for organizational scalability.

1. Developing the team

When I worked at Vontu, our CEO Joseph Ansanelli repeated a "wildly important goal" at every quarterly business review: hire and engage a great team. His post on the subject is worth a read.

Developing the team is the VP of Engineering's most important goal. If this part of the job is done right, nearly everything else gets easier. The right people will identify and solve the most important problems.

There's no science to developing a team. It's pure alchemy. It requires inspiring the team with a shared identity and vision of success. It also requires learning how to engage each member of the team. It's critical to recruit great people who make the team better. And it's sometimes important to ensure that some people leave the team.

2. Creating alignment

Everyone on the team needs to know why what they are doing is important for the business. If this were only a matter of communicating business objectives clearly, it wouldn't be that hard.

In reality, though, creating alignment involves a bunch of sausage making because there are a ton of constraints to navigate. e.g.,

• Short-term and long-term needs are often at odds.
• Individual needs sometimes conflict with team needs.
• The engineering organization may have important goals that compete for staffing with the needs of other organizations.
• Teams within the engineering team may have conflicting goals.

Achieving alignment requires managing both up and down. It takes a blend of skills: articulating a clear purpose, advocating for the team's needs, educating stakeholders on constraints, listening carefully to their perspectives, shaping strategy, and communicating business priorities. It's important to help non-technical executives reason about product development capacity so that they respect the team's priorities and understand the tradeoffs that need to be made.

3. Ensuring fast, reliable execution

Suster describes process as a key part of the job. Process is important, but it is also a means to an end. Processes exist to help the team execute quickly and reliably. Knowing when to add process, when to remove it, and when to leave things alone is a subtly hard part of the job.

4. Advocating for organizational scalability

As VP of Engineering, I'm often the guy in the room who's fighting for the organization's scalability — that is, the ability to maintain the team's performance as its demands increase. That means that I sometimes am the unpopular guy who argues that the benefits of a particular new toolset don't outweigh the operational and training burdens it imposes.

My four obsessions are in order because each one enables the next. A great team will define a better strategy. Clarity on goals focuses the team on problems that matter and away from problems that don't. Great execution puts the organization and the business in a position to scale. And a scalable organization makes it more likely that key employees will remain happy and engaged.

Books shouldn't be predictable. Neither should moviesmovie teams. Or sports teams. When it comes to entertainment, predictability is boring.

Work relationships, though, (hopefully) aren't just forms of entertainment. We should be predictable. When people can anticipate our feedback, they require less guidance. I know that the team can predict my thinking when they start gently mocking my predictability (as my team did when they wrote a chat bot that responded to all questions with the same advice: work in small batches). That's a sign I'm getting a point across clearly.

To that end, here are behaviors that will predictably make me happy. I try to practice these behaviors myself, and I value them not only in people who report to me but also in my peers and bosses.

• Give your best effort. This one is self-explanatory. I don't expect people to work all hours of day and night, but I do expect them to care. If you don't care about your job, you may be in the wrong job. I'm open to talk about why that may be and trying to find a better fit (even at another company).
• Know what's important. The best productivity trick I know has nothing to do with time management or keyboard shortcuts. If you why you're doing what you're doing and why it matters, you can focus on valuable activity and prune out whole classes of problems that you don't need to solve. A great sign is when someone has a simpler, cheaper way to accomplish a goal than I envisioned. A bad sign is when someone can't answer the question, "What are you trying to achieve?"
• Be transparent. The information in our heads is valuable to others. We have an obligation to share it, especially when we have news that might disappoint. I like getting feedback that a plan is unrealistic (especially when it's accompanied by a proposal for a new plan). I hate getting surprised at the last minute by information that was known to the team.
• Put the team first. Succeeding at anything requires a mix of glory and grunge. I like to structure teams so that the grungy tasks are shared. Even the perfect job will have its equivalent of boring bugs, build troubleshooting, and 2 am pages. GameChanger's iOS developers set a great example here. When our testing team was understaffed, developers executed test cases themselves in order to ship faster.
• Don't tolerate the status quo. It's easy for organizations to drink their own Kool-Aid. For an organization to survive and to grow, it must be doing something right. But there are always opportunities to improve, often dramatically. My former colleague Tom Leach obsesses about learning how other companies solve technical and organizational problems. He's great at evangelizing those solutions to his teams.
• Make decisions when you need to. We're going to face hard decisions and ambiguous circumstances. When time allows, I'm happy to talk through those decisions. But there are several instances where someone simply has to make a decision. Making decisions under uncertainty — whether to assume command of a production firefight or to pick one technical design over another — always earns my respect, whether or not the resulting decision ends up being the right one.

These behaviors make me happy. They also tend to make other people happy. Should I succeed in articulating these principles consistency, I expect that future colleagues will easy be able to predict whether "Phil would love that" or "Phil would hate that."

(Credit goes to Kiril Savino for planting this idea in my head when he promoted me into management and for exemplifying it personally.)

Automation severs ends from means. It makes getting what we want easier, but it distances us from the work of knowing.

- Nicholas Carr in The Glass Cage

Nicholas Carr's The Glass Cage is a thoughtful critique of automation. Carr's core argument is that, as we automate our work, we change the nature of the work itself and change ourselves in the process. These changes result in degradation of our skills and even our humanity.

This criticism isn't news to me. There's a convincing argument, recapped by Carr, that the crash of Air France 447 was enabled by autopilot systems — not failure of the systems themselves but, rather, failure of pilots to maintain their skills when autopilot systems made those skills useless most of the time.

The medical field has its own examples of this phenomenon. My dad, a doctor who has practiced for over 50 years, laments that the variety of medical tests available today has allowed doctors to fall out of practice with their physical exam skills. Instead of making quick, intelligent decisions based on examination of physical evidence, doctors add costs and delays by over-relying on batteries of tests. He once discovered a huge, palpable life threatening tumor that escaped the eye of doctors conditioned to ordering tests with minimal justification.

As an engineer, the notion that automation can degrade our abilities is both intuitive and uncomfortable. Two decades ago, as a student in MIT's 6.001, I realized that I did my programming homework faster if I wrote it on paper before attempting to run or test it on a computer. My mind helped me find answers more quickly than the computer did precisely because my brain was forced to work to solve problems on paper.

When I ran GameChanger's engineering team, we had to wrestle with whether some forms of automation were good or bad. And it wasn't obvious. I initially feared that AWS autoscaling would isolate our engineers from understanding our traffic patterns or understanding how our systems were bootstrapped. I believed that autoscaling's false sense of security slowed our reaction to production incidents, at least initially. In time, though, the team simplified how server provisioning and bootstrapping worked. Instead of trying to manage complexity with automation, our team eliminated it or moved it to a pre-launch build step (via Docker). In this simplified world, our automation worked and our availability surged to 99.99% in our peak season.

This experience helped me distill my feelings about automating processes. There's more leverage in simplification than in automation. Automation doesn't eliminate complexity. It hides it, and that's bad. I now advocate for automating that which is simple and simplifying that which is not. I resist automating whatever can't be made simple.

If I asked my colleagues to describe me, I don't think that "optimist" would be among the first terms they'd use. I detest bullshit. I insist on calling out failures and I avoid sugar coating mild achievements as true success. Those who spend a lot of time around me wouldn't describe my disposition as sunny.

Underlying my gruff demeanor, though, is a deep optimism. I see sugar coating as cynical, a tacit admission that true success isn't possible. I see admission and examination of failure as evidence of a highly idealistic stance: learning and improvement are always possible. I love high standards because they represent a belief that high achievement is possible. I can't function without optimism. Whenever I lose my optimism in a particular situation, I disengage very quickly.

My boss and I had a good talk this week. He helped me see that, while my honesty is visible, my optimism is not. It's a good observation for me to ponder.