1. Sell the dream; 2. Manage the disappointment

TL;DR It's 2018 & for majority of developers speaking to a business person (/stakeholder /user /sponsor) is still a grand rarity. We explicitly ask for "layers" of...

10 months ago

Latest Post How does Dunning–Kruger effect impact collaboration in tech teams by Sebastian Gebski

TL;DR It's 2018 & for majority of developers speaking to a business person (/stakeholder /user /sponsor) is still a grand rarity. We explicitly ask for "layers" of intermediaries who can translate business to tech & back. And once it gets to crafting the actual solution we either reduce ourselves to purely subservient automatons ("I do what I'm asked to, so where does this button go?") or follow the other extreme ("Provide written requrements until 10th, then we'll make something out of it & let you know"). We feel too comfortable in "secluded IT enclaves" where we can reduce problems to deal with to purely technical (in 95% meaningless) ones. Solution: BURN THE ENCLAVES.

Do you recognize the two-piece software development "law" quoted in the post's title? No? Lucky you (or very naive). That's the golden rule of (typical) software development workshops who build products for other companies (their clients). Rule that unfortunately frequently expands (even now, in 2018) to companies that build their software internally (via domestic IT), within the bipolar reality they've shaped themselves:

What's the exact meaning of this rule?

As software creator, at the beginning:

But once you get closer to assumed delivery deadline:

Perimeter is "secured"

This rule is about IT people who are firmly convinced that they know better (so they don't need to probe/ask/clarify).

  1. "Business" is evil, they always try to sneak something in.
  2. "Business" is stupid, cause they don't understand how the software is built.
  3. "Business" moves like in a dark, because they don't know what technology is capable of delivering.
  4. "Business" is dim, because 150 pages-long specifications we ask from them have always some inconsistencies & mistakes ...

There's just no other option but to isolate brave, smart, skilled tech people from all these halfwits that go under the name of 'users', so they can build their technical masterpieces undisturbed ...

One could think that this way of thinking will without a doubt die a natural death - whole markets jump on "digital" bandwagon, there are more & more success stories of small, focused, fully interdisciplinary teams that have gained unprecendented competitive advantage due to close collaboration of very different specialties on one, single, common goal. Sadly, many (intentionally or not) refuse to understand what's truly necessary to build good software. Various types of consultants preserve this knowledge gap (that's what provides them continuous inflow of new business), so do internal IT executives (to solidify the boundaries of their "princedoms") - "transparency" & "openness" frequently remain meaningless buzzwords that appear in occasional presentations.

IT Departments are so 90s

OK, I think it's the highest time for the punchline.

IMHO med/large organizations which'es core domain (their main source of income) is based on their own software products/services should not have separate IT departments. Or rather, they should have multitude of them - each linked 1:1 (preferrably incorporated into) to the business unit it powers (I didn't use word "support" on purpose).

Just to clarify this way of thinking:

It's the highest time to stop thinking about building software in context of "factories" that collect the work items from the endless (& obscure) queue of company-wide demand. Software development became a universal skill that can be applied to huge variety of problems, in pretty much any team - but to make it fly, it has to be involved directly (& immediately), because solution is NEVER made only of the pieces of code.

Sebastian Gebski

Published 10 months ago


Leave us your opinion.

Subscribe our newsletter

Recieve news directly to your email.

No Kill Switch © 2018.