Working with Coders — reflections a decade later

Working with Coders by Patrick Gleeson (2017) primarily aimed at non-engineers to help them understand how to collaborate more effectively with technical teams.

So why revisit this book now?

I’ve spent the last 20+ years working as a developer/engineer and, more recently, as an engineering manager. Over time, one pattern has become clear: the success or failure of software initiatives is not determined by technical complexity alone. More often, it comes down to communication, expectations, and alignment between technical and non-technical stakeholders.

That’s precisely the space this book tries to address.

At first glance, a book written nearly a decade ago might feel outdated in an industry that reinvents itself every few years. But interestingly, many of the core tensions it describes—misaligned expectations, oversimplified analogies, and the gap between “what is asked” and “what is needed”—are still very much present today.

There’s also a personal connection: I used to work with the author’s sister, who transitioned into the profession from a non-computer science background. She consistently demonstrated how effective collaboration doesn’t require deep technical expertise, but rather clarity of thought, curiosity, and respect for the craft. Her recommendation of this book reinforces its intent: bridging the gap between technical and non-technical worlds.

I’m using it as a baseline to help operational and business stakeholders better understand how software is actually built—and why it often behaves in unintuitive ways.

Main takeaways

1. The test of time

Despite being written in 2017, the book holds up well because it focuses on fundamentals rather than trends. Frameworks, tools, and methodologies evolve, but the human dynamics around software development change much more slowly.

Many of the issues described—unclear goals, shifting requirements, and miscommunication—are not artefacts of a specific era; they are structural characteristics of building software.

2. Building a house isn’t writing software

A core argument is that software development is often compared to construction—and that this analogy breaks down quickly.

In construction, you define the blueprint and execute. In software, building the system is often how you discover the real requirements.

This leads to familiar failure modes:

• Objectives are unclear or overly optimistic

• Requirements are over-specified in the wrong places

• Stakeholders only understand what they need after seeing something working

• Existing systems and sunk costs constrain decisions

In practice, the issue is rarely lack of knowledge—it’s premature certainty.

Estimates then get converted into commitments, and that’s where things start to unravel.

3. User feedback: when reality corrects intent

Every project hits the same moment: users interact with the system and realise that what they asked for is not what they actually need.

This is not a failure—it’s part of the process.

The challenge is managing expectations:

• Software operates in context, not isolation

• Unknowns will surface, often late

• Early versions should be treated as learning tools

Estimates should support decisions, not act as promises. They help answer:

Is it worth building this now, or investing somewhere else?

4. Fragility vs anti-fragility in development

Software systems—and the processes around them—can be:

• Fragile (break under change)

• Robust (resist change)

• Anti-fragile (improve through change)

Many teams unintentionally operate in fragile setups while aiming for robustness.

There’s also a useful distinction between:

• agile as a mindset

• Agile as a framework

Some implementations of Agile introduce rigidity rather than flexibility. Scrum, for instance, works well in constrained environments but can become mechanical.

In software, effectiveness matters more than efficiency. Optimising too early assumes we already know the right thing to build.

5. Estimates as negotiation tools, not predictions

Estimates are frequently misunderstood.

They are not:

• Deadlines

• Commitments

• Performance metrics

They are inputs for trade-offs:

• Scope vs time

• Quality vs cost

• Speed vs maintainability

When used properly, estimates enable alignment. When misused, they create tension between teams and stakeholders.

6. The illusion of visibility

From the outside, software looks simpler than it is.

Stakeholders typically see:

• A working demo

• A clean interface

• A successful use case

They don’t see:

• Integration complexity

• Edge cases

• Operational risk

• Long-term maintenance

This creates a perception gap.

Bridging that gap is less about explaining technical details and more about translating into impact:

• What happens when this fails?

• What’s the customer impact?

• What are we trading off?

This is especially relevant when influencing decisions without relying purely on authority.

7. Tools shape behaviour more than we admit

A practical observation: tools often define how teams work.

For example:

• Using JIRA tends to push teams toward Scrum-like workflows

• Alternative approaches become harder to express

• The tool subtly enforces structure

This can be useful for consistency, but also limiting.

Over time, teams risk optimising for what the tool makes easy, rather than what the problem requires.

Closing thought

The enduring value of Working with Coders is not in prescribing a methodology, but in highlighting a gap: software development is as much about people, expectations, and communication as it is about code.

A decade later, that gap still exists—and if anything, it’s visible with AI or not. Thanks again Patrick for the great book!

Between March 2024 and early 2025, I worked at Henry Schein One, using the Shape Up process developed by 37signals. It’s not just another prescriptive variation of Scrum. It’s closer to a product framework—a way to help teams commit to meaningful work using fixed time and variable scope. That blend creates a dynamic rhythm: enough structure to stay focused, enough flexibility to stay sane.

In January 2025, I gave a talk at the London Ruby User Group about how the team was using Shape Up, adapting its principles to a different scale of stakeholders. We covered the basics: shaping, cycles, bets, delivery—and the awkward-but-useful bits we’ve had to tweak for a larger, more distributed team navigating multiple, often conflicting requirements.

After the talk, we opened up for discussion, and that’s when Ed asked something simple—but sticky:

“What needs to be true for leadership to trust a team?”

The Way We Work Shapes the Trust We Get

Trust isn’t granted just because we ask for it—no matter how impressive the CV, or how strong the results we’ve delivered elsewhere. Trust is granted when the way we work makes sense to those putting their confidence in us. And it’s developed over time, as we keep the system moving in the right direction. As Peter Drucker put it, “What creates trust, what enables you to get the task done, is when ‘we’ gets the credit.” That kind of trust isn’t portable. The track record that earns it has to be built inside the company, in context, with the team that’s actually doing the work.

That’s where culture—the way we work—comes in. Culture tells a story, whether we mean it to or not. When we commit to fixed time and variable scope, as Shape Up encourages, we’re making a statement: that we value finishing something meaningful over juggling many things at once. We aim to define constraints we can actually honour, rather than setting deadlines we’ll quietly miss. It shows leadership that we’re not optimising for appearances—we’re building momentum through delivery.

