Skip to content
 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

22 Commits
 
 

Repository files navigation

Leadership README - How I work

This is intended to be an early shortcut for working together. It should give you a useful head start on how I think, what I value, how I communicate, and where I am likely to be helpful or annoying.

Please treat it as a conversation starter, not sacred text. If something here does not match your experience of working with me, I would rather hear that than preserve the illusion that I have myself perfectly figured out (and then I can update this file again).

The short version

I believe capable people do their best work when they have context, trust, clear ownership, and enough room to solve problems without being over-managed.

My default is to push authority as close to the work as possible. I do not believe management exists to supervise every decision. I believe it exists to create clarity, remove friction, protect focus, raise standards, and help people grow into more scope than they had before.

Some of the best improvements start with a sentence like: “I know we have always done it this way, but...”

What I value, and what I ask in return

Trust

Trust is the foundation for everything else. If we cannot trust each other, we have nothing.

I do not need every conversation to be polished, and I do not need every message to be perfectly phrased. I do need to know what is true.

Tell me when something is blocked. Tell me when you disagree. Tell me when I am missing context. Tell me when I am the problem. I will respect that far more than silence, avoidance, or surprise.

Say “I do not know” when you do not know. That is not weakness; it is how we keep bad assumptions from turning into bad decisions.

Ownership

I assume competence by default. I do not want to hover over your work, and I do not want you to feel like you need permission for every reasonable decision.

I take a hands-off approach because I trust competent people to do good work without being babysat. I will give you room to operate, and I expect you to keep me informed, ask for help when needed, and own the result.

With autonomy comes responsibility. Own the work, own the communication around the work, and own the consequences when something does not go as expected.

When things go right, I will make sure the credit stays as close to the work as the responsibility does.

Do not wait until a problem is fully formed before raising it. I would rather know early, while we still have options.

Improvement

I have a low tolerance for broken systems that everyone has quietly agreed to work around.

I am not allergic to process. Good process prevents known failure modes. Bad process often survives long after the original reason for it disappeared.

If you see a better way, I want to hear it. If you see something I missed, I want to hear that too. Good ideas should be tested, not protected by title, tenure, or who said them first.

Teamwork

Support your teammates. Offer help, raise concerns when you see something worth discussing, and share your hard-earned wisdom.

The best teams I have worked with were not made up of people quietly staying in their lanes. They were made up of people who cared enough to notice when someone else needed context, backup, challenge, or a second set of eyes.

How I operate

I like decisions to be made at the lowest responsible level by the people closest to the work.

When a decision is reversible, I prefer momentum over prolonged debate. Make the call, learn from it, and adjust. Think agile code development, applied to business decisions.

When a decision is hard to reverse, has a large blast radius, or creates long-term obligations, I want more rigor: clearer options, explicit tradeoffs, and enough disagreement in the room to know we are not sleepwalking into a bad choice.

I am comfortable with disagreement. When I present an idea to you or the team, the first thing I will usually ask is for you to poke holes in it. What am I missing? Where did I go off course? What breaks if we do this?

I expect that same standard to run both ways. Good ideas should be tested, not protected by title, tenure, or who said them first. I am much less comfortable with vague consensus where nobody says what they actually think.

What you can expect from me

I will give you context, not just assignments.

I will try to be clear about what matters, what constraints are real, and where you have room to make the call.

I will not intentionally leave you guessing about where you stand. If something is off track, I will tell you early enough that we can do something useful about it.

I will protect your focus when I can. I will remove obstacles when I can. I will escalate when escalation is useful. I will also tell you when something is simply hard, messy, or constrained by reality.

When you are doing good work, I will not insert myself just to look involved. I would rather cheer from the sidelines than create process theater.

Feedback

Never hesitate to tell me how I can do better.

I prefer feedback close to the event. The longer we wait, the more the context decays and the easier it becomes to turn a specific issue into a vague pattern.

For sensitive or corrective feedback, I prefer a real conversation: in person, video, or phone. Written feedback is fine for simple things, but tone and nuance matter when the subject is difficult.

You do not need to package feedback perfectly for me. Clear is better than polished.

I will ask you early on how you prefer to receive feedback, and I will do my best to meet you there. If I am missing the mark, please tell me. I would rather adjust with better context.

Watchouts

(These are my rough edges: the places where my instincts are well-intentioned, but can still get in the way if I am not paying attention.)

I can get impatient with problems that seem obvious but remain unfixed. That impatience is pointed at the system, not the people inside it, but I know it can still leak into my tone if I am not careful.

I sometimes move quickly from problem identification to solution mode. That can be useful, but people and teams sometimes need more time, context, and/or trust before a solution is ready to take shape. If you need me to slow down, ask more questions, or just listen before trying to fix the thing, say so.

I value directness, but I know not everyone processes disagreement, pressure, or change the same way. I will try to meet you where you are. I will also ask you to meet me partway by helping me understand what you really think (i.e. don't make me guess, I'll probably get it wrong anyway).

What I am working on

I am working on being as deliberate on the interpersonal side of leadership as I try to be in my technical work.

My instinct is to understand the problem, identify the constraint, and start addressing it. That instinct is useful, but good leadership is not just about seeing the path. It is also about understanding the people, history, risk, trust, and context around the work.

I am trying to get better at knowing when to move vs when to listen longer, and when the right next step is not a decision, but better shared understanding.

I am also trying to stay close enough to the technical details that I can make good decisions, while giving the people closest to the work enough room to own the solution.

Human stuff

I like direct people, practical problem-solving, useful sarcasm, and teams that can take the work seriously without taking themselves too seriously.

I’m a lifelong video gamer. If you’re looking for something to connect on, this is an easy in with me. Chrono Trigger is the greatest ever made.

About

My leadership readme/operating manual

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors