Diego Pacheco Tech blog

Rainy Days Some places have more rain than others. Some cities or regions have rainy seasons; one way or another, rain will happen. Either because it is in the season or because the players are traveling to play, and there is rain where they are right now. 

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

All engineers and professionals in the tech industry, at least one time or multiple times in professional life, suffered from impostor syndrome. Besides the impostor syndrome, as humans, we dont like to receive bad feedback. Remote work can often be a source of more silence than would usually happen in a face-to-face work environment. Everyboddy is on the call with the video off, just audio, why would you turn your video on? You are joining a new team, you don't ask questions, you wait for the last minute when you need to code something, then you "might" ask questions. It's possible you are wondering now: What do impostor syndrome, zoom calls, onboarding new team members, and asking questions have to do with such a blog post? Is it all ramblings? No. All these moments build up on something I'm calling: The Cost of The Silence. Silence is not desired; meetings that are supposed to reduce the cost of silence, like Daily meetings, fail the goal and often just bring w...

Meetings are part of our day-by-day activities. All companies do meetings, which probably is the most common practice ever. However little is done to change or even improve such practice. How many times do you see people cleaning up meetings, meaning analytically and systemically removing meetings as a regular activity? During the 2020 pandemic, everything became a meeting resulting in a Zoom call. Do you want to troubleshoot some problem, you need a meeting, do you need to ask your friend how is he going, guess what? You need a meeting.

Holacracy is an organization system where authority is distributed with self-organizing groups. I first heard about these ideas back in 2013 through Zappos's book . Culture is delicate and often moves much slower than technology. As generations are changing some values are slowly changing. Even COVID-19 is shaping how we live and do business. Holacracy has interesting properties, IMHO is all about the people, having the right talent might work in almost of forms of management systems, of course, the lots of great engineers don't care about what management systems they are in but others do. Today I want to share a slidecast I made sharing some ideas about Holacracy.

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

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

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. 

Coaching is under lots of critics down here in brazil, the critics started to happen around ~5 years ago around 2015/2014. As time pass more and more Coach role is being criticized for several reasons.  This kind of theme always gets me with mixed feelings in regards to blogging and videos because they are often flamewar subjects therefore I try no to blog about. After lots of considerations, I decided to blog some thought about it. I was wondering to blog about it last week but it was a super busy week so that why I'm writing today. During COVID-19 time my blogging activities had increased a lot since there is no place to go. Back to coaching, IMHO is not a bad thing, actually, it's good however I deeply understand why people are trying to avoid as much as possible. For these blog post, I want to talk about the Good and the Bad things about coaching and also about some forces behind it and problems which need to address no matter if you do coaching or not. I believe there ...

Getting more things done is something everyone wants. However, some people are better than others and can do more. Experience and Deep Technical knowledge play a hugely important role in this equation however there are other mindsets and tricks you can do to boost your productivity. Today I want to hare some of the tricks I'm doing over the years to boost my delivery hopefully it will help you do get more things done.  First of all, you need to understand the top 3 enemies of productivity: (A) Meetings / Interruptions, (B) Self-Pressure, (C) Lack of Clear Goals. First of all, meetings need to be bounded, you really should carefully pick how many meetings you do per week because meetings often can be very low on value because people often dont have a clear shared agenda, do not prepare well for the meeting and dont have a clear outcome or list of clear actions, having said so, meetings tend to proliferate, you really need to avoid meetings proliferation and get more outcome if you...

Estimates are lies, estimates are not reliable. It's super common to have companies doing estimates completely wrong. There is no way to do estimates right, however there are ways they can be even worse than usual like: A) Having managers doing estimating for engineers. B) Not accounting holidays, Refactorings and Bugs. C) Not comparing working items D) Ignoring variation: Different sizes, complexities, technologies, needs. E) Not understand when the system is stable or not. Very often estimates are done before the project or product start and where variation and uncertain is sky high. When we take a look into PMI, which is based on bridges and buildings we still see buildings and bridges with extreme delays, extreme over budget and poo quality. If this is true for construction engineering why the hell would not be true for software engineering where we barely have 50 years of experience as a industry compared with the +2K years in construction engineering. Project after pr...

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.

For more than 10+ years I run coaching sessions with the folks that report to me. There was a time where I had more than +30 direct reports and other times I got 3 direct reports. Currently, I have 8 direct reports to me (+40 indirectly) which I believe is almost the ideal number. IMHO 5 is the ideal number.  IF you run 1h coaching session which 8 people you still can do all your coaching sessions in a single day per week. However, if you do have 5 you can do with one afternoon with is much better and also you can pay much more attention to the people you are working with.  People come and go all the time, time to time people change life priorities and projects but as much as you can do 101s properly is crucial to improve your relationship with people not only to mention the support and speed you can provide to their career and direct benefits for your day by day projects and endeavors. Coaching sessions don't work alone, they work best with regular retrospectives and Open H...

So I thought several times if I should or should not write this blog post. First of all, I did not want all to make this post a kind of complaint. Companies have structures and roles. People tend to FIT people in the structure they have which makes all the sense. So let's say you want to build a boat, so you better like engineering and water, right? If you want to build better boats them you have 2 paths pretty much, first, you can know more about boats and get deeply involved in every aspect of the boat and therefore meaning being more technical. There is an extremely technical and deep example today of a company that does that which is Amazon. Amazon is extremely successful not only because of that but for sure they pay right attention to technical detail and really know what they are doing.  However, that's not the only path.

Kanban is a tool, it`s a culture and mindsets change tool, it`s a approach to change management. In order to make that happens we need to learn to see waste and see bottlenecks. There are several things you can do to archive that like retrospectives and peer-reviews but you also should be considering do as much metrics as you can. It could sound awkward talk about metrics on a Lean/Agile context because could easily sounding like non-sense but its not. So what kind of metric should i have, well that will depend of your system, when i say system i do not mean software but your people work system. Metrics does not need be atomic and microsecond precise you should see metrics as a thermometer rather than a raw number,

Back into 2008 i was doing lots of scrum like everybody else. I spot several issues working purely with scrum like: Issues working with delivery dates, issues working with distributed work, or work beyond the team level, issues working with FAKE Pos, or pos who could not make any call or was really afraid to make calls because a specific corporate culture. In brazil CMMI and process, unfortunately are still strong, maybe there are not strong in a direct way but they are still into a indirect way.  People often go to new methods and practices but with old culture and that does not work because as Deming said once: Dont copy the tools copy the principles in order to get the principles it require to change culture and values, for brazil old values around process and quality.