One of the most powerful cultural cues is the habit of fast-forwarding scope conversations—the ones that usually get awkward at the end of the cycle, especially when things haven’t gone to plan. Instead of waiting for pressure to pile up mid-delivery, we bring those hard trade-offs into the shaping process. Can we actually ship something valuable—and validate it—in six weeks? What’s the riskiest part of this idea? What will we drop if things get complicated? These aren’t fun questions, but answering them early signals that we’re being realistic, not naive. It strips away the “hope for the best” or “code and pray” mindset that tends to collapse under deadline pressure.

Another cue is scope discipline—sticking to what we shaped, even when we’re ahead of schedule. It’s easy to drift mid-cycle, to add “just one more thing here and there,” or to let sunk costs justify doubling down on complexity. But as a team, we’ve had to learn to keep our commitments smaller, clearer, and more public to build credibility.

When we say, “This is what we’re aiming to deliver,” and then we actually deliver it, trust compounds. And when we don’t hit the target, being able to show what changed and why matters just as much. It’s not just about hitting goals—it’s about consistency, and clarity on what we’re not doing (at least not yet).

All of these cues—front-loading scope conversations, sticking to shaped work, making clear and visible commitments—do more than help us deliver. They tell a story. A story of realism over optimism, alignment over noise, and clarity over chaos. They reduce the need for control because they reduce the chance of surprise. And that’s really what trust needs: not heroic effort, but steady, transparent progress.

Visible Behaviour Builds Trust — Not Vibes

Trust isn’t a feeling we try to create—it’s a conclusion someone else reaches based on what they can observe, what is visible and clear to them. That’s why visible behaviour matters. It’s not about energy, optimism, or “good intentions”—it’s about what leadership actually sees: how we make decisions, how we handle complexity, how we respond when things go sideways. The work speaks louder only if we help it speak—by presenting it clearly to our team, our stakeholders, and the wider organisation.

One of the clearest signals is how we commit. Not just what we plan to deliver, but how we frame it, how we revisit it, and how we talk about trade-offs. Leadership doesn’t just notice if we finish or not—they notice how we handle being wrong, how we adapt, and whether we stay anchored to the original appetite. When we treat scope, appetite, and deadlines as shared agreements—not personal promises—it becomes easier to adjust without spinning. That kind of calm, structured adaptability is easy to trust.

Another visible behaviour is how we talk about risk and uncertainty. If everything always sounds fine, trust erodes quietly—because people know it rarely is. What builds trust is being able to say: here’s what we don’t know yet, here’s where things might break, here’s the bit we’re still figuring out. The goal isn’t to dramatise—it’s to show we’re thinking ahead, not hiding behind confidence. We need to be careful not to sell guarantees. Pre-mortems are a good tool here—simple, honest, and focused on helping the team think about failure before it becomes real.

These behaviours aren’t fancy. They’re not performative. They’re small, visible signals: how we commit, how we talk about risk, how we shape scope and share progress. They’re what people actually see—and that’s what leadership responds to. No amount of energy, team spirit, or well-crafted dashboards will compensate for an absence of clear, grounded behaviours. If we want to be trusted, we have to work in ways that make trust visible.

What Happens in High-Trust / High-Commit Environments

High-trust, high-commit environments feel different. There’s more energy—but less noise. There’s space to speak up, and also space to focus. It starts with psychological safety: the ability to speak honestly, raise concerns, and admit uncertainty without fear of punishment. In these environments, people don’t hide mistakes or opinions—they surface them, because they know the team can handle discomfort without breaking. That safety becomes the base layer for everything else.

Next comes clarity of direction and responsibility. Teams aren’t just asked to execute—they’re trusted to choose, to shape, and to take responsibility for the outcome. That only works when the “why” behind the work is clear. When objectives are meaningful and priorities don’t shift randomly, autonomy becomes productive—not chaotic. Trust and commitment feed each other.

Then comes momentum. When people feel trusted, they move faster—because they’re not waiting for permission or second-guessing every step. Progress is steady because the process is stable. The focus isn’t just on getting more done, but on doing the right things well and finishing what was started. Delivery becomes less about velocity and more about flow.

Finally, there’s space for emotion—celebration and mourning. Celebrating delivery, even in small ways, reinforces shared progress. Mourning failed bets or missed goals—without shame—helps teams process and reset. That emotional honesty is part of the deal. In high-trust teams, outcomes matter, but people matter too.

In Trust, Leadership Has to Go First: A Team Doesn’t Earn What It’s Never Given

It’s almost impossible to earn trust in an environment where none is offered. Teams can do everything “right”—shape well, commit carefully, communicate clearly—but if leadership never takes the first step, the system stalls. Trust isn’t a transaction, it’s a gesture. Someone has to go first. That someone, more often than not, has to be leadership.

You can feel when you’re being given a real shot. Not blind faith, not abandonment—but space. Space to try, to reason through trade-offs, to deliver something meaningful without being constantly second-guessed. When a team receives trust, their first instinct is often to be cautious: are we really allowed to do this? Will it come back to bite us? That hesitation is natural. The answer comes not in words, but in the follow-through. A bet placed. A cycle left alone. A hard problem left in our hands.

The phrase we’ve used internally is: we give you a try. It’s small, but powerful. It says, “We see you. We know this might not go perfectly. But we believe it’s better to let you run than to keep you boxed in.” Of course, this doesn’t mean blind delegation. It means informed trust—a trust that comes with support, context, and the willingness to listen if things wobble. Without that, we’re just pretending.

Trying to deliver without any backup—without access, feedback, leadership clarity—is a futile effort. It drains momentum and erodes morale. Teams end up delivering to stay safe, not to create impact. That’s why leadership trust isn’t a reward for perfect execution—it’s the starting condition that makes good execution possible in the first place.

Redesigning software can be essential, yet it demands considerable resources, affecting timelines, budgets, and team focus. Back 10 years ago, our CSS migration revealed how such projects, though aimed at long-term improvement, also introduce immediate complexities.

