Let's talk about "seniority" - but not in the usual way, in a context of career progression. I'm more interested in speaking about the "seniority" itself, regardless of specialty/path chosen, compensation, labels & position names. It's the kind of discussion that revolves around the following questions: what makes senior "senior"?how to measure/compare "seniority"?does seniority have boundaries? (what is the ceiling, how to recognize it and ... what happens when you reach it?)Answering these questions ain't trivial & every organization does it its way (or pretends the problem doesn't exist ...). I have my ways as well: dimensions,…
All posts in Teamwork
This blog post is all about: what can be (effectively) visualized, when visualizing works (brings benefits), what does it mean that visualization is "effective", why visualization makes a difference, why visualization is not just about sketching something that comes to your mind.One of the defining moments in each professional Software Engineer's career is when (s)he realizes her/his limitations - that (s)he can do only about as much but not more. That it's not possible to up-scale her/himself anymore & out-scaling is the only option (if one is really determined to achieve MORE). That is the…
This blog post is all about: a special kind of contract that is almost never written down, comparing rat-race with inspired evangelism or a quest for workplace happiness, what does happen when "social contract" is broken (& why does it happen), why respecting "social contract" (and first - having it at all!) makes such a difference.I've started few series of blog posts - one related to compensation, another to the level of commitment required to achieve the success, but ... I've recently found out that I can't conclude any of those without introducing one important concept (that rarely gets named…
This blog post is all about: the Mother of All Rules; consciousness of assholes; why being an asshole with almost 100% certainty eliminates the possibility of building up sustainable, high-performing team; what's the problem with sarcasm (& how easily it can be solved); How not to be an asshole (it ain't that hard, really ...) Each week I'm trying to share some thoughts & frequently even make some advice to you: about architecture, leadership, technology, management & what not. And still, until this very day I didn't mention THAT. The most important advice. The most valuable rule. The mother of all…
In this blog post I'll describe why remote work != remote work, what's wrong about satellites and isles, why differences in communication bandwidth are worse than overall low bandwidth and what does it have in common with osmosis & water cooler.No, I'm not going to describe pros & cons of a remote work in depth. This is well covered in many sources & in a way I couldn't have matched in a blog post (or even series). My intention is to address a very simple & well isolated issue: plenty of people, encouraged by some commonly known successful examples of…
This blog post is all about: cognitive bias (one particular one), how quickly we get used to "the new normal", how being insatiable when it comes to knowledge can make us ashamed, why we get annoyed when some junior pops up with "microservices now!" idea, why leader in the trenches may help (& what does it really mean).Habit of fooling ourselvesYou've heard/read about cognitive bias, didn't you? If not, you should definitely read up - there's zillion of resources on them available on-line, e.g.: http://www.visualcapitalist.com/every-single-cognitive-bias/https://betterhumans.coach.me/cognitive-bias-cheat-sheet-55a472476b18https://rationalwiki.org/wiki/…
TL;DR Even today, many treat leading teams as a modern form of livestock herding. Limit the information (to avoid distraction), assign tasks, make a checkpoint each week, force controlled crunch before deadline, rinse & repeat. Fortunately, we can do so much better than that, if we manage to break some basic mental barriers - first: leading can (& should) out-scale; second: leading doesn't have to take ownership from team members; third: leadership is about communication (hence: understanding), credibility (hence: trust) & initiative (hence: driving actions). There are some topics that never stop popping up: even if in different contexts,…
TL;DR If you see that teams "reject" the (part of) codebase, working with it lowers their engagement level, they have neither energy nor will to tackle its challenges, it's very rarely the matter of codebase's size. Sober-minded engineers just do not want to have anything to do with crappy code, especially if they don't feel responsible for its "crappiness". What they need is not their nametags pinned to particular mounds of dung, but a viable, credible & feasible strategy to dispose it. Code ownership problem is almost as old as teaming in software engineering. At…