Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Promise theory: from configuration management t...

Promise theory: from configuration management to team leadership

How I applied Promise Theory to managing a loose team of people to most of whom I don’t have a line of command. PT was born in 2004 as Mark Burgess was looking for a model to describe CFEngine 3 but it soon proved able to model any complex system, and I had used CFEngine a lot when I became the Head of IT in Telenor Digital. With a lot of both operational and managerial tasks and an initial team size of one and then two, the challenge was big and borrowing help from other functions in the company was a necessity. A traditional management style was not going to work, so I decided to shape my own management style by using PT. This is the report of the first year.

Marco Marongiu

February 05, 2018
Tweet

More Decks by Marco Marongiu

Other Decks in Technology

Transcript

  1. PROMISE THEORY ...enjoy the ride! From: Configuration Management To: Team

    Leadership Class Ticket type Adult Child STD RETURN ONE NIL telenor digital Start date Route Conductor February 5th, 2018 Config Management Camp Marco Marongiu
  2. Agenda • Me and Telenor Digital • A primer in

    Promise Theory • Putting it all together... • What’s here, what’s next, what we don’t know yet
  3. Who I am • Sysadmin for several organisations; in Opera

    Software (Oslo, Norway) 2010-2016, did lot of configuration management there (Puppet first, then CFEngine); • Leader of the 24/7 squad of the IT Services Management team in Tiscali (Italian ISP), June 2005 June 2006 (5 reports); ‑ • Head of the Systems group in Sardegna IT (agency of the Regional Government of Sardinia), November 2008 March 2009 (8 reports). ‑
  4. Meet Telenor Digital • Part of the Telenor group, the

    biggest telephony operator in Norway with subsidiaries in Europe and Asia • Immersed in a “traditional” environment, yet modern – Agile methodologies – Heavily cloud-based – Freedom of experimentation, freedom to fail – Focus on innovation – DevOps culture
  5. Telenor Digital’s IT before November 2016 • Routine work distributed

    across the company (e.g. on-/off- boarding of employees, order of equipment...) • Bigger IT tasks (e.g. office network, company-wide systems) looked after by skilled engineers, but on a case-by-case basis • IT was no-one’s job and no-one’s priority • Technical debt accumulated year after year and the organisation was now feeling the pressure of it • It was time for TD to get a dedicated IT team
  6. Telenor Digital in November 2016 • I joined the company

    on November 1st, 2016 • Day-to-day tasks, the pile of legacy on my lap, different expectations coming from all directions • Lots of highly-important things, difficult to understand what should be on top and what should wait • One-man team until March 2017, a dozen helpers but no line of command to anyone.
  7. Rethink leadership • Traditional, “line-of-command-based” leadership cannot work • To

    succeed, I needed to exploit my helpers’ autonomy – Notice how my helpers’ autonomy is exactly what makes the traditional leadership style fail… • What leadership style is suitable to coordinate a group of people who don’t report to you for the most part?
  8. The three traits of my “leadership style” • You start

    by trusting each person in the team and being on their side • Don’t be a jerk • Don’t impose unless absolutely necessary
  9. Key concepts • An agent is anything that can promise

    an outcome or a capability (explicitly or implicitly)
  10. Things to notice about agents • There will be agents

    making promises and agents using promises • They make promises voluntarily, and they try keep promises voluntarily (agents are autonomous) – Autonomy and voluntary cooperation are so key to promise theory that you must always keep them in mind when using it; • There may be boundaries, limits or conditions to where the promise holds; • If an agent is unwilling to cooperate you can try to incentivize its will to cooperate somehow, as long as promising what you want is in its capabilities; • ...or you can try to impose on an agent, YMMV.
  11. Assessing promises • Who decides if a promise was kept

    or not? The agent making the promise or the agent using the promise? • There is an entire chapter in “Thinking in Promises” about assessing promises and it’s not only about assessing the outcome of an agent; however, in this particular talk we have to focus on assessing the outcome only. – Hint: you either have children or you were a child to someone: when parents ask a child to tidy his bedroom, who does the assessment of the outcome? • A successful outcome requires that the outcome is well specified in advance and is clear to both the agents making the promise and the agent using that promise.
  12. Thinking in promises... • Helper == agent offering/promising me a

    service – Help with video conference systems: orders, accounts, contracts… – Help with hardware orders and supplies – Help with managing the office network in a remote office – Help with managing Jira projects and other requests regarding Atlassian tools • Agents may not be able to keep their promises – e.g. they may receive conflicting orders from their managers, and those take a higher priority • Me == agent using helpers’ promises, super-agent offering IT services to the company – Promise IT services to employees and manager, based on the promises used – Represent my network of promises to others,or disclose as much details as needed, depending on the agent requesting information
  13. Advantages • I was not imposing on people; • I

    knew clearly what I could expect and by when, and what I could not expect – I was myself able to set realistic expectations for the IT team towards others – I was able to decide what tasks were better to take on and what were simply impossible to achieve at the current state.
  14. Expanding the horizon of PBL • Promise theory can be

    used to model processes – Design processes so that involved “agents” can promise to follow them • Promise-based leadership can be used with direct reports – Remember that impositions don’t guarantee the outcome, so there is no real advantage in using impositions instead of promises • Time to see some concrete examples
  15. Weekly planning • How it works: what tasks can we

    promise for this week? • What’s new with this process: easier to set realistic goals and realise what’s a stretch instead; • Does it work? Still influenced by our traditional way of scheduling, but it’s OK. • Open problem: does it scale to larger teams?
  16. Establishing processes • How it works: understand what people can

    promise, then design processes around that; • What’s new with this process: minimum reliance on imposition, effective processes, almost no need for “police”; • Does it work? It does. • Open problem: one year is not enough to tell if it’s sustainable.
  17. Establishing OKR for a team • How it works: incomplete

    objectives from previous quarter and overall goals for the year are evaluated; we pick from the most important things what we can reasonably promise for the quarter; • What’s new with this process: easier to set realistic goals and realise what’s a stretch instead; • Does it work? Didn’t work well initially because of high priority given to unplanned work (helpdesk); working better now with more focus shifted to long-term improvements (OKR 2017H2 == 66%) • Open question: not tested at scale. If you don’t know OKR: https://www.youtube.com/watch?v=mJB83EZtAjc
  18. promise promise promise promise PB-OKR for a company: seems familiar?

    proposal can’t keep - reformulate proposal can’t keep - reformulate promise can’t accept - reformulate promise can’t accept - reformulate can’t keep - reformulate proposal can’t keep - reformulate can’t keep - reformulate proposal can’t keep - reformulate
  19. Summing up • A promise-based leadership style contributes to better

    relationships with the team, helps setting more realistic goals by making it clear which objectives are doable, which are a stretch and which are impossible; it also contributes to set the right expectations on the people “using” your team; • It requires a leadership attitude that doesn’t rely exclusively on imposition, empowers team members and helps them develop so that they can promise more; • It requires a company culture where it is OK to say “no” and “I can’t do that” and is open to negotiation.
  20. Have a nice trip! Marco Marongiu Email: [email protected] Twitter: @brontolinux

    Web: http://syslog.me/ LinkedIn: https://www.linkedin.com/in/marcomarongiu
  21. Inscription • This work is dedicated to: – Ann Karin

    Tonstad – Anna Kennedy – Anne Omholt – Christoffer Viken – Eva Reisersen – Eyvind Bernhardsen – Gro Kvamme Johnsen – Holger Ihrig – Jarrod Harbrucker – John Corrigan – Kristian Barek – Miha Pirc – Ole Kristian Brattli – Tina Stenberg – Tina Tan – Volker Hilsheimer – ...and all those who helped me and the IT team since I joined Telenor Digital