People all the way down

Problems may be cultural or systemic, but change happens one person at a time. When proposing a change, stop to ask yourself what, specifically, someone should stop doing - or what specific thing you want produced that doesn’t exist today. Being specific matters: are you looking for a change in priority, a different SLA, a completely different workflow? Who is empowered and capable of making that change? Starting with that question forces you to take ownership of the analysis and move from vague complaints to actionable recommendations.

Feedback takes work to prepare & deliver. If you want feedback - and you should - create a culture that supports it. Pro-feedback cultures have high safety, low effort and clear benefit: (a) High Safety - people must believe that they won’t be yelled at, dismissed or worked around because they spoke up; (b) Low Effort - feedback should be solicited and shouldn't require perfect tone, phrasing or process. (c) Clear Benefit - feedback must result in change; asking for feedback without taking action will stop your peers from taking the time.

Most work is complex enough that it’s hard to judge quality from a quick glance. For bigger projects, build trust through time: consistently say what you’re going to do - then do it. Call your shot: using “why, what and how” language, describe the project you’re about to undertake and why it solves a problem. Take your shot: do what you said, adjusting scope and process as needed. Then celebrate your shot: show off your work, and how it solves the problem. This last part is important - no one will pay as much attention to your work as you, but everyone loves to celebrate when something goes well.

Bureaucracies create disempowered people, who have a narrow view of the world and little interest in the bigger problems their role fits into. Maybe it’s an overly risk-averse HR rep, a procurement associate or vendor security analyst: these processes need to exist in large companies, but the individuals implementing them aren’t often able to make their own tradeoffs. If you get an unfavorable decision from a disempowered partner, you can either try helping empower them - or accept that you should’ve found someone else in the hierarchy to partner with instead.

Literally “turning the roots” (preparing the roots of a bonsai tree for transplantation); in an organizational context it’s a perfect shorthand for shepherding complex decisions. Decisions often require complex tradeoffs and insight from different parts of the organization, so getting agreement goes best when you’ve done the prep work - going to each stakeholder in turn to get their feedback and input on a design or concept. By the time the proposal comes to a formal decision at an architecture board, budget committee or staff review, you’ve incorporated everyone else’s context and come closest to the best possible outcome.

“We should” - “I don’t understand why we don’t” - “It would be great if...” these are common things to hear, but they rarely lead to action. That’s because there’s no “secret we” - everyone already has their own projects. When proposing a project, who do you think should do it? What skills and personas are needed to get the job done? What would it take to get them interested and committed to the idea? There is no cavalry coming: how are you going to rally the troops yourself?

Trying is learning. Especially if you’re a novice, working with more experienced colleagues. If you’re stuck on finding a bug, figuring out a phrase, generating an insight, getting a tool to work - push yourself just past the point of being stuck. Take another 15 minutes to brainstorm ideas, develop tests, look for docs, and give it another shot. After that, write down what you tried and go ask for help. This has three great outcomes: First, you’ll learn new techniques. Second, you'll blaze a path for someone stuck on a similar problem. And third, the expert can now help better: knowing what you tried leads to more targeted advice. Don’t stay stuck forever; people love to help. But try, and then ask.

Proposals are easier to understand in context. If your recommendation is to “do something” and the primary alternative presented is “don’t do that thing,” inertia can win out; you're asking your reader to understand the consequences of the alternatives. But too much choice and context leads to bikeshedding and conversations that drag without a decision. Boil complex decisions down to three options: maybe from most to least expensive; or highest to lowest risk; define an Option A, B and C, with real tradeoffs - and make a recommendation. The feedback you get will help you understand business context and keep everyone aligned as you build.

Originating in a structured practice of connecting to customer needs in enterprise sales, “P2V2C” helps triage any stakeholder’s needs, including within organizations. Try to understand these five things: (a) Pain: what is your counterpart experiencing today that must get fixed? Without immediate pain, your needs won't make their priority list. (b) Power: who has authority to make the decision? Are you talking directly to a decisionmaker? (c) Vision: are you both moving in the same direction? (d) Value: How do they define success, or (to be crass), how will this show up in their performance review? (e) Control: How will you work together? Implementation is easier if you share tools, cultures or practices. With limited time for discovery with a partner, prioritize understanding these topics and tailor your approach to address them.

Do you need help or want help? Management involves a lot of problem triage, and it can be difficult to distinguish between an advisory conversation - “I have this under control and I don’t need action today, but in case you have good advice for me...” - and an escalation - “I don’t think we’re going to make this timeline / budget / deliverable work without help.” So be explicit: flag upfront whether this is a yellow (advisory) conversation, then explain what you’re trying and how you’ll know if it worked; or state directly that it’s a red (escalation) conversation, talking through what you’ve tried, what you’re asking for, and what happens if help doesn't arrive. Colleagues want to help - but you have to make clear that you’re asking.