• Time and money costs: The redesign required more developer time and attention than anticipated, stretching over several months and forcing us to defer other projects. Unexpected resource drains like this affect team productivity and may lead to postponing marketable new features that real customers are waiting.

• Risk of Introducing New Bugs: Switching to SASS brought unforeseen integration issues. For example, users on the Product Detail Page (PDP) encountered colour-switching bugs due to CSS dependencies not accounted for in the SASS setup. This instability spread across the site, turning small fixes into major debugging sessions. Tackling these bugs became a recurring and time-intensive challenge, revealing the unpredictable and often hidden interdependencies within the codebase that redesigns can uncover.

  

Our Journey Through Challenges

While we aimed to improve efficiency, moving to SASS impacted other previously stable components. We found that styles we assumed to be isolated were actually interdependent, causing more errors. Delays piled up, and halfway through, it was clear our original timelines were optimistic. However, the team stayed dedicated, working professionally to push forward, despite the increased pressure.

The Initial Expectations

We saw that LESS was getting stale, most of the community of developers using pre-processors were moving to SASS/SCSS. We thought are UI “iceberg” was melting as the book from Kotler would describe in Our Iceberg is Melting. We were scared and we needed to bring change, assuming we need it right away. We started with the team’s initial vision and assumptions going into the redesign of the UI experience for internal development and partners that would love our new code. We discussed with senior leadership how to make it have, provided expectations about timelines, team allocation and prepared sessions to identify complexity. We identified the Product detail page (aka PDP) as the most important part to modernise with high customer impact once delivered to encourage teams to extend and customise the eCommerce solution.

Unforeseen Interdependencies

Switching to SASS brought unforeseen integration issues in the PDP, that was contained in the overall structure of the page.

In addition to that we discovered multiple CSS interdependencies that weren't apparent initially, complicating the project more than anticipated. As we transitioned from LESS to SASS, styles that seemed isolated began affecting each other in unexpected ways. Global styles from the LESS setup conflicted with new SASS styles, creating issues like unintended layout shifts and visual bugs. For example, the Product Detail Page (PDP) relied on a stable global style for color-switching functionality, but the SASS migration unintentionally broke this interaction, leading to a frustrating user experience.

These cascading dependencies highlighted the risks of working in a tightly coupled system where changes in one area impact seemingly unrelated sections. Small changes in one module or component triggered changes across the project, leading to a cycle of bug-fixing and retesting. This experience underscored the need to map dependencies more thoroughly before undertaking redesigns and the importance of isolating styles to prevent similar leaks in future projects.

Escalating Delays and Project Pressure

As the project unfolded, delays in the cycle of release of isolate SASS began to compound. Every new bug or styling conflict required additional debugging, which added days. What initially seemed like a manageable redesign spiralled into a series of setbacks. Each delay affected timelines for other features and normal bugs to be fixed, putting pressure on team members and forcing us to slow down in the migration to stay put to other important tasks.

The mounting timeline began impacting team morale as well. With each delay, the pressure to deliver a stable redesign increased, especially as some feature releases were postponed. This created a cycle where team members felt pulled in many directions, what is more important to fix a bug in the current PDP or try to prevent it to happen in the new one? Additionally, the partners couldn’t use the new PDP without upgrading the existing projects adding external pressure to the release cycle.

Reflecting on this experience, we recognised the importance of building flexible timelines for future redesigns, accounting for the possibility of complex dependencies and bringing together the partners that were customising the existing features

Resilience and Team Spirit

Throughout the project, the team faced pressures and frustrations as they dealt with unexpected bugs and delays in the timeline. Despite these challenges, team members showed resilience and professionalism, remaining dedicated to completing their work and asking for help across the department. One strategy that helped sustain morale was regular, open communication; frequent check-ins, in person at the time, allowed team members to voice concerns, celebrate small wins, and stay aligned on progress. This approach fostered a supportive environment where everyone felt heard and valued despite the difficulties.

To maintain productivity under stress, we also broke down large tasks into smaller, manageable releasable goals, allowing the team to experience a sense of achievement and progress. We would reprioritise bugs as needed to keep the focus and retrospect every two weeks to identify improvements in the process. When setbacks occurred, we focused on solutions rather than placing blame, reinforcing a collaborative atmosphere that empowered team members to tackle problems creatively and maintain a positive outlook.

In reflection, these strategies not only kept morale steady but also strengthened team cohesion, helping us navigate the project’s challenges more effectively.

Key lessons learned

• Remember that redesigns have high costs, like our LESS to SASS migration are resource-heavy, requiring more time and focus than expected, and often defer other projects, delaying new feature development.

• Scout for hidden interdependencies: dependencies can surface unexpectedly, creating bugs and complex issues across the system. Mapping dependencies and isolating styles is critical for smoother redesigns.

• Have clear principles to define flexible timelines and trade-offs: anticipate setbacks by building in time buffers and prioritise what’s essential, allowing for complex dependencies and maintaining flexibility.

• Commit to team resilience: Regular communication, solution-focused retrospectives, and manageable goals help maintain morale, productivity, and cohesion, even under pressure.

At the end of the day, as Bernández once wrote in Para recobrar lo recobrado (to recover what has been recovered), one becomes "more luminous" after hardship, as both joy and sorrow shape a richer experience of life in the same way the tree bears fruit from what’s rooted beneth.

As we navigate the journey towards career-improvement, it's essential to reflect on the progress made, the challenges we faced and setbacks we had. 

Every step forward in our career involves adapting to reality and recalibrating tactics and strategies. This adaptation is not just about withstanding the blows but about embracing the quality of the outcomes our efforts yield. 

It's about recognizing both the high-value work and the necessary downtime or healing time, ensuring we remain effective without burning out.

Don't bend the spoon, think in adversity

"The Matrix" tells the story of Neo, played by Keanu Reeves, a computer hacker who discovers that his perceived reality is merely a façade and that he is the prophesied hero destined to lead the fight against the machines. 

