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.



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.



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.



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


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.

Process Automation Life Cycle – PALC


Sure, Process Automation Life Cycle, i.e. PALC, is something I just made up, but why?

Coming form Software Development background, Not long time ago, we have always been talking about Software Development Life Cycle, SDLC, methods and best practices (and a lot of people still do). We did that, because as software development was maturing, we needed best practices and guidelines to ensure the success of the projects. Since then SDLC has come a long way and we have got a lot better in delivering software systems.

Now, I feel the Process Automation, you can also read it as Digital Transformation, is where Software Development was 20-30 years ago. It’s still new and there quite a few flavours of approaches and implementations for it. A lot of companies are still learning best practices and approaches, where to start and where to end. So, I was thinking, it would be just a matter of time before the same concept as SDLC starts emerging for Process Automation. I Googled it a bit but didn’t find anything, and then thought let’s use the power of internet, start something and get other subject matter experts thinking. Hence, came around PALC.

I have spent good chunk of the last 10 years of my careers implementing solutions which helps businesses automate their processes. During the journey I have seen quite a few Process Automation projects and learn from them. I have also been lucky enough to be able to work on one of the leading Process Automation platforms which enables users to automate their processes with no or code. This has helped me gain a good exposure to the Process Automation domain. Based on my experience, you can break down PLAC into three main phases:

  1. Identification: Identifying the process across the business, centrally managing them and flagging the ones which are a good candidate for automation.
  2. Automation: Automating the flagged processes with the tools available
  3. Optimisation: Monitor, analyse performance of the processes, and optimise them accordingly.
PALC - Process Automation Life Cycle
PALC – Process Automation Life Cycle


I know it’s a bit strange at the first glance that Process Automation Life Cycle does not start or end with the Automation phase. I mean you could do that, but in most cases it would create a lot of silos and redundant works in companies. (which is totally against the merits of Process Automation)

Before I go into details about each phase, I’d like to call out that I assume you have your senior management buying in the whole Process Automation shift. PALC is only about the approach of implementing Process Automation.

Ok, let’s go a bit deeper in each phase:


As I mentioned above, PALC does not start with actually automating processes, but rather with identifying and creating a central repository of the processes in the company. This creates a holistic view of the processes in your company and I put my money down that you will be surprised to see how many processes are there which no one, except very few people, would know about, also, how many similar processes are there which can be merged. Most probably, you’ll find a few processes which were defined long time ago and never got changed, where they should have been. One more common scenario’s which companies face is that they find quite a few processes which can be potentially be merged into one and drive better results.

Once you have the central repository of your processes, there is some manual work required to review them and identify the ones which are prime candidate for automation. This, as we I call them the low hanging fruits or quick wins, are the smaller, less riskier processes with minimal dependencies on other organisations. There is both psychological and efficiency benefits to this approach. The low hanging processes normally are easier to automate, quicker to see the result and less riskier to changes. Hence, the learnings are going to be a lot more and the company sees progress and result a lot quicker.

Then move on the identify and flag the processes to be automated in the second, third, forth, etc. rounds

You can also identify and mark the processes you don’t want to automate because of any reason like compliance, regulation, effort required, risk etc. and I believe it’s ok. I personally rather be pragmatic than idealistic.


Next up, is moving on to automating the processes you have identified. There are quite a few tools out there, and more and more coming, which are designed to help companies automate their processes with minimal effort (low/no code) compared to writing a new software. Meaning, you normally don’t need to be a software developer to automate a process or you’d one for a short period of time. Depending on the type of process you may want to chose a tool with the specific capability.

Just remember, you’d want a tool which enables you to:

  • Automate the identified process as soon as possible,
  • Change them with minimal effort,
  • Put them in action with minimal deployment hurdles .

You almost want a tool which lets you prototype automating your processes in quickly, and change that prototype to the real final solution with very minimal effort.


The world, the regulations, and the way businesses operate are constantly evolving, and so should your processes.

Also, when you define and implement a process, you probably wan to monitor how it’s performing and if it actually has been effective. Based on your monitoring results, you may want to go back and change or optimise the process. Up until recently, this stage had been the most difficult of all, just because it was very labor intensive and error prone. It would have required a lot of manual tasks, overhead in the process execution itself, and a lot to analysis based of papers. It was so difficult that people would start questioning the value of it and, unfortunately in majority of the time, it would not happen. (unless something breaks)

Now the good news is that, with automated processes most, if not all, of the data is digitised and a lot easier, quicker and reliable to work with. Digitised data gives you an unprecedented ability to monitor your processes and find the parts which need to change to get a better result. You can also use the data to see how people involved in the process are performing and route the future instances to the most optimal one, based on the historical performance. I guess what I am trying to say is that, the limit of what you can do with the digitised process data, is the sky.


Final Word

Now that we have had a quick look at the phases, I’d like to remind you that, this is an iterative process. Using the insight you gain from the Optimisation phase, add, edit or split your process into multiple ones and feed them back to the identification phase, so that, they can follow the same life cycle.


I will try to write a few more blog to go deeper in each phase. In the meantime, please leave your comments below and let me what you think about PALC.



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.

NF Rules Correct


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.




What is the most important achievement of your professional life?

