4

Context: I work as a senior development staff at a medium-sized startup in the FinTech sector.

Our tech team is running at full capacity and we don't have time to address some of the features that are thrown our way.

A chairman on our board, who codes as a hobby, decided to produce a full REST API service in his free time and now demands that we put it in production.

How can we politely:

  • Decline his request
  • Make it clear to management that this is not acceptable

The early feedback that I received was that even though it's not right, we should still do it because we are already behind on other things and this is practically free labour. The flip side being that we'd have to rewrite everything: it's not great code, has no tests, doesn't follow our conventions, etc.

  • 1
    Helping him to become a better coder isn't an option? I'd not expect great code, but he's trying to help. What about showing the convention and how to do tests? It may become a win-win scenario. – Tiago Cardoso Sep 13 at 22:32
  • 1
    @TiagoCardoso: The executive is trying to help, but his approach is wrong. If the team is running at full capacity and still can't handle all work that's comming their way, then the best help the executive can offer would be to either do something to limit the load or increase the team's capacity by adding more people. If he chips in code by himself, that's not helping, that's just satisfying his ego of "Look, I can code. My code is even deployed and running in production". – Bogdan Sep 14 at 9:54
  • @NodeNodeNode: This is an ugly situation to be in, and it's a matter of chosing the lesser evil. Be carefull what you decide to do because you will be creating a precedent that will reinforce the same behavior in the future. – Bogdan Sep 14 at 9:55
  • IMHO he's trying to add more capacity to the team - but isn't quite sure how. You can either help him or tell him he needs to pay someone to do something he's trying to do. It massively depends on a plethora of factors, my view is just one amongst an infinite amount of possible scenarios. – Tiago Cardoso Sep 14 at 16:37
  • I'm going to point on that, as written, this is pretty close to a rant. If that's not intended, it's probably worth a little introspection about why the question comes off that way, and whether or not that's really the X in this X/Y problem. – Todd A. Jacobs Sep 15 at 17:16
4

Besides for dns's suggestion to add it to treat his submission like any other pull request and test it thoroughly, you also need to add values to your concerns.

Create a document explaining the cost, in man hours, of each concern:

  • We'd have to rewrite everything
    • That means X coding hours, X testing hours and X debugging hours.
  • It's not great code
    • That would require X hours of code reviewing it, X hours of white-box testing all interfaces, and X hours of stress testing
    • This is probably your winning card; if you can quickly prove that the code doesn't handle all use cases or is x% slower, then you can safely refuse to use it until it's up-to-standard.
  • Has no tests
    • X hours of (re)writing tests
  • Doesn't follow our conventions
    • Here you need to explain which conventions and why they are important and the potential risks once you allow exceptions.
    • And/or simply insist that it follows the conventions.
  • Forget everything. Whatever code he is writing, can be written by someone else working as a developer. Which means he can save time by simply hiring an extra developer. While it is a good thing that he likes to code, there is still a cost attached to his time. – jitendragarg Sep 27 at 9:16
  • @jitendragarg - we all agree on that - but that doesn't help the OP who asked: How can we politely: Decline his request, Make it clear to management that this is not acceptable – Danny Schoemann Oct 2 at 9:17
  • Well, we can always explain to him that his time is extremely valuable, and he can focus more on technical direction for the project, rather than doing actual development. Suggesting potential items to focus on, will help the executive decide how he wants to help. We can suggest something like "can you take up a training for the team to help them get better, which ensures that you can focus on bigger picture than on day to day development". Or maybe suggesting that he can help team figure out the right trainings to attend. – jitendragarg Oct 9 at 10:22
  • Continued from last comment. Maybe something like "I am extremely happy that you helped us with our work. I will add this code to our testing team's task list. In the meantime, can you help us identify the training sessions that can help the team deliver better, and save you the hassle of development work. We are glad to see the management willing to help us out, but we believe that we should not require the management to get down to brass tacks. This way, you can focus on bigger picture, and help us get better in the long run". This is just an idea though. – jitendragarg Oct 9 at 10:25
  • @jitendragarg - read the question again; the coding is "complete" as far as Mr. CEO is concerned. He did a great job, in his Humble Opinion, "and now demands that we put it in production"! he doesn't plan on spending more time on this; he's probably focusing on his golf moves, now. – Danny Schoemann Oct 10 at 9:49
5

TL;DR

There is a lot more that's structurally wrong with your situation than you think, and based on your tone and framing you yourself appear to be part of the problem. Your company appears to have an immature organizational structure without mutual respect between roles, and various people involved in this situation seem to be communicating poorly. Only effective communication at all organizational layers can resolve the issues you are describing.

Signs of Immature Organizational Structure

You are assuming that the problem is that someone in management is asking the team to implement a piece of code, but that's not supported by the information in your question. You have framed this as a "me vs. him" problem, as if you and the board chair are not part of the same organization. Nothing could be further from the truth.

