RJ Lindelof
The Leadership Philosophy of RJ Lindelof
7 min read
RJ Lindelof's Leadership Philosophy in One Paragraph
True leadership isn't about being in charge. It's about taking care of those in your charge. My goal has always been to create environments where people can do the best work of their careers while building something extraordinary together.
That is servant leadership, and it is not soft leadership. I am direct, plain-spoken, and willing to make the unpopular technical call. When the data says one thing and the loudest voice in the room says another, the data wins. I am a builder of high-velocity teams, not a manager of large ones.
Principles
Five Leadership Principles, and What They Look Like on a Tuesday
Vision with execution
A vision nobody can ship is a poster. My first 90 days in any organization follow the same pattern: cut the meetings, simplify the roadmap, get one real thing shipped, build trust, repeat. Every objective gets a metric, and every metric gets an owner.
What I do not do: run an organization on the appearance of work. I have a low tolerance for theater.
People first
People build platforms, not the other way around. I lead with autonomy and accountability: define clear objectives and metrics, then get out of the way. Autonomy alone is abandonment. Accountability alone is surveillance. You need both, on the same day.
What I do not do: micromanage people I hired for their judgment.
Continuous innovation
Improvement is a habit, not a quarterly initiative. At Follett I founded an internal R&D group on a fail-fast model. At GlobalMed it was Tuesday Technical Talks. At hc1 it was the company's first AI Hackathon. I practice Agile with a lowercase "a": whatever mix of Scrum, Kanban, and Lean gets working software to customers sooner.
What I do not do: adopt a tool because a vendor deck said so. The question is always the same: what problem are we solving, for whom, and why now?
Ethical leadership
Lead with integrity, and build things that leave customers better off. In regulated industries that is not abstract. It means a responsible-AI policy before the tools are turned on, audit trails that exist before the auditor asks, and post-mortems that are a leadership artifact, not a blame artifact.
What I do not do: ask who caused the outage before asking what the system allowed.
Adaptive strategy
Hold the long-term direction steady and stay flexible on the route. Metrics tell me where to look. Judgment tells me what to do. When the facts change, the plan changes, and I say so out loud instead of pretending it was the plan all along.
What I do not do: defend a roadmap because my name is on it.
Player-coach
Player-Coach: Staying Close to the Code
I spent thirteen years as an individual contributor before I led anyone, and I have stayed close to the code since. That is what lets me push senior engineers and architects on where a technology helps and where it quietly introduces risk.
Player-coach, for me, means pull-request review, architectural review, platform modernization plans, process design, hands-on prototype work for high-stakes decisions, and the occasional production triage. I will code up to 30% of the time when the work calls for it. It does not mean 50% feature delivery. A leader who is the critical path on a sprint is not coaching anyone.
The line between coaching and meddling is ownership. I will review your design and argue with it. I will not quietly rewrite it.
Remote engineering team leadership
One Organization, Many Regions
Remote was never the variable. Clarity was. Distance does not kill teams. Ambiguity does.
I have led hybrid teams since 2006 and fully distributed, global teams since 2012. Global teams are unified, not tiered. There are no second-class engineers. Onshore, nearshore, and offshore engineers work to the same standards, sit in the same reviews, and own the same outcomes: one engineering organization, not a vendor at the far end of a ticket queue.
The mechanics are unglamorous. Every decision has one name on it. Async is the default, which means decisions have to survive being read by someone who was asleep when they were made. And we stop confusing "needs to know" with "needs to sit in a meeting."
Decisions
How Decisions Get Made
With data first and one accountable name. Engineering is not an order-taker, so a request from product gets the same three questions as any other: what problem, for whom, why now.
Disagreement is expected. Psychological safety is not a soft skill. It is what makes teams call out the questions that prevent the next outage. The teams I have built will challenge me, and I will lose those arguments openly when they are right.
And when the risk is small, we move. An engineering manager who reported to me quoted my question back in a LinkedIn recommendation, from a moment when he was being a bit too cautious: "If there's so little risk, why wait?"
People
Hiring, Developing, and Retaining Engineers
I hire for curiosity and aptitude, not credentials. Technical skills can be taught; growth mindset and team-first attitude cannot. I look for drivers over do-ers: people who force a decision instead of waiting for one.
Development happens in the work. At hc1, Product was cross-trained on Playwright and code coverage went from under 10% to 40% without a dedicated QA team. At GlobalMed, time-to-productive for new developers dropped 35%.
Retention follows from the rest. People stay where they are trusted, where the roadmap makes sense, and where the meetings are short.
AI and leadership
AI Changes the Job, Not the Principles
AI did not shrink the need for senior engineering judgment. It made judgment the whole job. Code got cheap. Review, boundaries, and the ability to say no did not.
So the coaching changes. Leaders now have to teach verification, not typing speed, and treat skepticism on the team as a feature. AI adoption is a behavior and trust problem, not a license rollout. The technical side of that is on the AI-native SDLC expertise page.
User manual
Working with RJ: A Short User Manual
- Fastest way to a yes: bring the data and a recommendation. One name on the decision, preferably yours.
- Fastest way to a no: a Jira ticket wearing a fake mustache, presented as strategy.
- Meetings: I know RACI. I have also sat through RANCI, where the N stands for "Nobody knows why they're here." Do not invite me to those.
- Disagreeing with me: encouraged, in the open, with evidence. When you are right, I will lose the argument openly.
- Known flaw: low tolerance for theater. If the status report is prettier than the product, we are going to talk about the product.
- Known habit: if you tell me the risk is small, I will ask why we are waiting.
- Bad news: early and plain. A post-mortem is for learning, not for finding someone to blame.
For a longer list of things I learned the slow way, read the outtakes. For where these principles were tested, see the career timeline.
Need a leader who runs teams this way?
Tell me about the team, the product, and what is in the way.