unicolet.org

In business, a cost center (e.g., IT, HR, Legal) is a team that does not directly generate revenue, regardless of how well it is perceived. Within that category, there can be teams that end up being seen as a low-value cost center. In this writing, I am intentionally conflating the two, and even push for the logic that a cost center team (from a business point of view) can be perceived as a profit center when it increases business efficiency. My explanation is that this shift into negative happens when these teams' output does not meet the required business outcomes. For example, a software team could be constantly merging code but never ship anything useful or shipping too late: output is high, business outcomes are low. ( Read this excellent paper for more details ). Any attempt on the team's part to disprove this negative perception with facts or hard numbers is doomed to fail unless it is about business outcomes. Depending on the organizational maturity, understanding how a...

In Atomic Habits James Clear writes: “You do not rise to the level of your goals. You fall to the level of your systems.” For individuals, systems are habits and for an organization, systems are the processes and behaviors put in place and displayed (or tolerated) by leadership. If you ever wondered how leaders shape (directly or indirectly) organizations, now you know.

The story of Uber depleting its entire 2026 AI budge in just 4 months has been making the rounds and while there are certainly some distinctions to be made (speed vs efficiency, output vs outcomes) I guess he moral of the story, at least for me, is that you should never roll out a usage-based priced SaaS without any cost monitoring. With monitoring in place, you can tolerate inefficiency (acceptable) while keeping an eye on runaway costs (unacceptable) and you figure out how to connect usage to outcomes.

Interesting take on how one of the most regarded teams in the world (US Navy SEALs) use a dynamic hierarchy depending on the desired outcome: The US Navy SEALs offer a compelling example of how teams can dynamically shift their hierarchy. In the field, SEAL leaders employ strict, hierarchical, top-down command and control to ensure a unified front and clear delivery of their objectives. However, in after-action reviews on base, those same SEALs will deliberately flatten their team’s hierarchy, even going so far as to remove their stripes and insignia, to encourage open discussion and reflection uninfluenced by rank. Original article:  https://www.forbes.com/sites/londonschoolofeconomics/2026/03/12/the-most-successful-teams-dont-stay-flat-or-hierarchical-for-long/

I recently came across " Things I’ve learned in my 10 years as an engineering manager " by Jampa Uchoa and I loved it so much I wish I wrote it. Here are my favorite parts:  Everyone needs to care about the product : the most evident symptom of this is not happening is when we decide to hire QA or UX because we think they have the knowledge to fix the problem. Instead, the problem stays the same, and the flow of work breaks down. 60% of your job is being the cheerleader: the author mentions being the cheerleader for the team, and I would argue that we should also be the cheerleaders for the product. Your goal is for your team to thrive without you : I don't recall who said that leaders should be evaluated on their team's performance after they've left. It was probably former Navy captain David Marquet in "Turn the ship around! "

What we call perception is other people's reality Have you ever heard somebody say: yes, but we are perceived as <adjective>? as a way to say we're not quite like that, it's their fault for not seeing us differently, etc. In other words we're not taking responsibility. Stop right there and remember that how we are perceived is other people's reality. And it's our responsibility to change it , should we not be ok with it. And it's our fault if we don't. As the saying goes: we have to deal with world as it is, not as we wish it it would be

Accuracy is more important than precision! Let me illustrate that with an example: I need to measure the length of a piece of wood, let's say its real length is 10cm. Accuracy is how close I am to 10cm in the measurement, and precision is the number of decimal places (or error range, if you want) you can read out. If I measured with an extremely precise instrument and it said the piece of wood is 9.855 cm (3 decimal places) and another one that gave me 9.9, the first one would be very precise than the second but less accurate. Ultimately the second measurement is just more useful for practical purposes. Same happens with planning and estimates. An estimate of 18.55 man days for a piece of work is only as good as it is close the real value. If the work happens to take 21 days, then just saying three weeks is more accurate (but less precise). So let's say you make a year-long plan: it's more important that the plan is accurate than it is precise because that will mean that wh...

Via The Register : He cited a use case at US healthcare company Vizient where the CTO asked employees what tasks bother them on a regular basis – the sort of thing everyone dreads having to do when they arrive at work on Monday morning. Armed with feedback from thousands of employees, the company automated the most-complained-about chores. The result? “Instant adoption, zero change management problems,” Brethenoux said. Employees then bought in to AI and started to make good suggestions for further AI-enabled automation.

