Ownership, Commitment, and Communication

Three words, three values. These three words have been helping me set up and drive norm and culture of the teams I have been working with in the past ten years or so.

I have to say, I started with a much bigger list of values. Caring, Teamwork, Agility, etc. were all on my list. Overtime, I set a goal and a challenge for myself to simplify the values to three words. I believed, this would it make simpler for everyone to understand, remember, and apply.

I settle on those three, because of a few reasons. First, everything else on the list was a given thing on these days work environment. I mean, over the time I noticed that, having something like Caring on the list felt unnecessarily. It was like asking people not to hurt each other. By default, people don’t hurt each other. I figured, in a normal situation pretty much all people were caring for each other and it already was a norm. of course, once in a while you’d find an outlier, but then the team would reject him/her. So, items like Caring was removed from my list.

Second, the three selected values encapsulate or result in having the other values on the list as well. To understand it better, I explain in value in more details.

Ownership

The most important of all, from my point of view, because, without ownership the other two are not really helpful. (they won’t have a purpose)

By ownership, I mean we are all in this together. Irrespective of what each one of us does, our titles, and our location, we are equally responsible for the success of our purpose. I remind the teams that hierarchy and titles exist so that we can scale and do a better job a bigger team; that’s it. Each one us should have analytical and critical view to the whole thing not just the bit that we are “officially” responsible for. For example, as a tester in a software team, you won’t ever say, I didn’t test it because it was not part of acceptance criteria. Or as a developer, you won’t implement a feature a certain way, without raising your concerns (if any), just because it’s what’s been given by the UX/PM/DM. They are just human, and they can make mistake, miss something, or simply did not think of another way of doing something. We need to act as if we are the ultimate owner of what we are building, try to analyse everything coming our way and see if it’s missing something or there is a better way of doing it. and if there is be sure to raise it. no matter where it’s from, your manager or the CEO of the company, we need to raise and share our comments/suggestions.

Of course, ultimately there is going to be one decision maker, depending on the situation, but that should not stop you from sharing your observations. At bare minimum, it’s going to be an educated decision. This also drives a cultural of having a safe environment to criticise and be criticised at all levels.

I cannot tell you, how many times this value has saved me from making mistakes at various levels. It’s helped produce higher quality products, drive more teamwork, get teammates closer to each other, be better at what we do, and retain employees for a lot longer time.

It’s even caused us to change some strategies, in a good way, just because the feedback was valid and was the viewpoint that we had missed at senior management level.

Commitment

As the name implies, this value means that we need to do our best to honour our commitments as a team. We all know it’s almost impossible to always honour our commitments, because of various reasons. That’s why we say do our best to honour our commitments. However, having this as a value, keeps everyone on their toes (in a good way), drives a lot of teamwork and out of the box thinking. While we may miss a commitment or two or three, we know that we did our best as a team to not miss them and we also did a lot of innovative thinking. They are all going to help us be better at what we do and do it better next time.

Communication

I don’t know about you, but for me, most of the times where there has been an issue/problem/misunderstanding, (personal or professional life), it has been due to communication issues. There was no way I could take this off my list.

I keep reminding everyone, including myself, it’s better to over communicate than taking the risk of something being lost in communication. This could be as simple as, when you are sending an important message through Slack/Email/Etc. to someone, not to assume that she will read it. if it’s important just maybe walk to her desk to confirm that she has seen the message. Or, letting the team know that for whatever reason you need help with some tasks in hand. Or, making sure everyone is aligned about priorities by repeating it a few times, if required. Don’t just assume that everyone understands it the first time.

Keep communicating clearly until you make sure your message is heard.

As I have mentioned above, these three values have been helping me drive a lot of good behaviour and team culture, in the teams, in myself, and even for other senior managers.

Honestly, at some point in time, I felt weird if I had an idea/suggestion and nobody commented on it or criticised it J and I was very proud of it…

What are the values on your list?

Why did we choose Native Mobile Development for Nintex Mobile

Browsing the web, today I came across the news that Drobbox is also ditching code sharing and moving to Native Development for their mobile apps. Looking at the recent trends of big companies, like Airbnb, move towards native mobile development, this was not a surprise at all. However, it made me have a flashback about our mobile development journey for Nintex Mobile.

Back in late 2011/early 2012 when we started looking into which technology to use for Nintex Mobile, we POCed Native development, PhoneGap, C++ and Xamarin. However, the most important question we wanted to answer was not which technology was cheaper/quicker to develop on, but

WHICH TECHNOLOGY WORKS THE BEST FOR OUR USERS.

Don’t get me wrong, we were not Google or Facebook with unlimited resources and cost of development was definitely a factor for us to consider but not the most important one. With that priority in mind, PhoneGap and Xamarin were quickly crossed out. PhoneGap did not hit the bar from the experience point of view. Xamarin was fairly new back then and the effort we had to put in for getting what we wanted was significant, we hit various limitations (same as PhoneGap), and the end result was not hitting the bar either (although it was better than PhoneGap). It took us a while but we could finally get C++ working and result was good. However, there were way too many hacks and not standard approaches (for bridging, etc.) that made it a big risk. We knew, being an enterprise app, we needed to push each mobile platform to it’s limits for all sort of features, like network stack to support various authentication, etc., and not standard approaches is going to be fragile and time consuming. On top of that finding non standard resources on stackoverflow was going to be an issue. (yes, that’s the truth that everyone consults with stackoverflow and google for their software development questions :0 )