Before meeting The Oracle, Neo is in a waiting room filled with other potential saviours. There, he meets a young boy resembling a monk, who is bending a spoon with his mind, right away Neo tries but fails to bend the spoon. To 

Neo's surprise the boy advises: "Do not try and bend the spoon—that's impossible. Instead, only try to realise the truth... there is no spoon. Then you will see that it is not the spoon that bends; it is only yourself." Inspired by these words, Neo momentarily succeeds in bending the spoon himself.

Viewing obstacles through different lenses can transform your perception of challenges, much like the metaphor of bending spoons in "The Matrix"—it’s about realising there’s no spoon, there’s no unchangeable reality. 

This mindset encourages innovative thinking: if we can't find a way, we’re pushed to create one. Yet, amidst this relentless pursuit, it's crucial not to dwell in the 'anger mode' where frustration hinders growth. Instead, channelling that energy into constructive problem-solving can lead to breakthroughs even in scenarios that seem laden with suffering and scarcity (or unbending spoons).

There are no spoons, are we afraid of dinosaurs?

Can we be afraid of dinosaurs since they no longer roam the Earth? The fear of dinosaurs, though seemingly far-fetched, serves as a metaphor for distinguishing between real and imaginary fears in our work. 

Just as it's irrational to fear these extinct creatures, we often find ourselves anxious about scenarios that exist only in our imagination: are they actually going to lay us off? Am I doing well enough? 

What makes a difference between a dino-fear and a real one is the information we have available to support or not the threat. However the feeling is similar, we feel fear of what could happen to us.

This realisation helps us to prioritise our information gathering and focus on the actual challenges that require our attention and resources. By understanding the needs behind our fears we can better manage our reactions and maintain a clearer perspective especially in a professional context.

Self-compassion, the possible answer

Self-compassion is a vital companion on this journey of finding meaning in anger and fear. We can acknowledge the pain and setbacks we had in the past without letting them define our future. It is like setting up a tent to but not building a permanent residence in our discomfort, we visualise the pain and choose not to live in suffering. 

Reflecting on whether the pain serves a purpose helped me shift the perspective on the matter, particularly when it’s a company/market decision that I cannot do anything about. 

Compassion reminds me that "I’m still a fallible human being" as professor Dr. Windy Dryden, therapist and author who wrote `Ten Steps to Positive Living` among other books. 

Self-compassion helps us distinguish between useful and needless suffering. Mourning and being at peace with these setbacks pave the way for professional development. This allows us to acknowledge our limitations without letting them define our future, thus paving the way for significant professional growth.

By reflecting on our challenges, we can transform our perception, gather information more effectively and find new ways to problem-solve them.

"Image of office worker thinking in dinos" Generated by OpenAI's DALL-E, 06/05/24.

"Image Neo from the Matrix" Generated by OpenAI's DALL-E, 06/05/24.

Many companies nowadays plan quarterly OKRs or biannual big releases, they may be releasing software everyday, several times a day, but they don't do big marketing efforts of new product features or deals every day, they tend to cluster advancements to make it easier for the public to grasp and adopt, what we call general availability.

This doesn't mean that at the beginning of the work of these quarterly/annual projects all the work is apparently known and dependencies are mapped upfront.

There's more than one approach to plan and sequence work. A lot of "professional" project managers refer to the PMBok as the guiding definition of what sequencing activities are, Gantt charts and estimates come into play. On the other hand, Basecamp and others propose to have focus cycles of a few weeks, where the target is one interesting bet and we keep working on it during the cycle. This short project is evaluated at the end of the cycle and maybe iterated.

Enter probalistic forecasting

The book by Mattia and Chris on team metrics for business decisions is worth reading, if you want to visualise forecasts before reading the book make a copy as I did of their spreadsheets and input the number of stories, days of work or similar to get a taste of the approach. Use whatever you use to measure the actual work not the estimates.

We are not trying to set on stone all the constraints at the same time, but to isolate the problems and try to answer:

How long will it take to complete? This is a look-ahead indicator, assuming the pace of work is maintained, how much would it take to end. In this example, the project would take some additional sprints but we don’t put a date set in stone, similarly as we would do with older techniques such as PERT.

In this example the project will finish by the tenth' sprint, looking from the sprint 6. A sprint is a timebox where you count finished stories.

Tweaking parameters

If we discover stories and bugs faster than we fix/close them, we are not going to finish the project at all. It’s important to review why we keep finding new stories to do or what root causes of tech debt cause our bugs to resurface.

Dealing with perceptions

Forecasting helps us to deal with our past perception whenever we review the plan. To me the most dangerous perception of all is the perception of being late/failing a level of produce set in stone at the beginning of the project.

It demotivates the team implying you're never going to reach the target, which we set without elementts at the begining. Also it can give us a false idea that we have time to procrastinate.

Exit criteria

As important as keeping ourselves focus, we need to be clear when to cancel the project. It can become a drain of energy and money to keep prolonguing the project without enough feedback on our metrics. ShapeUp proposes a rather intense clean cut on the cycles to avoid projects growing too big without enough traction.

We need to ask ourselves what happens if we are later than X? What are the consequences and trade-offs. This is better to discuss in a pre-mortem of the project to make sure we know if the project is alive or dead when executing it.

One of the typical questions when planning is around what to do first want to do next and so on and it's important to have the principles there to make some decisions. These principles work best when set around the metrics we want to influence.

To organise the agenda

Google Calendar: comparing my working calendar from the end of 2021 with the one of 2022, now I’m able to allocate my time explicitly. I’ve tried a couple of other tools, including Calendly, with scarce results. The cherry on top of the cake: Google calendar’s labels help me to keep an eye on the type of meetings I’m in. This way, I don’t switch contexts too much during the day and I put consistent meetings for myself with agendas upfront (meetings that other people call “focus time”).

As a whiteboard

