- A developer, blissfully unaware you are agonizing your sales team
- A developer, tired of unrealistic demands from sales, wondering why they don't get it
- A client, sales exec, or biz dev person who wishes developers understood your concerns better
Regardless of your current title or situation, I'm somewhat blessed in this area as I have almost 15 years in both sales and development, and not even that, but sales and dev from a freelance role where I had to wear both hats, and also in corporate environments where I played one role and depended on the other.
Before I get into the list, I'd like to provide some context as to how the miscommunications even come about. If you don't care or already know, you can skip to the list here :)
In a nutshell, tech firms really have two tiers:
Both the sales teams and the project management team (often one in the same) either need to have some technical insight to make appropriate estimates for clients, or they need to depend on developers to create these estimates for them. This can create frustration on both sides - sales will sometimes generate a fixed bid and deadline based on assumptions and incomplete analysis and set the dev team up for stress and/or failure. Sometimes the dev team bids too high for the sales team to be able to close the deal. Regardless of how the project is sold, if it has a deadline, the sales and project management team desperately depend on the development team to carry out the outlined tasks on time and under budget to both save face as well as setup the company for future sales and services. Often, the project management team works with the dev team throughout the duration of the project and relays back to the client on small deliverables and timeline analysis so the accounting department is constantly in the loop of the budget status. Usually, the development team is completely oblivious to this.
Design and Development
Once the sales team has created a statement of work with the client and the client has agreed to initiate the project, the design and dev teams will be brought in. If too many decisions have been made before these teams have been brought in, it creates stress and lowers morale. Different companies have different approaches to this work flow. Some use agile scrum boards and do design and development in parallel. Some use a waterfall approach with wireframes -> comps -> code -> QA -> delivery. The only thing that matters is that when things get decided, they get decided, and move on.
5 Things project managers and Clients wish Developers Didn't Do
1. Plan detailed tech implementations before the sale
The sales team just wants the sale. They're live-in-the-now type of people. They have budgets, quotas, and deadlines, and to drag on a simple ballpark estimate into a 6 hour planning session where the developer is thinking about how to compartmentalize the services and use Redis for JSON cache with 12 servers for this, that and the other thing just frustrates them. If it is overwhelming to them, it'll be overwhelming to the client, and he/she might scare off and 6 hours have been wasted. For a ballpark estimate, give ranges to the sales team. They are generally ok with ballpark ranges. If, after a 6 hour detailed and itemized planning session you came up with $72,500 for a project, the sales associate would likely appreciate a "60-80k ballpark" range just as much, if not more. It allows for some up-sell flexibility as well as communicates to the client that budget will never be spot on for custom work.
Another reason it frustrates the sales team is that itemized estimation generally opens up a can of "what if" worms.
Dev: "Well, I can't estimate how long this part will take unless I know which third party system the client is using, or if we have to develop it internally."
Sales: "Well, how much would it cost to build it internally?"
Dev: "That's like asking 'How much would it cost to build an air conditioning unit vs installing one that's delivered by Trane'"
Sales: ".... ok what's the most it would cost for that?"
Dev: "How should I know? I don't know what they want - 1 to 5000 hours"
Dev: "How should I know? I don't know what they want - 1 to 5000 hours"
This is a much better approach:
Dev: "Well, I can't estimate how long this part will take unless I know which third party system the client is using, or if we have to develop it internally."
Sales: "What do you recommend?"
Dev: "A day to research the available 3rd party tools and we can estimate implementation costs when the client picks their favorite at that time.'"
Sales: "Perfect."
Much better indeed - it's quick, considerate of the tech requirement but deferring it realistically until the time is right.
2. Resist giving time estimates
Sales teams and project managers can only relate to previous projects for estimated turn-arounds for deliverables, or they can ask the developer. If it's custom work, and there is no previous deliverable for another client, it's really hard for devs to commit to a time. The reason is because the sales associate and the developer each have a different idea of what the most important thing is. For the sales associate, it's usually either the deadline or the budget. For the developer, it's the code quality. Forcing a developer to build a feature under a tight deadline means code is written in haste, and, while it may be delivered on time, it is more prone to being infested with bugs and lacking standards considerations. It's like asking an artist to paint a forest scene in 2 hours. You might get a painting, but it will lack heart. Unless the artist was Bob Ross, in which case it would be awesome and I would recant.
A better approach is to think of 4 hour or 8 hour time blocks and check in at those half-day points to see what has been accomplished. Do not ask when something will be ready. Developers are task-driven, not deadline-driven. They know what needs to be done, and they know that people are waiting on them. That is enough to keep the drive going. Any more prodding will simply lower morale and make the developer feel unappreciated. Ask if there are any blockers or unforeseen hurdles to be worried about, and if not, let the developer work. You will get much better results, often ahead of schedule.
3. Refactor so much
Often times developers have a fix-on-the-fly approach to coding. We live by the DRY (Don't Repeat Yourself) principal and often times a simple add on which "took the junior guy 20 minutes" to hack in takes a senior dev 2 hours. Why? Because we care about other developers down the road who will look at this code, rely on this code, scale it out, and not have to worry about whether or not they need to make accommodations to their own code to avoid breaking the add-on.
I love cars so I'll use the spoiler as a metaphor. Imagine taking a pristine Tesla Model S right off the factory floor, all glossed up and ready to go, and then some new guy comes along with a 2x4 and L-brackets. He proceeds to drill holes without measuring directly into the trunk and screw on this piece of wood. It doesn't match so he spray paints it to match. He calls it a spoiler. By definition, it is. He got it done fast and cheap, but is that really what the sales person wanted? What the client wanted? Of course not.
A spoiler upgrade requires prepping of the trunk panel, sanding, priming, bolting on the component, possibly applying resin mold to conform to the contours - maybe it's carbon fiber - the end result. It looks like it belongs on the car. It looks like it's part of the package and works so much better. The engineer is happy, the sales professional is happy, and the client is happy. It took longer and cost more, but it's the result that is important in the end.
Back to the code, that story holds true on all parts. Sure there are ways to cut time and short-sighted costs by copying/pasting/duplicating, adding in-line conditionals instead of decorator methods, etc., but those are not appropriate additions to a quality code base. The sales professional or project manager needs to understand that, most likely, the code is the way it is because of a previously agreed-upon decision that was made, and that new code needs to be carefully implemented as its own feature, with this new decision receiving the same value as the original one.
So all that being said, there is a time to not refactor. If production is broken and customers are leaving, patch, push, and @todo for the next release. Developers, please communicate with your project managers the difference between scope creep on a release and a bullet "off-release" fix. Taking 3 days to push up a bullet fix because you had to implement it the right way when a patch could have been added in 20 minutes is mis-prioritization. Again, patch -> push -> @todo.
Often times developers have a fix-on-the-fly approach to coding. We live by the DRY (Don't Repeat Yourself) principal and often times a simple add on which "took the junior guy 20 minutes" to hack in takes a senior dev 2 hours. Why? Because we care about other developers down the road who will look at this code, rely on this code, scale it out, and not have to worry about whether or not they need to make accommodations to their own code to avoid breaking the add-on.
I love cars so I'll use the spoiler as a metaphor. Imagine taking a pristine Tesla Model S right off the factory floor, all glossed up and ready to go, and then some new guy comes along with a 2x4 and L-brackets. He proceeds to drill holes without measuring directly into the trunk and screw on this piece of wood. It doesn't match so he spray paints it to match. He calls it a spoiler. By definition, it is. He got it done fast and cheap, but is that really what the sales person wanted? What the client wanted? Of course not.
A spoiler upgrade requires prepping of the trunk panel, sanding, priming, bolting on the component, possibly applying resin mold to conform to the contours - maybe it's carbon fiber - the end result. It looks like it belongs on the car. It looks like it's part of the package and works so much better. The engineer is happy, the sales professional is happy, and the client is happy. It took longer and cost more, but it's the result that is important in the end.
Back to the code, that story holds true on all parts. Sure there are ways to cut time and short-sighted costs by copying/pasting/duplicating, adding in-line conditionals instead of decorator methods, etc., but those are not appropriate additions to a quality code base. The sales professional or project manager needs to understand that, most likely, the code is the way it is because of a previously agreed-upon decision that was made, and that new code needs to be carefully implemented as its own feature, with this new decision receiving the same value as the original one.
So all that being said, there is a time to not refactor. If production is broken and customers are leaving, patch, push, and @todo for the next release. Developers, please communicate with your project managers the difference between scope creep on a release and a bullet "off-release" fix. Taking 3 days to push up a bullet fix because you had to implement it the right way when a patch could have been added in 20 minutes is mis-prioritization. Again, patch -> push -> @todo.
4. Avoid meetings
Sales people are "people" people. Developers usually aren't, which is one of the reasons we both choose and are good at our profession. We prefer the comfort of our computer and the inner-circles of our own kind. We get our inside jokes, our nostalgic D&D references, and enjoy our arguments over tabs vs spaces, camelCase vs snake_case, and whether or not to line break before the opening brace of a conditional. With that type of brain, we can usually understand exactly what we need to do and what we need our team to do in a matter of a couple minutes. And that understanding is planted deep. We're constantly in communication with our fellow developers via chat/IRC, VCS commit logs, code reviews, and whatnot, and we work best in 4 hour uninterrupted blocks of time. Meetings are the bane of our productivity.
For a sales person or a project manager, meetings are critical. As developers have multiple components and modules to consider in the code base, so do biz devs have multiple points of contact from various dependencies in the project to keep on the same page. If a few days go by without a meeting, it can be disastrous for a project manager. One team can be making assumptions about another team's responsibilities or about a requirement and critical time can be wasted.
When developers are invited to meetings (especially on a whim), it creates a major distraction in our thought process. Imagine if your computer had a certain amount of RAM, and you had various programs running, and every time you stepped away from your computer you had to reboot your computer. It's a nightmare and it happens to devs all the time, where the RAM is our short-term memory and focus, and the programs are all the open files of code on which we are currently working. We might have 2 batch jobs running each in its own terminal, with 2 IDE's open and an emulator previewing a build. To step away from that for an hour, or even worse, "just 15 minutes", means we have to take our head out of analytical, problem-solving, real-time mode, and turn it into communication, empathetic, and deadline-driven mode.
Often times what will happen is developers will opt out of meetings or bring their laptops into meetings to continue working, and the actions will be received by the project managers as "this developer isn't a team player" or "he/she doesn't want this project to succeed" which couldn't be further from the truth. Developers in sales and project management meetings generally feel that "we just explained this to you yesterday, how could you possibly have forgotten already?" or "There's a doc on Drive that shows what everybody is working on, why are we all here wasting time verbally saying what's on the doc?"
What I've found works best is if a non-coding representative from the dev team speaks for the devs in these meetings and then relays new requirements and changes through the channels the devs appreciate the most, like Jira or directly on the scrum board. The cost of having a "tech lead" or "dev manager" who just acts as a communication proxy between teams can be offset by greater productivity by uninterrupted developers, higher moral, better communication, and the use of appropriate responsibility disclosure channels.
5. Talk like a developer
Sales executives and project managers need to relay communication among various teams who have various degrees of technical understanding, from none to nerd. They generally don't like to have to relay things they can't pronounce or memorize, or even explain if they had to.
Sales people are "people" people. Developers usually aren't, which is one of the reasons we both choose and are good at our profession. We prefer the comfort of our computer and the inner-circles of our own kind. We get our inside jokes, our nostalgic D&D references, and enjoy our arguments over tabs vs spaces, camelCase vs snake_case, and whether or not to line break before the opening brace of a conditional. With that type of brain, we can usually understand exactly what we need to do and what we need our team to do in a matter of a couple minutes. And that understanding is planted deep. We're constantly in communication with our fellow developers via chat/IRC, VCS commit logs, code reviews, and whatnot, and we work best in 4 hour uninterrupted blocks of time. Meetings are the bane of our productivity.
For a sales person or a project manager, meetings are critical. As developers have multiple components and modules to consider in the code base, so do biz devs have multiple points of contact from various dependencies in the project to keep on the same page. If a few days go by without a meeting, it can be disastrous for a project manager. One team can be making assumptions about another team's responsibilities or about a requirement and critical time can be wasted.
When developers are invited to meetings (especially on a whim), it creates a major distraction in our thought process. Imagine if your computer had a certain amount of RAM, and you had various programs running, and every time you stepped away from your computer you had to reboot your computer. It's a nightmare and it happens to devs all the time, where the RAM is our short-term memory and focus, and the programs are all the open files of code on which we are currently working. We might have 2 batch jobs running each in its own terminal, with 2 IDE's open and an emulator previewing a build. To step away from that for an hour, or even worse, "just 15 minutes", means we have to take our head out of analytical, problem-solving, real-time mode, and turn it into communication, empathetic, and deadline-driven mode.
Often times what will happen is developers will opt out of meetings or bring their laptops into meetings to continue working, and the actions will be received by the project managers as "this developer isn't a team player" or "he/she doesn't want this project to succeed" which couldn't be further from the truth. Developers in sales and project management meetings generally feel that "we just explained this to you yesterday, how could you possibly have forgotten already?" or "There's a doc on Drive that shows what everybody is working on, why are we all here wasting time verbally saying what's on the doc?"
What I've found works best is if a non-coding representative from the dev team speaks for the devs in these meetings and then relays new requirements and changes through the channels the devs appreciate the most, like Jira or directly on the scrum board. The cost of having a "tech lead" or "dev manager" who just acts as a communication proxy between teams can be offset by greater productivity by uninterrupted developers, higher moral, better communication, and the use of appropriate responsibility disclosure channels.
5. Talk like a developer
Sales executives and project managers need to relay communication among various teams who have various degrees of technical understanding, from none to nerd. They generally don't like to have to relay things they can't pronounce or memorize, or even explain if they had to.
Sales: "Hey do we need to support Internet Explorer 6?"
Dev: "You mean the least-secure browser in the world? The one that let China hack Google and Adobe and doesn't comply to 80% of the JavaScript and CSS that we implement because it uses JScript with it's own ECMAScript interpretations of event handling which requires us to triplicate the size of our code base with IE6 shims and hacks? That browser NEEDS to go away, why would we want to support it?"
Sales: "Um.. the client mentioned it...so we shouldn't support it then?"
Dev: "....well.. who's their user base? I can't say no if the project is for some hospital intranet stuck on Win NT with a firewall that blocks browsers that were made after 2001."
Sales: "It's a Wordpress site. They're going to be selling shirts and stuff."
Dev: "No then"
Sales: "Ok... IE7?"
Dev: "You're killing me."
Let's try that again with some mutual understanding.
Let's try that again with some mutual understanding.
Sales: "Hey do we need to support Internet Explorer 6?"
Dev: "Most likely no unless they have business requirements that demand it. It will significantly increase costs to support anything below version 8 because of all the patch work we will have to do. A safe markup is 50-60% to add support for legacy IE."
Sales: "Perfect."
This also applies to meetings, as we discussed in complaint #4. Most of the time, all the non-developers in the room need to know is what the developer is working on, not how it's being done, regardless of how awesome or how clever the solution was. Really, they don't care.. seriously, they don't.
Here are some general tips to keep things happy:
- Don't use acronyms or tool names unless the other person knows the acronym or unless you are prepared to hear "what's that?" and provide an answer - is either of your days any better? No. Examples: IDE, VCS, Shell, Batch, Grunt, Git, Merge, etc.. Just think of talking with your uncle who keeps spitting out military acronyms like BCGs, MREs, BDUs.... you don't care.
- Developers, remember that sales and project managers earn respect and save face among their peers and supervisors by hitting deadlines and by coming in under budget with good returns. They want you to succeed because it means they also succeed.
- Sales professionals and project managers, remember that developers crave focus and time to work. I've known developers who have taken $30,000 pay cuts to get out of meeting-filled work days to work in a more chill environment. A burned out or distracted developer will produce bad code, which means that you will have to explain to your client why there are bugs that need to be fixed. Senior devs live by the "do it right the first time" mentality. If you can respect that, you will get some seriously awesome deliverables for your clients.
- Beer.
“I jumped on an opportunity to purchase a rental property over the 4th of weekend. Mr Lee was quick to respond and since this was my first time getting a loan to buy a rental property , he was able to help me walk through the loan process. It was a great experience working with a good and kind loan lender Mr Lee. I hopefully know very well if you are outta looking for loan to purchase a property or funding business purpose then Mr Lee will be able to help you with such process here his details WhatsApp +1-989-394-3740. / 247officedept@gmail.com !”
ReplyDelete