Well that left us with native development for iOS (Objective-C), Android (Java) and Windows (C#). (yes, we did Windows as well ). We formed a team to implement Nintex Mobile app, with one caveat, none of them had experience in mobile development. They were Enterprise App Developers with a great knowledge around Enterprise Software Development and Design Patterns. (I still dont know if that was a good or a bad decision )

The team had the first version of the app for iOS and Windows ready for release in 4 months or so which was a great achievement. With no experience in mobile app development, we tried to follow the best practices which were available at the time to setup the code, build pipelines, etc. but they all seemed so immature compared to the enterprise apps. Soon after the first release, we started doing Android. Developers being developers, i.e. efficient, they realized that there should be a more efficient way of delivering the same solution on three different platforms without compromising on user experience and functionalities. That’s when their experience came to help. So, We started asking the question, what’s the most time consuming part of delivering each feature. The answer came to be “defining a solution”. i.e. when to make a call, when not to, when to cache the result, when to prompt for authentication, what to do when the network call returns 404 or when user enters x instead of y. Then we realized that irrespective of the platform, these are shared logics and scripting them in different languages is not the hard bit. Next step was to see how we can logically share the “solution” for a feature across various platforms and implement it in different languages.

First step was to do a bit of refactoring (ok more than a bit ) to align the architecture of the application on iOS, Android and Windows. Back then we adapted MVVM and managed to implement the same architecture on all three. The layers structure was the same and they shared same name as well. Basically all the none UI classes and their interfaces had the same name. For example, if you had a tasksRepository class with getTasks method on iOS, you’d find a class and method with the same name in Android and Windows in the same logical location. The logic within each of the “business logic layer” classes were also almost identical but written in one of the three languages. All the platform specific technologies were wrapped in xyzHelper classes. For example we had networkHelper class which was in charge of making network call, fileHelpClass which was responsible for interacting with files, etc. These classes did not share any code/logic as their sole responsibility was to abstract platform specific implementation of network, file, sharing, capabilities enable the rest of the app to utilized them through a common interface. For example, the an instance of the networkHelper class gets injected into the taskRepository class, which would use the httpGet method of the the networkHelper interface to make a http call and get a lis of tasks. etc.

Basically instead of sharing code, we share the logical solution and we created the architecture to enable that sharing in an efficient manner. Once the solution is defined and implemented on a platform, it’s just a code translation (objective-c to Java, etc.) to implement it on another platform. Also overtime we realized that if one person does the same feature across all platforms, we get a a lot more efficient and consistent result.

After a while we were so consistent that if a logic related bug was raised in say iOS we for sure knew the the same bug would exists in other platforms. Again, once in a while we used to get platform specific bugs, like a strange behaviour for NTLM authentication on iOS etc, which had to be fixed in the one of the xyzHelper classes.

This approached has helped us be a lot more efficient and consistent while delivering native experience to our users. It has also help up pretty well. 8 years later the approach and the codebase is still the same and it’s given us so much flexibility that we have been able to use the same code engine to create Nintex App Studio.

And before I forget, I am not talking about a team of 30, 40 or 50 mobile developers. The team behind this was a team of only 8 people. One hands on manager, 4 developers and 2 testers.

Now, I am sure cross platform technologies like Xamarin, React native, flutter, etc. have come a long way since then and They are for use better choice for some projects. (even back then PhoneGap and others would be a better option for some other projects). However, the take away form our experience would be that start by asking which technology is going to serve your customers better and choose that one. It goes without saying that you need to apply common sense to this by considering your scenario, skillsets, funding, etc.. For example, if you are a start up with very limited fund, you may not be able to afford doing native development in the first go and may just want to start with something quicker/cheaper and then quickly move to native, once the idea is proven and you have more fund to invest.

The native technologies have served us pretty well and looking back I am very happy with the decision the team made back then.

Nintex Mobile – Runtime Rules Work on Android but not on iOS, Windows or Windows Phone

We get this question a lot that why some Runtime Rules work on Android but no on iOS, Windows or Windows Phone. So if you have created a validation rule or formatting rule in Nintex Form which works on Android but not the other mobile devices, most probably the issue is that you have used a custom JavaScript syntax instead of Nintex Form functions somewhere in your rule.

In most of the cases we have seen, users use == instead of equals(), > instead of greaterThan or < instead of smallerThan functions.

For example if you are writing a function to check age which is entered in AgeTextBox control you have to write it like this “greaterThan(18,AgeTextBox)”. This would work on all platforms but if you write it as “AgeTextBox > 18″ it would NOT work and is basically not supported.

To make sure your Rules work properly on all platform use the functions provided in by Nintex Form and avoid writing any custom JavaScript function in your Rules.

Your Product Reflects Your Team(s)

Yes, I truly believe that a product is pretty much reflects the team(s) working on it, their standard and their work culture.

In the software industry we keep talking about getting closer to customers and hearing their feedback, validating features/products, market testing etc.. which are all very valid tasks and we should do them in most scenarios.

I think we sometime miss the point that instead of blindly listening to user’s feedback, we need to listen to them and then start working on providing the best solution considering all possibilities and constraints and this is something which has to come from the team, not the team manger, not the UX and not the product manager but the team which includes all of the above plus engineers and testers. Fair enough I have always been saying that one person should have the final say and I still believe in that but the point is that you cannot/should not expect one person to cover all the possible requirements, quality measures and failure points. I dare saying that’s very, very unlikely that one person can cover everything and not miss one. If you are in a team which operates like that I bet yourself in situations where something has gone wrong and the engineers or QA would say “It was not part of acceptance criteria” and the product manager would say “We did not get that from the user testing UX team conducted” and the same sort of “excuses” from different people. This kind of team/culture would reflect in the product as either poor quality or missed deadlines.

In contrast, when every team member feels as equally responsible as the top manager, everyone feels like an owner of the product, is involved and would not close her eyes on something missed by another team member/process. For example an engineer would not only think about what is written in the user story but will also think about what is not written or how it could be improved and share it with the team. The same with product manager and testers. They would look at the product as a whole rather than just doing what is written somewhere be it a user story or user testing result. They’d challenge requirements, decisions and processes (in a positive way) and when a decision is made everyone moves on. This kind of teams/culture, reflects itself as high quality product which gets delivered on-time, because if UX or product manager misses something, it would be picked up by the developers or testers or someone else from the team. Well this does not mean that the team would absolutely miss nothing. They will but it will be much less and when it happens you won’t hear “it was not part of acceptance criteria” anymore but everyone would rather say “Yeah, I missed it (sorry)”. As a result of this work culture, you find team members taking pride in their work and motivated to deliver a better product/feature each and every time. why? because it’s their product, they are the owner and they are being heard when they give a feedback.

I am very lucky to work with teams like this which makes my job even more enjoyable. I’ll write another blog post on some of the techniques which have helped us setting such a culture in the teams.

We are hiring and here are some reasons for you to come and work with me at Nintex

So first things first. You are asking if this is a marketing email? answer is yes. I am expanding my team and I am writing this post to convince smart developers like yourself to come and work with us at Nintex. It’s me writing this and these are my own view points. No one from the company has asked me to write this (in fact no one knows that I am writing this. not even HR).

If you are reading this post I am assuming you are already familiar with work culture in good IT companies and their benefits like flexible hours, hack days, free drinks, great work place etc. So I won’t bore you with them.

What I really want to talk about is what we do and why I believe Nintex is developer’s heaven

1- What do we do?

So my team and I work on mobile applications. We create enterprise mobile apps in real sense which helps companies be much more productive. Now creating mobile apps is cool itself, but boy tell me about creating high quality enterprise mobile apps. Not many of us are fortunate enough to get to work on enterprise mobile apps which pushes mobile applications to their boundaries. It’s cool. It’s like the hottest thing now.

2- How do we work?

We are open to any practical development technologies be it native, xamarin or hybrid. You get to work with the latest and hottest technologies. At the moment we create our apps using native languages Objectve-C, Java and C#. All of us code in all three languages on all three platforms. It’s as sweet as it gets for developers. You get a taste of everything xcode, eclipse, visual studio you name it. But the coolest thing is how we design our apps architecture across the platforms. we have literally managed to adapt all patterns we use in backend technologies to all platforms and keep them alike. Inversion of Control, Dependency Injection, Repository pattern you name them and we have them on all platforms. Heck, we have even managed to replicate C#’s Async-Await in Objective-C how cool is that?

3- What about the team?

So pretty much everyone in the team comes from enterprise development background and that has helped us a ton. They are all passionate, intelligent developers like yourself who are absolutely fun to work with. We constantly communicate in the team about technical and non-technical stuff. and we learn a lot from each other. It’s absolutely a flat team in which everyone owns the products. All of us keep mentoring each other and teaching each other new stuff. In short you know you are working in a team when someone else fixes your broken unit tests without you knowing

4- Is it challenging?

Absolutely. Challenge is what keeps on going and not getting board. Everyday we have some nice technical challenge to attend. It keeps the blood flow constantly.

5- How is the company?

I will tell you this from developer to developer, I believe that it says it all; There is absolutely no bureaucracy.

6- What is the most important thing you achieve?

OK, for all of us it’s the fact that what we do makes some people’s life easier and make them more productive. If you want to see an example check out this two minutes video https://www.youtube.com/watch?v=xXYyvXz6_eI&feature=youtu.be

7- How is life in Australia? (if you are not in Australia already)

Well there is a reason Melbourne has been the most livable city in the world in the last few years :)Great people, great life style great city. I am an expat here but I wouldn’t leave this place and neither will my wife both of us love it here.

I tried to keep it as short as possible and hopefully this will give you some good reasons to come and work with us. So if you fancy working with us in the down under, drop me a line and we’ll setup some interviews. My twitter address is: https://twitter.com/vahidtaslimi and my email address is: [email protected].