At work I started to use Miro more extensively to map processes and as a whiteboard to understand problems. It’s very easy to create post-its and move them around, less handy with integrations yet. Helps me a lot to visualise ideas instead of writing them. Would be interesting if the integrations with other tools were better to move data in and out.

Getting a job

An unusual tool I used for job-hunting was Streak, a CRM tool that helps you track emails with labels. It was useful to keep in touch with so many recruiters and companies. I reached out to more than 30 companies to secure a new job in August when Pollen went into administration, leaving unpaid salaries and shocking debts. Overall, I’m quite satisfied with my work and personal inbox (less than 20 read emails sitting there) but it was challenging to keep up with linkedin and email. I managed at the end to keep a document for each prospective company and Streak did the trick to organise the emails and progressions in the “sales” pipeline.

Writing better

Another baby step of productivity was switching from a custom Gatsby JS static site hosted in Netlify to Substack with my own domain. The pipeline wasn’t complex but it was an overkill. Now I don’t waste any time installing npm packages or other trivial tasks. The UX is not as great as it could be but it’s readable, I can see how many people read what I write and it's easy to copy/paste to Linkedin. However I still use Google Docs to write and then paste into substack, the google docs corrections are great.

Reading better

Last but not least, there’s Libby, the app for reading ebooks or audiobooks from the local Merton library without needing to go to the library 😀. It helped me browse and even finish titles such as: “Languages are good for us“, re-read Agatha Christie’s “The thirteen problems”, “How do you teach philosophy to your dog”, Harry Potter and “Fooled by randomness”. Plus a lot of titles I didn’t get through the first ten pages 😛

Stuff that didn’t work as much

Notion: I haven’t buried the hatchet yet, I’m trying to use Google Docs as much as I can instead. I found the UI so boooring and clumsy at the same time, maybe a sign of my age 🤔

Budgeting and spending: I didn’t manage to improve my spreadsheet.

To sum up

Better tools, used more often, bring small improvements and avoid repetitive tasks becoming boring. I’m curious what tools 2023 will bring! Btw, Happy new year 🥂 !

Jobs don’t need to be particularly bad, but in tech companies usually it is easier to look around than bother too much above limitations of the context where one is. We (uhm… I?) tend to complain about the 20% that’s wrong in the job rather than appreciate the 80% that is good or OK.

Reading an HBR article on bosses it kept me pondering… What makes a boss bad and not just how technically competent a boss needs to be? The article is about retention and to a lesser extent productivity.

The article talks about 3 measurements:

• The boss seconding the employee

• The boss grew in the company

• The boss’ technical competence

Then it drives the conclusion that the employees’ job satisfaction, and therefore the retention problem, is correlated to the boss’ technical competency. I would say that the article is too shallow on understanding how it affects the relationship.

Given that I’m a boss I do have some experience on being a bad boss and a good boss, I’ll recap some of my experience.

A boss can do your job

For example, programming as good as the employees, less well or better than them. My rule of thumb is if you’re better at programming, you should aim to be a staff engineer, an specialised individual contributor. It may also mean that the boss can cover for you when you’re ill or on vacation to some extent. Unfortunately many companies don’t have a rewarding path for staff engineers.

I prefer the analogy of sports more, you as a manager need to ensure the athletes do their best and get the team results you’re looking after. You train with the players and when the player is not available the day of the match they almost always find a replacement player.

A competent boss is not an expert

As a boss you need respect to do your work properly; if you’re incompetent, people won’t trust you’re evaluating them fairly. However, a deep expertise in the employees’ core activities contradicts the idea of a generalist working with a plethora of skills to ensure things happen: organisation, connection, listening, followability, strategic thinking.

The technical expertise needs to be acknowledged, and in my experience it’s easier to see when you’re part of the furniture than when you aren’t. On the other hand, even if technical expertise buys you respect, it doesn’t buy you efficacy as a manager. You still need to prioritise, delegate, coach and hold people accountable which is a different set of skills than recursion or multi thread programming. Some ideas are transferable such as saying that people “talk to each other in TCP mode, you always need to establish a connection”.

As a manager, I always struggle to strike a balance between learning enough to understand what’s on the table and trying not to get too rusty on the basics.

Disliking the job

Again, it’s not the main reason to quit, all jobs have aspects we dislike to different extents. The fact that you dislike what you do can be bogged down with the lack of support, challenge or recognition from your boss. To make matters worse, a boss that doesn’t hear you or a boss that doesn’t understand has little use for sponsoring your career. Happiness may boost productivity, but the counter reciprocal is more important: unhappy employees can be problematic in too many ways so it’s safer to reduce deep unhappiness, particularly the one caused by chronic company issues rather than transient ones.

Changing the boss

It’s usually very hard to change the boss. It's a very unpleasant job to point out shortfalls to your boss, and more threatening to share that info with the boss’ boss. Moreover, your boss could be performing great in other areas. Last but not least companies also struggle to “I want to change team(s)/I want to change boss”

• The design system team makes the vision happen, that’s their primary mission.

• Even if I am not fond of cars, I learned that the lower part of cars (the platform as they call it) is a great example of design reused with different chassis and models. 

• "To thine own self be true" (be true to youself), it was the inscription at the top of the auditorium. It reminds me to try hard to be honest to oneself. It’s a quote from Shakespeare’s Hamlet (which I haven’t read)

• Empathy with your users pays-off. Spend more time continuously discovering what their pain points are and testing solutions, not validating them.

• Describe the steps to make your adoption process happen. The logistics of the design system. Getting buy-in from early users requires swet, blood, toil and tears. Do the hardest and most challenging components first including that ugly organism you rather not do.

• Life is too short to keep oneself overly busy, there's never enough time for doing important and meaningful experiences. 

• Naming things is easier than agreeing on how things are named, domain vs subdomain, message vs toast.

• Contributions to communities of practice are easier when included in the expectations of the actual roles.

What’s renting

So when you go to a coffee shop and buy a coffee cup in exchange for money, you become the sole owner of that coffee. You decide if you want to drink it after a few minutes of your time, if you add sugar (I wouldn’t).

