I've been managing engineers for fifteen years. Microsoft, Adapify (my own startup), Tenable — across companies of every size, in every stage, with every flavor of organizational dysfunction you can imagine.
And for fifteen of those years, I've been managing with... Google Docs.
Not because I love Google Docs. Because nothing better existed.
The Patchwork Problem
Here's what my "management system" looked like at various points in my career:
- 1:1 notes lived in a Google Doc per person. Sometimes a shared doc, sometimes my private doc, sometimes both (and they'd drift out of sync within a week).
- Performance review prep was a frantic two-week scramble through Slack search, Jira history, and my own terrible memory, trying to reconstruct six months of someone's contributions.
- Team health was measured by gut feel. How's the team doing? Well, Sarah seemed frustrated in standup yesterday, and Jake's been quiet lately, and we shipped that big feature on time so... probably fine?
- Career conversations happened when someone threatened to leave, not proactively.
- Action items from 1:1s went into the doc and were never seen again.
At one point I tried Notion. I built an elaborate system with linked databases, rollups, and relations. It took me an entire weekend. It worked beautifully for about three weeks, until the friction of maintaining it meant I stopped updating it, and then it became another graveyard of good intentions.
I tried Lattice, Culture Amp, 15Five. They're fine tools for HR. They're terrible tools for engineering managers. They don't understand that my job isn't just "have 1:1s and write reviews." My job is to ship software through people, and that means tracking technical decisions alongside team health, understanding how sprint velocity connects to morale, knowing that the reason deployment frequency dropped is because we lost our only infrastructure engineer and I need to make a hiring case.
The Breaking Point
The moment I decided to build emkit was embarrassingly specific.
It was review season at Tenable. I was writing performance reviews for eight direct reports. For one of them — let's call her Maria — I knew she'd had an incredible half. She'd led the migration to our new auth system, mentored two juniors, and handled a production incident at 2 AM with zero drama.
But when I sat down to write her review, I couldn't find half of it. The auth migration was spread across four Jira epics. The mentoring wasn't tracked anywhere — I just remembered it happening. The incident? I found the Slack thread, but my notes about how well she'd handled it were in a 1:1 doc from three months ago that I'd stopped updating.
Maria got a good review. But it wasn't as good as it should have been, because I couldn't reconstruct the full picture of her impact. And that's not fair to her.
That's when I realized: the problem isn't that engineering managers are bad at this stuff. It's that we're using tools that were built for something else entirely.
What I Actually Need
I started writing down what I wished I had. Not a feature list — a workflow list:
Before a 1:1: Show me what we talked about last time. What action items are outstanding. How this person has been feeling over the last few weeks (based on what they've actually told me, not a survey). What's coming up in their career plan. Any flags — declining PR activity, upcoming PTO, anniversary date.
During a 1:1: Let me take quick notes that automatically become action items when I write "TODO." Track the mood of the conversation. Link to the specific project or incident we're discussing.
Before a performance review: Give me a timeline of everything this person has done. Pull from the 1:1 notes, from the career ladder criteria, from the goals we set. Show me where they've grown and where they still need to develop. Don't make me reconstruct this from memory.
Day to day: Show me a dashboard. Team mood over time. Sprint velocity. Open action items. Upcoming 1:1s. Who I haven't talked to in a while. Incidents and ADRs from the last month. Not because I want to micromanage — because I want to notice things before they become problems.
When making the case to leadership: Give me data. How has deployment frequency changed since we adopted trunk-based development? What's our mean time to recovery trending? How does team health correlate with delivery speed? I shouldn't need a platform team and a data warehouse to answer these questions for my 8-person team.
Why Not Just Use [X]?
I've gotten this question a lot. "Why not just use Notion with a better template?" "Why not just use Jira dashboards?" "Why not just be more disciplined about your Google Docs?"
The answer is that the problem isn't organization — it's integration. Every tool I've tried does one thing well and ignores the connections between things. But management is all about the connections. The reason you need to know about someone's career goals during a 1:1 is so you can connect the project they're working on to the growth they want. The reason you need to see team health alongside delivery metrics is so you can catch burnout before it tanks your velocity.
emkit isn't a better note-taking app. It's the first tool that treats engineering management as a system — where 1:1s, performance, career growth, team health, delivery metrics, and hiring all connect because that's how the job actually works.
Where We Are Now
emkit is early. We're building the core modules — 1:1 framework, performance reviews, team health dashboard, DORA metrics — and working with a small group of EMs to get the workflows right.
If you've ever sat down to write a performance review and thought "I should have been tracking this all along," or if you've ever looked at your Google Doc full of 1:1 notes and thought "there has to be a better way" — yeah. There is. I'm building it.
Not because the world needs another SaaS tool. Because engineering managers deserve a tool that was actually built for how we work.
If that resonates, sign up for early access. I'd love to hear what your patchwork system looks like — I guarantee it's just as messy as mine was.