This is a follow up on last post on goals and finding a utopia. This is my current vision of what I think would be a nice place to work. Not saying it is perfect or covers everything, but it gives me a direction of where I’d like to drive things.
Woke up at 0730 Monday morning by the largest hug from my daughter and a kiss from my wife. Sun is shining outside, it is -12 degrees and it has been snowing heavily outside, 60cm of fresh powder. Get out of bed and make a cup of mother beautiful coffee. Make some small talk with my family and play a few minutes with our little girl before going in to the office. I start up my computer, put the coffee down, put on The Doors on the HIFI and check in with my team mates.
Nancy is our HR and Finance specialist in our team. She keeps tracks of us, makes sure we get enough money in. We don’t measure cost in the traditional sense, but rather throughput and that we get more money in than we spend which includes our salaries and the tools we use. She knows as much about programming as I do about HR and finance, which produces good enough software. Always on her toes and likes early mornings, so she have most of the nights events covered when the rest of us drops in.
Adelaide has been around longer than any of us. She has been with the company for ages and have been to more companies than years I’ve been alive. As a business analyst she has the intel of what we are doing and knows most of what will happen when we discuss. Having been around for so long and holding so many positions during her career she knows her way around most programming paradigmes, writes code like a godess and has a capability of sharing her knowledge in just the right moment and amount to trigger one and make all of us better. Being a database junkie and seen stuff from the seventies and onwards means she knows what works when. On mostly her recommendations we run different stuff on graph, Hadoop and document stores. We even have some things in a relational database, but it is diminishing. It rarely fit the the needs.
Then we have Alex, our Product Specialist. His programming skills aren’t the best, but on the other hand he has ideas like noone else and a way of visualising and making them tangiable for the rest of us in ways we can only dream of. As a visionary and knowing our product inside out, he has a good way to point out our way forward and making sure the goal is always just out of reach, making it clear enough to know what to do next as well as pushing us to go further.
Pink is our DevOps awesome sauce maker. Always dresses in black and have been around computers and electronics since born. Pink can script anything and makes sure we always deliver in terms of keeping us with the greatest tools and platforms no money can buy, but only the hands of Pink. Though young in age and in the team, never stops to amaze and comes up with the craziest ideas and finds the most peculiar things to do with the strangest pieces of technology. We mainly run our stuff in the cloud, but also keeps some private servers on location with all of which Pink does what seems like magic to the rest of us.
Then there’s me. Happy to be here and blown away by all the fantastic people around making this place special. As a developer I bring general software knowledge to the table and work closely with Alex to realize visions and ideas, but also acting as generalist specialist. Me and Alex are the ones who mainly write “product code”. But we know we couldn’t do without the others. How else would we know if it performs? On what will it run? What do we do if…?
All we need to do is fulfill a “team contract” which means that the product must be deliverable by https, provide a stream of things happening for other teams to take part of, bring in more money than we spend and keep us up for as much as we can. If we experience downtime, we must do what it takes to get us up again ASAP. In a way you could say that we are like a company in the company and the company provides a platform for us to exist within our line of business.
When we work we collaborate on all we do, we just happen to be different kinds of specialists mostly based on our past experience and interests. We don’t do several things at a time. We do one thing at a time and we ship it. Usually shipping means a day or two, sometimes a week if it is something really large, but regardless of feature size we put things in production 4-5 times a day so we get the heads up if we’re about to hit a snag. Something might not turn out the way we thought, there might be something we can’t really solve in a good enough way or something else we didn’t foresee. But since we don’t buy in with more than a few days at a time, it is never a big loss. And if something new, The Thing Of The Day comes up, it is never far away, like a few days or so.
The way our team choose to work is that we don’t keep a backlog, just a well defined goal which we just can’t reach with this next feature. We try to keep two things in the pipeline at a time, one to work on and one coming up next. When it is time for getting something new in there we just brainstorm for 30mins or so, have a poll and take the one we agree on. Sometimes if something has resurfaced enough times we pick that one anyway because we’ve seen it so many times that there is something in there making it important for some reason.
After that we do some kind of design meeting for lack of a better description where we set some general guidelines on input and output, what to measure and how aswell as defining when it is done and what we must achieve in order to call it success. There’s not really any architecture to consider, most of it is in place already and the parts we put in production every two hours or so are so small they don’t need much architecturing in themselves. When it comes to tech decisions it is mostly a decision of what we see fit or if we want to try somethings new. Since the parts are small it is easy to write something in one language and if it turns out to be a bad idea it is mearly a couple of hours to replace it. During this meeting we also setup the basic contracts we will use and deploy them right away. That means we all know and understand why every propery exists and the purpose of every attribute.
If something, god forbid, would go down. We know the drill. We all drop what we are doing and collaborate on the issue. We usually keep a Skype call or Hangout open to discuss loud and clear, exactly what we are doing and looking at. Last time that happened was last month when a service went down because of a bug we had created. But it was minor and didn’t really effect anything but we treat them all equally. Those kind of things happen maybe once a month or every two months, while a real outage is extremely rare. We run on AWS and a new cloud player based in northern Sweden and can fall between them at any time. Usually we run a few days on one and then switching just to make sure the switch is seamless and that they run equally good. Sometimes we run on both at the same time, some services on one and some on the other just to see that they play nicely together.
We don’t have any QA in the team, yet. Simply because we haven’t seen the need in the common sense. We do testing ourselves in different manners. Unit testing, “firedrills” (we thought Amazon seemed to be doing quite well with the chaos monkey so we implemented one as well), and different integration testing through our endpoints and such. But mostly we rely on the dashboards that mostly Nancy, Adelaide and Pink have created which shows us in pretty much real time exactly what is going on with our product. Are orders declining after a release? Do we have any deviances? Are things running slow? Is there something not responding?
We are however thinking of getting another person on the team which would be some kind of UX specialist, or as we see it, an Experience specialist. This guy would know more about interactions and perception of things. Both of what we produce for external customers, but also for us and our tools as well which would make us even quicker and better.
But, today is monday and there is all this fresh powder outside! I tell the team I need today and tomorrow off since the skiing will be off the charts. Noone has any objections since there is always stuff to do and we are not dependent on one another really since everyone can do eveything more or less. Knowing this and that we have free vacation and just work under the “team contract” gives a special kind of freedom and easy to keep things in balance and feel we have enough time for what we hold dear too.
Though the company is based in Tokyo, this team is located in Europe. Adelaide is in the countryside of England, Pink doesn’t really live anywhere but travel around the world most of the time but use Amsterdam as a base, Nancy in Stockholm aswell as Alex. When I got this opportunity me and my family were in Stockholm but decided to relocate given the opportunity. So now we live in the french alpes just a couple of hours north of the french riviera. My wife took the opportunity to start a business where she can work with the environment.
We meet up with the team IRL about once a month, usually at someones home, but sometimes we decide on some resort or similar, we are like a family more or less. The company thinks that it is important to be able to, within the team, work together at the same time. So the same timezone is what we strive for. And it seems true, though with Pink travelling a lot we don’t see we couldn’t solve it should the problem arise. This has helped the company tremendously in recruiting, since we aren’t blocked to a location. And, we get the perk of all going to Japan about 3-4 times a year to meetup and share our thoughts and insights with the other teams.
I take our daughter to kindergarden and go off hiking to get some good lines. Knowing I can both have the cake and eat it.
I love my work. I love my family. I love life.