Todoist has become my favourite To Do list after trying a few in my quest for better productivity in the past year. I love the product because it’s simple, intuitive to use and also fits on how I use it everyday. One of the biggest selling factors for me is how interoperable Todoist for me. I’ve always looked for services that are ubiquitous – I demand that my solutions don’t tie me down to any hardware or platform. This means that interoperability for me is key. I love that I can use Todoist on my phone, on my tablet and on my desktop extremely seamlessly.
One of my objectives this year is to plan more, work less but be more productive. To compound the difficulty, I am not the most naturally organized person in the world 😀 In a recent personal assessment I did lately, out of a score of 10, I scored a 2 for being naturally organized. At the same time, in my role as a leader, getting things done is a critical part of my success. In my natural state, I tend to be distracted by the various “problems” that happen to cross my brain and have the need to want to address them. In order for me to overcome this, I rely on a number of tools and techniques. When I do, I find that I’m significantly more productive. Continue reading “Being Productive By Getting Organized”
I really like the Scrum retrospective format that I used last year so I decided to use it again this year 🙂 One of the things that I really like about Scrum is the focus on continuous improvement. The retrospective is one the easiest way to allow me to focus on the things I accomplished last year and also think about the changes I want to do for the following year.
It’s hard for me to believe but it has been a little over 9 months since I started working at Points International and what a busy but awesome 6 months it has been. A big part of my job has been recruiting and one of the biggest things that we look for in a candidate is the ability to adapt to our agile environment. Agile is relatively new to Points being intoduced a little over 1.5 years ago here which was before my time. While the company has embraced it, as one of the Agile champions at Points, I find myself constantly thinking of what it means to me especially from a software engineering perspective.
I have spent the bulk of the last 7 years developing processes. For me, processes is best used as a form of communication. Processes that are used to exert control is what you get when a team or an organization is undisciplined or isnt’t high performing. When processes are used as control, it fails miserably because they tend to be rigid and brittle. I like Scrum because it removes barriers to communications and reduces friction and enables agility by increasing communication and reduces time and distance to make decisions.
In order to be agile, any team has to be disciplined otherwise you quickly become ad-hoc. I often liken an agile product team to the same an an elite combat force like the Navy Seals or to an elite athletic team. These teams often train hard and are focused. Execution comes like second nature leaving their minds to focus on adapting to the unexpected while the mundane and repetitive comes instantly like muscle memory. An agile product team is no different. Things like automated test coverage, scrums and prioritization should come like second nature to the team.
Having run operational teams before, one of the hardest things to do is to remain focused. Most incident management processes have the concept of severities to help prevent distractions but ultimately they still happen. One of the key successes to being agile is to be focused. There should always be only one priority one for a product team and they work on until it is solved or they are hit with a roadblock. So a big part of a software engineering team’s role in a product team is to look at how many engineers can fit into a story before they block one another. A product manager’s role is to ensure that there are clear priorities and a scrum master will try to keep the product team focused and remove distractions. The idea of herding cats should be gone.
What drives the focus of the product team is the business value of what they are producing. The product manager has the difficult role of assessing business priorities with all of the relevant stakeholders and then prioritizing them against one another. Another way that a product manager provides value is to ensure that the product team is working on stories that are thought out so that the development team isn’t spinning their wheels on stories that are constantly changing.
It’s hard to provide business value without quality. Your reputation is often driven by the quality of the product that you build. However how much quality you need is also driven by business value. The one thing that I love about agile product teams is that quality is not a role that is identified with a QA person. Instead, it is considered a trait that needs to belong to everyone. It is everyone’s responsibility to deliver a quality product from ideation to delivery.
Predictability is a powerful weapon to have in your arsenal when running a business. Predictability is useful when you need to commit something to market. Once a scrum team matures and achieves consistent velocity, a business can reliably predict when they can commit something to market with predictable quality and effort.
Ultimately, to achieve all this a product team needs to be cohesive in vision and they need to have self ownership of outcomes while being driven by a business vision. I love the fact that Points is commited to being a company that’s agile. While we aren’t there yet, we are committed to being there and maturing our company as a whole to get there. Working on being agile is one of the many things that I love about working here at Points.
- Understand the business problem and ensure that the process solves the business problem
This really is not very different from developing a technology solution for any business. Like all solutions, they need to resolve a business problems. In this particular case, there were multiple stakeholders and each of their needs were different. The stakeholders comprised of the client’s business management team, the client’s technology management team, Deloitte’s management team and the Deloitte’s support team. The client’s business management team required to receive adequate support in a timely and consistent manner. They had a business to run and their own clients to support. The client’s technology management team required to be able to justify that outsourcing was a viable solution to provide similar levels of support to the business while drastically cutting their ongoing technology costs. The Deloitte management team required to be able to report the support team’s ability to meet the agreed to Service Level Agreement by quantifying quality, identify issues and react to them accordingly. The Deloitte support team required to be able to do their job without being caught up in the process. The process should be a by-product of the support process and should not take up more than 10% of a support resources total day.
- Involve the people who are going to participate in the process
This often sounds simple but it often isn’t done well because it is time consuming. We had the luxury of developing and implementing the process in about 3 months. This was reasonable and acceptable to all stakeholders because this was a major change for the client. There was a lot of negotiation between the client business, technical and Deloitte teams to come to a process that was acceptable to all. The solution was compromise for all parties but the reality, like most development projects, is that most good solutions is a result of compromise. What makes them good solutions is that is the solution is acceptable by all parties albeit grudgingly. I had a Project Manager who once taught me that a sign of a good negotiation is when all parties come out as though they have given up more than they should. It means true compromised has happened.
- Make conscious effort to improve the process
Knowing that my team was going to find any kind of process burdensome, I entrusted the ownership of improving any processes back to the team. It gave them ownership of something that they found cumbersome but they were also the ones that would be the group that would most likely be able to suggest relevant improvements. Doing this indicated to the team that the promise made at the start of the project that we would be making process improvements more than just lip service. My role in improving these processes was to understand the change, ensure they met the business objectives and then negotiate the changes with the rest of the stakeholders. The key was to make this a living process. The process had to be relevant to all stakeholders.
- Accept that documented processes are best used as a communications tool not a problem solving tool.
It is useful to help communicate to new members joining a team what is typically expected of them. It is also useful to communicate expectations of when and where other parties are interacting within the same workflow. I’m a big believer that processes should not solve all problems; they should provide the general guide and not meant to resolve every question or issue that the team will face. You have to trust that the team you have is talented and intelligent and the process has to be flexible enough to allow team members to make appropriate decisions to resolve issues creatively without ignoring the process.. It is much better to replace a resources that isn’t performing than to try modify a process to deal with a small number of members that aren’t performing.
- Keep the process simple
The reality of complex processes is that they will fail. Complex processes are cumbersome and are difficult to maintain. A process should enable the team, not restrict them. Complex processes are generally very restrictive.
- It’s difficult to properly handle the growth of more than 8 individuals
This is speaking mostly from personal experience. It’s hard to help mature and grow the talents, skill and professional maturity of any individual. Each individual requires an investment of certain amount of time and energy in order to do it well. And all this has to be done in conjunction to the other responsibilities that you have as a manager. My magic number is 8. This number is derived from me taking about an hour of the morning or afternoon for each individual. 4 days a week allows me to focus on 8 resources leaving Friday to catch up with my own needs or issues.
- Democracy is ineffective in team management
Democracy is great in politics but has no place in technology management. I’m personally a believer in hiring the right team and that often means hiring a lot of smart people. The biggest benefit of having a really smart team is that they are going to have a lot of great ideas. The biggest detriment of having a really smart team is that they are going to have really good ideas that are going to contradict each others and chaos typically ensues in a flat structure. Technology decisions should be driven by purpose. You need someone to make the decision that aligns to the technology vision of the company otherwise the result is a fragmented solution that becomes difficult to support and extend over a period of time.
- Nobody is an expert in everything
Beyond accountability, there also is the issue of expertise. You want to pick the best solution/technology for the problem on hand. When developers are stuck on an issue, they have the tendency to not want to go for help. Creating functional responsibilities around areas of expertise helps you as a manager. You need to have go-to individuals for expertise when you have to make a decision. The team is no different. The team should have go-to people to accelerate the solution of certain problems.
- Roles and Responsibilities are the minimum requirements for individuals
Most people look at formalized roles and responsibilities as limits to what they can do. In most consulting organizations, fulfilling your prescribed roles and responsibilities guarantees that you don’t get fired only in the good years. In lean years, most consulting organizations will look at individual performers and keep anyone who is performing above and beyond what is expected of them. Roles and responsibilities should be used as the MINIMUM requirement for any individual. To be eligible for additional reward, you have to perform above and beyond what is expected of you.
- Responsibilities is not a reflection of value
A manager has different responsibility from a developer but it doesn’t in any way reflect the developer is more valuable than the manager. A good manager cultivates that culture by fostering the growth and mutual respect for every member of the team regardless of responsibility and title. In certain organizations, I’ve created lead responsibilities within a team that are meant to rotate from member to member. I’ve also created special teams where in those projects I would function as a business analyst reporting to team members who would otherwise be reporting to me in the overall project.
There have been a number of different events in my life right now that have caused me to start to looking back in my career. One of the biggest changes for me is the switch from having a very technical role to non-technical roles. Looking back, the change wasn’t as revolutionary in my career as I first thought; it was merely evolutionary. The main reason why technology development appealed to me is because it is one of the few ways that I can actually be creative in the way I solve a particular problem. When I first started out in development, much of the problem solving and creativity was isolated in the sense that both the problems and solutions were constrained to technology. The nice thing about technology is that it is binary. Things either work or don’t work for the most part. As my career evolved, my problem solving involved a mixture of business and technology; I was now using technology to focus on solving business problems. The business problems were interesting because the answers were not as concrete. There were a lot more variables to consider. In the past few years, my career has been more about building technology teams by setting up people, process and tools.
I had offered my cousin to help her prep for her university entry interviews and I thought that I might as well put together a blog entry for it. Like everything else, I’m not claiming to be an expert but rather that I just happen to have quite a bit of experience both interviewing and being interviewed for jobs so I thought I would do some quick sharing.
To start off, I often treat interviews as a two-way conversation. Most people focus so much on being evaluated that they fail to evaluate the other party as well. Interviews are a great opportunity to evaluate whether or not this is some place that I want to be at for a large chunk of the year and if this is some thing I truly want to do. Another thing to remember as well is that just like everything else in life, interviewing is a skill as well. Just because the other party is interviewing you, it doesn’t necessarily mean that they’re good at it. Most people are rather bad at it largely because they don’t do it often. Sometimes it’s just as important for the interviewee to try to put the interviewer at ease. It sounds ironic but it works. When being interviewed, I try as best as possible to try to engage the interviewer because it makes the process smoother. Sometimes humour works, sometimes they like to engage in idea exchanges and sometimes they like to be given the opportunity to talk about their work. It’s really not like any other conversation from that perspective.
Interviews are also very purposeful and because it is, there is much preparation to do. The most obvious one is to research about the subject. If you’re going to a school or program, research about the program. Talk to people who have been in it, see what they thought about it and try to understand what the goal of the program is. Also understand what kind of culture of the program is. It goes a long way in engaging in the conversation with the interviewer. If possible, always get the name of the interviewer before hand. If it’s someone more senior in the organization, perhaps they’ve written papers or spoken in conferences. Read up as much as possible about the interviewer. Last but not least, research the organization. Get to know simple things like their mission statement or mission statements.
Not so obvious is the self preparation piece. In general, I find most people are surprisingly unfamiliar with themselves and therefore uncomfortable with themselves. Questions like what are our strengths/weaknesses often cause us to stumble because we are often unprepared and that there are no right answers. I usually focus on “packaging” myself. We are generally multi-faceted; we have many strengths and experiences that make us ideal for what we are going to do. It takes time to focus on parts of our experiences to highlight those things. It takes a bit of prep to have certain strengths highlighted. Also, I tend to take inventory of those things and have them handy. Usually, I need key phrases to trigger my thoughts and that’s what I have. In general, my packaging is usually humility, experienced and interested. I tend to read about lots of things especially on the technology side but I also have to try to make sure that I don’t sound condescending.
A couple of other things that comes to mind are to attempt to answer all questions and ask lots of questions. I usually try to answer all questions. If I’m unsure, I will try to ask questions or try to ask for examples. If I still don’t know, I try to make an educated guess. When I’m guessing, I try to prefix it with “I’m not entirely sure but if I were to hazzard a guess, it would be…” Hopefully that shows a more thoughtful side of me and at the same time, I’m openly honest about the things that I don’t know. Always come prepared with a lot of questions. For one, it shows that you’re interested and prepared. Take notes during the interview because you’ll want to use that to answer questions. Ask questions that may pleasantly surprise the interviewer but don’t put them into a defensive position. If they can’t answer the question, give them an easy out. It’s key not to make the interviewer uncomfortable.
Do you have any other tips? If so, please do share!
I’ve never been one to follow politics closely. Not because it isn’t interesting but rather that the players over the past little while have not been that interesting. I’ve been quite inspired by Obama in the few times I’ve watched him speak. I like that his speeches are simple and quite articulate. He gets the point across while making it simple for the everyday person to understand; I like that he keeps his stories relevant and to the point. There were a couple of highlights for me in particular. The first was to brush aside the finger pointing with the AIG mess and to take responsibility. “While it’s not a mess that I created, it’s my job to fix it.” The buck stops here. I like that throughout the conversation he never once diverted from that message – he didn’t try to subtlely blame the Republican for the current decisions, he focused on the fact that it was up to him to make sure that these things don’t happen. Here’s another tip – regardless of whose fault it is, he focused on trying to figure out the solution to the problem and ensuring that the problem doesn’t happen again.
Another thing that really impressed me about Obama was the ability to focus on the future. “If we’re being out-educated today, we’ll be out-innovated tomorrow” or some variant of that. It’s so true. So often leaders focus on the immediate only and neglect the future. At the same time, he understands the concessions he has to make to get to the future. “It’s not like I like paying out the banks but we need credit flowing now.” The trick is not to stop on the short term fix. So often it’s so tempting to just focus on the short term fix because it can be so tiring to just get the short term fix done.
Another sign that impressed me about Obama is that he actively listens. In the final question, he was speaking to a man who lost his job in October. He talked briefly about his overall economic plan and quickly realized that he didn’t know enough. He followed up by asking specifically what the man used to do and then tailor his answers specifically to his situation. It would have been easier to left it generic.
I like Obama. It’s nice to be inspired by an individual. He has great ideas and great attitude. It’ll be interesting to see if he has the right people to help him execute it.