When "Good Enough" Becomes "Never Enough" Back in college, I took an FPGA Design course that assigned brutal weekly homework. Pages of digital logic problems, code to write, waveforms to document, test cases to verify. I was terrible at time management and procrastinated constantly. One week, desperate and out of time, I asked my professor a simple question: "What do you actually need to see to know I understand this material?" His answer surprised me. Usually, he just wanted to see a waveform showing the input and output with a brief explanation of why it was correct. Not the full problem set. Not all the documentation. Just proof I understood the concept. I started doing half the assigned work and getting the same grades as students who completed everything. They were furious with me. But here's what stuck with me: the written assignment and the actual requirement were two completely different things. Most students assumed they needed to do...

At standup, the team made a call. The feature they needed wouldn't be ready in time, but they found an undocumented API that could work. Problem solved. Deadline safe. Two months later, they went through the full release process again. And external testing. And additional regulatory costs. The workaround didn't work across all jurisdictions. The customer complained. Engineers are highly trained problem solvers. You're amazing at finding problems to solve and finding solutions to them. That's what makes you valuable. It's also what gets you in trouble. The problem with being good at problems When you see a problem, you solve it. That's the job, right? Not always. The team saw a clear problem: the platform feature wouldn't be ready before the deadline. They identified a solution using an undocumented API. They executed and hit the date. But they never asked if the date mattered. Product management was never consulted about waiting one month. No one asked ...

I thought I was being clear. We needed our QA team to shift their approach. Stop waiting until features were complete to start testing. Get involved earlier. Test continuously throughout development, not just at the end. I explained it in a team meeting. I sent follow-up emails. I talked about it in one-on-ones. Everyone nodded. Everyone said they understood. Three months later, they were still testing the same way they always had. The problem wasn't that they didn't want to change. The problem wasn't that I hadn't communicated the change. The problem was that I had shared information without ensuring they actually heard it. There's a massive difference between those two things. What Your Team Actually Hears Here's what I learned from that QA situation: your team isn't hearing your current message. They're hearing your current message filtered through every past experience they've had with leadership. The QA team had spent years being told th...

  (And Why It’s Killing Your Influence) You became chair because you’re brilliant at your discipline. You’ve published, mentored, and earned respect. Then, overnight, the job changed from doing great work to leading people, many of them, your peers. And now? You’re isolated. You’re buried in admin work no one trained you for. You hesitate to ask for help because you don’t want to look lost. You avoid cross-campus connections because it feels political, and you didn’t sign up for politics. Meanwhile, your department stalls. Your initiatives die in committee. You’re working 60 hours a week and wondering what you’re doing wrong. Here’s the truth no one told you: Your success as chair has less to do with your scholarship and everything to do with your relationships. Here’s the playbook: understand the isolation trap, redefine your team, build cross-campus relationships, make them reciprocal, and start small—but start now. The Isolation Problem Universities know this...

Universities now operate like corporations. Budgets, enrollment, and metrics dominate conversations that used to be about scholarship and teaching. And yet, while chairs are expected to run their departments like business units, most get no leadership training at all. You’re managing budgets, people, and strategy. But nobody ever taught you how. So let’s borrow something that works from the corporate world: Stop managing your dean. Start showing your work. The Problem with “Managing Up” If “managing up” makes you cringe, you’re not alone. It sounds political. Manipulative. Everything you went into academia to avoid. You’re right to resist that language. You don’t manage your dean. Your job is to lead your department well and make sure the right people know what’s happening. Why Deans Feel Distant Your dean isn’t ignoring you; they’re overwhelmed. Ten departments. Ten priorities. Ten contexts. That’s maybe two hours a week to focus on yours. They’re juggling...