Diego Pacheco Tech blog

Ambiguity is not simply having a difficult problem. It is not knowing exactly what the problem is, what matters most, or which direction will create value. It appears during requirements, scoping, analysis, and design—across the whole solution space. It also appears across teams: product, design, engineering, and the business. Ambiguity has always been one of the hardest parts of engineering. Agentic AI makes it worse at scale. A human engineer receiving an ambiguous request may push back, ask questions, make assumptions, or stall. An agent immediately produces something: code, commits, documentation, and a confident summary. The output looks like progress. It may have little to do with the outcome anyone wanted.  We always had this problem, but now agents are a huge employer.

Every single day, engineering teams need to do magic. Such magic manifests in several different shapes and forms. It could be by making hundreds of assumptions, figuring out what to do with little to zero context, and delivering decent solutions with proper architecture, design, comprehensive testing, and value via continuous delivery. It's a lot. In reality, most industries use Scrum/SAFE, which is far from the best way to work. In theory, when you are doing Scrum, if you do not finish a story during the spring, it's not a big deal; you go to the next one, shift the stories to the following spring, and it's all good. However, in reality, it is not exactly like that, unfortunately. That happens for various reasons: ignorance of what proper agile looks like, irrational pressure, industry pressure, and hundreds of other uncontrolled and hidden variables. Lean is all about learning to see waste, remove it, optimize it, and improve it with more quality. Companies, unfortunately...

After 7+ months of hard work, my third book is out. Introducing:  Continuous Modernization : The never-ending discipline of improving microservices, monoliths, distributed monoliths, individuals, and teams at scale. Modernization is something I have done over and over in my life. Modernization is something that all companies need and will always need. The need for modernization will never go away, even with LLMs and AI. Technical debt, Anti-patterns, and bad decisions do not take days off. Complexity never shirks and continually grows. Companies do not stop getting bigger and doing more and more software critical to growth, delivering value to customers, and staying competitive and relevant in the market. We need a better way of doing software to drive the best outcomes out of us. Continuous modernization is the counterforce to technical debt and anti-patterns. Continuous modernization is how to continually improve, even when you think it's impossible and nothing can be done. We ca...

Software is very interesting, it's amazing how little things make a huge difference, being able to see all the small intricacies and how the pieces fit together is a complex and fascinating task. The more we understand, the more we learn effectively, better we can do it. Software complexity does not reduce, it only grows, working with a relentless mindset of continuous improvement is the only way to go forward. Refactoring is often seen as a "bad word" a big spooky thing because everybody believes is busy, so why are you risking breaking a lot of things if you can move forward and "live" with the problems. XP (Extreme Programming) got this right from the get-go, you need the principles and values. XP has a value called: courage; courage to do refactoring, especially when the conditions are not in your favor, considering monoliths and distributed monoliths the odds are never in your favor. Once you start doing so, slowly put all guardrails in place, would such c...

XP (Extreme Programming) leaders popularized CI (Continous Integration) in the late 90s. The idea was very simple, to continuously integrate code in a common branch usually called trunk, nowadays we call it main. The principles behind CI were (A) Reduce feedback cycles (B) Increase response time and release software faster. CI it's a powerful concept, that requires automation of the build process and of course, automated tests. In order to do CI you also an SCM (Source Code Management system), in the past there were various solutions like CVS (not a drugstore), SVN, and GIT rules today. By definition CI also requires continuous merging, which leads to interesting realizations like, how often should we merge, the answer is as much as possible, as frequent as possible. Today's environments are more complicated than they were in the 90s, back in that time, the CI process was generating one single binary. 

Last month I was blogging about how code review is dead . Today I want to share some principles and practices to make things better. In the previous post I shared some actions, now let's understand the principles behind many of these actions.  First of all, can we save code reviews, and make them better, for sure we can. It's not that hard, for the code review it self-improve we need a couple of things in place. Usually, engineers have the same complaints like It takes a long time to do code reviews, there are too many files, I don't know this code or this service, etc... The fact is there are multiple mindset problems here. 

I want to share my cents about the post: " On the Diverse And Fantastical Shapes of Testing ". First of all, I believe this is a very interesting subject and yet still see very few engineers talking about it. People mostly take tests for granted. Secondly, I would like to acknowledge the parts I agree with on this post mainly around the concept of Sociable and Solitary Unit Tests are quite useful and show be widespread. Also with the need for teams to have reliable, fast, Bounded(Isolated) and not Flacky on Justin tweet . Now that I acknowledge that, let me elaborate on what I think we are missing and why IMHO the pyramid is dated and we need a mentality shift. I have 4 points I want to elaborate on and give more context.