No job is perfect. When helping a friend or teammate with professional development, or considering options for your own next role, start with three separate questions: (a) What are you good at? Managers will expect you to have some of the relevant skills already - so be honest with yourself about your unique strengths and how you’ll show them off. (b) What do you want? Frame it in terms of outcomes or rewards - learning, growth, impact, compensation - than artifacts of status like level or title. (c) What does the world need? A job has to provide value, or it’s just a hobby. Any role will be a balance of these: not perfectly suited to your strengths, or everything you want for yourself, and plentiful in the market, but neither should you compromise entirely on one area, either.

Ideas always seem clear in your head, but the process of distilling them - laying down an argument or plan - forces you to fill in the details and separate out the important from unimportant. Processes that feel like empty paperwork - design reviews, job requisition forms - were often initially designed to encourage completeness of thinking, ensuring that you considered the most critical considerations in your proposal. Even if there’s no process forcing you to write, it’s still an important exercise: can you make your idea precise, clear, relevant to multiple audiences; and fit all the parts into a coherent whole and compelling flow?

Knowledge work is a lot of convincing others to do things, and getting frustrated when they don’t happen the way you’d hoped. Before getting too upset, try to figure out where you’re misaligned. Work with your counterpart through five steps: (1) Do they agree there’s a problem (and on the problem definition)? (2) Do they agree it’s their problem to solve (or do they believe it’s someone else’s)? (3) Do they want to solve the problem now (or do they think something else is a higher priority)? (4) Can they develop a plan to solve the problem? (5) Can they follow through in executing the plan? These steps must go in order: providing a plan and micromanaging followups is bound to fail if steps 1-3 aren’t completed; but knowing where the problem is helps you fix it together.

The “build” part of a project, when the code is being written or the building constructed, is the most visible. But below that visible success is a great deal of hidden work. Before build starts, there is creating clarity on what to build, iterating on designs or proofs-of-concept, and marshalling resources. After build completes there is validation, delivery, client follow-through, and ongoing maintenance. Teams that don’t plan for the hidden work will struggle: they will feel behind, miss deadlines, and compromise on quality. Each project’s needs for prep and follow-through will be different, so make sure they are accounted for in your team’s planning and delivery processes.

We all hope for major-league glory and the rewards that come with it. But few of us go straight from the draft to the all-star game. Most careers grow bit-by-bit and choice-by-choice: work for an established player but a narrower role - or take a gamble on a smaller company with more autonomy but more risk of failure. There’s no perfect answer; at some points in your career it’s helpful to learn from an organization and colleagues who’ve already won a ring (or built a successful business); in others, it’s better just to get more at-bats (and learn more of the business) while relying on your own skills to grow. Either way, be clear on the decision you’re making - and never compromise on quality teammates for the sake of a bullet on a resume.

One of the first things you learn in flight training is positive control. Only one person can fly the airplane at a time; if the student and instructor are fighting each other, bad things happen. So you practice a three-way handoff: “I’m giving you the flight controls.” “I have the flight controls.” “You have the flight controls.” That way it’s never in doubt who is making the decisions and who is on the yoke. The same level of explicit handoffs can be helpful in project management and delegation - if it’s unclear, ask: who has the flight controls? I’ve completed a part of the project, are you good to take it from here?

If you’re trying to argue for a specific outcome and you find the conversation going in circles, step back: what kind of decision are we making - design, budget, priority? - and what general framework is best - cost, risk, short-term and long-term value - for evaluating options? Or, if you find yourself stuck on a general-purpose framework, stress-test with real examples and edge cases: would this project fall above your cutline? We may have clear policies and timelines for promotions - but do they work when someone is exceptional and at-risk? A focus only on single decisions or frameworks alone will be inadequate, with an untested framework muddling decisions; or each individual case devolving into independent, from-first-principles debates.

In 1956, George Miller published research showing the number of objects an average human can hold in working memory is “7, plus or minus 2.” Even seven may be too high: we chunk phone numbers into groups of 4 and 3 to make them more memorable. When putting together an argument, proposal, or any structured process, constrain your outline to “five bullets of five bullets” - three to five top-line focus areas that best break down your project, each illustrated by three to five supporting components. If you find yourself with 20 interlocking arguments or an architecture with a dozen boxes, you may be adequately representing the complexity of a real-world problem -- but you should still simplify for the benefit of your audience.