Most of the time in the world, you don’t buy software. I repeat, we DON’T buy software, we merely buy licences to use software. That was the commercial geniuses of Microsoft when they licensed their software to be used in IBM computers.

This action is more similar to renting: you are able to be there, ahem use their service, as long as you agree to the terms of conditions of the landlords.

When to rent

In some cases the discussion, should I rent or not depends on how strategic and commoditised is the capability or component you need. A strategic component is one that you need to control 100% of the roadmap because it’s key to the success of your company and you are the expert to get value from it. That’s why Zalando controls most of the software they build for their website, because it’s a critical component. Meanwhile renting servers is something more commoditised, that’s why most of us can go to one cloud provider and rent our servers or lambdas there. It’s standard, has comparable competitors and has clear SLAs. Simon Wardley would call them utilities in his Wardley Maps, the key performance indicator is efficiency. And it’s always renting, you are subject to their terms and conditions, and if you don’t follow them you can be evicted.

Another no-brainer example is for me email: you always need to send email, don’t need an email server, most of the time you’re better off with a third party email service unless there’s value your customer can perceive from having your own. Email has a standard protocol and known rules of how to operate, filter spam etc... You don’t need to host your own email server, or build your own email software because there are plenty of market services that can do for most cases.

When to build

You are better off building if the component is strategic and you need a lot of control on the roadmap. How it evolves, which features are added and which features are removed. You need to control how tightly coupled it becomes within your ecosystem and you can move faster if you do. Owning software is an asset that requires maintenance, high maintenance and it makes sense when it brings significant value that the customer appreciates, I mean they know they are paying for it and will keep paying for it. If your product is about improving a boring clerical process with AI, then those algorithms you use and the data sets are key components of your offering, you need to own them. How to operate these algorithms, using a processor or MLOps as a service is a good way to balance what you build vs what you rent, the servers that run the algorithms and the databases that keep your data.

When to replace 

It’s harder to let go of a system than not building it in the first place. When you start renting a service, you become entrenched in the service’s lock-in propositions, migration to other systems becomes more difficult, to the point you live with it, remember, when was the last time you changed databases for performance reasons?

On the other hand, some internal software you run will eventually fall behind with updates/maintenance and new feature development. You might even consider what to do, if it no longer fits your customers’ needs. You still have teams that worked in this system for months, years, that depending on the level of degradation will be eager to stop working with that code or look at it with melancholy of a golden past, when the system was better maintained. Your team needs to mourn their departure and picture themselves in the new landscape.

One aspect quite unknown (or at least to me) of BF was that at some point in time started a business with a partner, a printing house, and after sometime BF decided to dismiss the partner. There isn’t a lot written in the note of dismissal about it or why. I cannot imagine if it was painful or not to conclude that it was better to proceed alone.

The topic of the dispute was a printing house bought in a join venture by BF and Hugh Meredith, who is described a as “honest, sensible, observant man, a wide reader, though a poor printer who was addicted to drink.” The partnership was dissolved by July 1730 when was 24 years old.

Printing was a big business at the time, specially for BF, impactful and thought-provoking writings could see the sunlight trought one of the most prominent papers until 1800. The newspaper, the Penn Gazette, was acquired by the partnership from a previous owner and was instrumental for many writings oppossing British rule.

Reading the note and BF’s biography is interesting. Seems to me that reading English from 300 years ago bears some resemblance to reading Spanish from 500 years ago. The spelling changed but most of the grammatical structure and syntax stayed. In BF’s archive appears to be a note of an agreement between him and his partner that the latter renounces all his rights and obligations in the partnership.

There isn’t that much written on the decision making of that particular situation. The note is particularly succinct and to the point. Doesn’t explain why they are parting ways even if in BF’s authobiography there are additional indications.

It’s worth noting that the note is a miniscule part of all the writings by BF conserved by the archive by Yale. It contrast with so many stories of many contemporary stories of successul entepreneurs in their early twenties that had VC funding and didn’t dismiss any partners because of friendship.

Notes:

Autobiography: https://franklinpapers.org/yale?vol=50&page=007a&rqs=137&rqs=201&rqs=346&rqs=429&rqs=914

Dismissal note: https://franklinpapers.org/yale?vol=1&page=175a

Over the course of the years I have been blessed with many thanks of the good work I have done for others and of course gifted with useful constructive feedback but that’s for another moment.

Some of the most memorable I have is this:

I can honestly divide my time at the company into the pre-Pablo era and the peri-Pablo era. His organisational skills, energy and determination have brought about phenomenal improvements in terms of how the development team operates. Thanks to him productivity has increased dramatically, and the team is immeasurably happier and more cohesive.

He is invaluable as a leader and mentor, and someone who can be relied upon to support his colleagues in all situations. And his enthusiasm and good humour make him the cornerstone of our small department.

It was a great experience and I didn’t realise until I was leaving that company. Sometimes good work goes unnoticed, particularly for oneself when one’s afraid of asking for feedback for lack of energy and time to focus on the improvement side.

Feedback of good deeds helps remind me where to aim, it is not for resting on laurels however tempting.

Working with Coders by Patrick Gleeson

A book to explain to non-tech people what tech people do. Getting insights for improving my undestanding.

Team Guide to Metrics for Business Decisions: Pocket-sized insights for software teams by Mattia Battiston et al.

Mattia started to work with us last year, it’s about time for me to revisit how my teams define their metrics.

Empathy System Architecture by Andrea Goulet

Andrea’s making a strong case that empathy is a technical skill we can all train and use.

Cosmic Python by Harry Percival et al.

DDD in Python context.

What am I listening to?

The Inner Landscape of Beauty: John O'Donohue's interview with Krista Tippett

Four Languages of Influence by Roger Granis

Nevertheless, timing is a crucial aspect which is not taken into consideration enough to make the process simple, fast and repeatable. Let’s do a simple calculation of productivity and profits that will guide our most risky assumptions about the process.

We can measure productivity