Every company out there works with teams. There are all sorts of teams such as teams specialized in technology stack like Hadoop or teams which are domain-driven and have cross disciplines( Cross-Functional Team ) inside such as backend, frontend, QA, UX, Architecture, and more. People don't leave companies they leave teams, also it would be accurate to say that people don't join companies and they join teams. So should we have dynamic or static teams? Should teams self-assemble or should we have PMO doing that? Should the teams be stable or should we allow dynamic reteaming? Is work always fitting well in our team's structure? What about Platform vs product teams, which one is best? Should we just pick one model or should we use different models? Should engineers organize around managers or managers organized around engineers? Teams affect Architecture and our perception of ownership. Teams should be a people organization but often is just a grouping of people where everyb...

Like we say in Brazil (Todo Carnaval tem seu fim) all carnival has an end. This is the end, my friend. It's the final slidecast on the series. If you did not watch  part 1 and part 2 I highly recommend you do. Part 1and 2 I covered +40 books, 20 each slidecast, and today I will cover +20 more. Total +60 books. Even if you dont agree with all ideas here I recommend you watch them because you will see common patterns and connections between books and might get some insights or reading recommendations. So Let's get started! 

Lean / Kanban was always about managing work instead of managing people. Often mention as Manage the flow. Organizations are about organizing people, but they should be about organizing work instead. As organizations grow, it's harder to make an impact and easier to get benefits. Safi Bahcall, the Loonshots book, says that as organizations are growing, the perks become much easier to get rather than impact(outcomes). That's why politics and empire-building strike. Leaders need to be explicit about managing flow. Otherwise, organizations tend to focus on local hierarchies and produce local optimization(classical Lean issue).  If we should manage work/flow instead of people(Some coachs also called it to manage the system). Should we have teams? Are teams silos? Are silos always bad and wrong? When should we create a team? When should we decommission a team? Work often happens on teams, people leave and join companies because of teams, but would teams get into the way sometimes? ...

This is the second post on the series of management the non-obvious. I highly recommend you check out the first post . For the first post, I shared +20 books which was the base of the ideas of the first slidecast. This is the second slidecast. In this second slidecast, we will continue covering some non-traditional ideas and I will recommend +20 books again. Books are portals to other dimensions. We have several cognitive biases in our brains that work against us. We also live in a world that the bad things are repeat over and over and the good things are faiding. So it's really important to spot and think about it. Often we think we have all the answers and just need to execute something, is that so? They allow us to see things we were not seeing before. So I hope you guys like it. Let's get started.

We often dont realize how much we run into the autopilot mode. However, is the autopilot going in the direction that we want? Are we learning what we want to be learning? Are we investing where we want to be investing? Often the answer to this question is no. So how can we change direction? Would be awesome if we had an interface like google maps or Waze where we could just type another direction that we want to go and we would be driving there? Where the direction is a goal that we want to archive rather than a place. Plans often are problematic since the world is dynamic and plans are static. So what can we do? It's possible to slowly shift to the desired direction and here is what we can do. Let's get started! 

This is a pretty interesting book. I really love this kind of book where the author challenges the common sense and traditionally established truths that are not so true actually. Work is something we all do and I often think differently about it. Nine Lies about work sound arrogant but actually is not. The book is full of examples and scientific studies and argues very well on the spot. We are living a global pandemic(COVI-19) and that changed all our lives, that shows how fragile we can be. I personally was always into Lean/Agile and never was a fan of traditional management culture. So buckle up this book might shake up you a lot since will challenge traditional things like People to need Feedback. I often like feedback and worked a long time(~11 years) living strong and daily feedback however even that being a strong truth for me, the author managed to show me a different point of view(wit studies of course) and I still like feedback and strong feedback cultures but I see there are...

Around 2015 there was a huge fuss about Digital Transformation. 70% of all Digital transformations fail(According to Tony Saldanha ).  For sure, you are thinking, this is because of the lack of proper Talent Pool, or wrong technology choices. Fore sure that things matter a lot, but surprisingly the number #1 problem is lack of discipline. Lack of discipline in Defining and executing the right steps. IMHO lack if discipline is also the issue of why hard things dont get done or executed. To define and execute the right steps, you need to have VISION and know what you are doing and what problems you are fixing. If you dont understand the problems you are fixing, how do you know you are fixing the right ones? How do you know you are doing the right things? Well, often, companies don't know, or they think they know.  99.999999% of aircraft takeoffs and landings  are successful  compared with only 30% success in digital transformation initiatives. 