It’s a pretty standard question, isn’t it? it’s kinda being asked in all job interviews. and also once in a while when having a drink with your friends.

Up until a few years ago, normally my answer to this question was “my last project” and I was very proud of it. This was really my honest and genuine answer because most of the time each project I was involved was better than the previous one. Some projects however left me more proud and I kept mentioning them for a while. These were the project which would impact people’s life in a good way ex. makes it easier for people to do a job, make their life better or make them enjoy them their job/life much more.

In recent years however, it didn’t feel right for a software application or successful delivery of a project to be my most important professional achievement. Don’t get me wrong I was and still am very proud of them but I was not satisfied which kept pushing me to look for another thing.

So it was a while ago I started looking back at my professional experience in search of finding what it is that makes me really happy and proud. Listing down all projects I have been involved and all the things I liked about them, one common thing stood up and that was people involved in the them.

So this draw my attention to think more about the people and that was my “aha moment”. It was something which immediately made me happy and I was like How come that I did not think about it sooner…

Anyway since then my answer has changed. I am proud of the products and services I have helped to deliver but I am most proud of the people I have helped grow. I have been fortunate enough to work with some ultra intelligent people and also have had the opportunity to help some of them find a suitable professional path, learn more, gain confidence and grow. This is one of the most enjoyable thing in my life.

So next time anyone asks me What is the most important achievement of your professional life? my answer would be the people I have helped grow.

Launch Nintex Mobile from a hyperlink and pre-populate authentication fields

Update 2016/06/23

Nintex Mobile has deprecated support of pre-populating sign in information using deep link. On the other hand you now can Launch the app, open a specific form and pre-populate it’s field using a deep link url.


Nintex Mobile is a great way to take your business process with you on the go anywhere; no matter you are online or offline.

To use the app you need to download it from the store and sign in to a specific SharePoint URL using your credentials.

Nintex Mobile iPhone

And if you want to connect to an Office 365 tenancy, you need to first select Office 365 Account and then enter the tenancy URL:

Nintex Mobile iPhone Office 365

While remembering all of the information and instructions for an advance user is not an issue, most of users have to refer to the instruction sent by IT in order to sign in and use the app.

Nintex Mobile 3.0 has got a new feature which lets users launch the app and pre-populate authentication information through a hyperlink. Using this fantastic feature users don’t have to remember their authentication type, SharePoint/tenancy URL or their domain. All they need to do is to click on a link enter their password and sign in.

This feature makes deployment of Nintex Mobile in organizations much easier for IT.

So let’s see how to create a URL to launch the app…

the URL structure is as follow:


now lets look at the parameters we can pass to app using the hyperlink

authtype: The parameter indicates the type of authentication your company support for Nintex Mobile. Possible values are:

  • sharepoint
  • office365
  • microsoft

url: A string representing the SharePoint URL user should connect to. If you use Nintex Mobile to connect to an Office 365 tenancy, this represent the tenancy URL to which users should connect to.

Please note that this value must be URL Encoded. To URL encode a URL you can use many free online tools like this one.

domain: This value can be used to prepopulate the Domain field with your active directory domain. (this is only supported for sharepoint authentication type)

username: If you want to send a specific link to each user, you can use this field to pre-populate her username. (this is only supported for sharepoint authentication type)

*note that all of the fields are optional.

and below is an example of a URL to launch the app and configure it to connect to an on-prem SharePoint:


All you need to do is create a hyperlink in an email, web page, document etc. and point it to this URL.

Nintex Mobile URL Scheme

when user taps on the link on a device, Ninex Mobile launches and fields are pre-populated as per below:
Nintex Mobile URL Scheme    Nintex Mobile

Also if you need to connect to an Office 365 tenancy this need a URL like this:


Opening this URL on a device will launch Nintex Mobile and take user to the Office 365 page:

Nintex Mobile Office 365 URL Scheme

Hope this has been useful for you and don’t forget to provide your feedback for Nintex on https://community.nintex.com.

Delete orphan tasks from Nintex Workflow which keep showing up in Nintex Mobile

Once in a while you may end up having orphan Nintex Workflow tasks in your environment. Normally you wont end up in this situation in you production environment as this is normally as result of playing with the workflow or the list.

But anyway we don’t live in the perfect world and things like this happen and when it happens it can be really annoying. Specially if you are using Nintex Mobile to respond to your tasks. One symptom is that you keep getting the tasks even though you delete local storage. So here I show you how to delete the orphan tasks for good :)

  1. Navigate to your SharePoint site.
  2. Choose to edit the page.image
  3. Select insert => Web Part. From the Categories column select Nintex Workflow 2013(or 2010) and from Parts column select My Workflow Tasksimage
  4. Press Add button to add the web part to your page.
  5. Once the web part is added press Save button.
  6. You know must be able to see a list of tasks assigned to you in the web part
  7. The ones which have Remove task link button are orphan tasks and you can delete them by clicking on the link.image
  8. if you don’t see them in the first page, make sure you navigate to all pages and delete them all. Unfortunately the this moment there is no way to delete them all in one go and you need to do this one by one by one.image
  9. Go back to your Nintex Mobile, Delete Local Storage and you should not see the tasks anymore.

Hope this post saves you some headache.

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].