3 ms·

A few years ago, a recruiter reached out to me about a role at a company that sold a data analysis product which included geospatial mapping, and they needed an

A few years ago, a recruiter reached out to me about a role at a company that sold a data analysis product which included geospatial mapping, and they needed an API developer. They had a Python API, but it was complicated and difficult to use and no one liked it. They wanted something simpler and easier for outside developers to work with. I wrote them a cover letter that began: - - - When I design an API, I start with the apps. An API has no value on its own; its value comes from what you can build with it. There may be an existing app that needs a new API feature, but I like to write a self-contained sample app for quick iteration on the API design and to include in the SDK. An API also needs full test coverage, of course, but that comes after this initial step. Instead of test driven development, you might call it app driven development. An SDK developer is also in a customer support role: they should write solid reference documentation and tutorials and sample apps, and interact directly with the users of the SDK. It’s not a job for someone who likes to just sit quietly and code. One of my hobbies has always been to assist other developers in various online forums. Most recently this has been on Stack Overflow where I’ve posted over 600 quality answers. Previously I was known for my advice on the original jQuery mailing list and Windows programming forums. - - - I went on to list some of the APIs I've built. The cover letter must have resonated with them, because they brought me in for interviews the next day, and made an offer the day after that. This looked like my dream job! I love building APIs, working with the developers who use those APIs, and especially anything to do with geospatial data. The team that hired me had been a startup that was acquired by a larger company in another state. Things looked great at first. I was writing sample apps and imagining what APIs would make it easy to develop those apps. And then a team of Architects from the larger company swooped in and decided that they should be the ones to design the new API. They liked to design with UML charts of boxes and arrows, and thought the API should reflect the inner workings of their system. I thought the API should be simple and easy to use for outside Python developers, and I tried to put myself in the shoes of those developers to understand what would make their jobs easier. At one point my manager asked, "can't you just implement what the Architects have specified?" I gave it my best, but by that time I was demoralized and unproductive. The company wanted me to do the exact opposite of what I was good at and what they hired me for. I was fired after three months.

sibit 4y ago
> thought the API should reflect the inner workings of their system I've had to create and consume these type of APIs. Demoralized and unproductive has always be the result I've gotten.
no_wizard 4y ago
I hope its okay that I take a chance at digging into this a little bit because I think its a pretty interesting thing you encountered here. I myself have been part of acquisitions, both good and bad, and worked at 2 monolithic organizations (university system and Apple, respectively) and 5 varying sized startups back to a monolithic organization via acquisition. What strikes me as interesting here is the interference levels. The big question I have here is my initial thought upon reading this is: When the parent corps software architects came in to lay claim to the new frontiers of their acquisition, a few common scenarios come to mind [0][1]: The first is that its entirely possible that the architects saw a greenfield way to grow their career by treating the acquisition as a chance to grow their stature. Therefore, its important for them to have their names all over things and for some understandable version of what gets done to mirror things others will understand, presumably so they have the easiest path to explain their OKRs (or similar). If this was the case, then the best thing you could have done in my view was to express early about collaborating and learning their process, and try to insert yourself into the discussions and appeal to them as an authority, while selling your idea as if it was their idea[2]. The metric for them is visibility, familiarity and career ascension, and thats the hidden goal in this scenario you have to play into. Another scenario is that the team had already largely sold this upstairs (or it came as a top down directive) and they were simply under the thumb of need to make this follow the same uniform structure that the team had been following without any real room to make exceptions. It'd help if people just said this, but I have found often they don't, it comes out in other ways. A key thing I like to do when I interact with a team and they present me with something before I'ved asked for it in detail is ask if they already started or got some kind of sign off on it. If they did, you can appeal for changes, accept the design as is, or appeal to the higher stakeholder involved. In these situations, I've had the best luck drilling down into the surrounding circumstances and figuring out who it is that I need to build a relationship with to change the circumstances for the better, whenver possible. These are more political in nature and really will reveal alot about culture, so its important to use a deft hand. I've been in situations like this, and I've usually pitched something to the effect of you don't want this acquired tech to go south, perhaps we should re think this before it becomes a larger problem (though decidedly not worded in this direct manner, again, use a deft hand) Lastly, the last scenario that comes to mind for me is that its entirely possible that the team was generically tasked with taking on architectural responsibilities post acquisition and they simply had different culture / methodology for handling this, and only an appeal to a higher authority or diving into their existing process would help at all. I find generally its best to see if you can get into their process and start to form things around how they're already working that move the needle rather than trying to wholesale push back against whatever it is they're trying to achieve, that usually ends up being a losing proposition unless you have higher authorities vested in your success and outcomes over theirs, basically. [0]: They're hypothetical and based on what I've seen and learned from others, but not representative of every situation, and may not be related at all to yours. [1]: The advice I may lay out here, is hypothetical in that I can't speak to any specific situation, only pattern match. Sometimes, politics kills any good intent and attempts at proper compromise. That's when it becomes a red flag, depending on how, what, why, who and how often. can't win them all, unfortunately [2]: I realize this is one of the tenants from books like How To make Friends And Influence People but its easier than you might think, if you haven't done it repeatedly it might sound sneaky but it boils down to agreeableness to a big degree.