Threat Analysis is not a new concept. It's being around since the 90s. Threat Modeling is becoming more popular thanks to the DevSecOps movement. There are several other open-source Modeling tools such as  OWASP Threat Dragon and  Microsoft Threat Modeling Tool.  Threagile is an agile and open-source tool for Threat Modeling. The cool thing about Thredagile is that the tool is based on declarative modeling using YAML files. Threagile is built with Go language. One big advantage of open source software is that we can always look at the source code and even change it if we need it(i.e Understand how the RAA score works ). Security awareness is something that still needs to be work with engineering and product teams. This tool is a great way to tear down walls between InfoSec and engineering. Threagile is also dockerized making it very easy to use and play with it. Easily you can version the YAML file in your service repository and generate the reports as part of your J...

Agile is a wasteland . Don't believe me? Read Kent's Beck(Creator of Extreme Programing) article . IMHO Agile has been in decay since 2013. However, Agile become mainstream since 2000; in Brazil, agile become mainstream in 2015, more or less. Success means misuse. The demand for agile is very high in some countries like Brazil and quite inexistent in Europe and the USA(mainly Silicon valley). Scrum has often sold dogma and easy answers with easy certifications. Scrum is really a big part of agile being mainstrain and also why it is such a shit show. There is so much demand in some places and literally very few people who really understand the software and digital products which greats a very complicated enviroment. So having said that, should we drop agile completely? Well, in some sense, yes. Things we just do because of Dogma and we dont understand and really dont add value should be dropped 100%. However, would all problems just go away? 

  So if you read my previous post , I saw saying that for Platform / DevOps you dont want to have 1 single team but several small teams actually. However, when we are talking about Product Teams I believe we need to go the other way around. Could we have small teams in the product and yet be a good thing? Well depends. IF the Product teams are completely autonomous and selling their own product or completely independent module in sense of the business (Meaning autonomy is a business construct). Well for that case yes, have smaller and more teams will make sense however in practice what happens is the other way around. What happens is that many small product teams tend to create small microservices with have dependencies on each other and at scale, it becomes more problem they benefit. In order words, business verticals or bigger scoped SOA Services would make much more sense and also would fix several problems that small services at scale tend to create. If you want to know more ab...

DevOps it's a mindset, Skillset and it's not a Department. It's very common to see in the technology industry Centralized and Unique DevOps/Platform Teams. IMHO we are still not there. Most companies are still catching up on AWS and DevOps Engineering skills such as (Networking, Terraform, Observability, OS/Linux, etc...).  So DevOps centralized teams tend to be "Gate Keepers" for good practices and hygiene and several times cost zealots. That's is fine and has value, dont get me wrong. However several times unique and centrlized teams are just a pure form of a bottleneck. AWS has great infrastructure and tons of purpose-built services, I would argue most of the time you dont need to build anything in front of it. Using AWS directly could be coupling but as long as you use open APIs you should be fine. Several years ago I use to be bottered by coupling solution with ORACLE and with AWS the coupling is much bigger, not sure if any company would ever leave AWS, ...

Agile is around for at least +20 years. However, one big complaint was "how can we scale agile" or "how we go beyond teams". You might consider business agility as the 3rd wave of agile.  But is really hat the case? The world changed a lot in the last +20 years there are many other things to change in the next years. COVID-19 amplified lots of the issues that was already in place.  It's really business agility something entirely new or just an aggregation of previous movements, practices, and values? Business Agility is a hot topic right now, lots of people talking about, very few really doing it. It's hard to get real agile teams nowadays, imagine whole orgs being agile, even harder. IMHO to make the org agile is super hard, however, some of the reflections that business agility is proposing sounds right in the sense we might be asking these questions anyway. 

I'm doing retrospectives for more than 10 years. I saw it all, the good, the bad, and the ugly. Retrospectives are fundamental and instrumental part of Agile. Even if you are not doing Agile or is not agile-ish in our way of work I would 100% you need o to have some form of retrospective. Retrospectives are an important mechanism to introduce improvements. Pretty much all companies spend lots of time in planings sessions. Long planing sessions are pretty normal(4h or more). However long retrospectives are not popular at all. It's possible to work without classical retrospectives however you would need some form of Reflection and Guilds/Chapters might be a place to have retrospectives. IMHO Retrospectives is something you want to do without mercy(Maybe I'm watching too much Cobra Kai ). Meaning you should do lots of retrospectives. Retrospectives have different flavors and styles however I believe there are 2 important ones: Big & Micro. Retrospectives help to change t...