I have felt that the team trusts me to do the job and therefore I decided that my time will be used best by applying myself to the actual development. I neglected meetings that seemed unnecessary and reduced one-to-one communication.
I have set up tools to monitor my progress with the model (like tensorboard and sacred[1]), kept meticulous issue-tracking and a well-maintained repo on Gitlab. I also have been writing short semi-regular reports on the progress of the model (current issues, things to try and test, current metrics and suggestions for the development). It turned out, no one has ever reviewed any of the above and the team relied only on my summaries during short, semi-regular meetings. My ways of communicating turned out to be mostly inaccessible to people without engineering background!
As a result I was accused of slacking off and was deemed not worthy of any equity in the newly formed company [2]. I believe that my biggest mistake [3] was lack of proper communication of my progress and complexity I was dealing with. I was also unable to convey why some things take more time than expected during modelling or software development (like data processing, writing unit tests, etc.). Hence, my questions: How to effectively communicate the progress to non-engineer team members? How do I set reasonable expectations when the team expects development time to be closer to a hackathon project than a maintainable and certified product? How do you explain the complexity and gotchas of the work that needs to be done?
[1] https://github.com/IDSIA/sacred
[2] I resigned as a result (still working on the project until the end of the year). I am now transitioning to freelancing.
[3] There were other issues on both sides too of course, but not pertinent to my questions.
* Very few words, and no jargon. Every statement is a meaningful fragment, like a subtitle.
* Colors, but not too many. Think of a pie chart.
* Numbers. Executives love numbers, but be careful. The numbers have to mean something that contains very few words and no jargon.
* Keep it short, because they don't care anyway. They are just concerned that something was wrong, something was done, and finally risk was reduced. All your words and fancy colors are quickly discarded so that a quick pass reassures them emotionally.
That is exactly how I would brief a business partner today unless I have full faith they are actively involved in the health of the product. It isn't that they are stupid, but that they don't care and you cannot make them care.
This seems like you were basically in the wrong role. As the only full-time engineer, you're more than just an engineer, you're basically the IT department. So when the other departments were represented at meetings and disputes were being raised, IT wasn't represented. You failed at basic office politics. Office politics gets a bad rep because lots of people play it to further themselves, but being able to play basic politics is required to make sure other departments don't give your department all the blame.
Also, because you weren't at the meetings you weren't able to understand what the business really needed. If you understood what the business really needed you would have been delivering that and people would have noticed. Instead, I suspect you focused on the technical tasks and created a very good technical product that fit the basic idea of what was needed but didn't deliver what is needed. In the future I would suggest looking into something like BDD, it basically follows the premise that business people don't even know what to ask for, so you have to work with them in meetings to discover what the true need is. And because you weren't really delivering what was needed as far as the other teams were concerned it most likely came across as they had no idea what you were doing therefore doing nothing at all.
Basically, meetings, they're important. I hate to put it this way but I feel it's the truth, it's the difference between a software developer and software engineer. And the difference between a senior and a lead. It seems to me you would be much better suited for a role in a team where the management track stuff was dealt with by other people. I personally dislike the management track work but I understand the importance and I avoided management track roles for years to focus on writing code and solving problems.
A startup cares about business traction, functionality that helps existing or getting new customers. So a status update should be on how one is now closer to (or unexpectedly further away from) that. Note also that in a startup vision of the product, usage scenarios, user groups and business model often tend to evolve over time. You must make sure that you are up to date with the latest learnings, and that your development plans are inline with these. If you don't make sure to do this, your work may be perceived as (and/or be) irrelevant to the company success.
* This is generic human communications failure, not an engineer/non-engineer comms failure, i.e. you have incompatible communication styles. They like meetings, you like async reports. Do what is necessary to align this in future. Action item: "Hey, guys, I think I'm better able to express this in a report. I'll send you one every day/week/month". Alternative: "Hey, guys, I need continuous blocks of time to work. Can we schedule our sync at the beginning of my day".
* Explicit communication is superior to all else. Requesting ACKs is superior to all else. Action item: Set calendar event to 24 h after weekly report (send on Thursday or Monday), 2 h after daily report, subject: "Ask team if they read report, post abstract in team chat channel"
* Rapid feedback is key in early companies. The rest of your team may believe that the product does not deserve firming up (say the TAM is lower than projected, you're not getting traction, etc.). Assuming "maintainable and certified" may be misunderstanding objectives. Action item: Prioritize understanding where people stand. Default prioritize order: Make it work, make it right, make it good.
In any case, team failure is usually team failure not individual failure. Presumably your friends will provide validation of your self-worth so I have provided no indictment of the rest of your team. Still, it is expected of those with executive authority (your CEO) to communicate these things to you.
Some people are not comfortable to express their annoyance until it crosses a point of no return. You have to proactively seek to bring out their disagreements, and resolve them.
Until you've experience in resolving a number of conflicts with the persons involved, to the extent you understand them on a personal level, you have not achieved trust. In that case, reducing verbal communication produces fuel to create an environment of mistrust and suspicion.
Expressing what you want and care about, being open and vulnerable is also another part. They should feel like they know you and when you say something, they shouldn't have to guess where you are coming from.
This is easy to figure out if you spend time communicating with them. By ignoring meetings, you have missed out on those opportunities. Meetings are not completely unnecessary; wherever you got that impression from, you got it wrong. You have to figure out which meetings are important to you and which ones are not, obviously. But to know that, you have to be in enough of them. Some meetings present opportunities to know what is required of you and also communicate what you've been doing. You should never miss those. I highly suggest you read the book High Output Management by a former CEO of Intel to learn more about what meetings are... and a whole lot of other things.
Who was communicating to you this whole time? How did you figure out what was required? What were you going by? Whoever was doing that part is much more valuable than you. From the organization's point of view, they will not even notice that you are gone.
I suggest you learn these things and move on. Next time, if you want to work for a company, look for a company which is actually looking for someone like you and willing to compensate you fairly for your contributions.
> As a result I was accused of slacking off and was deemed not worthy of any equity in the newly formed company
You've been screwed over, probably deliberately, if you were doing this work before the equity agreement was made.
Also in my own experience I can get carried away with the side tech -- spending a few days setting up a monitoring system and things like that -- is it really needed or are you scratching an itch? Small companies can't really spare the time to set up the enterprise-grade tooling if it's not one and done.
Maybe you are actually slacking, it took me a while to accept the reality myself anyway.
To directly answer your question: go to the meetings. Meetings are a way to reset your slacker status to "not a", no matter how boring or pointless they are or how accurate it is (it's why managers love them). They're also sometimes a decent way to share information with the team without relying on having written it up nicely if you get to talk before the snacks come out.
Of course this is just one guy's assumptions and opinions. They could just be jerks.
There are a few ways to attack this, though all are tenuous. First, the ML project must be vital to the product. If it's not vital, then as soon as it starts slipping it will get cut. Second, you need to overcommunicate the level of difficulty and the amount of infrastructure necessary to get an ML model working. Third, it's extremely useful to have some authority and experience to point to. If you can confidently say "I have done this type of work before, and this is what it takes," you'll get much more acceptance of the longer timeline.
Of course, to keep support for your project, you needed to be better plugged in to the politics at the company. You needed more 1-to-1 communication with someone higher up, and to present your work more regularly to larger groups. It's not just to show them what's going on, but also to understand the current criticisms and the overall attitude towards your project. As with anything, if you were surprised by the result, then you weren't talking to (and listening to) enough people.
If the company is trying to grow by pushing out a product ASAP, it's definitely not the right strategy to be taking the time to write the most correct, accessible, documented and maintainable code. That's the kind of time you need to be taking in tech debt for speed and pushing something that's mostly correct, brings in revenue and has tangible results. Iterative improvement is key as long as it's visible to the people who actually control it (your bosses/managers) and those who actually use it (customers).
Remember that when you start something new, the expectations are not high. It's a completely different thing if, for instance, you're Amazon and you're releasing the next managed software solution. That would be something like a core competency, be supported by several teams and to an extent already be expected to have certain results.
I've written several replies here that address many things I consider important that might be useful to you[0][1][2]. These tackle communication, making sure people have access to information, tying business objectives to your activities and speaking a language that fits your audience (developers on the team, people on your team who may not be technical, people who are technical but may not be machine learning experts, CEO, advisors, investors, clients, domain experts at the client company, etc.)
These are all your "customers" to your communication product. You'll notice I went on and on about sharing meeting notes, or dispatching information to people so the message penetrates several levels and people know what they/you're doing and why.
>I am now transitioning to freelancing.
You might find a thread I tweeted[3] about this useful, too. It advises you about the benefits of dealing with enterprise as a company to make it worth your while, lawyers, building product[4], abstracting that product to expand and sell more. There's a lot of trial in there. The context is products for enterprise in the mid six figures that a couple of people could pull off by making sure they get the communication part with the client right, and other things.
- [0]: https://news.ycombinator.com/item?id=25025253
- [1]: https://news.ycombinator.com/item?id=25160534
- [2]: https://news.ycombinator.com/item?id=25176818
- [3]: https://twitter.com/jugurthahadjar/status/131066829330549965...
I think there is a multifactor problem with building a work product that other people in the company don't fully appreciate, and without gaining full "buy-in" to take the risks and time investment needed for success.
Part of this problem is communication: you need to be your projects own advocate, and communicate clearly how "model performance is X" and for profitability under assumption Y, we need "performance of at least Z given ...". This could take substantial time, but someone needs to do it, and it's the only way to justify the time investment in your model as a necessary business expense. Model training is just not important, where the model is in terms of business application is the only thing you should be communicating to a small team.
The other problem, I've found, is that some teams are far less willing or able to understand that the technical challenges of machine learning/data science are not quite the same class of problem as software engineering, and the deliver/work cycle can be both slower and less determinant. People read this as you not getting stuff done (your fault). The best remedy I've found is just to deliver early and often, which is sounds like you've done.
But there are a lot of other people who have other full time jobs to do and they will not have time to dig through all of those meticulous notes, no matter how productive you're being. If you don't take the opportunities to communicate regularly, you become invisible to those same people.
When they make an assumption and a decision that you aren't working as hard because you're not reporting in, even if you have the documentation showing everything that you've been doing...at that point it's now become a confrontation. To convince those same people who's good graces matter that you are correct, you have to point out to them that they were wrong. That becomes a no win situation for you.
Excessive meetings are clearly bad, but meetings that are intentionally short are often done so out of respect for everyone's time. Attend them. Communicate. Brag on yourself. Talk about the interesting problems that you're solving. Communication reassures people of progress even if your natural inclination is to go into a hole and come out the other side with a finished product.
There's an old expression that summarizes all of that pretty cleanly.
"Out of sight, out of mind."
Been seen.
First, neglecting meetings is a huge miss. If you believe they are unnecessary, it's your responsibility to explain why, and to provide a work-around to your other team-members so they can get what they need.
Second, your question about production ready vs hackathon is a classic tradeoff with startups. There was missmanaged expectations around creating a Minimum Viable Product, vs a production ready system. Somewhere your team and yourself did not have aligned understanding of what was being delivered.
Third, did you speak to your team about their perceived value of things like meticulous ticket tracking, well maintained rep, monitoring etc? Those things do matter in the long term, but reductively in the short term, unless your business is going to generate money from your issue tracking work et al, it's a waste of time.
Ultimately it comes down to your ability to make the case as to why the time spent on the work you did, ultimately impacted the business at it's current state.
From what you wrote, while you weren't slacking off, you spent a non-trivial amount of your time on things that were not of value to the business.
Did you have anyone on your team with startup development experience?
Your reports on progress were like that. Because you didn't check with the users (those who should have been reading the report), you didn't know that they weren't a format that was useful to them.
I'm not saying you screwed up in the way you wrote your reports; communication about technical topics is hard, and no one should expect to make it easy. But writing technical reports, and then not checking with the intended audience as to whether they were communicating what you wanted, is like writing software without testing it or getting user feedback. I bet you would never write software, not test it, and then expect that it was working, no matter how good you are at writing software.
So, in the future, think of communications such as reports as a deliverable in some ways similar to a piece of software. Check with your users, and test it (i.e. see if anyone is reading it, or understanding it if they do).
(1) You need visibility. You don't seem to be plugged in - what were the CEO's goals? How did his exec team manage towards them, what orders were passed down, and how did you execute on them? If you don't know, it's because you weren't plugged in - for all you know, you _were_ irrelevant.
(2) How to get visibility? You need to set meetings: project kickoffs, 30-day SteerCos, quarterly updates, AND end-of-project readouts. Out of sight, out of mind. You need to get in front of people who matter, and explain the value of what you do in a way that they can claim credit to their boss.
(3) When you get in front of $important_people, you need to speak their language. Show them the money (your exec summary is always the same: I [made, saved] $X M in the past Y months, which is Z% of total revenue). Mark progress against a roadmap. Make pretty presentations they can forward to their boss. And talk slowly (not so they can understand, but so _you_ can avoid looking silly).
When you're a freelancer, the above is _more_ important, not less. I'm sorry you got screwed (if engineers have to be good at business management crap, WTF are business managers for?) but these are, I think, the skills you're looking for here.
A good book to read on this is The First 90 Days by Michael Watkins, if you're curious.
1. Take a thinking styles test, like the HBDI (https://en.m.wikipedia.org/wiki/Herrmann_Brain_Dominance_Ins...)
People in executive roles frequently tend "Yellow / Blue" in their thinking HBDI thinking style.
HBDI certainly isn't gospel, but it can help frame the people around you and make sure your communication includes thinking style elements they connect with.
2. One time each week, make a short, bulleted summary of what is happening in words that can be understood by anyone. I first saw this technique in a lab mate. He made them in powerpoint, kept them in a binder, and was ALWAYS ready to make an account.
3. Make peace that detailed documentation should be for your benefit, and occasional CYA. Even most technical people you report to will want a summary.
4. Many decisions in business are made by people that are able to operate on gut feel. Sometimes this is works well, sometimes it doesn't. However, the outcome is largely immaterial. This is because people who only direct when information is complete don't end up leading, either formally or informally.
Appealing to the "gut" sensitivities of the de facto leaders of your organization will almost always increase your visibility.
Hopefully this helps!
They obviously do not value you. Leave and take your info with you.
1) You shouldn't be writing reports. 2) You should be at the meetings and a part of the team. It should be possible to say to business people there are '3 main parts i.e. web/front end, business logic, and data store' - they will understand that - and then to simply give a rough idea of timelines and complexities for each one without going into too much detail. 3) Your peers should understand this, when a team is small they have to have at least some understanding of the system. It's likely they are just bad at what they do, possibly from being inexperienced themselves.
I'm going to gather that the entire things is probably full of obvious problems, which is almost universally the case for young companies managed by young people. It gets papered over when 'some thing in the corner is blowing up'.
FYI larger companies are also full of bad practices, but they generally have some kind of baseline professionalism and systems that help them get through their daily operations which are baked in, and printing them money.
Chalk it up to experience, learn from it, move on.
Executives have a lot on their plate and usually work on a wide variety of topics at the same time. Therefore try to help them when they have to switch context
Concrete example:
* create a (bi)weekly status report with four sections (achievements last week, focus this week, current risks/impediments, decision needs)
* to every risk add a measure (don't admire the problem but bring a solution)
* to every decision need add the alternative(s) (usually something like "Option A", "Option B", "Option do nothing") and show the pros and cons
* show your vision and achievements. Every manager has another boss and will need marketing material to advertise what an important kind of work is going on. Show what you are working towards ("We want to use state of the art AI to improve drug development") and where you stand right now ("We have built the foundation by creating a structured training data set with records of more than 1 million drug trials")
* use abstraction to simplify (not "we switched our legacy adapter from SOAP to REST" but "we switched to a future-proof interface integration")
Regarding the meetings, cancel enough to show you are busy but participate in enough meetings to stay on people's minds
Concrete examples to improve meetings:
* ask for an agenda for each meeting and for your expected contribution
* keep meeting minutes, send them around if no one else does that
* everything that is dicussed should be related to actions that have been undertaken (status update) or will be undertaken (next steps). Every action has to be assigned to someone and has to have a due date
* I mentioned it before, focus on solutions not on admiring a problem (not "no one is providing the data we need" but "We currently lack the data. Who can we contact today to get access to the research data?")
While I don't know whether this would have helped you in the case you described, these are some general points for management communication that offer a good return of investment from my perspective.
As a guiding principle, think about what each team member needs and how they feel. Doing so would make the type of communication that would help them accomplish their goals very clear.
Imagine a car and a driver. Now imagine the car had no gas level gauge. Instead the car has two rules. 1. A driver can enter a destination distance and get a yes/no depending on gas levels, or 2. The car will give random updates of remaining range. Maybe this is reasonable from the perspective of the car designer; I mean how often does the gas state change, isn’t it micromanaging to get updates every second?
From the perspective of the driver though, how can they determine how far to go, when to stop to get gas, whether a detour is ok or will exceed range.
Empathy goes both ways. Imagine that checking the gas levels is computationally difficult and expensive. Imagine each measurement burns a gallon of gas? An empathetic driver would agree to less frequent readings.
So empathy all the things.
You could certainly have compensated by putting these in place yourself, which would have shown some initiative and leadership.
For example, you could conceptually divide your project into various stages, with milestones in each, then communicate any road-blocks that prevented you moving to the next stage.
You could also create a KPI for your model (or a few KPIs), like a % success-rate for a classifier against some kind of benchmark data-set. Even non-technical people can understand "we're at 60% now, and we aim to get to 95% by the end of the project".
Ultimately, people do not care about the unusual edge-case or bug that you're dealing with - they care about the output. Perhaps structure your communication to focus on outputs, not the minutia of technical steps along the way.
When given a task, I've explicitly asked which out of time, scope, and quality, is the most important to them.
Another important thing to keep in mind is that you get to choose the situation you are in. For future jobs it might be worth carefully evaluating who you will be reporting to and working with and their background. Even if they are not an engineer, have they worked with engineers before? Do they have realistic expectations around timelines? Do they have a level of understanding to at least talk at a high level about what you are working on? If the answer is no, it might not be the right job for you.
It's also worth understanding the working styles of the company you will join. I had previously been at a company with 100 engineers that focused on agile and used lightweight processes like tracking tasks on notecards in swimlanes on a physical wall. The next company I joined was over a thousand engineers and expected JIRA tickets for everything and writing large numbers of docs and getting sign offs from numerous people and departments before starting work. I know see that the first way of working is a better fit with my natural style, but you may fit in better with the second way.
For your situation, it sounds like the non-engineers had unrealistic expectations of what could be done with ML and how fast. Was there a discussion around timelines and you ended up going greatly over them? Or where you just going off to work and then they decided you weren't getting enough done.
I agree with everyone else who says that you have to understand your audience and tailor your message for what they care about.
But it is not. To most people.
Most people are not knowledgeable about your specific problem or challenge. Most people don't care, or don't have the time to care. If they understood it all, they wouldn't be asking for a meeting.
What they need to know is not all the process and challenges you overcame, but the outcome. What did you achieve, what were you not able to achieve, what do you need to finish the problem?
If you cannot provide those level of answers (and quite early in the presentation), then people are going to get lost (or turn off) if they don't have the mental / time resources to understand the minute details of what you're trying to tell them.
Unless you're giving a purely technical talk, you need to think about the implications of your work, not just give a summary of it. Summary is condensing all the things you did, but staying at the same level of detail. Implications take additional work to think through.
Showing lines of code is not telling people the implications and conclusions of your work. It's showing them process. It's boring. Showing them tensorboards (unless something really interesting happened) is also not implications.
It takes work. You have to think through, and put yourself into the shoes of someone who has not followed your work at the detail level, and spoon feed them decisions they can make based on your findings, not your process. If you were presenting to the CEO for 5 minutes, would you be talking about your gradient descent optimization? No, you should be thinking, what does the CEO need to know to act on the information I'm providing? You need to do the thinking for the other person, and have thought through that yourself.
And just once again, please for the love of god, don't show lines of code.
And, perhaps joining some sort of group that requires communication-- Toastmasters is one well known one.
Communication is a skill in-and-of itself. Sales & Marketing work generally teach communication involving expressing the benefits of thing to a potentially interested party. If you're able, perhaps try to get into some sort of part time sales/marketing role, such as helping out at a farmers market booth on the weekend.
Also, check out some college communication textbooks. They have a plethora of interesting advice and strategies.
Results that impact the bottom-line are the only thing that matters. If you cannot align your work to that, you're going to be undervalued and viewed as useless.
Also communicating what salary you're expecting. Maybe you accepted the job at a salary and they thought you were happy with that.
Participate in defining the goals of the company. Define your goals, that are derived from the goals of the company. Report on progress on achieving the defined goals.
Setting the goals will involve a lot of meetings.
I've found that communicating results of an ML model to non technical stakeholders is as simple as:
1) we are building the model to predict X 2) the model currently predicts X with Y% accuracy 3) I am doing X/Y/Z, eg feature engineering, to improve accuracy
The TL;DR is use the confusion matrix output from the ML library you're using to demonstrate model accuracy, false positives, false negatives, and so on.
The long answer is much more complex: Are you doing MLE work? DE work? DS work? Why are you using ML? Is it required for your current project? You haven't stated what kind of work you're doing. How you present has to do with what kind of work you're doing, so a clear answer can not be given, only a generic one.
A data scientist, for example, typically has to sit in tons of meetings hearing the business challenges over and over again, finding a way to solve the business problems, and then building a model to demonstrate feasibility and then proof of concept. They then presentation this proof of concept to sales, marketing, management, the board, or whoever else it pertains to as a way to solve their problems in an automated fashion with such-en-such percent of accuracy using a confusion matrix. The business then ruminates on this and then often comes up with more requests or modifications to the initial model, or a request to improve accuracy, or they're satisfied. When the model is satisfactory it gets handed off to a software engineer (machine learning engineer, data engineer, infrastructure engineer) who then takes their ideals and developts it onto a server and gets it connected up so that the customers end up getting that service. The engineers built it / put it all together in the end. The data scientist researched it.
Your situation sounds like you were thrown into a data scientist role and are approaching it like a software engineer, which is not an ideal way to go about things. I could be wrong. It could be the other way where you shouldn't be using ML to solve the problem, or you're productionizing other people's models. If you're truly doing engineer work, then you can show that customers are getting the service you're providing, which is a different kind of presentation, typically just updating management, not having a large company wide thing. Maybe you're expected to be management? That's a different story too.
For a business it doesn't matter why you don't ship on time. I bet the team would have been happy if you ship something much simpler on time actually. DHH was writing about the philosophy, that features can be dropped/changed by communicating, but the timeline has to be hard in business.