IT Consulting ‒ The Soft Parts
This article is work in progress. Originally published on 2026-01-25, I still have a lot of things I want to talk about, but maybe you already find it valuable.
You must never allow yourself to forget that consulting is the art of influencing people at their request.
The Fourth Law of Consulting
Gerald M. Weinberg: The Secrets of Consulting
I became a consultant because I wanted to solve problems, help people, and ideally make a living doing it. I also wanted to develop software, but that’s not why I became a consultant, it’s why I became a software developer years earlier.
I also wanted to code, but that’s not why I became a software developer, it’s why I became a programmer as a teenager. To “code” games, mostly. Nowadays I still code (one way or another), but it feels like much less of an important activity compared to everything else in software development, and even less so in consulting. What I do includes coding, but coding is not “what I do”.
Software development and IT are often thought to be mostly about machines and “technical” skills. In reality, they are much more about humans than one might think, and even more so if you’re in consulting. Many of the so called “soft skills” are not obvious at all, and developers (especially young consultants) sometimes plateau once they reach a certain level from mostly technical expertise. To me, being a consultant means not only being at least as skilled (at least in certain, impactful areas) as the average non-consultant with similar experience, but also being able to influence others, the whole team, or even the organization as a whole. Many problems that seem like technology problems on the surface are actually people problems or organizational problems once you look deeper, and that’s often where the most unrealized potential lies.
The First Company or Client can be Very Formative, for Better or Worse
Cucumbers get more pickled than brine gets cucumbered.
Prescott’s Pickle Principle
Gerald M. Weinberg: The Secrets of Consulting
If you’re new to the industry, or you’ve been in your first team for a long time, then their ways of working are pretty much all you’re familiar with. As a beginner, you’ll likely learn a lot in any team, but you probably also absorb some anti-patterns which they think are the only way to do things. Sometimes well-known anti-patterns are even called best practices if you ask the wrong person. Like the cucumber in brine or vinegar, your environment probably influences you a lot more than you influence it, especially in the beginning. So, what can you do about that? Here are some personal suggestions:
- Talk to likeminded people. Participate in communities of practice. Go to conferences (or watch them online).
- Question every habit and practice that you see in your day to day work, even if you may need to adopt it yourself in the short term. Many misconceptions or bad practices that are especially common in our industry can easily be disproven with a quick online search. Often they are “what we’ve always done” in that team, and the people who originally made the decision aren’t even there yet. Many of the practices that actually work in the long term are especially rare in the industry, mostly because they have a learning curve and are difficult to adopt when you’ve learned the opposite for years.
- Read about a wide range of topics related to the industry, beyond what you’re already familiar with. Often the things you would benefit from the most are things you haven’t even heard of yet.
- Change your environment. For a consultant, this might mean changing clients instead of employers, which I see as a great benefit. Don’t stay in the same single team or organization for an extended period of time in the beginning of your career, unless you do enough of the other suggestions to avoid becoming “pickled” by your environment more than you “cucumber” it. This becomes much less important once you’ve seen a variety of teams, organizations, and ways of working.
Picking Your Battles
When you join a new team or organization, and you’re experienced enough to know what good looks like, you might notice lots of dysfunction: Things like lack of communication, no culture of quality, inefficient processes, long lead times despite everyone rushing as fast as they can, lack of experience or of certain skills, multiple teams of one (i.e., everyone working alone), frequent large merge conflicts, etc. It’s rare to join a team and everything is already running flawlessly. In my opinion, sometimes consultants are actually most valuable in an environment where there’s a lot of room for improvement, because improving the environment is what we do. I like to call it “leaving the team (or organization) better than I found it” in reference to the boyscout rule. Of course technical expertise is also important, but it’s more of a baseline expectation, a prerequisite, rather than the main reason for hiring a consultant.
What’s likely going to happen if you join the team and immediately want to “fix” everything at once? People will get defensive. You will try too much at once and accomplish very little. You’ll get frustrated, burn out, or want to leave for another team where things are already “better” from the start.
Instead of wanting to fix everything immediately, try to be patient and observe long enough to understand. Maybe this anti-pattern or bad practice or tool existed for a long time already, and a few more weeks or months won’t really make it worse. Try to understand the reasoning behind it (sometimes it’s “context”, but often it’s “it’s always been that way”). Maybe you still need to prove yourself in the new environment, so it might be a good strategy to start with smaller problems first and work yourself up to the bigger problems over the next few months. If something is annoying, but not actually a big problem, try to accept it and focus on more important, but less noticable problems (these are often subtle but impactful missed opportunities rather than immediate problems). Dan North wrote about the Rule of 53, which is the phenomenon where you have 53 problems to fix (a symbolic, arbitrary amount), and you make a conscious decision to fix only the three most pressing problems while accepting the other 50 the way they are, at least for now. That way you don’t spread yourself too thin, and you need to be more intentional about which problems are actually worth fixing in the time you have available. There are likely some problems that you can solve next week, and some that you will be able to solve in six months, and they all have different levels of impact.
Some personal examples:
- At one client engagement there was a “merge team”, a small set of rather senior developers who were allowed to merge pull requests and resolve merge conflicts. One of the first organizational/process improvements I achieved there, maybe a few weeks after joining, was to help the project leads and the merge team see that they don’t really have the necessary context when they went through the list of PRs and merging all marked as approved. Instead they were just creating another bottleneck preventing flow of code changes through the system while reducing the sense of responsibility of the developers “causing” (or being involved in) the merge conflicts. Dissolving the merge team was kind of a low hanging fruit with immediately noticable improvements, like pull requests being open much shorter on average, and fewer merge problems (like merge conflicts, or PRs being merged into the wrong branch). The developers now felt responsible for resolving the merge conflicts that they previously didn’t even see, and to even prevent or reduce conflicts by integrating more frequently and being aware of their “surroundings”. We didn’t stop there, and there were bigger problems too hat we tackled later and improved incrementally over a longer period of time, but it was something that was impactful, easy enough to achieve early on, and it helped build trust for continued improvements later on.
Brandolini’s Law
The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it.
Alberto Brandolini
Alberto Brandolini, best known for Event Storming, coined this law in 2013, even long before generative AI accelerated the effect even more.
Skill Acquisition
As a consultant, you’re not just expected to have knowledge and skills that you can share with others, but also to continuously keep learning. Learning is part of the job, which doesn’t necessarily mean that learning “on the job” is enough.
The T-shaped Developer
T-shaped competence is a commonly used model for a well-balanced professional, not only but including in software development. The vertical bar of the T represents deep expertise in a relatively narrow field, and the horizontal bar represents fundamental knowledge in a wide area of (possibly related) fields. In my opinion, it is often interpreted too narrowly: It’s how you get things like “Java developers” and “React developers” as a specialization, with few transferable fundamentals.
I prefer to interpret it way more widely. The specialization alone is much wider, like software development as a whole, or maybe enterprise software development. This alone already requires deep expertise, but it’s not limited to a framework or a language. I imagine the horizontal bar also much wider and “thicker”, representing fundamental knowledge considered by many to be outside of software development, like product management, testing, operations, psychology, soft skills, and domain knowledge.
What happens when you specialize in a single tool or framework and it becomes obsolete after a few years? You’ll specialize in the next thing, and the old expertise might not be transferable. Think of a developer with 30 years of experience. Many of the technologies from 10, 20, or 30 years ago are long obsolete, but the value of 30 years experience is in the fundamentals that are independent from the specific technologies. Otherwise you get developers with 1 year of experience repeated many times.
Books are Underrated
I feel like books have a bad reputation among many developers. Reading might seem too academic, disconnnected from “the real world”. I see it differently. Many of them contain a lot of practical wisdom from very experienced developers and are mostly timeless. In general, I recommend books that go wide rather than deep, because they raise your awareness of alternative practices, principles, and concepts, allowing you to decide on what topics to go deeper. For example, there are many books where, if the majority of developers had read even a single one of them, there wouldn’t be so many developers who think that CI/CD is a tool that automatically runs your builds and tests, or that DevOps is (just) the automation of deployments.
My personal preferences for reading books: I like ebooks, because I can read them on my ebook reader or even on my phone, for example on the bus or train. I also like audiobooks, which for most of the topics I recommend are generally suitable because these topics rely on concepts and mental models, not code and tables. With audiobooks I can listen while doing house chores or on the commute.
Books (and ebooks) can be pretty expensive, but with Humble Bundle you can occasionally get some pretty good deals with bundles of 20 or so ebooks for about 20 euros (or pay less to get a subset of the bundle), all while supporting a charity and not being dependent on a big American tech company.
You can also buy ebooks on Leanpub, ensuring that authors get a bigger share of the book price and sometimes getting early access to new books before their official release.
This is a personal recommendation and I am not involved in or payed by either of them.
Outcome Orientation and Feedback
A common mistake among developers, include many of those I’ve worked with in my career, is being too focused on just the implementation of their immediate task. Developers work alone on the tasks assigned to them, then they hand it off to a tester (or a testing team), then continue with the next task. Deployments or releases (whether automated or not) are done by someone else entirely, often by a so called “DevOps team”. Consequences of defects are not visible to the developer until much later, and often they’re not even aware of what user problem their task is intended to address. This anti-pattern is often not exclusively the developers’ fault, but is reinforced by the environment: Project managers or product owners are seen as a “bridge” between development and the customer or user. Many developers don’t want to talk to users or domain experts, or (they assume that) they are not allowed to. Testing is done by a separate team, and the developers are always under (perceived) time pressure, so there’s no incentive to spend “additional” time testing. I’ve personally seen developers make changes and hand them over for testing, only for the app to immediately crash.