Next MBA Cohort Starts Monday, July 6th, 2026

Review Pricing and Join the Cohort

CTO Academy Logo
Log In

Category: Case Studies

Learn from other technology leaders. Case Studies cover the operational level of day-to-day challenges CTOs and Heads of IT are facing. Each case study covers implemented strategies, specific challenges, the key questions and, of course, input from fellow tech leaders, members of our community.

  • When Technical Leadership Stopped Being Enough

    When Technical Leadership Stopped Being Enough

    From the outside, nothing was obviously wrong.

    The title, responsibility, years of experience…everything was there. On paper, this was already a successful technology leader: someone trusted to make decisions, lead teams, solve difficult problems, and carry the weight that comes with seniority. There was no dramatic failure, no public collapse of confidence, no single moment where everything stopped making sense.

    But somewhere along the way, the role had changed.

    Or maybe it is more accurate to say that the role had expanded. What once felt primarily technical had become something broader, heavier, and less easy to define. The conversations were no longer just about architecture, delivery, tooling, or performance. More and more, they were about trade-offs. About influence, business value…priorities that were not purely technical, but still landed in technology leadership’s hands. About speaking to executives, product leaders, boards, peers, and stakeholders who were not interested in the technical elegance of a solution unless it could be translated into impact.

    That was the point at which a quiet discomfort began to set in for many of the graduates of CTO Academy’s Digital MBA for Technology Leaders. Not because they were failing. Quite the opposite. They were already doing the job. But the next level of leadership was beginning to demand something more than technical judgment alone, and they could feel it.

    “It’s rarely about tech.”
    Bianca Glasner, Head of Engineering, Austria

    Again and again, in the graduate reflections, what emerges is not a story of deficiency but a story of range: a growing awareness that technical competence, on its own, was no longer enough for the kind of leader they wanted to become.

    Bianca Glasner, a Head of Engineering and Firmware Lead from Austria, captures that tension in one line that stayed with her: “It’s rarely about tech.” What caught her attention was that the program did not treat technology leadership as pure engineering or as generic leadership training, but as a whole role with many interlocking parts. It reinforces what Manasa Kotha, an Engineering Manager from the US, said, “The program teaches you what leaders are supposed to do in certain situations and how to facilitate or help others in reaching their own potential while you discover yourself.”

    That matters, because by the time someone becomes a CTO, a Head of Engineering, or a senior technology leader on the path toward those roles, the challenge is rarely a lack of knowledge in the narrow sense. More often, it is that the job has outgrown the boundaries of their earlier training. Nobody teaches you, at the start of a technical career, how to think across the full shape of the role later on. Nobody sits you down and explains how to move from being the person with answers in one domain to being the person who has to hold ambiguity across many. Nobody really tells you how much leadership at that level is about reading context, shaping conversations, creating clarity, helping others perform better, and making decisions that are as much human and commercial as they are technical.

    So the tension does not announce itself loudly. It shows up more quietly than that.

    It shows up in meetings where you realize you understand the technical dimension perfectly well, but wish you had a stronger grasp of the business conversation unfolding around it. It shows up in moments when you know what should happen, but feel you could be more effective in how you frame it to executives or non-technical peers. It shows up in the distance between being a strong operational leader and becoming a more complete strategic one. It shows up when the next stage of your career begins to depend less on how well you can solve technical problems yourself and more on how well you can guide a business through them.

    For graduates, that was often the real reason for enrolling. Not to gather another certificate. Not to decorate a CV. And definitely not to pursue ambition for its own sake. They enrolled because something had become impossible to ignore: staying the same, even while remaining competent, no longer felt enough.

    Byron Rode, a CTO from South Africa, describes the effect of the program in a way that reveals the problem it solved. He says he likely would have reached the same endpoint eventually, even without the course, but it would have taken much longer, with more failure and error along the way. The Digital MBA helped him get where he is in his career faster, especially in areas where he had historically struggled: delegation, cross-departmental work, and the crucial skill of speaking non-tech to non-technical people.

    That idea of acceleration is important. It suggests that the program did not give people an entirely new personality or hand them a transformation they had not earned. It did something more credible than that. It shortened the distance between the leader they were becoming and the leader they needed to be.

    The question, then, was why this route, and not another one.

    Because there were other routes. There are always other routes. Traditional MBAs, short leadership courses, scattered books, podcasts, online classes, frameworks picked up over time, advice from peers, trial and error inside the role itself. Senior technology leaders are not short of information. What they are often short of is something else: a learning environment that feels genuinely designed for the complexity of their work.

    That is one of the clearest themes in the graduate reflections. The appeal of CTO Academy was not simply that it offered content. It was that it seemed to understand the reality of the person consuming it.

    “It is crafted for working professionals, blending business with technology.”
    Matthew Miller, IT Manager, Canada

    Matthew Miller, an IT Manager from Canada, points first to the structure of the program: a curriculum crafted for working professionals, blending business with technology, flexible across time zones, and built around community.

    Others talk about lectures that are easily digestible rather than overwhelming, practical modules that reflect real life, and the ability to apply what they are learning directly in their day-to-day roles. Rather than abstract leadership talk, the course seemed to offer something more grounded: insight that could be used immediately, then revisited later as needed.

    That distinction matters more than it first appears to. At this level of leadership, it is not enough for learning to be interesting. It has to be usable. It has to survive contact with a calendar already filled by other people. And more importantly, it has to fit around a job that does not pause politely so personal development can happen in isolation. The graduates frequently mention bite-sized, 100% online lectures that can be taken between meetings or during lunch, not because convenience is the whole story, but because practicality is inseparable from credibility. Senior leaders do not need to be persuaded that learning is good. They need to believe that the learning will fit inside real life rather than asking them to step outside it. Even the humor in Kasey McCurdy’s remark points to that sense of genuine engagement: “I always hated when those pesky meetings got in the way of me joining a CTO Academy expert session.”

    But convenience alone does not create meaning. What gave the experience its weight was what began happening once the course was underway.

    This is where the story becomes more interesting, because the shift described by graduates was not immediate and not theatrical. It did not sound like a single revelation. It sounded like a series of internal adjustments that, over time, became impossible to miss.

    At first, the program seems to have given people language for things they were already doing instinctively, without always knowing how to name them. Kevin Golding, a UK-based Field Technologist, describes that dynamic with unusual clarity, “As a leader,” he says, “You are often doing things without fully knowing that you are doing them, or without understanding why you are doing them at all. The course helped put those actions in perspective: what to do, when to do it, why it matters, and what else should be added to the plan to make leadership more effective.”

    There is a deep relief in that kind of recognition. Not because it flatters the leader, but because it turns instinct into awareness. It takes things that were half-formed and makes them more deliberate.

    Then something broader begins to happen. The role itself starts to look different.

    Leadership stops feeling like a string of urgent reactions and starts coming into focus as a system. Decisions are no longer just about immediate execution but about what kind of organization you are shaping, what kind of conversations you are enabling, what signals you are sending, what habits you are reinforcing, and how technology actually participates in the direction of the business. A module here sharpens one area. Another challenges an assumption. Another expands the frame. Gradually, a fuller picture forms.

    The most interesting part of the graduate reflections is that they do not merely talk about learning topics. They talk about becoming different in how they reason. That is subtler, and more powerful. They describe changes in how they speak to executives, how they work across departments, how they delegate, how they understand their own value, how they approach leadership dilemmas, and how they carry themselves in more senior spaces. This is not the language of “I picked up a few useful tools.” It is the language of identity slowly reorganizing itself around a larger role.

    “The course helped me recognize further value in what I do and what I bring to the table.”
    Stephen Morris, Fractional CTO, UK

    Stephen Morris, a Fractional CTO based in the UK, puts it beautifully. The course, he says, helped him recognize further value in what he brings to the table, while also allowing him to identify his weak areas. More than that, it gave him the perspective of a whole role that nobody had told him about at the beginning. That matters because once you understand the whole shape of a role, you stop feeling like you have wandered into spaces you do not belong in. You start to feel, in his words, more confident as a board member or aspiring board member, because now you know the answers. And even if you knew them before, you are more able to recognize your own value and be trusted in that recognition.

    That is not a small change. It is one of the hardest things to acquire in leadership: not just skill, but self-possession. Not just the ability to do the work, but the internal authority to stand in rooms that once felt slightly beyond reach and know that you belong there.

    Kasey McCurdy, Head of Engineering in the US, describes another side of that development. The course changed the way he spoke to product teams and to the executives he reported to. It helped him take on more of the executive functions and really own them.

    That phrase is worth lingering on: really own them. Not imitate them, not observe them from the outside, not perform them uncertainly, but own them. Because there is a difference between being adjacent to executive responsibility and feeling capable of inhabiting it fully.

    This is the real middle of the story. Not the modules themselves, but the accumulation of internal upgrades they triggered.

    A broader lens.
    A clearer vocabulary.
    Better judgment.
    More confidence in ambiguity.
    A stronger ability to translate.
    A more natural executive posture.
    A less fragmented understanding of what the role asks of you.

    And all of this happened while the leaders were still inside their jobs, still facing their normal pressures, still carrying the same responsibilities. Which may be why the learning seems to have landed so deeply. It was not taking place in an abstract future. It was colliding, week by week, with the real situations these people already had to navigate.

    Running alongside this intellectual and professional change was something else that graduates repeatedly return to: community.

    “It’s more than just a great course. It’s also about being a part of a network.”
    Byron Rode, CTO, South Africa

    This might sound secondary from the outside, but in the graduate reflections, it clearly is not. Again and again, what emerges is how isolating senior leadership can feel, and how meaningful it is to find a network that understands the role from the inside.

    Byron Rode says that, as a CTO, you rely on a network or community, especially if you are outside your usual realm, as in the case of an accidental CTO. Stephen Morris describes the community as a different type of support network: a place where you can reach out with specific technical questions or with leadership challenges, and where the people around you understand the peculiar difficulties of what you do. Matt Miller emphasizes that the curriculum itself is built around and for the community. And Kasey McCurdy perhaps captures the emotional truth of it most directly: when he faces a dilemma, he knows there are others in the world dealing with the same thing, and many of them are part of this community — some going through it now, others already through to the other side and eager to help.

    That completely changes the feel of the experience. It means the leader is not just studying alone. They are being accompanied. Their questions are not signs of weakness but part of a shared professional reality. Their dilemmas are not private failures but familiar patterns others can recognize and help untangle — whether that is working through a board-level disagreement, or finding a way to move a legacy team past resistance to change. For people in senior roles, that kind of support is not ornamental. It is often the difference between learning something intellectually and having the confidence to live it out.

    By the end of the experience, the outcomes graduates describe are striking precisely because they are not exaggerated.

    They do not read like miracle stories. They read like something more convincing: a noticeable shift in pace, confidence, and scope.

    For some, the main difference was speed. They arrived at stronger decisions faster, with less wasted motion. For others, the biggest change was language — being able to speak more effectively to product leaders, executives, boards, and non-technical stakeholders. For others still, the shift was more personal: recognizing their value more clearly, understanding where they were weak without shame, and feeling more grounded in the full role they were stepping into.

    Across the reflections, the pattern is consistent. These leaders did not emerge as entirely different people. They emerged as more complete versions of themselves: faster where they had been hesitant, broader where they had been narrowed, more confident where they had once felt slightly unsteady, more able to translate, align, influence, and lead across the business rather than only within technology.

    That is why this story lands where it does.

    Not in the territory of obvious reinvention, and not in the flat language of professional development. It lands somewhere truer than that. In the recognition that there comes a point in a leadership career when experience alone is no longer enough to unlock the next stage. When what is needed is not more hustle, not more technical depth, not another handful of fragmented ideas, but a more coherent way of seeing the role. A more integrated kind of growth. A structure for becoming the leader the job has already started asking you to be.

    For the graduates, that appears to be what the program provided. Not an escape from the work, but a better way to meet it. Not a dramatic identity transplant, but a steady strengthening of judgment, confidence, and range. Not a promise that everything would change overnight, but something perhaps more valuable than that: the feeling that they were no longer trying to grow into the next version of themselves by instinct alone.

    And perhaps that is the most persuasive thing in all of this. These were not people looking to become someone else. They were already accomplished. Already trusted. Already carrying real weight.

    They simply reached the point where technical leadership, on its own, was no longer enough.

    And they decided to grow into the full shape of the role.

    Hear the stories in their own words.

  • Year In a Worklife of a Scale-up Chief Technology Officer

    Year In a Worklife of a Scale-up Chief Technology Officer

    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.
  • Enhancing Collaboration with a Principal Engineer at TechGlobal

    Enhancing Collaboration with a Principal Engineer at TechGlobal

    An Engineering Manager (EM) at TechGlobal Ltd seeks advice on improving the working relationship with a Principal Engineer (PE) who, despite having extensive experience and a strong principled approach, poses challenges in team interactions and project progress.

    The PE’s direct and often critical communication style has led to a division among team members, impacting their willingness to engage and collaborate effectively.

    This case study delves into the complexities of integrating a high-level strategic vision with practical implementation steps in a technology-focused environment.

    I think on the topic of perception, what I have seen over many years leading teams is that perception becomes reality, so leaving a person on a team that makes others “afraid” to participate unintentionally says it’s OK.

    Dallas G.

    Context and Challenges

    • The PE brings a wealth of experience from a major tech company, holding strong and principled views on engineering practices.
    • Described as loud and curt, the PE’s approach in technical reviews and meetings has created discomfort among team members, leading to avoidance or unnecessary adjustments in project scopes.
    • The PE often critiques current architectures and proposes advanced future state architectures, but lacks intermediate steps and practical guidance to achieve these visions, leaving a gap in execution plans.

    Specific Incidents

    • Some engineers avoid presenting their work if the PE is involved, while others over-engineer solutions to preempt potential critiques.
    • A specific instance involved a junior engineer documenting the use of cloud-native tools, where both the junior engineer’s and the PE’s proposals lacked practical details and actionable steps, reflecting a disconnect in expectations and execution.

    Discussion Points

    • How can the EM facilitate a shift in the PE’s approach to offer more constructive, actionable feedback without dampening the valuable critical perspective?
    • What strategies can be implemented to improve the communication style of the PE to enhance collaboration and reduce team division?
    • How can the EM work with the PE to develop clear, actionable transition plans that bridge the current state to the desired future state architecture?
    • Considering the belief that teams need replicable patterns to succeed, what frameworks or methodologies can be introduced to support this need?

    We invite you to share your insights and experiences on navigating similar challenges within your organisations.

    How have you managed to align senior leaders with practical team dynamics?

    What approaches have you found effective in balancing visionary technical leadership with actionable team guidance?

    Peer Advice (Actionable Solutions from our CTO Community)

    Vigi J.

    If I were the EM I would provide feedback immediately after the meeting to reference the specific scenarios as they are fresh in people’s minds. If the PE is open to such feedback I think they would use the opportunity to grow. It’s also best to follow up verbal feedback with written feedback as well and make sure the hiring manager is aware of the situation. If the PE does not receive the feedback well perhaps a conversation with the hiring manager is needed. If the PE does not receive the feedback well you should follow up with a hiring manager conversation. I’ve been in the beer buddies situation before and it’s hard. In my case I continued to give honest and straightforward feedback and eventually the beer buddy was replaced. 

    Catherine

    I’m going to be potentially a bit controversial here and say this sounds like a people problem that in my experience is hard to resolve with a process or strategy. Hence the outcomes (dismissal) described.

    People problems are inherently contextual and relational, but I’d recommend the line manager open conversation with the PE to understand how they see their role, how they see it needing to be executed, how confident they are in discharging their role, etc. I’d also set out (as line manager) clear expectations on not just what they do, but how they do it.

    It’s important to be both open but also clear and factual in this case, and not editorialize, but provide reasonable support to the PE. I don’t believe in just dropping them into soft skills training – they need to understand and appreciate the problem, and their contribution to it.

    If that doesn’t work then performance management steps are appropriate. But I’ve had very good results with a coaching approach if it’s done early and nipped in the bud.

    Seetharam S.

    I have served as a Principal Engineer/Architect for many years, leading teams in both startup and large corporate environments. My success has stemmed from building trust and effectively communicating my ideas. When faced with disagreements, rather than imposing my views, I encouraged the team to develop a proof of concept before progressing to a comprehensive solution. This approach allowed the team to encounter and address challenges early on, with my guidance.

    The primary challenges I encountered were from upper management who sometimes perceived me as a threat rather than a collaborator. However, the support from my immediate supervisors, primarily Senior Vice Presidents, was instrumental. Their faith in my abilities and experience was crucial, as they advocated for me among their peers.

    Paul W.

    I’ve seen this kind of thing happen a few times.  One particularly memorable case was after a change of CTO.  One particularly senior engineer ( essentially a PE) used this as an opportunity to quite publicly attack the credibility of several engineers. This same individual had a history of aloofness, over engineering, slow delivery and being generally ‘superior’.  He was indeed a very good technical guy but would ignore business realities in favour of technical perfection then critique others who were forced to make trade-offs in order to deliver.  It backfired horribly, with the new CTO immediately identifying the guy as toxic and dismissing him virtually on the spot.  This really made the rest of the team feel protected and valued ( and sent a clear message re toxic team behaviors).   I think people like this are extremely difficult to change, and can be incredibly bad for team health.  If they don’t show immediate change after mentoring, performance plan etc.. then I know what I’d be doing :point_up: ( of course it will depend of the severity  and context of the problem also )

    One response to “Enhancing Collaboration with a Principal Engineer at TechGlobal”

    1. Holger Hammel

      Given it is not a clear case of a “brilliant jerk”, that has been covered already in the comments – it is basically a coaching topic. The step from senior to Staff/PrincipalArchitect usually implies a significant shift in role expectations – is this clear to the person? Is it stated in a role/level description and properly discussed and reviewed in 1:1s?
      Imho it helps to find out together where the ineffective behavior comes from? Is it that they are feeling like an imposter, defensive, overwhelmed? Or rather bored by the same problems, same questions, mistakes, arrogance of more junior engineers or managers for decade(s)?
      Different coaching strategies can be developed based on this self-reflection by the PE and 1:1s or 360s.
      A few tools I have used or seen working include: 1) re-framing it as a problem to solve – not a character flaw or soft skill to get better at – here is the problem: we shall lift the quality, flow, avoid risk: how do you do that w/o you doing it?
      2) Succession planning: for managers it is more common to make succession planning an explicit part of someone’s goals. Apply the same to senior technical leads and ask them to identify, support, coach and make sure that the next generation of principal engineers is growing (and seniors ..)
      3) Write things down – it is OK to be opinionated and define guardrails, standards for many aspects, but then write them down and be accountable; help PEs to do so in an inclusive, open way

  • The Metric Mirage at AgileX Solutions

    The Metric Mirage at AgileX Solutions

    AgileX Solutions, a leading Software as a Service (SaaS) company, is celebrated for its adoption of agile methodologies. However, the company encounters a significant challenge when its non-technical Chief Executive Officer (CEO) mandates the use of quantitative metrics to gauge the engineering team’s performance.

    This requirement starkly contrasts with the perspective of the Head of Engineering (HoE), who advocates for a more nuanced, holistic evaluation approach.

    The CEO’s insistence on employing analytical tools such as Jellyfish to monitor various metrics—including velocity, burn-down charts, lines of code and commit frequency—sets the stage for a critical exploration of the drawbacks associated with over-reliance on superficial or “vanity” metrics.

    This case study delves into the imperative of integrating quantitative data with qualitative insights to foster a balanced assessment framework.

    Key thing to understand is that with this kind of request, the CEO isn’t actually wanting insight into each individual’s or team’s performance to optimize or clean house, rather it’s an indicator that he doesn’t fully trust YOU

    Ken K.

    Key Issues at a Glance

    • Vanity Metrics vs. Value Delivery: The challenge lies in quantifying what truly constitutes a meaningful contribution.
    • Leadership Misalignment: A noticeable rift between the CEO’s quantitative demands and the HoE’s qualitative vision raises concerns.
    • Team Morale: The implementation of quantitative tracking mechanisms potentially jeopardises the engineering team’s spirit.
    • Protecting Team Integrity: The HoE faces the daunting task of safeguarding the team against practices that could be detrimental to their cohesion and productivity.

    Engagement Questions

    • Balancing Metrics: In the quest for a balanced assessment approach, how would you reconcile the need for quantitative metrics with the intrinsic value of qualitative insights?
    • Leadership Alignment: What strategies could facilitate the alignment of non-technical leadership with the tangible realities of engineering work?
    • Team Morale: Facing the introduction of potentially intrusive metrics, what measures can be taken to preserve team morale and culture?
    • Holistic Measurement: Propose a metric or practice that effectively encapsulates the genuine value delivered by the engineering team.

    Further Engagement

    • An invitation to participate in a “Metrics vs. Morale” virtual roundtable, aimed at debating the relative merits of quantitative versus qualitative metrics within agile frameworks. This forum is intended as a venue for sharing experiences and strategies.
    • The insights garnered from this case study will be further discussed in our upcoming Peer to Peer session. This presents an excellent opportunity to continue our dialogue, delve deeper into the issues at hand, and collaboratively explore potential solutions.

    Your Thoughts

    As fellow CTOs and engineering leaders, share your experiences and tips in the comments. Let’s collaborate to create a roadmap for effective leadership in the dynamic environment of a start-up. Your expertise could be the guiding light for many others in similar situations.

    Peer Advice (Actionable Solutions from our CTO Community)

    Ken K.

    My take on this situation (and I’ve definitely been in this position before):

    One of the key things to understand is that with this kind of request, the CEO isn’t actually wanting insight into each individual’s or team’s performance to optimize or clean house, rather it’s an indicator that he doesn’t fully trust YOU and how you’re leading, what you’re accomplishing with the department.

    Now this isn’t to say you’ve done or are doing anything wrong, either in-fact (what you’re accomplishing) or in trust from the CEO not being strong.  But it is pointing out there’s some gap in their ability to trust you’re driving great value from what you’ve got.

    Some CEOs need more data and detail than others, and perhaps that is the reason.  Often as leaders, even technology ones, we maneuver our teams, deliveries, and departments partially via intuition and finesse, and not precise algorithms or outcomes.  Some fantastic CEOs I’ve worked with are good with that, trusting me as the leader to keep them informed about how things are impacting the business.

    Other CEOs it’s not that they love data and detail, they’re just subconsciously (or consciously) feeling the need to get involved, control, and take charge.  So this speaks to helping build his trust in you, the leader.

    Now what I do in these kind of situations is to definitely put in place a series of metrics to regularly talk through with the CEO.  I’ll talk about what twist I put on it in a second, but just tracking and putting together metrics actually helps you as well, even if you don’t feel you need them.  “If you want to improve a thing, track that thing”  “The spotlight of awareness tends to make aligning to goals happen naturally on its own”  :slightly_smiling_face:

    Okay, but to metrics.  The fundamental twist or distinction I make here is to have the metrics as a whole be about MY OWN success or failure, as a leader, at accomplishing my strategy and targets (which encompasses the teams and individuals).  Yes this can feel a bit vulnerable and make you anxious, but IMO it’s the best way forward.

    • you subtly change the CEOs frame from focusing on the teams’ output to your leadership effectiveness
    • you build more and more trust with the CEO about you as a leader, so they need or want the metrics less and less.

    What does this mean?

    • It means having a solid clear technology strategy written down and understood by the SLT and CEO.  (you do have one of those, right? :stuck_out_tongue_winking_eye: )
    • it means, yes potentially, folding team metrics in such as cycle-time, even velocity and burn-downs, but lean heavily into couching that data about YOU, not the team.  Why are you making the choices YOU are making, with the detail and insight YOU have about the teams and their delivery?
    • it means using tactics such as milestone-orientation — coaching teams towards MVP milestone goals with lots of room for scope negotiation as timelines loom, yet still achieve (and claim) success.
    • it means even for tech debt areas, having a business case up front about what ROI the time/$ would bring, and tracking afterwards if that actualized

    just my rambling $0.02, but take Responsibility, take Ownership of the ask, the trust building, and opening up to show not just what decisions you’re making, but how and why you make them.  

  • CEO-CTO Chasm at InnovativeTech

    CEO-CTO Chasm at InnovativeTech

    TL;DR: At InnovateTech, a fintech startup aiming to disrupt the digital payments industry, a significant rift forms between CEO Alexandra James, who advocates for rapid market capture with new features, and CTO Marcus Lee, who prioritises sustainable, secure growth. This clash comes to a head during a board meeting where the CEO’s aggressive strategy is approved, leaving the CTO to reconcile this with the technical team’s capabilities. Resulting issues include growing technical debt, team burnout and turnover, and a severe security breach due to rushed development. This case study spotlights the need for harmonising business drive and technical stability, managing technical debt, fostering team resilience and responding effectively to crises. It invites readers to contribute ideas for better CEO-CTO alignment and ends as a parable warning of the dangers of strategic misalignment in tech companies.

    Introduction

    InnovateTech, a burgeoning fintech startup, is on the cusp of revolutionising the digital payments space. At its helm are CEO Alexandra James and CTO Marcus Lee, both visionaries in their own right but divided by fundamentally different perspectives on the company’s trajectory.

    The Scenario

    Alexandra, with her keen business acumen, is pushing for rapid expansion and the introduction of groundbreaking features to outpace competitors. Her mantra, “Speed is the new currency in tech,” reflects her urgency to capture market share.

    Marcus, on the other hand, is cautious. His focus is on building a scalable and secure platform that can handle the anticipated transaction volumes without hitches. His approach is methodical, emphasising the importance of technical debt management and a robust architecture to support future growth sustainably.

    The Conflict

    Tensions arise during a pivotal board meeting where Alexandra unveils her aggressive growth strategy, including an ambitious product launch timeline. Marcus, concerned about the technical team’s current bandwidth and the accumulating technical debt, voices his apprehensions, suggesting a more phased approach to development and scaling.

    The board, swayed by Alexandra’s compelling pitch, green-lights the expansion plan, leaving Marcus with the daunting task of aligning his team’s efforts with the accelerated timelines, without compromising on the technical integrity of the platform.

    The Complications

    As development progresses, the tech team encounters significant hurdles:

    • Technical Debt Accumulation: In their rush to deliver, the team shortcuts some of the best practices in coding and testing, leading to a pile-up of technical debt.
    • Burnout and Turnover: The pressure to meet deadlines leads to team burnout, with key members leaving, further exacerbating the delivery challenges.
    • Security Concerns: In an oversight during a sprint to introduce a new payment feature, a critical security vulnerability is introduced, putting user data at risk.

    The Climax

    A major security breach occurs, exploiting the overlooked vulnerability. The incident leads to a temporary shutdown of services, eroding customer trust and inviting scrutiny from regulators. The fallout forces Alexandra and Marcus to reckon with the consequences of their misaligned strategies.

    Discussion Points

    Strategies for Aligning Business and Technical Objectives

    How can CEOs and CTOs better synchronise their visions to support both innovation and operational stability?

    Managing Technical Debt

    What frameworks or practices could InnovateTech adapt to balance the pace of development with the need to manage technical debt effectively? 

    Building Resilient Teams

    How can start-ups like InnovateTech prevent burnout and retain talent, especially when navigating high-stress periods of growth and scaling? 

    Crisis Management

    In the wake of a security breach, what steps should a tech leader take to mitigate the damage, restore trust, and prevent future incidents?

    Conclusion

    The tale of InnovateTech serves as a cautionary story about the pitfalls of misalignment between a company’s technological capabilities and its business ambitions. By sharing and discussing this case study, we hope to illuminate the path towards more cohesive and successful partnerships between CEOs and CTOs in the tech industry.

    Invitation for Solutions

    You are invited to offer your insights, experiences, and suggestions for tackling the challenges faced by InnovateTech. 

    One response to “CEO-CTO Chasm at InnovativeTech”

    1. Mats Oberg

      Strategic alignment should have happened outside the boardroom. Probably with a pre-mortem. The the CEO could have presented to the board what the business benefits were, and how and why things may go wrong with the proposed strategy.
      Now it retrospect it seems like the chosen strategy was wrong headed, but was the security vulnerability really a result of moving fast? An oversight can happen during any sprint.

  • Balancing Team Support and Executive Pressure

    Balancing Team Support and Executive Pressure

    In the dynamic realm of a tech start-up known for its innovative products, Mia, an Engineering Manager, shines as a pillar of support. She’s led her team through several successful product launches, earning praise for their creativity and dedication. However, a challenge from senior management casts a shadow over these achievements.

    The team’s hard work is starting to take its toll, not due to Mia’s leadership but from the VP of Engineering’s intense pressure for continuous success, which is silently wearing the team down.

    The Breaking Point

    Mia notices signs of burnout among her team members:

    • Lowered engagement 
    • Declining quality
    • Rising absenteeism

    Unfortunately, despite her efforts to advocate for her team, the VP’s high expectations remain unchanged.

    Consequences of Disconnected Leadership

    The continuous push for excellence has led to a decline in product quality, customer satisfaction and team morale, with Mia’s protective efforts overshadowed by the VP’s demands.

    The Crucial Realisation

    A turning point occurs when a key team member resigns due to unsustainable work conditions, prompting Mia to address the situation directly with the VP, highlighting the risk to the team’s well-being and the company’s reputation.

    The Key Question

    How can Mia effectively convey the seriousness of the situation to the VP and champion her team’s health without compromising the company’s ambitious targets?

    Seeking Your Guidance

    As leaders who have faced similar challenges, what advice would you offer Mia? What strategies can help maintain team morale while achieving the company’s goals?

    Join the Dialogue

    We value your insights and experiences in navigating the complex dynamics of leadership under executive pressure. Share your thoughts on building a supportive environment that balances team well-being with corporate objectives. Engage in the conversation below and help craft a blueprint for compassionate, effective leadership.

    2 responses to “Balancing Team Support and Executive Pressure”

    1. Mats Oberg

      First Mia need to ask herself “what is my contribution to the problem?” “Am I giving the team the resources they need, am I helping them prioritize their work, do they need to do everything they are doing?” Asking the VP for help solving the issue. If a key member leaves due to unsustainable working conditions, the VP may realize that there is a problem. The ask for help cannot just be help. By having pondered the questions above, as well as other related questions, the manager may be asking for help in a really specific way. E.g. “my team has been providing training to our internal teams monthly. All these training sessions have been recorded, maybe we can take a break in providing live training and let them view the recordings. I know it is suboptimal as they can’t ask questions, but given the current workload, we need to stop doing something. I think it would be helpful if we could hire a short term contractor to handle weekly collection of …. What do you think?”

    2. Nilesh Jagdale

      Mia, facing pressure to meet ambitious targets while maintaining her team’s well-being, should gather data on productivity, quality, and absenteeism to illustrate the team’s state. She should frame these issues in business terms, highlighting impacts on customer satisfaction and the risk of losing key talent.

      Proposing solutions like adjusted deadlines, optimized processes, and initiatives supporting team well-being is crucial. Building alliances with other leaders who share concerns can strengthen her case.

      During discussions with the VP, Mia should use constructive communication, focusing on collaborative solutions and actively listening to the VP’s perspective. Piloting new approaches on a smaller scale can demonstrate their effectiveness, while continuous monitoring and adjustment based on team feedback will ensure sustainable improvements.

      By balancing these efforts, Mia can effectively advocate for her team’s health without compromising the company’s ambitious goals in the dynamic tech startup environment.

  • Aligning the Sense of Urgency Among Diverse Tech Teams

    Aligning the Sense of Urgency Among Diverse Tech Teams

    In a fast-growing technology company, the engineering, product and platform teams exhibit significantly different senses of urgency regarding project delivery and innovation. This misalignment leads to:

    • Delays
    • Frustration
    • Communication breakdown
    • Inefficient workflows
    • Concerns over losing a competitive edge due to missed innovation opportunities

    “On innovation – I find teams struggle to innovate if they don’t feel ownership”.

    Keith P.

    Previous Attempts to Solve the Situation

    • Cross-functional meetings to improve communication. 
    • Unified project management tool for increased visibility. 
    • Company-wide OKRs to align team goals.

    New Objective

    Explore strategies to align the sense of urgency among teams, enhancing collaboration, efficiency and innovation.

    The goal is a cohesive approach that balances quality, speed and stability.

    Discussion Points

    1. Strategies for addressing root causes of misalignment among tech teams.
    2. Effective communication practices for a shared sense of urgency.
    3. Balancing diverse priorities without compromising on quality, speed, or stability.
    4. Successful case examples or experiences.

    Let’s Discuss!

    Share your insights, strategies and experiences to help navigate this challenge and achieve team alignment for success in a competitive landscape.

    Peer Advice (from our CTO Community)

    Keith P, Head of Product Engineering

    I would question the current shape of the teams. With separate engineering, product and platform, there is (in my opinion) going to be an additional overhead in maintaining/aligning vision and purpose.

    If possible, I’d look to transform the teams into cross-functional pods, consisting of product, engineering and platform, and ensure they have a true sense of ownership – a one-team approach. 

    If this is not possible, I’d look to have advocates – bring a product person into engineering ceremonies (refinement, stand-ups, retros etc.) and vice versa.

    Also, as a team or team of teams, agree on what getting done requires and achieves. 

    On innovation – I find teams struggle to innovate if they don’t feel ownership.

  • Senior Engineer Struggling to Meet Expectations

    Senior Engineer Struggling to Meet Expectations

    The CTO of a start-up is facing a challenge with a Senior Engineer who, despite a promising start and strong technical skills, is delivering work far slower than expected. This situation has arisen after replacing a previous bad hire and deciding how to “delicately” proceed.

    Team Composition

    There are three team members: a Junior, a QA and the Senior Engineer. The start-up is at a seed stage, emphasising the critical role of each team member.

    “The skills and experience that made him a senior might not include being able to rapidly navigate your codebase/architecture/domain combination”.

    Glenn P.

    Performance Concerns

    Issues ranged from environment setup difficulties to absence on critical delivery days. A crucial ticket is now delayed, prompting a meeting to discuss performance and expectations.

    The Key Questions

    How would you address the performance issue without demoralising the team or the individual?

    What are possible ways to avoid similar hiring challenges in the future, considering the reluctance of senior candidates to engage in extensive interview processes?

    Your Thoughts

    Your insights and experiences could greatly assist in navigating this complex situation. Share your thoughts and advice in the comments below!

    This case study reflects the nuanced challenges of start-up leadership, especially in balancing team dynamics, individual performance and company culture.

    Peer Advice (from our CTO Community)

    Jamaica F.

    Interesting question, having been the “slow guy”, a couple of thoughts…

    Before jumping to conclusions or doing anything drastic, in my opinion, it’s critical to understand what’s going on on his end. Is this a bad fit or has there just been miscommunication on expectations?

    In no particular order:

    • How exactly has he been spending his time? Is he trying to really learn how things work in a new system with new tools? Refactoring and writing tests? If so how much? Is there too much context-switching?
    • What is his philosophy on tech debt?
    • What does he think his fundamental role is: to standardize processes and model good practices to JR dev or to just GSD?
    • Are expectations around delivery timelines totally clear to him?
    • As the new guy, where it sounds like others are starting to look up to him, does he feel safe potentially breaking things? (or shipping suboptimal solutions?)
    • As the only senior with you very busy with other things, does he have the support he needs? Does he feel comfortable bouncing ideas off of you, etc. or does he feel like he needs to do as much as he possibly can on his own (impacting delivery time)?

    Glenn P.

    I’d suggest here that 6 weeks in is a good time to have the intervention and do a deep-dive into what is preventing good performance.

    The skills and experience that made him a senior might not include being able to rapidly navigate your codebase/architecture/domain combination.

    From what’s been said – there’s lots to like about this individual. However, by the end of February, you need to identify if they were just a great interviewee or just a steady-starter.

    It’s right to consider the impact on the team, but in my experience, letting a bad hire go is better for the overall team mood from the day after letting them go.


    Ravi B.

    There was a discussion about personality types (DiSC or Culture Index etc).

    Some people are slow to start and need all the details before they get going. They want to do everything perfectly by evaluating all possible options.

    On the other side, you have people that jump into fire with very limited info.

    It appears to me that you have a personality mismatch for the size of your company.

    Tuomo T.

    I’ve had a somewhat similar situation with a senior hire. They were delivering much slower than expected. I talked with them and asked what exactly was taking so long.

    Found out that, indeed, it was mostly figuring out the architecture and how things are done and related etc.

    Now they’ve been doing a task where domain knowledge is not needed and they are delivering a lot faster.

    Depends on the product, but I think 6 weeks may not be enough to learn the code base and get very productive. I think the key is to find out why they are slow and what exactly are they spending their time on. Then find out if they can do anything in a reasonable time. If not, then it’s probably best to let them go sooner rather than later.

    Jayson W.

    Great points, Ravi. I share the same sentiment. On the surface, it sounds like there were some personality disconnects and or miscommunication expectations.

    Given this person’s background, it sounds to me like an architect which may make sense as to why he/she did well with the communicative things in the beginning but may have either not realized they were going to write code or gotten bogged down with the big picture thinking.

    Reply from Ravi:

    Yeah. As part of hiring we make everyone take the personality test from Culture Index. This gives us an insight into what to expect and helps us with the right expectations on their bias for action, how social/influential they are etc.

  • Addressing Leadership Challenges in Cross-Departmental Collaboration

    Addressing Leadership Challenges in Cross-Departmental Collaboration

    An organisation has embarked on a new journey, setting cross-departmental objectives that necessitate seamless collaboration among the subteam leaders from different departments. A team lead, Anisha and her PM counterpart, Gabriella, are at the forefront of this challenge. 

    Historically, their collaborations have been fraught with difficulties, stemming from their divergent leadership styles, values and interpretations of the organisation’s needs. This issue isn’t isolated to Anisha and Gabriella alone; it mirrors similar conflicts and competitive tensions among other team leads from these departments.

    Faced with the task of jointly charting a course towards a shared objective, Anisha and Gabriella find themselves at a crossroads, burdened by a legacy of unsuccessful collaborations.

    As no change happens from one day to another, the manager(s) would need to participate a lot more in day-to-day operations and be on the lookout for friction to immediately address them or bring the specific people to the side and work it out.

    Ricardo F.

    Strategies Implemented

    Anisha and Gabriella have previously attempted to bridge their differences and forge a path forward. These efforts, however, have been notably time-consuming and often fruitless, even with the involvement of other colleagues.

    NOTE: Unfortunately, at this stage, we don’t have historical information on taken actions so it’s for everyone’s interpretation.

    Challenges Encountered

    Despite the extended deliberations, agreements remain elusive, leaving many initiatives incomplete.

    The Key Question

    How can Anisha and Gabriella overcome the longstanding friction between them and unite effectively to achieve their collective goal?

    Your Thoughts

    As fellow CTOs and engineering leaders, 

    • How would you solve this conundrum? 
    • Have you faced similar challenges in your leadership journey? 
    • How did you navigate them?

    Share your experiences and tips in the comments. Let’s collaborate to create a roadmap for effective leadership in the dynamic environment of a start-up. Your expertise could be the guiding light for many others in similar situations.

    Peer Advice (Actionable Solutions from our CTO Community)

    Ricardo F.

    Hi everyone! Before I give my take on this case, here are some points I need to highlight:

    Having so many issues among team leads that seem to be craved on their way of working sounds like either the company culture needs to be revisited or it wasn’t well understood by the team and needs a lot of care in this aspect.

    The involvement of other colleagues doesn’t explain what was done exactly nor if they were the right people for the job since not everybody is cut to handle these delicate situations. I’ll have to assume that the methods used and the considerations made were indeed well thought out.

    From the leadership perspective, it sounds like they somehow were aware and tolerated these conflicts to happen and even affect the initiatives themselves, digging into their own problem at hand. Things should have been handled immediately and not allowed to scale it to this point.

    Setting cross-departmental objectives when the team is not in a solid state, could blow and end up as the many incomplete initiatives in the past.

    Now, my take:

    Let me start by stating the obvious – anyone picking up the current scenario will have a hard time making it right since it’s not an isolated episode or a strict group of people, even when you, as a manager, have experienced such problems in the past.

    Starting from the beginning, the manager(s) would have a 1-on-1 call with each of them and try to understand each other’s perspective. They should connect the dots of why there are so many conflicts which would potentially lead to a group call to address many of those points and bring the team back to cohesion. At the same time, they should make it clear that everyone is there to deliver their best work respectfully.

    As no change happens from one day to another, the manager(s) would need to participate a lot more in day-to-day operations and be on the lookout for friction to immediately address them or bring the specific people to the side and work it out. Always without forgetting the 1-on-1s to listen and make sure the other person knows they are listening to their problems/concerns even when they don’t agree with them and some contrary actions need to be taken. Sometimes, people just want to feel heard and feel their opinions are taken into consideration.

    Revisit the company culture, and make it open, inclusive and respectful. 

    Try to buy in whoever you can to help you foment these points and flip the current situation to a good path.

    Consider a gathering event, if it’s a remote type of company or some drinks in a video call on a Friday afternoon for the team to bond outside of work and try to find some common interests/perspectives.

    If nothing works and the manager(s) see that no one is making the effort to even try, maybe consider an improvement plan and personalise it for each team member. In the end, either they get better or you’ll need to find someone to take the business on a good path. In other words, manager(s) shouldn’t drag the situation for a very long time.

    I know I’m making some assumptions and the suggestions might be a bit generic, but as I said, it’s not an easy situation to handle when many members of the team are not working towards the same goal, delivering the objectives, even if they have different opinions/approaches.

    I would love to hear more thoughts on this and maybe even contradict/question my take.

  • Navigating the Leadership Labyrinth – A New Head of Engineering’s Journey

    Navigating the Leadership Labyrinth – A New Head of Engineering’s Journey

    Three months ago, Justin embarked on a pivotal journey as the new Head of Engineering at a startup, following the departure of the previous CTO. Commanding a team of eight, encompassing software developers and testers, Justin’s experience as a former team leader had primed him for this role. Yet, the path to leadership is often riddled with unexpected twists.

    Justin rushed into “hands-on” leadership in a very independent and autonomous leadership group. He might need to pull back on that account and start from the position of trust – trusting his employees to do their job well.

    Renata M.

    Strategies Implemented

    To forge a bond with his team, Justin introduced several initiatives:

    • Weekly one-on-one meetings to understand individual team members.
    • Discussions focusing on professional growth and career aspirations.
    • Active engagement in task execution for hands-on leadership.
    • Cultivating a friendly and approachable rapport.
    • Demonstrating best practices and exemplary work habits.
    • Assisting in problem-solving to foster a collaborative environment.

    Challenges Encountered

    Despite these well-intentioned efforts, Justin confronts a palpable barrier. The team views him as an outsider, their wariness manifesting in reluctance to engage fully. His approach, intended to nurture, is misinterpreted as micromanagement, leading to an atmosphere of confusion and demotivation.

    The Key Question

    How can Justin effectively bridge this gap and earn the trust of his team?

    Your Thoughts

    As fellow CTOs and engineering leaders, 

    • What advice would you offer to Justin at this critical juncture? 
    • Have you faced similar challenges in your leadership journey? 
    • How did you navigate them?

    Let’s discuss strategies and share insights that can help Justin transform this challenge into an opportunity for growth and stronger team cohesion.

    Share your experiences and tips in the comments. Let’s collaborate to create a roadmap for effective leadership in the dynamic environment of a startup. Your expertise could be the guiding light for Justin and many others in similar situations.

    Peer Advice (Viable Solutions)

    Renata M.

    I think several things can be done starting with separating status report meetings from 1-1s and explaining the “why” behind weekly 1-1s.

    It’s also possible Justin rushed into “hands-on” leadership in a very independent and autonomous leadership group. He might need to pull back on that account and start from the position of trust – trusting his employees to do their jobs well.

    Understanding how things, people and the organization work should come before any changes.

    Justin needs to focus on becoming the blocker removal personnel. He should be the force that helps get things done where needed.

    This will help build mutual trust and rapport.
    Once rapport is build he can lead his group according to his own vision, but taking into account that it might be significant change from what they had before.

    Change takes time, even in a start-up.

    Additional ideas:

    Has Justin ever asked his employees what they expect from their leader and does he fit that image?

    Is Justin applying the correct leadership style?

    Maybe the collaborative and democratic style does not meet the current needs of the organization?

    Paul C.

    Simply said, people are uncomfortable with change. Going in guns blazing with these initiatives was a bad idea. The problems are relevant but the approach was wrong imo. This team is small, probably tight knit.

    Perhaps Justin can organise a ritual reset/retro of the team, with a “I’m being a sponge” approach. Have the team describe what generally happens day to day, then address each of the 6 points as a “How might we”, if any of the rituals or points become a challenge/problem point.
    Building rapport is equally as important as being a sponge, so asking the team for help in a meaningful sense to both Justin and team development, i.e. “I’m looking for an expert on this subject to help me with Y” rather than “I need you to do Z.”

    Justin should prioritise the following day to day in everything he can do.
    – Context (pulling it left and right)
    – Communication (up and down)
    – Consistency (of the above two)

    Ken K.

    Those are some great thoughts
    @Renata M (and @Keith P) — I’ve found “managers”, even highly experienced ones, often don’t really know how to make 1:1s work effectively, and also struggle with how much (and what kind) of team interaction is best for their team(s).

    With 1:1s are hopefully not the place for being “transactional”, that’s what status meetings or chats are for.

    However, leaders in engineering tend to have a difficult time having effective regular meetings without that transactional “check off list”.

    And for that matter team members often are of the same bent, and really want 1:1s to be transactional so it seems clearer to them.

    To @Keith P’s point, weekly 1:1s that are simple calendar-ed 10-15 minutes chats are a great way to start down that road. Always go into the chat asking about the person’s life, make it personal, definitely steer it away from status updates unless something is just burning on their mind in that regard.

    If anything more specific comes up in the short chats, you can schedule follow-on chats to discuss it, such as them saying “I really want to start working towards my AWS certification”.

    Don’t problem-solve that immediately, but make definite time to dive into it more.

    With Team Interactions (“active engagement in task execution”)
    this one’s always tough as a Leader, because we want to help and are probably pretty darn good at the technical stuff.

    It’s also extremely impactful if done right, building trust with your team, and having a “felt experience” of what they go through (with the “legacy code” and “tech debt” for instance), rather than just hearing second hand I’ve found being inquisitive, absolutely servant leadership oriented, and as Renata M
    reminds – “Be the blocker remover”, not just at high-level, but even when looking at some code with your team.

    Jamie C.

    It’s a small team – make it fun. Be honest about the gaps in his own skills and that he is learning about the role – be humble.. Most of all, try and be that servant leader – if he can understand the things that make their lives hard and enable his team he will be successful.

    Keith P.

    I agree with Renata, it feels Justin might be jumping in with quite a procedural management style.
    Building trust with less formal chats before diving in to growth and career aspirations, would be something I’d always do.
    Asking the team where they might need help – more servant leadership

    Response

    1. Mourad Z

      Before jumping on ceremonies with his team, Justin should instead focus on two primary areas:

      Understand the current state of affairs: what works well, what doesn’t, how is the current process working or not, the state of tech debt, where are the expertise and skills deficiencies, who are the leaders and those with potential and who needs help and coaching, etc. This takes time but through his interactions with the team, Justin would need to collect this kind of information.

      Understand where things should be down the line in terms of how he and his team can best support the business, deliver great customer value, improve the products, the operational efficiencies and others.

      Doing these two can occur in parallel and in the process, Justin can be transparent with his team about what he is after. That would open up his team, knowing that their new leader has a purpose in making things better. During these two activities, he should do a lot of listening while also articulating his objectives. These two combined nurture trust and inspiration. In addition, they would be the needed context for Justin to formulate, with help from his team, a roadmap to make things better. Priorities need to combine bottom up and top down feedback and he needs to be transparent about this. Where he sees conflict between these two, he also needs to be transparent and tell his team why their feedback is leading the way or why top down considerations need to dominate for the moment.