Tech Leadership Challenges: Communication & AI at Financial Times • Alice Bartlett & Charles Humble

Alice Bartlett, Tech Director for Customer Products at the Financial Times, oversees a group of approximately 70 engineers responsible for ft.com, the mobile apps, and other customer-facing digital products. Her journey at the FT began as a principal engineer before she stepped into the director role, providing her with a unique perspective on technical leadership and organizational structure.

The Evolving Role of a Principal Engineer and Tech Director

The role of a principal engineer at the FT was historically a blend of management and technical strategy, rather than a pure individual contributor (IC) role. This has recently changed with the formal introduction of a dedicated IC track, providing clearer career progression for engineers who do not wish to pursue people management.

As a Tech Director, Bartlett’s responsibilities are multifaceted and center on handling the most complex challenges that arise within her group. She describes her role as dealing with problems that couldn’t be solved by others, which fall into several key areas:

• People and Process: A significant portion of her time is spent coaching her direct reports (principal engineers) on navigating difficult conversations, ensuring HR processes are followed correctly, and sometimes intervening in particularly sensitive situations.
• Long-Term Strategy: She focuses on the two-to-three-year horizon, aligning the technical direction of her group with the broader commercial strategy of the FT. This involves anticipating future business needs, such as creating a single customer view across the FT’s diverse product portfolio, and identifying the technical limitations that need to be addressed now to enable that future.
• Stakeholder Management and Communication: A crucial part of the job is ensuring information flows effectively. This means keeping the CTO informed to avoid surprises, aligning with peer tech directors, and managing stakeholder relationships to shield the engineering teams from organizational turbulence, allowing them to focus on their work.

On Leadership and Giving Feedback

Bartlett emphasizes a leadership style built on curiosity, trust, and clarity. When tackling a difficult problem, her first step is to gather context by listening and asking questions, resisting her natural “bias for action.” She relies heavily on her team of principal engineers to provide briefings and trusts them to escalate issues appropriately.

When it comes to giving difficult feedback, such as addressing underperformance, she advises:

1. Preparation is key: Never “wing” these conversations.
2. Remain curious: The goal isn’t just to state that someone is underperforming, but to understand why. It should be a collaborative discovery process to identify unmet needs or unclear expectations.
3. Be kind, not nice: Being “nice” is avoiding the difficult conversation to spare feelings in the short term. Being “kind” is delivering the necessary feedback, even though it’s uncomfortable, because it’s crucial for the individual’s long-term growth and the health of the team.

“To let someone underperform and not realize it is going to be worse for that person in the long run because they will eventually be moved along.”

Case Study: Refactoring the Content Rendering Pipeline

Bartlett shared an example of a major architectural challenge she led: untangling a “spaghetti-ish” content rendering system. She was chosen for the project not for her deep expertise in that specific domain, but for her communication skills. Her then-boss wanted a leader who could “keep the work in the light” and ensure stakeholders understood the value of a complex technical debt project.

Her approach involved:

• Assembling a motivated team: She brought together engineers who were passionate about solving the problem, including members of the platforms team who would eventually maintain the new system. This preemptively addressed the “not invented here” problem and ensured a smooth handover.
• Proactive communication: The team was encouraged to share their progress widely. This visibility attracted the attention of other teams, like the one managing the CMS, who realized they could leverage the new, unified rendering pipeline to eliminate their own duplicated code. This expanded the project’s impact significantly, improving the accuracy of article previews for the editorial staff.
• Incremental funding: Rather than asking for a multi-year budget, the project was broken down into six-month chunks. This made it easier to secure funding and demonstrate continuous value to the business.

The Impact of AI on Software Development

Bartlett expresses a measured, cautious perspective on the rise of AI in software development. She identifies a key challenge in the transitionary phase:

• The Mentorship Gap: Senior engineers, trained “the old-fashioned way,” can discern good AI-generated code from bad. Junior engineers, however, may lack this critical judgment.
• The Shifting Role of Seniors: The job of a senior engineer could shift from writing code to reviewing massive volumes of AI-generated code, which may not be a desirable evolution of the role.
• Uncertainty about Code Quality: In a future where AI writes and maintains code, the human value of “elegance” or readability might become irrelevant. However, it’s unclear what the long-term consequences for software quality and maintainability will be.

She suggests that a more deliberate application of AI could be beneficial, such as using it to generate code that passes a robust, human-written test suite. This maintains human oversight on the software’s behavior while leveraging AI for implementation, but represents a very different way of working.

• Tags:
• AI
• Communication
• Leadership
• Software Architecture
• Engineering Management
• Technical Debt
• Stakeholder Management
• Financial Times