{ "version": "https://jsonfeed.org/version/1", "title": "Organizational-Culture on enumerator.dev", "icon": "", "home_page_url": "https://enumerator.dev/", "feed_url": "https://enumerator.dev/feed.json", "items": [ { "id": "https://enumerator.dev/navigating-to-get-things-done/", "title": "Navigating to Get Things Done", "content_html": "

\n

In engineering culture, we sometimes refer to managers and Staff Engineers as “shit umbrellas” for their team. I’ve never liked this idea. It paints a picture that individual leaders create a peaceful oasis for their team while chaos reigns outside.

\n

Sounds nice to be one of those engineers! Not a care in the world. Just flow. It must feel special to have a shit umbrella manager.

\n

But the shit umbrella is a lie.

\n

If every manager believes they create a sphere of deep focus and flow, where is all the shit coming from? One team’s flow is another team’s dysfunction.

\n

The “shit umbrella” metaphor entrenches an “us versus them” culture and isolates individual teams from the rest of the company. It pits leaders against lowly engineers and ensures communication starts with arguments rather than curiosity.

\n

Be a Navigator

\n

Effective engineers engage across an organization and know how to navigate its complexities. Effective engineers recognize that people are complex, have diverse emotions, make mistakes, and struggle to communicate effectively. And that’s okay because we are all human.

\n

Teams need to understand how an organization operates to be effective engineers, and people leaders are responsible for helping teams focus, navigate complexities, and achieve their goals.

\n

Being a navigator for a team means helping them find their way and letting them do the work to reach their destination by helping the team understand who is who in the organization and what these individuals care about. Working with the complexities in an org is about curiosity and learning.

\n

Helping your team navigate an organization begins with trust and focus: trust that your team can handle what comes their way and that the people they work with understand their part of the organization better than you do.

\n

In Matheus Lima’s recent post on politics, he says:

\n
\n

The engineers who refuse to engage with politics often complain that their companies make bad technical decisions. But they’re not willing to do what it takes to influence those decisions. They want a world where technical merit alone determines outcomes. That world doesn’t exist and never has.

\n
\n

The same goes for managers who choose to be shit umbrellas. Protecting your team from politics isolates them from the business and creates an insular culture where “everything could be better if…” while not improving anything.

\n

Protecting Your Team Protects Dysfunction

\n

When people leaders try to protect their team from organizational chaos, they are unintentionally ensuring the dysfunction stays in place.

\n

The purported “shit” that a shit umbrella protects people from is just people being human. To quote Will Larson:

\n
\n

[T]he reality is that executives are human. You’ll make much more progress by focusing on improving how you communicate with them than by blaming them for their deficiencies.

\n
\n

Larson’s comments apply to anyone you work with in your org. Improving your communication skills ensures that you approach conversations with a clear understanding of the core business needs.

\n

Blaming others for their deficiencies ensures organizational dysfunction is the norm and prevents the business from growing.

\n

People at all levels of an organization need to make mistakes and learn from them. The shit-umbrella culture breaks this feedback cycle. It allows new leaders to fail without receiving feedback and support from their peers, isolates senior leaders from the teams they need to work with, and isolates your team from the business.

\n

Focus

\n

People who talk about being a shit umbrella want to maintain their team’s focus and limit distractions. It comes from a well-meaning place, but creates a culture of isolation instead of focus.

\n

As a navigator, show your team what to focus on and how to reach their destination. Trust them to raise concerns when things get hard, and trust your peers on other teams to support their work.

\n

Provide your team with a map and help them to focus on the business impact of their work, so that they can approach complex parts of the org with curiosity and an ambition to build great things for the business.

\n", "date_published": "2025-10-07T11:55:00+00:00", "url": "https://enumerator.dev/navigating-to-get-things-done/", "tags": ["organizational-culture"] }, { "id": "https://enumerator.dev/stop-talking-about-blameless-postmortems/", "title": "Stop Talking About Blameless Postmortems", "content_html": "

In tech, we talk about “Blameless Postmortems.” What does this mean? Why are we talking about blame?

\n

I think the phrase “Blameless Postmortem” has a strong connection to git blame, the command we use to find context on what work was done together and who wrote the code. git blame shows you who changed which lines and when. It gives you context on the current state.

\n

Origins of Blame

\n

North American culture has an innate belief in individuality and hard work, which comes from the Puritan culture that our capitalist economies are built on. We believe individuality and hard work have built the success of our countries. At least, that’s the cultural narrative.

\n

As a part of that, individualism comes with blame. Whose fault is this? It’s not mine, it must be someone else’s. Puritanism takes “blame” so far as to make us believe we need to work hard to make up for our innate faults.

\n

Success in this culture is working so hard that you overcome your innate weaknesses as a human.

\n

Each individual must labour away their weaknesses.

\n

This is my take, at least, on the origins of blame in North American culture. I think it has to do with innate cultural beliefs about hard work and individuality.

\n

git blame

\n

The git command itself has an interesting history.

\n

The short story is that it ended up in git because it was in SVN, and blame seemed to be a short word that carried strong meaning. In line with the culture that created rather blunt commands like kill, dump, and strip.

\n

I think there is a good possibility that the innate culture of programming at the time was blunt and individualistic. blame was a good word because we want to know who wrote this. annotate didn’t take off because it’s ambiguous about what it is doing. What is it annotating? What are these annotations?

\n

I’d prefer git context because it shows the context in which lines were modified together. I don’t care that much about who did it, unless I need help understanding it. However, many bugs occur because one line was written a few months or years ago, and another conflicting line was written yesterday. It is hard to “blame” anyone when you have this context.

\n

A Responsible Postmortem

\n

Now that you’ve followed the bunny trail of Puritanism and blame with me, let’s get back to postmortems.

\n

We often talk about “blameless” postmortems, which puts the word “blame” at the forefront. It creates a culture where no one wants to assign responsibility, and everyone can say, “Well, no one is to blame here; code is just hard, I guess.”

\n

We need “Responsible Postmortems.”

\n

Responsible postmortems understand the context in which the code was written, and they respect who owns the code and what needs to change to reduce the impact of similar errors.

\n

In a Responsible Postmortem, I would talk about my actions that led to the incident. My colleagues would discuss how they contributed, and we would diagnose the cultural, technological, and systemic changes we need to prevent a similar incident in the future.

\n

Responsibility is about knowing that, as a team, we approach our work with good intentions and are working together to build great things. We know that building great things comes with complexity, and we are excited to tackle that complexity together.

\n

Building Great Things

\n

To build great things, we need a culture that is energetic and creative. That encourages exploration, discovery, and synthesizing information into new findings.

\n

“Blame” drags people down and makes them afraid of taking risks.

\n

“Blameless” postmortems are even worse. They allow teams to shrug off responsibility and drown in the overwhelm of complex code.

\n

I try to create an environment where teams do not need to think about blame. We work to build things we’re excited about. The code is what it is. If you merge a bug, I’ll fix it. If I take the system down, we’ll get it back up together.

\n

I am excited to build great things, including building teams that build shared context and ownership over the code we work with.

\n", "date_published": "2025-07-12T17:14:00+00:00", "url": "https://enumerator.dev/stop-talking-about-blameless-postmortems/", "tags": ["organizational-culture"] }, { "id": "https://enumerator.dev/how-i-plan-software-projects/", "title": "How I Plan Software Projects", "content_html": "

In the past few months, I’ve worked on projects with several different teams across my company. I’ve noticed different styles of planning and executing projects, which has caused me to reflect on the system I’ve developed for project planning.

\n

For this post, a “project” is a unit of work requiring coordination among multiple people and possibly numerous teams. Work that can be done in isolation in a day or less isn’t a project. It may be important, but it doesn’t require much team coordination.

\n

Big Picture

\n

I am a “work backward from the end goal” planner. I set an end goal, envision an ideal state, and work backward. However, I keep in mind that my end goal will shift as I learn more about the technical implications of the work.

\n

Work back in enough detail to know the main steps, where the risks are, and your decision points. Decision points are especially important. Every project can be walked back in the early stages, but there comes a point where you are committed to keeping at least some of the work you’ve done.

\n

In a recent project, I set the end goal and clarified the business outcomes in the project name. This project was easy to sell to others because they instantly saw the value in the title. The early milestone in this project was quick and easy and proved the value of the work early. Later milestones were more complex but continued to deliver the same goal.

\n

Break it Into Milestones

\n

I always ship multiple milestones. Too many projects fail to deliver because they are built from the ground up without proving value and testing the work.

\n

I find getting early feedback on small milestones easier than tackling the hard parts first. With this early feedback, I then apply what I learned to a harder problem set.

\n

I usually pick the second milestone as a more complex, gnarly problem. This way, I have quick feedback from he first milestone and then time to strategically apply it to a problem that I know will be difficult.

\n

Decision Points

\n

I find the point of no return. A point of no return is a stage in the project when enough work has been done that you won’t be able to reverse any decisions.

\n

Another name I’ve heard for this is a “one way door” versus a “two way door.” There is no going back through a one way door but a two way door lets you go in and out easily.

\n

It is rare in coding projects to be able to walk away from a failed experiment entirely unless you know your point of no return. When does the project become a one way door?

\n

To find the point of no return I ask myself how early in this project I can collect metrics and pivot if I need to, and when will I be so deep in the work that rolling it back would have technical consequences.

\n

If I find my point of no return early in the project, I reconsider my plan and delay it as long as possible. I often develop a Parallel Change or expand-contract pattern to avoid this point.

\n

Defining metrics before I start writing code ensures a project’s success and simplifies questions that lead to scope creep.

\n

Detail Each Task

\n

Now comes the less fun but necessary part. I often do this task with the whole team. By this point, we’ve decided on the scope of work and understood the critical decision points.

\n

We now break up the milestones and make tickets for them together. I’ve done this over calls, where someone plays a lo-fi hip-hop playlist, and we each work our way through a section of tickets. Then, finally, we review the tickets as a group so we are aligned on the direction and detail of the work.

\n

Depending on the project’s scope, doing this work every two weeks or so is good. Too much detail too far into the future becomes wasted work. So, I ensure that we work through one milestone at a time and have enough work planned to fill the next week while making room to pivot as needed.

\n

I guide team members to detail tasks in a language that anyone on the team can understand. One-line tickets or tickets with only a title are banned.

\n

Ideally, a new team member could join the project, pick up a ticket, and get enough context to understand the ticket’s intent, even if they don’t understand the whole project yet.

\n

I follow a standard template for tickets:

\n
## Context\n\nThe context section explains how the work fits into the\ngreater project and why we need to do it.\n\n### Developer Notes\n\nThis is the gotcha section. I don't solve problems in\nhere, but I list potential gotchas or things to be aware\nof.\n\n### Acceptance Criteria\n\nHere, I define "done." What needs to be true for this\nticket to be done?\n

Most importantly, I do not solve the ticket in the description. The ticket defines “why” and “what,” not “how.” Each section should be no more than two to three bullet points.

\n

I trust the developer picking up the ticket to decide how they will do the work.

\n

Iterate, Measure, Modify

\n

Once work is kicked off, frequent check-ins with the team and frequent check-ins on metrics help guide the work. The big vision I started with is rarely where a project ends up, and that’s good. I expect my projects to take shape as we refine the work.

\n", "date_published": "2025-03-28T00:00:00+00:00", "url": "https://enumerator.dev/how-i-plan-software-projects/", "tags": ["organizational-culture"] }, { "id": "https://enumerator.dev/feeling-stuck-at-work/", "title": "Feeling Stuck at Work", "content_html": "

Early in my career, a mentor cautioned me, “One day, you won’t feel like you’ve learned anything in weeks. Work will feel slow and difficult. " They said, “But that’s okay. Learning comes in spikes and plateaus.” I am paraphrasing, of course, but their observation has been accurate throughout my career.

\n

I started at my current company three and a half years ago. In my roles, I’ve made technical contributions to multiple teams, guided single, impactful teams, and written the company’s architecture strategy.

\n

A colleague recently observed that when we started working together, I doubted everything I did, and now, I have broad technical influence at the company. “What changed?” he asked.

\n

I didn’t have a great answer then, but shortly after we chatted, he sent me Katie Sylor-Miller’s article, “The Staff+ Performance Cliff.”

\n

“Yes!” I thought, “But it’s not a cliff.”

\n

During growth periods, I learn something new daily. Each line of code I write is thrilling, every project plan has a broad impact, and I receive positive feedback every minute.

\n

Plateaus come abruptly.

\n

A plateau is a period of slowing down. Work seems more challenging and ambiguous, and my impact is unclear or absent. I often also experience a hit to my confidence because I feel less impactful and less relevant.

\n

Plateaus are expected, and I can think of two reasons for them:

\n
    \n
  1. I have other things going on in life.
    2. \n
  2. I’m learning to apply my new skills at a higher level.
    3. \n
\n

Life Happens

\n

Work is a part of my life, but not my whole life. Many life events can cause a plateau at work.

\n

Becoming a parent, coming out, going through a breakup, or experiencing a death in the family–all these things take time and energy, and they are IMPORTANT. Work comes second to these things.

\n

In some communities, periods like this are called a “Skill Regression.” In my own words, this is a period where things that previously seemed easy to you are challenging. This might be because you are overwhelmed or processing new stuff you’ve never experienced.

\n

In one Redditor’s words:

\n
\n

Think of your brain as a series of highways connecting a dozen towns. Each town represents a skill or ability that you have developed over your lifetime. The roads are the synapses and connections our brain creates to access those skills and our brain loves efficiency. We have a lot of roads that can get to those towns and those roads are developed over time from childhood.

\n
\n

Then. Boom. Something new happens in life, and all those roads don’t make sense anymore. All your old ways of accessing skills are gone because your brain is occupied learning new skills.

\n
\n

Suddenly, every single one of those efficient roads that kept you going every day has been blocked off by road construction and you can no longer access that town. The towns are still there, but you have a really rough route getting there as your learned experience is no longer accessible to you.

\n
\n

Life happens. And that’s okay. Plateaus, cliffs, skill regressions, or whatever you call them, are complicated. They are times to take care of ourselves and build support networks.

\n

What to do when life happens

\n
    \n
  1. Know your capacity. Determine for yourself what scope of work feels right. Recognize that you might not make a flashy impact in your work, but you will do essential work for the business.
    2. \n
  2. Tell someone. Once you know your capacity, talk to your manager about it. Tell them where you are at and what kind of work you are most capable of doing. Communicate your capacity. You don’t have to tell anyone why you need space; only that you need space.
    3. \n
  3. Know your strengths. You worked hard to get here, and while you might be at a plateau, this plateau is higher than the level you were at before. Remember to take a moment to enjoy the view. Even this version of you produces better work than you were a year ago.
    4. \n
  4. Expect pushback. Your manager or colleagues may expect you to perform and grow at the same rate you previously did. Lean on your strengths and continue to do the work you are skilled at. Accept feedback and set reasonable boundaries that acknowledge your current capacity. Continue to communicate your capacity clearly, and don’t over-commit yourself.
    5. \n
\n

When life happens, your job is to take care of yourself. You are already good at your job. You’ve done fantastic work to get here. Let work take a back seat while you learn new life skills outside of work.

\n

Working at A New Level

\n

Working at a new level brings on a different kind of plateau. One where the growth and learning that got you to this new position are suddenly not relevant to your work. You may have gotten promoted by leading a project and shipping a new feature. Congratulations! But now you are being asked for architectural direction that affects the longevity of a whole software system. Shipping features and setting architecture direction are two wildly different things! The skills needed to ship are not those needed to design resilient systems.

\n

You may have heard about “The Peter Principle,” or at least heard it summarized as “people rise to their respective level of incompetence.” In a hierarchy, everyone is skilled at the job below them but not the job they have.

\n

The Peter Principle is a bleak way of saying that people hit plateaus when promoted. However, they can learn new skills if they have the insight to recognize this plateau.

\n

I have encountered these plateaus in my career, requiring a thoughtful pause to create a learning strategy.

\n

What do you do when you’re learning new skills?

\n

First, read Katie Sylor-Miller’s article. I highly recommend reading her suggestions. Here is my take on a few things that have worked for me.

\n
    \n
  1. Find your peers. You are now at a new level, and you have new peers. But your peers don’t always have the same title. Recognize the people you work well with who are doing jobs you admire. These people can be across the organization, in another department, or adjacent roles on other teams. Having peers working at the same level, regardless of title, will help you see how your work fits into the organization.
    2. \n
  2. Build your network outside of work. This is a hard one for me. As a natural introvert and a horrible small-talker, I value a few deep relationships that cut through the small talk and get right to the point. I challenge myself to attend social events or reach out to people. These relationships can provide invaluable insight into how other companies work.
    3. \n
  3. Write everything down. I recently started a work log. I book a half hour at the end of the week to journal everything I did that week. These journals are succinct and focus on impact. I use this time to reflect on shaping my priorities to ensure I am consistent in the direction and impetus of my work.
    4. \n
  4. Seek feedback. When you work at a higher level, you will get feedback less often and rarely get positive feedback. Reach out to your peers and those above you for feedback frequently. Feedback in the moment is usually the best. After a meeting or when a project is wrapping up, I ask other leaders for input while their memory is fresh. Ask for actionable feedback. Don’t expect it to be positive; expect it to have your best interests in mind. This helps me adapt on the fly.
    5. \n
  5. Say no. It is easy to have too many priorities because, in your new position, you want to help everyone you can. You have to learn to say no and let go. Saying “no” frees up your energy to focus on priorities that matter to you, your peers, and your manager.
    6. \n
\n

Conclusion

\n

Plateaus caused by live events or working at a new level are similar. As you learn, you are reorganizing how you operate in the world. The skills that got you to this place are not the skills you need to continue to succeed.

\n

If you are conscientious of this, you can build the support you need into your work environment to get through the challenging parts of this new learning period. One day, this hard work will all come together, and you’ll feel like you’re back on a rocket ship, making an impact with every keystroke.

\n", "date_published": "2025-03-18T00:00:00+00:00", "url": "https://enumerator.dev/feeling-stuck-at-work/", "tags": ["career-growth","organizational-culture"] }, { "id": "https://enumerator.dev/problems-that-matter/", "title": "Problems that Matter", "content_html": "
\n

Good developers solve problems, great developers find problems.

\n
\n

My paraphrasing of a colleague.

\n

Problem solving is a unique skill needed in our industry. Synthesizing complex inputs from business needs, log patterns, observability tools, and Jira tickets into code is challenging and fun. It’s what drives many of us to excel at our jobs.

\n

There is a unique skill, though, that is also necessary. Finding problems. Especially problems that matter.

\n

In any code base, it is easy to find problems. There is old code that doesn’t look great. There’s a function call that isn’t as fast as it could be, or syntax issues make code hard to read. Backlogs quickly stack up with “we should fix this” type tickets that are well-meaning and collecting dust.

\n

Many of these problems are nuisances but don’t carry enough weight to make it into active work.

\n

In this post I’ll explore how to find problems that matter.

\n

Listen to Business Leaders

\n

Every organization follows fundamental truths, which are intuitive to the founders and ingrained in the company’s language. New employees can take years to understand these espoused beliefs, because they are rarely stated directly in any cultural artifact.

\n

Understanding these beliefs and understanding how they manifest in the business’s work will help you determine what matters to the company. To discover the espoused beliefs of your company, listen to non-technical and technical business leaders alike. Listen to how they discuss successes and failures, challenges, and the future.

\n

I once worked for a company that had the value “Be a good person.” Values can guide you in the right direction, but they don’t tell you how the company acts. This company did want employees to be good people, but understanding what this meant required listening, seeing who was rewarded for their work, and determining how work was prioritized.

\n

“Be a good person” at that company played out on the engineering team: “Be thoughtful, conscientious, and curious in code review.” This was a delightful way to work because code review was collaborative.

\n

It also meant that if you found an issue in code that might impact users negatively, it was prioritized without question.

\n

However, when you encountered difficult-to-manage code from the scrappy early days, code that might seem like a good problem to solve, it was next to impossible to prioritize working on it.

\n

I have bad news. Cleaning up messy code does not help the business. Even if you were following the “be a good person” value by cleaning up the code you see, you were not applying this value in a way that matters to the business.

\n

“Be a good person” means “be a good person when shipping new features and taking care of our clients,” not “be a good person and clean up old code code no one has looked at in a year (and might not look at for another year).”

\n

My story here is not unique to this company. It happens over and over. Engineers who dream of working in a clean code base find an early-startup-style cruft and want to dive deep into cleaning it up. Stop yourself from doing this.

\n

Old code is rarely a problem that matters.

\n

Problems that matter are problems business leaders care about. Learn what your business leaders care about and look at your work through their eyes. Listen to their all-hands presentations, read their LinkedIn posts, and read their Slack messages, and start noting what they talk about and how they view the business.

\n

Carefully studying how your company works will help you find problems that matter to the business.

\n

Finding Problems

\n

The art of finding a problem starts with understanding the system. As you work, build a mental model of the software and human systems. Identify choke-points and repeated stumbling blocks.

\n

Complex problems are rarely a matter of “shipping” but shipping a human-system and software-system fix. The best problems are ones where the solution speeds up whole teams or departments.

\n

Test what you’ve found with a circle of trusted people. Sharing ideas with a gradually broader group is a great way to get feedback and shape your solution. Start with people you trust who you know will give you actionable feedback. Treat ambiguous feedback as “this is a bad idea,” and return to the drawing board.

\n

When you look for feedback, focus on people who instinctively know the business’s fundamental truths—people who will tell you if you have found a meaningful problem. These people will give you the most precise, actionable feedback.

\n

Build your problem case into a solution and keep your solution close to what matters to the business.

\n

Conclusion

\n

There is no shortage of problems to identify. Discovering issues that matter to the business is the challenging part.

\n

Understand the language of the business. Grasp the deeply held beliefs on which the company operates. Use these insights to help you identify problems that matter to the business.

\n

Seek guidance from colleagues who understand the business and embody the company’s espoused beliefs in their everyday work for feedback and to keep you on the right path.

\n", "date_published": "2025-02-17T00:00:00+00:00", "url": "https://enumerator.dev/problems-that-matter/", "tags": ["organizational-culture"] }, { "id": "https://enumerator.dev/this-has-always-been-the-job/", "title": "This Has Always Been the Job", "content_html": "

AI is changing my job and yours, and it is a reflection of the failings of our socio-cultural and technical systems.

\n

These are two conclusions I’ve come to in my deep dive into AI developer tools in the past two weeks. And I’m not alone:

\n\n

Writing code is just the last step in the process. It’s the moment of joy when we see our work come to life.

\n

AI changes this by emphasizing the critical and challenging work of making clear design decisions, verifying our work, and iterating on both our successes and our failures.

\n

Our job has always been to think of edge cases, check our assumptions, and be purposeful in what we build.

\n

Prompt engineering, AI, agents, and LLMs introduce a new mode of doing this work. One that requires careful application and thoughtful experimentation.

\n", "date_published": "2025-02-15T00:00:00+00:00", "url": "https://enumerator.dev/this-has-always-been-the-job/", "tags": ["ai","organizational-culture"] }, { "id": "https://enumerator.dev/assumptions/", "title": "Assumptions", "content_html": "

As software developers we have to make assumptions. Making assumptions is our job.

\n

But making assumptions is easy. Knowing your assumptions, testing, rethinking, and acting on them is hard.

\n

As software developers it is our job to test our assumptions. So how do you go about knowing, testing, and rethinking them?

\n

For this post, I am talking about assumptions we make about how software systems work. The kind of assumptions we need to make to build, test, and debug software. However, we all make assumptions about how the world works too. Knowing, testing, and rethinking our assumptions about the world is as important as doing this practice in our work.

\n

Recognizing Assumptions

\n

When you look at a software system it can be hard to know, innately, what your assumptions are about it. You may be deeply embedded in the system and think “this is just how it works, though” or you may be familiar with the framework and have a fundamental belief about how it functions.

\n

To recognize my assumptions I need to test them by saying them out loud. On pair programming calls in planning sessions I often pause and reflect what I believe to be true about a system to others I’m talking with.

\n

I ask people to question my statements and I often start by questioning them myself. This is an important practice because it helps turn my beliefs about a system into assumptions that can be tested.

\n

I don’t always succeed at recognizing my assumptions. But pausing to state how I think the system works helps me focus on whether my fundamental assumptions about the system are true and how they might influence the outcome.

\n

Testing Assumptions

\n

At times, testing assumptions is as easy as writing some code and seeing the results. These are the easy ones. Lets say you open up an old file and notice that there are no tests. The file is complex and appears to “just work.”

\n

Testing assumptions in this case is as easy as writing tests. I frequently use tests to help me understand existing functionality. I’ll write tests that fail in order to see the correct output and learn how the system works.

\n

Other times I need a more data-driven approach. In a project a few years ago we were upgrading a GraphQL server from a very old version of Apollo Server to a newer one. We had the assumption that the change would go un-noticed by clients but we needed to test this.

\n

We built a new server to run side-by-side with the new one and sent requests to both servers and compared the results and latency. This allowed us to carefully validate our assumptions without impacting client experience.

\n

Finally, there are times when all we have is data on an event or incident and we need to figure out what happened. In these situations we need to state our assumptions about how the system works and then look to the data to validate our ideas.

\n

Rethinking Assumptions

\n

This is the hardest part. Once you know we have made an assumption, you have to be open to being wrong and you have to know what to do if it is correct.

\n

Being proven wrong is a good thing. As odd as it sounds, learning that your assumption about a system is wrong is empowering because you now know more about the system.

\n

This is where the whole process starts over again. If my assumption is proven wrong, I take in this information, look at the system again and test out a new assumption.

\n

If my assumption about a system is proven correct, I use this information to extrapolate and ask what I can learn next.

\n

Act on Assumptions

\n

I have proposed a circular process of stating, testing, and rethinking assumptions. But it is important that this process moves forward. Moving towards a better understanding of a software system enables us to make the system better, extend it, and make it faster.

\n

There will always be a point in this cycle where you have to decide that the data you have points you in a direction and you are going to continue down that path.

\n

Be wary of spiralling. Catch yourself from a cycle of self-doubt and use this process to move forward. The cycle of testing and rethinking is meant to refine your knowledge and skills. Once you have tested your assumptions about a system you can move forward in your understanding of the system.

\n", "date_published": "2024-12-20T00:00:00+00:00", "url": "https://enumerator.dev/assumptions/", "tags": ["organizational-culture"] }, { "id": "https://enumerator.dev/but-first-why/", "title": "But First, Why?", "content_html": "

In my last post, Strategy First, I explored the importance of having principles behind technical strategy.

\n

Starting with guiding principles is important, but team members can feel left adrift if they are only left with principles and no specific actions. Will Larson suggests:

\n
\n

…executives are generally directionally correct but specifically wrong, and it’s your job to understand the overarching direction without getting distracted by the narrow errors in their idea. – Will Larson

\n
\n

If you have a minute, read the whole blog post above. It’s an insightful discussion about translating a leader’s energy into collaborative, productive work that goes in the right direction.

\n

Let’s take a moment in this post to figure out how to bridge the gap between principles (the direction we are told to go in) and technical decisions (the specific actions we take).

\n

It is everyone’s responsibility to understand this–to dissect ideas from senior leadership and understand the real “why” behind their decisions.

\n

Let’s look at the principle, “we build technologies for our customers first” and a technical choice like, “we use GraphQL to build a fault-tolerant system.”

\n

Understanding “why,” or “extracting the kernel” as Will Larson says, is what differentiates following directions from embracing and working by the principles the company lays out.

\n

Let’s start with the principle “we build technologies for our customers first.” At a glance, that should sound like an obvious statement. But if you dig deeper into the culture of the company making that statement you might learn that the company has had great successes by prioritizing customer needs over technical excellence, or perhaps they’ve been deeply successful by building innovative and experimental products that customers love.

\n

The principle then focuses on the the technical solutions that the customer is excited about and values. The technologies themselves might be innovative, challenging to build, and exciting to work with. The flip-side of this value is that the company does not build technology for technology’s sake. They do not focus purely on technical excellence unless it has a payoff for the customer.

\n

Now lets look at the technical choice, “we use GraphQL to build a fault-tolerant system.” The technical leaders believe that GraphQL is a good technical choice to deliver a product that is resilient and ensures a delightful product experience.

\n

That all sounds good. But before you go build a distributed GraphQL API, you should ask, why? Why does do we use GraphQL to build a fault-tolerant system? If you were simply following directions, you might build a GraphQL API that serves the customer extremely poorly.

\n

This isn’t a post about the inner workings of GraphQL or failings that are so easy to come by. But I will touch briefly on one GraphQL concept. When a field produces an error, the nearest nullable field (either the field itself or one of its parents) is nulled out and replaced with an error. This practice means that we can return partial data to the frontend even if we encounter an error.

\n

Okay, now we understand one part of why GraphQL was chosen, because partial responses are better than no response. Now as a developer, or manager, or anyone leading an engineering team it is your job to remember this. Your company wants to build technologies with the customer in mind and GraphQL was chosen as a tool that can provide useful data to a customer even when errors occur.

\n

Now that you know the “why” behind the principle and how it led to the technical decision, it is your job to protect these decisions. Make sure that when you build GraphQL APIs they are built with fault tolerance in mind. Be meticulous about this, after all, you are building these APIs to ensure a delightful customer experience.

\n

If you revisit the statement above that the company does not focus on technical excellence unless it has a payoff for the customer, you can see where engineering team’s will focus their energy. There is a direct payoff for the customer to build fault-tolerant systems and the company believes that a well-crafted GraphQL API will help achieve this.\ncStrategy first. Technology follows. But first, always figure out why.

\n", "date_published": "2024-11-25T00:00:00+00:00", "url": "https://enumerator.dev/but-first-why/", "tags": ["organizational-culture"] }, { "id": "https://enumerator.dev/strategy-first/", "title": "Strategy First", "content_html": "

With the new year looming, I’ve been thinking about technical strategy. What does it mean for an organization to have a technical strategy? How is technical strategy related to business strategy?

\n

As I’ve worked through this I’ve come to the following definition:

\n
\n

Technical strategy is the set of principles that drive the direction of technical decisions. These principles need to be deeply informed by business objectives.

\n
\n

Technical strategy is not about technology choices. It is about the principles that guide your decisions and give your business a strategic advantage in the marketplace and it is imperative that these principles are guided by business strategy.

\n

Another way of putting this is:

\n
\n

Strategy first. Technology follows.

\n
\n

With strategy first we understand the why behind our decisions. Understanding “why” and aligning on “why” makes technical decisions succeed.

\n

Too often, organizations pick technical solutions because they think they’ll solve a problem but haven’t understood the direction that technology is taking them. Developers implement the technology because “they were told it was the thing to do” but they don’t know why it is the right thing or even if it is the right thing for their use-case.

\n

Time is a flat circle, and technologies come and go and come again. Defining technical direction without principles is a Sisyphean task of decomposing, recomposing and decomposing monoliths over and over again.

\n

Strategy needs to start with principles because we need to know why we are taking the actions we are. And these principles will only succeed if they are aligned with the rest of the business.

\n

Lets look at a practical example.

\n

Lets say you are on the technology leadership team of a startup. You know you have a bit of technical debt and some relics of past experiments, but overall, you have an app that works for clients and is making money for the business.

\n

You might be tempted to say, “Hey! lets clean things up and make them fast! We’re profitable after all.” But then business leaders come to you and say, “We want to drive customer acquisition in the next year. Can our app handle 5 x the number of users?”

\n

You are in the business of making customers happy and making your app easy to use, so what you need now is a technical strategy that can support this goal.

\n

From an engineering perspective, there are two common ways of answering this question:

\n
    \n
  1. Yes, we’ll just throw money at it and scale our services.
    2. \n
  2. Yes, we just need six months and two new teams so that we can implement <insert hot new technology here>.
    3. \n
\n

The second answer is obviously an exaggeration, but I hear something like it all too often. GraphQL will make things better! Microservices are our future! But…why? Why that technology or design?

\n

The first answer is actually not a bad decision if you use this time to understand how your system performs so that you can eventually spend less money on it to support the same number of customers. But without a guiding strategy, you might just end up spending more money and burning out your developers who are supporting your systems.

\n

A better answer is to ask, “What are the core principles we need to guide our decisions so we can support 5x the users?”

\n

Now, I don’t know your system in this hypothetical startup, but I can suggest some principles that might help scaling your system.

\n
\n

We build systems for our customers first.

\n
\n

This principle centres the customer in your technology decisions. I hate to say it, but your customers don’t care if your code looks bad. The only care if it works well for them. With this principle in mind we can focus our technical decisions on building things that delight the customer.

\n

This principle intentionally introduces a challenge. What about parts of our system that are hard to deal with but customers don’t see them? Often, the immediate effect on a customer isn’t apparent. But poorly designed systems can impact the customer’s perception of your app. That’s where the second principle comes in.

\n
\n

We build systems that are resilient and responsive.

\n
\n

Resilient and responsive are two very intentional words here. A resilient system is not one that never fails, but one that recovers–bounces back–when it fails. A responsive system scales well and feels intuitive to the customer.

\n

With this principle in mind, we can look at our end to end performance and focus in on problem areas that affect the resiliency and responsiveness of the system all while keeping the customer’s experience in mind.

\n

From here, we can start to make technical decisions. Perhaps a team member wants to introduce GraphQL to your architecture. You can now measure that against the principles and decide if GraphQL takes you in the direction the business needs to go.

\n

Choosing GraphQL, for example, might enable improved resiliency if you have the expertise to build a schema that is resilient to failure cases. However, this choice needs to be aligned with business goals. Does replacing REST with GraphQL inherently let you scale as the business leaders said?

\n

I’ll leave that up to you in this theoretical startup. Once you have the right principles behind your technical strategy, you can empower teams to confidently make technical decisions that support the business.

\n", "date_published": "2024-11-22T00:00:00+00:00", "url": "https://enumerator.dev/strategy-first/", "tags": ["organizational-culture"] } ] }