I’m a techie by trade, I’m sure you figured that out from the sort of things I blog about here. As such, I do get rubbed up the wrong way when I hear of so many companies complaining on a regular basis about their technical team. It’s either because they don’t deliver on time. Or the functionality is not quite what it was needed. Or because they are assigning priority to other projects than the ones which should be top priority for the company. Or that they are not engaging in discussions with the outside world to find out what the “real” needs are… The list goes on, and while I’m hoping you have no idea what I’m talking about, I think the sad reality is that most of us have heard (or even more so, have been involved in) these sort of discussions and accusations against techies.

As I said, I feel I need to defend the techies here — having been myself involved in these on both sides of the table.I’m going to look at some of the situations I’ve encountered and explain how and why that has happened. And while I am obviously partial in this, hopefully you will see that a lot of these situations were not entirely the techies fault.

One common thing I hear about tech groups in companies is that “they always say it can’t be done”. I agree, I have said that myself lots of times and heard it too. But here’s the thing: somehow the techies are never given the full context in these discussions. The discussion goes like this: CxO and CTO and tech team in a room:

CxO : “Hey guys, we have an opportunity to do XYZ and as such we need to deliver project A in the next quarter”.

CTO + techies: “Can’t be done”.

Big argument follows!

The thing is in this situation neither of the 2 side (the CxO on one side and the techies on the other) have got the full context; nor do they give it to each other. When the CxO stated the above he forgot to mention:

• The opportunity to do XYZ is worth $1 million, as such if needed, it’s ok to spend money on actually acquiring technology, or tools or people or outsource some of the work!
• Opportunity XYZ is considered right now by the whole board of directors to be top priority and everything else is second priority; this means it’s OK to push delivery times for other projects, which are OK to be put on hold for now.

Also, on the other side, the techies are not offering their side of the context:

• There is currently a high severity issue in production and all hands are on deck, with an estimated fix time of 2 weeks. This needs to be fixed, as otherwise the platform would be unstable and crash. It also requires 99% of the tech resources so the whole team is committed into this.
• There are a few projects the tech team is undertaking which have been paid for by customers and have strict deadlines — in order for these to be prioritized behind opportunity XYZ someone needs to liaise with the teams and customers expecting these and work out a new schedule for these.

Should the tech team be told they have a budget to invest in technology which cannot be built, as well as shuffle projects around, this won’t be an issue. To the CxO, who has the full context of this opportunity, these are implied; to the tech team they are not, and what they actually hear is “You need to still deliver everything you promised, in the same budget and now you also have another project on top of that”. Of course anyone else would say: “Can’t be done, sorry!”.

Now, if the CxO is told about the current urgent issue being taken care of by the techies, he’d be quite likely to communicate that 2-3 weeks delay is ok, he can work out a delivery schedule with the CTO which would account for this delay. Also if he’s told about the paid projects he can then reach out to the other departments find out which projects can be shifted and again work out a delivery schedule with the CTO. “Can’t be done” is final, there’s not much negotiation that can go on around that — on the other hand “I will need help to deliver this in time” or “We might need more than 3 months” already opens the discussion on both sides to figure out how this project can be scheduled in.

However, no one has the full context here. Sadly, in a lot of such situations like the above, I’ve seen the techies never being given the full context as well as not allowed to present the context on their side; left without any idea of a budget available for this project for hiring, technology, tools, etc, the answer is always invariably “Can’t be done”. Which is absolutely correct: if you have an over-committed tech team already, with projects scheduled in throughout the next quarter, it is impossible to deliver anything (not just XYZ!) without making any changes. And the lack of context given implies right away to the tech team the fact that there won’t be any changes made — to the team, the schedule, the priorities, and so on.

Another example I seen quite a bit is the fact that techies don’t deliver on time. I know all agile evangelists out there will jump up and down now screaming that in an agile environment this would not happen. But let me tell you something: I haven’t seen yet one 100% agile company, I think that’s an unicorn! Most companies adopt a mix of agile and non-agile methodologies which suits their needs best — going too extreme into agile or waterfall or what-not often slows down companies, and that’s not why we are adopting methodologies for! So for whatever reason, projects do get delayed and fall behind. Again though, I feel this is because of lack of scope given to the tech team — and to the ones around the tech team.

If you take the above example again, project XYZ gets delivered ultimately in one quarter — but to the expenses of other projects! These projects are delayed not because of the technical team, but because of a shift of priorities at board level, which rippled through to the tech team. No one has this context outside the tech team, so of course, for everyone not aware of this, the tech team is at fault.

Another example is when a certain project is estimated to get delivered in say one quarter. Some people leave, some people get sick, some other issues come up. We’re now half the way through the quarter with only 1/3 of the project finished — what is to be done? If the tech team knows there is room for budget there then technology, support, expertise, and other things, can be acquired in advance to make up for this deficiency. But typically, tech teams are not being told these factors. Also, quite often it does not pay off whatsoever to notify in advance about the fact that there are delays encountered — no one in the board cares that much about this and such an early announcement would only point more fingers to the tech team, rather than force everyone to re-evaluate the context and come up with alternative options. Ultimately, the tech team does not get enough context again to operate — as such they do exactly what they were doing before and keep going at the same pace; the end of the quarter arrives and the project is only 2/3 finished, well, what a surprise! At this point of course is too late to liaise with the customer, to throw money at the problem or anything else, the company just takes the hit and some techies get fired — and then the cycle starts again with just new people in the game, but same lack of context.

I hear also often that techies don’t listen to people. “I keep asking for XYZ and they never build it for me!” is a common one. Here’s the thing: tech teams, like all other teams, have targets, scheduled, deliverables and deadlines they work against. Simply “asking for something” doesn’t mean much to them — they won’t re-schedule all of their work because of a simple request. Try to formalize this request, transform it into a project which then gets scheduled in their work load. This will get them to spend time on it; just a formal discussion is not necessarily enough to focus effort on the project you need.

Also, if your project gets scheduled to be delivered 2 years down the line, it’s unlikely it’s the techies who have decided that — there are typically project managers in place who do this for the tech team. Chances are they are the ones who pushed your project all the way to the bottom of the pile, probably considering it not urgent. Try to give everyone more context about your project, why is it important, why it needs to be delivered by such-and-such deadline, and then you will see the tech team working on it. Without context and dates around it, your project would quite likely be considered a simple “nice-to-have”!

Last (for now, I’m sure this thread will cause a few more posts) is the issue of “They don’t deliver what I want”. I’ve seen this throughout a few disasters in various companies. Here’s a quick example:

CxO to the tech team: “Hey guys, can you build me a platform for hosting marketing video materials our marketing team is putting together? We are generating some educational video content and want a way to host this and put it on the web.”

Techies go to their corner, write some code and come back with something. CxO looks at it and decides: “It’s not what I asked for? Where are the social media sharing buttons? Where’s the post to Facebook functionality? Where’s the LIKE button? Vote up / down buttons? Form at the end of the video to subscribe to our blog? Follow us on Facebook?” Techies just put on a puzzled face as they are told their work is shite and are being sent to their corner.

Again, lack of context: to a marketer, the moment you talk about hosting videos, you talk about sharing on social media, you talk about forums, comments, vote up, vote down, landing pages, call to actions, Twitter, Facebook, the whole 9 yards. To the tech team, these (in most cases) are unknown requirements. Either spend days building a spec to the finest detail, such that you include all these requirements, or have your team be more transparent with what and how they use this technology, enough to build a context around it!

I’m probably going to revisit this subject with more thoughts on it, but I think the idea I’m trying to push here for now is that always, always, always create a context — it’s quite likely not your tech team to blame but their lack of context!