“We’ll have a development team and an ops team,” engineering used to say, before Flickr taught us about DevOps. Infrastructure and product engineering are still separate disciplines, but the core insight remains true. If your org design has one team that gets to do the exciting work with shiny toys and greenfield exploration, while another team does maintenance and support, burdened by legacy baggage handed to them by the innovators, you serve neither team well. Not the janitors - who burn out and miss opportunities to grow, without feeling ownership of what they build; but also not the ivory tower team - who, by being disconnected from the real-world consequences of what they build, are liable to miss important details.

Teams that ship software are built on top of four core knowledge areas: (1) what the technology is capable of and translating ideas into product; (2) what users will adopt; (3) how to get things done and stay on schedule; (4) what the people on the team need, and how to support them. These four areas may have natural titles - senior engineer (or tech lead), product manager, technical program manager and engineering manager - Rands introduced the framing of “bits, features, and truth” to highlight that it’s not titles that matter - it’s the skills themselves. When constructing a team, you want to know who has accountability for each area. But when thinking of your own career, aim for baseline ability in all four. Great engineers who also advocate for users and get things done? Product managers who own execution? These are massively valuable and minimize communication friction.

Show off your work! Regularly demoing what you’ve built for others encourages you to keep the user’s concerns first and foremost, and helps avoid rabbit holes that are technically interesting but ultimately irrelevant. But don’t make people sit through a demo where you show off every feature and detail - if you find yourself saying “and then you can just…”, stop: focus your talk track for a demo on motivation and impact instead of features and clicks. Even better: put your user on a Hero’s Journey, the classic story template from mythology (and blockbuster films): our hero’s normal life has a problem, a sense of unease; sets off into new territory; learns from friends along the way; overcomes challenges; has a great success and returns home changed by the experience. A demo with a story that follows these beats will be more engaging and memorable than a simple walkthrough.

If something isn’t getting done in the way you expect, before blaming laziness or stupidity, it’s best to assume there’s a reasonable, and fixable, explanation. When thinking through the blockers, it can be helpful to break down the reasons into “skill” or “will” (even though it’s often a combination of both): “Will” - the person doesn’t want to do the work - can be addressed by changing prioritization, giving better motivation or context. “Skill” - the person wants to do the work, but is missing some core ability - can be addressed through pairing, formal learning and development, breaking down the task into smaller units or changing the structure of the work entirely. Either way, picturing in your head an x/y graph - skill vs. will - and plotting a path from where your partner is to where they need to be will help you get them there.

Tribal Leadership describes five “stages” that people - and by extension the “tribes” they sort themselves into - go through: (1) life is unfair, might as well get mine; (2) my life sucks, I should just keep my head down and try not to be bothered, (3) I’m awesome but everyone around me is an idiot, (4) We’re amazing but that other team is awful - let’s beat them; and (5) We’re amazing and can change the world. Leaders who spot and use these patterns effectively create better, more motivated teams: for example, give small stage 2 clusters a win and watch them grow by having ownership. Show stage 3-dominant individuals, in small groups, that they need to lean on each other to succeed. People evolve slowly from one stage to the next, so using later-stage techniques to motivate earlier-stage colleagues will land poorly.

When should you use a “mission-aligned” design, with independent organizations with their own P&L and distinct business problems vs. a “function-aligned” design, built around depth in a skill area - data science, engineering, sales? Mission-aligned teams move faster, thanks to independence; but won't have a critical mass of functional expertise and duplicate work within a company. Function-aligned teams go deeper and are more efficient in their areas of support, but create bottlenecks that require complex coordination. Balance requires explicitly designing the interfaces between teams. Team Topologies provides a framework: some hard boundaries that look like X-as-a-service interfaces; some teams facilitating others’ work with a drop-in, consulting model; and sometimes combining disparate teams for a defined period of time to build something requiring deep collaboration.

“The people I love the best / jump into work head first / without dallying in the shallows / and swim off with sure strokes almost out of sight...” So begins Marge Piercy’s poem, reminding us not to align ourselves with “parlor generals and field deserters, but move in a common rhythm when the food must go in or the fire be put out.” Strategy and teaching are important, but be skeptical of strategists and thought leaders, or “a strategy” as a consulting deliverable: if we are here to solve real problems, and help real people, we can’t disconnect ourselves from the hands-on work, whatever it is. Build something real: if you find yourself devoting quarters to a study, a platform development effort, or a rebuild, strongly consider whether you can find a “thin vertical slice” that delivers value - and gets you feedback - faster.