This article was written by Ken Leaver who comes from a product & commercial background. He has founded multiple companies and held senior product positions at SEA tech companies like Lazada and Pomelo Fashion.
Ken runs his own agency that helps early stage companies execute faster and cheaper. Check out his LinkedIn at: https://www.linkedin.com/in/kenleaver/
Guest Author: Ken Leaver
I’ve been working with my ‘Everything as a task’ system for almost four years now. And I can honestly say that I’ve had almost no major conflict between team members during that time.
Which is quite honestly pretty different from companies and I worked with in the past in the offline world. As conflict was commonplace in many of those teams.
In part I attribute this to the fact that nobody in the team gets to know each other very well. And so you don’t see people forming into groups and ganging up on each other the way you almost always see in the offline world.
But another big component of this is good process. When literally everything you do is a task that has a clear assignee, there are very few opaque areas where it is unclear who has ownership.
And a lot of conflict in my experience relates to ownership.
This is the topic I’ll dive into today.
I’ll start with an example from 2018
In late 2018 I had moved my family to Russia to help a large ecommerce firm there. I was doing it as a contractor but with the intention that if I liked it and they liked me that I would stay on.
And the role was pretty big. I was leading about half the product in the (near unicorn) company and had something like 30+ product & design folks in my org.
Engineering on the otherhand reported separately into the CTO.
And I did not mesh well with one of the main engineering directors I was partnered with. Before I came there was no product head and so he’d been essentially heading product as well as engineering. So he wasn’t too happy that now he’d lost some scope.
And he was the type of person that didn’t mind showing his unhappiness. Particularly to me, because he knew that I had no real leverage over him. As he was pretty tight with the CTO.
My frictions with this engineering director
So he basically did as he pleased. We’d align on things and then later he would ignore it and just do what he wanted. Often aligning with business teams directly on what to build.
I’d find this extremely frustrating. Because if engineering was going to align directly with business on what to build, then there was no point of having a product org.
And the business teams would start to get confused. What was the point of aligning with me if engineering held the keys to what was built? Might as well just align directly with them.
So more and more business would just align directly with engineering so as not to lose time on a product org that seemed to lack any real authority.
We continued on like this for another bunch of months and eventually I just let my contract run out and decided to go my separate ways.
This experience taught me some valuable lessons
I learned a few very important lessons from this experience.
Lesson 1: If alignments are just verbal, there is no proof of what was aligned on.
I’d often point to the fact that we’d aligned on something, just to have him tell me that he had a different understanding from our meeting.
Lesson 2: When ownership is unclear a person with mal-intentions will exploit this to their advantage.
The process to develop things was very opaque. This was at the heart of how the engineering team was able to essentially develop what they wanted and ignore me/my team when they wanted.
Lesson 3: The way to avoid conflict was to make ownership and process VERY clear
Who owned the product part of development in the org? It wasn’t really clear. If I talked with some of the engineers they still assumed it was them. Nobody had even made it clear to some of them that they need to listen to product.
Sometime later I created systems that learned from these lessons
These lessons I mention above were at the heart of how I started creating my systems afterwards in early 2021. I wanted to create transparent systems that would never allow things like this to happen again.
I wanted to create systems that would expose the unprofessional bullshit that I had to put up with because everything would be in black and white… written in cards.
Literally everything would be a task in Clickup with clear ownership.
If someone ignored what we agreed on, it would be documented in a task and i’d just point to it.
If someone was poor at responding then again, i’d have tasks where this would be very clear in the comment history. And they’d have to answer for it.
In a way I considered it my version of the US terrorism policy, “We do not negotiate with terrorists.”
My version was “I do not negotiate with people that operate via this opaque bullshit anymore.” I am gonna fry them with my systems.
I’ve applied these lessons the last four years
These days I try to interact with literally anyone I work with ONLY via my systems.
My team of course has to use them because I typically hired them and have direct leverage. But also they very quickly see the value and enjoy it. Because it gives them transparency and independence. And because I am very supportive of them as long as they try to do a good job.
But even with other teams that do not report to me, I will apply my systems. Even if it is a client.
Now if some other team is not using Clickup, then I of course cannot force them to use my process. But typically I will align with the CEO that I will still document all the tasks that me and my team do in Clickup, and I will tag whoever I need cooperation from into the cards we work on.
This way I mimic my system by essentially replicating any of their communications to me and my team into our cards.
An example of how I use this system with teams that do not report to me
Lets say, for example, that the head of another team tells me that they’ll get me the design I need by Tuesday.
I’ll have a Clickup card in my board for that design and I will update with a comment that says “Joe just told me he’d get me the draft design on Tuesday.” And i’ll set the due date to Tuesday.
Then if Joe hasn’t gotten me the design by Tuesday I will ask Joe via Slack. And he’ll say “Oh i’ll get that to you Friday”. Again I will reflect this as a comment in my Clickup and update the due date to Friday.
Note that I’m not reliant on Joe using Clickup at all to do this.
If Friday rolls around and Joe still hasn’t done it and rather has an excuse, then i’ll again update my card with a comment.
And if the CEO than asks me the next week why it wasn’t done yet, I’ll just send the clickup card to him. Where the CEO will clearly see that Joe promised me to have it three times and then came up with an excuse each time.
And Joe will most likely get a less than happy message from the CEO.
But Joe will also have learned a very important lesson about how Ken operates. Ken documents everything he does and updates every important interaction with other teams when it relates to the tasks I am responsible for.
And if Joe is smart, he learns not to take that tact with me next time. Because i will expose his actions with transparency each and every time. Methodically. Like a Navy SEAL mowing down undisciplined terrorists.
Things typically just work smoothly pretty much all the time now
Now it might sound from the above that I am some aggressive badass or something. I am definitely not.
As long as folks are cooperative, people will find me to consistently be one of the most cooperative people they ever worked with.
When they need my help I give it.
When I tell them they’ll have something by a certain date, they know they can count on it being done.
With the systems I use I have had almost no major conflicts in my teams the past four years and I much prefer it that way.
And the reason boils down to this simple philosophy that I take now, which I call… “Good process = Good colleagues.”
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
