September 19, 2013
My job involves working closely with programmers and testers, identifying their impediments and helping them find ways to solve them. The team can remove most of the impediments, much more than developers would expect. There is however a restricted set of impediments that require management intervention, usually in the area of: better facilities, acquisition of tools and hardware. I teach the team and the Scrum Master (or facilitator, depending on the flavor of agile or lean used) to make these impediments visible to the manager and build a case for why they are important. This is when we hit a wall; “they will not do that because it is expensive”, they tell me. I teach them they should try anyway and trust the managers will work to remove the impediment, if the reasons are good enough.
Once again it comes back to mutual trust. I expect developers to trust the manager. This works for the best of the project, product, team, company. I expect the manager trusts the developers. The manager asks things that would make them more productive and would pay off in the long term. I expect the manager to come with alternative solutions if the problem is more complex than the team can see from their level. I expect the developers to understand that the manager wants to solve the problem, but sometimes it takes longer and requires creative thinking.
The truth is I have rarely seen this kind of trust between managers and developers. I have seen it in the Bucharest location of a large product company, in the Bucharest IT department of a large telecom company and in an e-Health department of a large German company. In these places, the environment was great for working, everyone was speaking openly, impediments were removed in time and the team became more productive. I had the feeling of a team that includes programmers, testers, designers, facilitators (or Scrum Masters), analysts, product owners and managers. This team works together, understands the challenges they face from business to technical level and overcomes them as one body and soul. It’s never easy, but can be easier to steer such a team in a new direction; this is the agility that companies are looking for. Such trust is built in time. Results matter: if you keep delivering what you promised, people will trust you more.
This is why, in Mozaic Works, we keep track of our promises to customers and make sure we keep them. Truth matters: if you cannot deliver something as promised, make sure your manager learns as soon as possible. This is not an easy conversation, but I have learned from Joe Little that bad news does not get better with age. One mistake developers make is to consider results synonymous with building trust. It is not enough because results are dry. Human relations are the other side of the coin of trust. When is the last time you have met your manager in a one to one meeting? Have you ever met your manager in a one to one meeting? How about the CEO?
I have worked in two medium outsourcing companies in the 2000’s. Both were acquired by larger companies, and management changed in one of them after the acquisition. Twice a year, I would go to the secretary of the CEO of the Romanian branch and ask for a meeting, whenever he was available. We would discuss for 30 minutes;
I would ask about the company strategy with respect to my position, about my career plans and opportunities I saw, about the impediments I had during my daily work and about things that required clarification because were not communicated clearly. Despite the workload a CEO has, they always welcomed me, had an open conversation with me and sometimes improved things after our meeting. I did this naturally and fearlessly.
After all, CEOs are people too, and what was the worst thing that could happen? That is why, I am still unable to understand why developers would look away whenever I mention discussing with their managers. I can imagine many reasons, but I am far from really understanding it.
It is true that in an agile or lean environment, managers should open this communication channel. At least once a month, your manager should invite you to a one to one meeting, or 121 for short. We have to understand though, as developers, that as difficult as it is for us to write software with less bugs, as difficult it is for managers to introduce new habits. If you want their help, try helping them too; in the end, you will help your environment to improve in time. Maybe in a few months you will feel better, you will be more productive and who knows, your salary might grow too. Not only because you keep your promises, but also because you have opened conversations with your managers and they know you can be trusted.
Want to build trust with your manager? Here are some ideas:
- What would you like to accomplish in your career? Let me know, and I will try to advise you.
- Do you communicate in a clear and assertive way? Ask me and I’ll explain how to do it.
- Can you keep your promises? An assessment will help you find out why not.
- Could your manager do better? Tell him about the Management 3.0 workshop.