Always failing but never a failure
You will always be failing someone. In a management or leadership position, you navigate a complex set of tradeoffs and someone will always be on the down end of those trade offs.
Trying to frustrate the absolute minimum number of people takes a costly communication toll (‘ruinous empathy’) and offers a middle of the road solution that will leave everyone frustrated.
Managing is about managing failure. You can succeed through failure by anticipating failures and planning accordingly. Directly ask people how you can avoid failing or frustrating them - and clearly state if you can or cannot satisfy their concerns.
I often start with something like ‘Hey I know that doing x is important, but I can’t do that right now and also meet y business goal. How can we solve this?”. Sometimes we can’t arrive at a solution but they now know not to depend on me to deliver something I can’t deliver. We talked about it and l don’t lose sleep over it.
The failures that matter are ones where you broke a promise. Success isn’t trying to win every battle but setting expectations early about which battles you expect to win and telling people.
Take all the time you can and always ask for more time
When in a new role, everything feels new. Psychologically, problems that are “new” (to you!) appear to be very urgent and important even if empirically, they are neither.
It is paradoxically hardest to ask for help effectively when you need help the most — largely due to overemphasizing your personal experience instead of what the other person will get out of it. Canned phrases really help dig you out of the hole. A good canned phrase should do 3 things:
- Ask the person what exactly then need by what time
- Project confidence that you have everything under control
- Convey that delaying the project is in THEIR best interest.
For example: Our project is going great, but some new opportunities have come up that I would love to explore while we are focused on this issue - can me/my team have until [exact date] exploring this or do you absolutely need [clear statement of scope] by [date originally promised]?
Critically, you should also be very clear when you do not know. For example: I don’t know when this project will complete / have an answer for that question. When do you need to know that? [ok thanks] I will follow up via an email. By [time agreed upon].
97% of the time, premature process is the root of all evil
At Cityblock, we love to say ‘it is a marathon not a sprint’. Despite that, we have a lot of process for such a young company.
A processes should 'run the the marathon alongside you'. A burdensome process forces you to stop running, go half a mile in some other direction to fill out a bunch of forms and then be told you filled out the wrong forms…and so on.
A great process should help people on the team consistently get where they were going.
When is a process is ‘too early’?
First, try to measure the ROI of the process. An good ‘return’ for a process would be an increase average quality by reducing the frequency of poor outcomes. However, the process may appear unnecessary if those poor outcomes have never happened or the cost of those poor outcomes is lower than the cost of mitigating them.
Measure twice cut once
Measurement around process is critical to instrument BEFORE instrumenting the process. Every process should justify its existence - positive ROI. If there is some consistent pattern you can measure, add process to improve outcomes.
Good examples of process measurements are the time it takes to onboard, go from final interview to offer, or off board.
Uncertainty is the life blood of a company. Managers need to quickly reorient their team in a new direction as priorities shift. Arduous process for things like manager handoffs or hiring approvals or departure processes hugely slow a manager’s ability to adapt the team to a changing environment. However, an efficient onboarding process or manager handoff process can really set team members up to adapt quickly.
Another principal of good process is the ability to bend and flex like a yoga class. For example, manager handoff process can be dialed up if you are dealing with a junior member of the team, but dialed down for more senior members of the team working with their 5th manager.
As a leader, you need to know how flexible process is and what is critical vs nice to have? (the answers may surprise you!)
In an ideal world, each process would be deployed at the perfect time for the company stage, complete with measurement and clear points of flexibility. However, that may not be possible. In general, at least shoot for launching the processes that you need today - not the ones you think you will need tomorrow.
Live and breathe YAGNI for your organization
As an engineer, you probably live YAGNI (‘you ain’t gunna need it’) in some way for your engineering team, but as a leader, you need to do that for the organization. While Martin Folwer applies this to software, hits at every aspect of building a company.
YAGNI is the idea that you should not introduce extra complexity now unless you will take advantage of it today. However, if you do something for a future need that doesn't actually add complexity, then there's no reason to invoke YAGNI.
For example, you may anticipate adding more people to the company and want a larger office. The same office but larger office won’t meaningfully add complexity to your company so no need to invoke YAGNI.
When adding new complexity, there are a variety of costs associated. They can generally be broken down into 4 categories:
- Cost of ‘build’. Setting up some new process takes time. How much time?
- Cost of ‘carry’. Having the process costs something by taking up space.
- Cost of ‘adjustment’. Since the process is not being used TODAY, when it is used for its intended purpose, we may find out it is wrong. We always pay this 'adjustment' cost but adjusting bigger and older things is more time consuming than adjusting smaller and newer things. Newer things often have the original team in tact adding to efficiency.
- Cost of ‘delay’ (opportunity cost). There are many near term investments we can make and building for a future need has to be more important than those near term investments.
In general, small projects can be one way to minimize the cost of carry, cost of adjustment and cost of delay -- allowing the team to be fast and lean. However, sometimes other methods achieve those overall goals and it is important to be open to larger projects.
The goal is not to launch a large number of small projects but to minimize the cost of carry, cost of adjustment and opportunity cost — may they be products or processes.
Deeply Collaborate with people/HR team members
Modern HR is…very different from 5-10 years ago in tech. It is reasonable to assume that letting someone go for performance reasons will take over 40 hours of a manager's after a decision to let them go has been reached with the HR partner. Changing someone’s manager will take 3-5 person days to complete (across you, the new manager and the direct report) and require many (~3+) pages of documentation to be written.
Though those hard conversations or changes are often the right thing to do for both you and the individual - they are costly and you should anticipate the cost. These are very large time costs that are not clearly stated at the outset - there is no ‘expect completing this form to take x hours’ at the top of the doc. Mis-estimating a task by 5 hours can really mess up your plans for the week!
If you are struggling in this environment for these or other reasons, bring in the people team — don’t push them away. Ie: “I need to do x, y and z for the business, and you are asking me to fill out 3 pages of documentation for each of 8 direct reports before we kickoff a new project? How can we work together to find a lightweight way of accomplishing the goal here.” The answers are often surprising! And in my experience, much better when you bring them in than when you keep them away.
[wip] Slow is smooth; smooth is fast…in the military
Probably the central struggle for me when managing up is a disagreement about how to handle forward planning. Specifically, given the option, should we improve the speed at which we can adapt to change or plan the next year based on what we know today. My experience has been that I do not know very much about what will be true a year from now, and that planning that far in advance, with maybe a year or two of prior data to work from, is a fools errand. So, I tend to focus on reducing the friction to change both organizationally and within my team. However, those efforts get a fair amount of pushback.
The tension between moving quickly and planning
Ground conversations in the company values ESPECIALLY with vendors and partners