The Customer Token Handler project offers an ironic illustration of Tuckman’s stages of group development – specifically how a highly skilled group can easily fail due to team dynamics. At a major technology company in Southeast Asia, an experiment in temporary team formation produced an unexpected lesson in ineffectiveness.
The setup appeared logical on paper. Three seasoned technical leads from Mobile, Homepage, and Supply Extranet domains would combine their expertise for two sprints in a temporary 3 person team. The mission: create a unified token handling library for customer authentication. Experience suggested their combined expertise would accelerate delivery.
Hour one revealed the fundamental flaw. The Homepage lead populated JIRA with exhaustive tickets. The Mobile lead covered whiteboards with sticky note tasks. The Supply Extranet lead, not one for the bureaucracy of planning, just started writing code. Three experts, three methodologies, zero progress. No forming, straight to storming, never reaching norming.
The two-sprint experiment dissolved afterwards without a working solution. The project appeared destined for failure until one technical lead took ownership. Working alone, they completed the token handling library in another two weeks – accomplishing more solo than the combined team had achieved together in double that time.
This outcome challenged conventional wisdom about collaborative development. While the three-person team generated extensive documentation, diagrams, and partial implementations, they never established the shared context necessary for effective collaboration. The eventual solo success demonstrated how reduced coordination overhead can sometimes accelerate delivery, did we end up with a better product from the solo lead? probably not, but its a working one at least that we can iterate on.
The Customer Token Handler story reshaped our approach to temporary team formation. It highlighted how Tuckman’s stages cannot be shortcuts, even with experienced technical leaders. Teams should be long lived to be effective.
We must never look at Engineering teams like a scheduling problem to solve, they are people, they have the same flaws and quirks as people do, we need to acknowledge them beyond their IC number in order to create winning teams.
There’s a saying in business that “what gets measured, gets managed.” But in the complex world of modern software systems, choosing what to measure can be as crucial as the measurement itself. Enter the concept of Technical North Star metrics – not just another KPI, but a fundamental compass that guides technical decisions and shapes organizational behavior.
The Power of a Single Number
When I first encountered the concept of a Technical North Star metric at a previous organization, I was skeptical. How could one number capture the complexity of our technical systems? But over time, I’ve come to appreciate the elegant simplicity it brings to decision-making and incident management.
The most effective Technical North Star metrics share three key characteristics: they’re ubiquitous throughout the organization, they directly correlate with business success, and perhaps most importantly, they’re actionable at every level of the technical organization.
Consider Netflix’s “Total Watch Time” or Facebook’s “Daily Active Users.” These aren’t just vanity metrics – they’re deeply woven into the technical fabric of these organizations. Every engineer, product manager, and executive speaks this common language, creating a shared understanding of success and failure.
From Metric to Currency
One of the most enlightening perspectives I’ve encountered came from a manager who described our Technical North Star metric as a “currency.” This analogy perfectly captures how these metrics function within an organization.
At Agoda, for instance, “Bookings” serves as this universal currency. While I can’t share specific numbers, what’s fascinating is how this metric has become part of the engineering team’s DNA. Ask any engineer about current booking rates, and they’ll know the number (though they won’t share it!).
This currency analogy extends beautifully to incident management. When an incident occurs, we can literally “count the cost” in terms of lost bookings. It’s not abstract – it’s concrete, measurable, and immediately understood throughout the organization.
The Art of Measurement
But how do we actually measure these metrics in a meaningful way? The approach needs to be both sophisticated enough to be accurate and simple enough to be actionable.
At Agoda, we’ve developed an elegant solution for measuring booking impact during incidents. We look at four-week averages for specific time windows. For instance, if the 10:00-10:10 AM window typically sees 50 bookings (a hypothetical number), any significant deviation from this baseline triggers investigation. When services are restored and the trend returns to normal, we can calculate the “cost” of the incident in terms of lost bookings.
This approach is brilliant in its simplicity. It accounts for natural variations in booking patterns while providing clear signals when something’s amiss. The four-week average smooths out daily fluctuations while remaining responsive enough to reflect recent trends.
Beyond Incidents: Driving Technical Excellence
The real power of a Technical North Star metric extends far beyond incident management. It shapes architectural decisions, influences feature prioritization, and drives technical innovation.
When every technical decision can be evaluated against its potential impact on the North Star metric, it creates clarity in decision-making. Should we invest in that new caching layer? Well, how will it affect bookings? Is this new feature worth the additional complexity? Let’s AB Test it on bookings.
You can look at the incrementality of these metrics to measure a B variants success which generally translates to direct bottom line value. For example, if we see a B variant is up on 200 Bookings per Day, this language translates to bottom line impact that’s easy for any engineer to understand. Connecting you day to day work to impact is very important for motivation of staff.
The Human Element
Perhaps the most underappreciated aspect of Technical North Star metrics is their impact on organizational behavior. When everyone from junior engineers to senior architects speaks the same language and measures success by the same yardstick, it creates alignment that no amount of process or documentation can achieve.
This shared understanding breaks down silos between teams. When a front-end engineer and a database administrator can discuss the impact of their work in terms of the same metric, it creates a foundation for meaningful collaboration.
Looking Forward
As our systems grow more complex and our organizations more distributed, the importance of having a clear Technical North Star only increases. The metric must evolve as our products and markets evolve. What worked yesterday might not work tomorrow.
The key is to maintain the balance between stability and adaptability. Your Technical North Star should be stable enough to guide long-term decisions but flexible enough to remain relevant as your business evolves.
The next time you’re evaluating your organization’s technical metrics, ask yourself: Do we have a true Technical North Star? Does it drive behavior at all levels of the organization? Is it serving as a currency for technical decision-making? If not, it might be time to look up and reorient your technical compass.
Remember, the best Technical North Star isn’t just a metric – it’s a shared language that aligns technical excellence with business success. And in today’s complex technical landscape, that alignment is more valuable than ever.
Two decades ago, the software development world witnessed a significant shift. Scrum, a framework within the Agile methodology, was gaining tremendous popularity. This change coincided with a wave of redundancies among traditional project managers. Faced with evolving industry demands, many of these professionals saw an opportunity to reinvent themselves as Scrum Masters.
The true nature of the problem became clear to me when the Project Management Institute (PMI) added an Agile certification, allowing it to contribute points towards one’s overall project management goals.
This certification still exists today, enabling individuals to become “Certified in Agile” through self-study and an online exam. The concept seems utterly foreign to me, especially when I reflect on my experience with the Certified Scrum Master (CSM) course I took with Scrum Alliance years ago. That intensive three-day course was such an eye-opener, fundamentally shifting my mindset. I simply cannot envision anyone truly grasping the core concepts of Agile without face-to-face communication – a principle that, ironically, is a core value in the Agile Manifesto itself.
This transition wasn’t always smooth or successful though. Many former project managers approached Scrum with a mindset still rooted in traditional methodologies. They viewed it as merely a new set of processes to follow rather than a fundamental shift in philosophy and approach.
This misinterpretation led to a superficial adoption of Scrum practices:
Gantt Charts Transformed: The detailed project timelines of Gantt charts were simply repackaged as product backlogs, missing the dynamic and flexible nature of true Agile planning.
Sprint Reviews Misused: Instead of focusing on demonstrating working software and gathering valuable feedback, sprint reviews often devolved into status update meetings reminiscent of traditional project reporting.
Daily Standups Misinterpreted: The essential daily sync-up became a rote status report, losing its intended purpose of team coordination and obstacle identification.
In essence, while the terminology changed, the underlying project management approach remained largely unchanged. This “Scrum-but” approach – “We’re doing Scrum, but…” – became prevalent in many organizations.
This misapplication of Scrum principles highlights a crucial lesson: true agility isn’t achieved by merely adopting a new set of practices. It requires a fundamental shift in mindset, embracing flexibility, continuous improvement, and most importantly, a focus on delivering value to the customer.
As modern software engineers and managers, it’s crucial to reflect on this history. We must ask ourselves: Are we truly embracing the spirit of Agile and Scrum, or are we simply going through the motions? The power of these methodologies lies not in their ceremonies, but in their ability to foster collaboration, adaptability, and customer-centricity.
The evolution of Scrum serves as a reminder that in our rapidly changing industry, it’s not enough to change our processes. We must also transform our thinking, our culture, and our approach to creating software that truly meets the needs of our users.
The Unintended Consequences of Rigid Scrum Implementation
Scrum was originally designed as a flexible, adaptive framework for product development. Its creators envisioned a methodology that would empower teams to respond quickly to change and deliver value efficiently. However, as Scrum gained popularity, a troubling trend emerged. Many organizations began to treat Scrum as a rigid methodology, leading to several significant issues:
Ritual Over Results: Teams became more focused on following Scrum ceremonies to the letter rather than using them as tools to improve productivity and value delivery.
Inflexible Sprint Lengths: The idea of fixed-length sprints, while useful for creating rhythm, was often applied too rigidly. Teams lost the ability to adapt to work that didn’t neatly fit into arbitrary time boxes.
Product Backlog as a Wish List: Product backlogs grew unwieldy, losing the crucial connection between backlog items and real customer needs. They became dumping grounds for ideas rather than curated lists of customer problems and needs.
One-Size-Fits-All Approach: Organizations often applied Scrum uniformly across different types of projects and teams, ignoring the need for adaptation based on context.
Overemphasis on Velocity: Story points and velocity, meant to be team-specific measures of capacity, became weaponized as performance metrics, leading to all sorts of dysfunctional behaviors.
“Never mistake motion for action.” – Ernest Hemingway
The results of this rigid application were often the opposite of what Scrum intended:
Decreased Agility: Ironically, the rigid application of Scrum led to less agile teams. They became bound by their processes rather than empowered by them.
Reduced Innovation: Over-planning and strict adherence to sprints left little room for experimentation. Teams became risk-averse, focusing on meeting sprint goals rather than solving customer problems.
Misalignment with Business Goals: The focus shifted to sprint completion rather than delivering business value, creating a disconnect between Scrum activities and overall product strategy.
Signs Your Team Might Be Falling into the Scrum Trap
If you’re wondering whether your team has fallen into a rigid Scrum implementation, here are some signs to look out for:
Ceremony Fatigue: Team members view Scrum events as time-wasting meetings rather than valuable collaboration opportunities.
Velocity Obsession: There’s a constant push to increase velocity, often at the expense of quality or sustainable pace.
Inflexible Planning: Your team struggles to accommodate urgent work or valuable opportunities because “it’s not in the sprint.”
Stale Backlog: Your product backlog is enormous, with items at the bottom that haven’t been reviewed in months (or years).
Sprint Goal Apathy: Sprint goals, if they exist at all, are vague or uninspiring, and the team doesn’t use them to guide decisions.
Lack of Experimentation: Your team rarely tries new approaches or technologies because there’s “no room in the sprint” for learning or innovation.
Lack of User Feedback: Stories come curated from a seeming invisible place in the sky onto the backlog, with little justification as to why we are doing things. After shipping you are “done”, no measurement of impact post release is done, only “feature shipped”.
Scrum Master as Process Police: The Scrum Master’s primary function has become enforcing rules rather than coaching and facilitating. Has your scrum master said lately “No you cant add that story to the sprint, we’ve already started, you need to wait till next sprint”, is this statement Agile?
One-Size-Fits-All Sprints: All your teams have the same sprint length and use the same processes, regardless of their work’s nature. They all measure themselves in teh same way, story points delivered or sprint completion rate, might be everyone’s main measure of success.
Conclusion: Rediscovering Agility in Scrum
The evolution of Scrum from a flexible framework to a rigid methodology in many organizations serves as a cautionary tale for the Agile community. It reminds us that the true spirit of agility lies not in strict adherence to practices, but in the principles that underpin them.
To truly benefit from Scrum, teams and organizations need to:
Focus on Outcomes: Shift the emphasis from following processes to delivering value.
Embrace Flexibility: Adapt Scrum practices to fit the team’s context and the nature of their work.
Foster Innovation: Create space for experimentation and learning within the Scrum framework.
Align with Business Goals: Ensure that Scrum activities directly contribute to overarching product and business strategies.
Continuous Improvement: Regularly reflect on and adapt not just the product, but the process itself.
Remember, Scrum is a framework, not a prescription. Its power lies in its ability to help teams organize and improve their work, not in rigid rule-following. By rediscovering the flexibility and adaptiveness at the heart of Scrum, teams can avoid the pitfalls of overly rigid implementation and truly harness the benefits of agile methodologies.
As we move forward in the ever-evolving landscape of software development, let’s carry forward the lessons learned from Scrum’s journey. Let’s strive to create processes that truly empower our teams, deliver value to our customers, and drive innovation in our products. That, after all, is the true spirit of agility.
In the fast-paced world of software engineering, the quest for code quality is never-ending. As organisations scale and codebases grow, maintaining consistency and preventing bugs becomes increasingly challenging. Enter linting: the seemingly perfect solution to all our code quality woes.
It’s a familiar scene in engineering teams across the globe. A passionate developer, let’s call them our “hero engineer,” identifies the root of all evil: inconsistent, potentially buggy code repeated throughout the codebase. Their solution? Implement a series of good practice linting rules to revolutionize the way people code. With the best of intentions, they charge forth, determined to elevate the entire team’s coding standards.
The promise is enticing: with these new linting rules in place, surely the code will magically improve. After all, if engineers can’t merge without passing these checks, they’ll have to write better code, right?
Wrong.
II. The Problem: When Linting Becomes Policing
In the complex ecosystem of a modern engineering organization, introducing new rules without proper context can lead to unexpected – and often counterproductive – results.
A. Engineers’ Reaction to Unexplained Linting Errors
Picture this: An engineer, deep in the flow of solving a critical problem, suddenly encounters a barrage of linting errors in their IDE or CI pipeline. These errors, appearing out of nowhere, seem to have no relation to the functionality they’re implementing. What’s their instinctive reaction?
More often than not, the goal shifts from “write good code” to “make the errors go away.” This usually involves finding the quickest path to silence these annoying new alerts that have suddenly appeared in their workflow.
Let me share a real-world example I’ve encountered:
In a production repository I once worked on, I witnessed this scenario unfold. Our well-intentioned “hero engineer” had implemented strict linting rules overnight. The next day, pull requests were failing left and right due to linting errors. What happened next was eye-opening.
Instead of embracing these new rules, engineers started adding // eslint-disable-next-line comments liberally throughout the codebase. Others went a step further, adding /* eslint-disable */ at the top of entire files. The very tools meant to improve code quality were being systematically circumvented.
This behaviour isn’t born out of malice or laziness. It’s a natural response to a perceived obstacle in the development process, especially when the benefits of these new rules aren’t clear or immediate.
And this inst a totally fictional tale, below example from production code bases I’ve witnessed people similar to our hero try this on
B. The Temptation to Force Rules
Faced with this resistance, our hero engineer might be tempted to double down. “If people won’t follow the rules voluntarily,” they think, “we’ll have to force them.” This usually involves:
Putting codeowners on lint configuration files
Implementing additional scripts to check for inline linting disables
Blocking merges for any code that doesn’t pass linting
“If all you have is a hammer, everything looks like a nail.” — Abraham Maslow
Suddenly, our well-meaning engineer finds themselves in an ongoing battle with their own colleagues. The very team they sought to help now views them as an adversary, the enforcer of arbitrary and frustrating rules.
C. The “Military vs. Police” Analogy
This situation reminds me of a quote from the 2004 series Battlestar Galactica. Admiral Adama says:
“There’s a reason you separate military and the police. One fights the enemies of the state, the other serves and protects the people. When the military becomes both, then the enemies of the state inevitably become the people.”
While we’re not dealing with matters of state security, the principle holds true in software engineering. When we turn our tools of improvement into our “military might” against our own team members, we risk turning them into adversaries rather than collaborators.
In a modern engineering organization, where collaboration and shared ownership of code quality are crucial, this adversarial approach can be toxic. It creates an “us vs. them” mentality, where developers feel policed rather than supported in their efforts to improve.
The result? A team that’s more focused on appeasing the linter than on writing genuinely good, maintainable code. The very tool intended to improve code quality becomes a bureaucratic hurdle to be overcome, rather than a valuable aid in the development process.
So, if forcing linting rules upon the team isn’t the answer, what is? How can we harness the power of linting tools without creating a police state in our codebase?
III. The Alternative: Linting as a Teaching Tool
“You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete.” – Buckminster Fuller
So, if enforcing linting rules like a code police force isn’t effective, what’s the alternative? The answer lies in a fundamental shift of perspective: from policing to teaching.
It’s about the Importance of Education and Buy-in. In modern engineering organizations, where autonomy and expertise are valued, dictating rules without explanation is rarely effective. Instead, we need to focus on education and securing buy-in from the entire team.
Remember: if your team doesn’t believe in the linting rules, they won’t follow them — at least not in the spirit they were intended.
Starting a Dialogue with Your Team, the key to successful implementation of linting rules is open communication. Here’s how to approach it:
Agree on the reasons for linting: Is it for bug prevention (quality) or increasing readability (velocity)? Make sure everyone understands and agrees with the goals.
Collaborative rule-setting: Involve the team in deciding which rules to implement. This isn’t just about democracy — it’s about leveraging the collective expertise of your engineers.
Use tools like Code Coach: For teams working with external contributors or in code review scenarios, tools like Code Coach can help enforce agreed-upon standards without feeling heavy-handed.
Implementing Linting Effectively, Once you have buy-in, consider these strategies for smooth implementation:
Plan for legacy code: Create a plan to clean up existing code gradually. Automation can be your friend here — look for existing code fixes or write your own if needed.
Fail fast: Implement linting warnings as close to the development process as possible. IDE warnings are far less frustrating than CI pipeline failures.
Document and explain: Ensure that every linting rule has a clear explanation and, if possible, a link to further documentation.
IV. Best Practices for Educational Linting
Now that we’ve shifted our mindset from policing to teaching, let’s explore some best practices that embody this educational approach.
Try to Explain the ‘Why’ Behind Rules. Unhelpful errors like “don’t do this” teach obedience, not understanding. We’re dealing with knowledge workers, not factory line operators. Put the ‘why’ in your errors, and if your linter supports it, link out to documentation.
For example, in C#, using Roslyn metadata can embed links to documentation directly in IDE error messages, providing immediate context and explanation.
BYO (Build Your Own) Rules When Necessary. Most of the time, the best way to start is by agreeing on standards within your team. Document these in an easily accessible format — markdown files in your repo can work well.
From this document, look for existing rules in the market that match your standards. If you can’t find any, don’t be afraid to write your own. Most language-specific rules are fairly trivial to write, usually requiring only 10-20 lines of code each.
You can read in this post about how we approached this is Agoda many years ago.
Please, please Use Auto-formatters, if you’ve established style standards, don’t make people implement them manually. Every major programming language has formatters that work with IDEs. Make use of them!
Here’s a story that illustrates the importance of auto-formatters:
I once had an engineer who was the first external contributor to a particular Scala backend in our company. He sent a PR with about 500 lines of code changed or added. The review came back with 140 comments — about one comment for every three lines. It was escalated to the Director/VP level because it seemed so egregious.
When we dug into it, we realized about 80% of the comments were purely about style: “You need a line feed before this brace,” “This brace needs one more tab in front of it,” and so on.
After this realization, we de-escalated the situation.
But here’s where the story takes a positive turn: my engineers did a follow-up PR to add Scala style configurations to the repo. They went through all 140 comments and reverse-engineered a Scala style config that suited the team’s preferences. They even held a knowledge-sharing session afterward.
That right there is good culture. Instead of assuming the contributor was careless or incompetent, the team recognized a knowledge gap around the tooling and filled it, then shared that knowledge.
Automate Fixing Where Possible. Most linters are based on AST (Abstract Syntax Tree) queries, which means you can often apply mutations to the AST to automatically fix issues. This makes it even easier for developers to comply with standards.
Here’s another story that illustrates this principle:
Whenever a new version of C# would come out, Microsoft would often include code fixes in Visual Studio to convert old language patterns to new ones. This became my personal way of learning new language features. My IDE would suggest, “This is a code smell. Let’s fix it,” and then I’d apply the auto-formatting to see a new, often more concise or readable way of doing things.
By automating fixes interactively via teh IDE while engineers are coding, you’re not just enforcing standards — you’re actively teaching developers new and improved coding patterns.
Remember, the goal isn’t to force developers into rigid compliance. It’s to create an environment where writing high-quality, consistent code is the path of least resistance. By focusing on education, collaboration, and automation, you can transform linting from a policing tool into a teacher that scales, elevating the skills of your entire engineering organization.
V. Creating a Culture of Continuous Improvement
In modern engineering organizations, the way we approach code quality can significantly impact team dynamics, productivity, and overall job satisfaction.
Don’t Assume Malice or Incompetence, when faced with code that doesn’t meet our standards, it’s easy to jump to conclusions about the developer’s skills or intentions. However, this mindset is rarely productive and often inaccurate.
Remember: In almost all cases, developers aren’t writing “bad” code out of laziness or incompetence. They usually haven’t been shown a better way yet. This principle applies not just to linting, but to all aspects of tooling and best practices.
Foster an Environment of Knowledge Sharing, try to create a culture of continuous improvement means making knowledge sharing a core value of your team. Here are some ways to encourage this:
Regular code review workshops: These can be opportunities to discuss common issues found in reviews and share solutions.
Linting rule of the week: Highlight a specific linting rule each week, explaining its purpose and demonstrating good practices.
Pair programming sessions: Encourage developers to work together, especially when implementing new patterns or working with unfamiliar parts of the codebase.
Tech talks or brown bag sessions: Give team members a platform to share their knowledge about tools, techniques, or interesting problems they’ve solved.
Encourage Feedback and Iteration on Linting Rules, remember, your linting rules shouldn’t be set in stone. As your team grows and your codebase evolves, your needs may change. Create a process for regularly reviewing and updating your linting rules. This might include:
Quarterly linting reviews: Discuss which rules have been helpful, which have been pain points, and what new rules might be beneficial.
An easy process for proposing changes: Make it simple for any team member to suggest modifications to the linting rules.
Trial periods for new rules: When introducing a new rule, consider having a “warning only” period before enforcing it, allowing the team to adjust and provide feedback.
VII. Conclusion: Embracing Linting as a Teaching Tool
The Teacher Approach vs. The Police Approach, we started by examining the common pitfall of treating linting rules as a policing tool. We saw how this approach often leads to resistance, workarounds, and a adversarial relationship between developers and the very tools meant to help them.
In contrast, we’ve explored the benefits of treating linting as a teaching tool. This approach focuses on education, collaboration, and continuous improvement. By explaining the ‘why’ behind rules, involving the team in rule-setting, and fostering a culture of knowledge sharing, we can transform linting from a source of frustration into a catalyst for growth.
B. Long-term Benefits of Educational Linting
The benefits of this educational approach extend far beyond just cleaner code:
Improved Developer Skills: By understanding the reasoning behind linting rules, developers become more skilled and conscientious coders.
Increased Team Cohesion: Collaborative rule-setting and knowledge sharing foster a sense of shared ownership and team unity.
Faster Onboarding: Clear, well-explained coding standards make it easier for new team members to get up to speed quickly.
Adaptability: Regular review and iteration of linting rules ensure that your practices evolve with your team and technology.
Positive Engineering Culture: An approach based on teaching and collaboration contributes to a more positive, growth-oriented engineering culture.
C. Call to Action: Evaluate and Improve Your Linting Culture
As we conclude, I encourage you to take a step back and evaluate your team’s current approach to linting:
Are your linting rules serving as a teacher or a police officer?
Do your developers see linting as a helpful tool or a frustrating obstacle?
Is there open dialogue about coding standards and best practices?
If you find that your current approach leans more towards policing than teaching, consider implementing some of the strategies we’ve discussed. Start small – perhaps by initiating a team discussion about one or two linting rules. Remember, the goal is not perfection, but continuous improvement and learning.
By shifting towards an educational approach to linting, you’re not just improving your code – you’re investing in your team’s growth and creating a more positive, collaborative engineering culture.
VIII. Additional Resources
To help you on your journey towards more effective, educational linting, here are some additional resources you might find useful:
Further Reading on Effective Code Review and Team Collaboration
“Best Kept Secrets of Peer Code Review” by Jason Cohen
A comprehensive guide to effective code review practices.
“The Art of Readable Code” by Dustin Boswell and Trevor Foucher
Offers insights into writing clear, maintainable code.
“Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. Martin
A classic book on writing quality code that’s easy to understand and maintain.
“The Pragmatic Programmer: Your Journey to Mastery” by Andrew Hunt and David Thomas
Provides practical advice for improving as a programmer, including tips on code quality and team collaboration.
Remember, the journey to better code quality is ongoing. Stay curious, keep learning, and always be open to new ideas and approaches. Happy coding!
In the world of software development, long-term roadmaps have long been a staple of project management. These carefully crafted plans, often spanning months or even years, aim to provide a clear path forward for product development. They outline features, set deadlines, and allocate resources with precision that would make any project manager proud.
But here’s the deal: by the time you start working on that meticulously planned roadmap, the market is already changing. The technology landscape shifts like quicksand beneath your feet, and customer needs evolve at breakneck speed. This creates a fundamental tension between our desire for orderly planning and the chaotic reality of the tech world.
The Siren Song of Long-Term Roadmaps
Despite this tension, companies are often drawn to long-term planning like moths to a flame. It’s not hard to see why:
Illusion of Control: Long-term roadmaps provide a comforting sense of control in an unpredictable industry. They offer a vision of the future that feels tangible and achievable.
Alignment with Business Goals: These roadmaps allow companies to align their development efforts with broader business objectives, creating a narrative of progress that’s easy to communicate to stakeholders.
Resource Allocation: With a long-term plan in hand, it becomes easier (in theory) to allocate resources, budget for future needs, and make hiring decisions.
Compatibility with Traditional Business Cycles: Many businesses operate on annual or multi-year planning cycles. Long-term roadmaps fit neatly into these established rhythms, making them attractive to executives and boards.
The Problems: When Plans Meet Reality
However, as Mike Tyson famously said, “Everybody has a plan until they get punched in the mouth.” In software development, that punch often comes swiftly and from multiple directions:
Rapid Technological Changes: The tech you planned to use might be outdated by the time you implement it. New frameworks, languages, or methodologies can emerge that render your careful plans obsolete.
Shifting Market Demands: Customer needs and expectations can change dramatically in a short time. The feature that seemed critical six months ago might be irrelevant today.
Disruptive Competitors: In the time it takes to execute your roadmap, a new competitor might enter the market with an innovative solution that changes the game entirely.
Estimation Difficulties: Accurately estimating time and resources for software development is notoriously difficult, especially for work that’s months or years in the future.
Stifled Innovation: Rigid adherence to a long-term plan can blind you to new opportunities and stifle the kind of rapid innovation that’s often necessary in the tech world.
Case Studies: The Perils and Promises of Planning
Let’s look at a couple of real-world examples that illustrate the challenges and opportunities in software development planning:
Waterfall Woes at FirstBank: FirstBank, a large financial institution with over 10 million customers, spent 18 months meticulously planning a comprehensive overhaul of their online banking system. The project, codenamed “Digital Horizon,” was designed to modernize their web-based services and improve customer experience.However, by the time they were halfway through development in 2010, the mobile revolution was in full swing. The iPhone and Android smartphones had exploded in popularity, and customers were increasingly demanding mobile banking solutions. Much of FirstBank’s planned desktop-focused features suddenly seemed outdated.The bank found itself in a difficult position. They had already invested millions in the project, but continuing as planned would result in a product that was behind the curve at launch. They made the painful decision to scrap significant portions of their work and pivot towards mobile development. This led to delays of over a year and cost overruns exceeding $30 million.The “Digital Horizon” project, originally slated to give FirstBank a competitive edge, instead left them playing catch-up in the mobile banking space for years to come.
Agile Triumph at QuickPay: In contrast, QuickPay, a small fintech startup founded in 2012, took an iterative approach to developing their peer-to-peer payment app. Instead of planning out years in advance, they released a minimal viable product (MVP) with basic transfer functionality and rapidly iterated based on user feedback.This agile approach allowed QuickPay to pivot quickly when they discovered an unexpected demand. Users were frequently splitting bills at restaurants and bars, and wanted an easy way to divide payments among friends. This wasn’t a feature QuickPay had originally considered as central to their app.Within two months, QuickPay had developed and released a “Split Bill” feature. They continued to refine it based on user feedback, adding capabilities like itemized bill splitting and integration with popular restaurant POS systems.Within a year, the “Split Bill” feature became QuickPay’s main selling point, setting them apart in a crowded fintech market. It propelled them from 100,000 users to over 5 million, capturing a significant market share from larger, more established payment apps.By 2015, QuickPay’s success attracted the attention of major financial institutions. They were acquired by a leading bank for $400 million, a testament to the value created by their, customer-focused development approach.
These examples highlight a crucial truth in the fast-paced world of software development: the ability to adapt quickly and respond to user needs often trumps even the most carefully laid long-term plans.
The Inevitability of Change in Software Development
In the world of software development, change isn’t just common—it’s inevitable. Unlike traditional industries where conditions might remain stable for years, the software landscape can transform dramatically in a matter of months or even weeks. This rapid evolution is driven by several factors:
Technological Advancements: New programming languages, frameworks, and tools emerge constantly, often rendering existing solutions obsolete.
Shifting User Expectations: As users interact with various digital products, their expectations for functionality, design, and user experience evolve rapidly.
Market Disruptions: Startups with innovative ideas can quickly disrupt established markets, forcing everyone to adapt.
Regulatory Changes: Especially in fields like fintech or healthcare, new regulations can necessitate significant changes to software systems.
This constant state of flux means that software development requires a fundamentally different approach to planning compared to other industries. While a construction project can often stick closely to initial blueprints, a software project needs to be able to pivot at a moment’s notice.
The key is to embrace change not as a disruption, but as an opportunity for innovation and improvement. This mindset shift is crucial for success in the dynamic world of software development.
Alternative Approaches to Planning
As Elon Musk once said, “You don’t need a plan. Sometimes you just need balls”, operating without a long term plan is scary for some people, you feel less in control, but once you realize you are in even less control with one, it get’s easier. Here are some alternative approaches that embrace the dynamic nature of software development:
Inspect and Adapt Principle: This principle acknowledges that we can’t predict everything, so we need to regularly examine our progress and adjust our approach based on what we learn. Agile methodologies, in particular, heavily rely on this principle, incorporating regular retrospectives and iterative development to ensure teams can pivot quickly when needed.
Extreme Programming (XP) Cycles: XP introduces an interesting approach with its weekly and quarterly cycles. The weekly cycle focuses on short-term planning and execution, where teams plan at the start of each week and deliver working software by the end. The quarterly cycle is used for reflection and longer-term planning, allowing teams to adjust their course based on what they’ve learned over the past quarter. This dual-cycle approach balances the need for immediate action with longer-term strategic thinking.
Rolling Wave Planning: This technique involves detailed planning for the near-term future, with broader, less detailed plans for the longer term. As time progresses, the plan is continuously updated and the detailed planning “wave” rolls forward. This approach acknowledges that we have more accurate information about the near future and allows for flexibility as we move forward.
OKRs (Objectives and Key Results): This goal-setting framework, popularized by Google, focuses on setting ambitious objectives and measurable key results. OKRs are typically set quarterly, allowing for more frequent reassessment and pivoting compared to traditional annual planning. They provide direction without prescribing specific solutions, giving teams the flexibility to determine the best way to achieve the objectives.
“Just Enough” Planning: This concept emphasizes doing only the minimum amount of planning necessary to start making progress. It’s about finding the sweet spot between flying blind and over-planning. The idea is to do just enough planning to provide direction and alignment, but not so much that it becomes a burden or limits adaptability.
The common thread among these approaches is flexibility. They all acknowledge that plans will change and build in mechanisms for adapting to new information or circumstances. By embracing these more dynamic planning methods, software development teams can stay agile in the face of inevitable change and uncertainty.
Balancing Long-Term Vision with Short-Term Flexibility
While embracing change is crucial, it doesn’t mean operating without direction. The key is to balance a clear long-term vision with flexible short-term planning.
The Importance of Long-Term Vision
A compelling long-term vision serves several crucial purposes:
It provides a North Star for decision-making
It helps align teams and stakeholders around common goals
It inspires and motivates team members
Your long-term vision might be something like “Become the go-to platform for peer-to-peer payments” or “Revolutionize online education.” This vision should be ambitious and inspirational, but also clear and focused.
Combining Vision with Flexible Planning
Here’s how you can maintain your long-term vision while embracing flexible short-term planning:
Set Directional OKRs: Use your long-term vision to inform high-level, directional OKRs. These provide guidance without prescribing specific solutions.
Use Adaptive Roadmaps: Instead of detailed feature lists, create roadmaps that focus on problems to be solved or outcomes to be achieved. This allows teams the flexibility to find the best solutions.
Regular Check-ins: Schedule regular sessions to review progress and reassess priorities (quarterly at most). This allows you to course-correct while still moving towards your long-term vision. Some advice I got on this once, if the project is on fire, bi-weekly check-ins, if the project is running smoothly monthly or even quarterly, if the project is doing “amazing” biweekly, work out what makes them so good and maybe you can apply in other areas.
Empower Teams: Give your teams the autonomy to make decisions about how to best achieve the objectives. They’re closest to the work and often best positioned to respond to changes.
Communicate Constantly: Regularly reinforce the long-term vision while acknowledging and explaining changes in short-term plans. This helps maintain alignment and buy-in.
By maintaining a clear long-term vision while embracing flexible short-term planning, you can navigate the ever-changing landscape of software development effectively. You’ll be positioned to seize new opportunities as they arise, while still moving consistently towards your ultimate goals.
Remember, in software development, the ability to adapt is often more valuable than the ability to predict. Embrace change, stay flexible, and keep your eyes on the horizon.
Implementing More Flexible Planning in Your Organization
Transitioning from long-term roadmaps to more adaptive planning isn’t just about adopting new methodologies—it’s a cultural shift. Here are some tips to help you make this transition:
Start Small: Begin with a pilot project or team. This allows you to test and refine your approach before rolling it out organization-wide.
Educate Your Team: Provide training on adaptive planning techniques. Help your team understand the ‘why’ behind the change.
Emphasize Outcomes Over Outputs: Shift focus from feature delivery to achieving business outcomes. This mindset change is crucial for flexible planning.
Shorten Planning Horizons: Instead of annual plans, consider quarterly or even monthly planning cycles.
Embrace Uncertainty: Teach your team that it’s okay not to have all the answers upfront. Uncertainty is a normal part of software development.
Communicating this change to stakeholders is crucial. Here’s how to manage expectations:
Be Transparent: Explain the reasons for the change. Share both the potential benefits and the challenges you anticipate.
Focus on Value Delivery: Show stakeholders how this approach will lead to faster value delivery and better alignment with business needs.
Use Visual Tools: Employ visual roadmaps or boards to show progress and plans. These can be easier for stakeholders to understand than traditional Gantt charts.
Regular Updates: Provide frequent updates on progress and changes. This helps stakeholders feel involved and informed.
Conclusion
Long-term roadmaps, while comforting, often fall short in the fast-paced world of software development. They can lead to wasted resources, missed opportunities, and products that don’t meet user needs.
Instead, embracing more flexible planning approaches allows teams to:
Respond quickly to changes in technology and market demands
Deliver value to users more frequently
Learn and improve continuously
Remember, change in software development is not just inevitable—it’s an opportunity. By adopting more adaptive planning methods, you position your team to seize new opportunities as they arise and create better products for your users.
Call to Action
As you finish reading this post, take a moment to reflect on your current planning processes. Are they truly serving your team and your users? Or are they holding you back?
Here’s what you can do right now:
Review Your Current Process: Identify areas where your planning might be too rigidly planning or disconnected from user needs.
Start a Conversation: Discuss these ideas with your team. Get their input on how you could make your planning more flexible.
Experiment: Choose one small aspect of your planning to make more adaptive. It could be as simple as adding a monthly check-in to reassess priorities.
Measure and Learn: Keep track of how these changes impact your team’s productivity and the value you deliver to users.
Remember, the goal isn’t to eliminate planning altogether, but to make it more responsive to the realities of software development. Start small, learn as you go, and gradually build a more adaptive, resilient planning process.
The future of your software development efforts—and possibly your entire business—may depend on your ability to plan flexibly and embrace change. Are you ready to take the first step?
In today’s fast-paced digital landscape, the way we approach software development is undergoing a significant transformation. As a product engineer with decades of experience in the field, I’ve witnessed firsthand the shift from traditional methodologies to a more dynamic, customer-centric approach. This blog post, the first in our series on Product Engineering, will explore this evolution and why it’s crucial for modern businesses to adapt.
The Changing Landscape of Software Development
Remember the days when software projects followed rigid, long-term plans? When we’d spend months mapping out every detail, stake holder meetings,d esign reviews for weeks architecting a massive new system, before writing a single line of code? Well it’s becoming increasingly clear that it’s no longer sufficient in our rapidly evolving digital world.
The reality is that by the time we finish implementing software based on these detailed plans, the world has often moved on. Our assumptions become outdated, and our solutions may no longer fit the problem at hand. As Mike Tyson says, “Everyone has a plan until they get punched in the mouth.” In software development, that punch often comes in the form of changing market conditions, disruptive technologies, or shifts in user behavior.
The Pitfalls of Traditional Methods
Let’s consider a real-world example. The finance industry has been turned on its head by small, agile fintech startups. Traditional banks, confident in their market position, initially dismissed these newcomers, thinking, “They aren’t stealing our core market.” But before they knew it, these startups were nibbling away at their core business. By the time the banks started planning their response, it was often too late – they were too slow to adapt.
PayPal and Square as examples revolutionized online and mobile payments. While banks were still relying on traditional credit card systems, these startups made it easy for individuals and small businesses to accept payments digitally. By the time banks caught up, PayPal had become a household name, processing over $936 billion in payments in 2020.
Robinhood as well disrupted the investment world by offering commission-free trades and fractional shares, making investing accessible to a new generation. Established brokerages were forced to eliminate trading fees to compete, significantly impacting their revenue models.
This scenario isn’t unique to finance. Across industries, we’re seeing that the old ways of developing software – with long planning cycles and rigid roadmaps – are becoming less effective. In fact, a staggering statistic reveals that 37% of software in large corporations is rarely or never used. Think about that for a moment. We constantly hear about the scarcity of engineering talent, yet more than a third of the software we produce doesn’t provide value. Clearly, something needs to change.
The Rise of Product Engineering
Enter product engineering – a approach that’s gaining traction among the most innovative companies in the world. But what sets apart companies like Spotify, Amazon, and Airbnb? Why do they consistently build software that we love to use?
The answer lies in their approach to product development. These companies understand a fundamental truth that Steve Jobs articulated so well: “A lot of times, people don’t know what they want until you show it to them.” And as far back as Henry Ford as well said, “If I had asked people what they wanted, they would have said faster horses.”
Product engineering isn’t about blindly following customer requests or building features that someone thinks people want. It’s about deeply understanding customer problems and innovating on their behalf. It’s about creating solutions that customers might not even realize they need – yet come to love.
The Need for a New Approach
In the traditional models many companies have built, engineers are often isolated from the product side of things. They’re told to focus solely on coding, “go code, do what you are good at”, protect this precious engineering resource, and don’t let them be disturbed by non-engineering things, with the assumption that someone else will worry about whether the product actually enhances the customer’s life or gets used at all.
This leads to what I call the “feature factory” – a system where engineers are fed requirements through tools like Jira, expected to churn out code, and measured solely on their ability to deliver features to specification. The dreaded term “pixel perfect” comes to mind. But this approach misses a crucial point: the true measure of our work isn’t in the features we ship, but in the value we create for our customers and our business.
Product engineering flips this model on its head. It brings engineers into the heart of the product development process, encouraging them to think deeply about the problems they’re solving and the impact of their work. It’s about creating cross-functional teams that are empowered to make decisions, experiment, and iterate quickly based on real-world feedback.
Looking Ahead
As we dive deeper into this series on Product Engineering, we’ll explore the specific skills, mindsets, and practices that define this approach. We’ll look at how to build empowered, cross-functional teams, how to make decisions in the face of uncertainty, and how to measure success in ways that truly matter.
The evolution of product engineering isn’t just a trend – it’s a necessary adaptation to the realities of modern software development. By embracing this approach, we can create better products, reduce waste, and ultimately deliver more value to our customers and our businesses.
Stay tuned for our next post, where we’ll dive deeper into what exactly makes a product engineering team tick.
What’s your experience with traditional software development versus more modern, product-focused approaches? Share your thoughts in the comments below!
As engineering leaders, one of our most critical responsibilities is effectively managing and developing our team’s performance. This goes beyond simply tracking metrics or conducting annual reviews. It’s about creating a culture of continuous improvement, open communication, and clear expectations. Let’s dive into some key aspects of performance management that can help you elevate your team’s effectiveness and job satisfaction.
The Art of Feedback
Feedback is the lifeblood of performance management. It should flow freely within your team, not just from manager to engineer. Many organizations offer training to help team members give and receive feedback effectively. As a manager, aim to provide feedback to your engineers at least biweekly. While technical feedback is important, don’t get too caught up in the technical details. Focus on broader aspects of performance and development.
A word of caution: be wary of feedback that’s overly positive or non-actionable. While positivity is great, feedback should always include areas for improvement or specific actions to maintain high performance. Remember, the goal is growth, not just praise.
Setting Behavior Expectations
When it comes to performance management, we often fall into the trap of creating “to-do” lists for promotion. However, what we’re really after is a change in mindset. We want our team members to be self-motivated, incorporating best practices into their daily work not because they’re chasing a promotion, but because it’s become part of their professional identity.
But how do we measure or change someone’s mindset? The truth is, we can’t directly measure it. However, the behaviors people exhibit serve as an excellent proxy. By setting expectations around day-to-day behaviors, especially in engineering-specific scenarios, we can create goals that foster the mindset we’re after.
This approach is inspired by Ben Horowitz’s famous “Good PM, Bad PM” blog post, which applied similar principles to product managers in the 90s and 00s. By focusing on behaviors rather than just outcomes, we create a culture of continuous improvement that becomes ingrained in daily routines.
The Power of Coaching
Effective coaching is a cornerstone of performance management and a critical skill for any engineering leader. It’s not just about solving problems for your team members; it’s about empowering them to solve problems themselves and grow in the process.
The Socratic Method: Questions as a Tool for Growth
One powerful approach to coaching is the Socratic method. Named after the classical Greek philosopher Socrates, this method involves asking probing questions to stimulate critical thinking and illuminate ideas. Instead of simply telling your team members what to do, ask questions that guide them to their own conclusions.
For example, if an engineer is struggling with a complex bug, instead of immediately offering a solution, you might ask:
“What have you tried so far?”
“Where do you think the problem might be originating?”
“What would be the impact if we approached it this way?”
This approach not only helps team members develop problem-solving skills but also increases their confidence and buy-in for the solutions they come up with. It transforms the coaching process from a one-way directive into a collaborative exploration.
The Importance of Explicit Language
Explicit Language isn’t about swearing, but on rare occasions that helps, but that’s a topic for another post.
When coaching, the clarity of your communication is paramount. Use explicit language to ensure your message is understood clearly. Be specific about what you’re observing, what needs to change, and what success looks like. Vague feedback or instructions can lead to confusion and frustration.
For instance, instead of saying “Your code needs improvement,” you might say “I noticed that the function on line 57 is handling multiple responsibilities. Let’s discuss how we can refactor this to improve its single responsibility and readability.”
Coaching for Technical and Soft Skills
While technical skills are crucial in engineering, don’t neglect coaching on soft skills. Leadership, communication, and collaboration are equally important for career growth. Help your team members identify areas for improvement in both technical and soft skills, and provide targeted coaching or resources for each.
The Continuous Nature of Coaching
Remember that coaching is not a one-time event, but a continuous process. Make it a regular part of your interactions with your team. This could be through scheduled one-on-one sessions, impromptu conversations, or even in the context of code reviews or project discussions.
By embracing the power of coaching, you’re not just solving immediate problems; you’re building a team of self-sufficient, confident engineers who are equipped to handle future challenges. This approach to leadership can dramatically improve team performance, job satisfaction, and overall success in your engineering organization.
Career Development: A Collaborative Effort
Career development should be a collaborative process between you and your team members. Start by creating individual development plans, or getting them to create them scales more and will have more meaning for them. These should be breathing documents that outline goals, areas for improvement, and action steps.
As a manager, it’s your job to provide opportunities for training and upskilling. Remember, you won’t always be the one who can directly train your team members. Most of the time, your role will be to identify and facilitate learning opportunities, whether that’s through courses, conferences, or mentorship programs.
Both you and your team members should have a clear understanding of what’s needed to reach the next level. An exceptional manager has a good sense of when all of their direct reports will be ready for their next promotion. This foresight allows you to provide targeted development opportunities and set realistic expectations.
Conclusion
Effective performance management is about more than just evaluating work. It’s about creating an environment where feedback flows freely, expectations are clear, and everyone is committed to continuous improvement. By focusing on behaviors, providing regular feedback, coaching effectively, and collaboratively planning career development, you can create a high-performing team that’s not just productive, but also engaged and satisfied in their work.
Remember, the goal of performance management isn’t just to improve output—it’s to help each team member grow, both professionally and personally. When done right, it’s a powerful tool for building an engineering team.
Welcome to our comprehensive series on the art and science of building exceptional engineering teams. As we embark on this journey together, let’s start with a fundamental question that lies at the heart of engineering leadership:
“What is the job of an Engineering Manager?”
If you were to ask me this question, my answer would be simple yet profound: “Building Awesome Teams.”
This straightforward statement encapsulates the essence of engineering management, a role that extends beyond technical oversight or project management. Building awesome teams is a continuous process that begins the moment you start hiring and continues through every stage of an engineer’s journey with your team, right up to and including the point when they move on to new challenges.
Tech: A People Problem in Disguise
One of the most crucial insights that any engineering leader can gain is this: Tech is, first and foremost, a people problem. The sooner you realize this truth, the sooner you’ll start winning at tech.
Yes, we work with complex systems, intricate code, and cutting-edge technologies. But at the end of the day, it’s people who write the code, design the systems, and push the boundaries of what’s possible. It’s people who collaborate, innovate, and turn ideas into reality. And it’s people who can make or break a project, a product, or even an entire company.
Exploring the Art of Team Building
In this series, we’ll dive deep into all aspects of building awesome teams. We’ll cover topics such as:
Hiring: How to attract, identify, and onboard the right talent for your team.
Performance Management: Strategies for nurturing growth, providing feedback, and helping your team members excel.
Execution: Techniques for forming effective teams, collaborating across departments, and delivering results.
Managing Exits: How to handle both voluntary and involuntary departures in a way that respects individuals and maintains team morale.
Each of these topics is crucial in its own right, but they also interlink and influence each other. By mastering these areas, you’ll be well on your way to building and maintaining truly awesome teams.
Why This Matters
In the fast-paced world of technology, having a high-performing team isn’t just a nice-to-have—it’s a necessity. They’re better equipped to solve complex problems, adapt to changing circumstances, and deliver value to your organization and its customers.
Moreover, awesome teams create a positive feedback loop. They attract more great talent, inspire each other to greater heights, and create an environment where everyone can do their best work. As an engineering manager, there’s no greater satisfaction than seeing your team thrive and achieve things they never thought possible.
Join Us on This Journey
Whether you’re a seasoned engineering leader or just starting your management journey, this series has something for you. We’ll blend theoretical insights with practical advice, drawing on real-world experiences and best practices from the field.
So, are you ready to dive in and start building awesome teams? Let’s begin this exciting journey together!
Stay tuned for our first installment in the series
I ran a survey recently with my engineers about their pain points. The number one pain point was too many meetings. This is a common complaint with teams that do Scrum, but our Scrum is pretty lightweight, so I started to dig a bit further – “go see.”
I sat down with a few of my engineers and, after confirming they agreed that they have too many meetings, I bluntly said to them, “Show me your calendar.” As I suspected, in all cases, it was pretty sparse, except for one of my tech leads, which I understood. What I did notice, though, is that they had meetings mid-morning and mid-afternoon consistently.
So my hypothesis was: it’s not that they have too many meetings; it’s that they get interrupted and don’t have long periods of focus to work. Working as an engineer before, I understand this. You need a good few uninterrupted hours every day to get into your zone and get stuff done.
I’ve had to deal with this before (as I said, it’s a common complaint in Scrum) and also have colleagues that have as well. Based on past experience, I was able to put together something that we tried. It starts off a bit draconian, but I think you have to because people always bend the rules. So here’s the guidance we came up with:
Practices around Meetings
Please observe the following practices around meetings to enhance productivity and maintain focus.
No Meetings after Lunch
Engineers need at least 2-3 uninterrupted hours straight each day, more if possible. This uninterrupted time is crucial for deep work and maintaining a flow state, which becomes essential for problem-solving and creativity in engineering tasks. According to Cal Newport, author of “Deep Work,” uninterrupted work periods significantly enhance productivity and job satisfaction.
While this may be challenging on sprint planning days, consider making one day per sprint an exception to this rule for sprint ceremonies. Getting other teams into this habit might also be difficult, but targeting one director area at a time can make it more manageable. Here are some tips to deal with it.
Alternative: If morning meetings are challenging, consider scheduling additional meetings at 5 pm to ensure uninterrupted work periods during the day until at least 5 pm.
Default Meeting Time is 30 Minutes
Avoid scheduling 1+ hour meetings at all costs, unless absolutely necessary. Shorter meetings encourage people to arrive on time and be efficient. It also pushes attendees to get to the point quickly and wrap up discussions promptly. Parkinson’s Law states that work expands to fill the time available for its completion. Therefore, shorter meetings can help in focusing discussions and give more time back to attendees.
Tip: If a meeting finishes early, LEAVE, rather than extending discussions unnecessarily.
Review the Purpose of Each Meeting
Assess the necessity of every meeting. If the meeting’s purpose can be achieved via an email or a Slack chat, do this instead. This helps reduce the number of unnecessary meetings and allows more time for focused work.
Tip: Establish clear agendas and goals for meetings to determine if they are truly necessary.
Combine Meetings with the Same Attendees
If you have two meetings that require the same people, schedule them back-to-back in the same room. This approach not only ensures everyone is on time for the second meeting, but if the first meeting ends early, you can start the second one earlier, and potentially give people back more free time.
Supporting Information and Citations Newport, C. (2016). Deep Work: Rules for Focused Success in a Distracted World. Grand Central Publishing. Parkinson, C. N. (1955). Parkinson’s Law. The Economist. Harvard Business Review. (2017). Stop the Meeting Madness. Retrieved from Harvard Business Review.
[Previous content remains unchanged]
Conclusion
Implementing these meeting practices can significantly improve team productivity and engineer satisfaction. By prioritizing uninterrupted work time, keeping meetings focused and efficient, and critically evaluating the necessity of each meeting, we can create an environment that fosters deep work and creativity.
Remember, the goal is not to eliminate meetings entirely, but to make them more purposeful and less disruptive to the flow of work. As we adopt these practices, we should:
Regularly check in with the team to assess the impact of these changes
Be flexible and willing to adjust the practices as needed
Lead by example, adhering to these guidelines ourselves
It’s important to recognize that changing ingrained habits takes time and persistence. There may be initial resistance or challenges, especially when coordinating with other teams or departments. However, the potential benefits – increased productivity, improved job satisfaction, and higher quality work – make this effort worthwhile.
By fostering a culture that values focused work time and efficient communication, we can help our engineers thrive and deliver their best work. Let’s view this as an ongoing process of optimization, always seeking ways to improve our work environment and practices.
This is a process I’ve tried a few times over the years and wanted to share, its great for teaching your team to teach themselves about common problems and blockers they have, and also getting them to understand how to work better as a team rather than a group of individuals.
This is how it goes:
Take a medium-sized story, put the team in a room, and get them to try to do it in a single day working together. Most of the time they will fail, but they’ll learn.
This helps answer the question, why can’t we get a story done in a short period of time?
Why is this important? During a two-week sprint, sometimes you have to wait for things, so you wait and go work on something else, and it doesn’t matter because you have a full 2 weeks, right? You don’t notice or try to fix these things. These things slow you down, examples are:
The flaky CI that you rerun a few times and 6 hours later it’s ready.
The code review ping pong that goes for 6 days.
The multiple systems that need to merge/deploy in order because for 1 story you need to change 3 systems.
The systems that take a whole day to get working on your laptop because you haven’t touched them in a month.
On top of finding the problems, the team also learns how to collaborate on a single story. This helps with not only faster delivery but also sharing of knowledge within the team.
This is good if you see this type of behaviour in your team:
At the start of the sprint, each dev picks up a single story and works in isolation
Standup meetings seem unimportant because everyone is working on different things
During the day your team is not talking; in office situations, they may put headphones on and ignore the rest of the team for the whole day
When questioned, you consistently get feedback “we can’t get more than one person working on this”, which usually means they’ve never tried
Note: It’s ok for devs to do short periods in isolation, they should not be “pairing all day” as some extreme companies encourage, but an entire day or more is a warning sign.
Expanded Process
1. Pre-exercise briefing (if it’s the first time) – Set expectations and explain the purpose. – Get buy-in from the team; if they don’t believe it’s a good idea, they will make it fail.
2. Story Selection: – Team agrees on a medium-sized story that would typically take several days to complete. – The story should be challenging but potentially achievable. – Choose a number of man-days similar to the people in the team if you use man-day estimation.
3. Team Composition: – Ensure the team has diverse skills to cover all aspects of the story. – Possibly including people that are needed for code review approval, deployment, etc.
4. Environment Setup: – Prepare a dedicated workspace where the team can work without interruptions. – Book a large meeting room. – Set up Pairing Stations for a day.
5. The Day:
– Set a strict one-day time limit, e.g., 8 hours. – Begin with a brief planning session to break down the story into tasks, 30min time box. – Execute, encourage pairing, and regular communication, time box 7 hours. – Call it on time, tell the devs “hands/pens/keyboards down”, at the end of the day, the goal is to learn rather than finish, don’t let them work into the evening, even if they want to. You need time for retro. – Conclude with a team retrospective to discuss learnings, challenges, and insights, 30min time box. This is the most important part, they can run overtime on this 🙂
Implementation Notes:
1. Frequency: Implement this approach periodically, not as a daily practice. 2. Follow-up: Use insights gained to improve regular work processes. 3. Balance: Combine with other agile practices for a well-rounded approach.
beerandserversdontmix 