There are actually several indicators that your organization, your leadership, and you yourself are all relatively new in your roles. This may indicate a lack of sufficient industry experience, or simply a set of process and soft-skills deficits. Indicators include:

  1. A "hands-on" board member.

    As a rule of thumb, governance and operational responsibilities should be separate. Start-ups can and do violate this rule, but it needs to be with an "eyes wide open" sensibility to the pros and cons of allowing the board (who should generally be more involved with succession planning, strategic planning, and oversight than day-to-day operations) to get too far down in the weeds.

  2. A board member bypassing the CEO/COO/President/etc. to direct employees.

    As a rule of thumb, an executive officer should be directing employees below the C-suite. A board member bypassing the executive team is a very bad organizational smell that often indicates inexperience (because experienced board members and executives usually prefer to work through the chain of command), or serious problems with trust or governance structures. A board that doesn't trust its executives, or a board that lack effective governance structures, are both red flags.

  3. A developer who thinks that he can make business decisions for the organization.

    Whether or not there is merit in your objections to the use of a given software tool or architecture, it is not the role of a developer (senior or otherwise) to make business decisions on behalf of the organization. A professional developer can (and should) provide feedback about technical approaches, and point out the pros and cons of a proposed solution, but this is in aid of informing executives so they can make analysis-driven business decisions. A developer typically doesn't get to make decisions (although you can certainly offer opinions and insights) about how the company spends its money or what products the company should make. At best, you should be objectively addressing the merits of the API in meeting (or not meeting) the project's objectives with your management team, and then letting them decide whether or not it belongs on the roadmap.

  4. A lack of formal project management.

    You mention your own role, and mention the existence of the board chair. You don't mention any other executives, although we should be able to infer at least one C-level executive. However, your post has zero mention of a project manager, product manager, Scrum Master, or any other similar role that might assist in improving organizational communications and process controls.

Organizational maturity comes from industry experience, the passage of time, and effective communications. The only one of those things you can directly impact is communications, so keep your focus there.

Poor Communications

Make it clear to management that this is not acceptable

Acceptable to whom? You work for at least two additional layers of management (the executive team and, indirectly, the board) so while you can find something personally unacceptable, you don't get to decide what's acceptable to the business. Thinking that you do is a major red flag in itself.

Effective communications starts with sharing a common frame of reference, and then making sure everyone is hearing the same things. If there's a process problem, a chain-of-command problem, or a technical problem, then your management and leadership teams should be part of the solution. This solution must ultimately be a mixture of politics and communication, and the only valid metric of success is business value.

You and the management team shouldn't be on opposite sides, even if you don't agree with the currently-accepted solution. You and your leadership team should be actively collaborating, not both playing "take it or leave it" with one another. In the end, though, the final decisions about everything other than whether or not you quit rest with the company.

Risk Management and Iterative Development

You strongly imply that you've discussed this already with your leadership team, and have been given what I consider a reasonable answer. You said:

[W]e should still do it because we are already behind on other things and this is practically free labour. The flip side being that we'd have to rewrite everything: it's not great code, has no tests, doesn't follow our conventions, etc.

You've essentially said this API represents technical or business risk of some sort, and your management team has explicitly told you that it is an acceptable risk. Risk can only be mitigated, transferred, or accepted. Right now, you're clearly being told the risk has been accepted. That means the leadership team has acknowledged the risks, and has decided to proceed anyway. If everything works out, then they get to claim credit for a lower-cost success; if not, then when it breaks they get to keep both halves. That's the nature of business decisions, and it seems like your leadership team is okay with that.

The underlying problem is that you aren't okay with that. I'm not sure why not, since refactoring, interative and incremental improvements, and rewrites are widely considered standard software development techniques nowadays. You should take the code with the knowledge that it will have to be improved, fixed, or scrapped in the future, and that management has accepted those possible outcomes. You can then iteratively build tests and refactor API code as necessary when problems arise...or not, as directed by management.

Your Personal Options

If you truly feel that you can't execute the business objectives defined for you, and you've already had your concerns heard without generating the outcome you want, then you should consider that your current project, team, or organization is a bad fit. Without assigning blame either to you or to your leadership team, it's enough to simply say that you may have irreconcilable differences. If that's the case, brush up your resume and move on.

On the other hand, if you are mature enough and experienced enough, you can just as easily document your concerns in the project's formal risk log, and then support the current company objectives and processes. If and when problems arise in the future, you can always re-highlight the risks and proposed mitigations you've documented at that time. That doesn't guarantee personal or project success, but it is a much more collaborative approach than taking a purely oppositional approach to everyone on your leadership team.

Being oppositional, obstructionist, or passive-aggressive will not lead to process improvement. It is much more likely to lead to you getting fired. Your mileage may vary, but a developer telling senior management or board leadership what is or isn't acceptable is unlikely to get you where you want to go in life.

Startups and small-business culture aren't for everyone. You may simply be in an untenable situation, or a better fit for a different (or perhaps larger) organzation. However, if you treat this as a learning opportunity and develop the soft skills needed to identify, control, or accept risk related to your project then you're well on your way to mastering essential skills that can serve you throughout your career.

  • Thank you for your response. There's a lot to unpack here, let me address some of those points by giving you some context. - The company is 40+ employees, with a solid Executive team, some VPs and 2 product owners, in charge of squads. - I have joined the company about 2 months ago with the mandate, amongst other things, of getting the company on track tech-wise. – NodeNodeNode Sep 16 at 13:01
4

You could treat his submission like any other pull request: give him feedback like you would any other code review. If he understands the conventions of your team, if he knows your team doesn't put code into production without acceptable test coverage, then he might take the feedback seriously and improve the code.

Code quality is, however, only part of the concern here. The other concern is team cohesion -- and I don't generally recommend that a team invite the intermittent contributions of a non-team-member. In your case, though, you ought to weigh the pros/cons of having this board member interact more with your team. It may be great; it may be catastrophic.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.