Every time you wake up in the middle of the night in the dark forest and leave your tent, you feel slight discomfort, no matter how experienced a camper you are. But it’s not the dark forest that causes it. It’s the unknown that triggers the sympathetic response. You simply don’t know if some threat is lurking in that darkness.
In professional life, that means living in a constant state of stress and anxiety, with impaired working memory. Not exactly a recipe for success, is it?
In change management, specifically, the root cause is the T-Shape Dissonance.
T-Shape Dissonance in Change Management
Anette Jacobs, one of the recent guests in CTO Academy’s Expert Q&A sessions, published an insightful post on LinkedIn on this subject. In her own words, it is „a reflection on how lack of clarity and unspoken shifts in decisions can create a hidden emotional and cognitive load in relationships and workplaces, and how attempts to restore understanding can sometimes deepen disconnection instead of easing it.“
Whenever we talk about change management, this exact problem surfaces.
The reason it causes friction in organizations is that leaders, used to sudden pivots, automatically assume that the same applies to their direct reports. However, such a mindset isn’t universal. For many, a sudden change without a clear context triggers a sympathetic response.
The solution seems simple enough: Remove the “unknown” (dissonance) from the equation, and you restore the resonance. While that is undoubtedly the fact, the more immediate question is not the What or How, but When.
You see, the problem is that, by the time you start explaining the Why, the shift is already underway. In other words, you’ve been reactive instead of proactive.
To make things more difficult, in some instances, people who absorb ambiguity and, therefore, pivot with ease often struggle to convey the Why in an understandable manner, which just adds to the problem instead of solving it.
At the core of this problem are different perspectives and expectations. You can observe it as a T-Shape Dissonance. Top-level executives, standing at the top of the vertical, look left and right while setting the stage for the change. They expect people to simply follow their lead. However, employees experience that same change from the bottom of the vertical, with left and right views often blocked or, at the very least, seriously limited.
The Solution is Timing
You’ll often hear people mention the military way of leadership as the most effective. It’s quick, simple, and straightforward, with no need for additional explanation. A unit can move left, right, front, and back in an instant, no questions asked. That’s the definition of agility, something we all strive for.
The reason for that lies in basic training, when soldiers prepare for different scenarios. So before they hit the battlefield, their brains are programmed to expect sudden pivots. At the same time, they know Why they need to execute a certain maneuver or tactic.
Recall any of your personal onboarding processes and early stages of your career. Have you ever even heard about change management at that career stage? Did anyone organize thematic workshops? Did anyone train you for different scenarios or specific courses of action, in case of sudden pivots or a fundamental change in a strategy?
As a leader, you must never forget your roots; the place from which you emerged to the leadership role. It is that exact bottom of the vertical with left and right views blocked or limited.
Good leaders remember that feeling. Bad leaders choose to ignore it.
Technology leaders spend a lot of time thinking about systems: how they scale, how they fail, and how they perform under pressure. But one of the most important systems you design is the environment in which your team works.
That matters because neurodiversity is not an edge case. It is part of the normal variation in how people think, process information, communicate, focus, and respond to stress. Organizations such as Acas and the CIPD have both highlighted the same underlying issue: many workplaces are still designed around a narrow idea of how people “should” work, which creates avoidable friction, stress, and underperformance.
For senior technology leaders, this is not simply an inclusion topic. It is a leadership, culture, and operating model topic. The way you run meetings, structure communication, set priorities, manage energy, and design team rituals directly affects how well people can contribute.
This article draws on insights from a CTO Academy Expert Q&A with Anette Jacobs, turning them into a practical leadership guide for CTOs, VPs of Engineering, Heads of Product, and senior managers building high-performing teams where different minds can thrive.
TL;DR
Neuroinclusive leadership is not a niche people issue. It is a leadership and operating model issue.
The way you run meetings, set expectations, structure communication, and manage pressure has a direct impact on whether different minds can do their best work.
For senior technology leaders, managing neurodiverse teams well means removing unnecessary friction: reducing ambiguity, improving meeting hygiene, protecting focus, making unwritten rules visible, and giving people more than one way to contribute.
Get that right, and you are not just creating a more inclusive team. You are building a better one.
About the expert
Anette Jacobs is a neurodiversity-affirming, trauma-informed coach and facilitator, and an EMCC Global EIA Senior Practitioner. She is the founder of Rooted Flow Coaching and works across psychological safety, leadership development, burnout prevention, and inclusive learning design. For readers less familiar with coaching accreditation, the European Mentoring and Coaching Council’s EIA framework is an internationally recognized professional standard for coaches and mentors.
Watch: In this short clip, Anette Jacobs explains why managing neurodiverse teams starts with understanding how different people process work, communication, and pressure.
Table of Contents
Start with a Better Leadership Model (design for variability, not sameness)
One of the most useful ideas from Anette’s session is that neuroinclusive leadership begins by moving away from a deficit lens.
Too many workplaces still ask, explicitly or implicitly: How do we help people fit the system?
Better leaders, on the other hand, ask a different question: How do we design the system so more people can do excellent work within it?
That is a critical shift in reasoning. Acas guidance on making organizations neuroinclusive recommends building these practices into day-to-day management rather than relying on one-off fixes after problems have already surfaced.
For technology leaders, this means accepting a simple truth: not everyone thinks, communicates, prioritizes, or recharges in the same way.
Some people do their best thinking in fast verbal discussion. Others need time to process. Some thrive in high-collaboration environments. Others produce their best work with fewer interruptions and clearer written expectations.
But that does not mean lowering standards. It means removing unnecessary barriers to high performance.
A common leadership mistake is to assume that support for neurodivergent colleagues is exceptional, highly individual, or somehow in tension with performance.
In practice, however, many of the changes that help neurodivergent team members also improve execution for everyone:
Clearer agendas
Quieter environments for deep work
Fewer unnecessary interruptions
Written follow-ups after meetings
Better prioritization
More flexible ways to contribute
Fewer unwritten rules
This matches current Acas recommendations on neuroinclusive organizations, which emphasize manager capability, regular check-ins, clearer processes, and adjustments that can often be normalized more widely across the org.
In other words, much of neuroinclusive leadership is simply good operational leadership.
If your managers rely on ambiguity, constant interruption, poorly designed meetings, or inconsistent expectations, the strain will be felt across the team, whether people disclose a neurodivergent condition or not.
5 Pressure Points Senior Leaders Should Fix First
1. Meetings
Meetings are one of the biggest sources of avoidable cognitive load.
When too many people are talking, topics move too quickly, the purpose is unclear, and decisions are not written down, some team members will struggle to process in real time. That does not mean they lack insight. It usually means the meeting itself is poorly designed.
For senior tech teams, the solution is not complicated: standardize a better meeting model, like this:
Share the agenda in advance
State the purpose clearly
Appoint a chair for complex discussions
Keep to one conversational thread at a time
Capture decisions and actions in writing
Allow async input before and after
Make camera use intentional rather than automatic
This is especially important in distributed organizations. CTO Academy’s guide to building resilient remote engineering teams is a strong companion piece here because resilient remote practices often overlap with neuroinclusive ones: better async communication, clearer norms, and more deliberate collaboration.
2. Sensory Load
Not all underperformance is a capability issue. Sometimes it is an environment issue.
Open-plan offices, constant Slack notifications, hot-desking, back-to-back meetings, and noisy collaboration rituals can create a level of sensory and cognitive friction that steadily erodes attention and energy.
Acas guidance on adjustments for neurodiversity points to practical changes such as quieter workspaces, flexible working arrangements, adjusted communication methods, and environmental changes that reduce unnecessary strain.
For tech leaders, the relevant question is not whether your environment is “normal.” It is whether it helps people do high-value knowledge work well.
If your team needs sustained concentration to debug systems, write architecture, review code, investigate incidents, or make decisions under uncertainty, then noise and interruption are not minor irritations. They are performance issues.
This connects directly with CTO Academy’s article on how to avoid burnout in your tech team, because unmanaged cognitive overload and relentless context switching are major contributors to burnout, even if they are not always named that way.
3. Processing Time and Executive Function
Senior leaders often reward speed of response more than quality of thought, usually without realizing it.
In reality, some people need more time to process information, prioritize options, formulate a response, or switch between tasks. If your culture expects instant answers to complex questions, you will systematically disadvantage some of your best thinkers.
A better leadership approach is to make reflection possible:
Send questions or prompts in advance
Separate brainstorming from decision-making
Give people time to reflect before responding
Break complex questions/requests/tasks into smaller parts
Follow up verbal discussions with written summaries
Avoid treating thinking time as disengagement
This is not only more inclusive. It often leads to better decisions.
It also fits a broader leadership principle: strong teams need both pace and reflection. CTO Academy’s How to Be an Effective CTO makes a similar case for leadership that is strategic and deliberate rather than purely reactive.
4. Unwritten Rules
Every organization has hidden norms. The problem is that hidden norms create a hidden tax.
Think of it this way: if nobody explains how decisions actually get made, how much detail is expected, when disagreement is welcome, what escalation looks like, or what “ownership” really means, some people will spend enormous energy decoding the culture instead of doing the work.
Leaders should make these rules visible:
Communication norms
Meeting expectations
Escalation paths
Definitions of urgency
How feedback is given
What good performance looks like
How can people ask for support
This is particularly important for leaders entering a new org or reshaping an existing one. Your First 90 Days in a CTO Role is a useful related read because the same principle applies: clarify priorities, observe how decisions really happen, and make expectations explicit early.
5. Manager Behavior Under Pressure
One of the least discussed aspects of neuroinclusive leadership is the manager’s own state.
Managers who are overloaded, ambiguous, reactive, or constantly improvising tend to create fear and confusion even when they mean well. Managers who are calmer, clearer, and more intentional create more psychological safety.
That matters because neuroinclusive leadership is not built only through policy. It is built interaction by interaction.
Managing neurodiverse teams well is not about special handling. It is about designing a better leadership system.
What Good Neuroinclusive Leadership Looks Like in Practice
For SLTs, the goal is not to become an expert in every neurotype. The goal is to create an environment where people do not have to waste energy battling preventable friction.
That usually means doing five things well.
1. Be Strengths-led, Not Stereotype-led
Avoid making assumptions based on labels.
Two people with the same diagnosis may need completely different support.
Instead, ask a few practical questions:
What kind of work helps you do your best thinking?
What tends to drain your energy fastest?
What meeting format helps you contribute most effectively?
What should I do more or less of as your manager?
What gets in the way of doing excellent work here?
2. Default to Clarity
Clarity is one of the most underrated forms of support.
To achieve it, use written agendas, explicit priorities, clear deadlines, named owners, and documented decisions. The more ambiguity you remove, the more capacity your team has for higher-order work.
3. Offer More Than One Way to Contribute
Not all valuable contributions happen live, verbally, or in the room. For example:
Written comments
Chat
Pre-reads
Post-meeting follow-ups
Async decision notes
Smaller group discussions
Camera-optional participation where appropriate
That often improves not just inclusion, but the quality of the thinking you get back.
4. Reduce Unnecessary Friction in the Environment
Audit how work actually feels:
How noisy is the office?
How interrupt-driven is the team?
How many meetings are avoidable?
Are deep-work blocks protected?
Do people have a reliable way to step out of overload?
5. Make Support Normal, Not Exceptional
Support works best when it is routine.
Acas recommends training managers, normalizing supportive conversations, reviewing workloads, and making it easier to discuss what helps without forcing unnecessary disclosure. GOV.UK guidance on disability at work also makes clear that employers may need to make reasonable adjustments where someone would otherwise face a substantial disadvantage.
That means leaders should stop treating support as a last resort and start treating it as part of responsible team design.
A Practical 30-day Plan for CTOs and Senior Engineering Leaders
A Practical 30-day Plan for CTOs and Senior Engineering Leaders for Managing Neurodiverse Teams – visual representation of the plan week-by-week with action steps for each week
As the graphic suggests, if you want to improve quickly, start here.
Week 1: Audit friction
Review your team’s operating environment:
Meeting volume
Meeting quality
Office or remote distractions
Slack and email expectations
Role clarity
Manager consistency
Hidden cultural norms
Ask each manager to identify one team ritual that creates unnecessary cognitive load.
Week 2: Standardize Better Defaults
Introduce a few baseline expectations across leadership teams:
Agendas before meetings
Written action summaries after complex discussions
Explicit turn-taking in large meetings
Camera-optional by default
Protected deep-work time where possible
Week 3: Improve Manager Conversations
Coach managers to ask better questions:
What helps you do your best work?
What gets in the way?
Which parts of the week feel hardest to manage?
How could we change the system, not just your coping strategy?
Week 4: Formalize What Should Not Depend on Manager Goodwill
Create or strengthen the mechanisms that make support durable:
Meeting norms
Flexible working principles
Guidance on adjustments
Manager training on neuroinclusive leadership
Continuity practices so that support does not disappear when line management changes
This is also where a broader culture conversation can help. CTO Academy’s Balancing Team Support and Executive Pressure case study is a useful related read because it speaks to the leadership tension many senior managers feel between delivery expectations and sustainable people leadership.
The Leadership Takeaway
The most useful lesson from Anette Jacobs’ session is that leading neurodiverse teams well is not about creating a parallel management system. It is about designing a better one.
For senior technology leaders, that means:
More clarity
Less ambiguity
Stronger manager capability
Better meeting hygiene
More thoughtful environments
More flexibility in how people contribute
Less reliance on unwritten rules
More attention to how work feels, not just what gets shipped
Do that well, and you create a team that is not only more inclusive, but more resilient, more thoughtful, and more effective.
That is good leadership, full stop.
Ready to become a more effective technology leader?
Explore CTO Academy’s programs, expert-led resources, and leadership community for senior tech professionals navigating the real challenges of scale, people, and execution.
What does it mean to manage a neurodiverse team well?
Managing a neurodiverse team well means designing the way your team works so people with different thinking, communication, and processing styles can perform at their best. In practice, that means reducing unnecessary friction, improving clarity, making expectations explicit, and giving people more than one way to contribute.
Is neuroinclusive leadership only relevant if someone has disclosed a diagnosis?
No. Neuroinclusive leadership is useful whether or not someone has formally disclosed a diagnosis. Many of the practices that support neurodivergent colleagues, such as clearer meetings, better documentation, flexible communication, and reduced sensory overload, improve working conditions and performance for the whole team.
What are the biggest mistakes leaders make when managing neurodiverse teams?
The most common mistakes are relying on ambiguity, expecting instant responses to complex questions, overloading people with poorly run meetings, leaving cultural norms unspoken, and treating support as something exceptional rather than part of good leadership. Another common mistake is making assumptions based on labels instead of understanding individual needs.
Do managers need specialist training to support neurodivergent employees?
Managers do not need to become clinical experts, but they do need the skills to lead with clarity, curiosity, and consistency. Good manager training should help them run better meetings, ask better questions, respond calmly under pressure, and make practical adjustments that improve how work gets done.
What are some simple changes that make a team more neuroinclusive?
Simple changes include sharing agendas in advance, writing down decisions and action points, allowing async input before or after meetings, protecting time for deep work, reducing unnecessary interruptions, clarifying priorities, and making team norms more visible. Small operational improvements often make a significant difference.
How can senior technology leaders make neuroinclusion part of team culture?
Senior leaders can make neuroinclusion part of team culture by setting better defaults across the organisation. That includes clearer meeting standards, more thoughtful workload management, better documentation, flexible ways of contributing, and manager expectations that reward clarity rather than constant reactivity. Culture changes when these practices become normal, not optional.
Why does neuroinclusive leadership matter for team performance?
Neuroinclusive leadership matters because it helps remove avoidable barriers to focus, communication, and decision-making. When people are not wasting energy dealing with poorly designed systems, they can contribute more effectively. The result is often a team that is not only more inclusive but also more resilient, more thoughtful, and better able to perform under pressure.
Whenever they must manage distributed teams, technology leaders face the dual challenge. The first is driving outcomes. The second is nurturing a coherent, connected culture. This playbook offers a step-by-step guide to building resilient remote engineering teams equipped to thrive across time zones and communication barriers.
1. Assess Current Team Structure
Start with a situational audit:
Map out current roles, overlap in working hours, and collaboration effectiveness.
Identify gaps in visibility, autonomy, and performance tracking that might hinder remote efficiency.
2. Define Remote Work Policies
Establish policies that align with your business objectives and team diversity. Include:
Expectations for availability
Documentation standards
Meeting etiquette
Boundaries between work and rest.
3. Set Up Communication Cadence
Regular touchpoints are essential. This is what you should do:
Use daily stand-ups, weekly retrospectives, and monthly strategy calls to synchronize efforts.
Tailor formats to avoid fatigue and ensure inclusion across time zones.
4. Implement Collaboration Tools
Select and integrate a tech stack for seamless collaboration. Essentials include:
Version control (Git)
Project tracking (Jira)
Documentation (Confluence)
Messaging (Slack).
TIP: Automation can bridge tool silos.
5. Onboard Remote-Focused Culture
Onboarding should instill values, not just workflows. Therefore, introduce peer mentoring, asynchronous onboarding journeys, and culture-building rituals like virtual coffee hours to embed a shared ethos.
Use dashboards for velocity, PR cycle time, and DORA metrics.
Supplement with pulse surveys and regular 1:1s to uncover sentiment trends.
7. Create a Continuous Feedback Loop
Enable retrospectives every 4–6 weeks.
Capture feedback anonymously and publicly.
Adapt rituals and tooling based on evolving needs to foster continuous improvement.
With intentional leadership and robust systems, remote engineering teams can exceed the impact of colocated peers. Remember, resilience emerges not from tools but from trust, clarity, and shared purpose.
Recently, we surveyed technology leaders and engineers to explore the key difficulties organisations face regarding contemporary work arrangements. The study presented participants with a list of potential challenges and recorded the frequency with which each was identified.
As you can see, sustaining creativity and innovation was most frequently selected, closely followed by fostering a sense of belonging.
Maintaining effective collaboration, onboarding new talent, balancing flexibility with cohesion and preventing work culture fragmentation are also high up in the focus.
In contrast, addressing overwork and optimising office space were noted far less often. Nonetheless, to some, they are pivotal.
This article provides immediately applicable solutions to these challenges, offering technology leaders the practical tools to navigate workplace complexities effectively.
1. Sustaining Creativity and Innovation
Challenge: In a hybrid or remote environment, fostering creativity and innovation can be difficult due to reduced spontaneous interactions and isolated workflows.
In 1968, Dr. Spencer Silver, a chemist at 3M, was attempting to create a super-strong adhesive for use in aircraft construction. Instead, he accidentally created a weak, pressure-sensitive adhesive that could be peeled away easily without leaving a residue. At first, this invention seemed like a failure – after all, who would want a glue that doesn’t stick properly?
It wasn’t until 1974 that his colleague, Art Fry, came up with the idea of using the adhesive to create bookmarks that wouldn’t fall out of his hymnal. This spark of creativity led to the development of the Post-it Note.
Would Fry even find out about Silver’s invention if they worked remotely and had isolated workflows?
Yes, the first action step is to synchronise workflows. In-house, hybrid or fully remote; it doesn’t matter as long as the workflows are synced.
But there’s another problem – it’s not always people’s fault they are not creative and innovative.
Get ready to face the hard truth about your leadership style and/or organisation’s culture in general.
Only 24% of employees reported feeling curious in their jobs regularly.
Approximately 70% said they face barriers to asking more questions at work.
In other words, leaders might believe they allow creativity and entice curiosity, but their team members certainly don’t feel that way.
This leads us to the most interesting thing in the study and that’s the list of 3 key innovation/creativity blockers:
Leaders often believe that encouraging curiosity will lead to a costly mess and make the company harder to manage.
There’s a concern that allowing employees to explore their interests would lead to more disagreements and slow down decision-making processes.
Despite listing creativity as a goal, people frequently reject creative ideas when actually presented with them.
Hence, the
Immediate Solutions
There are a few important takeaways from this study and general practice that should mitigate the problem of lack of creativity and innovation:
Create an environment where employees feel safe to ask questions, explore and share new ideas without fear of ridicule or punishment.
Understand that exploration doesn’t always produce immediately useful information but often yields better long-term solutions that require many mini-solutions in between to work.
While some structure is necessary, allow for flexibility in exploring new ideas and approaches.
Implement recognition systems that reward not just successful outcomes, but also the process of exploration and learning.
However, not all people are creative (and innovative) by default. In fact, only a handful are. So what is the simplest method to entice creativity in otherwise uncreative individuals?
This may sound counterintuitive, but setting strict limits can be your ace in the hole.
Constraints, when approached with the right mindset, can be a catalyst for creativity rather than an obstacle.
In 1960, Bennett Cerf, the founder of Random House, bet the famous Dr. Seuss $50 that he couldn’t write an entertaining children’s book using only 50 unique words. This challenge came after Dr. Seuss had already successfully written “The Cat in the Hat” using a limited vocabulary of 236 words from a list of 348 words that first-graders should know.
The result?
Dr. Seuss accepted the challenge and produced “Green Eggs and Ham,” which became:
His best-selling book
The fourth best-selling children’s hardcover book of all time
A book that has sold over 200 million copies worldwide
Creativity thrives under limitations: Rather than stifling creativity, the 50-word constraint forced Dr. Seuss to be more innovative in his storytelling.
Quality over quantity: Despite the limited vocabulary, the book became a masterpiece of children’s literature.
Problem-solving skills: The constraint required Dr. Seuss to approach the writing process differently, enhancing his problem-solving abilities.
Focus and efficiency: The word limit forced Dr. Seuss to be concise and focused in his storytelling.
In business, limited resources often lead to innovative solutions while time constraints can increase productivity and focus.
2. Fostering a Strong Sense of Belonging
Challenge: Employees, especially those working remotely, often struggle with feeling disconnected from the company culture and their colleagues.
Take it from someone who’s been working remotely for the last 11 years – this is a tough nugget to break. It will take a hard personal investment to create a sense of belonging. Nonetheless, it is achievable.
Now, the widely used solutions are:
Virtual Team-building Activities
Regular Check-ins
Weekly Team Meetings
Monthly Team Meetings
Recognition Programs
Company-wide Rituals
Make no mistake; all of them work, but only if you a) give a team member a true sense of purpose and b) hold them accountable.
Consider a complex, interconnected machine – a sophisticated network of gears, levers and circuits. This machine, let’s call it “Synergy”, represents a tech organisation operating in a remote environment. Its smooth functioning depends entirely on the coordinated effort of its individual components – the remote tech teams or members.
The organisation’s leaders, the “Master Engineers”, understand that simply providing the blueprints isn’t enough. They need to instil a sense of purpose and accountability within each team, each member, each cog in the Synergy machine. It is an eight-step process.
Step 1: Ensuring Seamless Operation
To cultivate purpose, the Master Engineers ensure every team member understands their critical role in the machine’s overall operation. They explain how even the smallest line of code contributes to the larger function, and how each bug fix prevents a catastrophic system failure.
Step 2: Directing Personal Growth into Synergy’s Progress
They also work with each team to set “precision-engineered” goals – targets that align not only with Synergy’s overall performance metrics but also with individual career trajectories. A junior developer might aim to master a new coding language, while a senior architect might focus on designing a more efficient data flow.
Step 3: Reinforcing the Significance of Individual Contributions
Regularly, the Master Engineers showcase the impact of each team’s work – how a new feature improved user experience and how a security patch prevented a data breach. In other words, they demonstrate real-world consequences.
Step 4: Laying the Groundwork for Responsibility
To enhance accountability, the Master Engineers establish clear “performance parameters” – specific, measurable outcomes for each team and project. These defined expectations might include code quality metrics, sprint completion rates or client satisfaction scores.
Step 5: Encouraging Self-regulation and Peer Oversight
Synergy is equipped with a sophisticated “monitoring system” – a suite of project management tools and performance dashboards that provide real-time visibility into the machine’s operation.
Step 6: Ensuring Alignment
The Master Engineers also conduct regular “calibration sessions” – one-on-one and team meetings to discuss progress, address challenges and performance deviations and refine goals.
Step 7: Fostering a Culture of Ownership
They empower team members to take initiative in problem-solving and decision-making.
(QUOTE)When individuals feel responsible for their part of the machine, they’re more likely to hold themselves accountable for the results.
Step 8: Reinforcing the Value of Accountability
Finally, the Master Engineers recognise and reward exceptional performance – publicly acknowledging teams and members that consistently exceed expectations and demonstrate strong ownership.
The outcome?
An environment where each team member feels deeply connected to their purpose and takes genuine ownership of their responsibilities. Such a combination not only drives performance but also ensures long-term stability and success.
3. Maintaining Effective Collaboration
Challenge: Coordinating efforts across distributed teams can result in inefficiencies, miscommunications and delays.
The problem is that managers stick to the paradigm of the office environment, completely ignoring the fact that their teams operate from living rooms, bedrooms and basements of their homes. And homes have an opposite paradigm.
Traditional office environments are structured for face-to-face interactions, spontaneous conversations and immediate feedback. Homes, on the other hand, are designed for personal life and privacy, creating a fundamental paradigm shift.
Moreover, office environments rely heavily on non-verbal cues, body language and spontaneous exchanges, which are largely absent in remote settings.
Immediate Solutions:
When using collab platforms like Nifty, enforce ‘tasking’ instead of messaging for even the smallest and simplest of tasks – without exceptions. In other words, the “Can you check that update” message transforms into the “Check the XYZ Update” task.
Ensure clarity in task ownership and deadlines.
Create and enforce the use of priority tags in tasks (eg, High Priority, Medium Priority, Low Priority)
Maintain an immutable team meeting schedule (to create a sense of expectation and, eventually, a loop of habit).
Set clear agendas and outcomes for every type of meeting.
During meetings, entice transparency and proactive updates to avoid misunderstandings.
Create a centralised knowledge base by developing and maintaining a repository of processes, procedures and frequently used resources.
Whenever possible, use visual project roadmaps that detail timelines, milestones and responsibilities.
4. Onboarding and Developing New Talent
Challenge: Remote and hybrid setups make it harder for new employees to integrate quickly and build meaningful workplace relationships.
If you can put together an extremely precise onboarding program, even better.
That’s basically all you can do besides providing access to the centralised knowledge base and training programs. If it sticks, fine. If not, repost the job ad. Some people are simply not a team material and there’s nothing you can do about it.
Here’s the thing. Onboarding and developing a new talent is directly related to and dependent on a sense of belonging. So by focusing on #2 (Fostering a Sense of Belonging), you will effectively address #4 (Onboarding).
Belonging is a key factor because a sense of belonging is crucial for new employees to feel engaged, confident and committed to their organisation.
5. Balancing Flexibility with Organisational Cohesion
Challenge: The push for flexible work arrangements can sometimes undermine organisational unity and alignment with company goals.
We are back to the shifting paradigm where an employee constantly changes between home and office. The first thing you need to do is to create a shared digital workspace – and use it. It doesn’t matter if a part of the team is in the office; they still must use that workspace as long as even a single member is remote.
What happens is that team members who work from the office, tend to disregard the fact that some of them are missing. In their minds, that person is on leave or has a day off. It’s simply part of that common office paradigm we mentioned earlier.
Additional Solutions:
Define clear policies (guidelines) that balance autonomy with necessary in-office collaboration.
Establish overlapping work hours for synchronous communication.
If in any way possible, schedule physical meet-ups to reinforce team spirit.
Create an internal knowledge base to ensure consistency in workflows and processes.
Prioritise accountability by all means.
If you manage distributed teams, involve all team members in defining and refining the team’s vision and goals.
6. Preventing Fragmentation of Work Culture
Challenge: A dispersed workforce can lead to fragmented cultures, where different teams develop disconnected subcultures.
Immediate Solutions
Several experienced leaders have successfully addressed this issue through innovative approaches and strategic initiatives:
Automatic Created a Unified Digital Culture
Automattic, the parent company of WordPress.com, provides an efficient example of maintaining a cohesive culture in a fully distributed workforce. Their leadership team adopted a “write early, write often” strategy to foster transparency and collaboration.
By encouraging team members to share updates and feedback in shared documents, they created a virtual environment that mimics the organic interactions of a physical office.
IBM’s leadership team faced similar challenges when shifting to a remote-first strategy in 2020. Initially, they observed a major decrease in employee engagement compared to in-person work. To combat this, IBM’s leaders implemented three innovative solutions:
Regular virtual town halls to maintain open communication.
Social hours to foster informal connections.
Integration of virtual reality (VR) in leadership training programs.
Tariq, a young leader in a global firm, successfully addressed cultural fragmentation in his 68-person division spanning 27 countries and 18 languages. His approach included:
Introducing a unifying team motto: “We are different yet one”.
Creating opportunities for employees to share their cultures.
Implementing a zero-tolerance policy for cultural insensitivity.
These initiatives helped bridge cultural divides and rebuild team cohesion, demonstrating the importance of acknowledging and celebrating diversity while fostering unity.
We Emphasise Shared Purpose
CTO Academy leaders consistently remind team members of their common purpose and how their work contributes to overall company goals. During weekly team calls, for instance, a CEO reviews the group’s performance relative to company objectives. This practice helps maintain focus and unity, especially when team members are geographically dispersed like we are.
Personal Connection and Recognition
A manager based in Dallas, Texas, inherited a large team in India following an acquisition. To prevent cultural fragmentation, he:
Involved remote employees in important decisions.
Maintained frequent contact to discuss ongoing projects.
Personally called team members to give them their birthdays off.
Leverage technology to improve communication and capitalise on diversity while emphasising unity.
Maintain personal connections across geographical boundaries.
7. Addressing Employee Overwork and Burnout
Challenge: The blurred boundaries between work and home life in remote and hybrid setups have led to increased burnout rates.
If this is the prevalent issue in your organisation, you need to take a big step back and reorganise your processes. There is something in your operations that disturbs the balance.
Immediate Solutions:
1. Set Boundaries on After-hours Communication
In Germany, for example, contacting employees after hours is generally prohibited, with exceptions for emergencies and specific roles. The aim of this measure is to:
Actively promoting and tracking employee vacations to ensure they take breaks can be somewhat challenging when managing distributed teams. In our experience, the best approach is to utilise your central digital workspace.
Our COO, for instance, has implemented a time-off calendar where team members easily schedule their time off in Nifty after manager approval. This provides immediate visibility for the entire team, showing who’s out and for how long. It simplifies tracking and helps with processes because a team member can’t receive a task with a deadline that doesn’t take the time off into account.
3. Implement No-meeting Days
These are basically dedicated days for deep work without interruptions.
4. Provide Mental Health Resources
In a fast-paced environment, burnout is inevitable. One approach is to provide comprehensive mental health resources such as counselling services, webinars or self-help materials. They should be:
Easily accessible
Encouraged
Utilised
Confidential
This will enable you to identify and manage stress and burnout early on.
8. Optimising and Adapting Office Space
Challenge: With hybrid work models, many companies struggle to justify office expenses while ensuring the space remains functional.
Real-time desk and room booking systems to prevent scheduling conflicts and maximize space usage.
Occupancy sensors to provide data on space utilisation, helping manage office density and optimise layouts.
All-in-one platforms like Microsoft Places and Gable for comprehensive workspace management, offering features such as AI-driven work schedule optimisation and access to flexible workspaces.
The point is to rethink the organisation of the office space because clearly something is off. Maybe you have collaboration hubs but no quiet thinking bunkers where an employee can retreat to contemplate the problem without distractions. Perhaps it’s overcrowded or oversaturated with unnecessary equipment and simple re-arrangement could go a long way.
This is where technology or a good old professional interior designer helps.
Now, you may have also heard of ‘hot desking’ otherwise known as ‘hoteling’. If you are thinking about implementing such an option, consider these factors:
Loss of personalisation
Psychological discomfort
Reduced productivity
Weakened social structures
Decreased job satisfaction
Sense of belonging
That’s the less discussed outcome of booking desks and spaces practice. As a species, we are wired to grow attached to our personal spaces and the office desk is no exception. Drop us anywhere and we’ll transform a hole in a rock into a cosy and warm place with a personal signature.
Just for fun, imagine a bunch of kids storming into a room filled with cool toys – day after day.
Conclusion
So to sum up:
Creativity and innovation can be fostered through synchronised workflows, a safe environment for exploration and perhaps setting strict limits to encourage creative problem-solving.
Giving team members a true sense of purpose and holding them accountable can help them feel strongly connected.
Effective collaboration can be maintained by enforcing tasking instead of messaging, ensuring clarity in task ownership and deadlines and creating a centralised knowledge base.
Onboarding and developing new talent can be effectively addressed by focusing on fostering a sense of belonging.
Balancing flexibility with organisational cohesion requires creating a shared digital workspace, defining clear policies and establishing overlapping work hours for synchronous communication.
Leveraging technology, maintaining personal connections across geographical boundaries, and emphasising shared purpose can prevent the fragmentation of work culture.
Addressing employee overwork and burnout requires setting boundaries on after-hours communication, encouraging time off, implementing no-meeting days and providing mental health resources.
Finally, optimising and adapting office space can be done by using smart space management systems and rethinking the organisation of the office space.
Rebecca Murphey, the Field CTO at Swarm, delved into improving developerproductivity in a recent CTO Shadowing session we hosted.
However, she did not focus on zooming in on individual developers even though there’s talk on LinkedIn about how some 10% of them aren’t doing any work. Instead, Rebecca dealt with teams working together to ship value to customers and, more importantly, how to further improve that process.
Because, at some point, you stop valuing people’s contributions in terms of time, and start valuing their contributions in terms of life goals. In other words, you start valuing the outcomes they produce that may expand beyond actual coding or otherwise expected output.
Additionally, Rebecca looked into the overall developer experience (not to be mistaken for ping-pong tables and kegs) and the concept of business outcomes in terms of its correlation to developer productivity.
The Guiding Principle for Improved Developer Productivity
The guiding principle is simple:
We want our developers to work efficiently on the right things.
For that to happen, all three concepts: productivity, experience and outcomes, must come together to lead to a successful engineering organisation. And it all depends on tech leaders and their ability to set the environment and processes right.
So for a starter, ensure that your team isn’t working on twenty things at once.
Second, if they are drowning in interruptions, they must have the capacity to reduce them.
If interruptions occur regularly, ask yourself the following questions:
Did the organisation set clear and reasonably consistent priorities?
Are the teams empowered to follow those priorities and seek the outcomes the business wants?
Are teams allowed to say no?
Where Leaders Often Go Wrong and Damage Productivity
Teams are forced to work on too many things at once
Missing automation processes
RULE OF THUMB: A team of four people should work on one story before moving to another instead of having each member work on a separate story.
Habits and Tendencies of Engineers – US vs. Outside the US
Cultural differences are profound when it comes to productivity. In the US, for instance, people tend to work more independently; i.e., less collaboratively. They want to own a project so that they can brag about it at their performance review in the hope of getting a bonus.
Outside of the US, on the other hand — and this is a vast generalisation –, there is a lot more collaboration. In other words, people tend to work together on something as a team.
The same goes for monetary incentives: they are more appreciated in the US than outside the US.
Preventing Common Failure Modes
As a leader, there’s a lot that you can do to intervene in some of the most common failure modes:
Prevent working on too many things.
Defend against interruptions.
Reduce “waste work” (the result of the constant switching or wasting time on deprecated projects).
Fail to address these issues and the outcomes are:
Less predictable delivery
Higher error rates
More wasted work
Flow Efficiency
Flow efficiency measures the proportion of active time spent on a task compared to the total time it takes to complete the task, from initiation to production.
Ideally, you want to see around 80% active and 20% idle time.
If, on the other hand, you get 30% active time and 70% idle time, either you are utilising about 30% of the capacity or you’re trying to do too many things. Also, the team might be too small to handle so many pull requests in such a complex system. Or, you have an optimal-size team, but there are too many external processes they have to go through (eg, security or API reviews, manual QA process…).
How to Define Capacity
Here, we are talking about predictability ratherthan productivity. It is a more suitable term because to determine the capacity, you must know the likelihood of having something finished in X days.
By default, this assessment is based on historical performance. For example, you know that your team can deliver five small stories a week. Hence, the predictability gives you their capacity.
TIP: Use Gen AI to build the model. Include variables such as flow efficiency, delivery and lead time and failure rate.
The other thing that helps with capacity planning is to ensure you’re never doing anything big. That, of course, doesn’t mean that you never accomplish anything big. Instead, you work on small things that lead to big things. Here’s an example:
You can ship one ticket at a time, but the feature may take 20 tickets before it’s done. Now, this number might seem insignificant; however, don’t forget that you’re a) constantly putting that code in production, and b) making sure that the right people can see the current state of it even though your customers perhaps can’t. When you can redo this process, it is called reduced batch size.
When you can reduce the batch size and get each of your units of work down to about the same size, your predictability goes up and your capacity becomes more predictable.
Let’s go even deeper now:
We know that we can get five stories done every week. Here’s the key: Every story should be 1 to 2 points, not 8 or 13. As soon as you start talking about eight and thirteen points, you have walked away from predictability. In other words, larger stories have a greater likelihood of being carried over to the next sprint.
Speaking of sprints…
Sprints are great training wheels, but once you get basic alignment and prioritisation in place, Kanban can be a lot more effective because it reduces the ceremonies and focuses the team on a specific goal. However, bear in mind that Kanban might be more suitable for mature teams because it focuses on predictability.
TIP: If you’re using Jira, you can make the column red when you have too many things in progress and/or review.
Now we are getting to the part where you acquire the relevant data.
The “Brains Methodology†Framework
The principle of the Brains Methodology is to get a baseline using DORA metrics for different teams (the four metrics that look at the tension between delivery velocity and delivery quality) and then assess the current state.
Now, arguably the best approach here is to just sit and watch your team(s) working; especially if you have a situation where your lead time is one hour or something like that, but every deployment is broken. You want to understand why it is happening.
You’d be surprised how much you learn about your teams and processes if you just sit and watch.
Now, here’s the thing. You want to speak to each member besides doing surveys because you want to understand individual pain points and get their opinions on improvements. For example, you want to know what frustrates each of them daily while they work on projects and/or systems.
Once you have the answers, use them to implement changes and show the team that their feedback leads to concrete actions.
For example, you might want to increase productivity by 20%. One way to achieve that is to actively protect 40% of their time by acting as a shield against, say, product or sales teams that are trying to infringe on that time. This shielding helps them with problem-solving because they know that they can put their brains together without being interrupted.
On the technical side of things, you could implement a CI/CD process, get automated tests up and running and place alerts in your production.
However, the most positive changes come from cultural shifts.
Take Stripe for an example. The company invested in developer productivity early on thanks to one engineer who realised that he could be more productive working on the builds than on the features using those builds. That gave birth to the platform and had an enormous impact on how work gets done at Stripe even today. The moral of the story is to let them choose their battles from time to time.
Remember, it’s better to focus on outcomes than on outputs; for example, an effective delivery that lifted net retention by 3% or reduced the cost of customer acquisition by 1%.
How to Subtly Introduce Brains Methodology?
(Without making everyone feel watched and having their every commit scrutinised.)
Start by explaining that this is about transparency and not things being put under the microscope. And that transparency will eventually provide evidence for their claims.
For example, an engineer might be frustrated with constantly working on keeping the lights on (KTLO). This type of work often limits opportunities to take on projects that would lead to a good performance rating. The team might also be concerned about their career prospects if they spend up to 80% of their time KTLO-ing. The Brains Methodology can help alleviate these concerns by providing clear evidence of how their time is actually being spent. This data can then be used to justify requests for additional resources or to support arguments for shifting priorities towards more innovative projects.
Of course, every now and then, you have to remind them that we live and operate in capitalism and that they are paid for the value they bring to the organisation. But when it gets hard for them, they must feel free to inform you about their predicaments because you’d want to know about it so that you could figure out what needs to change.
Now, as you can imagine, this transparency will shine a light on the imposed processes more than it will on teams. And that’s a good thing because more often than not, it’s the process that impedes the progress. Brains Methodology gives you a developer productivity tool to not only see inside a single process but also to get an overview of the intricate correlations and dependencies between multiple processes at once.
That’s why we are looking into team performance rather than individual. And that’s why we should be more interested in outcomes than outputs. Something to contemplate, isn’t it?
Recently, we had Emily Castles, CTO at a scaling start-up, Boundless, joining us for her fourth CTO Shadowing session. She reflected on their journey over the past year and, by doing that, provided an exclusive look into the challenges of a scale-up Chief Technology Officer who has to recover from severe financial cuts and consequent team losses.
Rebuilding the Teams
A year before, the financial cuts at Boundless affected product and tech teams. The product team especially suffered and was reduced to virtually nothing. At that point, of the original eight team members (a full development team with a product manager), only she and one other developer remained.
Having finally recovered from a period of downsizing and uncertainty, Emily focused initially on rebuilding the teams.
Now, the common scenario in start-ups is that employees have to cover areas outside their imminent scope of work. Emily quickly realised that, due to the specific nature of their products, they also needed a dedicated customer support person to offload work from HR and Payroll. With that addition, things finally got moving again.
Measuring Success in a Changing Landscape
As the company scales, the CTO requires more concrete metrics to measure success. In Emily’s case, they’ve implemented a company scorecard to track key performance indicators (KPIs) and gain a clearer picture of the company’s health.
The key metrics they were monitoring at this stage were:
Velocity
Customer engagement
Customer incidents
Of course, it took a while before they got in a position to actually measure success. It is just one of the realities of being a CTO in a scaling start-up. Security, data protection and onboarding new (big) customers were priorities. So at that point, measures of success were qualitative.
However, after implementing a company scorecard, they ended up with 15 metrics, measuring success and accountability weekly with a 13-week testing period.
Her immediate challenge was to define product metrics. One of them was the velocity measure. In Emily’s experience, this was the best place to start even though it’s not the best tool for measuring productivity.
The second one was the service-specific customer engagement metric; in other words, it is custom-made for the type of services Boundless is offering, and it should resolve the issue they had in the past where they didn’t really know if people were using people or products to solve the problem. Its purpose is, therefore, to measure the number of operations happening on a customer level while interacting with the product.
The final metric, this time from a project perspective, was customer incidents.
Besides measuring CSAT and NPS, Emily required insight into operational mistakes (eg, mistakes in payroll, a signed contract that has to be undone and redefined, bugs, etc.). The purpose was to immediately identify glitches in the system and improve the product/service.
You never know whether the thing that you’re about to measure is going to be right until you go and do it. — Emily Castles, Boundless CTO
As a scale-up CTO, you must always acknowledge the challenges of maintaining a culture of honesty and transparency as the company grows and the SLT becomes further removed from day-to-day operations. The emphasis must therefore be on open communication and public feedback channels to ensure visibility into potential issues. In practice, this means that if there’s a security incident (eg, breach) or anything like that, there should never be any kind of admonishment. You don’t want people sweeping problems under the carpet, after all, do you?
Third-Party Integrations and Outsourcing
The immediate goal Emily is trying to achieve is eliminating the need to enter every information twice. Customers are putting a lot of data in their own systems, and then they have to put it into the Boundless systems as well. Granted, the company has various ways to pull data from one system to another but integrating with third-party HRIS systems seems like the best solution. So it has been a priority, but she’s struggled to identify the most critical problem to solve to decide which of the available solutions would be optimal.
Another thing she’s currently evaluating is whether to use a unified API or integrate directly with individual providers. After all, the company plans to grow and a unified API might impose certain limits.
Emily is also considering outsourcing some aspects of the project, but she wants to keep core development work in-house while allowing external developers to work on the edges of the project.
Operational Expenditures and Internal Tooling
While operational expenditures haven’t been a major focus due to the company’s funding stage and relatively low operating costs, as the CTO, she is increasingly looking for ways to streamline internal operations and reduce the need for additional headcount.
As a part of that effort, she’s exploring no-code/low-code platforms like Retool and Microsoft Power Platform to build custom tools for internal teams.
Quarterly Retrospectives and Looking Ahead
Emily found the quarterly retrospectives with colleagues to be a valuable exercise, providing a structured opportunity for reflection and feedback. They also appreciated the external perspective and different language used in these sessions compared to internal meetings.
Looking ahead, she is focused on continuing to scale the company’s operations and product development efforts while maintaining a strong culture of transparency and collaboration. She is also excited to explore new technologies and approaches to streamline internal workflows and improve efficiency.
In the original shadowing session with Emily Castles, we explored the challenges and considerations of a CTO in a scaling start-up. It detailed topics such as:
Rebuilding and managing a development team
Implementing metrics and scorecards to measure success
Integrating with third-party systems and potential outsourcing
Managing operational expenditures and exploring internal tooling solutions
The value of retrospectives and external feedback
As always during these sessions, attendees had the opportunity to ask questions and share knowledge and experience. So if you haven’t already, sign up for CTO Academy Membership to not only draw from the experience of seasoned technology leaders in different industries but to offer your own unique perspective.
Key Takeaways
Building and maintaining a strong team is crucial for success. Emily emphasised hiring and retaining skilled developers and a product manager to drive product development.
Metrics and transparency are essential for effective scaling. As the company grows, implementing clear metrics and maintaining open communication channels become increasingly important for monitoring progress and identifying potential issues.
Exploring new technologies and approaches can streamline operations. In Emily’s case, it involves investigating no-code/low-code platforms and other tools to improve internal workflows and efficiency.
Our Digital MBA for Technology Leaders covers a wide range of business, technology and skills-related topics. One of the lectures in Module 1 (Leadership & Teambuilding) goes into detail about remuneration packages and renegotiating better terms for yourself.
It is one of the responsibilities of every technology leader that is not limited to the onboarding process of new developers but to the retention of talent as well.
In this summary of Julian Costley‘s lecture, we bring you the gist of everything, starting with the very first step.
Prerequisites for Designing a Remuneration Plan
Clear definitions of the roles and responsibilities of every member of your team and their level of experience.
An industry benchmark data by job title, industry and company’s geo-location.
Guidance from your CEO or CFO.
Company’s policies on stock options.
Company’s policies on bonus schemes.
The timescale for delivery of your plan.
How to Use Annual Salaries Reviews
First, match your people to the roles identified in the surveys.
Attenuate by industry and location.
Note growth rates and take into account expected rises for the following year.
Run your staff’s salaries against the benchmark salaries for their role.
Create variance columns:
One in absolute money and the other as a percentage variance to what they should be paying (benchmarked against the company and your new staff)
RULE OF THUMB: There’s nothing wrong with paying less than the benchmark figure, but only if you’re confident as a company that you can offer real advancement for that individual, training or projects that the competitors can’t match.
Example Bonus Against Performance
In a tech department, it should be a mix of technical milestones hit during the year in relation to what is expected to be achieved within the budget.
For example:
5% over performance = 10% bonus (max. 25%)
Remember, setting maximum percentage caps prevents some problems that you might run into.
TIP: Avoid setting individual bonuses for individual milestones. It’s a massive headache to set up and it sets you up for potential accusations of unfairness or favoritism.
Now that you have some idea how to set remuneration for your employees (the lecture explains it in much more detail), it’s time to learn how to improve your financial position in a few bullet points.
How to Negotiate a Better Package for Yourself
Explore the scope of promotion.
Use benchmark data.
Push for basic salary increases (by pointing out all your achievements).
Is more expected from you next year? (Larger budgets to manage, more staff, upcoming uniquely complex or business-critical issues and projects.)
If all else fails get a bonus increase.
Suggest that you want a salary increase three or six months ahead.
TIP: Ensure that your role in the company is fairly set at an equal level to other senior executives.
Key Points
Money is rarely the most important factor to IT professionals (but it does play an important role).
There are proven processes to benchmark salaries against the market.
Build incentives into your remuneration packages.
Be cognizant of the constraints the CEO and the CFO are under. In other words, help solve their problem don’t be the problem.
Look after your interests, but be careful not to reward yourself at the expense of your team.
When onboarding developers, you must always consider these four elements: technical empowerment, mentorship and collaboration, clear expectations and goals and continuous learning and growth. So think twice before delegating the entire process to HR without your direct supervision.
That said, before we lay down the onboarding program, we should quickly go over these elements and the common challenges associated with the entire process. As you are well aware, a good software engineer is not your everyday employee. They are mostly introverts with extremely high expectations on one hand and extremely low patience thresholds on the other.
So…
4 Main Elements of Successful Onboarding
(click to enlarge/download)
1. Technical Empowerment
Remember this: developers must hit the ground running.
In other words, they must have:
A development environment set up.
Access to necessary tools and code repositories.
Clear guidance on project structures and coding standards.
This creates a sense of competence and productivity right from the start, thus ensuring a positive onboarding experience.
2. Mentorship and Collaboration
Assigning a mentor or an “onboarding buddy” creates a supportive learning environment.
The mentor/buddy should therefore:
Answer questions
Provide context
Help navigate the company culture
Additionally, the mentor should further encourage collaboration with the development team through code reviews, pair programming and open communication. This, in turn, builds relationships and accelerates learning.
3. Clear Expectations and Goals
For a more effective onboarding, you first want to define three things here:
Developer’s role
Responsibilities
Expectations
Next, you must set achievable goals and provide regular feedback to help software developers understand how their work contributes to the team’s success. This practice provides a sense of purpose.
4. Continuous Learning and Growth
The onboarding process should be seen as a launch pad for ongoing development.
Therefore, providing opportunities for training, workshops and conferences shows a commitment to the developer’s growth and empowers them to expand their skills and stay current.
The developer onboarding checklist that we provide here is based on these four elements but, at the same time, it also answers common challenges.
Common Challenges of the Onboarding Process
As a CTO, you will inevitably face a challenge or two during the entire developer onboarding process. Time, knowledge, culture and communication issues will arise and exponentially grow in a remote work environment. Here are a few proven practices that address these challenges.
Time Constraints
Developer onboarding is often time-consuming because it requires significant effort from the new hire and existing team members. Your job is to balance the need for thorough onboarding while being under pressure to get new developers to contribute quickly.
The simplest solution is assigning small, manageable tasks early on. It enables developers to contribute quickly while getting familiar with the codebase and company practices.
Knowledge Gaps
Even experienced developers might have gaps in their knowledge of company-specific technologies, processes or codebases. Ensuring they get up to speed without overwhelming them or slowing down their progress can be tricky.
A combination of codebase walkthroughs, training, workshops and mentorship should fill any knowledge gaps and, subsequently, accelerate the learning process.
Cultural Integration
Integrating new developers into the company culture and team dynamics is often completely overlooked or in the best-case scenario takes too long. Fostering a sense of belonging and helping them navigate the social aspects of the workplace is crucial for their long-term success.
This is where team lunches, social events and a designated mentor come into play. Combined, these activities help new developers integrate into the company culture and build relationships faster.
Communication Challenges
Clear communication is vital during onboarding, but misunderstandings or misaligned expectations can always arise. It is, therefore, essential to establish open lines of communication and provide regular feedback to avoid any confusion or frustration.
We are talking about regular check-ins and clear expectations to ensure everyone is on the same page. In other words, if you feel somebody failed to understand what you were saying at the meeting, explain one more time.
Remote Onboarding
Onboarding remote developers presents unique challenges, such as building rapport and establishing strong working relationships without face-to-face interactions.
Remote onboarding often requires additional effort to ensure new hires feel connected and engaged. This most commonly includes frequent virtual meetings, screen-sharing tools and collaboration platforms to ensure effective communication and knowledge transfer in a remote setting.
However, don’t go overboard with this. Software engineers who opt-in for remote contracts do that for a reason. They work best when distractions are reduced to a bare minimum. So if you insist on daily virtual check-ins, it might backfire.
(This is one of the reasons our Digital MBA for Technology Leaders heavily focuses on soft skills along with technical and business ones.)
Scaling Onboarding
As your company grows and you hire more developers, scaling the onboarding process efficiently while maintaining its quality and effectiveness can be a challenge.
The only solution here is to continuously refine and replicate the structured approach we will now outline.
Developer Onboarding Checklist
Pre-Onboarding (Before Day 1)
Equipment and Account Setup:
Ensure the new hire’s workstation, laptop or any necessary hardware is ready.
Set up accounts for email, code repositories, project management tools, communication platforms and other relevant systems.
Provide necessary access keys, software licenses or security tokens.
Welcome Package:
Send a welcome email with essential information, such as their start date, time, location, dress code, parking information and who they should report to on their first day.
Include a company handbook or any onboarding documents they can review beforehand.
Consider sending a small welcome gift or company swag.
Day 1: Orientation and Introductions
Warm Welcome:
Greet the new developer personally and show them around the office.
Introduce them to their team members and key personnel from other departments they’ll interact with.
HR Onboarding:
Complete any necessary paperwork and formalities.
Provide an overview of company policies, benefits, and culture.
IT Setup:
Help them set up their computer, install the necessary software and connect to the network.
Ensure they have access to all the tools and resources they need.
Team Lunch or Coffee:
Arrange a casual team lunch or coffee break to help them get to know their colleagues in a relaxed setting.
Week 1: Project Integration and Training
Assign a Mentor or Buddy:
Pair them with an experienced developer who can answer questions, provide guidance and help them navigate the company culture.
Project Introduction:
Introduce them to the project(s) they will be working on.
Provide context, explain the goals and introduce the team members involved.
Codebase Walkthrough:
Give them a tour of the codebase, explaining the structure, coding standards and any important architectural decisions.
Set Up Development Environment:
Help them set up their local development environment, ensuring they can build and run the project.
Training and Workshops:
Provide training on any company-specific technologies, tools or processes they need to be familiar with.
Consider offering workshops or online courses to help them upskill or fill any knowledge gaps.
Month 1: Ramp-Up and Contribution
Assign Small, Manageable Tasks:
Start with small, well-defined tasks to help them get familiar with the codebase and build confidence.
Code Reviews and Feedback:
Conduct regular code reviews to ensure code quality and provide constructive feedback.
Encourage Collaboration:
Encourage them to participate in team meetings, brainstorming sessions and pair programming activities.
Regular Check-ins:
Schedule regular one-on-one meetings with their manager or mentor to discuss progress, address concerns and provide support.
Click to enlarge/download
Ongoing: Continuous Learning and Development
Performance Reviews:
Conduct regular performance reviews to provide feedback, set goals and discuss career development.
Learning Opportunities:
Encourage and support ongoing learning and development through conferences, workshops, online courses and mentorship programs.
Promote a Culture of Feedback:
Create an environment where feedback is given and received openly and constructively.
Additional Tips for a Successful Developer Onboarding
Clear Communication:
Ensure clear and open communication throughout the onboarding process.
Encourage questions and provide prompt answers.
Documentation:
Provide clear documentation on processes, coding standards and company-specific information.
Social Integration:
Organize team-building activities and social events to help new hires feel welcome and connected.
Feedback and Iteration:
Regularly seek feedback from new hires about the onboarding process and make improvements as needed.
Remember, the onboarding process is an ongoing journey, not just a one-time event. You must, therefore, continuously invest in your developers’ growth and development. It is the only way to create a positive and productive work environment where you can all thrive.
“You have a meeting to make a decision, not to decide on a question”.
Bill Gates
Meetings can easily become an onerous element of any leader. When they’re scheduled back-to-back, they a) consume more time than you thought they would and b) don’t solve a thing.
With this article, we want to ensure that, if a meeting is needed, you have the exact tools to make it productive, engaging and, finally, get the work done while the meeting is on.
The Key Learning Points
How to prevent cognitive overload and improve information retention.
Ensuring inclusiveness.
Creating an engaging environment.
Asynchronous work and the mindset needed for productive teamwork.
The Harvard Business Review found it’s too hard for humans to say no to a meeting invite. Some of the reasons are the now infamous FOMO and the false belief that everything is urgent.
Now, we all know that extroverts enjoy interaction while introverts would rather avoid meetings altogether. In both instances, however, the event can cause cognitive overload.
Preventing Cognitive Overload and Improving Retention of Information
It happens when a meeting triggers stress and anxiety. For example, a technical meeting that requires extra concentration from attendees.
The key here is to avoid overwhelming people with too much, too quickly.
Always remember that some people in the meeting don’t have a technical background so go easy with the tech jargon.
Never assume knowledge. Never make it harder than it needs to be for the people in the room. Instead, use metaphors and analogies to bridge that gap.
Next, be clear about the structure and agenda of the meeting so people know what to expect.
During the meeting, pay close attention to the speed at which you deliver points. In other words, give people the necessary time to digest and process information so they can better retain it.
And, whenever possible, deliver content with a hands-on activity because it improves learning and personal connections between the people.
Also, debrief during and at the end of every topic (and meeting) to ensure that everybody is a) engaged and b) understands. Ask open-ended questions like, “What particularly excites you from today’s meeting and is there something that worries you?”
What to do if an attendee zoned out?
Throw in a fun question to distract people or bring attention back.
Make them move.
Change the tempo.
Inclusiveness
Our brains register exclusion the same way they register physical pain. And without that sense of belonging, fear and anxiety kick in. Consequently, we shut down.
So, to increase inclusions in meetings, allow all participants an equal opportunity to participate and contribute.
But for that to happen, you must create a safe environment where everybody feels comfortable to speak and be heard.
There is, however, a slight problem with this. You see, what extroverts perceive as a safe environment, introverts may not.
Unlike extroverts, introverts need time to absorb information and reflect on questions. To tackle this, distribute the meeting agendas in advance.
Introverts also shy away from verbal processing and prefer to crystallise their thinking before vocalising it. In other words, they like a finished product.
And since they experience fatigue rather quickly, you should hold shorter meetings.
Creating an Engaging Environment
Use tools.
Run a creative sprint, different from daily stand-ups or retros.
“The longer the meeting, the less is accomplished”.
Tim Cook
Lately, a lot of workplaces are adopting asynchronous work. A good example is GitLab. According to them, the easiest way to enter into an asynchronous mindset is to ask this simple question:
How would I deliver this message, present this work or move this project forward right now if no one else on my team or in my company were awake?
If the answer is, “I must wake everybody up”, then it’s fair to call a meeting.
Maintaining a Productive Meeting
Leave as much as possible for asynchronous collaboration outside the meeting.
Assign duties at the end of it (if you fail to do it, the meeting is pointless).
Assign a supervisor (to track and report deliveries).
Follow up on items you didn’t cover and revisit each in the next meeting.
You don’t have to lead every meeting (remember inclusiveness).
In Module 1 of our Digital MBA for Technology Leaders (Leadership and Team Building), expert lecturers break down the meeting issues in detail and provide actionable solutions to each problem. We briefly went over a few of them here, but that was just the tip of the iceberg. For example, how to identify introverts/extroverts or how to assign specific tasks and to whom.
Remember, meetings are, effectively, problem-solving sessions, and it is imperative to understand every aspect of them to, ultimately, make them productive.
OK, we’re not talking about the criminal form of blackmail here – though that would be an interesting blog post. What we’re talking about is when a business becomes over-reliant on one or two key developers and they become aware of it, it can lead to a form of ‘developer blackmail‘ that makes managing team dynamics extremely difficult.
With deployment, methodology, programming style, UI colours and even the brand of coffee in the kitchen, they can take advantage of that reliance to become an overbearing voice of opinion.
Whilst they might be brilliant at programming and short-term solutions, that omnipresence can develop into a significant risk. It can negatively impact team functionality, harmony and psychological safety.
Early in my career, I started a project, hired a good developer and soon became reliant on him. I saw the danger emerging, so I tried to hedge against that risk by attempting to change their contract termination period.
No great surprise that when I wanted to make that change, I started receiving serious pushback and simply couldn’t move them. And they were very well aware of it.
My managerial inexperience allowed this situation to become toxic and impact many other areas of the business, not to mention the sleepless nights in working out how to find a resolution.
This issue is not limited to smaller teams only
I experienced a team of 30+ where every six months, two developers would ask for a pay rise that senior managers were afraid to refuse.
You might simply call it market forces at play, but when building a team, it creates significant discontent.
On a bigger team of 100, I saw one DBA wielding absolute power over the database and an architect who designed a ridiculously complicated framework that caused extra (completely unnecessary) work for the team whilst, at the same, time reduced productivity.
Another recipe for much unhappiness!!
Mentoring viewpoint
We saw this problem within our coaching assignments here at CTO Academy. Commonly, the root cause of issues today can be traced back to one or two individuals.
Let me just point out that not all individuals in these situations are intent on being malicious. However, too much knowledge in too few hands brings a clear risk to the business of abuse and/or flight.
Risk Mitigation – Steps and Best Practices
Let me address potential solutions in two ways.
First, how to reduce the risk?
Second, how do you prevent it from happening again or at all?
In an early business where I was the critical developer, we analysed the risk of what would happen if the proverbial bus ran me over (probably being driven by one of my business partners at the time!).
We highlighted what would need to happen in the first 24 hours, month and longer term.
Much as I’d like to think I’m irreplaceable, everyone ultimately is and, more importantly, absolutely needs to be “replaceable”.
Therefore, to isolate points of weakness, you must analyse these three areas:
(click to enlarge/download)
Knowledge. Is there knowledge in the developer’s head that no one else knows or would take them a long time to find and understand?
Productivity. Are they significantly more productive than other team members and thus would slow down the roadmap?
Deployment and Customer Facing. Are they the person who does the deployment and/or set up the customer-facing systems?
If you’re in the middle of this dilemma, then there is no magic bullet for an overnight solution. But there are steps you can take to start mitigating the risks.
Key steps in mitigating the risk associated with ‘developer blackmail’
Automate as much as possible. This has two effects:
Removes reliance on an individual’s knowledge.
Places the knowledge within the process and system.
Improve your important documentation. This should not be dry design documentation as no one ever reads it. Instead, focus on these three areas:
Disaster recovery plan. Put together a plan to recover from a disaster in your live systems. This could mean restoring a new installation in a new data centre and restoring backups.
Architectural Diagrams. High-level diagrams of how components interact allow someone to get up to speed very quickly.
Comment Code. No need to go overboard, but make sure there is adequate documentation on key algorithms. Code analysis tools can provide some feedback.
Implement code quality metrics. This will standardise the code and thus make it difficult to identify who authored what. Standard practice and layout make it much easier to understand code particularly when new to it.
Spread the load/responsibility across the team. If you have enough people, you may be surprised who steps up to the challenge. If there are not enough people, then look for the budget to hire people to double up starting with the high-risk areas first.
Additional proven practices in managing developers
Get Buy-In From Your Team
If you’re running an existing team, then the team should buy into these changes. It will make their lives easier and allow them to concentrate on the more “fun” stuff of actual development.
If members are opposed, then by natural attrition they will likely move on. Nonetheless, for those more entrenched, you may have to help them move.
Be aware that you may have to account for extra costs in the short term (eg, recruitment fees, a short-term loss of productivity and upheaval within the team).
To prevent this from happening:
A) ensure the implementation of quality processes right from the start, and
B) automate as much as possible (eg, code analysis and deployments).
This applies to all business sizes, from start-ups to international corporations.
Know What is Right for You and Your Team
Many people do not like change, so be prepared to stand up to your convictions and, ultimately, impose your authority.
I’ve had to replace entire teams on two occasions because they were so entrenched. Both times caused significant upheaval, but productivity increased and the respective companies were free to expand.
On other occasions, I have had to deal with more confrontational situations. Now, while compromise is important, if you know something is not right, then remain resolute and enforce what’s best for the business. In other words, don’t allow individuals to effectively try to blackmail the organisation.
Put steps in place to avoid over-reliance. On the other hand, if you find yourself inheriting this problem, apply a strategy for negotiating the roadblock. But be aware that it might not be easy. It could take many months to implement. However, once it’s done, the transformation could be remarkable and you’re more likely to have the backing of both your team and the wider business.
CTO Academy – Discounted Offer
Now, I won’t lie to you; this can all be pretty overwhelming. So if you’re struggling with this or any other managerial dilemma, then consider joining CTO Academy. As a member, you can tap into our wide range of leadership resources and global community of senior technology leaders at any time.
And just for reading this article, we are giving you 20% off of our annual Membership package subscription.
Find out more here and if/when ready to sign up, use the checkout coupon my20%reward to take advantage of that discount.