sibit 4y ago

> thought the API should reflect the inner workings of their system I've had to create and consume these type of APIs. Demoralized and unproductive has always be the result I've gotten.

no_wizard 4y ago

I hope its okay that I take a chance at digging into this a little bit because I think its a pretty interesting thing you encountered here. I myself have been part of acquisitions, both good and bad, and worked at 2 monolithic organizations (university system and Apple, respectively) and 5 varying sized startups back to a monolithic organization via acquisition. What strikes me as interesting here is the interference levels. The big question I have here is my initial thought upon reading this is: When the parent corps software architects came in to lay claim to the new frontiers of their acquisition, a few common scenarios come to mind [0][1]: The first is that its entirely possible that the architects saw a greenfield way to grow their career by treating the acquisition as a chance to grow their stature. Therefore, its important for them to have their names all over things and for some understandable version of what gets done to mirror things others will understand, presumably so they have the easiest path to explain their OKRs (or similar). If this was the case, then the best thing you could have done in my view was to express early about collaborating and learning their process, and try to insert yourself into the discussions and appeal to them as an authority, while selling your idea as if it was their idea[2]. The metric for them is visibility, familiarity and career ascension, and thats the hidden goal in this scenario you have to play into. Another scenario is that the team had already largely sold this upstairs (or it came as a top down directive) and they were simply under the thumb of need to make this follow the same uniform structure that the team had been following without any real room to make exceptions. It'd help if people just said this, but I have found often they don't, it comes out in other ways. A key thing I like to do when I interact with a team and they present me with something before I'ved asked for it in detail is ask if they already started or got some kind of sign off on it. If they did, you can appeal for changes, accept the design as is, or appeal to the higher stakeholder involved. In these situations, I've had the best luck drilling down into the surrounding circumstances and figuring out who it is that I need to build a relationship with to change the circumstances for the better, whenver possible. These are more political in nature and really will reveal alot about culture, so its important to use a deft hand. I've been in situations like this, and I've usually pitched something to the effect of you don't want this acquired tech to go south, perhaps we should re think this before it becomes a larger problem (though decidedly not worded in this direct manner, again, use a deft hand) Lastly, the last scenario that comes to mind for me is that its entirely possible that the team was generically tasked with taking on architectural responsibilities post acquisition and they simply had different culture / methodology for handling this, and only an appeal to a higher authority or diving into their existing process would help at all. I find generally its best to see if you can get into their process and start to form things around how they're already working that move the needle rather than trying to wholesale push back against whatever it is they're trying to achieve, that usually ends up being a losing proposition unless you have higher authorities vested in your success and outcomes over theirs, basically. [0]: They're hypothetical and based on what I've seen and learned from others, but not representative of every situation, and may not be related at all to yours. [1]: The advice I may lay out here, is hypothetical in that I can't speak to any specific situation, only pattern match. Sometimes, politics kills any good intent and attempts at proper compromise. That's when it becomes a red flag, depending on how, what, why, who and how often. can't win them all, unfortunately [2]: I realize this is one of the tenants from books like How To make Friends And Influence People but its easier than you might think, if you haven't done it repeatedly it might sound sneaky but it boils down to agreeableness to a big degree.