Dániel Baranyi

[Dániel Baranyi @dbaranyi]

#corporatelife #csináljukazagilist

[Shreyas Doshi @shreyas]

The ability to accurately analyze why a product or experience resonates—specifically the implicit user psychology behind that resonance—is a profound unfair advantage because you end up constantly compounding your creativity simply via your everyday experiences with products.

[devleader @DevLeaderCa]

One of the biggest misconceptions in software is that you need a special title to lead. Senior? Manager?

You don’t.

Leadership shows up in:
- Volunteering to walk someone through the docs.
- Raising awareness of challenges on the team.
- Proactively sharing risks before they explode.
- Taking ownership of ambiguous tasks.
- Sharing failures and lessons learned.
- Mentoring someone through a PR.

Engineers can lead from any level. And the ones who do consistently are the ones who are recognized for it.

It's part of their brand. It's how they operate as developers -- regardless of their title.

Don’t wait for a title. Act like a leader now. The title will follow.

[Dániel Baranyi @dbaranyi]

Kormányprogram

[Sahil Bloom @SahilBloom]

The 10 most dangerous Logical Fallacies:

(bookmark this)

[Evan LaPointe @evanlapointe]

Today's thinking:

Satisficers (people who look for good enough instead of great) run completely different operations than maximizers (people who want to make something great).

At every step of the process, things are night and day different:

[Alex Lieberman @businessbarista]

I stole this idea and now use it with every single employee.

It’s the best illustration I’ve seen of teaching someone to be high agency.

It says there are 5 levels of work:

Level 1: “There is a problem.”

Level 2: “There is a problem, and I’ve found some causes.”

Level 3: “Here’s the problem, here are some possible causes, and here are some possible solutions.”

Level 4: “Here’s the problem, here’s what I think caused it, here are some possible solutions, and here’s the one I think we should pick.”

Level 5: “I identified a problem, figured out what caused it, researched how to fix it, and I fixed it. Just wanted to keep you in the loop.”

Using this framework, here’s what I say to every new employee…

You will live at Level 4 from Day 1 and as we build trust you will rise to Level 5.

Being high agency doesn’t just mean tackling problems in this way. It means your entire way of working should be oriented to being a Level 4+ employee.

Plz feel free to steal it as well.

And ty @stephsmithio for the framework!

[Shreyas Doshi @shreyas]

In my experience, most team-building events force a kind of inauthenticity that, while enjoyable to some employees, feels like a transparently contrived ritual to some others.

This latter group of employees often includes independent thinkers who won’t automagically feel uplifted after 3 hours of performative community service just so some of their other teammates can reassure themselves that they are now “better human beings” after this offsite.

These independent thinkers just do the math: if community impact were truly our goal, the money spent on the event could have created 5X the impact had we simply donated it to a competent organization.

Whether this is right or wrong for a given team or company is a judgment they must make for themselves.

But while some people get a rush of happy hormones from shouting a silly “ONE company, ONE team!” chant at the top of their lungs, others see this as childish nonsense.

And their skepticism is only reinforced when, a month later, the company lays off 15% of the very people who were cheerfully chanting “ONE company, ONE team!”.

Of course, this doesn’t mean all team-building events are destined to be useless.

The best events are designed intentionally, with a clear sense of team context and the experience you want to create as a leader. That requires true care, judgment, and time, which is a rare combination in practice.

Most team-building events are conceived logistics-first rather than goals-first. They just recycle what’s been done before, or what they’ve seen with other teams, instead of being designed from the ground up to serve a specific purpose. And so the charade continues.

[Not My Agile @NotMyAgile]

To expedite planning, the product Owner has already pointed all the stories and assigned them to each of you for the sprint. Please make sure you uphold this commitment.

#NotMyAgile

[Ryan Els @RyanEls4]

😂🤭

[Jason Fried @jasonfried]

There's nothing complicated about company culture.

Culture simply happens. It's emergent behavior. There's nothing to do, it just is.

A company's culture is a 50-day moving average. It's what you've been collectively doing as a company over the last 50 days.

How do you treat people? Who have you hired (or fired) and why? What do you when people are stressed out? How do you help people? How do you critique each other? How do you share? How do you help people who are stuck? Where's the bar on quality? How do you support customers? How do you close deals? What have you let go on too long? What have you celebrated? What have you let slide? How honest have you been with each other and yourself.

It's all that and a zillion other things. But it's all stuff that actually happened, it's not lists of things you wish had happened, or declared would happen in some ideal setting. Much of it is interpersonal, expressed both inside and outside the organization.

Why 50 days? It's enough time for patterns to emerge, yet malleable enough to be current and honest. One day, or even a couple weeks, isn't enough to stand for culture. A series of moments tied together loosely by near-term time just isn't enough to establish what it's really like somewhere. We can all be on our best behavior for a little while, but the longer while tells the truth.

Culture is the non-fiction story of an organization. It writes itself.

[Not My Agile @NotMyAgile]