A note-to-self kind of post on a playbook to turning around a struggling sw engineering team. Core principles always behave trustworthily slow down and make time to address problems do you have the right people? if you can't get consensus, seek consent Foundational engineering best practices With regards to engineering best practices, the following are foundational and should be part of the execution somewhere between steps 4 and 8 of the playbook: trunk-based development continuous integration no separate tester or devops team (this can be relaxed after the team begins performing), seek out a stream-aligned team instead SCRUM with its process is useful to align the team and at last one main stakeholder automate as much as you can, especially the parts that come up often for discussion; one obvious but often overlooked example are customized coding styles (use the consent-over-consensus principle to reach a decision) If the team resists them or does not make progress, then see the...

Another golden nugget from The Knowledge Project podcast in episode  Dr. Jim Loehr: Change The Stories You Tell Yourself [The Knowledge Project Ep. #193] : time only has value in its intersection with energy or how I have it memorized: time has no value without energy . And how I picture it: one hour on the couch has not the same value as one hour studying or exercising. And this becomes even more important when we consider our relationship with others. Dr. Jim Loehr continues (emphasis mine): Well, I will tell you, time has no value, has no valence, has no force. Until time intersects with energy, you really have nothing.” I mean, you’re just there. You can be present with your family, but because you’re there, is that going to move the needle toward being a loving, caring mother or father? And the fact is no; you’re going to have to invest energy aligned with the mission. Time doesn’t give you anything except the opportunity to make the investment of the one thing that moves the...

One of the things I always tell to those who come to seeking advice on a process improvement is the following: prepare for the inevitable downturn: things will get better in the short term, but then something bad will happen and things will get much worse than they are now. This is ok, and totally expected. Be prepared for it, know that the only way forward is through and then things will really get better. Then I usually draw this curve in the air with my hands: Most people stop at the first downturn, and that why most process improvements fail. Enough failures and people stop believing in any improvement at all, creating a death spiral. Another way to look at this is to think about is described in Gary Gruver's book A Practical Approach to Large-Scale Agile Development : [...] after you have chosen an approach you don't need to worry about getting the advantages of that design because it will come naturally. Where you need to provide management focus is on addressing the dis...

Besides Entropy , the Buffett/Munger duo is another rabbit hole I find myself going down into often in these last days of the Xmas break. I liked this quote in particular: We can handle bad news, but we don't like them late

The best people (game-changers) leave when they run out of things to learn.

Quoting myself: There aren't good or bad ideas, only good or bad executions.

 From https://techcrunch.com/2020/02/12/effective-board-members-create-value-for-startups : One of the analogies I often use for the role of a board is that of being a “mirror” to the management team. Entrepreneurs, by their nature, live on a roller-coaster ride that is matching their startup’s journey. Their perception of the business is often an amplification of the current state of the business. The highs are often more optimistic than the business might really deserve and the lows are often much lower than they should be. The board should reflect a snapshot of the reality of the business. All businesses, both the most successful and the somewhat troubled, involve a lot of sausage-making. There are aspects that are not working well that shouldn’t be brushed aside or ignored, but should be focal points of improvement. Conversely, when things aren’t going well, entrepreneurs can often be too critical of their own business. By placing things in the context of other experiences, the...

This LinkedIn post hurt 😅: The metrics they create for engineering help them convey to the board and to the other non technical department how engineering is helping the business move forward, how engineering is adding value. Not what the DORA metrics say without any relationship to what the company is trying to achieve. As a huge DORA fan, I am hurt that DORA is not the pinnacle of clarity that I want it be, especially since I have it on the deck I present the board each quarter. The fact is that Adelina Chalmers is right. The language of business is accounting and engineering performance should be ultimately connectable to bottom line impact. If it can't, there is a disconnect which will ultimately lead to a rough wake up call. So what can we use instead? A similar question was asked in the CTO Craft slack. Here is my take, straight off the top of my head (so probably still a bit rough). Considering that a C-Level/Board would be talking at the level of impact , we need to con...

Last week I was helping one of my children with their history study, and I came across something I had forgotten: the clear distinction between prehistory and history. Prehistory ends with the discovery of writing, and history begins. Is there a prehistory and history for organizations too? Can an organization benefit in a similar way as the human civilization did by committing to a writing culture? I think so. I wrote an advocacy piece on writing culture here .

Collaboration : working together towards an output . For example: collaborating on a presentation, book, song, etc. Cooperation : working together towards an outcome . For example: "customer centricity", volunteer fire departments protecting communities, different departments sharing resources but working separately Which one do you need, and when?

A bad system will beat a good person every time. W. Edwards Deming at a February 1993 seminar.

I recently picked up People and Performance by  Peter F. Drucker . If you're keen on understanding what is this manager job that everybody talks about (especially if you're new to management) this book will set you on the right path. I've thoroughly enjoyed reading it and I wanted to make a visual summary for my own use. I think it came out nice enough that it might be worth sharing it, so here it is: