Diego Pacheco Tech blog

Let me remove the obvious issues before I make my point. Ignoring problems is bad; ignoring problems at scale is even worse. If we have a network effect of ignoring things at scale, that's the worst thing we can do. Ignoring problems leads to Ignoring culture . Being aggressive with problems is not being reckless; it's not about moving so fast that we break things by doing it so. When applying for software, we ask some apparent questions but sometimes forget to apply for people. In software, we don't want to discover all the bugs in production; we want to shift left and find as many problems as possible before going to production. We must apply the shift left to people and address the issues immediately. The sooner we find problems, the sooner we fix them, and the sooner things improve. 

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...

Security is the new black. Years ago Tests were not widespread as they are today and the same happened with DevOps where automation, Infra as Code, Versioning become the norm today. However, for security, we are not there yet. I believe this will change in the next years and more and more security is a concern where the teams need to care about and understand more about. Security can be pretty scary but at the same time is not rocket science and you can learn it for sure. Today I made a slidecast which I want to share with you guys and go over the security principles, common vulnerabilities and attack vectors, culture, trends, and much more. So Let's get started!

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.

I had experiences where every single service had to be a ticket with an architect document in order to be able to start using every new technology or service. So every engineer hates to work like that. I personally dont think thats the why to roll because thats means that process wins.  Netflix is famous to have a culture where they threaten people like grown-ups. So if you have grown-ups why do you need to review every single thing people do all the time? For sure reviews are a good thing but architects as Gate Keepers are not a good thing. In general Gate Keepers(DevOps Engineers) as well is as bad as Arch as Gate Keepers. I have mixed feelings but personally, I dont think there is value in having Gate Keepers which is a very poor solution and IMHO a poor usage of people's times. So Why gate Keepers exist? 

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...

Social media is about attention. Real-time chat apps like Messenger, Whatsapp, slack are about attention. 101 meetings are about attention. We live in an attention economy. Everybody whats a time-share of you. A long time ago I disable ALL notifications from Slack, Skype, Whatsapp, Facebook(is closed most of the time of my day) and that is one of the best things you can do too. Not only for your mental health but also to put you in control of your time and therefore your happiness. Interruption is the ultimate killer of deep and meaningful work. However, we also need attention and we might need positive attention much more than feedback(Nine Lies about work).  Humans' attention is a very scarce commodity. I'm not judging anyone: Some people cannot read articles bigger than 5min or videos bigger than 10min. Not for accident Twitter originally had a limit of 140 chars(I miss that :-) ). Attention economy is about information management which threatens human attention as a resourc...

Traditional management often sucks. Main because the focus is on control, time management, and micro-management. Plus, traditional management does not learn and just repeats the same process repeatedly and expects different results. I prefer modern incarnations like Coaches or even Engineering Managers.  I'm aware that Agile Coaching is a bad word in brazil because of Scams, but it does not mean it is a bad thing - It really depends on the people. People are more attached to managers than you can think. People do not know quite companies, they quite they managers. That's why management is a super important element of companies culture. Companies are complex. Complexity is everywhere; at the same often people just game the system rather than have complex and systemical thinking. So if you want to change the culture, you need to change management., Today, I would like to cover some non-obvious aspects that can deliver a better culture and, therefore, better solutions and better m...

So this is not a post about Slack(IRC/Chat application) - there is nothing about instant group messaging here. Slack also means LOOSE which is the opposite of tight. We all know Debit as bad. We all know Debit slows down execution and increases maintained cost. So why do we still suffer too much about it? IMHO there are several reasons that go from Bad management, Lack of Vision, Poor Tech Talent Pool, Lack of Software Ownership and Culture. Recently I finish Upstream from Dan Heath, which is an amazing book about product discovery but also about Software Architecture and Team Organization(Because both are the same :-) ). Dan has other amazing books like Switch . Which I highly recommend it. 

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, ...

Previously, I was blogging about two very HOT Button Issues ( The Death of Microservices and Why Waterfall can be better than Agile(Sometimes) . Today I want to expand and correlate these two topics a bit more. It's important to say again that I like agile, and I do it for +14 years. I have no problems talking about Agile issues. You shouldn't either. Hard questions sharpen our solutions. There is a huge difference between go trough a set of hard questions to justify investment harder than power or politics game to archive a result. The difference is one is healthy the other is not. There are "Healthy" matters like: Coupling, De-coupling, execution, Agile / Waterfall we should be able to navigate, talk, analyze trade offs without dogma or any issue whatsoever. However is hard to us to talk about some subjects right? What happens is that there is so much FEAR and TABOO on companies that some subjects cannot be ever on the table. Effective Learning means, we can talk...

Sounds crazy, right? How could that possibly be the case? Before I continue, I need to say I',m doing agile for +14 years non-stop, and I sincerely believe Lean / Agile does good things. However, like everything in software, there are trade-offs. You might be thinking(Crazy Brazillian), and Agile is about incremental, fast feedback cycles, effective learning, and practical, tactical way to avoid waste and risk by shipping code to production often. How could that be bad, after all? To understand the hidden trade-offs here, we need to understand what is behind the principles of Agile. Hold on bozo; there is no such thing as assumptions behind principles. Recently I was challenging microservices . Today is Agile, tomorrow I don't know but something else might come up. To some degree, I feel agile needs to be challenged because last time I did it was around 2015. It's healthy to disagree if it helps to harden your decisions and as the whole team/company you take better decisi...

Estimates and a very huge concern for pretty much company doing business now a day. Especially during COVID-19 times I dont belive the questions like when something will be done will be out of the table soon.  However, is very hard to get estimates right but is possible to take action to reduce the blast radius of estimates and try to get something reasonable.  Today I want to share a short video I recorded some thoughts on estimates. If you are following up muy blog you will see these ideas were published in previous posts if you did not read my latest posts on similar matters you can read it here: 1 , 2 , 3 , 4 , 5 , 6 , 7  and 8 . In this video, you will see why estimates often go south and what we can do to improve and deal with estimates in a reasonable way.

I'm working with Agile methods since 2006. In this last +10 years, I learned a lot about Agile Principles, Lean Principles, DevOps, Lean Startup, Lean Discovery, and much more. Today I want to share 4 pieces of training I did from 2010 to 2013 which I compressed in 2 videos. In these videos, you will see agile principles, lean principles, coaching techniques, agile coaching techniques, and tools and also experiences and lessons learned in this +10 years working with engineering teams. Fortunately or unfortunately the videos are all in Portuguese, the slides are in English but the videos dont :(.  I hope you guys enjoy and have fun and hopefully learn something that you can apply in your time. These videos are focused on for those who are tech leaders, managers and agile coachs who want to learn more and want to know how I operate with my teams.

Feedback can help people to get better if you use as such. Feedback is often a vision based on your own experiences, so if you dont have great vision often could become just a opinion, what the problem with opinions well they may very depending on your humor. You get better feedback if you feedback process is based on Lean/Kaizen in other words it means you have a culture of continuous improvement with no blame, no pointing finger and learning. If You dont have the right culture around feedback could just be a form of trade of politician manipulation.  You do provide better feedback to people if you try to wear they sues and think about they on they experiences. You will have success most likely if you help the person to figure out whats going on with her/him. Feedback is about self-awareness, people from outside maybe have a better vision of our problems but that does not mean they know what is the solution.