Can you add a few more tasks to the sprint? We want to make sure everyone stays 100% busy all the time. That’s what agile efficiency is all about!

#NotMyAgile

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

I don't believe in "junior" programmers. It's a pejorative, a way of asserting one's own superiority. I do believe in "effective" and "ineffective" programmers, and that has nothing to do with age or how long you've been programming. I've met ineffective programmers (many of whom looked down their noses at the "juniors") who have been ineffective for their entire careers.

Both categories of programmers make mistakes. Neither category knows everything. The difference is that effective programmers are eager to learn and see their mistakes as learning experiences. I also usually see a correlation between effectiveness and a willingness to admit fault and get help. That's easiest to do with psychological safety (Google it—it's not some woo-woo hippie concept) and a collaborative environment where people at all skill levels literally work together.

The good news is that it's never to late to start learning.

[Gergely Daróczi @daroczig]

Please help me bring visibility to our new project (monitoring cloud offerings with pretty damn cool hardware info and performance benchmarks) by retweeting this post 🙏

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

Here's all that matters when it comes to Agile—everything else is complete crap:

"We are uncovering better ways of developing
software by doing it"

It's entirely about learning based on experience. Uncovering, not uncovered.

"Individuals and interactions over processes and tools"

Rituals, ceremonies, Sprints, SMs, POs, various meetings. NONE of that is useful. Dump it all. Talk to people. Get feedback. Pay attention.

"Working software"

Anything that's not directly putting working software into customer's hands is just waste. Stop it.

"Responding to change over following a plan"

We learn as we work, we adapt based on what we learn.

That's it. Anybody who says "Agile" is anything other than that is selling you snake oil. Any corporation that's calling anything other than the above "Agile" is either delusional or evil.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

The Toyota Production System (TPS, usually called "Lean" in the West) defines three sorts of difficulties, all of which apply to software development: Muri, Mura, and Muda. They're all worth thinking about.

Muri is long-term overburdening of the entire production system (e.g., too much work for the people at hand). That's not waste so much as creating a system incapapable of doing the work. To my mind, Muri also encompasses inappropriate organization architectures, where the management structure is fighting against working in effective—all too common in larger corporations, but you see it everywhere.

Mura is variation in the work to do. The biggest cause is usually random show-stopper bugs in the drop-everything-and-fix-this category. Variation can also happen at a macro level, for example, tax-related software that's used only once a year, so all the bugs surface over a couple of weeks rather than continuously throughout the year. In general, the more variation you have, the more buffering and slack time you need in your schedule to absorb it.

In the Muda category, TPS defines eight categories of waste (all of which apply to software). I use the acronym DOWNTIME to remember them:

* Defects (of all sorts, but bugs and technical debt).
* Overproduction (is related to Inventory. Producing software we can't sell—often because we're not validating products before we build them)
*Waiting (all sorts of dependencies cause waiting, as do processes that mandate lots of meetings and the like).
* unused taleNt (punnishing people as "unproductive" instead of training them is a big one here.)
* Transportation (when the work needs to move from one place to another—from product to dev or dev to test, for example—you have delays).
* Inventory (work done that has not been released to customers. Money spent without a balancing revenue.)
* Motion (too much process. too many meetings. Lots of motion, but no progress).
* Extra Processing (building more software than you need. futureproofing).

Of course, all this is just the tip of the waste iceberg, but it's a good start.

[Extinguished Engineer @ExtinguishedEng]

> We don't want developers talking to users and stakeholders because they might say something that sounds like a commitment.

What happens when developers aren't involved? A variation of the exact same problem, only worse. 1/7

[annie @soychotic]

Putting non-tech millennials in tech and giving them titles like “Product Owner”, “Project Manager”, and “Scrum Master” is just a modern Stanford Prison Experiment

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

“[Agile] does not attempt to forecast, it attempts to be as productive as possible while not knowing the future. It focuses on resilience as a risk management strategy, not anticipation.”
Chris Morris (@the_chrismo by way of @tottinge)

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

POs do not design the software. Their job is to understand the market and sort the backlog (and contributing that expertise as the team works). That's it. IMO, they shouldn't even be collecting stories or "refining" them, at least not on their own. The pathological case is a PO spending all their time parked in front of Jira adding details to tickets. That's something that the team does just before and during implementation. The world does not need ticket monkeys.

[Allen Holub. https://linkedIn.com/in/allenholub @allenholub]

This chestnut pops up annoyingly often. I can guarantee that businesses DO NOT want to build something that nobody wants on time and within budget. Firing people who are not meeting fantasy deadlines that management pulls out of their ass (or which they force programmers to pull out of their's) will destroy your company. Firing people because they tell you things you don't want to hear (e.g. "we can't predict that") is an equally destructive path. Software development is inherently unpredictable. Pretending it's not is just self delusion. You cannot run a business based on fantasies and bullying. If you really want to run a business "in the real world," you need to accept reality and then plan around it. Planning around fantasy is not that.