Productivity is quite hard to measure, there have been books and debates from the past 40 years, sophisticated methodology such as cosmic metrics, confusing story points etc... So let’s assume the quantifiable value of a delivery team is 500K USD a year and it is composed of 5 people with equal pay of 50K USD, which costs the company 250K USD a year. These are not real-numbers, go to payscale to see actual market values, it suits the back of the envelope calcs.

So for every dollar invested in the team, the company gets two in revenue, again simplified profits of 250K a year and roughly 4.8K per team-member month (if you read Brook's mythical man month book you know this is not linear).

This is easy to calculate if your company does consulting and bills per hour or per day, it is just a cross multiplication. Otherwise, you may need help to translate the output from your team into money outcomes. Last but not least in real-life, people don’t earn equally and the company may accrue some additional costs such as employers’ national insurance which is more than the employee gets before deduction and taxes.

Sad news

Starting the new year one team-member decides to move on to another company for a variety of reasons (we can write about those some other day). There are many other effects of a person leaving, in terms of teamwork, domain knowledge and wellbeing of the team that are not that easy to quantify in money so less focus on the easy numbers first.

The company has a new scenario:

• 200K costs. Savings of 50K

• 400K revenue. Potential loss of revenue for 100K

And the total opportunity loss for the new year is 50K.

So, a lot of questions arise on what to do next? Hire a replacement? How fast can we go in hiring? How much time would the person need to ramp up? How much will the team slow down without help? Again, let’s talk only on the money left on the table for the time being and some milestones.

Notice period

Let's say it is 1 month (loss: -2.4K). Most companies agree terms between 1 and 3 months of notice period. This implies the person usually still works but the productivity varies, some people are committed until the last day while others are just thinking in their next gig/position. I am glad to say many people that commit to the last day but let’s say on average the person is half productive for a month as he/she could be.

Empty seat period

It could be 3 months (loss: -14.4K) or more. Companies don’t necessarily reopen the position immediately, managers take some time, hopefully less than a week to decide what to do. If you are in the middle of a Coronavirus crisis you may even rethink when to open positions globally. You need to have the budget for replacement approved from finance, in any company size, whether startup or large company.

Once the Job description is out and recruiters get candidates into the process time elapses and the efficiency of making an offer takes time. Usually, if the candidate is good there would be competition of offers and lag between hiring processes. As a candidate it is always better to have many options to pick the best.

As a manager you are hopefully waiting for a yes, then to sign the contract, and finally…. Wait for the notice period in the previous company :(

Ramp up period

The equivalent of 1 month (cost: -9.6K). So the new candidate joins the company, everyone happy or not, but they made it. Now you cannot expect the same productivity as the former colleague from day one would you? Most likely the candidate would find quick wins, but how long would it take to get up to speed for the team work? It is hard to say less than a month, or you can prorate the throughput in the months to come, in one company we used to count the person as half for a 3 month period. In this case, you are already paying the agreed salary but not yet getting all the value. Also the team reduces their velocity because they need to figure out a new working agreement, they are a new team, and get the person up to speed.

Total costs

So far we counted 26.2 K, 21.6K of opportunity cost and 4.8K of salary just to get back where you were in financial terms.

Sounds too machiavelical? Maybe, but the whole point is to convince the finance and talent teams to keep the gap between an open position and a real person coming to help as slim as possible. We are not taking into account the time invested by interviewers, managers and teams accommodating the decision.

The most important is how the people in the team found themselves after the team-member decides to go, what troubles them and how can be addressed.

Teams have all the necessary skills to build, test and deploy a story, they own it basically.

It may lead to a bottleneck if the skill required, for instance to deploy or test is not shared among all the team-members. This usually means that the testers could endup being the gatekeepers of the release. In true service of self-service everyone in the team needs to be able to sign-off deploys.

Then you start having “internal service teams” instead of renting in platforms as Heroku or Digital Ocean. Who knows…

To avoid it the main ideas mentioned a while ago:

1. Focus on an idea that will bring immediate revenue, i.e. SaaS or desktop product. I made the mistake of thinking I'll wait until I had a lot of users before I charged for features. I never made it that far, and wound up sinking money into hosting and other costs in the process.

2. Embrace outsourcing, exchange dollars for time when it is to my advantage. Since I only have a few hours a night I want to maximize that time. This may be something you'll want to ease into after you've validated your idea and are fully committed.

3. Tap the wisdom of those who have done it. I like Rob Walling's blog and his Micropreneur site. I've also followed companies he's graduated from his company (i.e. BidSketch) that are successful.

My two cent on the matter, from my answer to starting with no experience:

If your regular, full-time job is so demanding that you cannot be quiet in the weekend without having to answer email from the company, endless times you have to stay more than 10 hours at the office, not only it is an unhealthy job but also is a job that won't allow you to create your own company some day.

Were you to start a company little by little, you would need to have a more compartmentalized work, regular hours, no bouncing schedule. Otherwise, you will end with no time for a startup, not even a decent life.

The links to OnStartups are broken since the site is no longer maintained but fortunately the was an Internet’s archive snapshot

Once I overcome the blocks, words flow. As simple as that, like a stream of fresh water coming down the mountain when the snow melts in early spring. The icy blocks trap the treasure of the thoughts and feelings intertwined. The blocked, shareable ideas are judged, pre-judged even before landing in my google notes, and therefore they don’t survive long.

Other times I manage to land them in the tintero (Spanish for inkwell), my collection of notes, post titles, topics I may have a say or some copy-paste I would like to revisit later. In Spanish we have this fabulous saying quedarse en el tintero, literally to stay in the inkwell, about things we regret we didn’t write about.

In the remote past, I mean way before our parents, writing was done using a fountain pen with required ink from an inkwell. From a usability perspective it is quite weird that you need to fill the pen every few strokes to keep writing, with all the side effects of tossing the inkwell and ruining your writings. I am glad we have other alternatives less error-prone.

Continuing with our Spanish phrase, writing is a creative activity that you need to put in paper to be easily contrasted and shared. So the ideas that you wouldn’t put in paper will remain in the inkwell until you move them into paper.

Getting words out of the inkwell is hard. In my case my main block is this inner censor or jackal, the mental rules of thumb that try to help me decide what’s good enough to be read to be worth writing. Making sure that the content is useful without writing it first.

My second block is reviewing. As most of us, I struggle to review my own writings, my own programming code. Why was I writing this in the first place? Who was my reader? Was it for me? I struggle to review my notes, even when 10 or 15 years pass and I am a distant witness of the original writer. Which is good when writing about technologies because after 10 years there’s very little in software that survives the test of time, mixture of oblivion and obsolescence. In that case it is enough to bin it, and move on to other things, detached from the initial concern of writing something worth reading.

Two magic spells may help me to melt the ice, the first is to schedule some time, to see if with enough rays of sun the ice may cede eventually. The other spell is to write in response to a threat or some other triggering situation, which reminds me of the finitude of time and little value of leaving things work in progress.

Memento mori, remember you die, wrote the old Romans.

There are many ways of delivering software projects (Kanban, SCRUM, DFD, RUP), as many and varied as we have sources for generating electricity, I associate AC with Eolic generation, in the sense that it’s clean and circumscripted to a given scenario, it is not a solution for the entire product vision.

In 2008 the gold standard for medium/large projects was the PMBOK, with it myriad of artifacts, documents and endless meetings :( . We used to write verbose, and somehow over-complicated, use cases written in Rational with its diagrams: a funny ellipsis or two placed within a box and arrows that link them to stereotypical users.

Use case diagram (from: Wikipedia)

However, sometimes these didn’t highlight the inherent complexity of the software essence, were too simplified to grasp the best of it. So the use case had to include an extensive narrative of the situation which becomes challenging when you need to refer to conditional logic, almost writing a pseudo-code.

In spite of all its problems, Use Cases were the defacto document for teams to communicate over and we didn’t have a product manager at that time, we would have several functional analysts that communicated these narratives to programmers, and the sum of the writings was usually called the Product Spec. Overall teams somehow deliver but we were very rigid in terms of accepting changes during development in the phase. Challenging and even heated discussions would happen if a request for change was introduced, and then the team meetings turned into a tank of sharks swimming around, waiting for the first to draw blood so the rest can attack.

Over the years, the entire community of software practitioners moved over to the outcomes of the Agile Manifiesto, trying to develop sofware with agility. A new set of practices (methodologies or cookbooks?) appear, and SCRUM became the defacto standard for processes.

Then Dave Hunt, one of the signers of the Manifiesto, declared that Agile was dead; and Kent Beck, also talked in favor of Waterfall.

Oh my, should we re-shuffle again? Are methodologies fads as with fashion clothes? Well, maybe, there are things that repeat themselves.

Nevertheless, one of the key agile principles to apply is the People over Process: writing steps that commit the entire team to produce accountable results, not only working software.

The story is a succint narrative of what happens and provides the boundaries to what does not happen so the team is on the same page on whether the story is done or not. It is a clear WHAT. It is not for displaying the HOW the software works, that’s more about documentation of the tasks. It is also insufficient to provide a higher vision of a product so needs to be complemented when scaling to a product spec but small enough to be iterable. And once all stories appear the same, as all the mills in the windfarm look alike.

Therefore, Stories with AC allow you achieve sustainable development in a similar way of eolic energy.

The Need of Sustainable Development by using applying the principle of Simplicity — the art of maximising the amount of work not done — is essential.

More interesting readings to read further:

The Acceptance Criteria for Writing Acceptance Criteria

The Definition of Done

Clear Acceptance Criteria and Why They're Important

Manifesto for Agile Software Development (from 2000!)

Here’s me drinking Mate (typical drink from South America):

I was a developer for a while, an entepreneur for less, nowadays an engineering manager. I’ve been through many web technologies such as PHP, .Net, GeneXus, Ruby, JavaScript and NodeJS. Some time ago co-organised JSConf.uy

Fond of the agile principles, not so much of SCRUM nor JIRA :P

I supporting anc coach teams to deliver great products.

My full cv is in Linkedin.

“The answers you get depend upon the questions you ask.”

Thomas Kuhn

Another interesting thing is when people confuse extroversion with working as a manager. Sure I work with engineers, helping them deliver and grow professionally but it has little to do with extroversion/introversion.

Effective management is about leading, delegating, organising and supporting. Ensuring people have ownership so they can excel solving problems. It has little to do with chatting to people until exhaustion. There are many tools and schools, not to mention good, great and poor books.

Actually, extroversion according to many personality instruments such as MBTI, the Myer-Briggs type indicator, is about “how we recharge batteries” not how outspoken nor how much you express your feelings. Extroverts recharge spending time with people, introverts recharge alone, for instance writing or reading. That doesn’t make introverts anti-socials at all.

One big benefit of extroversion is being able to meet people an extra mile or two, since you usually get recharged. It does not mean you can process all the emotions that you encounter during the day, particularly low feelings that reflect unmet needs, for instance when handling rejection or hearing bad news.

Active listening, I mean being there and not just hearing, is a precious skill, very useful when you are a manager. It’s very hard to understand without listening and hard things are even more difficult to listen to. Extroversion doesn’t give you listening powers, but you can, if you pay attention, listen for longer, and in most cases being more energetic after the conversation.

Moreover, being an extrovert doesn’t give you superpowers when delivering presentations (or at least not to me). I would still need to prepare the notes and practice, and do dry-runs with supporting people that provide constructive feedback. What’s really cool is being able to re-run the deck with different audiences many times without getting tired because everytime you practice you get better and recharged.

One last note on tests that label you A or B. MBTI is an interesting tool, as are other personality inventories such as DISC Profile and Clifton’s strengths. The key when using them, is explore how to expand the boundaries and keep doing more of what makes you stronger. The test may tell me that I am an imaginative motivator but in practice we are not just a snapshot.

Share Software, Pablo Dejuan et al.

Sign up now so you don’t miss the first issue.

Subscribe now

In the meantime, tell your friends!